Subject: Re: Updated Implicit Ports Proposal
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Fri Apr 12 2002 - 09:39:50 PDT
> 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).
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.
>
> 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.
--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.
Kev.
This archive was generated by hypermail 2b28 : Fri Apr 12 2002 - 09:41:58 PDT