Subject: RE: Suggestion for "implicit variables"
From: David Smith (david_smith@avanticorp.com)
Date: Wed Aug 29 2001 - 09:22:08 PDT
Hi Michael,
I do not have any real issues with the points you make. I too would prefer to minimize the use of "implicit typing". But, you have to remember I come from a VHDL background and do not find strong typing a problem.
A couple of points though.
On the issue of "isn't schematic capture dead". Schematic capture of designs is quite alive and well in the IC market. It is used for custom IC design and for high level system design (engineers still like drawings). Talk to Cadence about their schematic products such as Analog Artists, SPW, AMS Designer, Orcad products, etc... And this is just one of the EDA companies. Verilog is used in these environments and one of the major purposes for the Verilog++ effort is to extend Verilog up out of the RTL level to the system level (where Matlab, for example, is a major player and provides block diagrams - schematics by another name). So, there is quite a viable market for graphical front-ends for design. Not that there have not been fatalities and problems - but you can say the same for Verilog simulation companies that are no more as well :).
I think there is a legitimate tension between how the language is used. The question is what are we willing to support within the language so that it can be used in different forms. Clearly the Verilog community has not felt that implicit types are bad - as evidenced by existence of default_nettype to begin with. I would support the complete removal of this and all weak typing as well. I find the handling of implicitely declared wires connected to regs unexpected and would much prefer an explicit declaration and conversion. But, this would not be acceptable to the user base. My suggestion is to extend an existing mechanism in a logical fashion to support implicit typing of other types besides wire types. Yep, lots of problems. We already have them with the existing use. It does help a lot in the definition from schematic. Your suggestion of really tight integration between the schematic system and the language environment is not a bad one but I do not believe anyone does it to!
day. Of course, they do not do it in the simulator either so you can argue who should do it.
I am interested in Peter's thoughts when he surfaces again. He may have a completely different take as well.
Regards
David
-----Original Message-----
From: Michael McNamara [mailto:mac@verisity.com]
Sent: Tuesday, August 28, 2001 6:06 PM
To: Verilog++ Committee (E-mail)
Subject: RE: Suggestion for "implicit variables"
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 : Wed Aug 29 2001 - 09:53:23 PDT