[sv-bc] RE: SV-EC Proposal: Implicit Universal Data Type - Cliff Cummings to champion the proposal


Subject: [sv-bc] RE: SV-EC Proposal: Implicit Universal Data Type - Cliff Cummings to champion the proposal
From: Michael McNamara (mac@verisity.com)
Date: Mon Feb 03 2003 - 11:03:51 PST


> My proposal is to allow wires, declared or implicit, to allow EITHER
> procedural assignments OR continuous assignments within a module and that
> the behavior of the identifier is consistent with either wires or regs,
> depending on how they are used in the module. Advantages:
>
> (1) I don't add any new keywords
> (2) I don't have to change the declaration when I change from
> procedural to continuous assignments or vice versa - wire can
> now be used as a generic, sized variable
> (3) Wire is already the default type
> (4) I get the size that I need (which is really all I care about)
> (5) Resolved data type within the module if I make multiple-driver
> assignments to the identifier
> (6) Syntax error if I try to mix procedural and driver assignments to
> the same variable
> (7) Does not break any existing designs
>
> Sell me rope and I will help sell your rope to the users (this should be an
> easy sell).

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; and the user
would have to write:

module a(inout [31:0]j,k);
  thing [31:0] t;
  assign t = j+k;
  thing [31:0] g;
  assign t = g;
  initial begin
     g= 0; #1 g = 31'bz;
  end
endmodule

which will be really hard to explain to a user:

"Well, yes, Grasshopper, you a correct that 't' and 'g' are both 32
bit things, but becuase there is an continuous assignement elsewhere
in the design to the thing t, you can't make a procedural assignement
to it in the same module. Instead you can get what you want by making
a procedural assignment to another thing, which is the same size,
which we will call 'g', and then we assign g to t, and everything
works as you desired. Another way you could get what you want is by
passing 't' to another module, which can not see this continuous
assign, and make a procedural assigment there."

In my humble opinion, the current requirements are much more logical:
procedural assignemnts can ONLY be made to registers. Registers hold
a value until it is changed.

Wires ONLY reflect the value of their drivers. If you want to drive a
value onto a wire, write the value to a register that is driving the
wire.

-mac



This archive was generated by hypermail 2b28 : Mon Feb 03 2003 - 11:05:03 PST