Electronics > FPGA

Verilog automatic one-hot encoding for state names

<< < (6/6)

rstofer:
My designs are fully synchronous so Gray encoding isn't all that important.  What I really wanted to see was how much longer it took to synthesize when compared to binary or one-hot encodings.  I would be interested to see what the timing report thinks for fmax.

Berni:
Gray code can be useful for crossing clock boundaries.

When you want to get a value across a clock boundary you need to make sure you don't read the value right at a transition point. Otherwise you might get a mix of old and new bits that in binary encoding are garbage. But if you are clock crossing a value that moves by 1 (like a counter or a pretty linear state machine) then reading the value in gray code right at the transition will read the old or new value, but never garbage.

Don't think gray code is much a power saving since while it does toggle less bits, it does need extra logic to encode and decode.

nctnico:

--- Quote from: rstofer on January 27, 2022, 02:59:07 am ---My designs are fully synchronous so Gray encoding isn't all that important.  What I really wanted to see was how much longer it took to synthesize when compared to binary or one-hot encodings.  I would be interested to see what the timing report thinks for fmax.

--- End quote ---
Fmax from the synthesis tells you absolutely nothing about how fast a design can go. You'll need to go through place & route and tweaking the parameters can make huge differences in time needed & the speed that can be achieved.

rstofer:
Timing analysis is far above my pay grade.  It is best left to the wizards of the trade.  But, yes, there are settings to influence place-and-route.  I have never gotten comfortable with the constraints file in either ISE or Vivado although I thought I had a better handle on it under ISE.

Vivado knows what the clock frequency is (generally 100 MHz) and if there is a problem, I'll get a warning or error.  One thing I do note is the number of nonsense warnings that I should probably find a way to disable.  Who cares about the output delay to an LED?  Or the input delay on a pushbutton.  Now, clearly, the are important delays on input and output but not in this particular project.

For the project I am looking at right now, for the worst case delay the net portion of the delay is 3 times the logic delay. 

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version