RE: [sv-bc] defparam problems

Subject: RE: [sv-bc] defparam problems
Date: Wed, 9 Nov 2005 12:05:13 -0700
From: "Premduth Vidyanandan" <premduth.vidyanandan@xilinx.com>
To: "Clifford E. Cummings" <cliffc@sunburst-design.com>,
        <sv-bc@server.eda.org>
X-Virus-Scanned: ClamAV 0.83/1166/Mon Nov  7 11:01:45 2005 on
server.eda.org
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id
jA9JCcdM012487

Hi Cliff,

I agree with everything you have to say here - very valid point.

For most one-instance basis, we ask everyone in our company to use the
inline parameter passing as well. The only question I have is what the
replacement method for hierarchical defparam passing is. What I mean by
this is similar to what Shalom was saying:

If I have a parameter on instance A that is buried under B which is
buried under C, then I can use the defparam from my TB to change the
value at instance A by using:

myparam.uut.b.a = ..

Does the inline parameter passing option allow for this? 

Is there syntax on how to do this with the inline parameter method?

Thanks
Duth


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Clifford E. Cummings
Sent: Wednesday, November 09, 2005 11:49 AM
To: sv-bc@eda.org
Subject: [sv-bc] defparam problems

At 11:14 PM 11/8/2005, Bresticker, Shalom wrote:
>Almost any language construct can be used well or abused. Such is the 
>case with defparam as well. That is one reason why we have guidelines, 
>to avoid problematic usage while allowing reasonable usage.

Shalom is correct that defparams are not the only Verilog construct with

problems that are properly addressed with coding guidelines. But unlike
most Verilog constructs, the problem with defparams is that most
possible uses of defparams are problematic, which warrants their
deprecation from

the Verilog language.

>In more than 15 years of experience with Verilog, I have never 
>encountered a real-life example of any of these pathological uses of 
>defparams. If others have, it just means that we need a lint tool to 
>check that defparams are not doing weird things.

I have not seen all of the pathological cases, but I have experienced a
number of them.

- Multiple defparams in the same file - seen it - very confusing until
you find the problem

- defparams can be placed before the instance or after the instance and
I have seen engineers group all the defparams either at the beginning of
a

file or at the end of a file, pages away from the instances they modify.

They become difficult to track and debug. Named parameter passing places

the instances and parameters together for easy interpretation (great
documentation style).

- Until just a few years ago, Synopsys DC did not allow parameter
redefinition using defparam. Only #(positional) parameter passing was
recognized. I was most disappointed when Synopsys allowed use of
defparams.

- Defparams in a separate file - IMO it is a bad idea to control local
variables from a global file. I have seen local defparams overridden by
global-file defparams. Very confusing until you find the problem.

- Downward hierarchical parameter manipulation using defparams.
Reasonable
under controlled conditions (Shalom has mentioned some) but not
synthesizable and problematic for RTL designers. Seen it! I believe we
can address this with a downward-only hierarchical-name parameter
passing enhancement - I could support this.

- Upward hierarchical defparams. Why do this? I would like to see the
compelling methodology that makes this capability a recommended
solution. 
IMO changing parent-parameters and parameters in a parallel hierarchy
using
upward- and cross-referenced defparams is on the same par as
self-modifying code. I have not seen a compelling reason to do this.
Anybody want to submit an example for scrutiny?

- I have never seen the circular parameter modifying pathological
example that had in my earlier email, but I did find it interesting that
one vendor iterated through 10 cycles before stopping and warning the
user that cyclic parameters might be present.

In addition, the implementation of defparams has triggered some authors
to make other ill-conceived recommendations to avoid the defparam
issues.

Bening & Foster - Principles of Verifiable RTL Design, 2nd Edition, pp.
146-147
The authors recommend using `define and in-house preprocessors to avoid
parameter problems. Some of their reasoning is just plain silly, but we
get to the crux of the problem on page 147, starting with the second
bullet:

"Parameters have a higher degree of difficulty than `define in their
implementation by EDA tool developers. As well as startups, major
established vendors have differences (bugs?) in their implementation of
parameters."

"We recommend that you let your competitors spend their time on the
parameter issues while your project sails on to success without
parameters."

Quite frankly, all the tool vendors have handled parameters correctly,
forever. Even simple defparams located next to instances have worked
well. 
So what could Bening and Foster possibly have seen that would cause this

strong (and silly) recommendation? defparam-abuse!

IEEE 1364-2001 - Section 12.2.1

The first paragraph removed defparam orthogonality - no hierarchical
defparams from a generate statement, which was the right thing to do.

The third paragraph was a poorly conceived editorial comment that we
have already debated: "The defparam statement is particularly useful for
grouping all of the parameter value override assignments together in one

module." (IMO - this statement should be removed).

The last paragraph was added to the 1995 standard because vendors were
giving different results based on placement of multiple defparams (yes
this was happening!): "In the case of multiple defparams for a single
parameter, the parameter takes the value of the last defparam statement
encountered in the source text. When defparams are encountered in
multiple source files, e.g., found by library searching, the defparam
from which the parameter takes it's value is undefined." (The solution
proposed in this paragraph?? 
- we give up!!)

Brad gave an `include-task example that I have never seen anyone try. I
would like to know why this methodology is recommended. Even this could
be fixed with hierarchical named-parameter passing. The
struct-parameters could be addressed (if desired) using the
named-parameter passing.

My hatred for defparams and my support for defparam-deprecation stems
from the fact that aside from the simple defparams placed next to the
instances, and Shalom's possible downward defparams for behavioral
models, every other use of defparam either an abuse, obscures the
redefinition, or contributes to difficult debug situations.

If there were no reasonable alternative to defparams, then defparams
would offer value, but the Verilog-2001 named parameter passing
enhancement all but removed the need for a defparam statement. But when
the potential for abuse outweighs the potential for correct usage and
good design practices, it is time to remove the problem. "Death to
defparams!!"

Regards - Cliff

>Shalom

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com Expert Verilog,
SystemVerilog, Synthesis and Verification Training

--
Matt Maidment
mmaidmen@ichips.intel.com