Re: SV APIs (Assertion)

Subject: Re: SV APIs (Assertion)
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Oct 02 2002 - 03:20:53 PDT

Hi all,

since an example says sometimes more than one million words, I am trying to explain what I learned from Kevin's statements. Hope this is a good checkpoint and will help to get the discussion going. Kevin, please correct me, if I am wrong.
This is just a trial to proof whether we are all talking about the same thing.

A) According to Joao, the donation provides the following functionality
   Ja) means to obtain static information about the assertions defined within the code
   Jb) means to request callbacks on assertion and engine events
   Jc) commands to control the assertion engine and/or specific assertions
B) Kevin proposes to
   Ka) implement the control functionality in SV (I assume this refers to Jc)
   Kb) do call-backs as regular events in SV (I assume this refers to Jb)

How could this look like? I use in the following the assertion definitions in the SV 3.0 LRM, despite the fact that this can/might/will change. Joao stated, that the Assertion API should be mostly independent from the assertion language ... 

---

This set of examples tries to cover mostly the proposal Kb)

SV defines four types of assertions, I will only pick two of them for ths example
i) Immediate assertions having the syntax:
   [ identifier: ] assert( expr ) [ pass_statement ] [ else fail_statement ]
   It test the given expression when the statement is executed in the procedural code.

   I am not sure what Kevin means with his proposal, but in my eyes the best method to implement a functionality like Jb) on top of SV+DirectC [or any other PLI/VPI i/f] would be:
    - attempt event: call a DirectC function before the assert() statement
    - success and failure events: call a DirectC function as part of the pass_ and/or fail_statement
    - control event: <no idea how this could be done for a specific assertion ...>
    - initialization, finish events: <call a DirectC function after the $asserton, $assertoff, $assertkill statement>

   OR does he propose that any invocation of the assertion engine generates an event associated with the assertion identifier, that can later used to control an invocation of a directC function ? :

   @(identifier) directC
   [similar applies here as above, although I am not clear on how we want to distinguish between attempt, success and failure events, not to talk about control, initialization and finish events]

ii) clocked_strobed_assert having the syntax:
   assert_strobe ( expr_sequence ) step_control restricted_statement_or_null [ else restricted_statement_or_null ]
   The example in the SV LRM for this kind of assertion is (see page 47):
      a9: assert(req1;gnt;!req1) @@ (posedge clk) ;

   <Here I would like to ask Kevin to provide an example on how to code the corresponding callbacks for attempt, success and failure events; IMHO this is either pretty similar to the above or I am pretty wrong on everything.

---

According to Joao Jc) permits to do
 . Reset, stop or terminate assertion engine (SV has $asserton, $assertoff, $assertkill)
 . Reset, disable, enable a specific assertion (SV has disable)
 . Terminate current assertion attempt(s) leaving assertion active (no SV equivalents)

-------------------------------------------------------------------------------------------------

So what is this excursion good for? Let's see whether we can agree on one or even more of the following statements:
a) There is no functionality currently within SV and the existing API's to retrieve the information we should be able to get from Ja)

b) There is a way to implement most of the Assertion API callbacks directly within SV by calling DirectC (or however we name this) functions from the SV code (attempt, success, failure events)

c) Implementing some of the Assertion API callbacks directly within SV by calling DirectC (or however we name this) functions from the SV code might would not be closely linked to the assertion, but to the corresponding control function (control,
initialization, finish events)

d) It would be required to change the SV code to attach a debugger or another third party tool that needs to know about assertions to a simulation

e) The functionality provided by the assertion API and SV does not match for Jc).

Last but not least I would like to ask Kevin to elaborate a little bit more on his last statement:
"If all the required functionality of C is supported in SV, then the issue is what APIs are need to make the compiled SV code portable between simulators (which takes me back to the topic of ELF libraries and routine naming conventions)."
Being a SW engineer I know and understand ELF, but I see absolutely no relationship to this and how it could help us here. Please educate me a little bit.

Regards,
Michael

--
Quote of the day:
"Better to remain silent and be thought a fool than to speak out and remove all doubt."
[Abraham Lincoln (1809-1865)]

NOTE:
The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.

The information contained in this email has been classified as:
Motorola General Business Information (x)
Motorola Internal Use Only            ( )
Motorola Confidential Proprietary     ( )

         ___________________________________________________
        |                                                   |
      _ | Michael Rohleder            Tel: +49-89-92103-259 | _
     / )| Software Technologist       Fax: +49-89-92103-680 |( \
    / / | Motorola, Semiconductor Products, ASA Methodology | \ \
  _( (_ |  _   Schatzbogen 7, D-81829 Munich, Germany    _  | _) )_
 (((\ \>|_/ >                                           < \_|</ /)))
 (\\\\ \_/ /    mailto:Michael.Rohleder@motorola.com     \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \

***This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the
sender by return email and delete this email from your system. Thank you!***

This archive was generated by hypermail 2b28 : Wed Oct 02 2002 - 03:21:31 PDT