Subject: [sv-bc] Re: Proposal: Implicit Universal Data Type - Cliff Cummings to champion the proposal
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Fri Feb 07 2003 - 16:42:38 PST
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.
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).
>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.
>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.
Regards - Cliff
>At 03:57 PM 2/3/2003 -0800, Clifford E. Cummings wrote:
>>>I have been quietly following this debate over the years.
>>>
>>>I am curious why you want #6. All along I thought you and Stefen and
>>>Adam wanted this magic type polymorphisim so that adding a procedural
>>>writer to a wire would automagically create the shadow register and
>>>assignment. Hence if the original code looked like:
>>>
>>>module a(inout [31:0]j,k);
>>> thing [31:0] t;
>>> assign t = j+k;
>>>endmodule
>>>
>>>And I changed it to:
>>>
>>>module a(inout [31:0]j,k);
>>> thing [31:0] t;
>>> assign t = j+k;
>>> initial begin
>>> t = 0; #1 t = 31'bz;
>>> end
>>>endmodule
>>>
>>>the compiler would automagically act as if I had instead written the
>>>1364-2001 equivalent code:
>>>
>>>module a(inout [31:0]j,k);
>>> wire [31:0] t;
>>> assign t = j+k;
>>>
>>> reg _t_r;
>>> assign t = _t_r;
>>> initial begin
>>> _t_r = 0; #1 _t_r = 31'bz;
>>> end
>>>endmodule
>>>
>>>Given your requirement #6, the above would be an error; ...
>>
>>I can't speak for Adam and Stefen, but I have never wanted this behavior.
>>Explanation below.
----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, Synthesis and Verification Training
This archive was generated by hypermail 2b28 : Fri Feb 07 2003 - 16:41:58 PST