RE: analog operators as system functions

Hi Ken,

No, the only change for implementations I propose is in syntax; I would also propose a  slight rearrangement of the LRM in line with those changes, i.e. moving the description of the analog operators to the chapter on system functions.

Marq


From: Bakalar, Kenneth [mailto:kenneth_bakalar@mentor.com]
Sent: Thursday 10 September 2009 14:16
To: Marq Kole; verilog-ams@server.eda.org
Subject: RE: analog operators as system functions

Hi Marq,

Are you suggesting only a change in the syntax of the identifiers, or does the change have some deeper consequence?

Best Regards,
Ken
________________________________
From: owner-verilog-ams@server.eda.org [mailto:owner-verilog-ams@server.eda.org] On Behalf Of Marq Kole
Sent: Thursday, September 10, 2009 4:16 AM
To: verilog-ams@server.eda.org
Subject: analog operators as system functions

Dear All,

Recenly I have been reviewing some of the analog features in Verilog-AMS and it struck me that the current distinction between analog operators and system tasks and functions is rather artificial. There are a few analog operators that do not require the specific treatment of the analog filter functions, while there a few system tasks and functions that do. Specifically, the analysis function call and the small-signal AC and noise sources could very well be defined as system functions and tasks. And on the other side $limit is actually an analog filter function with $bound_step and $discontinuity in a kind of gray area.

As in LRM 2.3 we have provided system-function syntax to the mathematical operators $sin, $exp, etc, wouldn't it be better to extend this to the analog operators as well? That would allow us  to create a more logical grouping of system functions where limexp and $limit would be in one group, and analysis and $simparam would be in another group. The restrictions on analog operators could then be made specific to those system tasks and functions to which it applies - as is currently done for the analog kernel control system functions $limit, $bound_step and $discontinuity.

Would there be any clash with $analysis, $ddt, $idt, $idtmod, $ddx, $absdelay, $transition, $slew, $last_crossing, $limexp, $laplace_nd, $zi_nd, or any of the other Laplace and Z-domain functions?

Legacy code would be compatible using the same approach as proposed in LRM 2.3 - to use the `begin_keywords and `end_keywords compiler directives.

Cheers,
Marq


Marq Kole
Product Manager AMSRF Simulation
NXP Semiconductors / Corporate I&T / Design Technology & Flows


--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.