Hello to everybody, I am trying to decrease usage of elements in my project for Cyclone IV in Quartus II 13.0. I found the way of improvement synchronous sequential circuits in the book (rtl hardware design using vhdl by pong p. chu) (https://www.dropbox.com/s/x5on6xoytyrl8e0/rtl%20hardware%20design%20using%20vhdl.pdf) on pages 213-250. Author proposed to create two segment logic, where next-state and output logic are a combinational circuit and memory elements is only for saving current state. It helps to divide combinational logic from memory and it is better to perform optimization and to fine-tune circuit by author`s opinion. When I used examples from this book and rewrote them by two-segments style, I haven`t recognized any differents in logic usage. And when I tried to adopt my project to this style, I found that logic usage is more than 2 times than one segment style. I tried to test the concept in a simple circuit design, but one-segmented coded style seems to be better in that case too. Example files of two styles are in attachments. Has anybody there been successful with two-segment logic in projects? Thanks for advices.

I don't think the book claim is worth it. separating logic from registers is already the very structure of FPGA. Resource depends on your design and in this case you have added extra counter for the two segment case. I normally use one clocked process for any state machine, clean, timing safe,no latches and readable at the expense of extra registers.

Thanks for reply. By author opinion, two-segments style is better way for optimization of combinational logic by analysis&syntesis module, because it is separated from registers. And It`s seems to be true. If it is, by such reorganization of code, we can get some additional le for other blocks. My attempts has no positive results, but may be anybody has them. Counters in two-segment and one-segment code are the same, I use it for waiting for the end of external process in my project. So I added it to my example.

--- Quote Start --- Thanks for reply. By author opinion, two-segments style is better way for optimization of combinational logic by analysis&syntesis module, because it is separated from registers. And It`s seems to be true. If it is, by such reorganization of code, we can get some additional le for other blocks. My attempts has no positive results, but may be anybody has them. Counters in two-segment and one-segment code are the same, I use it for waiting for the end of external process in my project. So I added it to my example. --- Quote End --- What really matters is your design. after all it is all registers and logic that you ask for whichever way. The state machine is just an old design concept or methodology that translates to registers and logic. For example a two states machine(s1,s2) may end up as two registers(s1,s2). You might equally just use explicit registers: if s1,s2 = 00 then s1,s2 <= 01 ..etc (in fact a counter is same). any other logic can be tied up to these registers e.g. if s1,s2 = 11 then... so in short, it is just a way to clear the mind about the design and I don't see any evidence of better or worse resource.

Functional equivalent designs can be expected to give identical or at least almost equal gate level implementation. The shown examples are functionally different in two regards: - outp is registered in the single process style FSM and combinational in the "two segment" FSM - count works different, resulting in 3 versus 4 counter bits The resource count is different by only one 1 LE in Cyclone 3/4 Choosing one or the other style for resource usage efficiency makes no sense. Personally I prefer single process style for this reasons - visual representation of FSM behaviour, particularly with additional registered signals, may be internal signals like counters or design outputs - no risk of unintentional latch generation by lack of attention - FSM outputs are automatically registered as usually wanted

The two-process FSM has the advantage of being able to generate 'combinatorial' outputs which are often necessary, e.g. for the 'valid' and 'ready' signals in ST-modules. In the case of a single-process FSM you still have to maintain a second (combinatorial) process to generate this kind of outputs. As you now have to 'copy' some of the transition rules over from the synchronous FSM, you end up with two separate processes which can generate a harder debugging chore than weeding out the latches (which Quartus II warns you about). I personally use two-process FSMs 9 times out of 10. I almost never use embedded counters in the FSM but instantiate external components, this produces nicer RTL diagrams. I once spent a lazy Sunday afternoon writing up a contrived example to test this. See the attached .qar.zip. The results are (for Cyclone IV E, auto device): style les registers mhz Two-Process 44 17 386 Synchronous 46 17 378 Hybrid 36 16 380 Hybrid JosyB 35 16 380 Note that the example doesn't have combinatorial outputs.

One segment vs two segment State Machine style

16 Replies

Altera_Forum
Honored Contributor
12 years ago
I just posted a similar question about this earlier on. The thing with one-hot state machines is that you'll need a register for each state. So if you have large state-machines (say, 32 states) that would, as a binary state, only require 5 bits. Yet if it's encoded as one-hot, it will require a bit for each state, effectively turning it into 32 registers.

So if you can achieve the same result with multiple, smaller state-machines that utilize the LUT's better, you could potentially save logic. The more inputs your states require, the bigger your register usage gets as well.

Last but not least, it's a lot easier to maintain a (few) smaller state-machines than one gigantic monster.

-Mux
Altera_Forum
Honored Contributor
12 years ago
Altera choses one hot by default as it has better timing performance. IIRC, it will chose numerical (ie a count sequence) for when Nstates > 32 or 64 (cant remember which). You can chose either of these encoding methods, or grey-code, via attributes in your VHDL. You can even specify what code to give to specific states if you really want, again via attributes so you can keep your state type without using std_logic_vector.
Altera_Forum
Honored Contributor
12 years ago
--- Quote Start ---
I just posted a similar question about this earlier on. The thing with one-hot state machines is that you'll need a register for each state. So if you have large state-machines (say, 32 states) that would, as a binary state, only require 5 bits. Yet if it's encoded as one-hot, it will require a bit for each state, effectively turning it into 32 registers.

So if you can achieve the same result with multiple, smaller state-machines that utilize the LUT's better, you could potentially save logic. The more inputs your states require, the bigger your register usage gets as well.

Last but not least, it's a lot easier to maintain a (few) smaller state-machines than one gigantic monster.

-Mux
--- Quote End ---

To add a little more information to this, I created a single statemachine with less than 8 states for an EPM7128. While the LE count is 2 higher on the segmented statemachine ( selection mux for output ), it uses 10 fewer registers ( 19-vs-29 ) and 16 fewer p-terms (72-vs-88).

Compiling the same code for a Cyclone, you get somewhat similar results with the seperated statemachine taking up more resources ( 37-vs-34 LE's and 32 -vs- 23 registers).
Altera_Forum
Honored Contributor
12 years ago
--- Quote Start ---
To add a little more information to this, I created a single statemachine with less than 8 states for an EPM7128. While the LE count is 2 higher on the segmented statemachine ( selection mux for output ), it uses 10 fewer registers ( 19-vs-29 ) and 16 fewer p-terms (72-vs-88).

Compiling the same code for a Cyclone, you get somewhat similar results with the seperated statemachine taking up more resources ( 37-vs-34 LE's and 32 -vs- 23 registers).
--- Quote End ---

I have been for years and still asking myself if a design passes timing why should we worry about state machine encoding.
state machines is an old and generic methodology of design across various areas of engineering(including mechanical for example) and my understanding is that HDL does not really support it in the true sense. It instead implements the idea in registers to keep track of circuit "memory". Thus a counter can be used equally and if I trust a counter will not go wrong then why should I worry about states extra encoding.
Just a thought. Moreover, the number of extra registers may not matter much unless you have lots of state machines.
Altera_Forum
Honored Contributor
12 years ago
The actual implementation matters depending on what you're after. In my case, it's saving as much space as possible. Looking at the RTL design the separate state-machine seems to bury most of the combinatorial logic inside the LE's, which is kinda what you want whereas the single statemachine has a boatload of combinatorial crap hanging off on the right of it. Now I don't know if that's an accurate visualization but it seems to make sense.

Anything that has lots of combinatorial logic (i.e. large state-machine) will potentially waste registers that can't be used, which means you're not utilizing your resources the fullest extent. It also means that you should get faster performance when you 'front-load' combinatorial logic which is, for all intents and purposes, free.

Of course, in this day and age this doesn't really matter that much but when you're working with an FPGA with 6144 bits or RAM and only 576 LE's, it does :-)

-Mux
Altera_Forum
Honored Contributor
12 years ago
It seems to me that the thread is departing from the initially gained insight that functionally equivalent logic will result in almost identical resource usage. It are the functional differences that matter, e.g. registering or not registering output signals. It has been sufficiently clarified that user requirements are different in this regard. Properties that are considered as advantage by one are unwanted by others. In so far I'm not sure if additional analyses of single versus dual process state machines will bring essentially new results.

State encoding is a special point. For most FPGA FSM designs, the default one hot encoding is just fine. Besides timing, it's also the decoding effort for binary and similar compact encodings that must be counted. My personal favourite for all critical state machines is "safe" encoding, which uses also one state hot representation.

Splitting FSM in partial machines may be reasonable in some cases, but "form follows function". I won't do it to save a few LEs.

I started programmable logic design more than 30 years ago with small GALs and know that tiny CPLD design has other constraints. A CPLD FSM don't use the one state hot default, and it might be necessary to taylor a design down to the function of each register. Thus I won't refer the discussion primarly to CPLD design.

Forum Discussion

One segment vs two segment State Machine style

16 Replies

Recent Discussions

Is Quartus Prime Pro 22.4 Compatible with Stratix 10 NX Series Device?

Timing analysis - long combinational path

QuartusPro 25.3 Crashed after using the Signal Tap Logic Analyzer

Duplicate_hierarchy_depth / duplicate_register

Automatically added negative node for TDS output doesn't work with Agilex 5