Subject: Re: [sv-bc] Proposal to change interface ref-port default mode -or- documentation
From: Dave Rich (David.Rich@synopsys.com)
Date: Wed Aug 20 2003 - 22:05:29 PDT
Cliff,
For the proposal on 9.6, why not add the fact that three continuous
assignments are not allowed; when there are two instances a module with
ref ports connected together. You might also want add that four
continuous assignments are not allowed when there are two ref ports and
one hierarchical reference.
I did not add an emoticon to the above so it would add more punch,
otherwise I would have typed it in. (Call me if you still don't get it).
The point is that maybe we didn't do a good enough job explaining the
ref port semantics. Its not supposed to change any of the rules that
apply to variables. Only one continuous assignment means only one
continuous assignment, whether it be directly to the variable, via a
plain hierarchical reference, through ref port of a module, or through a
ref argument of a task/function. (A ref argument of a task/function
could only place a procedural assignment on the variable, which could
still create an illegal combination of assignments).
The example you show is EXACTLY the behavior users have been asking for
years. The two modules, sub1 and sub2 work fine in a testbench
independently, but as soon as you try to connect the two of them
together, you get a compiler error.
Dave
Clifford E. Cummings wrote:
> Subject: Proposal to change interface ref-port default mode -or-
> documentation
>
> Hi, All -
>
> A PDF version is attached with colors and italics.
>
> Thanks to Jay and Dave Rich for responses.
>
> Included below:
> Proposal to change wording in section 9.6
> Proposal to change wording in section 18.8.1
> Proposal to change default behavior of interface variables, including
> new "default ref;" declaration.
>
> I would like to discuss and vote on these proposals at the next sv-bc
> meeting.
>
> Regards - Cliff
>
> Jay noted section 9.6 Continuous Assignments.
> " ... Variables can only be driven by one continuous assignment or one
> primitive output. It shall be an error for a variable driven by a
> continuous assignment or primitive output to have an initializer in
> the declaration or any procedural assignment. See also Section 5.6."
>
> And Dave Rich noted section 18.8.1
> 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.
>
> Taken together, I can now see that we have sort-of shown that two
> continuous assignments through ref-ports could be illegal. I think the
> wording must be more clear than just this (proposals below). The
> problem is that ref-ports have been defined as this
> last-assignment-wins variable at a higher level of hierarchy, which is
> why I thought the rest of the documentation indicated that a
> continuous assignment through a ref-port was equivalent to a
> hierarchical procedural assignment to the upper data type; hence, not
> a true continuous assignment.
>
>
> I believe the following clarifications are required to disambiguate
> the continuous assignment behavior to a ref port.
>
> Proposed change to section 9.6
> " ... Variables can only be driven by one continuous assignment or one
> primitive output. This also means that a variable cannot be driven by
> two continuous assignments from ref ports through two different
> modules to a common variable, nor can the common variable be driven by
> a continuous assignment through a ref port and by any other procedural
> assignment, including a procedural assignment through another ref
> port. It shall be an error for a variable driven by a continuous
> assignment or primitive output to have an initializer in the
> declaration or any procedural assignment. See also Section 5.6."
>
> Proposed change to section 18.8.1
> 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. If a continuous assignment is made to ref-port
> connected variable data type, no other continuous or procedural
> assignment can be made to the variable data type, even if the
> assignments were made through other ref ports. This kind of port can
> not be left unconnected.
>
>
> For the record, we have defined a ref-port without really describing
> why or how they should be used. No real good examples of ref-port
> usage is shown in the standard.
>
> Ref-ports are already strange to the normal Verilog user. I will
> accept on faith that ref-ports can be valuable for behavioral
> modeling, per Dave Rich's earlier mention of cache-modeling (I still
> would like to see a full, useful behavioral model done using ref-ports
> so I could evaluate the feature based on an actual design and my own
> design background, but I don't think that is going to happen).
>
> One of my big concerns is that for the first time in Verilog-coding
> history, an engineer will now have to know how a variable was assigned
> in an instantiated module because the nasty and difficult-to-debug
> ref-port behavior is going to be the default in SystemVerilog
> (interfaces without modports default to this whole new ref-port type
> and you better understand how ref-ports are assigned in the sub-modules).
>
> With the previously mentioned ref-port behaviors, it is now possible
> for an engineer to correctly code an interface, successfully attach
> the interface to block tests and fail once the interface and blocks
> are connected inside a top-level model. See example below.
>
> I personally believe that the default interface ref-port will yield
> lots of support calls to EDA vendors, a whole lot more than the .*
> that Karen Pieper fears so much. Engineers are going to unknowingly
> use ref-ports wrong and they are going to call and place the blame on
> the EDA tools. Even after EDA support personnel explain the nuances of
> the ref-port and how the engineer needs to pay more attention to the
> assignment types in the interface-connected modules, the engineers are
> going to tell your support teams that this behavior is absurd and you
> need to fix this in your tool. Look at how long it has taken to
> explain this to Cliff and I know my Verilog and SystemVerilog better
> than almost every RTL design engineer who is going to run into this.
>
> If I were an EDA vendor who was trying to slow down the adoption of
> SystemVerilog by the engineering community, I would be all over this.
> I would show the "much touted interface" and how default interface
> ref-ports can cause debugging nightmares and require more scrutiny of
> instantiated modules.
>
> I really should not be fighting this because this is obviously going
> to require a lot of training and examples and exercises and labs to
> help engineers get it right. This could add a half-day to any good
> SystemVerilog training class (more billable hours!)
>
> PROPOSAL:
> I would like to propose that an interface be allowed to include a new
> declaration: "default ref;" and without the "default ref" declaration,
> all interface nets AND VARIABLES default to inout ports. Good reasons
> to implement this change include:
> (1) Since "default" and "ref" are already keywords, this
> introduces no new keywords to SystemVerilog.
> (2) Since this declaration requires only two words to be added to
> interfaces, it still allows rapid interface prototyping without the
> more verbose modport declarations (seemed to be an important point
> with Matt Maidment).
> (3) The engineer has to at least make this declaration before
> cutting his own throat with the new and unfamiliar ref-port types.
> (4) SystemVerilog is still young and not widely used. Now is the
> time to fix the ref-port defaults in interfaces.
>
>
> Dave Rich gave a couple of good error examples using ref-ports, but I
> think the examples are too simple and not indicative of the types of
> problems engineers will discover. Consider the following example (not
> tested). When just sub1 is compiled, it should work(block test #1).
> Turn on the switch +define+SUB2 and it should still work (block test
> #2). Turn on the switch +define+TOP and it fails. Non-intuitive
> debugging follows.
>
> interface example_if;
> logic a; // a is a ref-port (no modport)
> endinterface
>
> module sub1 (example_if s1_if);
> assign s1_if.a = 1;
> endmodule
>
> module sub2 (example_if s2_if);
> assign s1_if.a = 0;
> endmodule
>
> `ifdef TOP
> module top;
> logic sel, x2;
> example_if x_if;
>
> sub1 u1 (.s1_if(x_if));
> sub2 u2 (.s2_if(x_if));
>
> // Illegal
> assign x1 = !sel ? x_if.a : 'z; // u1.s1_if.a
> assign x1 = sel ? x_if.a : 'z; // u2.s2_if.a
>
> initial begin
> sel = 0;
> #10 x2 = x1;
> sel = 1;
> #10 x2 = x1;
> // ...
> $finish;
> end
> endmodule
> `elsif SUB2
> module top;
> logic sel, x2;
> example_if x_if;
>
> sub2 u2 (.s2_if(x_if));
>
> // Legal
> assign x1 = sel ? x_if.a : 'z; // u2.s2_if.a
>
> initial begin
> sel = 0;
> #10 x2 = x1;
> sel = 1;
> #10 x2 = x1;
> // ...
> $finish;
> end
> endmodule
> `else
> module top;
>
> example_if x_if;
> logic sel, x2;
> sub1 u1 (.s1_if(x_if));
>
> // Legal
> assign x1 = !sel ? x_if.a : 'z; // u1.s1_if.a
>
> initial begin
> sel = 0;
> #10 x2 = x1;
> sel = 1;
> #10 x2 = x1;
> // ...
> $finish;
> end
> endmodule
> `endif
> ----------------------------------------------------
> 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
-- -- David.Rich@Synopsys.com Technical Marketing Consultant http://www.SystemVerilog.org tele: 650-584-4026 cell: 510-589-2625
This archive was generated by hypermail 2b28 : Wed Aug 20 2003 - 22:08:32 PDT