Subject: Re: Updated Implicit Ports Proposal
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Fri Apr 12 2002 - 10:11:19 PDT
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.
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.
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.
> >
> > 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.
>--
>
>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).
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.
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.
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
//*****************************************************************//
// 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 - 11:52:55 PDT