Subject: Re: Proposal to Delete the new SystemVerilog FSM syntax
From: Stefen Boyd (stefen@boyd.com)
Date: Thu Nov 29 2001 - 22:14:58 PST
At 05:13 PM 11/29/2001 -0800, Clifford E. Cummings wrote:
>Thanks for pointing this out. Was this described prior to its use in the
>example on page 32?
Actually, even later in the document it isn't very clear
of the semantics. My understanding (or lack thereof) is
based on discussions rather than the text. It seems to
me that the explanation was that although the ->> operator
acts like a non-blocking assignment, when the state
variable has an event control, multiple value changes
between triggering the state update (ie "@(posedge clk)")
will overwrite the previous value.
>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.
It certainly looks that way.
>>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.
If it's really more like two always blocks, maybe it's not
quite as bad. But it seems that if we are going to keep this
construct, it really does need a good explanation of the
semantics.
>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.
I have to agree that a new construct needs to address
the different types of hardware created without requiring
a rewrite to switch styles.
Regards,
Stefen
--------------------
Stefen Boyd Boyd Technology, Inc.
stefen@BoydTechInc.com (408)739-BOYD
www.BoydTechInc.com (408)739-1402 (fax)
This archive was generated by hypermail 2b28 : Thu Nov 29 2001 - 22:54:08 PST