Subject: [sv-bc] Re: [sv-ec] Interfaces - logic type & Intel
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Jul 21 2003 - 08:16:07 PDT
At 10:59 AM 7/16/03 -0700, Dave Rich wrote:
>Cliff,
>
>See my comments below. I could of saved you some more stupid assumptions
>if I knew what was bothering you in the first place.
Yeah, but you shouldn't have to field ALL of my stupid assumptions! ;-)
>Dave
>
>
>Clifford E. Cummings wrote:
>
>>Subject: Interfaces - logic type & Intel
>>
>>Hi, all -
>>
>>I have been asking questions of a few committee members related to the
>>above subject, but I think it is time to open the questions and debate to
>>the SystemVerilog email lists. I wanted to eliminate all of my most
>>obvious stupid assumptions before I shared my more select stupid
>>assumptions :-)
>>
>>With help from Dave Rich and Tom Fitzpatrick, I have discovered something
>>we passed for SystemVerilog 3.1 that I did not know we had passed.
>>
>>This subject came up because I asked the question whether modports were
>>practically required in an interface. Since almost all interface
>>variables must be declared to be of type logic (or another variable type
>>- but not wire), I was concerned that a logic variable that connected two
>>or more interfaces without modports was actually connecting two or more
>>inout ports to a logic variable and that logic did not permit multiple
>>drivers. Dave and Tom have pointed out that logic is not permitted to be
>>connected to any inout port and that logic in an interface that is not
>>defined with a modport becomes a ref-port.
>>
>>Section 18.8.1 - 4th & 5th bullets
>>— 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.
>>
>>Translation: Unless there are modport declarations, all interface
>>variables become ref ports which do permit multiple interfaces to connect
>>to the ref-ed variable at the higher level with last-assignment-wins
>>semantics. Without modports, logic variables at a higher level no longer
>>check to make sure that there is only one driver, because the variable is
>>now being changed as if there were hierarchical assignments from the
>>connecting interfaces.
>
>The check for one continuous driver is still there, even with hierarchical
>references. You are correct about multiple procedural writes, though this
>will violate the writes from multiple procedural block synthesis modeling
>style. This is why we suggest that the synthesis style *strongly*
>reccomend the use of modports.
Acknowledged. I guess checking for multiple ref-port procedural assignments
is a job for a linting tool. As an alternate, the synthesis tool will also
check and discover this (this is good to know).
Agreed that modports should be the recommended style.
>>Section 19.2.2 - 1st paragraph
>>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.
>>
>>Translation: Unless there are modport declarations, all interface
>>variables are assumed to be ref ports (nets become inout ports - which
>>are almost useless except for bi-directional busses and multiply driven
>>nets, such as onehot muxes and bus crosssbars).
>
>The fact that a port is declared as inout does not mean the user *must*
>use the port in a bidirectional or multi-driven manner. In fact, most
>Verilog simulators that I am familiar with do not look at the port
>direction unless the port is at a separate compilation boundry.
True. But the problem with wire inout ports in an interface is that
typically one side of the interface is reading the port and the other is
making a procedural assignment to the wire inout port, which is illegal.
(SV permits assign to a variable but not a procedural assignment to a wire).
interface inf1;
wire n1; // no modport - n1 is a wire inout port
endinterface
module m1 (inf1 a);
initial a.n1 = 1; // illegal
endmodule
module m2 (inf1, b);
logic c;
initial c = b.n1;
endmodule
module top1;
inf1 d;
module m1 (.a(d));
module m2 (.b(d));
endmodule
Whenever an interface signal is declared to be of type wire, that signal
cannot be assigned by a procedural statement anywhere, which limits the
flexible utility of an interface signal.
>>Now back to Intel.
>>
>>My understanding was that one reason Intel likes logic variables is that
>>the compiler made sure that there was only one driver on the logic
>>variable (VHDL-like std_ulogic behavior). I am sure that Intel guidelines
>>require engineers to add modports to interfaces, thereby turning the
>>ref-ports into input and output ports so that the logic-driver checking
>>is again enforced.
>>
>>If an engineer accidentally creates an interface and forgets to add one
>>of the logic signals to the modport but still makes assignments to the
>>logic interface signal from multiple modules, I believe we are again
>>going to have last-assignment-wins ref-ports, no multi-driver checking
>>will be enforced, and a rather nasty bug could exist in the design.
>
>If an engineer forgets to add a signal to a modport and connects a module
>to that modport, then the module will not have access to that signal, read
>or write, and will result in a compiler when error they try to access it.
Good point.
Question. What if two modules connect to a higher level logic variable
through interfaces, one with a modport output (output wire behavior) and
one without a modport (default-ref-port behavior). Is this a syntax error?
Where have we defined this in the SystemVerilog Standard?
>>I thought logic variables were going to give us very nice multi-driver
>>checking, but this appears to be an easy way to defeat the testing of
>>logic variables (by putting them into interfaces, not including modports
>>and turning all of the logic interface signals into ref-ports). I did not
>>understand this nuance when we voted for this behavior.
>>
>>Again, this problem does not appear to exist if we add all logic signals
>>to modports, but an omission yields strange behavior. Are the Intel
>>engineers okay with this behavior?
>>
>>I am still trying to think of a good shared-variable example to even
>>justify the existence of ref-ports. I know this is supposed to be an
>>architectural enhancement but I don't see the benefit, yet. Anybody have
>>a good example they would like to share?
>
>The most common example is a shared memory or cache between multiple
>processors. Let's assume that the connection between the array of
>processors is a shared memory. At the alogorithm or architectual level,
>this shared memory would be passed as a ref to the processor and a
>semaphore would be used to model the access arbitration. You could not use
>a global variable to represent the shared memory because each connection
>requires a different memory object.
>
>>If an engineer accidentally connects the output of two flip-flops in two
>>separate modules together to a logic inout port (a port not declared in a
>>modport), the behavior is going to be very un-hardware-like at the higher
>>level (last assignment wins as opposed to contention or compiler error).
>
>If the flip-flop is a primitive or another module, then a compiler error
>will occur because there are multiple continuous assignments to the same
>variable. If the flip-flop is modeled with always_ff, then the users
>intent has been recorded and software tools can check that no other
>procedural processes write to that variable.
Apologies - my description above failed to note that the flip-flops were
inside of modules and the ports are handled through interfaces. Now the
flip-flop outputs that drive interface logic ports (no modports used) will
be connected through ref-ports at the higher level and last-assignment-wins
behavior (non-hardware-like behavior) will result.
It seems to me that interface variables not declared with modports should
require ref-port declarations (if this behavior is desired) and that
ref-ports should not be the default. It seems like ref-port behavior should
be explicitly requested and not come into existence by accident.
So many of the SystemVerilog LRM interface examples are shown without
modports and the more I play with interfaces, the more convinced I am that
modports should not only be recommended, but in most cases, their omission
will yield behavior that is largely unexpected (ref-port default behavior
is sparsely described in the SystemVerilog Standard).
Barring a good reason to leave non-modport declared ref-ports as the
default behavior, I will submit a proposal that ref-ports not be the
default, which will almost guarantee that modports be required inside of
interfaces. This probably means that the discussion of modports should come
earlier in the SV standard and that almost all interface examples be
re-worked to include modport declarations. I am willing to take this action
item if I can convince the committee that this proposal should be adopted.
>>Regards - Cliff
>
>--
>Dave Rich
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 : Mon Jul 21 2003 - 08:20:01 PDT