Subject: [sv-bc] Re: Proposal: Implicit Universal Data Type - Cliff Cummings to champion the proposal
From: Stefen Boyd (stefen@boyd.com)
Date: Fri Feb 07 2003 - 16:54:29 PST
Cliff,
I'm not really passionate about removing the restriction, but
I could see how I would benefit from it (i.e. this will be
the last you hear from me on this thread ;).
Comments below...
At 04:42 PM 2/7/2003 -0800, Clifford E. Cummings wrote:
>Precedence: bulk
>
>Hi, Stefen -
>
>Comments inserted into your comments
>
>At 04:14 PM 2/7/03 -0800, Stefen Boyd wrote:
>>Cliff,
>>
>>Actually, the only reason for an error is to prevent weird
>>synthesis results... if it resulted in automagic shadow variables,
>>then it solves the testbench problem (a real need)
>
>Although it would insert automatic shadow registers into the testbench, it
>creates multiple always-active drivers, which is typically not what we
>want in the testbench. If you code the stimulus and assign a value to a
>shadow register and then turn it off by assigning HiZ to the same shadow
>register, yeah, this works.
And that would be the way I would use it...
>Most of the time when I use a shadow register in a testbench, I drive the
>shadow register through a tri-stating continuous assignment, with the
>testbench driver controlled by the inverse of the control signal that
>causes the DUT to drive the same bi-directional bus. Example:
>
>assign data = ce_n ? data_shadow_reg : 'bz;
>
>When ce_n is low, the DUT drives the data bus and my testbench drives HiZ.
>When ce_n is high, I drive the shadow register value onto the inout data bus.
>
>I believe an engineer has to understand how this works and therefore the
>automatic shadow-register insertion does not help and may even confuse the
>novice user (the design compiles but the data bus is always undefined).
They would debug the same as any other contention... check
drivers and see that they never turned off the drive from
the testbench.
>>and defines
>>the behavior in a way that would prevent synthesis tools from
>>doing something weird. Now you would get the two flops you would
>>expect without extra garbage logic. It would always behave the
>>same pre and post synthesis!
>
>True, but tying two flip-flop outputs together usually is wrong whether or
>not the pre- and post-synthesis simulations match. Better to leave things
>as screwed up as they are now to justify the guideline: do not make
>assignments to the same variable, from multiple procedural blocks.
Matching pre and post is a benefit because it means that
you would see drive fights turn to unknowns during RTL
sims. You wouldn't have to wait for synthesis to give
you weird results to figure out that you did something
stupid. The guideline is good, this way it would be obvious
and you wouldn't have to beat folks over the head with a
guideline... the tool would do that for you.
>>Stefen
>
>IMO - automatic insertion of the shadow register would be non-intuitive,
>confusing and cause as many problems as it solves. I don't see value in
>making this behavior automatic.
The only draw for me is that if you want to make the universal
type have a name of "wire", then I would want it to always
behave like a wire... multiple driving blocks means drive
fight. But, really, I don't care enough to waste any more
bandwidth on it.
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 : Fri Feb 07 2003 - 16:54:36 PST