RE: our suggestions for Verilog-AMS extensions

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 !!!

-- 
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.