Subject: RE: Suggestion for "implicit variables"
From: Michael McNamara (mac@verisity.com)
Date: Tue Aug 28 2001 - 18:05:35 PDT
David Smith writes:
> 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?
The bit select of the real error I introduced on purpose, to
illustrate my point. It is completely impossible to tell from
examining the module top whether the always block is meaningful or
not. What you described as a typo of wire a versus x really isn't an
error, as because x is not otherwise defined, it would become a
single bit wire, correct?
And yes, if I replace ' if (a[b] ...' with something like 'if
(top.mc1.g.h.j.k.a[top.mc2.d.e.f.g.h.b]...' it is also impossible to
tell from looking at just the module whether the code is legal, or to
do separate compilation.
But just because the patient has a cold, this doesn't mean we should
go ahead and infect them with malaria as well! Let's make it better,
not worse.
> 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.
I actually like the 'medium' type balance that Verilog has today --
with some minor exceptions. Making the type system even weaker (like
ML or common lisp) than what Verilog has now yields, IMHO, little if
any benefits; and opens up many opportunities to create errors.
I submit that the schematic capture tool can, and SHOULD run down the
hierarchy when I am selecting to instantiate an 'mc1' and let me know
that the ports are a wire, 32 bit unsigned reg, and a 64 bit real.
Further when I try to connect one of these ports to a different
thing, the schematic capture tool should insert impedance matching
logic if required; and when I save my work as Verilog, it should do
all the bookkeeping, and write a perfect netlist with everything
nicely declared so that I am assured that later passes of simulators,
synthesis tools, formal verification tools, static verification
tools, coverage tools, waveform viewers, timing tools and other tools
I have not dreamed of as yet will parse the design as the schematic
tool intended.
You offer that perhaps we propose this facility just for when code
has been created by a schematic tool, and that we continue to require
human authors to completely define their code. To that I must
respectfully ask why are we shifting the burden from the single
schematic tool to each of these downstream tools that I outlined
above, which with this change must each do complete elaboration and
promulgation of types?
[Educate me: Is there a viable market for schematic capture tools
today? To be blunt, Isn't Escalade gone, and Innoveda in big
trouble?? ]
I am a firm believer of pushing verification as far as possible into
the early part of the design cycle, which at the logical conclusion
means having the tool that the users use to create the code do as
much checking as is possible. If the tool is a schematic drawing
tool, then it should check. If the tool is Emacs, then it should
check (visit http://www.verilog.com for code that will teach your
emacs all about verilog.. (shameless plug, I know))
>
> 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 - 18:06:09 PDT