Re: Wreal/User defined types on wires

Hi Marq, All,

Regarding Accellera Policies and Procedures. There is a section on
donations also as part of this document.

http://www.accellera.org/activities/Accellera_TC_Policies_Procedures_V2_2.pdf

Regards,
Sri

On 3/19/2010 2:29 AM, Marq Kole wrote:
> All,
>
> In general I have a hard time finding any documents on the Accellera
> website pertaining to the donation procedure. Is anyone able to point me
> (and perhaps others in the committee) to the applicable "governing rules"?
>
> Cheers,
>
> Marq
>
> *From:* owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] *On
> Behalf Of *Martin O'Leary
> *Sent:* Thursday 18 March 2010 21:49
> *To:* Ian Wilson
> *Cc:* Verilog-AMS LRM Committee
> *Subject:* RE: Wreal/User defined types on wires
>
> Ian,
>
> good question. My understanding is that accepting the donation puts no
> such constraints on the committee.
>
> Thanks,
>
> --Martin
>
> ------------------------------------------------------------------------
>
> *From:* Ian Wilson [mailto:ian.wilson@berkeley-da.com]
> *Sent:* Thursday, March 18, 2010 1:42 PM
> *To:* Martin O'Leary
> *Cc:* Verilog-AMS LRM Committee
> *Subject:* Re: Wreal/User defined types on wires
>
> Agreed - this is an interesting and timely discussion.
>
> Although accepting the donation does not make it into a standard, isn't
> there some sort of
> moratorium that would come into effect on standards work in the same
> area if the donation
> is accepted?
>
> --ian
>
> ----------------------------------
>
> Ian M Wilson
>
> Architect
>
> Berkeley Design Automation
>
> Office: 408-496-6600 x238
>
> Cell: 714-272-7040
>
> ian.wilson@berkeley-da.com <mailto:ian.wilson@berkeley-da.com>
>
> http://www.berkeley-da.com
>
> ----------------------------------
>
> True SPICE accuracy, 5X-20X faster
>
> Don't Be Left Behind!
>
> ----------------------------------
>
>
>
>
>
> Martin O'Leary wrote:
>
> Kevin, Marq, Shalom,
>
> interesting discussion. I agree that going forward, the Verilog-AMS wreal concept needs to be made more generic and scalable perhaps along the lines that you say.
>
>
>
> The challenge will be to make sure this fits with the SystemVerilog net/data-type schema as well as having backward compatibility with existing Verilog-AMS.
>
>
>
> I look forward to further discussions and brainstorming on this topic in the committee. I believe we can work out a way to do this.
>
>
>
> The Cadence donation can be useful during this discussion as it is pertains to real user issues that need to be considered. Remember that the group is not voting to accept the Cadence donation as a standard, but basically accepting a license from Cadence to the various materials. It can be subsequently be used in whatever manner the committee sees fit.
>
>
>
> Thanks,
>
> --Martin
>
>
>
>
>
> -----Original Message-----
>
> From:owner-verilog-ams@eda.org <mailto:owner-verilog-ams@eda.org> [mailto:owner-verilog-ams@eda.org] On Behalf Of Kevin Cameron
>
> Sent: Friday, March 12, 2010 4:21 PM
>
> To: Marq Kole
>
> Cc: Verilog-AMS LRM Committee
>
> Subject: Re: Wreal/User defined types on wires
>
>
>
>
>
> It's easy to map a single-valued item onto a two-valued item it's the reverse that's hard - i.e. the wreal use just maps directly to potential (you can ignore flow). As I understand it: current wreal usage is discrete and doesn't go to the analog solver.
>
>
>
> Resolution can be done across disparate types, the extra functionality required is type-conversion functions - i.e. you type convert the drivers to the same accuracy/domain then resolve. Access functions are just a short hand for specifying that you are dealing with potential or flow (rather than logic value), it is not necessary that items treated as potential/flow actually go to a solver, that is only required if they are involved in a continuous equation with other conservative values.
>
>
>
> The (SV) class system usage is for a generalized scheme with resolution functions, not just wreal, specifically it supports the RF type modeling that Jonathon is requesting. There's no point in doing a wreal hack if you need to support the general case anyway.
>
>
>
> The discipline information was originally intended as a technology typing scheme, not a driver/receiver typing scheme, driver receiver typing (analog, digital etc.) can usually be determined from context.
>
> Since these are orthogonal concepts it's a bad idea to conflate them.
>
>
>
> Kev.
>
>
>
> On 03/11/2010 01:47 PM, Marq Kole wrote:
>
>
>
> 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> [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* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

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