[sv-dc] Notes from meeting on 2011-06-01

2011-06-01
----------
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 1111111111111111111 Scott Little (Chair, Freescale)
v 1111-111-------1111 Scott Cranston (Cadence)
v 11111-1-11-1111111- Sundaram Sangameswaran (TI)
v 11-1111-11111111-11 Gord Vreugdenhil (Mentor)
n ----1------1111-11- Top Lertpanyavit (Intel)
n ------------------1 Dana Fisman (Synopsys)
n 1-1-11--1-11--1-1-1 Ghassan Khoory (Synopsys)
y 11----111-11111-1-- Ian Wilson (Accellera/BDA)
n ------------------- Ken Bakalar (Mentor)
n ------11--1111-111- Kevin Cameron (obs)
v 11111-111111-11-111 Arturo Salz (Synopsys)
v 111-11-1--1-------- Dave Cronauer (Synopsys)
n ------------------- Ed Cerny (Synopsys)
n --------------1--11 Tapan Halder (Synopsys)
v 111-111------------ Jonathan David (Qualcomm)
n ------------------- Jim Holmes (Lynguent)
n ------------------- Walter Hartong (Cadence)
v 1111111111111-11111 Shekar Chetput (Cadence)
n ---------11111111-- Martin O'Leary (Cadence)
v 111111111-----1---- Francoise Martinolle (Cadence)
n ----------1--1----- Prabal Bhattacharya (Cadence)
v 1111-1111.......... Abhi Kolpekwar (Cadence)
v -111111-1.......... Steven Sharp (Cadence)
v 11-1--1............ Kishore Karnane (Cadence)
n -1----1............ Dave Miller (Freescale)
v -11111............. Jess Chen (Qualcomm)
v 1111............... Mark Hartoog (Synopsys)
  |-> attendance on 2011-06-01
|---> voting eligibility on 2011-06-01

Upcoming dates to note:
2011-06-15 - SV-DC meeting
2011-06-29 - SV-DC meeting
2011-07-13 - SV-DC meeting
2011-07-27 - SV-DC meeting
2011-08-10 - SV-DC meeting
2011-08-24 - SV-DC meeting
2011-09-07 - SV-DC meeting
2011-09-21 - SV-DC meeting
2011-10-01 - P1800 TC work ends

Agenda:
0. IEEE patent policy (http://standards.ieee.org/board/pat/pat-slideset.ppt)
1. Results of e-mail vote on mantis 3398 (http://www.eda-twiki.org/svdb/view.php?id=3398)
2. Discussion of generic interconnect
3. Opens

MH: Motion to approve the patent policy as if read.
GV: Second

SL: Mantis 3398 passed via an e-mail vote.

FM: I found a few typos and simple modifications to the nettype proposal. How do you want to handle these fixes?

SL: Please correct them prior to the next meeting and send out a changeset. We can do a voice vote in the next meeting. [Note: assuming we vote on this issue in the meeting on 2011-06-15 it will get into the next Champion's vote]

SL: We can now move on to a discussion of generic interconnect. Gord, can you begin?

GV: See my e-mail to the reflector. I would like to see a distinction between a topological connection point and the port. It behaves like a net except it doesn't have a type associated with it. It is meant to describe pure interconnect. Should be able to declare and use in port connections and that is it. There are a few rules that I give about how these can be used. Initially we should require that they collapse. This makes a bunch of the rules relating to their end behavior simpler.

Interconnects go away and if the actual types are correct then everything will be fine. I think that everything works out if we require collapsing of interconnect.

This is a minimal set of things that allows people to do what they want. It should allow people to switch out models with various levels of abstraction without having to insert models in between to do port conversion work. That is the basic idea. I don't think this is a terribly complicated thing if we keep it down to this minimal set of capabilities.

AK: Can you elaborate on the type conversion?

GV: We haven't talked about type conversion yet. Eventually we will want to talk about type conversion or how to convert between dissimilar items. That is in the future. Right now there are strong rules that prevent that. I am somewhat optimistic that adding a basic for of generic interconnect won't cause problems. They are typeless, so it shouldn't impact decisions about where you do nettype conversions.

AK: It depends on how we design the type conversion, but if you have typeless interconnect that will affect it.

GV: The way it is defined things are collapsed, so it shouldn't cause a difference.

ShC: If you have several levels of hierarchy does it work top down or bottom up? What about the error message?

GV: It shouldn't matter. The error message may be different.

ShC: Right now in VAMS electrical is dominating. Could user-defined netttypes also be dominating over others?

GV: That could be defined. Right now those sorts of things aren't defined.

FM: Can you also declare a port of the child to be an interconnect?

GV: Yes.

AK: If you have an interconnect port of a given direction can it have a direction?

GV: Why does it matter? If it is going to force a collapse why does it matter?

SC: When you say it must collapse it means that the two ports must collapse. Do we want that?

GV: I think we do because it simplifies the rules. It may not be as flexible as we want long term, but I don't thinks it causes a problem.

AK: This is going to be restrictive from a user's perspective.

GV: I agree. This is a minimal set of functionality. If you want to connect a var port to a port using generic interconnect then you may need to wrap it. If we want to go further then some effort will be required to define the rules. I prefer to leave that for now if not for this entire PAR. Let's leave it as a clean set of rules and then come back when we know more unless we believe it is too deficient.

AS: In your example would it be sufficient to say that i1 and i2 use a specific configuration?

GV: You don't talk about configuring the interconnect. Assume configurations aren't in play. Somewhere in your library you have definitions for child1, child2, and child3. The code is either legal or not. If you have a configuration you can change the models. This gives you the advantage to change the models as long as the types remain consistent.

FM: On the top module there isn't really any debugging capability?

GV: Within the HDL, no. Within the tool it depends.

FM: If the user wants to have some code that makes sure everything happens correctly there is nothing they can do. It has to be put into the children.

GV: Correct. You can put the debug capability in a module and then bind it in. Then you would get an error if the ports aren't what you expect.

AK: Can we go over my e-mail questions?

GV: "1. Can the interconnects be probed/accessed for value and type information?" This is related to this debug question. My perspective is no. I don't want to have any implementation knowledge about the type within the HDL. I want to be able to reason and compile a module without any knowledge of the type. Of course, a vendor tool can expose all sorts of information.

AK: In current SV is there a concept of net properties or metadata that can be associated with a net?

GV: There are attributes.

AK: Can interconnects attach an attribute.

GV: Yes.

AS: Attributes don't have any defined behavior. I don't think you want to worry about that.

GV: From an AMS perspective what you would have to do is extend the port collapsing rules. If you want to say that an electrical connection is the dominant type and if you connect something that is illegal that is fine and you would have to define it. I am not defining it here, but I don't see anything that would conflict.

AK: I should be able to attach an attribute to an interconnect net?

GV: Sure.

AK: Can I query an attribute?

GV: Within the HDL, no.

FM: Within the VPI.

AS: I think you want to think about UPF and all of these. They contain the metadata.

AK: You are right. I am thinking in that direction.

AS: We may be wise to think about how the UPF properties may be associated.

AK: We may want to think about how to attach high level information to an interconnect.

GV: "2. I assume nets with "matching nettypes" can be connected through an interconnect." Yes.

AK: Fair to extrapolate by saying that if I am an interconnect that the only thing I can connect to is a matching nettype or other interconnect?

GV: There is a simpler definition. An interconnect can connect ports that are legal to collapse together. If it is legal to collapse then it is fine to do with an interconnect.

SC: Do the port collapsibility rules include port direction?

GV: No. Port directions are immaterial.

AK: I can't connect a variable port directly to an interconnect?

GV: No. That is a much more complex set of rules.

AK: I can have an interconnect that connects to two other interconnects?

GV: Sure. I think we have covered question 3.

FM: Can you have expressions?

GV: You could have concats, selects, but not addition. Only collapsible, structural expressions are permitted. That leads to "4. Are interconnects allowed to be vectors? If yes, are different bits of the interconnect vector allowed to have different types?" Sure. Because of the fact that this is purely interconnect, you just process the interconnect via collapsing rules and you can actually end up with a heterogeneous vector. Part of it is dealing with an accurate model and the rest of it is simple you could end up having bits 0-7 of the interconnect vector be a complicated type and the rest being logic. As soon as you allow the HDL do stuff with an interconnect then this type of thing is going to be problematic.

FM: When you say the different bits of the interconnect vector can have different types I am assuming the different bits are connected to different instances.

GV: Yep.

FM: You started by saying it is a new kind of nettype, but the resolution function is defined by what it is connected to?

GV: Sure it just follows the collapsing rules.

ShC: One assumption on a vector is that all the bits will have the same type? Isn't that a fair assumption?

GV: I am explicitly saying that this doesn't have to hold for generic interconnect. What I am saying now is that because I am not going to give you the ability to talk about the value I can be more flexible about how these things collapse and now give you a different type on the bits of the array because there is no way to talk about the individual bits.

ShC: What about packed or unpacked?

GV: It doesn't matter. They either collapse or they don't. When you start talking about collapsing rules on an individual simulation nets whether it is packed or unpacked doesn't matter. Just like wires now. If you have wires now and describe them as packed or unpacked it doesn't matter. The only time it matters are times when you are trying to use the entire wire as a value. Here you can't do that, so it doesn't matter.

GV: "5. When conflicting nettypes are connected through interconnects, is the exact location of the error reporting left to the implementation?" Error reporting is left to the implementation just like other error reports. If you want to report "Error in design" that is a legal error according to the LRM. A vendor would want to be more informative.

GV: "7. Is the use of interconnects in certain behavioral constructs allowed?" I don't want to allow assign, but I would be okay to allow alias statements. I don't want to allow any behavior at all. Partially b/c of the heterogeneous nature of vectors and partially b/c I don't want to do anything that relates to the type of the nets.
 
FM: Are we going to list the legal operators?

GV: No, the structural collapsing expressions are well defined. If we allow additional behavior then we have to define it.

FM: That would get complicated.

AK: In the assign are you assuming i1 and i2 are interconnect?

GV: No.

AS: I suspect there is not simulation semantics for the interconnects?

GV: No.

AS: If you compile it and don't configure it then should it work?

GV: I would be inclined to say that interconnect can't exist in the final design, but I could be okay with it if we define what they mean.

SL: What is the next step?

GV: I would prefer to have more consensus before working on a write-up. Let's leave this until the next meeting.

SL: I will create mantis items for net aliasing, const ref argument types to resolution functions, and the net introspection functions.

AK: What does the October 1st deadline mean? What work do we need to have done at that point?

SL: We would need to vote on all proposals by that time. The Champion's may give feedback and there may be some iteration, but we would need to have a vote on a complete proposal by that time.

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