Subject: Re: Updated Implicit Ports Proposal
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Fri Apr 12 2002 - 13:32:55 PDT
> 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.
> 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. Just 'cause it hasn't happened, doesn't mean it won't.
> 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.
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.
> > >
> > > 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.
> >--
> >
> >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.
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.
> 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?
If I'm objecting now, I'm sure there will be a bunch more people objecting
when these proposals reach the IEEE.
> 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.
> 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 :-)
Kev.
This archive was generated by hypermail 2b28 : Fri Apr 12 2002 - 13:36:00 PDT