Subject: Re: Proposal to Delete the new SystemVerilog FSM syntax
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Thu Nov 29 2001 - 17:13:17 PST
Thanks, Stefen for the notes.
At 04:31 PM 11/29/01 -0800, you wrote:
>At 03:13 PM 11/29/2001 -0800, Clifford E. Cummings wrote:
>>Attached is a pdf document with proposals to scrap the new state machine
>>syntax that has been proposed for the SystemVerilog language.
>
>Cliff,
>
>Thanks for spending the time to try using the new syntax
>with some existing problems... I must agree that the new
>transition statement seems to lack when trying to do
>asynchronous resets and one-hot.
>
>Some comments on your notes:
>
>2) "I believe there is a missing semi-colon in the third transition
>statement:"
>According to the bnf (d3 p87):
><statement> ::=
>...
>| <transition_to_state> <statement_or_null>
>
>Looks to me like it's treated the same as delay or
>event control that is allowed to have a statement
>immediately following.
Thanks for pointing this out. Was this described prior to its use in the
example on page 32?
I believe ->> is treated like a nonblocking assignment, so I think this
statement does the following?:
S <= @(posedge clk) S0 if (serial) found_101 =1;
Looks like a mixture of blocking and nonblocking assignments in the same
statement. Is the "if (serial)" test performed immediately or on the
posedge clk? And is the blocking assignment performed immediately or before
or after the assignment of S <= S0 after a posedge clk. Pretty strange
scheduling and probably pretty confusing code for new students to learn.
Heck, its strange to me and I think I know something about nonblocking
assignments!
>1) "Upon closer examination, I am confused by the always_comb statement."
>It looks like you're talking about FSM1. This is the
>same as we have been doing with two always blocks: the
>"state" declaration includes the "@(posedge clk)" to
>create the sequential logic, and the always_comb
>creates the combinational next-state logic. The problem
>is that we really need to be able to handle asynchronous
>reset here in order to truly get the two always block
>equivalent...
Maybe I see a little better now, but ...
The problem is that states transition on a clock edge, the reset is
synchronous to the posedge clk, but the reset assignment shows up in the
middle of the always_comb block (synchronous assignment in an always_comb
block). Does reset going high trigger the always_comb block? Is the
assignment treated the same as?:
if (reset) S <= @(posedge clk) S0;
If so, is every change on the serial input going to re-trigger the
always_comb block, test reset and schedule another S <= @(posedge clk) S0;
assignment? Scheduling numerous future nonblocking assignments would
degrade simulator performance. Like I said, this is going to be confusing,
the scheduling of future nonblocking events on a clock edge inside of an
always_comb block. At least now I see how this might at least be
functionally correct.
Also true that the coding style works with synchronous reset but not
asynchronous reset. Now engineers have to learn completely difference
coding styles for synchronous versus asynchronous reset state machines.
This coding style does not appear to work with synchronous resets and
onehot FSMs. Another coding style to learn.
>Regards,
> Stefen
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 Nov 29 2001 - 17:14:38 PST