Hi Simon,
How can the conflicting views possibly both be right? - because they are. It really comes down to coding approach. Some like coding a design in a single large process with everything in it. Some like coding piece wise.
Lets assume you are coding piece wise where you code your statemachine and the datapath logic in one more more separate processes. Under these conditions, if you use a one process statemachine, then every output from it is asignal with a register on it. If you use these outputs to control datapath logic (that is in a separate process), such as a load enable, then that load enable has a flip-flop on it and potentially has an extra clock cycle of latency on it that it may not need (timing wise, you are connecting the output of one register to the load enable input of another). Of course you can code around this by writing separate logic outside of the statemachine to generate the load enable signal - but then you are writing a informal multiprocess statemachine that may end up being harder to debug (and read andreview). I suspect this is what Pong was thinking of a piece wise approach when he said there would be an extra register.
Another way is to code is lump all of the logic in an architecture into onelarge clocked process. Use variables for combinational logic values. In this case, the load enable signal, if broken out is a variable that is thenused later in the process to control the register.
What is better, one, two, or three? From a quality of result perspective, I expect all are similar. There was a contest that John Cooley ran - not the V vs. V one, but the statemachine one. The way I interpreted the results is that if you enabled all statemachine optimizations (now on by default - then on by settings), most statemachines coding styles are within 10% of each other - this included statemachines generated by the block diagram tools.
At the end of the day, the most important thing about your code is readability and reviewability. Either approach (statemachine or coding approach) can be made readable. To make reviews easier your group may wish to adopt a coding practice document that documents what it expects as the more similarthe code is to expectations, the easier it is to review.
Personally I like coding piece wise and use a two process statemachine. For me this forces a practice of code separability and locality, which makes it easy to see the hardware within the software. From a philosophical perspective, when I deliver code to a customer, I want them to be able to modify it when they make the next generation of the device without my help. Hence I consider seeing the hardware within the code and separability and locality important to readability.
I would bet someone coding carefully with a single large process can get the same degree of readability.
From a readability stand point, I like rising_edge. Potentially clk='1' and clk'event is more simulation efficient (faster in sim due to less checks), but I would hope that the simulators optimize these in a similar fashion - as readability is important.
If you like two process statemachines (like I do), here are a few tips:
1) Be careful with your sensitivity lists. If your synthesis vendor supports the VHDL-2008 keyword all in the sensitivity list use it, or if they don't submit a bug report against their tool. Using "all" removes what I would consider the number one issue with two process statemachines.
2) Be careful about latches on outputs. To do this, give all statemachine outputs a default value at the top of the next state process to the non-driving value (typically 0). This also means to make an output a 1 during a particular state, you must set it to a 1 (which increases readability).
When I code a one process statemachine, I follow this same rule. From a _reviewability_ standpoint, I hate when someone retains a value on an output from a previous state.
3) Be careful about latches on the state variable. To do this, assign the NextState signal to the State signal at the top of the next state process. This happens automatically with one process statemachines.
The alternative is to tediously make sure that the NextState signal receives a value in every branch of every state - typically by having every if statement end with an else branch.
Following these steps, results in little difference in length of code.
As a consultant and trainer, the religion around this issue is a non-starter. The coding styles I use must be consistent with the customer's coding guidelines. The code must be readable.
My personal opinion is that most hardware designers learn fastest thinking in smaller chunks and coding piece wise. Getting the hardware done and correct is the first job. My expectation is that as designers grow in experience that their code will think in bigger chunks and also become more efficient software. Some will make this transition faster than others - for some the design size and simulation speeds will demand it. However, as they progress, the code must remain readable and reviewable.
Best Regards,
Jim
SynthWorks