Subject: RE: [sv-ac] SV-AC 10/31/02 Meeting Minutes
From: Stephen Meier (Stephen.Meier@synopsys.com)
Date: Fri Nov 01 2002 - 16:21:56 PST
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 : Fri Nov 01 2002 - 16:23:14 PST