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

2011-06-15
----------
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 11111111111111111111 Scott Little (Chair, Freescale)
v 11111-111-------1111 Scott Cranston (Cadence)
v -11111-1-11-1111111- Sundaram Sangameswaran (TI)
v 111-1111-11111111-11 Gord Vreugdenhil (Mentor)
n -----1------1111-11- Top Lertpanyavit (Intel)
n -------------------1 Dana Fisman (Synopsys)
y 11-1-11--1-11--1-1-1 Ghassan Khoory (Synopsys)
y 111----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 1111-11-1--1-------- Dave Cronauer (Synopsys)
n -------------------- Ed Cerny (Synopsys)
n ---------------1--11 Tapan Halder (Synopsys)
v 1111-111------------ Jonathan David (Qualcomm)
n -------------------- Jim Holmes (Lynguent)
n -------------------- Walter Hartong (Cadence)
v 11111111111111-11111 Shekar Chetput (Cadence)
n ----------11111111-- Martin O'Leary (Cadence)
v 1111111111-----1---- Francoise Martinolle (Cadence)
n -----------1--1----- Prabal Bhattacharya (Cadence)
v 11111-1111.......... Abhi Kolpekwar (Cadence)
v 11111111-1.......... Steven Sharp (Cadence)
v -11-1--1............ Kishore Karnane (Cadence)
n 1-1----1............ Dave Miller (Freescale)
v 1-11111............. Jess Chen (Qualcomm)
v 11111............... Mark Hartoog (Synopsys)
  |-> attendance on 2011-06-15
|---> voting eligibility on 2011-06-15

Upcoming dates to note:
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

SL: Directed folks to the IEE Patent policy

JC: Filed a patent to do PLI functions that do some of the things that are being discussed here.

SL: I will inform Karen Pieper of this. Thanks.

SL: FM, can you describe the changes in the most recent version?

FM: I made some small editorial changes that are highlighted in pink.

GV: I object to change of 'or' to 'and' because it is inconsistent with other places in the LRM. I would like to fix it at once every place in the LRM. That sentence is consistent with the requirement and intent elsewhere in the LRM.

SS: I don't see why we should make this one wrong if the others are wrong.

FM: There are at least two or three more instances of this phrase.

GV: I don't want to have folks wonder why this one is different.

SS: Which group should address this?

GV: EC

SS: I am willing to give way.

SL: Will somebody submit a mantis on this subject?

FM: I will. (Note: mantis 3625 was created to address this issue.)

AK: Do we want to get the const ref change in to this version?

SS: I am okay either way.

GV: I don't feel too strongly about it either way. We need to decide by the end of this PAR though. I would like to get this on to the Champion's as soon as possible. I am prepared to make a motion to version 13 with the removal of the color changes and the reversal of 'and' to 'or' with those two friendly amendments.

SS: Second.

DC: I will abstain. I am not up to speed.

SL: Motion passes. 11y/0n/1a

Generic interconnect

SS: Want to raise concerns if they could be declared as vectors if they were unpacked. Then Gord raised the issue that they can be heterogeneous. I have significant concerns about that. Presumably you are saying they can be heterogeneous.

GV: They would collapse to different user-defined nettypes.

SS: I am concerned because we have an array-like thing (it is not an array because it is not homogeneous). I would like to object on a number of grounds. You couldn't declare a datatype. It would be a new thing so there is no reasoning about it. You couldn't talk about the datatype within the mechanisms. The interconnect would present something you couldn't explicitly declare. You can no longer connect this to anything but another interconnect. You would only be able to connect homogenous sub parts. I am concerned about all of these issues. I can understand that you may want to model different levels of abstraction with this interconnect but we do have a precedent for arrays that can be non-homogeneous (instance arrays and for generate scopes) and these cause problems with users. I don't think it is as big of a problem with interconnects because you can't operate on them. In the future if we allow some sort of procedural access or through interfaces it could start to cause a problem.

GV: This is definitely a trade-off. The fact that we have heterogeneous structure doesn't bother me.

SS: It is struct that is indexed by a number instead of a name.

GV: Exactly. I believe it is restrictive enough to not cause a problem now. As far as future I believe it will be a problem to allow procedural access in the future. There are enough long term issues with procedural access that I am willing to say that I don't think that will ever fly and instead allow the user to have this capability. Most of what I have heard from users is that managing the type of ports that becomes a major hassle. I think that the trade-off in the direction I am specifying is useful.

SL: I am okay with this tradeoff based on comments from Freescale users.

SS: If you don't have a concrete type it would be difficult to write procedural code on this. To do it you would need type introspection. I know that GV has said he doesn't want that. I can see this being pushed as a way to do this. If type introspection does get added then there is a problem because you can't return a correct type.

GV: A similar problem is what to do about floating interconnect. You can talk about a type of an element of an array of interconnect. It could have no type (interconnect) or it could have a type. Even if we add introspection restrictions could be added that could work with the fact that there is a heterogeneous bus. I agree that there are some concepts that are different than much of what we have in the language.

SS: Do you just always declare these as vectors and connect them to unpacked things then you split up the vector and connect them to each individual bit?

GV: In a sense you already have a certain amount of that with wires. Fundamentally by the time you look at your indexing expression you end up accessing bits of the individual sequence of bits and they are collapsed independently. It can be expressed in resolution but not in type. Right now you could have different resolution functions within a wire.

SS: The only thing that you can connect to the entire interconnect is another interconnect because there isn't another matching type. A struct can look like this but it is indexed by name and not number. What is the motivation?

GV: Split a bus between two devices and you don't need to swap when the models change. It is only one case, but I believe it is an important one.

SS: What about connection rules involving packed/unpacked dimensions?

GV: Having the packed and unpacked dimensions connect in the same way that they would be required to match in a wire definition is what I would want.

SS: How else can you connect to a 32-bit bus of logic and another connector with 32 items in a struct? I don't think you can unless you allow packedness agnostic connections. You can convert from a packed to an unpacked if you are going to vector except if they are really unpacked but you can't go the other direction.

GV: With the new array rules without a ' it isn't clear to me that you can't go the other direction.

SS: I would say that the new array concatenations it has gotten a bit fuzzy. Now that the new rules have come into place there may be some confusion. I don't believe that the intent is to allow those types of concatenations. What you propose doesn't give you full flexibility. If you are going for flexibility I think users may want this. I am concerned that this makes the generic less flexible.

GV: I don't want to solve all of the generalization problems. The problems that I am trying to make sure get addressed is that right now people have trouble in managing pin out. They know the pin out but not the abstraction.

SS: Your interconnect is at the level of a single connect point but you don't know how to represent it.

GV: Yes, that is the problem I would like to solve in this committee.

SS: If that is the goal then I would assume there is a requirement that each interconnect item connects to something that atomically resolves.

GV: Yes, that is my intent. Right now all of the collapsing semantics are at an individual point. All of the current discussions are currently at these levels.

SS: I don't think that talking about it from the collapsing perspective is enough.

GV: I agree. We can make this clear in terms of questions. You have raised some good points in the packed/unpacked issues. Is this close enough to where we want to go that I should start on a proposal?

SS: We have only had one user response vs. the various disadvantages. Even if we make them homogeneous no one is saying that we will have procedural access.

GV: Making them heterogeneous closes that door pretty firmly.

JD: For our purposes this would be fine. It isn't going to prevent the waveform viewer from looking at the interconnect. It isn't going to prevent a PLI function from querying the type of the interconnect.

SS: There would have to be extensions to the PLI but there isn't anything theoretically preventing it. It sounds like to me that JC doesn't imagine using interconnect.

JC: Yes, I don't want to even be aware that interconnect exists. I want the netlister to manage all of that.

GV: This proposal is trying to provide a tool independent way to describe how a netlister would describe very general interconnect.

JC: Interconnect scares me because of a previous experience with wreal. Vendor x allowed wreals to connected via wire while vendor y required wreal a wreal declaration throughout the hierarchy. Declaring wreal or similar throughout the hierarchy is not workable.

SS: I don't want to use wire because connecting a real to a wire is already defined. It would coerce it.

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