Subject: Re: [sv-bc] Interface notes from Friday's meeting
From: Karen Pieper (Karen.Pieper@synopsys.com)
Date: Tue Nov 18 2003 - 08:48:31 PST
My comments below.
At 11:58 AM 11/17/03 -0800, you wrote:
>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.
No this is not how they will be simulated. All you have to do is add a
specify block to those ports, and voila, they have to
be simulated as ports would be simulated otherwise (no hierarchical
reference.).
>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).
They are not hierarchical reference. See above.
>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).
If you want to simulate timing, they have to be connections.
>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.
Again. Using interfaces on ports are not hierarchical reference any more
than normal ports are hierarchical reference. If you are
willing to rewrite all ports as hierarchical reference and do away with
specify block timing, the ability to add delays (buffers, etc)
to long busses, and so on, then you can call interface ports hierarchical
reference. BUT THAT MEANS ALL PORTS! I don't
think you are prepared to do that, and legacy designs would not let us do
that anyway.
K
>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 : Tue Nov 18 2003 - 08:50:20 PST