Subject: Re: Updated Implicit Ports Proposal
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Fri Apr 12 2002 - 14:38:01 PDT
At 01:32 PM 4/12/02 -0700, Kevin Cameron x3251 wrote:
> > From owner-vlog-pp@eda.org Fri Apr 12 11:57:40 2002
> >
> > At 09:39 AM 4/12/02 -0700, Kevin Cameron x3251 wrote:
> >
> > > > From owner-vlog-pp@eda.org Fri Apr 12 05:51:54 2002
> > > >
> > > > Hi Kevin,
> > > >
> > > > Please explain what you mean by "a mechanism for blocking inappropriate
> > > > connection (e.g. 'local' preceding non-exportable signal delarations)".
> > > >
> > > > Unless I'm misunderstanding you, I believe the way to block
> inappropriate
> > > > connection is simply not to put the signal in the port list. I seem to
> > > > recall a previous email from you about "local", but I can't find it.
> > > >
> > > > Thanks,
> > > > -Tom
> > >
> > >There isn't a way of saying that a port connection requested by the
> > >child is invalid e.g. if "reg foo" in the parent is not supposed to
> > >be connected out of the parent (by user intention), but the child has
> > >the port "input foo" the connection will be made (legally by .*
> > >semantics). My suggestion was that declaring "foo" as "local reg foo"
> > >would block that (and any other cross-module reference).
> >
> > Or use .* except for the port where you do not want a connection and then
> > use a named port connection for that port to show that .foo is
> connected to
> > something other than reg foo.
>
>Assumes you know the child view.
I must still be missing the problem. Perhaps a few well-thought-out
examples would help (I spent days putting together FSM examples to prove a
few points, perhaps you could put together examples to help clarify your
points).
From my perspective as a designer, I have to know the child view before
using it (or I could instantiate the child view with no ports as a
place-holder). I really do not understand this point.
> > This discussion came up with respect to debugging. We asked Intel, whose
> > IHDL tool basically does .*, if they had seen debugging problems due to
> > like-named ports and signals incorrectly connected. They said no.
>
>Not a good argument.
Not true. At least I based the argument on experiences of engineers who
have successfully used this methodology for years as opposed to a
hypothetical worst case scenario. I claim the sky is not falling. Intel's
experience seems to back up the claim.
>Just 'cause it hasn't happened, doesn't mean it won't.
Agreed, but even though I recognized the problem and thought it was a
non-issue, other committee members thought it might be an issue so I at
least took the time to ask a company that has been using this methodology
for years. Their report confirmed that this was not a big issue. I believe
it will be rare that a signal name matches the name of a port that is not
connected to the signal, and in those rare cases where it does happen, and
those even rarer cases where I forget that a signal name exists that
matches an invalid port, I anticipate that it will be easy to debug using a
waveform viewer and RTL source code listings.
> > Now that I better understand your request, I'm afraid I oppose the
> required
> > local declarations. Maybe you can make a better case for them in
> version 3.1?
> >
> > >It's also an issue with modular compilation, since by default
> > >everything in Verilog is a global variable it's hard to optimize
> > >locally.
> > >
> > >Ideally I'd like it the other way round: that nothing is global unless
> > >it is a port or declared as "exported" - but that would be less backward
> > >compatible.
> > >
> > > > From: "Adam Krolnik" <krolnik@lsil.com>
> > > >
> > >...
> > > > >2. I'm not that keen on .* without module/interface prototyping
> > > > > and a mechanism for blocking inappropriate connections.
> >
> > Again, based on Intel's feedback, I think an explicit mechanism to block
> > inappropriate connections is not warranted.
>
>You can offer alternative syntax/keywords if you want, but I'll be voting
>"no" until there is a mechanism. The implementation cost is trivial, and
>you don't have to use it if you don't want to.
Acknowledged (you will be voting "no"). Again, I don't think I grasp the
entire problem that you are trying to describe. If I don't have to use it,
then why do I need to add this capability to version 3? The proposal does
not inhibit this addition at a later date, does it? If so, I need to
understand the problem better. Full examples of what you want to do would help.
>NB: a lot of Verilog is created by software and is difficult to fix if
>you run into these kind of problems. It's easier if you can construct
>it without the ambiguity.
Again, I do not see the problem yet.
> > > > Could you elaborate on the first reservation, 'module/interface
> > > > prototyping'? I don't quite understand what you mean.
> > >
> > >.* is a connection that is made upward rather than downward so
> > >(as with the 'local' issue) you can't tell without seeing the child
> > >module what is actually being connected. If .* is only allowed when
> > >a prototype declaration is present for the child, then you can tell
> > >what connections are being made and that lets you do modular compile.
> > >Enforcing "declare before use" works too.
> >
> > This reminds me of my VHDL synthesis days (the dark ages ;-) when I had to
> > make a ba-zillion component declarations before I could instantiate
> > entities (modules). This was near the top of my "VHDL_yuck" file.
>
>I'm not particularly keen on VHDL, but I do do a lot of C/C++ with which
>prototyping is a fact of life. The extra effort involved in prototyping
>is easily won back in the shorter compile and link times.
Shorter compile and link times are only a benefit if they do not cost
longer learning curves and coding times. I still do not see why your
proposal should be so important to me.
> > >These proposals are mostly to do with making it easier to build an
> > >efficient SystemVerilog parser/compiler/simulator system, i.e.
> > >they may not make it easier to use (from a designers perspective)
> > >but they make it easier to implement tools - which should help
> > >speed the adoption of SystemVerilog.
> >
> > If I remember correctly, ModelSim does a great job with modular
> > compilation. If the model is missing, the compiler waits until all modules
> > are called during simulation and then discovers the interconnect
> > incompatibilities. I know you want the capability to tell the tool that
> the
> > models are right before getting to the run-phase, but I have done fine
> with
> > ModelSim's current use-model. ModelSim also had the first really clean
> > method of combining Verilog and VHDL models in the same simulator (none of
> > the (* foreign model VHDL-architecture ...crap... *) that Cadence
> > simulators used to require).
>
>My point exactly - you have to wait until the simulator gathers everything
>together before you know you have a problem. The bigger the design, the
>longer you wait.
Again, coding ease versus compile time. If I can cut 5 minutes of coding
for every one minute of added compile time, it is probably a win for me.
Usually te disparity is much greater.
>There is no standard methodology for combining VHDL & Verilog, so while
>it might work well in ModelSim, it still isn't portable - and we don't
>use ModelSim here anyway.
This could be standardized (but not by us). Standards are often based on
successful tool implementations.
> > I am proposing enhancements that will make it much easier for Verilog
> users
> > to instantiate designs. This will speed adoption (and demand) of
> > SystemVerilog by end-users. The implicit port connections are a one-time
> > compile issue. After the entire design is compiled, the simulation should
> > be just as efficient as before. Tools are supposed to make the end-users
> > job easier, not the other way around.
>
>What tools are you building yourself?
Mostly FSM generation scripts and Perl scripts to build or manipulate
Verilog code.
>If I'm objecting now, I'm sure there will be a bunch more people objecting
>when these proposals reach the IEEE.
In my eight years on the Verilog Standards Group, the only other request
that I can think of that resembles your request was for an "extern module,"
requested by Eli Sternheim. On the other hand, the complaints I have heard
about verbose module instantiations rises to the level of "wailing and
gnashing of teeth!"
Every proposal needs a champion. Sounds like "you da-man" but we need
better examples to show us why this will make Verilog-coding life so much
better.
> > IMO - forcing the end-user to identify and label the different compile
> > blocks to facilitate tool-development for modular compilation is not
> > progress. End-users have already put into place their own methodologies to
> > do modular design compilation and incremental compile using
> capabilities of
> > existing tools. I have never felt that I was lacking this capability
> > whenever I have done Verilog design.
>
>Methodologies that exist outside the standard do not help people who are
>trying to build standard compliant tools. NSC and Intel do not have the
>same tools and methodologies.
However, as I visit numerous companies, I am amazed at how many of the
methodologies ARE the same, without being standardized.
> > Kev, I respect your opinion and I know I do not have your vote (you
> already
> > voted "no" to these proposals last week), but with my current
> understanding
> > of your proposals, I find myself in opposition to your proposed
> changes. Sorry.
> >
> > >Kev.
> >
> > With apologies - Cliff
>
>That's OK, just need to raise the issues so that everyone knows the downside
>as well as the upside :-)
Agreed. Take another stab at showing me why I should care about all of
this. I'm really not stubborn (just dumb and slow to catch on!)
>Kev.
Regards - Cliff
//*****************************************************************//
// Cliff Cummings Phone: 503-641-8446 //
// Sunburst Design, Inc. FAX: 503-641-8486 //
// 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
// PMB 501 Web: www.sunburst-design.com //
// Beaverton, OR 97005 //
// //
// Expert Verilog, Synthesis and Verification Training //
//*****************************************************************//
This archive was generated by hypermail 2b28 : Fri Apr 12 2002 - 14:39:47 PDT