[Fwd: RE: my suggestions for Verilog-AMS extensions]

I might have forgotten to set our committee on CC ...

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

attached mail follows:

Hi Marc,

thanks, I had a look, you are right, point #2 is definitely solved!

I once read this, then forgot about it, because it was not implemented
in my Cadence flow at this time point and hence I did not practice.
But I heard Cadence has implemented something like this recently,
unfortunately I do not have their flow license available right now.

Achim

On Thu, 2011-02-17 at 15:38 +0100, Marq Kole wrote:
> Hi Achim,
>
> With respect to item #2 already since Verilog-AMS 2.2 there is the $port_connected system function that seems to do exactly as you suggest. Perhaps you could explain what is different in the $connected system function? Also what Cadence system function do you refer to?
>
> Cheers,
> Marq
>
> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Achim Bauer
> Sent: Thursday, February 17, 2011 3:27 PM
> To: Verilog-AMS LRM Committee
> Subject: 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.
>
>
Received on Thu Feb 17 07:34:37 2011