my suggestions for Verilog-AMS extensions

Hi,

in the following I have shortly listed five desirable Verilog-AMS
enhancements, that I missed a lot as a long term user.

( we also planned to discuss about electrical to real-value/aggregate
connections in our next meeting, but unfortunately I did not found
enough time to prepare some initial thoughts for this.
I am sorry, but I think we might discuss this off the cuff too :)

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.

   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
   * 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
     e.g. like constraint : x > y/10; instead of + ( ( V(x) >
V(y)/10 )? 0 : 1M );
   * implicit (real-value) equations at both the analog and the digital
side
   * powerful solver algorithm, e.g. using randomized logarithmic start
vectors

2) SYSTEM FUNCTION $connected(<portname>)
=
   returns true if a pin is connected from externally, false if it is
open
   executed before elaboration, so it can be used already in parameter
section.
   usable within analog and digital code.

   why?
   ====
   smart sensitive interfaces for plug&play usage:
   library elements often shall be usable as-they-are, e.g. to build up
rapid prototypes or testbenches.
   e.g. enable- or supply-pins are not connected in the first instance
or a differential input is just
   contacted single-ended or a signal generator is not synchronized by
an external clock but via internal
   parametrization.

   example
   =======
   ...
   initial if ( $connected(en_i) ) enable = en_i; else enable = 1'b0;
   ...
   generate if ( ~ $connected(VSS) ) analog V(VSS,gnd) <+ 0;
endgenerate
   ...

   remarks
   =======
   * Cadence already offers a similar system function, hence
compatibility should be maintained

3) DYNAMIC ARRAY
=
   of scalars, of arrays, of structs...
   With VHDL-like attributes, e.g. LEFT, RIGHT, RANGE, LENGTH, LOW,
HIGH ...

   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, but in diverse
reuse/application scenarios the number of samples to be
measured/asserted might vary/scale over many orders of magnitude.

   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

4) OOMR READ AND WRITE OF INTEGER AND REAL VALUES
=
   why?
   ====
   modify/write/direct/control and observability of real values e.g.
from a remote testbench or correlated modules.

5) 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 mentionend.

   why?
   ====
   enables user-friendly, efficient (automated) application of
Verilog-AMS modules e.g. of
   o highZ/floating node checker around interface of a certain instance
   o voltage range assertion 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 !!!

Kind regards,
             Achim

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