Subject: [sv-bc] Re: [sv-ec] RE: SV-EC Proposal: Implicit Universal Data Type - Cliff Cummings to champion the proposal
From: Stefen Boyd (stefen@boyd.com)
Date: Fri Feb 07 2003 - 16:14:46 PST
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) 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!
Stefen
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.
--------------------
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:14:45 PST