RE: Wreal/User defined types on wires

Hi Kevin,

Interesting proposal, but I do not see how you would map a single real value on a conservative system with both voltage and current. It would work fine with a signal-flow system but you really do need two independent real values for electrical.

In general I would say that resolution functions and access functions are incompatible: if you use access functions the resolution is provided by the analog solver; if you don't use an analog solver you need a resolution function to handle multiple drivers on a net. You can't have both as the resolution function provides only a local solution to the system of equations instead of a global one required by the analog hardware.

My proposal would rather be to tie the handling of wreal to the discipline system that is already in Verilog-AMS instead of the class system that is currently only in SV.

discipline wreal
  domain ddiscrete;
  net_type real;
  net_resolution default;
enddiscipline

This can be implemented without much ado in existing Verilog-AMS tools without the need to get the whole class system of SystemVerilog on board.

Cheers,
Marq

NXP Semiconductors

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Kevin Cameron
Sent: Thursday 11 March 2010 21:24
To: Verilog-AMS LRM Committee
Subject: Wreal/User defined types on wires

Just a note on how I would suggest doing user-defined wire types (in
AMS/SV).

Syntax wise I'd suggest just doing -

    wire <type> <wires>;

Where <type> can be either a built-in type (e.g. real) or a struct or
class. Built-in/struct types can be used for non-resolved copy-through.

Since SV has typedef you can put a declaration like -

    typedef wire real wreal;

- in a standard header, and the semantics would be as current AMS for
wreal declarations in user code.

If you need resolved type then you can use a class definition, and add
the resolution function to the class. For AMS compatibility and
plug&play/polymorphism I would also suggest recognizing flow/potential
functions in the class for use with discipline access functions e.g.:

  class my_res_real;
    real r;
    function real resolver (real []); // takes array of driver values
      ....
      return x;
    endfunction
    function real potential;
      return r;
    endfunction
    ...
    // copy constructors etc. here
    ...
  endclass

  typedef wire my_res_real wreal; // use instead of standard definition

In the code you could then say -

  module ...
    wreal wr;
    electrical wr; // sets access functions

    always @...
      if (V(wr) > 2.0) begin // V() -> potential method of class
        ...

With this kind of scheme you have backward compatibility (if you want it) and as much flexibility for real value usage as anyone is currently asking for, and the methodology extends to other uses (like RF signal modeling).

Kev.

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