RE: m-factor in IEEE 1364

---------- Forwarded message ----------
From: Steven Sharp <sharp@cadence.com>

I am still not entirely clear what the original request to 1364 was about.
I can only hazard a guess.

It appears that a form of m-factor support was added to NC-Verilog-AMS using
a kludge. This kludge is presumably an interim solution, rather than a
proposal for how it should actually be done in AMS (or at least I hope so).
This kludge involves having an actual digital-Verilog parameter represent
the m-factor in the Verilog source, but using non-standard behind-the-scenes
mechanisms (specified by attributes) to get the desired m-factor-like
behavior (i.e. not having to explicitly declare the m-factor parameter,
not having it be affected by normal parameter overriding, passing it down
through levels where it isn't actually specified, and multiplying the values
together at levels where it is specified).

I am guessing that the request was to add some kind of official mechanism
for doing this to the digital-Verilog standard.

However, it does not appear to me that the "hybrid" approach used in this
kludge is appropriate for either Verilog-AMS or digital Verilog. The AMS
description seems to call for the m-factor behavior to be transparent to
the model, without the model explicitly referencing it. The hybrid approach
involves explicit references, which is undesirable for AMS.

Digital Verilog could presumably work with a transparent mechanism. The
source would not explicitly reference the m-factors, which would be fine
because digital Verilog doesn't care about them. It could also work with
a fully explicit mechanism, where the existing Verilog parameter propagation
support was used to pass explicit parameter values down and perform explicit
multiplication. But this half-transparent-half-explicit hybrid doesn't fit.
By the time all the behind-the-scenes stuff is added to make them act like
m-factors, these things don't act much like Verilog parameters any more.
It is hard to see why parameters would be an appropriate foundation for
adding this functionality to the language.

The use of attributes to control this functionality is also inappropriate.
Attributes in Verilog are not supposed to have any direct effect on the
semantics of the Verilog code. But these attributes would have effects
that would be visible in the digital Verilog code, which would violate this.
Changing the behavior of parameter overrides by making them multiplicative
would violate it. Allowing passing a parameter to a module that didn't
declare it would be an even stronger violation of this, actually changing
what syntax was allowed.

I assume that this kludge allowed a quick-and-dirty implementation of
m-factors in NC-Verilog-AMS based on the pre-existing support for both
attributes and parameters in NC-Verilog. I can understand the reasons for
doing this in a first-cut implementation. That doesn't mean that this
kludge is an appropriate extension for either language.

It is possible that there is a way of doing this that is appropriate. But
based on the limited information I have, it looks like an approach that is
fully transparent in the digital code is the "right" way to do it in the end.

Steven Sharp
sharp@cadence.com
Received on Tue May 11 16:51:59 2004