RE: analog operators as system functions

Hi Sri,

The maintenance of internal state is actually a requirement to be able to implement these functions. My main objection is the inconsistency by which $limit is not an analog filter function where it should be one (it also needs to retain history). Similarly, the analysis analog operator should become normal a normal system function as it does not need to maintain internal state for its correct functioning. The small-signal sources ac_stim, white_noise, flicker_noise, and noise_table do not have the limitations imposed on the analog filter functions so I would suggest that these become system functions as well.

Your argument on the BNF is just a choice in documentation and does not influence the semantics of these language elements. Apparently, P1364 has chosen to express the limitations on the inputs of system functions and tasks only in the chapter describing them and not in the BNF. I cannot imagine a language user that would check the BNF instead of the chapter on analog behavior when looking for the use and definition of an analog filter function. I do not see the difference considering the definition of the language.

So if we consider the maintenance of internal state the distinguishing feature, I would still like to rationalize the current selection of analog operators and those of system functions:
	$limit		--> limit
	analysis		--> $analysis
	ac_stim		--> $ac_stim
	white_noise		--> $white_noise
	flicker_noise	--> $flicker_noise
	noise_table		--> $noise_table

Cheers,
Marq


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

-----Original Message-----
From: Sri Chandra [mailto:sri.chandra@freescale.com] 
Sent: Friday 11 September 2009 5:41
To: Marq Kole
Cc: verilog-ams@server.eda.org
Subject: 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.