Re: Verilog-AMS Committee Meeting Minutes - 14th Mar 2011

I'm not sure how wreal (as is) will go down with the IEEE given that there are some patent issues. However, I did propose an alternative which probably works with respect to modeling primitives -

http://www.eda.org/sv-dc/hm/0288.html

- if you consider the value of the signal being propagated as separate from the strength and the certainty of the signal (what I call a 3-D signal model), then because propagation is purely on strength and strength reduction is already defined then the various primitives work as expected in an all "wreal" scenario.

The issue is more how to define the behavior of a primitive (like nmos) where one side is "logic" and the other side is "wreal", on either end you have the possibility of having to resolve logic with wreal. That's where it's useful to have discipline information and to be able to convert the wreal and logic drivers up to some other level to work out how to do the resolution. In Verilog-AMS the common level for resolution is the analog solver, i.e. the drivers of a net are converted to analog contributions with D2As, for SV-DC it is necessary to find lower-accuracy (discrete) levels to convert the drivers to in order to perform resolution, and to provide mechanisms for users to define how that works.

The current proposal seems to have much more to do with syntax than semantics and simulation/verification methodology, and falls far short of solving the problem above. However, solving that problem is just a more general case of what has already been done in Verilog-AMS, so it at this point it shouldn't be too hard to come up with some syntax and simulation semantics that actually work.

Kev.

On 04/15/2011 12:53 PM, Dave Miller wrote:
> Meeting - Thursday 14th March 2011
>
> Attendees:
> ============
> Gordon Vreugdenhil (Mentor)
> Achim Bauer (EXL Modeling)
> Marq Kole (NXP)
> Ian Wilson (BDA)
> Shalom Bresticker (Intel)
> Ken Bakalar (Mentor)
> Scott Little (Freescale)
> Abhijeet Kolpekwar (Cadence)
> Martin O'Leary (Cadence)
> Dave Miller (Freescale)
>
> * User Defined Nettype
> Gordon presented the SV-DC proposal for defining user defined nets within SV
> http://www.eda.org/twiki/pub/VerilogAMS/AmsDiscussionDoc/UserNettypes_v3.pdf
>
> The SV-DC committee is looking at the implementation of real values modeling within SystemVerilog.
> The SV-DC group is not part of Verilog-AMS/Accellera. They are a working group within P1800.
> They are not implementing or merging sections of Verilog-AMS into SV. However since the real valued modeling is also part of the Verilog-AMS standard (wreal) we agreed that it would be a good idea for the Verilog-AMs committee to look over the proposal to make sure that it doesn't introduce any potential conflicts (keywords, contructs, etc.) that might impact the Verilog-AMS/SV merge.
>
> During the development of the proposal, the SV-DC group have kept in mind the wreal construct used within Verilog-AMS to ensure that what they propose will be able to support existing wreal functionality.
>
> Gordan noted that the interaction of user defined nets with the primitives, especially the switchtype (nmos, pmos) still needs to be resolved.
> Ken pointed out that this will be one area that may have an impact on AMS.
>
> The Verilog-AMS group is encourage to review the proposal over the next week or so to see if there are any conflicts which might cause us problems. We can then feed those back into the SV-DC group.
>
> The SV-DC group is expecting to be able to vote on this proposal by the end of next month. This proposal is currently on track to be included in the current P1800 par.
>
> Next call scheduled for Thurs 28th Apr.
>
> San Francisco, Thurs 06.00a
> Austin, 08.00a
> Boston, 09.00a
> Amsterdam, 03.00p
> Tel Aviv, 04.00p
> New Delhi, 06:30p
> Adelaide, 10:30p
>
> Call-In Details:
> USA Toll Free : 8008671147
> Australia Toll Free: 1800009128
> India Toll Free : 0008006501482
> Netherlands : 08002658223
> Passcode: 0970751#
>

-- 
http://www.grfx.com
mailto:dkc@grfx.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.