Hi,
A colleague and I are having a friendly debate on coding state machines in Verilog, targeting synthesis for FPGAs. Comments are very appreciated. I am NOT trying to start a holy war here regarding syntax style (one process vs. two process, etc).
Crux of the matter: Do you need to define values for outputs of your state machine in EVERY state, or do you only need to define values for outputs in states where you want the output to update/change?
Skip to the chase: At end of message is a Verilog state machine that does NOT define outputs in all states. Is this acceptable Verilog or unacceptable (targeting FPGA)? If not, how would you re-write it? If yes, what are the implications? When you write a SM in Verilog can you "abbreviate" your output logic and let the synthesizer infer storage registers for flags assuming you don't define output condition for all states?
For the code below, the synthesizer (Altera Quartus II v7.1) produces DFF with MUXes in front ; no latches synthesized. The register is fed back its value when NOT in the states where value is updated. This is gleaned from using RTL Viewer in Quartus II. I am curious what ISE
10x would do with this Verilog too...
Colleague: Verilog/RTL is supposed to provide a reasonable abstraction, so if you have a state machine where you are updating a flag (i.e. set the bit/flag in one state, clear it in some other), you only need to define the output in those states where the bit will be set or cleared. The synthesizer will then produce a register and only update the value(register) in the correct state. Coding values of ALL outputs in ALL states would be too tedious and negates advantage of RTL.
My perspective is : You must define output in every state otherwise the synthesizer will produce a latch, or some other kind of unwanted feedback vs. decoding the output based off state registers (and possibly any other asynchronous inputs). When I wrote VHDL I would always define output of SM (mealy or moore) and it would result in unpleasant to read RTL but synthesized to what I want. FWIW, I prefer to combine output statements and next-state logic in one process since I can follow the logic more easily; if I want a set/clear type flag then I define SET_FLAG and CLEAR_FLAG signals and they are driven in every state; a clocked process is used to check SET and CLEAR to synchronously toggle output (flag).
cpu_lw_*, ackb are all outputs and outputs are not always defined in all states (hence the debate).
-----------------------------------------------------------------------------------------------------------------------------------------------
//State Machine always @ (posedge CLK or negedge negreset) begin if(!negreset) begin ackb