Subject: RE: [sv-ac] Final SV-AC Requirements Results
From: Erich Marschner (erichm@cadence.com)
Date: Tue Oct 08 2002 - 10:01:58 PDT
Adam,
I ended up voting 'no' on a number of requirements because they were still unclear as worded, or appears to be biased towards OVA (due to the use of OVA examples), or because the schedule will preclude our ever addressing them anyway. I suspect some of the contradictory patterns you've identified result from this sort of skew.
Note that the FVTC went through two rounds of requirements development - the first resulting in an approximate set of requirements somewhat like the current SV-AC requirements; the second being a refinement to ensure that the wording and meaning of each requirement was clear, and that each requirement was independent of other requirements, or at least that interdependencies were well identified. We did the second round of requirements refinement in part because, after the first vote, it was still unclear what we had actually voted for. If we were to do a second round of refinement on the SV-AC requirements, you might find fewer strange patterns of the sort you've identified here.
Regards,
Erich
-------------------------------------------
Erich Marschner, Cadence Design Systems
Senior Architect, Advanced Verification
Phone: +1 410 750 6995 Email: erichm@cadence.com
Vmail: +1 410 872 4369 Email: erichm@comcast.net
| -----Original Message-----
| From: Adam Krolnik [mailto:krolnik@lsil.com]
| Sent: Tuesday, October 08, 2002 12:50 PM
| To: fitz@synopsys.com
| Cc: sv-ac@eda.org
| Subject: Re: [sv-ac] Final SV-AC Requirements Results
|
|
|
|
| Good morning;
|
| I was reading the ballot results and saw a few strange
| voting patterns.
| Anyone care to comment... Any other strange results IYO?
|
| for/against votes
| 8/5 "R74" "Define recommended method to separate
| design code
|
| I'm surprised there wasn't much support for this - very cheap and
| easy to support (by users/tools.)
|
| 8/4 "R1d" "Assertions must be embedded directly
| in-line with
| 6/7 "R6" "Pass/fail statement for declarative
| assertions"
| Seems to conflict with
| 12/1 "R5a" "Declarative assertions as well as
| procedural"
| 14/1 "R5b" "Declarative assertions inside of
| modules/interfaces"
|
| While everyone was for declarative/procedural assertions and being
| part of a module or interface, there was less support for actually
| supporting the desire with an implementation. Is this freedom from
| specific requirements to allow DWG to define as they desire?
|
|
| 8/4 "R29a" "Optional user-specified unique name for
| assertions"
| 7/5 "R29b" "Mandatory user-specified unique name for
| assertions"
| Seems to conflict with
| 15/0 "R20" "Ability to define/declare reusable sequences
| (and
| refer to them by name)" "SM3, TF3"
| 13/1 "R80a" "Language shall define the status of
| specified
| named
| assertion(s)" "SD56"
|
| While support for naming sequences and status of named
| assertions was
| desirable support for naming of assertions was not very desirable.
| Somewhat strange too.
|
|
| Thanks all.
|
| Adam Krolnik
| Verification Mgr.
| LSI Logic Corp.
| Plano TX. 75074
|
This archive was generated by hypermail 2b28 : Tue Oct 08 2002 - 10:03:44 PDT