Subject: Re: Updated Implicit Ports Proposal
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Fri Apr 12 2002 - 16:03:41 PDT
> From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
[ I trimmed the text some ... ]
> At 01:32 PM 4/12/02 -0700, Kevin Cameron x3251 wrote:
> > > ...
> > >
> > > 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.
>
In a large design with multiple engineers and multiple architectures/views
for many modules, and re-use of parts from other designs, a single engineer's
chance of knowing exactly what .* will connect is likely diminish, and
assumptions made at one point in time may not stay true.
If designers never got it wrong we wouldn't need the assertion committee!
> > > 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.
It's a trade-off. You are taking an educated guess that it's not a problem
worth expending any effort on for the amount of risk involved.
I say I'd rather reduce/eliminate the risk anyway.
> >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.
Intel don't sell simulators. There's a bunch of joint C++/Verilog simulator
environments that have been developed in-house at NSC, the folks that use
them will probably swear that they are great and have no problems too :-)
...
> >
> >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.
>
I don't see how the learning curve changes much, most folk will have used
C/C++ before Verilog these days, so they would hardly be new concepts.
....
> >
> >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 the disparity is much greater.
Spend 5 minutes writing a perl script to generate your prototypes that you
can use in your Makefiles and you won't have to do much typing - it's a
methodology familiar to most C/C++ programmers. Maybe I'll provide the script :-)
> >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.
Why not Accellera? - it would probably be less effort to define the language
interoperation than to re-invent lots of VHDL constructs in Verilog.
[ Start another thread for that one :-) ]
> > > 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.
As I said above, generating prototypes and declaring things 'local' shouldn't
require much typing at all if perl is doing the work :-)
> >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!"
Good for Eli!
> 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.
You are probably familiar with the "..." syntax of C/C++ which makes things
like 'printf("%s %d",s,d)' work. It probably seemed like a good idea at the
time since most machines where simple Von Neumann stack-based machines and
you could just run a pointer up/down the call stack to get the data. RISC
machines like SPARC don't let you do that, so implementing "..." is a real
pain. ".*" may seems like a good idea now, but it may lead to nasty
implementation problems that we can't entirely predict.
I just want the additional syntax/semantics to support the alternative
"strict" methodology, using it could be optional.
.....
Kev.
This archive was generated by hypermail 2b28 : Fri Apr 12 2002 - 16:05:36 PDT