Re: Vector arguments

Hi,

I can only confirm this from my experience.
The current implementations with constant parameters are a severe practical
restriction !

E.g.:
* when you want to model a trimable / variable filter you have to do this by
implementing a lumped version of it.
* when you want to derive a Laplace parameter array from typical spec params
(e.g. gain, GBW, phase margin)
   you often have to perform an (initial) computation to determine them, so
the parameters can not be constant
   in that case.

thanks,
          Achim

----- Original Message -----
From: "Morrison, Scott" <scott@ti.com>
To: "Dave Miller" <David.L.Miller@freescale.com>
Cc: "Paul Floyd" <Paul_Floyd@mentor.com>; <verilog-ams@eda.org>; "White,
Andrew" <a-white@ti.com>; "Wiltshire, Dave" <dave.wiltshire@ti.com>
Sent: Tuesday, February 08, 2011 5:00 PM
Subject: RE: Vector arguments

> Dave,
>
> Thank you very much. If this enhancement is possible it will be
> beneficial, in my opinion, to give flexibility in coding more compactly as
> I mentioned below.
>
> Thanks,
> Scott
>
>
> -----Original Message-----
> From: Dave Miller [mailto:David.L.Miller@freescale.com]
> Sent: Tuesday, February 08, 2011 9:50 AM
> To: Morrison, Scott
> Cc: Paul Floyd; verilog-ams@eda.org; White, Andrew; Wiltshire, Dave
> Subject: Re: Vector arguments
>
> Hello Scott,
> I will lodge this as an enhancement to look at. I believe originally when
> we
> stamped these filters, they had to be constant.
> That is not necessarily the case now, so this restriction may be able to
> be
> removed.
>
> Regards
> Dave
>
>
> On 02/08/2011 08:26 AM, Morrison, Scott wrote:
>> Hi VAMS committee,
>>
>> On a similar subject as Paul has mentioned, is it possible to upgrade the
>> analog operators such as Laplace filters to take a truly dynamic argument
>> that will re-evaluate after time zero? I have had a need several times of
>> the last 2 years to have dynamically calculated Laplace arguments that
>> change throughout time, but obviously the Laplace filters currently only
>> latch the start value and ignore future updates to their dynamic
>> arguments.
>>
>> Given the limitation above I usually find some other (more complicated)
>> way to code a "dynamic filter" such as having multiple parallel filters
>> and some mechanism for muxing between then, but obviously this is
>> computationally-unfriendly and memory-unfriendly.
>>
>> Thanks,
>> Scott Morrison
>> Texas Instruments
>>
>>
>>
>>
>> -----Original Message-----
>> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
>> Behalf Of Paul Floyd
>> Sent: Tuesday, February 08, 2011 3:54 AM
>> To: verilog-ams@eda.org
>> Subject: Vector arguments
>>
>> Hi
>>
>> Section 4.5.1 says
>>
>> "4.5.1 Vector or array arguments to analog operators
>> Certain analog operators require arrays or vectors to be passed as
>> arguments: Laplace filters, Z-transform filters,
>> and noise_table(). An array can either be passed as an array_identifier
>> (array parameter) or an
>> array assignment pattern using a constant_optional_arrayinit (Laplace
>> filters, Z-transform filters) or a
>> constant_arrayinit (noise_table())."
>>
>> Then 4.5.14 says
>>
>> "If a dynamic expression is passed as an argument which expects a
>> constant expression, the value of the
>> dynamic expression at the start of the analysis defaults to the constant
>> value of the argument. Any further
>> change in value of that expression is ignored during the iterative
>> analysis."
>>
>> This seems to be a conflict. The first says that Laplace/Zi can only
>> take an array parameter or a constant_optional_array_init. The second
>> says that a dynamic expressions are allowed.
>>
>> In 9.20, $table_model can take a "table_model_array". The example given
>> uses a vector variable. [Does this mean that the table can change during
>> simulation?]
>>
>> My view is that all three of these cases should be consistent (well,
>> almost). Dynamic vectors should be allowed, with changes after the start
>> of the analysis ignored. I said almost because Laplace/Zi don't have a
>> filename option, and I see no need for one either.
>>
>> While I'm on the subject of Table 4-20 and section 4.5.14, in version
>> 2.2 of the LRM, the equivalent of Table 4-20 included monitored event
>> statements (timer, above, cross). These have been removed in version
>> 2.3[.1] of the LRM (fair enough, they are in Chapter 5). The BNF syntax
>> gives the monitored events "constant_expression_or_null" arguments. I
>> can't see anywhere that it's stated that these arguments can be
>> variables but treated as constants using their first values. I imagine
>> that there was no intent to change this rule.
>>
>> Honestly my last word on Table 4-20. The laplace_xy Constant expression
>> arguments are given as "poles, abstol, zero". "zeros, poles, abstol"
>> would be more consistent with the zi_xy entry.
>>
>> Regards
>> Paul Floyd
>
> --
> ==============================================
> -- It's a beautiful day
> -- Don't let it get away
> --
> -- 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, and is
believed to be clean.