Subject: RE: [vhdl-200x] Transmission gate mechanism and new parameter mechanism wanted
From: Jay Lawrence (lawrence@cadence.com)
Date: Fri Mar 21 2003 - 07:08:56 PST
Verilog allows this capability via the 'defparam' statement. A defparam
can be used to set a parameter value anywhere in the hierarchy
(including your own parent) and there is no end to the pain and
frustration it causes implementors.
User's do end up creating loops between parameter values. Because of
historical precedence for this we build a dependancy graph and only
allow one iteration through the loop and then just stop. In the Verilog
2001 world some restrictions on generate statements in Verilog were
added to not make the problem even worse but it still exists for regular
instances.
===================================
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
> -----Original Message-----
> From: Jonas Nilsson [mailto:jonas@hardi.se]
> Sent: Friday, March 21, 2003 9:57 AM
> To: Paul J. Menchini
> Cc: vhdl-200x@eda.org
> Subject: Re: [vhdl-200x] Transmission gate mechanism and new
> parameter mechanism wanted
>
>
>
>
> "Paul J. Menchini" wrote:
> > Erich is right. IIRC, one of the major problems is that
> causal loops
> > can be created. Even if such loops are not created, the
> evaluation of
> > generics becomes NP in the general case.
> >
> > Of course, such concerns are not reasons to reject this
> request out of
> > hand....
>
>
> Restrictions could be placed on how the "upward" parameters are used,
> and how their values are assigned. (For instance: parameter
> values have
> to be locally static in the lower level module or even
> restricted to be
> declared in the entity before the generics, so they can't use generic
> values or any static value calculated in the rest of the
> entity/architecture)
>
> The drawback of restrictions like this is quite severe, since
> it would prevents propagation of these values through modules,
> both laterally and through hierarchy. But better ways could
> perhaps be devised.
>
> Figuring out the dependency graph during elaboration would be better
> from a user standpoint. Even if this is an NP problem, real life
> designs would probably contain a limited number of parameters that
> needed this analysis.
>
> The biggest problem I see is that the dependency graph can become
> so complex that it's easy for the user to inadvertently create
> loops but difficult to figure out how to break them when the
> elaborator reports an error.
>
>
> Regards,
> Jonas
> --
> Jonas Nilsson
> HARDI Electronics AB
> Dalbyvagen 22
> SE-224 60 LUND
> SWEDEN
>
> Phone : +46-46-16 29 00
> Fax : +46-46-16 29 01
>
This archive was generated by hypermail 2b28 : Fri Mar 21 2003 - 07:14:42 PST