Subject: Re: Proposed requirements for SV assertion API
From: Joao Geada (Joao.Geada@synopsys.com)
Date: Thu Aug 15 2002 - 08:19:06 PDT
Hi Bassam,
thanks for the comments.
bassam@novas.com said:
> 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.
Good point. I agree.
bassam@novas.com said:
> > 3- Provide means to get handle to an assertion by name
>
> full name (meaning full_design_instance_name.assertion_name)
Yes, one way or another the name has to be a fully qualified name.
bassam@novas.com said:
> > 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..
Whether there are reject/accept constructs on in the language itself is one thing, but
I really believe that the API should be able to exert some "low-level" control
over the assertions. In this sense:
enable: allow the assertion to run as usual
disable: stop the assertion from running (& reset any internal state)
reset: behaves as disabled immediately followed by enable.
(in a sense: discard all current attempts, start new attempts on next clock)
bassam@novas.com said:
> ** 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.
I am not sure exactly what you mean here.
bassam@novas.com said:
> > 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 ?
Good catch.
There are really a couple of areas of both static and dynamic information
for which tools will need access that I failed to include in the requirements:
+ static information (added to item 7)
+7.8: list of all HDL expressions referenced by an assertion (static drivers)
+10 - dynamic information on per attempt basis (new item 10)
+10.1: list of all HDL expressions actively driving the current state of the assertion
(on a per attempt basis: ie all expressions that were used by the assertion
on its last clock tick)
+10.2: values of all assertion "local" variables (this will depend, of course, on
the kind of local variables that will be present in the SV assertions)
+10.3: trace of expressions over time matched by the an specific attempt of an assertion
NOTE: there will have to be significant limitations on this requirement, eg
can only be provided for specific assertions and for a specific attempt and only
if this information is requested ahead of time.
Without limitations this requirement would kill all performance and capacity.
bassam@novas.com said:
> > 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
OK. We should use whatever terminology is consistent with the assertion standard.
bassam@novas.com said:
> > 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...
Is the clocking signal an attribute or a "driver" ?
I consider "attributes" to be things are generally informational hints to
tools, and specifically to be things that should have no impact functionality/semantics.
Both clocking and weak/strong clock have both functionality and semantics, so
in my opinion these are "properties" of an assertion rather than "attributes".
But moving away from the terminology issue, I agree that there are probably
a number of other "property/attribute/..." things that could be provided by
the API _and_ that we should be careful on how many of these are made part of the
API requirements.
Joao
==============================================================================
Joao Geada, PhD Sr. Staff R&D Engineer Verif Tech Group
Synopsys, Inc TEL: (508) 263-8083
154 Crane Meadow Road, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
This archive was generated by hypermail 2b28 : Thu Aug 15 2002 - 08:21:05 PDT