Subject: Re: NEW FSM Syntax Proposals and Examples -20020325
From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Tue Mar 26 2002 - 11:25:12 PST
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.
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.
> >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.
>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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland-hdl.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland-hdl.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Tue Mar 26 2002 - 11:21:54 PST