Subject: Re: PROPOSAL: Remove the SystemVerilog State Machine Section
From: Anders Nordstrom (asic@sympatico.ca)
Date: Mon Apr 01 2002 - 07:48:54 PST
Hi Cliff,
Thanks for re-coding the FSMs in soo many ways, it really helps to be
able to compare them.
I don't agree that we should remove the State Machine section from the
standard.
What I like about the transition statement is that, that's how I think
when designing an FSM. I draw a bubble diagram and the main concern is,
what are the transitions between states. Using the transition
statement, it is clear to all tools that this is an FSM and you can have
as many as you want in a module without confusing the tools. For now,
it is useful to be able to specify the coding of the states but really,
I don't want to do that anyway. The only reason I do it is because I
know that if I code my FSM one-hot it synthesize well. This is a
synthesis tool limitation, not a language limitation.
I prefer the style in your example fsm2 and I have a few suggestions.
Remove the XX state and the state = XX; assignment. It shouldn't be
necessary to declare it. If a transition is missing in a state, then
state should be unknown without any special statement required.
Ideally I would like to get rid of the next variable as well. The
transition statement could be coded: transition (state), however I don't
know how to re-code: state <= next;
module fsm2 (output reg found_101,
input serial, clk, reset);
enum {S0, S1, S2, XX} state, next;
always @(posedge clk or posedge reset)
if (reset) state <= S0;
else state <= next;
always_comb begin
state = XX;
found_101 = 1'b0;
transition (state ->> next)
S0 : if (!serial) ->> S0;
else ->> S2;
S1 : begin
->> S0;
if (serial)
found_101 = 1'b1;
end
S2 : if (!serial) ->> S1;
else ->> S0;
endtransition
end
endmodule
Regards,
Anders
On Thursday, March 28, 2002, at 06:31 PM, Clifford E. Cummings wrote:
>
>> PROPOSAL: Remove the State Machine Section (section 9 in draft 4) from
>> the SystemVerilog draft standard.
>>
>> Please see accompanying email with FSM-required enumeration
>> enhancement proposal.
>>
>> At 11:25 AM 3/26/02 -0800, Stu wrote:
>>
>>> Thanks Cliff!
>>>
>>> Your findings, examples and comments go a long way in convincing me
>>> the revised FSM modeling constructs area at least usable and create
>>> human readable/maintainable code. I still have reservations,
>>> however, that "transition" really gives me any significant capability
>>> beyond the current modeling style of using 2 or 3 always blocks with
>>> case statements. The transition keyword and operators may save a few
>>> keystrokes, but don't seem to add any new capability. I'm not
>>> convinced the few keystrokes are worth convoluting Verilog with new
>>> keywords, operators, and yet another modeling style.
>>>
>>> My personal preference is to add enumerated types in SystemVerilog
>>> 3.0 and postpone adding transition to SystemVerilog 3.1. That gives
>>> time to really justify its value with realistic examples.
>>
>> I agree with Stu. Even after spending days-to-weeks working up
>> SystemVerilog style FSM designs, and even though I hate throwing away
>> all of that work, I do not see enough difference to justify adding the
>> transition statement in its current incarnation. We also have not
>> considered the implicit-goto-style examples that David Knapp and I
>> have put together (is David Knapp still out there?)
>>
>> The only cute advantage of transition statements is that we could
>> use "->> IDLE;" instead of "next = IDLE;" (not enough
>> delta-improvement to warrant the change in its current form).
>>
>> PROPOSAL: Remove the State Machine Section (section 9 in draft 4) from
>> the SystemVerilog draft standard.
>>
>> Enumerated types provide most of the improved functionality that most
>> users want in Verilog FSM design.
>>
>> I still like the idea of a transition statement, but not in its
>> current form. The way that transition is defined right now is that it
>> is basically a case staement that permits ->> transition assignments.
>> I also like the idea of both ->> (blocking) and ->>> (nonblocking)
>> transitions, but they are little more than syntactic sugar in their
>> current forms. Both transitions and transition operators could be much
>> more powerful and much more useful. See ideas below.
>>
>>> As I've been working on indexing the LRM, there is something that has
>>> come to my attention. SystemVerilog adds a huge amount to
>>> Verilog-2001 already. If we want the EDA community to adopt this new
>>> standard relatively quickly, we need to be careful not to add too
>>> much too quickly. I can almost hear some vendors saying the list of
>>> new features is so large that it can't be done. I would disagree, of
>>> course, but still, I think we need to careful not to overwhelm those
>>> who will be implementing SystemVerilog. One giant leap at a time is
>>> enough.
>>>
>>> SystemVerilog 3.0 could still reserve the transition keyword for
>>> possible future use. In fact, I think we should reserve any keywords
>>> in 3.0 that we think may be needed in SystemVerilog 3.1, such as for
>>> pointer declarations.
>>>
>>> I've cut out a couple of items from Cliff's e-mail, where I have
>>> comments or questions...
>>>
>>> At 06:38 PM 3/25/2002, Clifford E. Cummings wrote:
>>>> After doing the coding, I like the idea of just declaring enum (no
>>>> transition enum).
>>>> (c) To do multiple FSM designs in the same file using Verilog,
>>>> naming conventions would already have been used to avoid parameter
>>>> name collisions. I do not see the big advantage of separate
>>>> "transition enums" just to reuse a state name.
>>>
>>> I agree. It would only serve to make code more confusing and debug
>>> to read if two FSMs in the same module shared the same state names in
>>> different enumerated lists. In a waveform display or some other
>>> output tool, how would I know which "IDLE" I was looking at if there
>>> were multiple "IDLE" state names? Using just enum for state names
>>> provides the capabilities needed, and because of shared name space
>>> will "encourage" coding styles that are less error prone.
>>>
>>>
>>>> >The enum_onehot is a possible extension.
>>>>
>>>> This is still a glaring omission in all HDLs today and an
>>>> opportunity to really make a valuable contribution to HDL design
>>>> with a new SystemVerilog syntax. It should probably be postponed
>>>> until SystemVerilog 3.1 to make sure we get it right. Like I
>>>> mentioned before, this is not addressed efficiently even by VHDL.
>>>
>>> I also agree that this could be deferred to 3.1. The assertions
>>> group is identifying assertions for several types of state encodings
>>> (I think). Any special types of enumerations in SystemVerilog should
>>> match the assertion capability and naming conventions. I don't think
>>> there is enough time to accomplish this for SystemVerilog 3.0.
>>
>> See below for more details.
>>
>>>> >BTW indexing into a vector can already be done from an enumeration
>>>> e.g myvec[int'(myenum)].
>>>>
>>>> Interesting, but this still requires significant code modifications
>>>> to turn an FSM design into an efficient onehot FSM design.
>>>
>>> Did you have a proposal on this, Cliff? I think you made some
>>> suggestions last December. Is that still on the plate for
>>> SystemVerilog 3.0, or is it something you want to defer to 3.1? As a
>>> minimum, I would like to see SystemVerilog 3.0 allow bit/part selects
>>> of enumerated types. It leaves the door open for a variety of uses
>>> (and abuses?) of enumerated types.
>>
>> Although there is not time to do this now, I have been proposing
>> adding enum_onehot to the language where onehot enumerated types would
>> be treated differently by transition statements. This would make
>> transition statements more valuable and would make conversion from a
>> binary-encoded FSM to a onehot encoded FSM a trivial task. If, as Stu
>> claims, the assertions group is defining multiple assertions related
>> to state-encoding styles, then I agree that we should sync up to what
>> they are doing and create additional special types of enumerations,
>> such as : enum_onecold, enum_onehot0, etc. There is no parallel in
>> existing software languages (that I am aware of) but these
>> capabilities would add valuable abstraction to typical hardware design
>> tasks.
>>
>> // This enum describes which bit is hot, not the bit pattern
>> enum { IDLE=0, // 00001
>> READ=1, // 00010
>> WAIT=2, // 00100
>> DLY1=3, // 01000
>> DLY2=4} // 10000
>> state, next;
>>
>> always @* begin // Very efficient onehot FSM coding style
>> next = 0; // set all next bits to zero
>> case (1'b1)
>> state[IDLE]: begin
>> out1 = 1;
>> next[READ] = 1'b1; // set the hot bit to one
>> end
>> state[READ]: ...
>> ...
>> endcase
>> end
>>
>> //--- Versus proposal ---
>>
>> // enum_onehot describes which bit is hot, not the bit pattern
>> enum_onehot { IDLE=0, // 00001
>> READ=1, // 00010
>> WAIT=2, // 00100
>> DLY1=3, // 01000
>> DLY2=4} // 10000
>> state, next;
>>
>> always @* begin
>> transition (state ->> next)
>> IDLE: out1 = 1; // if the state[IDLE] bit is hot ...
>> ->> READ; // set all next bits to zero except
>> // set the READ bit to a one
>> READ: ...
>> ...
>> endcase
>> end
>>
>> I have also suggested making transition different from case by not
>> permitting an expression for the case item and removing the
>> requirement of adding begin-end from each case-item expression. This
>> would reduce unnecessary begin-end verbosity and make having the
>> transition statement worthwhile.
>>
>> case (state)
>> IDLE: begin
>> out1 = 1;
>> next = READ;
>> end
>> READ: ...
>> ...
>> endcase
>>
>> transition (state ->> next)
>> IDLE: out1 = 1;
>> ->> READ;
>> READ: ...
>> ...
>> endcase
>>
>> =====
>>
>> case (1'b1) // legal
>> a&b: begin // legal
>> out1 = 1;
>> out2 = a;
>> end
>> c&d: ... // legal
>> ...
>> endcase
>>
>> transition (1'b1) // illegal
>> a&b: begin // illegal
>> out1 = 1;
>> out2 = a;
>> end
>> c&d: ... // illegal
>> ...
>> endcase
>>
>>>> PROPOSAL: remove all discussion of hierarchical FSMs from the
>>>> SystemVerilog standard until at least version 3.1. We have not yet
>>>> established any value to using this capability.
>>>
>>> I agree!
>>>
>>> Stu
>>
>> Amended above to remove the entire section.
>>
>> Regards - Cliff
>
> //*****************************************************************//
> // Cliff Cummings Phone: 503-641-8446 //
> // Sunburst Design, Inc. FAX: 503-641-8486 //
> // 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
> // PMB 501 Web: www.sunburst-design.com //
> // Beaverton, OR 97005 //
> // //
> // Expert Verilog, Synthesis and Verification Training //
> //*****************************************************************//
>
This archive was generated by hypermail 2b28 : Mon Apr 01 2002 - 07:50:03 PST