Subject: RE: Suggestion for "implicit variables"
From: David Smith (david_smith@avanticorp.com)
Date: Tue Aug 28 2001 - 16:56:50 PDT
True. (small type in the definition of mc1 where I believe you mean wire x instead of wire a, the c[d] is indexing a real scalar with an integer index (seems illegal), real being compared with a reg - defined???, etc...).
Do you see a problem with this?
Clearly the meaning is difficult to understand without having the context of the definitions of the leafs (or at least the location where you do the actual type declaration). Type checking cannot be done until context is known. etc..
I can forsee that there will be a camp of users that will NOT want to use this. I can also forsee some design tools allowing it when coming from netlisting but not supporting it when defining in text. Possibly providing support for elaborating as required to show context (if required by users).
The problem is that there are two different use models being discussed. One is a text driven user interface where declaration and definition are integral. The second is a text driven or graphics interface where connection is being made and type of connection is NOT integral to the design. This is clearly indicated in the Verilog-AMS approach where analog "signals" can be connected to digital nets directly. The conversion is handled automatically in the language. Is this a good thing? There are likewise two camps on this. The first is the strong type camp that says everything must be declared and compatible. The second is the weak type camp that says only some things need declared (type can be discovered) and compatibility can be forced by implicit casting.
I am suggesting that the investigation of supporting both models has value. It is up to the user (and tool developer) which to use and when.
Regards
David
-----Original Message-----
From: Michael McNamara [mailto:mac@verisity.com]
Sent: Tuesday, August 28, 2001 4:24 PM
To: David Smith
Cc: Verilog++ Committee (E-mail)
Subject: RE: Suggestion for "implicit variables"
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:58:32 PDT