How Many Blocks Do You Use When Designing a FSM? - Page 1
Forum section: electronics / general

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 14, 2020, 07:03:34 pm
content: I’ve seem FSMs written to use one, two, three, and even four process/always blocks. How many do you use in your FSMs?

author: ejeffrey
author_rank: Super Contributor
timestamp: July 14, 2020, 08:09:47 pm
content: Generally 2 but sometimes 3.One combinatoric block for state transition computation. One for clocked logic and reset. Generally I will put the outputs in with the clocked logic, but if it gets too complex I would use a separate combinatoric block.

author: filssavi
author_rank: Frequent Contributor
timestamp: July 14, 2020, 09:20:22 pm
content: Since the FSMs I need are usually small and boring Bus interfaces for custom IPs I tend to use just. A single always block And I tend to use Moore type as much as possible (no asynchronous logic to fuck with my timing).If for some strange reason I can’t avoid going mealy, then two blocks are needed.IMO having everything in a single always block improves tremendously the readability of the code, as everything you need to fully understand how the FSM operates is logically and spatially close together. This obviously only works if the machine is small enough (as it always is in my case) not to require its own module/file.

author: Bassman59
author_rank: Super Contributor
timestamp: July 14, 2020, 11:41:24 pm
content: One sequential process. Never more than one. Synthesis tools have been able deal with single-process state machines for 20 years now. Also the distinction between "Mealy" and "Moore" machines is purely academic and rather silly.

author: 0db
author_rank: Frequent Contributor
timestamp: July 15, 2020, 12:44:13 pm
content: Quote from: Bassman59 on July 14, 2020, 11:41:24 pmWell, actually Mealy can do more than Moore!The difference between a Mealy machine and a Moore machine is how and when the outputs are changed. In a Moore machine, the outputs are set based on the current state. In a Mealy machine on the other hand, the outputs are set when the state change happens.It's not silly when it's relevant. Otherwise you can ignore the difference. But there is a difference

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 15, 2020, 02:28:40 pm
content: Quote from: Bassman59 on July 14, 2020, 11:41:24 pmSame here. I'd still like to see real arguments in favor of using more than one sequential process, and possibly figures about performance if performance (max speed for instance) can be influenced by that. I for one have never had a problem with single-process FSMs, and they are generally easier to read and easier to maintain.As to Mealy vs. Moore FSMs, as summed up here:https://en.wikipedia.org/wiki/Mealy_machineQuoteBoth can be implemented with a single sequential process if you stick to that base definition, and the one you use entirely depends on the application, depending on whether you need to take the "current inputs" into account or not. I've heard some people more or less claim that they implement their FSMs the "Moore" style because they split them in several processes, which can make it look like the "outputs" only depend on the current state, but if you need to take "inputs" into account in another (or several other) process(es), this is just bullshit IMHO, and still is a Mealy machine that you have just structured differently.Of course, whatever approach you use, the clock cycle at which "outputs" and state change is a concern, and depending on whether you use a single sequential process, or several processes including a combinatorial one, things may not happen with the same "latency", which IMHO is the main point to consider here.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 15, 2020, 03:42:08 pm
content: Quote from: SiliconWizard on July 15, 2020, 02:28:40 pmHere's a paper by Cliff Cummings, who presents papers on subjects like this at various industry conferences:http://www.sunburst-design.com/papers/CummingsSNUG2019SV_FSM1.pdfHe covers many of the trade-offs and pitfalls of 1-, 2-, 3-, and 4-block FSMs.

author: ejeffrey
author_rank: Super Contributor
timestamp: July 15, 2020, 03:50:28 pm
content: Quote from: SiliconWizard on July 15, 2020, 02:28:40 pmHonestly I mostly prefer 2 blocks just because that is how I learned. I do find them easier to write and they look clearer to me but I suspect that is just because of familiarity. I do like that they tend to have at least one fewer layer of nesting. Another advantage to me is that if I do my state transition computation within a verilog always_comb block the synthesizer will warn me if I miss a case because it will infer a latch. Inside a sequential block, the state will just remain unchanged. I don't think there is any performance or functionality impact either way. AFAIK they are completely equivalent as far as the synthesizer is concerned.QuoteYes, most important of course is that the FSM does what it is supposed to.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 15, 2020, 04:02:25 pm
content: Quote from: ejeffrey on July 15, 2020, 03:50:28 pmThis is understandable, and in my own humble experience, one of the most common reasons engineers use the 2-block style. It was common to teach FSMs this way, probably a bit less so these days.You're being honest though, as quite a few of them tend to say "it's just how you do it" instead of admitting that "it's what I learned and am comfortable with".

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 15, 2020, 04:38:35 pm
content: Quote from: Sal Ammoniac on July 15, 2020, 03:42:08 pmThis study is based on SystemVerilog, but I don't think it matters much. The same applies to Verilog and VHDL IMO.Didn't read it thoroughly, but from what I've seen and related to this thread:- One of the main points against the 1-block approach seems to be the "coding effort" (and by that, it looks like they judged it by the number of lines of code...). OTOH, the 1-block approach has good performance overall compared to others.- The 2-block approach, which is pretty commonly seen, doesn't look all that interesting as far as coding effort or performance goes.- They seem to recommend the 3-block approach, or the 4-block for better performance (but still akin to that of the 1-block.)- One point to consider is that "area" and "perfomance" are obviously different on FPGAs and ASICs, so if you're mainly/exclusively using FPGAs, you likely don't need to bother as much in the general case.Of course this is very simplified, so don't hesitate to correct me or add missing points that would be important.After reading that, and considering I still think just one block is more readable and much easier to maintain (even if it may require more LOCs), I'm probably not going to change styles for the time being.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 15, 2020, 05:04:45 pm
content: Quote from: SiliconWizard on July 15, 2020, 04:38:35 pmThat's pretty much the conclusion I came to after reading that paper.

author: tggzzz
author_rank: Super Contributor
timestamp: July 15, 2020, 05:54:14 pm
content: Quote from: Sal Ammoniac on July 14, 2020, 07:03:34 pmMy answer is the same for whatever language and technology is used, from gates up to and including traditional application languages like Java.There are two key considerations:starting with avalidatedspecification, choose whatever style makes it easiest toseethat the implementation matches the specification. Testing ought to be a "minimal afterthought"specifications frequently mutate over time, either because functions are added or errors are found. Choose whatever style enables you to unambiguously and clearly determineexactly which part of the implementationhas to change to match the new specification - and that thechange doesn't affect other partsof the specification. The latter may mean that some duplication is beneficial. Given the low cost of hardware, often that is a good tradeoffYou might be able to guess where I stand w.r.t. this justly famous quote: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult". ― C. A. R. HoareSo, since specifications can take many forms, I wouldn't obsess too much about trying to define The One True Style. Instead match the style to the specification.

author: asmi
author_rank: Super Contributor
timestamp: July 15, 2020, 06:09:09 pm
content: I liked that part:QuoteAs to the actual question, I use 1 (always_ff) block and 4 (2 always_ff and two always_comb) blocks. Typically start from the former, and at some point convert it to the latter, because as the complexity of FSM grows, it becomes easier to think of the logic in terms of what outputs should be for each state, rather than when transitions have to happen, which is what the former essentially is. Also 1 block approach is easier to grasp for beginners in HDL coming from regular imperative programming, because it "kinda sorta" works like a program would.

author: Bassman59
author_rank: Super Contributor
timestamp: July 15, 2020, 07:20:51 pm
content: Quote from: SiliconWizard on July 15, 2020, 04:02:25 pmThe reason many engineers were taught to use the 2-block style is because early synthesis tools -- I'm talking about you, Synopsys FPGA Express! -- required that idiom because they were dumb. All of the code examples for those tools showed the two-block style. And even though synthesizers have come a long way since, and they all support one-block FSMs, the examples in the documentation still show that two-block style.So the new engineers learning the languages and the tools look at the examples in the documentation and emulate it. Or perhaps their instructors, who don't have any real-world experience, teach the ancient idioms and not the improvements, so of course the students follow that.And -- pardon my French here -- for fuck's sake, for VHDL the documentation still shows code examples written using VHDL-87 idioms.if clk'event and clk='1'is still used instead ofrising_edge(clk). G-d forbid an example shows a label on a process or a label on a case statement. D-g forbid they showend architecture fooinstead ofend foo. And they still use the obsoletestd_logic_arithlibraries that should have been pulled from the language oncenumeric_stdwas released 27 years ago!For Verilog the examples don't show the simplified port lists introduced in Verilog-2001. (I haven't done Verilog in a long time so I'm sure I'm behind in the other improvements.)</rant off>I previously posted an example of code I use to implement a state machine that can have variable/programmable state durations. It involved setting a signaldurationin each to the desired time. Outside of the state decoder (but in the same clocked process),durationdecrements until zero. In the state machine, the states that care about the duration timing wait for it to go to zero and then they do something.In other words, in stateS_FOO, we setdurationtobarand immediately transition to stateS_BAR, where we wait untildurationis zero before doing the next thing.So, is this a Mealy machine? A Moore machine? As one of my physics professors liked to say, "Don't know! DON'T CARE!" What is important is that the logic works as intended, and whether it fits an academic idiom or not is, as I said, irrelevant.Does anyone put the decrementer in a combinatorial process and register it in a separate synchronous process? If so, WHY?

author: rstofer
author_rank: Super Contributor
timestamp: July 15, 2020, 07:23:11 pm
content: I use two processes - always! There is a simple clocked process that sets state <= nextstate and a combinational process with all the actions to be taken at each state including generating nextstate. That's the only way i have ever done it.The question is fairly popular and there probably isn't a single perfect answer. This blog post talks about 1, 2 or 3 process FSMshttps://vhdlwhiz.com/n-process-state-machine/I still prefer the 2 state variant. When I am looking at a state, I want to see everything that happens as a result of being in that state. I don't want to have to chase after a 3rd process hundreds of lines away. True, a signal set in a state may kick off a process a long way away but at least I can see the signal and comment on what's going to happen when I change its value.ETA: For those of us who are mere students of FPGAs maybe this book has some merit:https://www.amazon.com/Finite-State-Machines-Hardware-SystemVerilog/dp/0262019663

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 15, 2020, 08:21:46 pm
content: Quote from: Bassman59 on July 15, 2020, 07:20:51 pmThanks for that info. I'm probably not quite old enough to have run into these early tools.Quote from: Bassman59 on July 15, 2020, 07:20:51 pmYes, that's pretty much how it happens.Quote from: Bassman59 on July 15, 2020, 07:20:51 pmFully agree. Those points are really bad when still taught by teachers. They should reasonably follow how standards evolve and what's recommended. std_logic_arith in particular is NOT part of the standard, and ever since std_numeric was introduced, it should definitely NOT be taught. (Maybe just talked about so students understand what this is if they ever run into it in existing code, and understand why they shouldn't use it.)But as to your remark, std_logic_arith HAS been pulled from the language. It's not part of the IEEE standard. Teachers/code examples still use it out of habit and laziness. It is still available in most tools for legacy reasons. (Removing it would break a lot of code.)Quote from: Bassman59 on July 15, 2020, 07:20:51 pmAs I said above. I agree with the "don't care" here, but basically if your FSM depends on "inputs" (whatever you actually DEFINE as inputs in your design), then IMHO it is a Mealy FSM, doesn't matter in how many blocks you partitioned it. If you have states, and counters for some of the states, then I guess those counters should count as "inputs" formally speaking, but as they are mostly a way to restrict the number of states (you could use a lot of states instead, theoretically), then I guess you could also say it's a Moore FSM.Who cares really - bottom line is, the fact your FSMs are made of 1 or more blocks doesn't make them Moore or Mealy just by that metric. And yes I agree, I don't care either.

author: tggzzz
author_rank: Super Contributor
timestamp: July 15, 2020, 08:37:49 pm
content: Quote from: asmi on July 15, 2020, 06:09:09 pmYes, that is idiotic "logic".It implies everything should be written in APL, where, according to the old joke, all programes can be one line long.

author: asmi
author_rank: Super Contributor
timestamp: July 16, 2020, 07:59:24 pm
content: Quote from: tggzzz on July 15, 2020, 08:37:49 pmNo it is not. My experience in both software and hardware development backs it up 100%. The only code that's guaranteed not to have bugs is the one that doesn't exist. But I figured VHDLers would get a kick out of itQuote from: tggzzz on July 15, 2020, 08:37:49 pmNo it's doesn't imply that. Moreover it doesn't talk about lines of code, but the amount of it. That's why boilerplate is cancer, not only it's a PITA to write over and over again, but it reduces the signal-to-noise ratio of the code during reading, and almost any code is read much more that it is written.

author: ejeffrey
author_rank: Super Contributor
timestamp: July 16, 2020, 08:38:10 pm
content: It's not 100% for sure, but amount of code is an extremely good indicator for how much effort it takes to develop and more important debug -- when you are talking about implementing the same thing. That's usually where people get misled, they compare code doing something complex in a high level language to code doing something simpler and more verbosely in a low level language.

author: tggzzz
author_rank: Super Contributor
timestamp: July 16, 2020, 11:00:46 pm
content: Quote from: asmi on July 16, 2020, 07:59:24 pmI've seen idiots try to minimise the number of lines of code on that basis; the result was an incomprehensible mess.It ismuchbetter to make code readable and modifiable, at the expense ofsomeextra lines.QuoteAh. Somebody that doesn't realise that in APL more or less everycharacteris equivalent to a statement in other languages. For example (~R∊R∘.×R)/R←1↓ιR generates all the prime numbers from 1 to R, or Conway's Game of Life is life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵} Now you may regard that as better because it is shorter; to me it looks like line noise.Boilerplate is tolerable if it makes it easier tomaintaincode, especially code written bysomebody else.

author: BrianHG
author_rank: Super Contributor
timestamp: July 17, 2020, 12:21:03 am
content: Quote from: asmi on July 16, 2020, 07:59:24 pmThere are no such things as bugs. It's all advanced intelligent hidden features.

author: Bassman59
author_rank: Super Contributor
timestamp: July 17, 2020, 03:02:52 am
content: Quote from: tggzzz on July 16, 2020, 11:00:46 pmAs we say in Hoboken, "fuck is that shit!"

author: tggzzz
author_rank: Super Contributor
timestamp: July 17, 2020, 07:54:37 am
content: Quote from: Bassman59 on July 17, 2020, 03:02:52 amHave a go athttps://tryapl.org/Try7 - 77 - 7 - 77 - 7 - 7 - 77 - 7 - 7 - 7 - 7and explain the resultsIt does have one nice feature: "proper" representation of negative numbers. If you remember back to school, you were probably confused by "-3" and "X-3". In the latter the "-" is an operator, in the former it is part of the number. APL makes the distinction: a negative number is represented by "high neg", e.g. ¯3.

author: rstofer
author_rank: Super Contributor
timestamp: July 17, 2020, 02:19:22 pm
content: I was taught that the unary minus in -3 simply meant 0-3.I wonder if the "high neg" evolved from signed-magnitude notation where the most significant bit is the sign and all other bits represented a positive value. -7 => b'1111 and +7 => b'0111. This was a popular encoding in the early days of computers. It eventually lost out to 1's and 2's complement.

author: tggzzz
author_rank: Super Contributor
timestamp: July 17, 2020, 03:17:30 pm
content: Quote from: rstofer on July 17, 2020, 02:19:22 pmYeah, that was the unconvincing "explanation" I suffered too.It convinced me as much as the explanation that wings generate lift because a glob air has to travel further over the top surface in order to meet up with the corresponding glob that goes under the wing. No, the globs don't meet up and that isn't how lift is generated!QuoteAPL started as a mathematical notation, and only mutated into a programming language a few years later. When it did, not all computers were twos complement; some were ones complement.But to turn back towards the original thread, APL is a good illustration that brevity can be taken too far. Sometimes more is better; it is all a matter of good taste.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 17, 2020, 04:21:49 pm
content: Let's try to stay on topic... but as the "coding effort" was one of the criterions mentioned in the linked article, a few points come to mind.- "Coding effort" is a very vague term. What would be seen as more "effort" to someone may look like the same, or even less "effort" to someone else.- When people try to quantify it, a few metrics pop up. The number of LOCs is commonly used, even though it's obviously flawed on several levels. Usually LOCs are counted excluding comments and blank lines. But is that really related to the "coding effort"? Not really. Expressing the same functionality with fewer LOCs can actually take much more effort.- As has been said here, and that I often say as well, when writing in any language, readability is key. If better readability means more LOCs, so be it; you're not likely to get anything better (fewer bugs for instance) by making your code less readable.- When comparing languages and/or coding styles, "verbosity" is often a key marker. But that has to be clearly understood, and clearly defined. Some languages are inherently more "verbose" than others (such as VHDL is more "verbose" than Verilog), so a similar implementation will take more "code", but is this extra code a source of bugs? I don't buy it whatsoever. So that's another way considering LOCs and verbosity in particular is completely flawed. Considering verbosity, the extra "coding effort" is merely some typing effort, and of course, aiming for the shortest code possible can lead to absurd, unreadable and completely unmaintainable code.- Linking the average number of "bugs" to the number of LOCs is also a common metric. Whereas it's flawed, it kind of becomes statistically significant in a given team using given tools if the number of LOCs is large enough. It's hard or impossible to transpose it to other teams, and if the number of LOCs is small, it usually doesn't make any sense anyway.- Back to HDLs: a typical HDL project is usually much smaller than a typical software project, so definitely the number of LOCs can't be used statistically to infer the potential number of bugs IMO, even in a given team using given tools.- Considering the coding effort, the number of "statements" is a slightly better metric than the number of LOCs. But it's still flawed. The basic idea is that if you need to write more statements to implement a given design, there are just more opportunities to introduce bugs. Statements itself is a vague metric. To make sense, we should consider statements that actually have an effect. But even so, sometimes implementing a given feature in fewer statements is much harder, and thus is more likely to introduce bugs than merely splitting the implementation over several statements, even if it's more code. And of course, as already said, if it helps readability, it's also likely to help limit the number of bugs.- One factor that makes code harder to write correctly and maintain is splitting implementation in too many places that have dependencies between themselves. Back to HDLs and FSMs, splitting a given FSM into several processes (depending of course on the structure and FSM itself) can fall into this category, in which case, even though it may lead to fewer LOCs (or better, statements), is much harder to get correct and even harder to maintain.

author: tggzzz
author_rank: Super Contributor
timestamp: July 17, 2020, 05:14:53 pm
content: Quote from: SiliconWizard on July 17, 2020, 04:21:49 pmPrecisely. I often know I am succeeding when the number of lines of my code is reducing. If any managers were stupid enough to have a LOC/day or more LOC==more complete metric, then they would be having kittens.QuotePrecisely. Frequently more typing means static errors are discovered earlier, thus reducing the overall project duration.As for typing effort, in a decent language plus IDE plus design patterns, autocompletion removes a lot of the keyboard bashing. That's possible because the "extra" typingelsewherehas reduced the number of possibly valid options atthispoint in the code - and that means fewer static errors.QuoteTastefully splitting a single FSM into multiple cooperating FSMs is likely to be more effective at reducing bugs than fiddling with two processes vs three processes, or fiddling with the numbers of lines of code.Tasteful use of appropriate design patterns may (or may not) increase the number of lines of code, but should increase the clarity of the implementation.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 17, 2020, 06:31:04 pm
content: Quote from: tggzzz on July 17, 2020, 05:14:53 pmAs long as you don't go overboard and start creating things likeSimpleBeanFactoryAwareAspectInstanceFactoryandAbstractInterceptorDrivenBeanDefinitionDecorator.

author: tggzzz
author_rank: Super Contributor
timestamp: July 17, 2020, 07:51:58 pm
content: Quote from: Sal Ammoniac on July 17, 2020, 06:31:04 pmWithout context I can't tell whether those display good taste or bad tasteTyping them will be relatively painless, using ctrl-space or whatever the IDE uses for autocompletion (I conjecture without evidence that VHDL might be better than Verilog in that respect).They occupy a lot of horizontal space, maybe 20% of my window's width. Just as well we have more than 80*24 screens nowModules/namespaces help a lot too.

author: 0db
author_rank: Frequent Contributor
timestamp: July 17, 2020, 08:16:24 pm
content: back to fsm: anyone does how how SCALA implement fsm? with one block? two blocks? three blocks? with one block + variables?

author: Bassman59
author_rank: Super Contributor
timestamp: July 17, 2020, 08:29:28 pm
content: Quote from: tggzzz on July 17, 2020, 07:51:58 pmemacs vhdl-mode: tab autocompletes. And it auto-completes and generates templates, too!

author: Bassman59
author_rank: Super Contributor
timestamp: July 17, 2020, 08:30:25 pm
content: Quote from: 0db on July 17, 2020, 08:16:24 pmNobody uses SCALA

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 18, 2020, 04:29:28 pm
content: Quote from: Bassman59 on July 17, 2020, 08:30:25 pmI suppose he's talking about Chisel, which is based on Scala? It would probably take someone who knows Chisel very well to answer this question.(So, that's not quite nobody, but still a niche.)

author: 0db
author_rank: Frequent Contributor
timestamp: July 18, 2020, 05:07:15 pm
content: Quote from: SiliconWizard on July 18, 2020, 04:29:28 pmYup. Precisely. Chisel/Scala implements fsm-s in the same way the C language implements arrays in assembly. But I wonder how?!?

author: NorthGuy
author_rank: Super Contributor
timestamp: July 20, 2020, 03:34:17 pm
content: I don't think the two-block habit comes from ancient languages. It comes from the theory. FSM is two transforms:Code:(inputs,state) -> statestate -> outputHence, the straightforward implementation uses two processes. The first one is clocked to calculate the next state, and the second one is typically combinatorial to calculate the output.From the programming viewpoint, it's certainly easier to use one process because everything is in one place. If you used two processes, they often would have similar "ifs" and "cases". You're certainly better off if you have only one copy of each of these.From the design viewpoint, it doesn't matter if you used one process or two. The result is likely to be identical.

author: ejeffrey
author_rank: Super Contributor
timestamp: July 20, 2020, 04:22:03 pm
content: Quote from: NorthGuy on July 20, 2020, 03:34:17 pmI don't think that is the way the OP was discussing using a two process block. The canonical "two-process" FSM that I have seen has a combinatorial process to calculate the next state and a clocked process to actually assign "state <= next" and to handle reset. If the output is non-trivial and placed in its own process then that would be a 3 process FSM.You could certainly write a 2 process FSM that uses a single sequential process for the state logic and a separate combinatoric one for output assignment, but I don't think that is what most people above were talking about.

author: rstofer
author_rank: Super Contributor
timestamp: July 20, 2020, 05:52:41 pm
content: Quote from: NorthGuy on July 20, 2020, 03:34:17 pmIt seems to me, when it comes to providing signals to logic outside the FSM, there is a one clock delay in the clocked-only design because of the Moore model (the outputs, in this case, are registered). The Moore model produces less glitches (if they matter) but there is a delay (latency). Pipelines fit in here somewhere...There is a book, "Finite State Machines in Hardware - Theory and Design (with VHDL and SystemVerilog)" by Volnei A. Pedroni that spends 300+ pages on this stuff. The author breaks FSMs into 3 categories 1) Regular State Machines, 2) Timed State Machines and 3) Recursive State Machines (having code like y=y+1 where y has to be stored somewhere) along with Mealy and Moore implementations of each in both VHDL and SystemVerilog (which looks more like VHDL than Verilog).I haven't finished the book but it's a pretty good read. It covers things I hadn't thought about and points out where my use of Karnaugh maps has been deficient when thinking in terms of glitch free transitions. Minimal logic isn't always the goal! I have to believe I used to know this stuff but it's been a long time since I was in school.I really wanted an introduction to SystemVerilog and since all of the complexity in my projects revolves around FSMs, this seemed like a targeted approach.https://www.amazon.com/gp/product/0262019663

author: rstofer
author_rank: Super Contributor
timestamp: July 20, 2020, 06:03:22 pm
content: Quote from: ejeffrey on July 20, 2020, 04:22:03 pmAlas, that is exactly what I was describing: One clocked process to deal with reset and setting state <= next_state along with a much larger combinational process to generate next_state and all of the FSM outputs. Definitely a Mealy machine.The one trap for young players is that every output of an FSM must be defined at every instant in time. This leads to setting default output values for every output at the top of the combinational process. This sometimes gets overlooked when adding additional outputs later on. It turns out that most trivial textbook examples don't do this, they just specify every output in every state and conditional. Sometimes textbook examples are misleading!

author: Bassman59
author_rank: Super Contributor
timestamp: July 20, 2020, 06:38:56 pm
content: Quote from: rstofer on July 20, 2020, 05:52:41 pmAnd the glitching is the reason why the state machine outputs are registered.In the two-process model, you have a combinatorial process assigning all outputs and the next state as well as a synchronous process registering the next-state as well as possibly registering the outputs. If you don't have the registered outputs, you stand a good chance of glitching because of all of the decoding paths.So if you are going to register the state register -- which you have to do, anyway -- and you're going to register the machine outputs, then why not combine that all into one synchronous process?There is an argument mentioned in this thread and elsewhere that goes, "well, I have a signal foo and if I assign it in state S_FOO, then with a synchronous process then foo looks like it changes in the next state S_BAR! AND I DON'T LIKE THAT!" That's a pretty silly argument,QuoteMy reason for calling the discussion about Mealy-vs-Moore-vs-Whatever state machines "academic" is because when you design your logic, you might combine all of the elements of those types and your result is a mix. And really, to reiterate again, what matters is the actual functionality of the logic, not whether the code fits into some predefined pigeonhole.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 20, 2020, 09:22:27 pm
content: Quote from: rstofer on July 20, 2020, 05:52:41 pmI've had that book on my Amazon shopping list for a while now and based on your comments will get and read it.QuoteMy go-to book for SystemVerilog is this one. It's not specific to FSMs, but covers all the basics with an emphasis on synthesizable RTL.https://www.amazon.com/RTL-Modeling-SystemVerilog-Simulation-Synthesis/dp/1546776346/

author: rstofer
author_rank: Super Contributor
timestamp: July 21, 2020, 02:23:29 am
content: Quote from: Sal Ammoniac on July 20, 2020, 09:22:27 pmWell that was expensive! Education has never been free.Basically, my interests are really on synthesizable RTL. I don't spend a lot of time with simulation even though I'm trying to learn more about it.

author: Someone
author_rank: Super Contributor
timestamp: July 21, 2020, 07:03:42 am
content: New answer:less than 1 blockWriting out a dense module today that the tools decided was best implemented in 2 state machines (all 3 majors, but they didn't agree on the encoding), despite their only being one block. Resource usage was around where a hand made implementation would reach and it tests out ok in simulation and hardware. So another win for using high level languages as high level languages.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 21, 2020, 03:06:55 pm
content: Quote from: 0db on July 18, 2020, 05:07:15 pmDoesn't look like anyone here really uses Chisel. If you're interested in it, you should probably download the tools, learn how to use them, then implement a few FSMs in Chisel, get them translated to Verilog by the tools and see for yourself. As with many code generation tools, I would expect somewhat difficult to read output, and possibly a lot of separate processes instead of just one or two. But really, you should try it.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 21, 2020, 03:16:26 pm
content: Quote from: NorthGuy on July 20, 2020, 03:34:17 pmYes, it's very likely where that originally comes from, and it's a pretty common approach in education. It's much easier to get students to understand the theory. A single, or more than 2 process-approach would probably look pretty confusing to most people learning FSMs, at least if you want to teach them the theory, and not just a bunch of recipes.Quote from: NorthGuy on July 20, 2020, 03:34:17 pmYeah that's my view as well. Of course that depends on how exactly you implement your FSMs. But if you use a two-process approach, and you need to modify both processes (which is often the case) if you later add a state, or modify one, then that's two places to maintain instead of just one, and thus a potential aggravated risk of introducing bugs. OTOH, of course if your FSM becomes very large, splitting it in several parts will make it easier to maintain too - but then, the best way is not necessarily to use the "textbook" two-process way.As someone already said (I think), if you have several clocked processes on the same clock, you can always combine all of them in a single process - that will do the exact same. Likewise, you can split a big clocked process into several ones. It's all in readability and how you structure your code.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 26, 2020, 04:21:25 pm
content: Quote from: rstofer on July 20, 2020, 05:52:41 pmMy copy of this book arrived and I spent the day yesterday reading it. It’s a very thorough introduction to FSMs and covers them in lots of detail. Recommend.One caveat, however... In his SystemVerilog examples he uses non-blocking assignments exclusively, even in purely combinational always_comb blocks. There’s not a blocking assignment to be seen anywhere. This is not standard practice, which is to use non-blocking assignments in sequential always blocks, blocking assignments in combinational always blocks, and not to mix the two. At the very least, his SystemVerilog is going to have synthesis/simulation mismatches.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 26, 2020, 04:26:56 pm
content: Quote from: Sal Ammoniac on July 26, 2020, 04:21:25 pmThat doesn't look too good.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: July 26, 2020, 10:13:20 pm
content: Quote from: SiliconWizard on July 26, 2020, 04:26:56 pmNo, it doesn’t. Pedroni is known for his VHDL books, so perhaps he isn’t familiar enough with SystemVerilog to understand the implications, or perhaps he had a grad student do the translation.On the plus side, this book is published by MIT Press, so it’s tightly edited and I found no typos or misspellings. This is in extreme contrast to Stu Sutherland’s SystemVerilog book, which is self-published, and has hundreds of typos scattered throughout the book, sometimes several on a page.