RE: Mfactor proposal..

I agree. I dont think a language feature should be specified as part of an attribute, which the simulator can ignore (but still give same results).
 
The problem with {} before the port list might mean a change to parsing the instance line which might impact both the digital and analog instance spec right?

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Kevin Cameron
Sent: Tuesday, May 25, 2004 10:19 AM
To: CLC Shekar
Cc: Verilog-AMS LRM Committee
Subject: Re: Mfactor proposal..

CLC Shekar wrote:

Hi all,

Please find attached a pdf document outlining the proposal for mfactor
support in Verilog-AMS(structural). Please let us know your comments.
cheers,
Shekar.

That looks like a bit of a hack to me. The parameter and attribute mechanisms are general purpose schemes for things that are not part of the language proper. M-factor needs to be part of the language proper: attributes and parameters can be ignored when they shouldn't be.

I prefer my earlier proposal (http://www.eda.org/verilog-ams/hm/0705.html <http://www.eda.org/verilog-ams/hm/0705.html> ) that the m-factor be specified in the instance statement in {} before the port-list, and be retrievable in an instance with the system-function $mfactor (returning a real).

Kev.

-- 
Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862