Subject: Re: [sv-bc] Proposal to change interface ref-port default mode -or- documentation
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Tue Sep 02 2003 - 09:20:12 PDT
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 - 09:24:08 PDT