Subject: [sv-bc] Ref ports - Documentation needs much clarification
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Aug 18 2003 - 14:21:23 PDT
Hi, All -
Based on our discussion of ref-ports in the SystemVerilog-BC meeting today,
I decided to do a better search for ref port references in the
SystemVerilog 3.1 document. Below are all the applicable passages. There
were other passages related to passing by reference to tasks and functions
that I don’t think are applicable.
I found nothing to suggest that implicit ref-ports assigned in two separate
modules with continuous assignments and connected at a higher level had
behavior any different that last-assignment-wins, same as if they had been
procedural assignments to variables within the modules. This is what I
mentioned in the meeting.
I personally find the interface ref-port explanations to be sparse and
lacking significant detail.
Although I find Matt's argument that ref-ports permit rapid prototyping
without requiring modport declarations to be significant, I am still
discouraged that we seem to defaulting to the ref-port exception case,
which will surely be a source of much confusion in the user community.
I also did not see a description of what would happen if a ref-port form
one module and a non-ref-port modport-defined port from another module are
connected at an upper module. Can a modport-ed input be connected to a
ref-ported variable (there is only one driver), and is a modpoert-ed output
connected to a ref-port variable and error? (one driver and a shared variable).
There is nothing that I could see that indicates that a continuous
assignment to a implied ref-port logic variable behaves any differently
than a ref-port logic variable assigned by a procedural assignment.
What am I missing? Interface training slides just keep getting more and
more complex!
If I go along with the ref-port default, can I count on all of you to
recommend my SystemVerilog training to everyone you meet? Because, nobody
is going to get this right just by reading the LRM!
Regards - Cliff
5.6 Nets, regs, and logic (page 42)
SystemVerilog variables cannot be connected to either side of an inout
port. SystemVerilog introduces the concept of shared variables across ports
with the ref port type. See Section 18.8 (port connections) for more
information about ports and port connection rules.
18.8 Port connection rules (page 200)
SystemVerilog extends Verilog port connections by making all variable data
types available to pass through ports. It does this by allowing both sides
of a port connection to have the same compatible data type, and by allowing
continuous assignments to variables. It also creates a new type of port
qualifier, ref, to allow shared variable behavior across a port by passing
a hierarchical reference.
18.8.1 Port connection rules for variables (page 201)
· A variable data type is not permitted on either side of an inout port.
· A ref port shall be connected to an equivalent variable data type.
References to the port variable shall be treated as hierarchal references
to the variable it is connected to in its instantiation. This kind of port
can not be left unconnected
Cliff-Note: Two typos in above bullet: (1) hierarchal should be
hierarchical, and (2) missing period at the end of the bulleted item.
19.2.2 Interface example using a named bundle (page 205)
The simplest form of a SystemVerilog interface is a bundled collection of
variables or nets. When an interface is used as a port, the variables and
nets in it are assumed to be ref and inout ports, respectively. The
following interface example shows the basic syntax for defining,
instantiating and connecting an interface. Usage of the SystemVerilog
interface capability can significantly reduce the amount of code required
to model port connections.
19.4 Modports (page 210)
Note that if no modport is specified in the module header or in the port
connection, then all the nets and variables in the interface are accessible
with direction inout or ref, as in the examples above.
Cliff-Note: There were also examples that included a "ref data" port in the
modports but beyond declaration, I don't think this port was actually used
in any of the examples.
----------------------------------------------------
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 : Mon Aug 18 2003 - 14:23:44 PDT