[sv-dc] notes from SV-DC meeting on 2010-09-08

Below are John's notes from the meeting today.

2010-09-08
----------

SV-DC Meeting Notes
 
Attendees:
v 11111 Jim Lear (Cirrus)
v 1-111 Achim Bauer (EXL-Modeling)
v 11111 John Havlicek (Freescale)
v 11111 Scott Little (Freescale)
v -1111 Scott Cranston (Cadence)
v 1111- Sundaram Sangameswaran (TI)
v 11-11 Gord Vreugdenhil (Mentor)
v 1-11- Top Lertpanyavit (Intel)
n ----1 Dana Fisman (Synopsys)
v 1-1-1 Ghassan Khoory (Synopsys)
v 1-1-- Ian Wilson (BDA)
n ----- Ken Bakalar (Mentor)
v -111- Kevin Cameron (obs)
v 1-111 Arturo Salz (Synopsys)
n ----- Dave Cronauer (Synopsys)
n ----- Ed Cerny (Synopsys)
n 1--11 Tapan Halder (Synopsys)
n ----- Jonathan David (obs)
n ----- Jim Holmes (Lynguent)
n ----- Walter Hartong (Cadence)
v 11111 Shekar Chetput (Cadence)
v 111-- Martin O'Leary (Cadence)
n 1---- Francoise Martinolle (Cadence)
  |-> attendance on 2010-09-08

SUMMARY: Scott Little was elected chair, John Havlicek co-chair.
The roadmap document was discussed and revisions made. The revised
roadmap is available at:

http://bit.ly/apjS6s

DETAILS:

IEEE patent policy motion:AS 2nd:TL
0n/0a/11y (unanimous)

Voting on permanent officers.
Approve SL as chair
0n/0a/11y (unanimous)

Approve JH as co-chair
0n/0a/11y (unanimous)

Roadmap discussion

- AB: Existing simulations are not sufficiently scalable. Concern about
marketing
  nature of this sentence. One solution is to delete the sentence
entirely.
- GV: I can live with it or delete it.
- JH: I don't have a problem with this sentence. "Scalable"
- SL: Do others have a strong opinion about this sentence?
- SL: Let's move on to other issues and come back to this.
- AB: Consider folding scalar net requirements into aggregates.
- AB: Consider adding events to R05.
- GV: Avoid pinning down exactly what is to be discussed. Also we are
not
  saying what order these have to be addressed.
- AB: R07 only mentions "bidirectional"; "unidirectional" is intended
also, as
  in R04.
- AB: Many analog blocks are filters; some mention of that might be
good, but maybe
  that is too detailed.
- AB: It would be useful to have a state for nets.
- AS: I thought we agreed not to do that in resolution functions.
- GV: Some discussion of this would be useful.
- AB: Information about driving or loading strength requires state in
net.
- GV: How about a "should" requirement to investigate/discuss ways of
modeling
  state within net resolution.
- AB: Aggregates are a must; need to be sure that we can effectively
use them
- GV: There is a question of phasing. We only have about a year to
complete this
  round.
- SCh: What is the meaning of "must", "should", "could"?
- GV: "must" need to be addressed together to have anything functional.
"should"
  items are highly valuable and would like to consider them in this PAR.
- SCh: Then we need to be careful about the "musts".
- AB: R12 should not be a "must". R17 should be a "must".
- GV: Access from testbench in R17 through VPI is from
non-SystemVerilog testbench.
  Any hierarchical references, forces, etc. in SystemVerilog would have
to be defined.
  VPI needs to go through SV-CC and always lags core functionality.
- AS: OOMR within SystemVerilog simply has to work.
- GV: <suggested rewording of R17>
- AB: So a probe referencing a real net would follow existing rules of
SV?
- GV: Yes, we would have to work harder to disallow it.
- JL: Aggregate vs. user-defined?
- GV: "aggregate" in LRM roughly means non-integral
- JL: "aggregate" basically implies a user-defined type. Do we mean
that the user-defined
  types have to be aggregates?
- GV: No.
- GV: Aggregate nets of integral components already exist; we should
not redefine them.
- AS: We should not explicitly require real components for resolution.
- JL: I want to be able to handle user defined types with no real
components.
- SS: X/Z state built in are important for writing proper resolution
functions.
- GV: X/Z as built in can be separate discussion in committee.
- AS: X/Z built in is core functionality in our opinion.
- GV: But let's discuss that in committee, not in the roadmap.
- AB: Can an aggregate contain an event?
- GV: Adding the "such as" leaves the door open for events.
- AS: Why would you consider an event on a net?
- AB: It would be important to have an event on a port. On a net it
would be important
  to schedule events. <simple example>
- AS: I understand that, but it seems hard to put all that into the
net.
- JL: The mechanism I used took advantage of synchronization of ADCs.
Programmable sample
  rate.
- AB: Strong methodology should not have these synchronization
restrictions.
- JL: Need event on net that is sensitive to when the net is read.
- GV: We need to get closure at the level of the roadmap, focus on
flexible core functionality.
  It doesn't preclude those discussions in the future.
- SS: What about seamless net connectivity with other languages?
- GV: Cross language connection is beyond the scope of any PAR. Our
domain of work is
  SystemVerilog.
- SL: E.g., connect two reals to one.
- GV: Also, real to integral conversion, which already exists, needs to
have mechanisms
  to differentiate between existing default and a custom threshhold
conversion.
- AB: What is meant by R12 and R15?
- SL: R12 is generic interconnect without specifying types of ends.
R15 is important
  if X/Z are built in.
- SL: Let's move to discussion of the priorities.
- MOL: Just getting scalar real-valued nets is a significant amount of
work and add value.
  Suggest aggregates be "strong should".
- JL: I disagree. Real scalars are insufficient.
- AB: Users will not agree.
- JL: Martin, your suggestion would mean we could settle on wreal.
That's too limited.
- MOL: What happens if at next summer we don't have agreement beyond
scalars? Can we not
  standardize?
- AS: No, it doesn't mean that. They are priorities; these can change.
- GV: User community is asking for aggregates; if we couldn't do it, we
could explain the
  roadblocks to finishing in current PAR and how to address these issues
later.
- SCh: This gets back to definition of priorities.
- GV: Working group is not trying to make things hard for us. They are
trying to ensure
  that we have reasonable goals.
- SL: "must" indicates capabilities that are needed for complete
solution. If we can't
  provide some of them, we need to have good answers.
- SCh: Atomicity is not clear in aggregate net section.
- GV: It is essential to deal with atomic aggregates and
compositionality. Working from
  simple up can complicate the composite solution.
- AS: Simpler things can have simpler solutions.
- GV: R12 - R14 can be "should" because these could be a lot of work.
- SL: These are definitely important for us.
- JL: R22 could be addressed by aggregates and resolution.
- GV: If we get aggregates right, we could leave an easy door for
things like UPF to walk
  through. We may not need to address it directly.
- SL: Some question of stewardship.
- AS: Some infrastructure may be needed in the language.
- AB: R21 would have been good.
- GV: R21 will potentially stress fundamental assumptions of digital
implementations.
- SL: Let's move on to relation to VAMS.
- FM: Aren't there two groups working on the same thing, the merger of
real AMS capabilities
  into SystemVerilog?
- GV: These are different things. SV-DC is focusing on discrete domain
modeling, no
  analog solving. Also, the nature of the merger is far from decided.
- AS: These are different things.
- FM: Don't we need to pay attention to what is going on with VAMS
wreal?
- AB: VAMS is looking to see what SV-DC will do.
- FM: Doesn't VAMS already have a lot of these net capabilities.
- SL: VAMS standard does not allow multiple drivers.
- FM: Does VAMS allow aggregate nets?
- GV: No, not atomic aggregates.
- JL: User defined resolution functions are not covered by VAMS work.
- FM: How the merger and relationship with VAMS will work is important.
- JL: Section 3 describes the relationship.
- MOL: It is advisable that SV-DC not create duplicate mechanisms.
- FM: Would like to see stronger statement about how SV and analog
models will
  work together.
- SL: We could have discrete models that never hook up to analog.
- FM: We need to make sure that they work together.
- GV: No, that is outside our domain.

Next week we will meet to approve the roadmap document. Issues should
be raised in
advance.

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