Subject: RE: Proposed requirements for SV assertion API
From: Bassam Tabbara (bassam@novas.com)
Date: Wed Aug 14 2002 - 17:02:25 PDT
Looks good, thanks Joao, couple of comments.
>
> Assertion API Requirements:
>
> 1- Provide means (eg iterator) to obtain every assertion within a
> given instance
>
> 2- Provide means to obtain every assertion associated with a given module
> (sum of all assertions in all instances of the given module)
Let's just say it's: 2- Provide means to obtain every assertion associated
with a given module
It should not be "sum...", it's just things bound to module instead of
instance (i.e. module ... { })
So it is really "intersection..." but let's not even say that. Just keep it
for module bound, we have the instance bound in 1- above.
> 3- Provide means to get handle to an assertion by name
full name (meaning full_design_instance_name.assertion_name)
> 4- Provide means to control assertions:
> 4.1 enable an assertion
>
> 4.2 disable an assertion
>
> 4.3 reset an assertion
We are still working in SV-AC on "reset"/"accept on"/"reject on"/.... so we
may need to add/remove a few things here..
> 6- Provide means for applications to register callbacks for:
What happened to 5- ? :-)!
** We probably need to classify callbacks (r/w/...)... Some callbacks are
"read" (you cannot control assertion), whereas others are "write" (need a
better word of course, but here you can enable/disable/reset/.... the
assertion). Essentially the idea is the relationship between callbacks (of
success/fail/...i.e. dynamic occurrences) and control.
> 6.1 assertion success
>
> 6.2 assertion failure
>
> 6.3 assertion attempt
>
> 6.4 assertion being disabled
>
> 6.5 assertion being enabled
>
> 6.6 assertion being reset
Are these the only dynamic info ? What about things like assertion "local"
vars (init/assign..), these objects will need to be available for access as
well ... what else besides vars ?
> 7- Provide means to obtain per assertion static information:
>
> 7.1 assertion type (eg check/forbid/event/...)
>
> 7.2 assertion attributes (eg assume/guarantee/...)
Can we call this one "assertion modes" (or directive modes ...), I'd rather
reserve attributes for 7.4
> 7.3 source information (source file, line number, ...)
>
> 7.4 clocking signal/expression
We need to generalize this one. "attributes", clocking signal is one
attribute, there are others (weak/strong clock), others ? Of course, we
should define how far we should go here ... what's is useful info for the
scope of this API, and what's too much...
> 7.5 instance in which assertion exists
>
> 7.6 name of assertion
>
> 7.7 module in which assertion declared
>
> 9- Provide means to obtain information about a specific success/failure:
> 9.1 time assertion attempt started
>
> 9.2 signal/expression where success/failure detected
>
This archive was generated by hypermail 2b28 : Wed Aug 14 2002 - 17:14:26 PDT