RE: [sv-bc] defparam problems

[Shalom Bresticker]
> If we are talking about debugging problems, then a very frustrating
> problem I have frequently encountered with in-line parameter 
> passing is the following:
> I come to a parametric module.
> I don't know what the parameter values are in the instantiation.
> I don't even know who instantiates it.
> I have to go searching for its instantiation.
> Then when I finally find it, I find that the actual parameter value is
> itself a parameter or function of parameters passed down from yet a
> higher level module.
> So I have to repeat the process.
> This can go through several iterations until I get to the final stop.

Whilst I agree that this can be hard work, I don't really see how
it differs from any of the issues one encounters when debugging
low-level problems in a large hierarchy.  The whole point of 
hierarchy is that the source code of a child instance neither
knows nor cares about its instantiating parent.

What's more, the debugging problem you describe is considerably
harder if defparams are used - I can't reliably locate the 
parameter overrides even if I successfully locate the instance 
of "my" module in its parent.

Defparam has historically been handy to provide named
mapping of parameter overrides at the site of a child
instance, but this was completely obviated by V2k1 
named parameter mapping.

I am unable to see why it is a good idea for a *design* to
override parameters of modules further down the hierarchy
than its immediate chlidren.  On the other hand, I have often
found situations where it is extremely useful for a testbench 
to tweak low-level modules to make them easier to debug, or
to control generates for assertions or other diagnostic stuff.
So although I strongly sympathise with the decision to deprecate
defparam, I have a certain nostalgic attachment to it.
-- 
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.