5

There are two popular ways of coding a state machine in VHDL: one process or two processes. There are rumors (and it is taught in some colleges) that two processes might result in better hardware. Does anybody have any hard evidence for this? My own preliminary tests show that there is no difference at all.

I'm looking for reproducible experiments: VHDL code for the two coding styles, and specifics on how to synthesize them (which tool, which parameters).

Please help me to either debunk or confirm the myth that two processes result in better synthesized hardware.

Philippe
  • 3,700
  • 1
  • 21
  • 34
  • I have always thought that the two process approach is for better understandability of the code, and for better simulator performance. – Schedler Oct 25 '11 at 13:36
  • 1
    @Schedler there are good reasons to assume that simulator performance is actually _worse_ if you use two processes. But to be sure, you'd need to run a small test! The "I have always been taught" argument is exactly what we're trying to avoid here. In the middle ages, people had always been taught that the earth was flat. – Philippe Oct 25 '11 at 21:22
  • I am not sure whether it makes any difference or not, but for better readability and "less code size" I always go for one process state machines. – vipin Oct 26 '11 at 01:36
  • @vpin: ...and for exactly the same reasons I go for the two process version. – Paul S Oct 26 '11 at 07:13
  • @Philippe: Good point - my designs have always been small, so performance has never been an issue. Therefore I also have no measured data on this point. – Schedler Oct 26 '11 at 12:02
  • My own Verilog experiments with Talus indicate there are situations where RTL syntax affects synthesis results. –  Oct 27 '11 at 04:56
  • @Adam12 Now we're gettings somewhere. Can you post a minimal example? In one of my own experiments, I thought I wrote the same thing with different syntax, but it turned out that it a subtle different meaning. – Philippe Oct 28 '11 at 07:52
  • @Philippe Posted below. I ended up using an FV tool in some of my experiments to check my many conversion errors. –  Oct 29 '11 at 18:56

3 Answers3

3

A lot of this kind of "knowledge" is based on the tools that were around 20 years ago. Things have moved on.

That's not to say that it's everything has been fixed in all cases, but you're doing the right thing by actually performing trials.

Other things which have been avoided in the past are:

  • Generics, because apparently they're unsynthesizable. Not true, and far better than
    pre-processing code, which is the normally what's being defended.
  • Records on ports. This did cause DC-shell problems for a long time. It would misconnect things. I don't know if this is solved.
  • Various styles of synchronous process, especially those using wait rather than the sensitivity list. This one is particularly crazy because if you read the VHDL spec it says the two are equivalent and should be implemented in the same way.
Paul S
  • 7,645
  • 2
  • 24
  • 36
  • 1
    "based on tools of 20 years ago" That was my feeling exactly. I have tested some stuff and it turns out to be equivalent for 1 or 2 processes. Unless somebody produces evidence, I think we will have to officially rebuke this "knowledge". – Philippe Oct 25 '11 at 21:25
2

Sorry, no reproducible experiment, but I'd be staggered if a synthesizer cared (at least these days - I have no hard evidence though)! Surely it just parses the VHDL down to a bunch of logic feeding a bunch of flipflops.

I don't even know if it used to be a problem with old-fashioned synthesizers or whether people just assumed it to be so!

Martin Thompson
  • 16,395
  • 1
  • 38
  • 56
  • 1
    "...whether people just assumed it to be so." In my first experiment, I got huge differences between 1 and 2 processes. Turned out that my two state machines were not equivalent -my error-! When people are not careful, experiences like this can fuel "rules of thumb" that are not based on reality. But we're engineers, not alchemists, so I'm trying to debunk some of the black magic that goes on in hardware design. – Philippe Oct 25 '11 at 21:30
0

The code below should demonstrate this for libraries that have clock gates. The simulation results will be the same and Formal Verification will prove both of these identical. However the first one will likely use less power and less area.

//Instances 1 clock gate
reg [7:0] value;
always @(posedge i_clk)
  if(enable)
    value <= new_value; 

//Instances 8 muxes
always @(posedge i_clk)
  if(enable)
    value <= new_value;
  else //Exhaustive so assignment always occurs
    value <= value;

The first example will use a single clock gate for the clock into all eight DFFs. The second example will use 8 muxes looping back the output from each DFF to it's input. Depending on the area and power ratio of clock gates to muxes, the differences can be significant. This was tested on Talus.

Of course the else clause in the second example is useless but the point of the experiment was to see how well the tool handled complex casez/x statements and shared enables across always blocks. For FSMs, I would lean towards syntax doesn't matter as long as the FSM is detected. I base this on how XST handles them and that state machine optimization is a very mature topic.

  • 1
    "will _likely_ use less power..." is not what I'm looking for. Did you actually run these code snippets through your synthesis tool? (Talus I suppose? Did you use a recent version?) I just tested on Altera Quartus, with identical results for both snippets. – Philippe Oct 31 '11 at 12:51
  • The question is specifically about VHDL. Note this snippet is Verilog instead. – Mast Jun 20 '15 at 09:26