[sv-dc] Notes from meeting on 2011-03-23

2011-03-23
----------
SV-DC Meeting Notes

Attendees:
v 11111111111111 Scott Little (Chair, Freescale)
v 111-------1111 Scott Cranston (Cadence)
o -1-11-1111111- Sundaram Sangameswaran (TI) (obs)
v 11-11111111-11 Gord Vreugdenhil (Mentor)
n ------1111-11- Top Lertpanyavit (Intel)
n -------------1 Dana Fisman (Synopsys)
n 1--1-11--1-1-1 Ghassan Khoory (Synopsys)
v -111111-11-111 Arturo Salz (Synopsys)
n 1-1--1-------- Dave Cronauer (Synopsys)
n ---------1--11 Tapan Halder (Synopsys)
o 11------------ Jonathan David (Qualcomm) (obs)
v 11111111-11111 Shekar Chetput (Cadence)
n ----11111111-- Martin O'Leary (Cadence)
v 1111-----1---- Francoise Martinolle (Cadence)
n -----1--1----- Prabal Bhattacharya (Cadence)
v 1111.......... Abhi Kolpekwar (Cadence)
n 11-1.......... Steven Sharp (Cadence)
n -1............ Kishore Karnane (Cadence)
n -1............ Dave Miller (Freescale)
o 1............. Jess Chen (Qualcomm) (obs)
  |-> attendance on 2011-03-23
|---> voting eligibility on 2011-03-23

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

SL briefly discussed the new participation rules and IEEE patent policy.

The primary topic of the meeting was a discussion of outstanding questions/concerns regarding the most recent version of the Cadence/Mentor proposal. Below is a summary of the committee consensus with additional discussion points for some items. GV volunteered to do a scrub of the proposal and post an update to mantis 3398 and the reflector. Areas of the proposal that don't yet have consensus will be highlighted in a different color.

a. unresolved nettypes (purpose, restrictions, future, late binding)
DECISION: Leave unresolved nettypes in the proposal. Current restrictions are fine. GV would like to address late binding in the current PAR but is willing to let it fall out of the core functionality.

GV: Unresolved nettypes strictly don't add any additional power. There are some small differences, but I haven't heard a technical reason to remove them.

b. current value argument to the resolution function
DECISION: Postpone for now. If it is needed in the future the argument can be added, and the function signature can be used to distinguish functions using the new features from older functions.

c. parameterized nettypes
DECISION: Allowing this would require some new syntax, but we aren't confident we clearly understand the complete set of requirements. For now we will suggest that users adopt the class-based mechanism SV-BC has demonstrated for parameterized functions. If there is a big need for this in the future it can be designed into the language when the requirements are better understood.

FM: The only oddity I see is that a resolution function in a class will have to be a static method.

StS: A static method that is an automatic function. Outside of a class it must be an automatic function.

GV: That is the ongoing confusion regarding static class methods and automatic functions in the module world.

StS: We will be introducing a new group of people to that confusion.

GV: Fortunately most of this can be boiler-plated for end users.

d. clarify rules for driving nettypes (partially driven nets ok?)
DECISION: Disallow at this time.

GV: Originally thought I would allow it. There is a fair bit of infrastructure that would need to go along with the features. I am less convinced that this would be needed. The only restriction we need to add to the current definition is that for a user-defined nettype you can't use a field or index select on the LHS of an assignment.

StS: You could allow a partial assignment, but the rest of it could be assigned to its default values. You couldn't do multiple assignments and assume to drive multiple fields. This is too likely to lead to mistakes.

e. resolution functions and side effects (restrict or leave as implementation dependent?)
DECISION: Restrict to not allow side effects. The understanding from the vendors is that sensible system tfs (e.g., $display) will be allowed although strictly they do cause side effects.

f. user defined initialization of nettype
g. clarify if resolution functions operate in the case of 0 or 1 drivers
DECISION: Vendors need to go back and look at how the different proposals will affect their tools

StS: I think we need to have resolution function execute at time 0. For structs in SV it is possible to specify initial values for the members. Right now the LRM says those are ignored on nets. If we wanted to use this then we could say on user-defined nets this could be used as initialization. It would only work for structs. If you wanted a single net you would have to wrap it in a struct.

GV: I think that is a pretty clean way of dealing with the issue. It avoids additional syntax. It is a fairly straightforward one liner in the definition. To express undriven nets you need a way to ensure that the initialization is consistent with your high-z state. I worked around this with a 2-state enum where the lowest value was the high-z state. Making it explicit will be more clear.

StS: As far as the issue of no driver, what is its value? The value for an undriven net is what your resolution function does when it is given an empty array of drivers.

ScC: Isn't the resolution function enough to specify that?

GV: That is true. I don't think we even need the extra rule. The default initializers in a resolution function could setup the right values.

StS: As long as we specify the resolution function runs at time zero.

GV: If we ignore the issue and don't do anything special for the initial value and say that resolution functions are always run at least once at time 0 and that if you have no drivers you get an empty array. That should allow the initialization.

StS: Will you get an event at time 0?

There was discussion of initialization strategies to properly get events and deal with cross-language interactions between SV and VAMS/VHDL.

GV: There are probably going to be various issues in this domain. I am not sure I want to come up with something in pure digital that maps to AMS. I think that some of the things you need to talk about in AMS are difficult to express in a digital way. The answer may be that when an AMS definition comes out it would say in cases when analog contributions are present then the following definition supersedes the digital behavior.

h. possibilities for generating events from user-defined nets
DECISION: It is possible under the current proposal to say always @(udt_wire). If there is a big need to allow users to define posedge and negedge it can be added.

i. review port connection rules
DECISION: Get user feedback on what is desired.

GV: The current definition is to collapse for inout and not otherwise. My bias is to keep that definition.

StS: I have a slight bias in that direction as well. If the user wants to collapse then they just make it inout. If that power isn't useful and users get confused then we could leave the door open and say you could only use input and output for now.

SCh: I would like to mention that the current wreal with multiple drivers follows the collapsing semantics of Verilog.

j. clarify that resolution functions from classes must be static and explain the intent of
   allowing resolution functions from classes?
DECISION: See the discussion of item c.

k. (additional item from StS) Concerned about the users being able to manipulate the dynamic array of drivers. This makes it difficult to optimize.
DECISION: Only allow read access and query functions on the driver array.

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