Subject: RE: Suggestion for "implicit variables"
From: John Sanguinetti (jws@forteds.com)
Date: Tue Aug 28 2001 - 17:15:12 PDT
I think one of the biggest failings of Verilog is the need to see the
whole model in order to discover what the type of an identifier is.
This manifests itself in the difficulty of doing separate compilation
of modules. The more this can be reduced going forward, the better
off everyone will be. So the answer is yes, I do see a problem with
Mac's example.
John
At 4:56 PM -0700 8/28/01, David Smith wrote:
>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 - 17:15:48 PDT