Subject: PROPOSAL: Remove the SystemVerilog State Machine Section
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Thu Mar 28 2002 - 15:31:14 PST
>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 : Thu Mar 28 2002 - 15:32:23 PST