Get documents about "P1801 unapproved minutes 20100511
Document Sample
IEEE P1801: 11 May 2010 Meeting Minutes:
not approved as of 11 May 2010.
Action Items for Next meeting:
Gary to email Judith (and the rest of the group) IEEE-SA corporate membership
information. http://standards.ieee.org/sa-mem/corp_overview.html
Please review {} placement in set_power_state
Please consider buf primitive use as a power domain driver
Connection details: at bottom See also
http://www.accellera.org/apps/org/workgroup/p1801/calendar.php
Attendees:
P1801 Attendance
Name Entity
11-May-10
16-Mar-10
30-Mar-10
18-Aug-10
13-Apr-10
27-Apr-10
16-Feb-10
2-Mar-10
9-Nov-09
9-Dec-09
2-Feb-10
5-Jan-10
9-Oct-10
1-Sep-10
Official
o
o
o
o
o
o
o
o
o
o
X Yatin Trivedi
X X X X X E E Cary Chin Accellera
X X Gary Delp
X X X X X X X X X X X X Gary Delp Spirit
X X X X X X X X X E X X X Shir-Shen Chang
X X E X X Cary Chin Synopsys
Jim Sproch
X X X X X X X X X X X X Erich Marschner
X E X Rick Koster Mentor
X X John Shields
- X X X X E X X X E X X X John Biggs ARM
X X X X X X X X X X X Rolf Lagerquist
TI
X Minh Chau
X Prasad Subbarao LSI
X X X X X X X X X X X X Judith Richardson AMD
X - X X E X X E X X X Knut Just
Infineon
X Juergen Karmann
X X - Michael Rifani Intel
X - X X X X X X X X Jon Worthington
Magma
X X X Raghunandan Rao
- X X X X Ben Beaumont Azuro
- - X X X X X X X X X Don Mills
Microchip
X Pedro Ovalle
Technology
Tim Jordan
X X X Fred Jen
X Ramesh Chandra Qualcomm
X X Sorin Dobre
Key: X – in attendance, v - vacation and they told us, e- excused, p – proxy present
No annotation or – not present
Agenda
BoilerPlate:
o Patent policy
o Action Items from previous meeting
Primary Topics:
Patent Policy
All attendees are aware of IEEE Policy, the IEEE patent Slide Set was presented, and the
call for essential claims was made at the meeting.
There were no responses to the call for known essential patents relevant to this proposed
standard.
Previous to the meeting: Review minutes from previous meeting
Approval of agenda
o XXX moved to approve the agenda; XXX seconded
o Abstentions
o Approved by acclamation
Action Items from previous meeting:
PG Document:
Waiting for confirmation from IEEE on the process to achieve approval.
Shir-Shen to confirm with Liberty™ use of that document text.
Reply received.
Looking for clarification on how to have technical experts have ongoing
participation, p1735 is also looking for this.
Looking for clarification on email lists, can only paid entities participate, can
Accellera members inherit access?
Clarification on copyright use pending.
Currently DASC sponsors workgroups are running with previous policy with
DASC permission.
Clarification pending on DASC membership providing access to the group. (Gary
to check with Stan)
Agenda:
BoilerPlate:
o Patent policy
o Action Items from previous meeting
Primary Topics:
o IEEE Policy review
o Proposal from Si2 – Interoperability Guide
o Issues sub-committee
Erich update on states
PG_Pin mapping update
o Issues review
Meeting Minutes:
Roll call; 9/10 companies 9 people
10 minutes after the hour quorum determined, meeting called to order.
Patent Call: http://standards.ieee.org/board/pat/
No patents revealed.
Agenda moved for approval by Erich Marschner, seconded by Knut. The motion was
approved by acclamation.
Minutes of previous meeting 4/13/2010. motion to approve previous minutes made by
Judith Richardson, seconded by John Biggs, Prasad, Erich, and Ramesh abstained, but the
motion still passed by acclamation.
Waiting for confirmation from IEEE on the process to achieve approval. –
received confirmation of the viability of the proposed process and likelihood of
approval.
Shir-Shen has confirmed with Liberty™ that we may use that document text.
Gary to email Judith (and the rest of the group) IEEE-SA corporate membership
information.
Looking for clarification on how to have technical experts have ongoing
participation, p1735 is also looking for this.
Looking for clarification on email lists, can only paid entities participate, can
Accellera members inherit access?
Clarification on copyright use pending.
Currently DASC sponsors workgroups are running with previous policy with
DASC permission.
Clarification pending on DASC membership providing access to the group. (Gary
to check with Stan) – used for process oversight.
For the time being we may carry on, with official approval from CAG, DASC,
and IEEE-SA. (keep calm and carry on) see:
http://en.wikipedia.org/wiki/Keep_Calm_and_Carry_On
Please decide if you would like to consider input from the Si2 Interoperability Guide
available for unencumbered download at: http://www.si2.org/?page=1131
There is also a set of questions on the set_isolation –location switch located at:
http://www.si2.org/?page=1047
State discussion
(see Issue# 2602)
Group assertion: Power states may be overlapping and the standard language must
accommodate this. There are a number of place that assume uniqueness, these need to be
extended to accommodate the multiplicity of truth.
1. Issues in the algorithm for determination of "the power state" of a supply set (pg 45 of 234)
a. Bidir implication between logic expr and supply expr in determining power state of a supply set
- inappropriate
b. missing not in a)1)v) ?
c. incorrect else structure ("otherwise")
d. how does UPF package function set_power_state interact with this?
Because we can set the leaf level and the top level we have a checking capability.
In simulation we have a constraint solving problem. If we set a system state, it may imply
contradictions in leaf levels.
2. Issues with power state uniqueness
set_power_state needs to take a list, and be able to fail if a contradiction is specified.
The list to include true, false, and don’t care.
The constraint solving problem of finding a set of supply net value that work.
Get_power_state should return a list of true power states, and may include logic/supply filters.
A possibility is to express this in the form of sv constraints (at least to enable thinking about the
problem.)
a. UPF package function set_power_state - should enable/disable a given power state, non-
exclusively, not set to one
note that in this case, power states are treated as unique, when everywhere else they are not
(this is different from simstates, for which there is an algorithm to select one of many that can
apply)
3. Issues with refinement semantics
a. Refinement of logic expressions and supply expressions must be limited to conjunction -
correct?
b. In general, can the top level of any logic expression or supply expression involve anything
other than conjunction?
c. A state previously marked legal can be later marked illegal (and illegal overrides), but not vice
versa. Is this consistent with refinement semantics? What are the implications for power states
that reference illegal states?
d. How do UPF package functions factor into the predicate/constraint relationship?
4. Conceptual issues
a. There is a difference between power states as a set of possible values and power states as the
current value
- better terminology is needed to distinguish between the two
b. There is a need to define names to which system power states can be attached
- analogous to PST names, but it would be better to view these as (sub)system names
c. General problem - semantics are defined in terms of gate-level netlist constructs (e.g., "nets"),
which are hard to interpret at the RTL level
5. Syntax questions
a. There are two forms of reference to supply values - can we combine them?
b. Expressions are very restrictive - limited to comparison to literals - can we generalize this to
allow reference to objects?
Page 45/234
The power state of a supply set is determined as follows:
a) After the signal network is updated, including the supply network (see 5.2.2) and prior to evaluation
of the power state of power domains:
1) If any named power state of the supply set has a non-empty -supply_expr, then
i) Foreach power state with supply expression {
The -supply_expr for is evaluated.
ii) The supply set is in a named power state if the -supply_expr for that named power state
evaluates True. Zero, one, or more named power states may match (its -supply_expr
evaluates True). (The predefined DEFAULT_NORMAL and DEFAULT_CORRUPT
power states are named power states.)
iii) In simulation, it shall be an error if any named power state matches and the matching state
is defined as an illegal power state.
Implementation tools may presume illegal power states do not occur.
iv) In simulation, it shall not be an error if the -logic_expr for any matching named power state
does not evaluate True, see 5.4.3.3. (because it may contain additional terms not included in the
supply_expr)
Implementation tools may presume -logic_expr evaluates True for any matching named
power state. – implementation tools are not required to check the truth of the logic_expr
v) In simulation, it shall be an error if the -logic_expr evaluates True for a non-matching
power state (i.e., a power state for which -supply_expr does not evaluate True).
Implementation tools may presume -logic_expr evaluates False for any non-matching
named power state.
}
2) Foreach named power state with only a –logic_expr {
the supply set is in the named power state if its -logic_expr evaluates True. Zero, one
or more named power states may match.
}
Note: When both a logic_expression and a supply expression are given, they may differ only in interval or
duration of application. The logic expression becomes an operational constraint. – Additional words are
needed.
Gary to locate portion of the spec that discusses the time basis of comparison.
Issues review:
(see Issue# 3042) The members of the committee will poll their delegations on the need
and cost to include the ability to reference at the sub-module level.
Ask about Named primitives (not named as a design element in the current spec)
Ask about named Always blocks (not considered a design element in the current
spec)
Ask about named process statements (not considered a design element in the
current spec)
labeled: statements in SV (not considered a design element in the current spec)
There are many optimizations that blur the boundaries of these names, what are the
implications?
(see Issue# 3043) The discussion centered on the behavior of the buf(primitive) is it
visible in a domain or not. Good arguments in both directions. It is either a continuous
assignment equivalent, OR it is a way to explicitly declare a driver in a domain.
Cary Chin to collect consequences, others should as well.
(see Issue# 3040) there may be a change that we want to make; we should at least
recognize that we have an inconsistency in the parameter passing syntax of the
add_power_state command; the –state parameter takes two arguments, a symbol name
and a list (potentially explicitly empty)
http://html.sourceforge.net/doc/tcl/ParseArgs.html
add_power_state object_name
{-state state_name {[-supply_expr {boolean_function}] [-logic_expr {boolean_function}]
[-simstate simstate] [-legal | -illegal] [-update]}}*
[-simstate simstate][-legal | -illegal]
[-update]
Going forward, the name value pair is the designated syntax for new commands.
We may want to allow the updated syntax, but still require support for the syntax as
given. We have not asserted a decision; it is not in violation of tcl.
At least several examples are required.
Erich moved to adjourn the meeting, Judith seconded the motion; all acclaimed the
wisdom of the motion by hanging up at 10 minutes past the hour.
References:
o Schedule expectations
First Ballot June 2011
New version December 2011
TBD: Sense of the workgroup straw man for TI’s issue.
o Activity expectations
Near term clarifications
Potential means to disconnect net
FAQ
Publishing a “Sense of the Workgroup living document”
Interpretations/clarifications of the current standard
Current view of any additions to the standard in the next
version.
Accumulate decisions of the work group
Publishing externally – may be a subset document.
Meeting details:
Topic: IEEE P1801 Work Group
Date: Alternating Tuesdays starting 12 May 2009
Time: 10:00 am, Central Daylight Time (GMT -05:00, Chicago)
Time: 8:00 am, Pacific Daylight Time (GMT -07:00, San Francisco)
Time: 4:00 pm England, 1800 CET, 8:30 pm India
You can contact me at:
Delp.gary@mayo.edu or Gary.Delp@gmail.com
+1-507-293-1547 (mayo) 1-507-289-7276 (home office – usually forwarded)
+1 563-289-7276 (Google Voice)
Group: IEEE P1801
Primary: Synopsys contributed:
Time: 9:00 am, Pacific Daylight Time (GMT -07:00, San Francisco)
Meeting Number: 330 335 748
Meeting Password: ieee09
-------------------------------------------------------
To join the online meeting
-------------------------------------------------------
1. Go to https://synopsys.webex.com enter meeting number 330335748
2. Enter your name and email address.
3. Enter the meeting password: ieee09
4. Click "Join Now".
-------------------------------------------------------
To join the teleconference (MeetingPlace)
-------------------------------------------------------
Meeting ID: 44217
Call Synopsys MeetingPlace at:
4-6338 (Internal)
1-650-584-6338 (Local/International)
1-888-813-5316 (Toll-free)
Press 1 to attend the meeting
Enter the Meeting ID “44217” followed by #
Press 1 to confirm the Meeting ID
Speak your name followed by #
Press 1 to attend the Meeting
7. Local dial-in numbers
Armenia, Yerevan +374.10.492609
Canada, Mississauga +905.273.8402
Canada, Nepean +613.221.8603
Switzerland, Zurich +41.44.567.1551
Chile, Santiago +56.2.714.6898
China, Beijing +86.105.986.0609
China, Shanghai +86.212.307.2214
China, Shenzhen +8675582519810
Germany, Aachen +49.240.756.3610
Germany, Munich +49.899.932.0192
Denmark, Copenhagen +49.899.932.0192
Finland, Espoo +49.899.932.0192
Finland, Tampere +49.899.932.0192
France, Montbonnot +33.4.56.38.48.09
France, Montpellier +33.4.56.38.48.09
France, Rungis +33.1.45.12.06.12
France, Sophia +33.4.97.23.97.06
United Kingdom, Livingston +44.15064.86027
United Kingdom, Reading +44.1189.651119
Sweden, Stockholm +49.899.932.0192
Hungary, Budapest +49.899.932.0192
Ireland, Dublin +353.1.4368831
Israel, Herzelia +49.899.932.0192
India, Bangalore +91.80.401.88823
India, Hyderabad +91.40.40.331016
India, Nodia +91.80.401.88823
Taiwan, Taipei +886.2.3725.5705
Taiwan, Hsinchu +886.3.558.1800
Japan, Tokyo +81.3.5746.1339
Japan, Osaka +81.3.5746.1339
Singapore, Singapore +65.6393.7140
South Korea, Seoul +82.2.3404.2701
-------------------------------------
Cary Chin
Director, Technical Marketing
Low Power Solutions, Synopsys, Inc.
+1 650 584 4217 cary@synopsys.com
