Subject: [sv-bc] Re: [sv-ec] Interfaces - logic type & Intel
From: Dave Rich (David.Rich@synopsys.com)
Date: Wed Jul 16 2003 - 10:59:07 PDT
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.
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.
>
>
> 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.
>
>
> 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 error they try to
access it.
>
>
> 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 a 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.
>
>
> 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
>
>
>
-- -- Dave Rich Principal Engineer, CAE, VTG Tel: 650-584-4026 Cell: 510-589-2625 DaveR@Synopsys.com
This archive was generated by hypermail 2b28 : Wed Jul 16 2003 - 11:03:02 PDT