Subject: Re: [sv-bc] Proposal to change interface ref-port default mode -or- documentation
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Tue Sep 02 2003 - 14:24:48 PDT
Hi, Peter -
At 06:24 PM 9/2/03 +0100, Peter Flake wrote:
>Hi, Cliff,
>
>The problem I have with your inout ports for variables is that they are
>not genuine inout ports. You wrote
>
>"A variable inout port would allow one continuous assignment (or
>procedural assignments on one side of the inout port? (Jay - can a
>SystemVerilog procedural assignment be made to an inout port per new
>flexible assignment capabilities?)
>A variable inout port would almost always be an error without a modport to
>change the default-inout to a direction. I suppose one could use the
>default inout port in an interface to a continuous assign on one side of
>the port and a procedural READ on the other side of the port.
>For all practical purposes, the default inout variable means that an
>engineer has to declare modports, or bypass the modport declarations with
>the "default ref;" declaration (essentially taking full responsibility for
>all the ref-port problems that are about to occur, as opposed to allowing
>them to occur by default)."
You are right that the ports are not genuine inout ports. The interface
ports are meant to be connections between logic blocks, and an inout port
is almost like a wire connection between blocks (if we had passed my
proposal to allow procedural assignments to a net, this would not be a
problem ... but I digress :-)
The bigger problem is, in real hardware, there is no such thing as a
ref-port - there is no logic equivalent. Again, per my estimates, consider
that 85-90% of all Verilog models are RTL models coded by hardware
engineers. Since a ref-port is not hardware, ref-ports are not going to
make much sense to most hardware engineers.
If interface ports were just non-directional wire ports, and if we could
make procedural assignments to wires (following my earlier proposed rules),
the ports would behave according to a hardware engineers understanding and
port direction would be a non-issue. It should be noted, even with my
proposed wire-ports, there could still exist the possibility of
successfully compiling a parent module with a sub-module that assigns to a
wire-port with a procedural assignment, and later successfully compile the
same parent module with another module that makes a continuous assignment
to the same port, and when the two submodules are combined, into the same
parent module, this would be a syntax error (but it would be a well
understood compile-time error).
>In Superlog and SV 3.0, inout ports for variables behaved like ref ports.
In Superlog, the behavior was ref-port behavior (and all of the hardware
design engineers on the Superlog Working Group objected to the behavior),
but I did not think "ref-ports" actually came into existence until SV 3.1.
I think in SV 3.1 we addressed this because I raised the issue that a logic
variable "driven" by the outputs of two sub-modules should be an error
(i.e. I thought the documentation was either incomplete or wrong).
>You thought this was too confusing, so ref ports were introduced in SV 3.1.
True. And I still think ref-ports are going to be generally confusing.
>Now you seem to be saying that a variable cannot be written from more than
>one place unless "default ref" is used, or modports.
True. Since I believe this behavior should be the exception and not the
default, I believe an engineer should intentionally shoot themselves in the
foot as opposed to this being the default behavior. All existing
non-modport Superlog and Intel models could add "default ref" and continue
to work as they do today.
>So maybe all we needed was a qualifier to the interface to provide a
>"default ref" feature, instead of ref ports!
"default ref" says that all non-modported signals are ref ports and again,
I don't think ref ports existed until SV 3.1.
I personally don't like ref-ports (maybe because I have not seen a good use
of ref ports in a real model), but I realize that other committee members
do like ref ports, so I proposed the "default ref" as a compromise.
>BTW surely the synthesis tool will catch any incorrect use?
Not true. Synopsys currently allows assignments to the same variable from
more than one clocked always block and WARNS about an unknown wired logic
type and then proceeds to build two flip-flops with outputs anded together.
In the pre-synthesis simulation, there is an assignment race condition
(just like the new ref-port race condition), but the post-synthesis logic
does not match either race-simulation.
The only interface guideline that I have heard so far from synthesis tool
vendors is that they will RECOMMEND that modports be used with interfaces
(modports will not be a requirement). If the RTL code only has one
procedural assignment to a ref-port and another module reads the ref-port
module, the inferred logic will be reasonable and correct. If the RTL code
has two procedural assignments from two different modules to a common
ref-port, the inferred logic will have all of the problems of the
two-flip-flop model above.
>Regards,
>
>Peter.
Regards - Cliff
----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, Synthesis and Verification Training
This archive was generated by hypermail 2b28 : Tue Sep 02 2003 - 14:27:50 PDT