Subject: Re: [sv-bc] Proposal to change interface ref-port default mode -or- documentation
From: Peter Flake (Peter.Flake@synopsys.com)
Date: Tue Sep 02 2003 - 10:24:44 PDT
Hi, Cliff,
The problem I have with your inout ports for variables is that they are not
genuine inout ports. You wrote
"A variable inout port would allow one continuous assignment (or procedural
assignments on one side of the inout port? (Jay - can a SystemVerilog
procedural assignment be made to an inout port per new flexible assignment
capabilities?)
A variable inout port would almost always be an error without a modport to
change the default-inout to a direction. I suppose one could use the
default inout port in an interface to a continuous assign on one side of
the port and a procedural READ on the other side of the port.
For all practical purposes, the default inout variable means that an
engineer has to declare modports, or bypass the modport declarations with
the "default ref;" declaration (essentially taking full responsibility for
all the ref-port problems that are about to occur, as opposed to allowing
them to occur by default)."
In Superlog and SV 3.0, inout ports for variables behaved like ref ports.
You thought this was too confusing, so ref ports were introduced in SV 3.1.
Now you seem to be saying that a variable cannot be written from more than
one place unless "default ref" is used, or modports.
So maybe all we needed was a qualifier to the interface to provide a
"default ref" feature, instead of ref ports!
BTW surely the synthesis tool will catch any incorrect use?
Regards,
Peter.
At 09:20 02/09/2003 -0700, Clifford E. Cummings wrote:
>Hi, Peter -
>
>Thanks for the reasoned reply.
>
>At 02:48 PM 9/1/03 +0100, Peter Flake wrote:
>>Cliff,
>>
>>The ref port feature is not intended for RTL designers, so it is not
>>surprising that no RTL designer has asked for it.
>
>By my estimate, 85-90% of all Verilog modeling is RTL-based, which is why
>I object to ref-ports being the default.
>
>This is why I will propose that all nets AND VARIABLES default to inout
>ports in the absence of a modport declaration. To help engineers build
>their transaction-level models with ref-ports.
>
>I will further propose that an engineer can add the declaration "default
>ref" to an interface. This is not a cumbersome requirement and can be
>easily added to existing models. These keywords already exist, so no new
>keywords are required. An engineer must now intentionally turn ports into
>ref-ports to get this odd behavior (odd as defined by RTL engineers).
>Adding two words to an interface is not too much to ask to avoid confusion
>and RTL coding problems.
>
>As I showed in my previous emails, ref-ports introduce three new rather
>nasty side-effects:
>(1) Sub-blocks that compile and simulate separately, may now fail during
>run-time simulation when combined.
>(2) ref-ports introduce a new form of race condition
>(3) ref-ports manipulate the variables of the parent module (and this is
>somewhat hidden because no hierarchical reference is made to the parent
>module).
>
>These side-effects are all new and they will confuse unaware RTL coders.
>
>This is also why, at a bare minimum, I have asked to add clarification
>wording to the sparse ref-port descriptions, to warn SV users that these
>ref-ports are very new and need to be carefully used.
>
>>It is for behavioral and transaction level modeling, before the detailed
>>control logic has been designed.
>
>I actually believe this may be true, but nobody has shown me a ref-port
>transaction model. I would like to see such a model. I would like to add
>such a model to the SV standard. I would like to try coding the same model
>a different way to see if the proposed solution is the best.
>
>>Subsequent RTL implementation could be a tri-state bus, requiring design
>>of the enable logic for each driver and the replacement of the shared
>>variable by the driven wires.
>
>This is a pretty good hint but still not specific enough to test.
>
>>One of the aims of the interface construct is to remove the brittleness
>>of hierarchical names. If you remove the ref port, the only way to get
>>shared variable behavior is to use hierarchical names. Similarly, the
>>behavior of hierarchical names seems the natural default for interfaces.
>
>Yes and no.
>
>It is true that interfaces remove the requirement to know the full
>hierarchical path name; hence, they are more flexible because they can be
>easily attached to any parent module without modification to the interface.
>
>It is true that references to parent variables within the interface do not
>require a hierarchical reference (potentially good for architectural and
>transaction based modeling ... still waiting for examples - very bad for
>RTL design).
>
>Interfaces introduce a whole new level of hierarchical naming wherever an
>interface is instantiated. I actually find this rather annoying, but
>necessary, because one could have multiple interfaces in a module
>port-list or instantiated into a module.
>
>>BTW some people liked the abstract FSM construct that you did
>>not. However the weakness that you found was that it did not map well to
>>the RTL implementation.
>
>Unfortunately, all of the examples shown in the original SV spec were RTL
>examples, all of which shared the same FSM coding style weaknesses. The
>only hierarchical FSM examples in the proposal were all simple and silly.
>
>I actually liked some aspects of the new style and made proposals to
>improve the style using both the transition keyword and ->> token. We
>reserved the transition keyword, but when no further hierarchical examples
>showed up in SV 3.1, I did not have backing to keep holding transition as
>a keyword and so it was removed from reserved status.
>
>There is nothing in the 3.0 standard that would prohibit adding a
>hierarchical FSM proposal in the future. I would just like to see a good
>example and make sure the proposed solution addresses the problem in the
>best way. I was not convinced that we had the best solution in the
>original proposal.
>
>>Regards,
>>
>>Peter.
>
>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 : Tue Sep 02 2003 - 10:35:25 PDT