[sv-dc] Notes from meeting on 2011-05-04

2011-05-04
----------
SV-DC Meeting Notes

Attendees:
n ----111111--11111 Jim Lear (Co-chair, Cirrus)
n -----11111-11-111 Achim Bauer (EXL-Modeling)
n --------111111111 John Havlicek (Freescale)
v 11111111111111111 Scott Little (Chair, Freescale)
n 1--111-------1111 Scott Cranston (Cadence)
v -11-1-11-1111111- Sundaram Sangameswaran (TI)
v -1111-11111111-11 Gord Vreugdenhil (Mentor)
n --1------1111-11- Top Lertpanyavit (Intel)
n ----------------1 Dana Fisman (Synopsys)
v 1-11--1-11--1-1-1 Ghassan Khoory (Synopsys)
n ----111-11111-1-- Ian Wilson (BDA)
n ----------------- Ken Bakalar (Mentor)
n ----11--1111-111- Kevin Cameron (obs)
v 111-111111-11-111 Arturo Salz (Synopsys)
v 1-11-1--1-------- Dave Cronauer (Synopsys)
n ----------------- Ed Cerny (Synopsys)
n ------------1--11 Tapan Halder (Synopsys)
v 1-111------------ Jonathan David (Qualcomm)
n ----------------- Jim Holmes (Lynguent)
n ----------------- Walter Hartong (Cadence)
v 11111111111-11111 Shekar Chetput (Cadence)
n -------11111111-- Martin O'Leary (Cadence)
v 1111111-----1---- Francoise Martinolle (Cadence)
n --------1--1----- Prabal Bhattacharya (Cadence)
v 11-1111.......... Abhi Kolpekwar (Cadence)
v 11111-1.......... Steven Sharp (Cadence)
n -1--1............ Kishore Karnane (Cadence)
n ----1............ Dave Miller (Freescale)
v 1111............. Jess Chen (Qualcomm)
v 11............... Mark Hartoog (Synopsys)
  |-> attendance on 2011-05-04
|---> voting eligibility on 2011-05-04

Agenda:
0. IEEE patent policy (http://standards.ieee.org/board/pat/pat-slideset.ppt)
1. Discussion of updated proposal for user-defined nets and resolution functions (Mantis 3398)
2. Discussion of Verilog-AMS feedback (http://www.eda-twiki.org/verilog-ams/hm/3238.html)
3. Discussion of SV-DC next steps. See the roadmap for additional guidance (http://bit.ly/apjS6s).
4. Opens

SS Motion to accept the IEEE patent policy as read. Second: AS
6y/0n/0a

*** Discussion of updates to proposal ***

AK: Added a line in 6.6.7 to create an additional name for the nettype.
 
SS: This creates two different names for a nettype.

AS: To be clear in one IP you have a full nettype declaration and in the other you just have name without the full declaration.

AK: The changes we have made are in dark brown text. In the examples we add an example of how the nettype renaming works. The next changes are in 23.3.3

SS: There was some concern from AMS of implicit conversions. This is what Gord foresaw. If both sides are nettypes of the same type they will collapse. If either of them is an atomic net then they have to be matching data types. We don't have backward compatibility problems because nettypes didn't exist before.

AK: The spirit is to keep it restrictive and then relax later when we know how conversion will be done.

SL: Do we have a consensus on Variant C?

SS: I believe that is the case, but we need to confirm with Gord. If you don't want collapsing you can just add a cast to get the continuous assignment semantics.

FM: What about renaming of built-in nettypes (wor, wand, etc.)?

AS: We haven't heard a requirement for this.

SS: It would be nice for completeness, but I think it opens other questions. The built-in nettypes were the inspiration for the nettype. We can look at it for follow-on.

AK: The note to the reader above the variants is wrong and should be updated on C.

AS: Can't we remove the other variants?

AK: I will e-mail Gord and then remove them if he agrees.

SS: Net aliasing. We need to look at the language features that may be affected by the nettype addition. There is a feature that allows you to take two different nets in the design and tie them together. I don't know why the alias is needed, so I don't know if it is needed for the SV-DC design style. It is already in the toolbox and it is trivial to add. Implementations have to already do the collapsing for inouts, so it shouldn't be hard.

SL: Go ahead and add it.

SS: It will require some text in the aliasing section. It will say that they must be the same nettype, etc. Also, need to consider $countdriver.

AS: My preference would be to provide a VPI routine.

SL: I would prefer to define $countdriver as not applying to atomic nets.

SCh: What about other places in the LRM might need changes?

SL: I had wondered about adding assertions to the resolution functions. It seems like deferred assertions would be the right thing to avoid spurious assertions for intermediate values.

SS: That won't work because the resolution function isn't within a process. The thing that calls the resolution function is a magic hidden thing as opposed to the things you see in regular SV. Deferred assertions are defined based on a process.

FM: Today you can write the assertions across nets why is this needed?

SL: It is a convenient way to check all wires of a specific type. Is it hard to add later if we don't define this up front?

AS: Yeah, I suspect it would.

SCh: One other thing I want to think about is filtering values. If a nettype has multiple values and you may want to filter what you define as a change. There could be performance issues associated with that.

AK: Is this appropriate for the standard?

SCr: Isn't that more efficiently done in the kernel than the user code?

SS: Yep.

FM: Do we need to add a line in the LRM regarding posedge/negedge?

MH: Why can't you do negedge if the data type allows it?

SS: I don't know if we need to define anything. Those rules are already defined for the types. The rules should already be defined for the type.

AK: I create a nettype foo with a real r. Can I wait on foo.r?

SS: Yes.

SL: What about foo?

SS: I don't think so. It would be still disallowed unless you use always_comb.

*** Verilog-AMS feedback ***

SL: We wanted to understand if we are doing anything that is going to complicate the merger work. I don't see anything along that line in the feedback.

SS: I agree. The concerns are more related to features they would like to see.

*** Discussion of SV-DC next steps ***

SS: My thought on the built-in wreal is it is nettype real wreal; b/c it doesn't have resolution. I don't see a reason to add that as a built-in.

FM: Are we supposed to do the VPI model for this?

SS: I think the CC appreciates it if the subgroup helps them. If there are things that are important to users in the data model the CC might not be aware.

FM: Do it as a separate proposal and add a mantis.

AS: Standard nettype in a standard package. We should come to some agreement. If there is demand for that.

SL: Voltage and current at a minimum would be nice.

FM: We don't know what the users will do. I am not sure we should add it to the standard package.

AS: I was thinking of a struct with a single real that carries a voltage and does voltage resolution. We could think of more. People in the AMS community have a bit more experience.

AS: If you support late binding you could emulate generic interconnect.

AK: I am not sure. Generic interconnect means no type. From my point of view providing generic interconnect and deferred binding are different. If you limit deferred binding to generic interconnect then I am fine with it.

SL: I would like to see tran gates with atomic nettype support.

AK: Generic interconnect then tran gates. If we get those in we would be in good shape.

FM: I think that the interconnect is our highest priority at the moment.

SL: I will send out a list of potential enhancements for folks to vote. I think it is important to know who will do the work. In your vote please also list if you are willing to do a proposal for a specific item.

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