StateCAD 7.1i is broken?

Hi -

Every once in a while, someone on this group asks about FSM design tools, and invariably StateCAD is mentioned. Xilinx bought this graphical FSM entry tool a while back, and continues to offer it as part of ISE. I've never been terribly enthusiastic about the tool, mostly because coding an FSM in Verilog just isn't that hard.

But after years of hand-coding FSMs, then drawing FSM bubble diagrams with Visio, I decided to take another look at StateCAD, to see if I could eliminate the need to make two sets of revisions--Verilog and Visio--every time I modify an FSM. And after a couple of hours of fooling around with the latest incarnation of StateCAD, I found that I could produce an FSM with the features I wanted in a fairly straightforward way.

But there is one significant problem: the Verilog code emitted by StateCAD is wrong.

When I generate a one-hot FSM from a StateCAD drawing, the state register portion looks something like this:

always @(posedge clk_50 or posedge ga_reset) begin if ( ga_reset ) STATE1 = 0; else STATE1 = next_STATE1; end

always @(posedge clk_50 or posedge ga_reset) begin if ( ga_reset ) STATE2 = 0; else STATE2 = next_STATE2; end

always @(posedge clk_50 or posedge ga_reset) begin if ( ga_reset ) STATE3 = 0; else STATE3 = next_STATE3; end

...and so on. (Aside: The asynchronous reset is intentional and OK. There's also a synchronous reset that you can't see in this code fragment.)

Note that each state bit is updated in its own always block, using blocking assignments.

Synthesis-wise, no problem: any synthesis tool will recognize these constructs and produce the correct logic. But a simulation tool can evaluate these always blocks in any order, meaning there's no guarantee that the state FFs will be updated in a race-free fashion. This is exactly the kind of coding faux pas that every novice Verilog writer is instructed to avoid.

Xilinx Answer Record 16616 admits to the simulation problem. But it also says, "...Verilog State Machine code generated by StateCAD might not be optimal." That's putting it kindly. I'm not 100% sure that Xilinx realizes the tool is broken in any flow that includes functional simulation, which these days includes just about any flow for a non-trivial design. I guess I could tell them, but it looks like someone already did, almost two years ago.

I'm probably going to write a Python script to correct the emitted code. Anyone have a better solution? And you can assume that "Don't use StateCAD" is already at the top of the list of fixes being considered.

Thanks, Bob Perlman Cambrian Design Works

Reply to
Bob Perlman
Loading thread data ...

I agree. Consider simulation waveforms to check and visualize the state transitions.

That's fine, if you enjoy the exercise, but consider using a text file as the source document. The fewer tools in the design loop, the better.

Anyone have a better solution?

Consider using a single synchronous always block for the entire module like this:

formatting link

-- Mike Treseler

Reply to
Mike Treseler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.