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

2011-04-20
----------
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 1111111111111111 Scott Little (Chair, Freescale)
n --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 -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 11-111111-11-111 Arturo Salz (Synopsys)
v -11-1--1-------- Dave Cronauer (Synopsys)
n ---------------- Ed Cerny (Synopsys)
n -----------1--11 Tapan Halder (Synopsys)
v -111------------ Jonathan David (Qualcomm)
n ---------------- Jim Holmes (Lynguent)
n ---------------- Walter Hartong (Cadence)
v 1111111111-11111 Shekar Chetput (Cadence)
n ------11111111-- Martin O'Leary (Cadence)
v 111111-----1---- Francoise Martinolle (Cadence)
n -------1--1----- Prabal Bhattacharya (Cadence)
v 1-1111.......... Abhi Kolpekwar (Cadence)
v 1111-1.......... Steven Sharp (Cadence)
n 1--1............ Kishore Karnane (Cadence)
n ---1............ Dave Miller (Freescale)
v 111............. Jess Chen (Qualcomm)
n 1............... Mark Hartoog (Synopsys)
  |-> attendance on 2011-04-20
|---> voting eligibility on 2011-04-20

Notable dates:
2011-05-04 - Meeting: Discuss proposal and next steps
2011-05-18 - Meeting: Target date to vote on a proposal for mantis item 3398
2011-10-01 - Technical work complete for P1800-2012 PAR

Decisions/AI summary:
-Leaning toward requiring the resolution function dynamic array to be a const ref. Cadence will confirm their preference after internal discussions.
-Adding a simple method to alias nettypes of the form nettype nettype_id id
-Collapsing rules in Variant C seem like the right direction, but we need to ensure they are sufficiently restrictive to allow future work on type conversion to progress without being hindered. Gord has sent out an example to help folks think about proper restrictions.
-Cadence will update the proposal based on consensus from this meeting.
-Next meeting we will discuss proposal changes and subsequent topics for SV-DC this PAR. Note: the roadmap is found at: http://bit.ly/apjS6s

Motion: Have the IEEE patent policy as read. (FM) 2nd (GV)
Vote: 6y, 0n, 0a

SL: Cadence has raised the issue of the dynamic array being passed by ref. They would like it disallowed.

FM: The fact that the dynamic array of nets passed to the resolution function can't be modified needs to be in the proposal.

GV: That is already there.

FM: We want to make sure you can't call another function and pass the dynamic array as a ref to that function.

GV: This has been discussed in BC and the discussion there suggests that you can't pass an input argument as a ref because an input argument can't be an lvalue.

AS: If it is an input argument then why is this even important? It is already a copy.

SS: I don't care if you resize the array. I don't want the original array to be touched. The only reason we are using a dynamic array is because we need a structure with a resizable number of items. I don't want the user to touch the array.

AS: If you allow it to be called from other places then all bets are off. Why not state const ref?

SS: We could require the argument to be passed as const ref. I am not sure because I don't know the efficiency details.

AK: Why don't we get back to you.

AS: I prefer const ref.

MH: I expect const ref will be higher performance.

GV: I don't really care, but I prefer const ref I think.

SL: It appears that we are leaning toward requiring the dynamic array of nets to be const ref, but we will wait for Cadence to get back to us with their final opinion.

Port connections

GV: Described the three variants.

SS: Assuming we allow expressions on the source side. If someone really wants the hierarchical resolution they can always put a cast on the hi side.

GV: There are two things in play. The datatype and nettype. You must have a matching datatype.

SS: You are willing to have it assignment compatible?

GV: For now I want it to be as tight as possible.

MH: What about the case of hooking two atomic nets of different nettypes even if they have the same datatype?

GV: It is an error. If it is the same datatype it would be legal but not collapsed. If it is an inout it would be illegal. Cadence has suggested some matching rules. I don't want to do that right now.

SS: It needs to spelled out for the same reason that matching data types need to be spelled out.

GV: I am okay to be precise about that. There is no typedef equivalent for nettypes and I don't want to open that up right now.

AK: Let's say we have 2 IPs with different nettype names but we really mean the same resolution function and datatypes.

GV: That is an error. You have the same problem with structs or enums today.

SS: We can get around that by using a typedef to rename the type. We need that capability here as well.

GV: I am going to object to using typedef because nettypes aren't types.

SS: It would be misleading. I agree.

AS: I don't understand the motivation for this. Why do we need to be able to alias?

SS: You have two different groups of designers using the same datatype and resolution function, but the nettype is different. How this actually happens I don't know. If they do that then they won't have a way to connect the blocks together without globally changing the nettype in one of the designs. If you have a global way to rename the nettype it would solve the problem.

AS: They should use a package.

GV: This is a real problem. You do have issues where enforcing a unique package naming convention is a difficult design problem. It is a real issue.

AK: Is your issue related to using a typedef?

GV: I am going to strongly object to calling it a type.

AK: SS had an idea that you can use nettype id to override.

GV: I like that. It will need to be properly restricted to only nettype nettype_id id. It is just a naming alias for the first id. It is just like a simple typedef.

SL: Okay, that should be added to the proposal.

SS: You say you want 3 bits on one side and 10 bits on another

GV: Atomic continuous assignment says that all parts must be driven and the datatype must match. The width of the vector will cause it to not match.

FM: It doesn't say that the datatype must match.

GV: And it should.

AK: We will take this as an action and reword.

SS: Is there any other reason to require matching datatype other than to be conservative?

GV: No, not really. If we just say that it is assignment compatible that is probably fine. At this point if we are going to say it is either a matching nettype or assignment compatible data type then I am fine with that.

FM: If you have a user-defined nettype with a datatype that is a packed vector it can only be connected to another net of the exact same nettype?

GV: No. If it is inout that this true. If it is input or output it will only collapse if it is the same nettype otherwise it will be continuous assignment assuming it is assignment compatible.

FM: The datatype on the other side can be different, but it must be assignment compatible.

SS: The only reason I can see for not allowing it is that users will make mistakes.

GV: That is why I was biased to the much stronger rules initially. Variant C opens the issue that you get all of the same Verilog rules where you have relatively flexible net connections. Now we are saying that you only get collapsing in very specific cases but everything else works. There are a lot of implications here that I hope people have thought through. I am sort of okay, but I think this may impact things down the road. For example, issues that AMS people care about like type conversion and implicit type conversion. I think that having the flexible rules is closer to Verilog digital, but I am concerned about eventual AMS concerns.

SL: What about disciplines? Can they help?

GV: Yes, but if we make a decision now it may complicate what can be done when disciplines are ready to come into the language. It isn't wise to assume how something might be done in the future. It is better to be restrictive now and possibly loosen the restrictions down the road when type conversion is ready to come into the language.

The case you want to understand if I have a 1'b1 on the hiconn what nettypes am I allowed to connect that to. If I have a wire on the hiconn what nettypes am I allowed to connect that to. The rules had better be the same.

SS: And if I want to be able to have a 1'b1 to be able to end up as a 5.0 one day then you don't want the normal SV assignment rules.

If you put a literal on a port you are putting it on a nettype. I don't think we want it restricted to just literals. We should also allow expressions. It gives you a loophole to use a cast. If we do such a rule for ports do we do we need such a rule for continuous assignments?

GV: No, I don't think so.

SS: It isn't a boundary that people usually compose designs across.

FM: Did we define datatype matching for arrays of atomic nets? If you have an array of atomic nets on a port what can it be connected to? We will need to define the datatype for an array of atomic nets.

SS: I think it is clear how it works, but it should be documented. I don't know where to put that.

GV: What I am concerned about is if it isn't clear to us. In some of these cases there is almost always something where there is an edge case that can be clarified. I think we need to get a reasonable version of this proposal and start propagating it up. As long as we aren't doing anything wrong I think we want to get closure on this and move it up the food chain.

AK: We will update the proposal.

GV: I won't be able to attend the next meeting. Can we push off the vote an additional meeting?

SL: Yes, we will plan to vote on May 18th.

GV: I can try to look at the proposal if it is finished prior to May 4th.

SL: Cadence, can we have the proposal in a week from now?

AK: I can't guarantee it, but we will try.

SC: What is next on the agenda?

SL: That hasn't been decided, but we still have some MUST items left on our list. Next we should consider SHOULD items. Based on previous comments I would conjecture it might be resolution function override/late binding.

SC: We would like to discuss the next steps.

SL: We can do that at the next meeting assuming we have time left after the discussion of the proposal changes. GV, you won't be in the next meeting. Do you have thoughts about what you would like to handle next.

GV: In order of priority I would like to deal with generic interconnect then late binding.

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