RE: [sv-bc] defparam problems

Hi,

The description of this real and frustrating problem that I have often
encountered was prompted by the implication that in-line parameter
passing eliminates uncertainty about the parameter values actually used.
It just ain't so.

I was not trying to imply that defparams do solve that problem.

On the other hand, if I had all defparams grouped together in one
central file, it would indeed be easier to find the actual values used.

Shalom

>-----Original Message-----
>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
>Behalf Of Jonathan Bromley
>Sent: Thursday, November 10, 2005 11:08 AM
>To: sv-bc@eda.org
>Subject: 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.