Hi, all -
The VMM uses multiple examples of interface definitions constructed completely with wire declarations. This seems wrong. I have been trying to find a good reason to do this but I have not found it yet.
A common new-user mistake is to declare an interface using all wire declarations (after all, it seems like just a bundle of wires connecting different blocks. Right?) and then try to make a procedural assignment to an interface wire - ERROR - cannot make procedural assignments to net-types.
For years I have been giving SystemVerilog students to follow the guidelines:
(1) Only use a net (wire) where multiple drivers are required.
(2) For everything else, use an unresolved type (such as logic or bit)
These rules make perfect sense. But these rules are violated by the VMM.
Whenever there are multiple drivers on a net, everyone knows that you have to assign to the net from a continuous assignment, but for all single driver or procedural-assignment variables, logic (or bit) are universal data types.
Declaring an interface requires all interface-wires to be driven by continuous assignments or clocking block clocking drives. This seems like an unnecessary restriction.
Am I missing something regarding the importance of all-wire interface blocks?
Regards - Cliff Cummings
----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
cliffc@sunburst-design.com
www.sunburst-design.com
World Class Verilog & SystemVerilog Training
-------------------
Response from Janick:
Since the VMM also recommends that you use modports to enforce directionality AND clocking blocks for synchronous signals, you never actually make a procedural assignment to a wire but to the implicit driver in the clocking block. For asynchronous signals, you usually use a continuous assignment that requires a wire anyway.
You could use a 'logic' type as it turns into a wire if there is only one driver - hence does not violate the spirit of the VMM guideline. The important case is that they not be declared as reg or bit as it does not allow the same interface to be connected to all types of agent on it (e.g. it cannot be connected to an output port). It simply felt easier to state and enforce to require a wire in all cases.
Using wires also makes it easier to connect an interface defined by a VIP to an interface defined by a RTL design, both representing the same signal bundle.
--------------------
Hi, Janick -
Thanks for the response. Helps me to understand the underlying VMM assumptions. I thought this might be the answer. Let me offer some additional thoughts, insights and a recommendation.
The topic now transcends discussions on just the VMM so I have also posted this to SVUG.org.
>>> Janick >>> Since the VMM also recommends that you use modports to enforce directionality AND clocking blocks for synchronous signals, you never actually make a procedural assignment to a wire but to the implicit driver in the clocking block. For asynchronous signals, you usually use a continuous assignment that requires a wire anyway.
Working from a strict VMM standpoint this makes sense (more on this below).
For those doing pre-VMM experimentation, the all-wires interface causes significant grief.
(1) On the SystemVerilog cmmittee, we once considered requiring modports for all interfaces but a early adopter pointed out that they appreciated the ability to quickly assemble a design, much like a white-board block diagram, without working at the detailed modport level. Later when the design was considered to be more firm, modports would be added before widespread use. Seemed reasonable, so we agred that interfaces without modports had value.
(2) I have found places where I wanted to initialize variables at time-0 (your asynchronous scenario) and then make clocking drive assignments after time zero. Without the clocking prefix, I cannot make the asynchronous procedural assignments to wires. We on the SystemVerilog standards committee just finished clarifying that you can make both non-clocking and clocking assignments to the same variable. This will be particularly useful if we are able to include reproducible 2-state random initialization of variables (currently patented by HP). Lionel Bening and I wrote a paper on the topic for Boston SNUG 2004: SystemVerilog 2-State Simulation Performance and Verification Advantages
http://www.sunburst-design.com/papers/CummingsSNUG2004Boston_2StateSims.pdf
>>> Janick >>> You could use a 'logic' type as it turns into a wire if there is only one driver - hence does not violate the spirit of the VMM guideline. The important case is that they not be declared as reg or bit as it does not allow the same interface to be connected to all types of agent on it (e.g. it cannot be connected to an output port). It simply felt easier to state and enforce to require a wire in all cases.
Slight semantics correction: the logic type behaves like a wire if it is driven by a single driver and behaves like a variable when assigned from one or more procedural statements. Making both driver and procedural assignments to the same logic variable is illegal.
As of Accellera SystemVerilog 3.1, all Verilog variable types behave this way. You can now make continuous assignments to integers. This means that reg and logic are the exact same thing (as of SystemVerilog 3.1). There was no backward compatibility issue because nobody previously made driver assignments to reg-variables. That having been said, I agree with you and strongly prefer the new logic keyword over reg because of the common misconception that reg variables are always registered logic.
The bit-type is just a 2-state version of the logic and should also be perfectly safe in a VMM interface context, and indeed may help reveal a whole new class of bugs that are discovered when doing 2-state simulations (see the references to Lionel's other 2-state simulation papers in the paper mentioned above).
Bottom line, you can now connect output ports to regs and bits (avoid the regs - on this, Janick and I agree).
Good to hear that logic does not violate the spirit of the VMM guideline. I will now make that a forceful guideline in my training classes.
Although easy to state, the problem with the wires-in-interfaces guideline is that when taken out of VMM context, it can cause significant grief. That is when you find engineers coding pass-through continuous assignments to get their variables assigned to an interface signal (ugly!)
The bigger problem is, since many consider you (Janick) to be HDL Deity, they figure that when Janick gives a commandment, the commandment is applicable everywhere.
>>>Janick>>> Using wires also makes it easier to connect an interface defined by a VIP to an interface defined by a RTL design, both representing te same signal bundle.
Again, unless I am missing something, the only part that is easier to connect is a bi-directional or multi-driven bus. One might argue that an engineer should at least be aware of the bi-directional and multi-driven buses in the design and declare those buses to be multi-driver-compatible wire-types (and I might be that "One" who would make that argument ).
What I have gathered from this discussion is that there is no reason not to following the simple SystemVerilog guidelines:
(1) for multi-driven signals declare the signals to be wires(2) for everything else, declare the variables to be logic (or bit for 2-state simulations).
I would like to suggest that a future version of the VMM adopt the spirit of these guidelines, which also follows the spirit of the VMM.
Regards - Cliff |