Subject: RE: Proposed requirements for SV assertion API
From: Bassam Tabbara (bassam@novas.com)
Date: Thu Aug 15 2002 - 18:56:22 PDT
Hi Joao,
> 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.
Ok, I owe you an explanation. What I am thinking is that callbacks have
"levels of access". for example:
assert_api_register_callback(assertion_handle, ON_FAIL, READ_ONLY,
my_routine);
my_routine will be called on FAIL of assertion but once called it can
only -READ- the data of the assertion. It is NOT able to -control- the
assertion e.g. reset/enable/disable the assertion.
Other access levels could be CONTROL (a.k.a. "write") ... and so on....
after the callback the routine is allowed to disable the assertion, or kill
attempt etc... if it so wishes.
The idea is to try to classify the types and level of access for
optimization/performance/classification purposes (much like we do/will do in
PLI/VPI/DFLI...)
(FYI in your last email you state something similar to this effect about how
much "data" (requested ahead of time) the routine registered through API can
see (all expressions for some attempt etc..)).
Again, my comment concerns the "control" vs. "callback" interaction.
Obviously the intricacies of this interaction are crucial... callback
reasons and control modes may grow in the future, so we should have a robust
expandable foundation as you propose.
Thx.
-Bassam.
This archive was generated by hypermail 2b28 : Thu Aug 15 2002 - 19:08:48 PDT