Subject: Re: Draft 1.9 // synthesis encoding vs state_machine
From: VhdlCohen@aol.com
Date: Thu Jan 31 2002 - 10:39:01 PST
Bhasker,
I like your comments, with the exception of the following statement:
"FSM extraction is the process of extracting a state transition table
with tuples of the form "current_state next_state actions" from an RTL
model."
1. SOme users write FSM with the next_state/current_state all in one process
instead of two (one for the next state, and one for the current state
register).
2. Looked up "tuple" in Collegiat dictionary on Internet:
Main Entry: -tuˇple
Pronunciation: "t&-p&l, "tü-
Function: noun combining form
Etymology: quintuple, sextuple
: set of (so many) elements -- usually used of sets with ordered elements <
the ordered 2-tuple (a, b)>
Word is confusing to me, perhaps becuase it is rarely used (at least by me).
3. Am not sure if this is the right terminology. Perhaps it is.
4. How about:
"FSM extraction is the process of extracting a state transition table
from an RTL model where then hardware advances from state to state at a
clock edge."
Improvements/comments welcomed.
Ben
In a message dated 1/31/02 10:21:46 AM Pacific Standard Time,
jbhasker@cadence.com writes:
> These two attributes relate to FSM extraction. So before we introduce these
> two attributes, we need to
> define what FSM extraction is. So here is what I propose:
>
> ----------------------
> FSM extraction is the process of extracting a state transition table
> with tuples of the form "current_state next_state actions" from an RTL
> model. In such a case, it may be necessary to guide the synthesis tool in
> identifying the state register explicitly and to provide a mechanism to
> override the default encodings if necessary.
>
> If a synthesis tool supports FSM extraction, then the following attribute
> shall also be supported
> ( i dont see the need for two attributes: one seems to be sufficient):
>
> (* synthesis, fsm_state=<encoding_scheme> *) -- applies to a reg.
>
> The attribute when applied to a reg identifies the reg as the state vector.
>
> The encoding_scheme is optional. If no encoding is specified, the default
> encoding as specified in
> the model is used. The value of encoding_scheme is not defined by this
> standard.
>
> Note: Use of encoding scheme may cause simulation mismatches.
>
> Examples:
>
> (* synthesis, fsm_state *) reg [4:0] next_state; // Default encoding is
> used and "next_state" is the state vector.
> (* synthesis, fsm_state="onehot" *) reg [7:0] rst_state; // "onehot"
> encoding is used and "rst_state" is the state vector.
>
> -----------------------
>
> Comments?
>
>
----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
<A HREF="http://www.vhdlcohen.com/">http://www.vhdlcohen.com/> vhdlcohen@aol.com
Author of following textbooks:
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Thu Jan 31 2002 - 10:51:07 PST