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.