4
\$\begingroup\$

State machines are a pattern that is used very often in writing synchronous designs. They serve as the controllers in the design. So, is there a standard way to verify them if they are written using VHDL or Verilog/SystemVerilog? Or is it better to use some GUI to draw them and then generate code from the GUI instead?

By standard way I mean a pattern of code used to verify them. There are always different ways to "skin the cat" but perhaps there is a method that is very popular.

The thing is that state machines can be quite big and one would have to write code to verify each branch in the state machine which leads to a lot of code in the testbench.

Edit: I am only taking about verification of the fsm itself on its own, to verify that it matches the fsm state diagram and no errors in rtl coding exist.

\$\endgroup\$
  • 3
    \$\begingroup\$ I'm curious to see what others say about this. I've written a lot of state machines, but no, I don't have a standard verification process. For me, writing HDL to implement a given state machine design is not really the hard part -- the hard part is making sure that the design of the state machine itself has the behavior that the application requires under all possible input combinations. \$\endgroup\$ – Dave Tweed Dec 9 '16 at 0:26
  • 1
    \$\begingroup\$ I have thought that if a specific GUI tool exists for this and we use it, we can take it for granted that the code is correct as long as the state machine diagram is correct. Like you pointed out, writing all that testbench code to verify all possible routes that the state machine must take, this is annoying even for simple state machines. The main problem is if I realize that the state machine needs to be changed and then the code has to be rewritten or changed. It is tedious. \$\endgroup\$ – quantum231 Dec 9 '16 at 0:53
  • \$\begingroup\$ Now basically, some time ago I did a course in Comprehensive VHDL from Doulos in UK. It was a fantastic course. In it they also taught how to write state machine in VHDL, the idea was to seperate the synchronous processes that assigns next state to current state from the asynchronous (not clock) process that generates value for the next state from the current state and current inputs. That was a very interesting as it gets rid of many pitfalls in state machine design. However, while they covered state machine design exclusively, this is not so for state machine verification. \$\endgroup\$ – quantum231 Dec 9 '16 at 8:44
  • \$\begingroup\$ Strange, no response for all these days. \$\endgroup\$ – quantum231 Dec 11 '16 at 23:15
  • 1
    \$\begingroup\$ Stateflow by MathWorks is a GUI tool to code FSMs. \$\endgroup\$ – Shashank V M Sep 22 at 6:09
4
\$\begingroup\$

Verification is a huge part of the design process; in a complex design, it would not be unusual to spend as much time, or even more time on verification than you do on the actual design. That being the case, a question which is essentially 'how do you verify complex designs' is quite broad.

In overview, if the design copes with a large number of scenarios, as indicated by there being very many states in your state machine, a good starting point for the test suite would be to have separate tests that stimulate the design so as to replicate all theses scenarios. You can then use code coverage tools to see which state transitions have been covered, and add new tests until everything is being covered. You can manage different test cases using the configuration construct in VHDL

It might commonly be the case that there are scenarios that are variations on a theme, for example receiving a packet of some kind, but with different packet lengths, lengths that are out of bounds, etc. In these cases you can write tests that generate a number of random length packets; you would then need to make sure that all your edge cases are met, for example the minimum and maximum lengths, the minimum plus one, the maximum minus one, etc, and that your design does the correct thing in every case. You might also need to test combinations of inputs to the design, and again these combinations could be generated by a test case, as opposed to writing them out manually one by one.

There are a number of methodologies that attempt to help manage the process of generating stimulus and recording the results. I use OSVVM, which I learned about through a course a couple of years ago. I like it because it uses the same VHDL language that I am used to, along with a bit of TCL scripting, and does not require any 'extras' in order to work with my simulator. There are many alternatives, which I won't try to list here, but a quick Google search for 'fpga verification' brings up a lot of resources.

| improve this answer | |
\$\endgroup\$
  • 1
    \$\begingroup\$ I only meant testing the state machine on its own, that its behaviour matches the state fsm diagram \$\endgroup\$ – quantum231 Dec 12 '16 at 12:58
  • 1
    \$\begingroup\$ The best way to test it is as part of the system that it controls. If you test it in isolation, you risk not providing it with the same stimulus it gets in the real system. You need to create a test bench for the system as a whole anyway, so you may as well make one test bench that does it all. \$\endgroup\$ – scary_jeff Dec 12 '16 at 13:15
1
\$\begingroup\$

Depending on the CAD tools you use, you can either draw the FSM in a GUI and generate HDL code or generate the State transition diagram from the HDL code.

I am aware of 2 solutions for these 2 cases:

  1. StateFlow by MathWorks can generate the HDL code from a state machine diagram.
  2. ModelSim by Mentor Graphics has a built-in FSM viewer to view the state machine generated from the HDL.

I recommend 2 ways to debug and verify that you have coded FSMs correctly:

  1. You can visually inspect the state machine diagram and (optionally) debug it by stepping through the state machine and observing the transitions. This method works well for FSMs with fewer states. I believe most CAD tools would have this feature.
  2. You can write PSL or SystemVerilog assertions for each transition to verify that you have not made any typing or coding mistake.

Acronyms:

  1. GUI: Graphical User Interface
  2. PSL: Property Specification Language
| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.