[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