RE: [sv-bc] Defparam -- mixed message from IEEE standards

The comparison to the programming goto is cute but facile, in my opinion.
It is extremely easy to describe the behavior of a goto and to implement it
in a compiler (most of the time anyway). The use of a goto is bad from a
methodology point of view, not because any individual goto's behavior is
unpredictable.

I defy *anyone* to explain all the intricacies of defparams in all their
glory, how they affect the design elaboration process and other defparams in
all the corner cases (including cycles, interference with generates,
interference with packages, interaction with libraries, effects on separate
compilation (if supported), etc)

Sure, the "common use" is relatively straightforward, but I know everyone
has in their regression suites lots of very peculiar corner case behaviors
for defparams. I wouldn't bet money on there being a consistent
interpretation of defparam behavior across all such corner cases across the
leading implementations.

Whether or not it is deprecated, it sure would be nice to have well defined
bounds of behavior for this construct.

Joao

-----Original Message-----
From: owner-sv-bc@server.eda-stds.org
[mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Paul Graham
Sent: Thursday, June 15, 2006 12:16 PM
To: mcnamara@cadence.com
Cc: Dave_Rich@mentor.com; sv-bc@server.verilog.org
Subject: Re: [sv-bc] Defparam -- mixed message from IEEE standards

> And, last time I checked, ANSI C, FORTRAN, et cetera, still has the goto
> statement, despite Edsger's best efforts, now 38 years in progress [Ref:

Even Ada has the goto statement!  Some language features are
just so useful that no amount of complaining will make them
go away.

Paul