Subject: RE: [sv-ac] SV-AC 10/31/02 Meeting Minutes
From: Miller Hillel-R53776 (r53776@motorola.com)
Date: Sun Nov 03 2002 - 02:41:02 PST
Stephen,
Thanks for your answer.
I see that we agree on one thing which is regular expressions add
expressive power along side complexity.
The question is then, do we need this expressive power. Seldom
is the case when dealing with complexity can really work. Why
can't we just "keep it simple" ?
Motorola has succeeded semi/formal verification for the last
6 years using a language without regular expressions.
Sugar and OVA where invented by geniuses for geniuses.
How about engineers developing an assertion language for engineers ?
I do not want to be technically challenged. I want a good solution and
I want it now.
Best Regards
Hillel
-----Original Message-----
From: Stephen Meier [mailto:Stephen.Meier@synopsys.com]
Sent: Saturday, November 02, 2002 2:22 AM
To: Miller Hillel-R53776; 'Stephen Meier'; sv-ac@eda.org
Cc: Miller Hillel-R53776
Subject: RE: [sv-ac] SV-AC 10/31/02 Meeting Minutes
Hillel:
Thanks for your comments and questions.
At 10:28 AM 11/1/2002 +0200, Miller Hillel-R53776 wrote:
>Hi,
>
>Is there any reason why we are locked onto regular expressions ?
>I do not see a "really explicit" requirement for regular expressions (it
>seems to be imposed as the only choice).
My interpretation of the requirements ballot indicates nearly unanimous
support for regular expressions to define sequences. In specific, R23
refers to the ability to combine sequences using logical operators. In
addition the process DWG has been using it to initially focus on
intersection of Sugar and OVA and thus since they both have regular
expressions we have preserved the capability.
>I agree that they are very (maybe too) powerful, however, pratically
>speaking, regular expressions
>always have seemed problematic to me, unless you restrict them.
Expressive power creates complexity, that is indeed the tradeoff.
It is possible to create a policy on to restrict use of features as
appropriate for a given methodology.
>I have yet to see the following problems solved and others when using regular
>expressions with no restrictions:
>
>- Debugging tools, how would one view the progress within
> a regular expression with respect to the behavior of the design's
> signals.
I believe that several companies are investing in development of debugging
technologies. These tools can identify sub-expressions and display their
results and also track multiple evaluations. I have seen some early
technology demonstrations of these and I see potential for getting to
workable solutions.
>- Coverage tools, how would assertion code coverage tools work ?
> How can you debug coverage when you cannot find the exact condition
> that is not being activated thru some debugging tool.
Coverage tools can measure # of completions of sequences and successes,
failures, and may also possibly report the variety of paths through
sequences. The debugging technologies for assertions above would be
utilized to debug and analyze coverage results.
>- Simulation completion, how do you mark which assertions started
> evaluating and did not complete due to simulation completion.
Simulation tools will likely report which assertions were launched but not
completed as ongoing status. The SV assertions standard will not legislate
tool behaviors/reports like this.
>- How can you test for vacuity of asserts containing regular expressions
>using simulation only ?
Coverage tools are performing some vacuity checks (for implications) today.
>There have been a number tools that have been provided that use regular
>expressions
>in the tools assertion language. I have asked these questions to the tool
>providers and never received
>satisfying answers.
Sometimes the language definition presents tool challenges that take time
to develop and mature. Our focus has been to provide a reasonable tradeoff
between providing expressiveness and ability to have tools implement the
support.
>Am I missing something ?
No these are technical challenges the tools face and it is an engineering
trade-off.
>Thanks
>Hillel
>
>-----Original Message-----
>From: Stephen Meier [mailto:Stephen.Meier@synopsys.com]
>Sent: Friday, November 01, 2002 8:38 AM
>To: sv-ac@eda.org
>Subject: [sv-ac] SV-AC 10/31/02 Meeting Minutes
>
>
>Hello:
>
>Please find meeting minutes for SV-AC 10/31/02 meeting attached.
>
>
>Steve Meier (stephen.meier@synopsys.com) W: 650-584-4476, Cell: 408-393-8246
Steve Meier (stephen.meier@synopsys.com) W: 650-584-4476, Cell: 408-393-8246
This archive was generated by hypermail 2b28 : Sun Nov 03 2002 - 02:41:46 PST