Subject: [sv-bc] RE: [sv-ec] Interfaces - logic type & Intel
From: Vassilios.Gerousis@Infineon.Com
Date: Wed Jul 16 2003 - 04:26:37 PDT
Hi Cliff,
I have added sv-bc team on this email. You may not be familiar with
the new set up for 3.1A development. All design related portion of
SystemVerilog is the responsibility of the SV-BC team. SV-EC is only focused
on Testbench. The interface section definitely is required for all
components of SV and crosses different boundaries. Both teams should discuss
this. The interface section should be owned by one of those two committees.
I will discuss this with the chairs and together identify the correct
committee.
The simple rules we need to follow is that:
1- sv-bc owns the design component of SV (implementation/usage issues and
enhancements).
2- sv-ec owns the Testbench component of SV (implementation/usage issues and
enhancements).
3- sv-ac owns the assertion component of SV (implementation/usage issues and
enhancements).
4- sv-cc owns the full API component of sv (implementation/usage issues and
enhancements).
This change is important, since 3.1A will solidify 3.1 standard.
Vassilios
-----Original Message-----
From: Clifford E. Cummings [mailto:cliffc@sunburst-design.com]
Sent: Wednesday, July 16, 2003 12:58 PM
To: sv-ec@eda.org
Cc: mmaidmen@ichips.intel.com; wayne.clift@intel.com
Subject: [sv-ec] Interfaces - logic type & Intel
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 varibles 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.
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).
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.
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?
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).
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 : Wed Jul 16 2003 - 04:29:45 PDT