On Dec 5, 5:20=A0pm, "carlob" <carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote:> >Anyway...probably I was wrong...I don't need to avoid registered output > >(and a lot of you were right)...in fact I'm always assigning the "output="> >of a FF...therefore I'm sure that when fsm reach a state the output will > >change to the value that is required on that state on the same clock > front > >and I don't have to wait for another clock front to have that value on > >output... > > This is not completely true...state change immediately if change conditio=n> is met...output is still at values on previous state...on the next clock > front the output goes to the new state value...this is the effect of the > output FF...I'm sorry a misunderstanding....No, something is wrong with your understanding. If your outputs are defined at the same time as the next staate is defined, you can get the outputs changing at the time as the state. It just means the outputs will use similar logic to the state logic and will depend on both the current state and the inputs, just as the state does. This can all be in one process. The only limitation of a one process FSM is that the outputs can only respond to the inputs at a clock boundary. There are cases where the output needs to change as soon as the input changes without waiting for the next clock.> ..the difference is now clear....I've just simulated the two > situations...(1 process, 2 process-no register)...and checked the > differences....If you are finding your outputs to be changing one clock cycle after the state changes, then you aren't coding the output to depend on the input, only the state.> Anyway...since all input signals "should be sinchronous" to the raise fro=nt> of the clock and the produced output MUST be synch I think that the best > way to achieve that is registering output and evaluating input on clock > raise...my previous implementation was wrong because output is allowed to > change asynchronously...I have to correct...and I think that 1 process > style fit better the requirements...An output can be synchronous and still be purely combinatorial. All logic between registers is combinatorial, it has nothing to do with how you code your HDL.> If in some cases I will need to unreg output I will use concurrent > statements outside of the process as pointed out in the discussion...But if you need your output registers to change at the same clock edge as the state, that shouldn't be a problem. You don't need combinatorial code to do that. Rick
FSM single process...BIG question
Started by ●December 2, 2010
Reply by ●December 5, 20102010-12-05
Reply by ●December 6, 20102010-12-06
>On Dec 5, 5:20=A0pm, "carlob" ><carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote: >> >Anyway...probably I was wrong...I don't need to avoid registeredoutput>> >(and a lot of you were right)...in fact I'm always assigning the"output=>" >> >of a FF...therefore I'm sure that when fsm reach a state the outputwill>> >change to the value that is required on that state on the same clock >> front >> >and I don't have to wait for another clock front to have that value on >> >output... >> >> This is not completely true...state change immediately if changeconditio=>n >> is met...output is still at values on previous state...on the nextclock>> front the output goes to the new state value...this is the effect ofthe>> output FF...I'm sorry a misunderstanding.... > >No, something is wrong with your understanding. If your outputs are >defined at the same time as the next staate is defined, you can get >the outputs changing at the time as the state. It just means the >outputs will use similar logic to the state logic and will depend on >both the current state and the inputs, just as the state does. This >can all be in one process.Hi Rick...yes...it is definitely....I understand your point...I think that we are expressing the same concept in different ways...it is not easy to explain without an example.....>The only limitation of a one process FSM is that the outputs can only >respond to the inputs at a clock boundary. There are cases where the >output needs to change as soon as the input changes without waiting >for the next clock. >Yes...definitely...I agree...that is another important difference....>An output can be synchronous and still be purely combinatorial. All >logic between registers is combinatorial, it has nothing to do with >how you code your HDL. > > >> If in some cases I will need to unreg output I will use concurrent >> statements outside of the process as pointed out in the discussion... > >But if you need your output registers to change at the same clock edge >as the state, that shouldn't be a problem. You don't need >combinatorial code to do that. > >RickYes...I agree again....what I wanted to say is that my input should be synch with the clock...therefore I think that is a requirement to evaluate their change only on a clock front...the output will change on a clock front too... 1 process approach seems to fit better (input are evaluated on clock raise/fall and, obviously, output will change only on a clock raise/fall...)...I don't wanted to say that you cannot do with combinatorial logic...but, in that case, you have to explicitily code FFs to have that (input and output)...with 1 process it is not needed...FFs are implicit in the HDL... Hope to have explained my point...it is diffucult to say in words this kind of concepts... Thanx Carlo --------------------------------------- Posted through http://www.FPGARelated.com
Reply by ●December 6, 20102010-12-06
>>Anyway...probably I was wrong...I don't need to avoid registered output >>(and a lot of you were right)...in fact I'm always assigning the"output">>of a FF...therefore I'm sure that when fsm reach a state the output will >>change to the value that is required on that state on the same clock >front >>and I don't have to wait for another clock front to have that value on >>output... >This is not completely true...state change immediately if changecondition>is met...output is still at values on previous state...on the next clock >front the output goes to the new state value...this is the effect of the >output FF...I'm sorry a misunderstanding.... > >..the difference is now clear....I've just simulated the two >situations...(1 process, 2 process-no register)...and checked the >differences.... > >Anyway...since all input signals "should be sinchronous" to the raisefront>of the clock and the produced output MUST be synch I think that the best >way to achieve that is registering output and evaluating input on clock >raise...my previous implementation was wrong because output is allowed to >change asynchronously...I have to correct...and I think that 1 process >style fit better the requirements... > >If in some cases I will need to unreg output I will use concurrent >statements outside of the process as pointed out in the discussion... > >Thanx to everyone who helped me... >Carlo >Something that no-one seems to have brought up (sorry if I missed it) is whether you are trying to implement a Mealy FSM or a Moore FSM. What you are doing will infer a Mealy FSM, but I suspect that you don't know why you are using that version. Reading up on the difference should be helpful - there is a lot of stuff available on the Interwebs that any decent search engine will find. For high-speed stuff, I usually go for a Moore FSM, but with registered outputs via a slightly subtle variation. --------------------------------------- Posted through http://www.FPGARelated.com
Reply by ●December 6, 20102010-12-06
>Something that no-one seems to have brought up (sorry if I missed it) is >whether you are trying to implement a Mealy FSM or a Moore FSM. What you >are doing will infer a Mealy FSM, but I suspect that you don't know whyyou>are using that version. Reading up on the difference should be helpful - >there is a lot of stuff available on the Interwebs that any decent search >engine will find. > >For high-speed stuff, I usually go for a Moore FSM, but with registered >outputs via a slightly subtle variation. > > >--------------------------------------- >Posted through http://www.FPGARelated.com >Hi, Yes...it was a Mealy FSM...the output depends on state and input...otherwise you can add more states and move to Moore...but...when you register the output are you already going toward Moore or not??? I think that are similar... It could be interesting to have more info on the the high-speed stuff... Thanx Carlo --------------------------------------- Posted through http://www.FPGARelated.com
Reply by ●December 6, 20102010-12-06
On Dec 6, 5:20=A0am, "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:> >>Anyway...probably I was wrong...I don't need to avoid registered output > >>(and a lot of you were right)...in fact I'm always assigning the > "output" > >>of a FF...therefore I'm sure that when fsm reach a state the output wil=l> >>change to the value that is required on that state on the same clock > >front > >>and I don't have to wait for another clock front to have that value on > >>output... > >This is not completely true...state change immediately if change > condition > >is met...output is still at values on previous state...on the next clock > >front the output goes to the new state value...this is the effect of the > >output FF...I'm sorry a misunderstanding.... > > >..the difference is now clear....I've just simulated the two > >situations...(1 process, 2 process-no register)...and checked the > >differences.... > > >Anyway...since all input signals "should be sinchronous" to the raise > front > >of the clock and the produced output MUST be synch I think that the best > >way to achieve that is registering output and evaluating input on clock > >raise...my previous implementation was wrong because output is allowed t=o> >change asynchronously...I have to correct...and I think that 1 process > >style fit better the requirements... > > >If in some cases I will need to unreg output I will use concurrent > >statements outside of the process as pointed out in the discussion... > > >Thanx to everyone who helped me... > >Carlo =A0 > > Something that no-one seems to have brought up (sorry if I missed it) is > whether you are trying to implement a Mealy FSM or a Moore FSM. What you > are doing will infer a Mealy FSM, but I suspect that you don't know why y=ou> are using that version. Reading up on the difference should be helpful - > there is a lot of stuff available on the Interwebs that any decent search > engine will find. > > For high-speed stuff, I usually go for a Moore FSM, but with registered > outputs via a slightly subtle variation.That's why I never bother to use these definitions anymore. I never code either machine type really. I design FSMs to suit my situation. These two machine types were created to facilitate the mathematical analysis of FSMs and I find using these terms adds little to analyzing my design. Just my two cents... Rick
Reply by ●December 6, 20102010-12-06
On Dec 6, 6:02=A0am, "carlob" <carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote:> >Something that no-one seems to have brought up (sorry if I missed it) is > >whether you are trying to implement a Mealy FSM or a Moore FSM. What you > >are doing will infer a Mealy FSM, but I suspect that you don't know why > you > >are using that version. Reading up on the difference should be helpful - > >there is a lot of stuff available on the Interwebs that any decent searc=h> >engine will find. > > >For high-speed stuff, I usually go for a Moore FSM, but with registered > >outputs via a slightly subtle variation. > > >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0 > >Posted throughhttp://www.FPGARelated.com > > Hi, > Yes...it was a Mealy FSM...the output depends on state and > input...otherwise you can add more states and move to Moore...but...when > you register the output are you already going toward Moore or not??? I > think that are similar... > > It could be interesting to have more info on the the high-speed stuff...The Mealy vs Moore doesn't have to do with registering the outputs. That is just an issue of delays since registering the inputs and/or the outputs delays the outputs. The real difference is that the outputs become a sort of separate state machine on their own although the output values don't feed back to affect either the machine state or the output state. But the outputs are an independent function of the inputs and the outputs. The outputs can change value with input changes without the state changing. The outputs can have a different value for the same state depending on how you reached that state. I used to design FSMs considering the issues of Mealy vs Moore, but now I just design FSMs based on what I need and don't even bother with the M v. M distinction. The bottom line is there are many variations on the theme, so why bother with just these two? Rick
Reply by ●December 6, 20102010-12-06
>On Dec 6, 6:02=A0am, "carlob" ><carlo.beccia@n_o_s_p_a_m.n_o_s_p_a_m.libero.it> wrote: >> >Something that no-one seems to have brought up (sorry if I missed it)is>> >whether you are trying to implement a Mealy FSM or a Moore FSM. Whatyou>> >are doing will infer a Mealy FSM, but I suspect that you don't knowwhy>> you >> >are using that version. Reading up on the difference should be helpful->> >there is a lot of stuff available on the Interwebs that any decentsearc=>h >> >engine will find. >> >> >For high-speed stuff, I usually go for a Moore FSM, but withregistered>> >outputs via a slightly subtle variation. >> >> >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0 >> >Posted throughhttp://www.FPGARelated.com >> >> Hi, >> Yes...it was a Mealy FSM...the output depends on state and >> input...otherwise you can add more states and move toMoore...but...when>> you register the output are you already going toward Moore or not??? I >> think that are similar... >> >> It could be interesting to have more info on the the high-speedstuff...> >The Mealy vs Moore doesn't have to do with registering the outputs. >That is just an issue of delays since registering the inputs and/or >the outputs delays the outputs. The real difference is that the >outputs become a sort of separate state machine on their own although >the output values don't feed back to affect either the machine state >or the output state. But the outputs are an independent function of >the inputs and the outputs. The outputs can change value with input >changes without the state changing. The outputs can have a different >value for the same state depending on how you reached that state. >Strictly speaking you are right... :-))>I used to design FSMs considering the issues of Mealy vs Moore, but >now I just design FSMs based on what I need and don't even bother with >the M v. M distinction. The bottom line is there are many variations >on the theme, so why bother with just these two? > >Rick >Yes...in effect...you are right....I usually don't pay attention to Moore/Mealy too.... Carlo --------------------------------------- Posted through http://www.FPGARelated.com
Reply by ●December 6, 20102010-12-06
rickman <gnuarm@gmail.com> wrote: (snip)> The Mealy vs Moore doesn't have to do with registering the outputs. > That is just an issue of delays since registering the inputs and/or > the outputs delays the outputs. The real difference is that the > outputs become a sort of separate state machine on their own although > the output values don't feed back to affect either the machine state > or the output state. But the outputs are an independent function of > the inputs and the outputs. The outputs can change value with input > changes without the state changing. The outputs can have a different > value for the same state depending on how you reached that state.> I used to design FSMs considering the issues of Mealy vs Moore, but > now I just design FSMs based on what I need and don't even bother with > the M v. M distinction. The bottom line is there are many variations > on the theme, so why bother with just these two?Many years ago, I was using some system with a state machine compiler. After doing a design (I believe as part of a tutorial session) I figured out that my design was somewhere between Mealy and Moore. Also, I once found a bug in the Altera state machine optimizer, by designing one in a way that the tools didn't expect. It seems that the tools wanted a separate verilog case block for state selection and output generation. I believe that is independent of the Mealy vs. Moore question, but they are much easier for me to read with state selection and output selection together. -- glen
Reply by ●December 6, 20102010-12-06
I really do not recommend combined clocked processes with combinatorial paths from in to out. They tend to have many of the disadvantages of both clocked and combinatorial processes. What's the difference between adding a flag (v_delay) and adding another state? In general, if I'm using an FSM to control the timing of something, I don't want to also use flags set by the FSM. Or if I'm using flags to control the timing of something, I don't want to also use the FSM state itself (especially if the FSM is the one controlling the flags) So, you could add a TXD_Delay state to replace the flag: if (reset='1') then act_txd_state := TXD_IDLE; elsif (clk'event and clk ='1') then case act_txd_state is when TXD_IDLE => if (txValid = '1') then act_txd_state := TXD_ACTIVE; end if; when TXD_ACTIVE => if (txReady = '1') then act_txd_state := TXD_DELAY; end if; when TXD_DELAY => act_txd_state := TXD_END; when TXD_END => if (txValid = '0') then act_txd_state := TXD_IDLE; end if; end case; end if; if (act_txd_state = TXD_ACTIVE) OR act_txd_state = TXD_DELAY) then if (dataIn = "00000000") then tx_data <= "01000000"; else tx_data <= "11000000"; end if; elsif (act_txd_state = TXD_END) then tx_data <= dataIn; else tx_data <= "00000000"; end if; Or you could create a better flag that tells you exactly when to alter or pass data_in, and not have to bother with decoding the FSM elsewhere. This is my favorite method, if the outputs cannot be coded directly in the case statement for the FSM. It decouples the FSM state transitions, etc. from the output logic. If you later need to add/ remove/change states (for error handling, etc.), your output logic need not change. Note that since the flag is only used in conditional statements, it is easier to use if it is defined as a boolean. Of course, it could probably use a more descriptive name too. if (reset='1') then act_txd_state := TXD_IDLE; v_flag := false; elsif (clk'event and clk ='1') then -- v_flag := '0'; -- get rid of this, we don't want it defaulting back to 0 case act_txd_state is when TXD_IDLE => if (txValid = '1') then act_txd_state := TXD_ACTIVE; v_flag := true; end if; when TXD_ACTIVE => if (txReady = '1') then act_txd_state := TXD_END; v_flag := false; end if; when TXD_END => if (txValid = '0') then act_txd_state := TXD_IDLE; end if; end case; end if; -- Do you really need tx_data to be "00000000" at the end? -- I'm going to assume that you really don't care what it is, right? if v_flag then -- greatly simplified here & decoupled from FSM design if (dataIn = "00000000") then tx_data <= "01000000"; else tx_data <= "11000000"; end if; -- elsif (act_txd_state = TXD_END) then else tx_data <= dataIn; -- else -- tx_data <= "00000000"; end if; Of course, this last example also would be simple to split into a separate, clocked process for FSM, and a combinatorial process for the data path (v_flag would have to be a signal.) Here is a concurrent assignment statement that would do the trick: tx_data <= "01000000" when v_flag and data_in = "00000000" else "11000000" when v_flag else data_in; Hope this helps, Andy
Reply by ●December 6, 20102010-12-06
I agree with the advice to achieve the "very best performance," but only if that means "fastest clock speed". However, that is true for probably < 5% of most FPGA design work (not necessarily only 2% of FPGA resources). Sure, there are pieces of many FPGA designs where Fclk rules, but those pieces are usually small (especially in terms of how difficult it is to describe) compared to the rest of it. My point is, don't start worrying about what will fit in a LUT until you have to worry about Fclk. For the other 98% of your project that doesn't care, best performance = "easiest implementation to read, write, verify and maintain". For many organizations, "verify" also means review/audit by peers, so approaches to design are preferred that are simple not only for you to understand, but also your potential reviewers/auditors. Luckily, approaches that are easy for them to understand are also likely to be easily understood by potential maintainers, which might even be yourself in another few weeks/months/years. Hint: describe the behavior you want, not the implementation you think you want, at least until the tool tells you it can't come up with an implementation on its own that meets timing and available resources.
