Minutes of
the
This
is my list of attendees and voting status. Please
submit corrections to
johny.srouji@intel.com:
(aaaaaaaa________) Johny
Srouji (Intel) *
(aaaaa__aaa_aaaaa) Cliff
Cummings (Sunburst Design) *
(___a___aaaaaaaaa) David
Smith (Synopsys)
(aaaaaaaaaaaaaaaa)
(aaaaaaaaaaaaaa_a) Kevin
Cameron (NSC) *
(aa_a_aaaaaaaaa_a) Steven
Sharp (Cadence)
(__a___aaaaa_aaa_) Dennis
Brophy (Model Technology)
(_____a__a___aaaa) Tom Fitzpatrick (Co_Design)
(aaaa_aaaaaa____a) Gord
Vreugdenhil (Synopsys) *
(aaaaaaaaaaa_____) Brad
Pierce (Synopsys) *
(aaaaaaaa_a____aa)
(aaaaa_aa_______a) Don
Mills (LCDM Engineering) *
(________aa__aa__) Mike
McNamara (Verisity)
(__________aaaaaa) Stefen
Boyd (Boyd Technology)
(_____a_____aa___) Medi Mohtashemi (Synopsys)
(___________aa___) Paul
Graham (Cadence)
(_____a_____aaaaa) Peter
Flake (Co_Design)
(___________aaaa_) Simon
Davidmann (Co_Design)
(___________aa__a) Heath
Chambers (HMC)
(____________aaa_) Dave
Kelf (Co_Design)
(_a_a_a_______aaa) Vasisilios Gerousis (Seimens)
(aaaaa_a_________) Dan
Jacobi (Intel) *
(_____a__________)
Stuart Swan (Cadence)
(_____a__________)
Adam Krolnick
(a_aaaa__________) David
Rich (Synopsys) *
(_____a__________)
Yong Xiao (Synopsys)
(aaaa_a__________) Jay
Lawrence (Cadence) *
(aaa__a__________) Matt
Maidment (Intel)
(_____a__________)
Wolfgang Keil (Synopsys)
(____a___________)
Alec F. Stanculescu (Fintronic)
*
indicates eligible to vote on consensus issues
**
SV-BC BNF meeting on
Minutes
·
Review of our F2F minutes for the
·
Review of the BNF specific meeting for the
·
SV-BC F2F Meeting: Johny moves to have a joint meeting w/ sv-ec on the 27th
(afternoon). Agree: Gord, Cliff, Dave, Steven, Karen, Kevin. Need to check w/
Dave Smith on relevant topics and need.
·
Discussion of open items which were passed from SV-EC:
1.
Slice with Unpacked Arrays
Issue Description & Background
This is regarding the use of slices with unpacked
arrays. All of the examples in 3.0 were with packed data. Was it intended that
unpacked data could be used as well?
It is not clear in Section 4.4 which is supported.
The first paragraph refers to packed array or integer type. There are
additional references to both packed and unpacked. The example we want to
verify is:
string
d[5:1] = { "a", "b", "c", "d",
"e" };
string
p[*];
p =
{ d[1:3], "hello", d[4:5] };
which
would result in: "a" "b" "c" "hello"
"d" "e"
Is
the use of the slice legal?
Resolution/Discussion Outcome
We discussed Dave Rich proposal which was sent on Jan
13, and posted under: http://www.eda.org/vlog-pp/sv-bc/hm/0331.html.
It was noted that the
issues are not with slices, rather than the definition of literals. Dave raised
the concatenation versus a literal issue. When you have a packed array or
structure then ops is the concatenation and when talking about unpacked
objects. We’re talking about a literal.
As to the following
example,
p = { d[1:3],
"hello", d[4:5] };
What’s wrong is that there should be a cast. You can
use a slice of unpacked array but not as an expression. “hello”
is a packed object not an array of characters.
After further
discussions, we came up w/ the following answers:
·
Is
taking slices of packed arrays valid? The answer is YES, but there is a whole
bunch of issues. We need to define what’s legal wrt spec 3.1. There is no way
in 3.0 to concatenate unpacked arrays.
·
Can
you use a slice of unpacked arrays? YES, but there is no way to concatenate
unpacked arrays. This is inconsistent to the semantics of other “{“ in SV. This may cause confusion.
Conclusions
It was agreed that Dave Rich will come up w/ a
modified proposal and others will comment on it, before we vote in our next
tele-call.
Updates
Dave submitted a modified proposal on Feb 4th,
and posted under: http://www.eda.org/vlog-pp/sv-bc/hm/0436.html.
2.
Issue with Enumerations
Issue Description & Background (as submitted by David Smith)
It appears that the SV-BC has recommended that all
static casts perform run-time checking (costly) while the SV-EC has recommend
that the static casts perform a fast coercion that always copies the value
regardless of it being either a legal enumerated value or within the range. In
order to provide type checking the dynamic cast is provided.
This conflict should be resolved.
Resolution/Discussion Outcome
The committee did not find anything that passed
previously when interpreted in context (that all static casts perform run time
checking)
Cliff pointed that user input and perspective is
important. Matt pointed that if the tool does not create the assertion and
check the nature of the cast a user will have to do it, so it is better for the
tool to do that.
It was proposed to ”Do
static checks only and not do any run time checking”. Dave Rich moves to
accept it. Cliff seconds. Agree: Kevin, Dan, Brad, Dennis.
Oppose: Steven Sharp. Abstain: Jay, Karen, Francoise,
Gordon, Matt, Johny
Conclusions
It was decided that Dave Rich will put a detailed
proposal. The static checks are not clear. We are checking types not values.
Updates
Dave
submitted a modified proposal on Feb 4th, and posted under:
http://www.eda.org/vlog-pp/sv-bc/hm/0434.html