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

2011-04-06
----------
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 111111111111111 Scott Little (Chair, Freescale)
n -111-------1111 Scott Cranston (Cadence)
v 1-1-11-1111111- Sundaram Sangameswaran (TI)
v 111-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 1-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 111111111-11111 Shekar Chetput (Cadence)
n -----11111111-- Martin O'Leary (Cadence)
v 11111-----1---- Francoise Martinolle (Cadence)
n ------1--1----- Prabal Bhattacharya (Cadence)
v -1111.......... Abhi Kolpekwar (Cadence)
v 111-1.......... Steven Sharp (Cadence)
n --1............ Kishore Karnane (Cadence)
n --1............ Dave Miller (Freescale)
v 11............. Jess Chen (Qualcomm)
  |-> attendance on 2011-04-06
|---> voting eligibility on 2011-04-06

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

0. IEEE patent policy (http://standards.ieee.org/board/pat/pat-slideset.ppt)

AS: Moved to accept the IEEE patent policy as read.
GV: Second
7y/0n/0a

1. Discussion of proposal(s) for user-defined nets and resolution functions
  a. nettype initialization

SS: From a simulation accuracy point of view we need to evaluate resolution function (RF) at time 0 in case the default value of the RF isn't the default state. If there are no drivers on the net then you will still run the RF.

GV: You could also call the resolution function for every net without the driver information then connect the drivers and do another call.

SS: I am not very fond of that approach. I would favor using the initial values for struct to achieve user initialization and then run the RFs with connected drivers at time 0.

GV: Do people have practical use cases? Are there cases where we need to differentiate initialization from the undriven case?

SL: I don't have a use case, but I favor the flexibility.

SS: If the user finds out they need to do that we have given them an out with the structs.

GV: If someone wants something in the future for non-struct data type initialization then we can deal with it then.

SS: I think it is an easy enough solution. It is a user defined way to specify the default value. If it gets overridden by some new method then fine.

Consensus is that struct initialization can be used as default values for structs at time zero. These default values will be immediately overwritten by the results of an RF call at time zero. RFs will be called at initialization with all drivers connected.

SS: When exactly the RFs run at initialization is related to whether users can read outside variables, etc.

AS: I thought we can consensus that the RFs would be pure.

SS: Gord put in that they don't have side effects, but they don't have to be pure. I want to be clear that they are not sensitive to outside variables.

GV: I wasn't sure if folks want to do things differently for .op, .tran, .ac and have a variable to control that. If we don't give the users any way to effect the behavior of a RF during simulation then even approximations to these things may become difficult.

Consensus was that RFs shouldn't be allowed to access outside variables. If a reference to outside variables is needed it can be added later. One suggestion was to add an additional argument to the RF. The RF could then be sensitive to that variable. It was believed that sensitivity to these external variables is important for practical use.
 
  b. port connection rules

SL: The users I contacted wanted input/output to not collapse and inout to collapse.

SS: Do you have specific use cases?

SL: No. Just conjecture.

SS: There may be some legacy issues with AMS and collapsing. If we switch to this there might be portability issues with AMS.

SC: Even wreal would be problematic. Question of collapsing or not becomes important when drivers are across the hierarchy.

Consensus was that more effort should be given to find solid use cases for the different approaches. This is a decision that may be difficult to "undo." We should get it right the first time. VHDL has non-collapsing semantics, so VHDL users might have some use cases. Gord volunteered to put the rules for both options (inout collapsed and input/output not collapsed vs. everything collapsed) in the next revision of the proposal.

  c. use of dynamic array for resolution function ports

AS: I am concerned about what the users can do with the dynamic arrays in the resolution functions.

GV: I added restrictions in the most recent update. Users are not allowed to write or resize the dynamic arrays. They are essentially equivalent to a const input argument.

AS: That is very good, but it doesn't address the issue that the RF could be called from user code. This makes it difficult to optimize those functions.

GV: I am not convinced that the difference in performance justifies introducing additional restrictions. I am fine with moving to the const input restrictions. I would have to be convinced further for more restrictions.

AS: What are the reasons for calling it in user code?

SS: One reason I see is for debugging.

AS: You can do that by copying the RF and renaming it somewhere else. Does forcing RF to only be called as RFs help the tools give the users better warning?

GV: I don't see why it is necessary to disallow it. The current rules don't preclude doing the analysis and warning the user about it.

AS: It would be possible to detect at parse or compile time and warn the users. We do need to add a restriction that disallows passing the array as a non-const ref.

  d. ability to override the resolution function

SL: AS and GV have mentioned that they want an override/late binding capability. These seem to address similar concerns. Last meeting we decided to remove that concern from this proposal. Do we want to revisit this decision?

Consensus was the same as in the last meeting. We will consider this item in another proposal. That reconsideration can still potentially be in this PAR.

2. Opens

SC: What about communicating with Verilog-AMS?

SL: I have talked to Dave Miller. He thought it would make sense to speak with them when we have converged farther. It seems like we are pretty close to converging. Now may be a good time.

SC: They may have opinion about the port collapsing.

SL: I will talk to Dave and see when we could present. I will let everyone know and those who can attend the meeting will be appreciated.

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