State of Automation

April 07, 2014

The truth is, I have mixed feelings about automated tools for code generation

State machines are a great abstraction for many embedded hardware and software tasks. I’ve written about software state machines many times (for example, in 2011 and in 2012). In particular, that last link talked about a tool called SMC (and the discussion mentions similar tools QO and Ragel). I wanted to look to see if there were similar open-source tools for FPGA development as well.

The truth is, I have mixed feelings about automated tools for code generation. Xilinx used to ship StateCAD but stopped. There are products from Mentor and Mathworks that do similar things (HDL Designer and HDL Coder, for example). Sometimes I want to really see what the HDL is doing. However, l get tired of writing the same old state machine code a slightly different way each time.

The tool I found was Fizzim. It met all my requirements. It is Java-based (with a Perl backend) so it runs on my Linux machines. It outputs Verilog, which I prefer (although it can output VHDL).

The Java program is a pretty simple GUI for drawing state machines. The figure below shows a simple state machine for a pulse generator. The T input goes high and a pulse goes high for 6 clocks and then stays low for at least 10 clocks. After that, the T input can trigger another pulse at any time.

What makes the GUI interesting is that it uses a name value pair system so you can attach different options to the drawing. This makes it easy to add new features in the Perl backend without having to do much (or anything) to the GUI.

In the diagram, you can see the machine has five states: Idle (the default, indicated by the double circle), S1, S1delay, S2, and S2delay. There is an output Q. The two counters also show up as outputs, but they are suppressed (using attributes attached to them in the editor). I also set an attribute that tells the system to assume there is an implied loopback transition that applies if nothing else happens in a clock cycle.

The T on the arrow going between Idle and S1 means that transition occurs when T (the input) is true. You can use a complex expression there, though, like the other transitions that test the counters for a zero value.

The text in the circles describes what happens during that state. S1, for example, sets the Q output to 1 and loads ctr1 with 5. The next state keeps Q at 1 and decrements the counter. A transition arrow with no text is the default (1, from the table at the top of the chart) and will be taken if no others apply. In the case of S1 to S1delay, there is only one transition, so it is always taken.

The Fizzim tutorial is excellent and also explains a lot of the design choices the authors made as well as choices you can make. You can set up one hot encoding, gray code encoding, outputs that are stored instead of derived from the state variable, and different types of outputs. There is a way to insert arbitrary code into the output, and a way to pass constraints to do things like select your synthesizer’s case implementation. If you want to use Fizzim, you really should take the hour or two to read the tutorial.

The GUI is pretty simple, but it does allow multiple pages, stubs to keep the lines tidy, and some color options. I haven’t done anything really large with it, but it seems up to the task, although it isn’t as polished as drawing in, say, Visio or OpenOffice.

I wrote a small test bench for the pulse generator and ran it through simulation. You can open up the same session at EDA Playground. You should see a result like this:

The tool has a nice feature where it generates a text representation of the current state for simulation. However, EDA Playground doesn’t display ASCII text as strings, so it isn’t very useful there. But if you are using Modelsim or GTKWave, it is very handy.

Next time, I want to dig into the state machine that the code generated. You can see the output on EDA Playground or you can download the whole project in the online listings.