Subject: [sv-bc] Interface notes from Friday's meeting
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Nov 17 2003 - 11:58:03 PST
Hi, All -
I appreciate the time that Vassilios gave me at the whole group meeting
last Friday, November 14th to discuss issues related to interface
functionality and documentation. Based on the comments and participation
during the meeting, I believe that the interface documentation requires
significant modification.
Part of the discussion focused on synthesizability or non-synthesizability
of hierarchical references and interfaces.
In my opinion (IMO), Verilog and now SystemVerilog are simulation languages
with reasonably defined subsets that can be rendered as hardware using
synthesis tools. IMO, SystemVerilog is not a synthesis language, even
though we have strongly considered synthesizability when proposing
SystemVerilog enhancements. I believe Stu made a good point that the
current documentation mixes simulation-centric and synthesis-centric
descriptions, and in so doing it is confusing to most readers.
Examples of synthesizable Verilog that are not very hardware centric
include the following:
module dff1 (output reg q,
input d, clk, rst_n);
always @(posedge clk or negedge rst_n)
if (!rst_n) q <= 0;
else q <= d;
endmodule
In this example, an asynchronous reset must be prefaced with either posedge
or negedge. In real hardware, an asynchronous reset is not edge-sensitive,
rather it is level-sensitive. The edge specification is required to get
correct simulation behavior of an asynchronous reset.
Another example would be that in the Verilog language, anything on the LHS
of a procedural assignment must be declared to be a variable type
(typically, of type reg). This is used for modeling both sequential and
combinational logic. There is no such concept in real hardware. (note that
VHDL signals are a much better representation of hardware than Verilog nets
and variables and VHDL engineers think the whole concept of separate
declarations for wires and regs to be very silly - they're right!)
Yet another example is the declaration of signed buses and
variable-vectors. There is no such thing in hardware - a bus is a bus! The
hardware has signed logic to perform signed arithmetic on buses connected
to the hardware.
I can provide even more examples if requested. Much of the Verilog language
is not synthesizable but still very useful for verification.
The point is, Verilog has always been described as a simulation language
and the synthesis subset defined and described later. Similarly, I believe
describing interfaces in simulation terms would be the easiest to understand.
IMO, it is correct to document that a declared interface type that is
referenced in a module header but that has not been instantiated is a
simulation error, even if this is perfectly legal and synthesizable by
synthesis tools.
IMO, the concept of ref-ports is very confusing as currently documented,
but they become much better understood when described as a hierarchically
referenced interface variables, similar to Verilog hierarchical references.
IMO (and this would have helped me to better understand interfaces years
ago), we should mention that interface types are declared, they are
instantiated into a module and the interface nets and variables can then be
referenced from a module header. This is the general case. Users can add
modports to provide port information to synthesis tools and to apply
simulation usage restrictions to interface nets and variables.
Dave Rich mentioned that hierarchical references to nets are exactly the
same thing as connecting nets to modules through inout ports. Dave is
correct, but now we have to unnecessarily describe nets and variables
differently for SystemVerilog interfaces. If synthesis tools turn
non-modported nets into inout ports, but require variables to be declared
in a modport to be synthesizable, that is fine by me but it really does not
affect SystemVerilog simulation.
If we described interface access to nets and variables simply as indirect
references to the nets and variables and stay away from default inout ports
and ref-ports, I believe we are concisely and correctly describing
interfaces as they will be simulated.
We should further describe modports as a means of applying hardware meaning
and usage restrictions to interface variables. IMO as a good coding
methodology - any user that adds a modport to define inputs and outputs
should also add inout ports (and ref-ports) to the modport definition and
not leave nets to build inout ports through a default action.
IMO, it would be useful to describe interfaces as syntactic sugar to make
indirect hierarchical access to interface variables. Hierarchical
references require knowledge of the hirerarchical path name while
interfaces reference an instantiated interface using a local aliased name
(not a very good description).
IMO, describing interface references as connections and ports confuses the
simulation model and turns the description into a partial RTL-hardware
description of interfaces (just like Stu noted in the meeting).
IMO, it is easier to understand interface tasks, functions and assertions
if they are described as referencing common tasks, functions and assertions
from an instantiated interface. Stu mentioned that automatic tasks could be
thought of as being unique to each "connected" interface, but my experience
with tasks is that are very rarely used in RTL synthesis (sometimes used in
large FSM designs to make repetitive macro assignments to multiple FSM
outputs). IMO, interface tasks, functions and assertions are going to be
most useful for verification purposes.
Karen mentioned that an interface with an modport output is not the same
thing as a hierarchical reference (without the modport, they were basically
the same thing). If we had wanted to, we could have proposed an "output
a.qout" declaration (where "a" is the hierarchical path) to accomplish the
same thing (believe me, this is NOT a proposal that I would support!)
SUMMARY - IMO, interfaces should be described as a form of hierarchical
references, plain and simple, and then mention modports for use with
synthesis and to apply net and variable access restrictions. IMO, this
covers all cases very simply and we no longer have these strange inout and
ref-port defaults. IMO, we should drop descriptions of ports, instances and
connections from interface net and variable references.
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, SystemVerilog, Synthesis and Verification Training
This archive was generated by hypermail 2b28 : Mon Nov 17 2003 - 12:26:24 PST