Electronics > FPGA

Verilog automatic one-hot encoding for state names

<< < (5/6) > >>

nctnico:

--- Quote from: rstofer on January 26, 2022, 04:37:03 am ---
--- Quote from: nctnico on January 26, 2022, 12:24:24 am ---
--- Quote from: rstofer on January 25, 2022, 12:32:30 am ---The enum's of SV would probably work as long as I can make the eventual value one-hot instead of integer (or something).  I want to avoid the 7 to 100 demux to get the state for subsequent logic expressions.  One-hot gives me just a single bit that I can use without worrying about decoding.

--- End quote ---
I'd let the synthesizer deal what such decissions. Using a large one-hot can easely create a lot of logic to encode the next state as well! Letting the synthesizer deal with the best encoding leaves you the choice to let it optimise for speed or size as well which could be handy.

--- End quote ---

This setting was always an option (buried in the Preferences, I believe) in ISE.  I haven't looked for it in Vivado.

I don't understand the encode issue.

--- End quote ---
Just ask yourself what the logic looks like to produce the next state. If you have cross references between states (from state 1 to state 3 and from state 2 to state 3 for example) then the logic that determines that the bit for state 3 should become '1' depends on the bits state 1 and state 2 AND the signals that influence going to state 3. In the end you are ending up with the same amount of logic! You are basically trying to push a balloon in a suitcase. What you push in from one side, comes out at the other side.

As Berni stated: if speed and / or size are of concern then a programmable statemachine is a much better option. You get the re-use a lot of the logic while allowing complicated state changes. The Picoblaze (from Xilinx) comes to mind.

rstofer:
I have no idea how next_state is generated.  Next time I play with Vivado, I'll come up with a test program with some non-trivial number of states.  I suppose I should look at 1, 2 & 3 process FSMs with binary, gray and one-hot encoding.  I can look at timing and resources.

hamster_nz:

--- Quote from: rstofer on January 26, 2022, 11:04:18 pm ---I have no idea how next_state is generated.  Next time I play with Vivado, I'll come up with a test program with some non-trivial number of states.  I suppose I should look at 1, 2 & 3 process FSMs with binary, gray and one-hot encoding.  I can look at timing and resources.

--- End quote ---

I was trying to think when Gray coding for an FSM would be of use... fully async designs? when the state is used in a different clock domain?

Anybody got any use-cases that make it seem the representation of choice?

Someone:

--- Quote from: hamster_nz on January 26, 2022, 11:34:43 pm ---
--- Quote from: rstofer on January 26, 2022, 11:04:18 pm ---I have no idea how next_state is generated.  Next time I play with Vivado, I'll come up with a test program with some non-trivial number of states.  I suppose I should look at 1, 2 & 3 process FSMs with binary, gray and one-hot encoding.  I can look at timing and resources.

--- End quote ---

I was trying to think when Gray coding for an FSM would be of use... fully async designs? when the state is used in a different clock domain?

Anybody got any use-cases that make it seem the representation of choice?
--- End quote ---
Gray being a special case of binary coding, except the mapping from states to encoding is arbitrary anyway....    so there should be no difference between them other than the optimization goal where known (fixed or more probable) sequences could be preferentially encoded:
https://en.wikipedia.org/wiki/State_encoding_for_low_power
That article mentions the need for a different trade-off depending on the lut/register ratio, so back to implementation specific.

SiliconWizard:

--- Quote from: hamster_nz on January 26, 2022, 11:34:43 pm ---
--- Quote from: rstofer on January 26, 2022, 11:04:18 pm ---I have no idea how next_state is generated.  Next time I play with Vivado, I'll come up with a test program with some non-trivial number of states.  I suppose I should look at 1, 2 & 3 process FSMs with binary, gray and one-hot encoding.  I can look at timing and resources.

--- End quote ---

I was trying to think when Gray coding for an FSM would be of use... fully async designs? when the state is used in a different clock domain?

Anybody got any use-cases that make it seem the representation of choice?

--- End quote ---

As you know, Gray coding has the property of having consecutives values changing only by 1 bit. So first remark is: for a FSM, it will make a difference only if you only cycle through states always in the same order (which can allow you to use consecutive Gray codes for states), otherwise it won't make much of a difference. But if you can ensure the order of states is fixed for a given FSM, the fact only 1 bit is flipping at each transition can both limit power consumption (now on a typical FPGA, it's probably not going to matter much, but for an ASIC, it could) and avoid glitches. Glitches are usually not going to be a problem if your FSM is synchronous (and timing requirements are met), but for asynchronous FSMs, that could be an issue. That is probably not going to matter on FPGAs, because pure asynchronous FSMs are probably a rare beast, but again for general digital design (on ASIC for instance), there could be some use cases.

One-hot encoding will change 2 bits from one state to the next, but it will be consistent for any state change, whatever the order.

All in all, on FPGAs, I've never seen a need for gray encoding for FSMs, and I've almost only ever used one-hot encoding. This is also often the default for FPGA synthesis tools.
But if you're not targetting FPGAs, then I guess it could be needed. Just my 2 cents - do not hesitate to show how Gray coding could be needed/make a real difference on FPGAs, and in which contexts.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

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