[sv-dc] Notes from SV-DC meeting on 2011-03-09

2011-03-09
----------
SV-DC Meeting Notes

Attendees:
v 111111--11111 Jim Lear (Co-chair, Cirrus)
v -11111-11-111 Achim Bauer (EXL-Modeling)
n ----111111111 John Havlicek (Freescale)
v 1111111111111 Scott Little (Chair, Freescale)
v 11-------1111 Scott Cranston (Cadence)
v 1-11-1111111- Sundaram Sangameswaran (TI)
v 1-11111111-11 Gord Vreugdenhil (Mentor)
n -----1111-11- Top Lertpanyavit (Intel)
n ------------1 Dana Fisman (Synopsys)
n --1-11--1-1-1 Ghassan Khoory (Synopsys)
v 111-11111-1-- Ian Wilson (BDA)
n ------------- Ken Bakalar (Mentor)
v 11--1111-111- Kevin Cameron (obs)
v 111111-11-111 Arturo Salz (Synopsys)
n -1--1-------- Dave Cronauer (Synopsys)
n ------------- Ed Cerny (Synopsys)
n --------1--11 Tapan Halder (Synopsys)
n 1------------ Jonathan David (Qualcomm)
n ------------- Jim Holmes (Lynguent)
n ------------- Walter Hartong (Cadence)
v 1111111-11111 Shekar Chetput (Cadence)
n ---11111111-- Martin O'Leary (Cadence)
v 111-----1---- Francoise Martinolle (Cadence)
n ----1--1----- Prabal Bhattacharya (Cadence)
v 111.......... Abhi Kolpekwar (Cadence)
v 1-1.......... Steven Sharp (Cadence)
n 1............ Kishore Karnane (Cadence)
n 1............ Dave Miller (Freescale)
  |-> attendance on 2011-03-09
|---> voting eligibility on 2011-03-09

SL read the IEEE patent policy for new attendees. The IEEE patent policy can be found at: http://standards.ieee.org/board/pat/pat-slideset.ppt

SL gave a summary of the committee status as requested by JD. Based on a roadmap developed by the committee (http://bit.ly/apjS6s), the P1800 WG granted SV-DC full technical committee status. We intend to complete the must roadmap items during this PAR. We decided to begin with requirements for user defined nets and resolution functions. Proposals to address those requirements are due today. We need to work through the proposal in committee. We intend to work toward a vote on a final proposal in the meeting scheduled for May 4th.

GV led the discussion of the joint Mentor/Cadence proposal that was sent to the reflector by AK of Cadence.

GV: I want to give a tiny bit of context. Primarily we are trying to establish some fundamental functionality that we can use as a baseline for future discussions. The proposal leverages ideas in core SV and Verilog about how you talk about wires. It introduces a nettype. This is similar to a type, but it is specifically coupled to a wire type of behavior. Nettypes are different than datatypes. Later on we can talk about what you can't do with a nettype that you can do with a datatype.

The first section gives background then the actual form. It looks a bit like a typedef. It takes a datatype description and allows an optional function to be associated with that nettype. Function will be a resolution function when you have multiple drivers on such a net. The restriction is that you are only allowed to have integral types and real types. It specifically disallows dynamic types. You can't have a net type whose data type is a class. It must be something that has a known shape.

JD: Is it possible to allow strings? or fixed size logic values?

GV: A fixed size value is legal. String type is a dynamic value. You could have a fixed size reg that is treated like it contains a string.

KC: What is the rationale for not allowing dynamic types?

GV: We wanted to keep it simple and didn't want to open up questions regarding when memory allocation happens. We are trying to keep the problem to the smallest useful set we can until we become more comfortable with it.

We talk about nets with these types as atomic nets. Fundamentally this set of values that represents a single connection point. Essentially resolution functions rely on scheduling semantics of the core simulation algorithm. This gives implementations flexibility about when the resolution function is actually called. There is intentional ambiguity here.

-Discussion of assignment to nets. There are some details that need to be worked out. The intention right now is to disallow partial assignments.

GV: Near the bottom of the first page, two different nettypes can have the same datatype to allow different resolution functions. If there are side effects of the resolution function then we say the result is implementation specific. We can discuss if we want to add restrictions or leave it to be implementation defined.

The optional parameter of the current value isn't well described. There are also several typos in the examples regarding the struct fields, etc. These will be fixed.

JL: Question about the force statement. At times it would be nice to add a driver instead of force.

GV: In SV there aren't good ways of doing that. It would have to be a tool extension. You could certainly do things where if you wanted to add a driver that you could turn on or off with bits to indicate if a driver is active or not.

JL: Can the user override the default for a type?

GV: This proposal as is does not allow you to change the default value for a particular nettype. There has been discussion of it. There are syntax issues to work through there. At this point it is reasonably straightforward to do it yourself using an ENUM

GV: The proposal doesn't talk about calling resolution functions if there isn't a driver. Implication is that they won't. There is room for tweaking.

SuS: Is it possible to assign a strength?

GV: You could add something to your vector, but it isn't allowed directly.

Getting back to 6.7.1. You can create an array of atomic net of type wT. Each atomic net has a datatype that matches the datatype. Each element is resolved independently like an individual net.

-Discussion of motivation for allowing nettype declarations without a resolution function. AS mentioned that it doesn't give any more power than the type itself. GV wants to have infrastructure in place for possible late binding in the future.

GV: Small change to 6.10 saying it is illegal to implicitly define user defined nets. Again restricting early and may change later.

Middle of page 4 you are saying that you can only define a delay. The simulator doesn't know what rising and falling means for a custom nettype.

StS: Note that this delay is separate from delays on the drivers.

GV: The end of page 4 defines the connection rules for different port types. There is some ambiguity here and we need to come back and have a discussion. The important part is the third part. 'matches' is well defined in SV. There is no statement at all about whether merging of net occurs or not. This area is intentionally underdefined.

Page 5 is just a little bit of cleaning up. Note that nettypes don't have strength levels. That is an overview of where we are going. This is a minimal set of functionality that we want to use as a base for future discussion.

-Brief discussion about looking at something like parameterized nettypes in the future. We also discussed the optional parameter to the resolution function that contains the present net value. This was a late addition to the proposal and needs additional fleshing out. This led to discussion about accessing attributes of the drivers. KC mentioned that this functionality exists in Verilog-AMS. JD thought it is useful but would be better done in an OO style. This feature allows the user to maintain small bits of history across calls to a resolution function. The motivation was to be able to approximately replicate the behavior of a trireg.

AS: I wanted to touch on the fact that a resolution function could come from a class?

StS: We said that you can use a static class method as a parameterized function.

AS: It would have to be a static class method?

StS: Yes. You may want to parameterize it and we wanted to leave the door open.

GV: It gives you a way to treat classes like type and function generators.

StS: They are kind of like parameterized packages.

AS: The restriction is that it is required to be a static method.

GV: It would not hurt for the average reader to point out htat it has to be static and point out the intent.

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