Subject: RE: Suggestion for "implicit variables"
From: Michael McNamara (mac@verisity.com)
Date: Tue Aug 28 2001 - 16:24:13 PDT
David Smith writes:
> Greetings,
>
> Having thought a little more about handling of "implicit variable"
> declarations for use in connecting ports on modules I wanted to
> propose that a way to do this could be adding a new value to the
> 'default_nettype of "inherit". This would be in addition to the
> existing values and would NOT invalidate any of the existing uses. It
> would have the desired behavior that the type of the undeclared name
> connected to the port would be determined at elaboration time, remove
> the complexity of having a schematic system (or other design tool)
> having to check for the definitions within all connected elements (a
> partial elaboration) to determine the type of the connection, etc...
> Since hierarchical module definition is now supported within VerilogPP
> does it make sense to extend the use of the 'default_nettype to be
> definable in a module and restricted to the scope of the module. This
> would then allow for creation of hierarchical scoped module
> definitions with the type of connections without affecting any of the
> external definitions (again backward compatible with Verilog-2001 when
> not defined in a module definition). A value of 'default_nettype
> "previous" could also be added so that the previous value of nettype
> could be restored. This would then be used to bracket a set of module
> definitions in a "library" so that they do not affect other
> definitions (mixture of new and old types). Some thoughts for Peter
> Flake to think on while he is considering the mater from the last
> meeting. Regards, David
>
> David W. Smith
> Architect
>
Just to shed more heat on this, with the proposed change, the
following becomes legal:
`default_nettype inherit
module top;
mychild c1 (a,b,c,d,e,f);
always @(a) begin
if (c[d] > e) begin
$display($time,,f);
end
end
endmodule
...
module mychild(a,b,c,d,e,f);
mc1 c1(a,b,c); // substitute arbitrary many levels of further hierarchy
mc2 c2(d,e,f);
endmodule
...
module mc1(x,y,z);
wire a;
reg [31:0] y;
real z;
endmodule
...
module mc2(r,s,t);
integer r;
reg [31:0] s;
real t;
endmodule
This archive was generated by hypermail 2b28 : Tue Aug 28 2001 - 16:25:00 PDT