[sv-dc] Notes from meeting on 2011-07-27

2011-07-27
----------
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 1111111111111111111111 Scott Little (Chair, Freescale)
v 1111111-111-------1111 Scott Cranston (Cadence)
v 1--11111-1-11-1111111- Sundaram Sangameswaran (TI)
v 11111-1111-11111111-11 Gord Vreugdenhil (Mentor)
n -------1------1111-11- Top Lertpanyavit (Intel)
n ---------------------1 Dana Fisman (Synopsys)
y 1-11-1-11--1-11--1-1-1 Ghassan Khoory (Synopsys)
y -1111----111-11111-1-- Ian Wilson (Accellera/BDA)
n ---------------------- Ken Bakalar (Mentor)
n ---------11--1111-111- Kevin Cameron (obs)
v 11-11111-111111-11-111 Arturo Salz (Synopsys)
v -11111-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 1111111111111111-11111 Shekar Chetput (Cadence)
n ------------11111111-- Martin O'Leary (Cadence)
v 111111111111-----1---- Francoise Martinolle (Cadence)
n -------------1--1----- Prabal Bhattacharya (Cadence)
v 1111111-1111.......... Abhi Kolpekwar (Cadence)
v 1111111111-1.......... Steven Sharp (Cadence)
v 11-11-1--1............ Kishore Karnane (Cadence)
n -11-1----1............ Dave Miller (Freescale)
n --1-11111............. Jess Chen (Qualcomm)
v 1111111............... Mark Hartoog (Synopsys)
  |-> attendance on 2011-07-27
|---> voting eligibility on 2011-07-27

Upcoming dates to note:
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)
   Please review these slides prior to the meeting if needed.
1. Election of co-chair (All nominations are due prior to the meeting)
2. Discussion of the response to Champions feedback on 3398 (see v14 attached to an earlier e-mail from Francoise.)
3. Discussion of generic interconnect
4. Opens

SL: I would like to draw your attention to the IEEE patent policy.

There was a discussion of procedures for P1800, champions, and Oct. 1 deadline.

SL: Please bring-up any new items ASAP. Otherwise we won't have enough time to properly deal with them.

FM: Reviewed proposal changes based on Champions feedback.

FM: Does anyone think we need to add something about redefining built-ins?

GV, AS: No.

FM: What do we need to clarify regarding atomic nets?
Shalom's comment: The term "atomic net" also does not reflect the nature of the net. A net can be defined with type integer, which belongs to integer_atom_type. Why would that be less of an 'atomic net'?

GV: I think that some confusion happened when Shalom looked at the grammar and thought that the atom in the grammar may be related to what we are talking about here. They are different. It is an unfortunate choice of production wording in the grammar. I think what we have is more clear now.

SS: Have we been careful to not use atomic net when we meant net of user-defined nettype? We need to go through the mantis and check that.

FM: Shalom's comment re: 6.7.2 and driver changes (below). What do we need to do here?

6.7.2 says, "Since the actual evaluation of the resolution function is subject to scheduling non-determinism, no assumptions can be made regarding the state of driven values during the guaranteed call, which may precede or follow any driver changes at time zero."

   But even if a driver values follows the resolution function evaluation at
   time 0, won't the resolution function then be re-evaluated? The sentence is
   not clear about that, and appears to hint that possibly not.

GV: I think this is clear. It is similar to what happens with always_comb. I don't think that we need to do anything there.

SS: There isn't anything special or funny there so we don't need to say anything.

FM: What about the default initialization comments (below)?
6.7.2 says, "The default initialization value for a user-defined net shall be the default value defined by the datatype." This is not clear. Table 6-7 specifies default initialization values for various data types. But it relates only to variables. For example, it says that the default value of a 4-state integral type is X. But for a normal wire (except trireg), it is Z. Till now, wires could only have these 4-state integral types, but this proposal allows them other types. So what value is applied here? Also see 0002409 and 2420.

SS: Rules for wires aren't applicable here. We have defined rules for nets of user-defined type.

FM: I added a sentence in 6.7.2 to say that this table also defines the default value for data types of nets of user-defined data types. I didn't change the title of that table.

SS: I think that is adequate.

FM: I will go through the document again.

GV: Go ahead and finish up your review and then send it along to me. We can send it out the committee for review and ask Shalom to review it again. It just takes too long w/ the committee.

GV: Move to accept Abhi as co-chair
FM: Second

12y/0n/0a

SL: Do we have any generic interconnect updates?

AK: There has been much internal debate. We have created some internal requirements that we are used as a reference for an internal. I am hoping there will be a few more rounds of internal discussion. We are getting to a point when we can engage Gord.

SS: The general flow of what Gord sent us seems reasonable. There are some detailed aspects about what exactly can be connected to ports. One of the big items is do you allow concats to be connected to interconnects on the other side and how are those defined. Clearly a bit concatenation is allowed and is collapsible. An array concatenation is allowed but it isn't clear that it is collapsible. These things are supposed to be collapsible. Assignment patterns are another item.

GV: Assignment patterns are an odd item b/c of the typing rules. Assignment patterns take the type of the target. We have to be careful how we do that with interconnect before collapsing. I suspect that some of the things where you need the type of the port will have to be disallowed.

MH: Assignment patterns can have a type.

SS: Yes, assignment pattern expressions.

GV: Things that have to appeal to the type of the port where the type of the port is an interconnect will be problematic.

SS: That includes assignment patterns and array concats.

GV: There are two aspects to the type. Even the current rules get into that a little bit because they talk about the array bounds and how you distribute that cross a connection. What I would not expect to allow is to allow a single interconnect connect to a regular vector wire.

SS: I would expect that since each item of that vector wire is an atomic net.

GV: As long as we are talking about atomic things connecting to atomic things you can talk about how many we have and their connection.

GV: I think that a concatenation of interconnect will be the special case that we need to deal with. For interconnect whether it is packed or unpacked it doesn't matter. I think that you can just pick a form for the equivalent interconnect type for the concatenation of interconnect and say that is ok. The only thing that you can't have an interconnect concat that mingles interconnect and wire elements.

SS: Would you treat the concat of interconnects as being a new construct?

GV: I would define it as being a vector or array form of interconnect. Just say that a concat is equivalent to a treatment as a vector of interconnect.

SS: One thing you may want to do is use a concat to items that are heterogeneous.

GV: I would be tempted to stay away from that. It is convenient but not required. I am not sure that I would want to try and deal with that in this round unless we want to break it up and talk about it as a template for interconnection.

FM: It seems to me that it would be difficult to determine if the port you are going to connect it to will be compatible.

GV: Sure. That is true in general. You don't know until elaboration.

FM: Couldn't I put the interconnects in an interface and pass the interface through a port?

AS: Ugh, let's not go that way.

GV: I don't see any real issue with homogeneous interconnect vectors. What I do see as difficult to express is a heterogeneous concatenation. That wouldn't be expressible with the language in the current LRM. We would have to invent some language to talk about that.

AS: Concatenation is overloaded in several ways. This may be another version of that.

GV: I am not sure it would be worth it to go that way in this PAR. I expect to see interconnect to be used in 1. modules with 100% interconnect or 2. down at the implementation level where you have a module implementing behavior at which point you have hardened types. You can construct scenarios where you have a mix, but I don't think that will be the common use or what this is targeted for. I don't see a compelling reason to deal with these issues in this PAR. If we can deal with normal concats and deal with concats of interconnect I think we are okay.

ShC: When you say heterogeneous you mean data types and not net types? Can you combine something that has the same nettype but may have different resolution function?

SS: You could as long as you split them back out later.

GV: If late association of resolution functions are allowed then it would be ok. The typing issues with user-define nets are sort of artificial because of the way we have defined the type.

SS: What is your current view on interconnects that are heterogeneous because of different bits being connected differently?

GV: No problem. I expect that to be useful.

SS: What about concats of interconnect of differing types?

GV: That is fine.

GV: Interconnect is not meant to solve a general polymorphic net behavior.

AS: My mental picture is what is the next step. You will have to put functionality in there?

SS: No. The function is describing connections.

GV: The real behavior is eventually connected to a real type. All of the behavior is at the place in the design where the definite types exist.

AS: That is where I see the problems happening. When you specify full behavior for everything is when problems happen.

SS: When it connects to something then the interconnect gets that type and you propagate it all over the place and things will behave as if it had been declared that type all along. And interconnect is compatible with any other nettype and submits to it. There are corner cases where you can get heterogeneous interconnects which is sort of bundles of separate things that are associated together.

AS: That would be something different.

GV: It isn't observable though because you can't do anything with the interconnect vector.

SS: It is just a connection scheme. If you have an interconnect w/ 4 reals and 4 logics you can't connect that entire interconnect to anything because you can't create an array like that. You can connect the top/bottom 4 bits to things.

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