RE: [sv-bc] Defparam -- mixed message from IEEE standards

> The full quote was, "Like I have said before, 
> defparam was a good idea gone bad."
 
> Also remember that verification code is much freer
> than design code.

I think this may be a storm in a teacup.  Few synthesis
tools support defparam except possibly for defparams
on a child instance, specified at the instantiation site.
Consequently, the loss of defparam would have essentially
no implications at all for RTL design now that we have
named parameter mapping in module instances.

For non-synthesisable code, though, defparams (in my 
view) remain a powerful and useful feature.  They provide
the facility, which also exists in VHDL hierarchical
configurations, for centralising control of parameters
throughout an instance hierarchy.  They allow constant
values in leaf modules to be tweaked from within a 
testbench, to ease some kinds of debugging.  All this
is good stuff, and far too widely used in legacy code
to permit the loss of defparam in the foreseeable future.

What I absolutely fail to understand, however, is the
utility of *upwards* defparam.  This seems to me to 
be a recipe for disaster, with its brain-warping 
opportunities for circular reference.  I'd be very 
grateful if someone could outline how an upwards 
defparam could ever be appropriate and necessary; 
alternatively, perhaps some of the vendor experts 
who have access to large suites of user code samples 
could indicate how many of those samples make use 
of upwards defparam.

For clarity: when I say "upwards defparam" I mean defparams
that affect sibling or ancestor modules.  There's a common
and useful case where hierarchy-wide defparams are located
in an annotation or configuration module which is then
elaborated at the top level; I suppose that, strictly 
speaking, every defparam in such a module is an upwards
reference, since its name search must float upwards from
the top-level annotation module to find the main 
simulation hierarchy.  I don't really see that as an
upwards defparam, although I suspect it would be rather 
hard to capture the distinction in a language standard.
In any case, it could trivially be worked around by 
instantiating the main top-level within the annotation
module, which I suppose is somewhat like the way a 
VHDL configuration works.

Why, by the way, are Verilog users so fond of elaborating
simulations with multiple top-level modules?  What would be
so hard about instantiating all those top modules in a 
trivial top-level wrapper?
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

-----Original Message-----
From: owner-sv-bc@server.eda-stds.org [mailto:owner-sv-bc@server.eda-stds.org]On Behalf Of Bresticker, Shalom
Sent: 15 June 2006 09:12
To: Brophy, Dennis; cliffc@sunburst-design.com; sv-bc@server.verilog.org
Subject: RE: [sv-bc] Defparam -- mixed message from IEEE standards


 
Shalom
 



From: Brophy, Dennis [mailto:dennisb@model.com] 
Sent: Wednesday, June 14, 2006 5:56 PM
To: Bresticker, Shalom; cliffc@sunburst-design.com; sv-bc@server.verilog.org
Subject: Re: [sv-bc] Defparam -- mixed message from IEEE standards
 
Those are not the words I recall that Cliff uses to describe DEFPARAM.  Of course the quality of DEFPARAM is noted in the past tense which suggest the idea may no longer be a good one.  :)


-----Original Message-----
From: owner-sv-bc@server.verilog.org
To: Clifford E. Cummings; sv-bc@server.verilog.org
Sent: Wed Jun 14 02:35:52 2006
Subject: RE: [sv-bc] Defparam -- mixed message from IEEE standards

I quote Cliff: "defparam was a good idea".

Almost any useful construct can be misused.

I searched through 1364-2005 and 1800-2005. The word "useful" is used 19
times in 1364-2005 and 28 times in 1800-2005.

Does anyone want to propose disallowing upwards defparams ?

Shalom