Re: our suggestions for Verilog-AMS extensions

From: Dave Miller <David.L.Miller@freescale.com>
Date: Mon Feb 21 2011 - 10:37:00 PST

The next call is scheduled for 3rd March. I try to keep the webpage updated now
days so you can find the call information:

http://www.eda.org/twiki/bin/view.cgi/VerilogAMS

Cheers...
Dave

On 02/21/2011 12:32 PM, Morrison, Scott wrote:
> Hi there,
>
> When is the next scheduled Verilog-AMS call?
>
> Thanks,
> Scott Morrison
>
>
> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Achim Bauer
> Sent: Saturday, February 19, 2011 5:53 PM
> To: Verilog-AMS LRM Committee
> Subject: our suggestions for Verilog-AMS extensions
>
> Hi,
>
> I have updated the document and included your remarks/suggestions.
> Marq, Xavier, David, Jonathan, Scott, Kevin, thanks for your tips!
> Perhaps we can discuss the document on our next meeting?
>
> Hope I can also add a few thoughts on electrical<to> real connect
> modules by then.
>
> Kind regards,
> Achim
>
>
>
> 1) EVENT-DRIVEN SOLVER FOR IMPLICIT NON-LINEAR EQUATION SYSTEMS
> =
> e.g. initially or triggered during ongoing simulation
>
> why?
> ====
> practical spec-like parametrization
> often a typical set of high-level parameters has to be mapped to an
> internal representation
> and the underlying equation system for this can not be solved
> explicitly.
> the existing specification is for electrical signals and performed
> CONTINUOUSLY (evtl. degrading speed).
> Its solution can not be used for initial parametrization.
>
> example
> =======
> ...
> @(initial_step("dc","tran")) begin
> // non-linear equation, e.g. system with transcendental functions, to
> be solved numerically:
> V(x) : V(x) == V(x) + ... ln(f1(x,y),n) ... pow(f2(x,y)) ... ;
> V(y) : V(y) == V(y) + ... sin(f3(x,y),n) ... exp(f4(x,y)) ... ;
> end
> // desirable e.g. according to Scott Morrison
> V(op,on)<+ gain * laplace_zp( V(ip,in), , { -x,0, -y,0 } );
> ...
>
> further suggestions
> ===================
> * also solved for real variables, not only electrical with access
> operator,
> tolerances have to be specified, e.g. like x ~ 1e-4 : 0 == ...
> * the syntax for specifying the equation system might be simplified
> e.g. like V(x) : 0 == ... instead of V(x) : V(x) == V(x) + ...
> * it should be possible to constrain/guide/initialize the solver in a
> clearly readable way
> e.g. like constraint : x> y/10; instead of + ( ( V(x)>
> V(y)/10 )? 0 : 1M );
> * implicit (real-value) equations usable at both the analog and/or
> the digital side, because the requirement to map high-level to low-level
> parameters can also arise for discrete (real-value) models.
> * powerful solver algorithm, e.g. using randomized logarithmic start
> vectors
> (but this is an implementation detail of the solver)
>
>
> 2) dynamic array (of scalars, of arrays, of structs...)
> =
> with VHDL-like attributes, e.g. LEFT, RIGHT, RANGE, LENGTH, LOW,
> HIGH ... or better
> with SV functions like insert, delete, size, push_front, pop_front,
> push_back, pop_back
>
> why?
> ====
> to measure an unknown number of samples,
> e.g. for asserting a rolling average or for extracting statistical
> data.
> currently: wasting memory, (simulation) performance and the users
> time:
> a worst case parameter has to be set for the width of a parametrized
> array,
> but in diverse reuse/application scenarios the number of samples to
> be
> measured/asserted might vary/scale over many orders of magnitude.
> Another workaround is using (slow) fileIO commands.
>
> example
> =======
> ...
> real y_array [1:+]; real t_array [1:+];
> ...
> if ( sampling ) begin
> sample = y_array'RIGHT + 1;
> y_array[sample] = Vprobe;
> t_array[sample] = $abstime;
> end //if
> ...
> samples = y_array'LENGTH;
> ...
>
> further suggestions
> ===================
> pointers as dynamic array of structs ?
> as a powerful extension of 3), to handle/process more complex data
> aggregates or structs.
> 2) is a SV/VAMS MERGER ISSUE, since existing SV data types /
> functions shall be made usable
> for the analog side
>
>
> 3) oomr read&write for logic, real, electrical
> =
> why?
> ====
> modify/write/direct/control real values, observability within remote
> testbench
>
> further suggestions
> ===================
> real values on the analog side might be updated in sync with the
> write event on the discrete side (similar to D2A update in connect
> module).
>
>
> 4) bind
> =
> SystemVerilog-like bind/generate,
> assigns/instantiates e.g. signal generators and measurement units to
> particular scopes
> of instances, modules, hierarchy levels, port directions,
> pin-naming-patterns
> or combinations (AND OR NOT...) of the mentioned.
>
> why?
> ====
> enables user-friendly, efficient (automated) application of
> Verilog-AMS modules e.g. of
> o highZ/floating node checker (ASVA) around interface of a certain
> instance
> Jonathan and Geoffrey confirmed practical importance.
> o voltage range assertion (ASVA) at all nets with a "_1V2" pattern
> o noise injection at a specific scope/node set ...
>
> example
> =======
> I am using a fictive "oomr"/SV-style binding here,
> that names a common (parent) path for all the particular signals that
> are then
> branching away with their specific hierarchical sub-paths in the
> mapping list:
> bind<scope_specification> <module_to_be_bound> <instance_name>
> (<mapping>);
> examples for scope specifications:
> tb.dut+3; // the top three hierarchy levels in the instance dut of
> the testbench tb
> module bp_filter; // cell based
> pattern VDD_?V?; // all ports or nets that contain this pattern,
> e.g. AVDD_1V2
> instances I1 I2 I3 // instance based
> ports outputs
> ...
> bind tb.dut+4 AND ports AND NOT pattern *_tri_* highZ I_highZ_
> (.sensor(scope), .ctrl(tb.assertions.assert_highZ.trigger),
> .result(tb.assertions.assert_highZ.result_));
> ...
>
> remarks
> =======
> of course the above example is at best an initial idea,
> I have not thought all too much about that topic yet,
> there is plenty to brainstorm and discuss for us !!!
>
>
>
>

-- 
==============================================
-- 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.
Received on Mon Feb 21 10:37:28 2011

This archive was generated by hypermail 2.1.8 : Mon Feb 21 2011 - 10:37:28 PST