Jonathan Bromley
Guest
Tue Mar 15, 2011 11:29 pm
On Mon, 14 Mar 2011 15:41:22 -0700 (PDT), Andy wrote:
Quote:
I found it strange that you mentioned "hiding" as an advantage to the
XMR capability. While the overhead of implementing the interface is
hidden (if not avoided entirely), the entire implementation of the
module is exposed by XMR.
Undoubtedly true; I should have said "encapsulation" rather
than "hiding", I suppose. In vanilla Verilog EVERYTHING is
both static and public, with some justification (think VPI
and debug...), whether you like it or not. The language
doesn't allow the writer of a module to enforce a contract.
The packaging I described isn't bad, though, as you
must surely admit. A Verilog user with some measure of
self-discipline (and buy-in from colleagues) can maintain
appropriate separation between modules. Like you, I wish
the situation were somewhat different, but it ain't.
Quote:
I cannot help but wonder if this XMR capability (in any language) is a
wolf in sheep's clothing. As long as I, the writer of a module, force
you to go through a mutually agreed upon interface to verify my
module's functionality, I'm free to change the implementation without
fear that it will break someone's verification code, so long as I have
not changed the behavior at the agreed upon interface.
Not just verification, but for any use whatever, the
fear is always there. Sure. Verilog believes that you
know best, and rarely offers you a safety rail at the
edge of the cliff.
Quote:
Even if I use
global signals in a package (VHDL), I am still declaring (and
protecting) a public interface to which I am implicitly promising (and
more importantly, limiting) fidelity. If you have a need to interface
with a module, whether it is for verification or not, that interface
must be agreed upon by all parties (with its limitations documented,
even if only in code), instead of taken for granted by the
verification engineer that it will continue to work in the future.
Ah, contract at the interface. Not a shining feature of Verilog.
Even for RTL design, where synthesis tools (not the language) forbid
you from accessing the functionality of a module by any means other
than through its ports, the ports themselves provide no contract
about the functionality they implement - they're just the names
and directions of signals. And those directions aren't very
rigidly enforced by Verilog either. Ho hum.
Quote:
Is there any way to limit the tasks or objects that may be accessed
externally?
No, not in regular Verilog. Of course, in SystemVerilog you
can write classes and give them local and protected members;
doesn't help for RTL design, though.
--
Jonathan Bromley
