Re: analog operators as system functions

Marq,

In fact with $discontinuity and $bound_step - they used be part of 
analog functions syntactically (without the leading $) prior to LRM2.0 
(and limited exponential moved from being a analog function to system 
task - probably this should be classified as a filter function). So that 
explains the grey area with these particular system functions that you 
are talking about.

The main differentiating factor between the two was about retaining 
history (maintaining their internal state) for the analog filter 
functions and hence the associated semantic restrictions.

One positive side-effect of classifying them separately under 
analog_filter_functions rather than as system_task was that we described 
the syntax of these particular functions explicitly in the BNF. In P1364 
all the system tasks are mentioned as part of the chapters and there is 
no description of the syntax in the BNF and we took this same approach 
in LRM2.3.

Regards,
Sri



Marq Kole wrote:
> 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* <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.