RE: my suggestions for Verilog-AMS extensions

Hi Achim:

One additional point to what Dave mentions here for 3. SystemVerilog has dynamic arrays and queues. Queues have the various functions you are requesting (insert, delete, size, push_front, pop_front, push_back, pop_back). I would expect these would be available after the SV/VAMS merge.

Thanks,
Scott

> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> Behalf Of Miller Dave-A17239
> Sent: Thursday, February 17, 2011 10:23 AM
> To: Achim Bauer
> Cc: Verilog-AMS LRM Committee
> Subject: Re: my suggestions for Verilog-AMS extensions
>
> Hello Achim,
> 1. I don't quite understand what you are asking here, seems we already
> support
> this, but I may be totally missing the point?
>
> 2. Already in LRM for quite a while- $port_connected (9.19)
>
> 3. We do allow parameters in ranges which gives some flexibility but
> yes,
> having a truly dynamic vector may have uses. Certainly something we can
> discuss.
>
> 4. We allow OOMR read of analog variables and quantities (branch probes
> etc.).
> We disallow OOMR write of analog variables. We had issues of how it was
> to
> behave (when is it updated, can read OOMR assignments propagate partial
> dependencies? Since we couldn't resolve these issues, assignment to
> OOMR's was
> disallowed.
>
> 5. bind is part of System Verilog, hence it will be merged into the
> language by
> default. I don't think we want to start taking bits of the SV language
> and
> merging them in separately unless there is a really good case for it
> (like ASVA
> for example).
>
> Anyway we can discuss all these points. I lodged this into Mantis for
> you as
> Mantis item: 3392
>
> cheers...
> Dave
>
> On 02/17/2011 08:27 AM, Achim Bauer wrote:
> > 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
> >
> >
>
> --
> ==============================================
> -- 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.