Re: Proposal for two additional environment parameter functions

I am still to write up the minutes which I hope to get to today, but just to 
summarize this discussion from the meeting last week.
It was not the intention of $freq to change the matrix stamp. The matrix would 
still be based on the op values. $freq was intended as a debug function. If a 
module had that then the simulator would solve that instance for every 
frequency point (even though that solve would not impact the matrix).
We decided at this point, that we would not implement $freq in the LRM for 2.3. 
For now, simulators can implement this as an extension if they so choose.

We will however, modify noise_table() to take a filename argument. If the first 
arg to noise table is a string, then it is the name of a file that contains the 
  freq / pwr pairs.

This resolves the designer related issue that caused me to propose $freq.

Cheers...
Dave


Marq Kole wrote:
> All,
> 
> I've had a similar discussion last year on another forum with the usual 
> suspects :-) http://www.designers-guide.org/Forum/YaBB.pl?num=1156512831/0
> 
> The only safe use of a $freq system function seems to be as part of the 
> printing API ($write, $fwrite, $debug, etc.) as all other uses would 
> essentially enter the problematic field of automatically translating 
> frequency-domain models to time-domain. In that sense a % code might be 
> more appropriate than a system function.
> 
> Marq
> 
> Inactive hide details for David Miller 
> <David.L.Miller@freescale.com>David Miller <David.L.Miller@freescale.com>
> 
> 
>       *David Miller <David.L.Miller@freescale.com>*
> 
>       Sent by:
>       owner-verilog-ams@server.eda.org
> 
>       13-07-2007 16:36
> 
> 	
> 
> To
> 	
> "Geoffrey.Coram" <geoffrey.coram@analog.com>
> 
> cc
> 	
> Verilog-AMS LRM Committee <verilog-ams@server.eda.org>
> 
> Subject
> 	
> Re: Proposal for two additional environment parameter functions
> 
> Classification
> 	
> 
> 	
> 
> 
> Hi Geoffrey,
> Yes I understand for an ac, the circuit is linearized around the op 
> point. I
> never (at this stage at least) intended for $freq to cause G and C to be
> recomputed.
> I have supported $freq for many years and it is mainly a debug function 
> (It is
> helpful when used in conjunction with $debug()). I also use it in noise
> analysis, where we can have frequency dependent elements. It has proven 
> helpful
> to designers when debugging model problems. I can detect models that are
> dependent on frequency to ensure that they are solved each point (even 
> if that
> solve doesn't modify the jacobian).
> 
> Recently a model developer asked me how to load noise freq/pwr pairs 
> from a file.
> One solution is that you use $fscanf to load the values from the file 
> into an
> array and then use noise_table(). However this is inefficient as you 
> need to
> know how many elements are listed in the file so that your Verilog-A 
> array is
> the correct size.
> 
> So the other way was to use $table_model() and $freq. This could do the
> interpolation of the freq/pwr pairs, and then you could use 
> white_noise() to
> load that pwr value.
> This worked beautifully, it allows you to have all the benefits of the
> $table_model interpolation/extrapolation algorithms (not just clamping 
> at the
> bounds).
> However it is breaking the definition of white_noise() since now my pwr 
> value
> is frequency dependent.
> 
> A couple of ways to solve this:
> 1. Extend noise_table() and overload the first arg such that if it is a 
> string
> then it represents a file name which contains the freq/pwr pairs.
> 
> 2. Add $freq, and a new function 'colored_noise(pwr)' and use 
> $table_model to
> do the interpolation.
> 
> I prefer 2. as I am not keen on overloading arguments to be different 
> types.
> But I was still working through some of the finer points of the 
> colored_noise()
> function, so wasn't quite ready to propose it. But I thought $freq was 
> fairly
> simple, so thought I would send it through now for people to critique.
> 
> Cheers...
> Dave
> 
> Geoffrey.Coram wrote:
>  > Arpad -
>  > $abstime works OK in a transient analysis, because the full model is
>  > evaluated
>  > at each timepoint.
>  >
>  > Spice's ac analysis is a different sort of animal: the operating point is
>  > computed, and then *the circuit is linearized about that op-pt*.  
>  > Generally,
>  > this means that the model is evaluated during the op-pt and all the
>  > derivatives
>  > are stored off.  Then, for each point in the ac analysis, the
>  > derivatives are
>  > used to compute J = G + j w C, where G=conductances and C=capacitances
>  > (derivatives of contributions involving ddt()); G and C are *not*
>  > re-computed
>  > at the new frequency, because Spice assumes that they only depend on the
>  > v-vector (the operating point).
>  >
>  > I agree with David (from Tiburon) about the hazards of $freq expressions
>  > for models that are supposed to work in transient, HB, etc.
>  >
>  > -Geoffrey
>  >
>  >
>  > Muranyi, Arpad wrote:
>  >> Geoffrey,
>  >>
>  >> I don't understand the reason for why the IF statement
>  >> wouldn't get evaluated during the AC sweep.   Could
>  >> you please explain that to me?
>  >>
>  >> If we had this in the language, I would expect it to
>  >> work the same as $abstime.  Doesn't $abstime=0 in the
>  >> operating point analysis and greater than zero
>  >> thereafter?  If I remember correctly, I was able to
>  >> use if($abstime ...) before.  Why couldn't $freq do
>  >> the same?
>  >>
>  >> Thanks,
>  >>
>  >> Arpad
>  >
> 
> -- 
> =====================================
> -- David Miller
> -- Design Technology (Austin)
> -- Freescale Semiconductor
> -- Ph : 512 996-7377 Fax: x7755
> =====================================
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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.
> 

-- 
=====================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
=====================================

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