Harry, Moshe,
I provided a bit more information about these two in the detailed notes
at the end of the minutes. I'll repeat that here and explain further:
> 4. Review and Clarify Requirements Prioritization
>
> Reqs 1-8 all talk about what set of operators
and data types
> are provided. The sense of the discussion seems to be that we
> adopt a standard that does NOT address the atomic level
> (data types and expressions), and then as an option define a
> set of data types and operators to implement.
The original requirements list included requirement 1, which said
"Support rich data types and expressions (using syntax which is
independent of VHDL or Verilog syntax)", followed by requirements 2
through 4 which covered supporting Verilog, VHDL, and other (e.g.,
SystemC, SuperLog) data types and expressions, and then requirements 7
and 8 which effectively amplified requirement 1. In the Paris meeting,
we discussed the tradeoff between supporting HDL types and expressions
(reqs. 2,3,4) vs. defining a new expression syntax and semantics (reqs.
1,7,8). Going into the discussion, the poll indeed suggested that
requirements 3 and 4 both be dropped, leaving only requirement 2 (support
for Verilog types/expressions) among the HDL support requirements. But
there was some dissension about focusing only on Verilog (given that
Accellera covers both VHDL and Verilog), and some concern about defining
a new expression syntax/semantics. Limor suggested that we focus on
defining the temporal language independent of the predicates it covers,
and that later, separately, we could define how predicates can be
expressed within the property language - e.g., by using HDL expressions,
or by using HDL-independent expressions. This suggestion seemed to be
acceptable to the group. I interpreted the overall discussion to
indicate a consensus that a requirement exists for a rich set of data
types/operators/expressions such as are found in HDLs, but that no
specific requirement exists (yet) regarding the form of those
expressions. I tried to reflect that in the minutes (above).
> Req. 57 - declared Nice
Going into the meeting, the poll stood at E:2, N:7, D:8, so while the
majority said "drop", nearly the same number said "Nice to have". As I
recall, Harry ruled this requirement to be a "Nice to have", and no one
objected.
I hope this helps clarify the above items.
Regards,
Erich
At 09:42 AM 8/4/01 -0500, Harry Foster wrote:
>
>> Harry, as far as I can see, requirements
>> 4 and 57 should have been classified as
>> dropped according to the vote.
>
>Hi Moshe,
>
>Actually, the initial vote (which is reflected in
>the Excel spreadsheet turn out to be different than
>what we decided in Paris for these two requirements).
>I don't recall the reasons, be we decided to change
>4 and 57 in Paris. If you have concerns with these
>two requirements, I suggest that you vote to accept
>everything else--and that we move these two
>requirements to the Undecided category which
>will be reviewed again in the next meeting.
>
>As Ed Clarke suggested, these will enable us to
>approve as many requirements as we can. Then the
>committee can focus on the remaining (hopeful small
>set) of requirements that are controversial.
>
>Best regards,
>
>-Harry
>
>
>
-------------------------------------------
Erich Marschner, Cadence Design Systems
Senior Architect, Advanced Verification
Phone: +1 410 872 4369 / +1 410 750 6995
Email: erichm@cadence.com / erichm@home.com