Subject: Re: SV APIs (Assertion)
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Oct 03 2002 - 17:56:04 PDT
[ This reply is probably out-of-sequence ]
> From michael.rohleder@motorola.com Wed Oct 2 03:19:58 2002
>
> 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]
The Testbench donation includes new flavors of event, we can try to combine those with events
generated by assertions and extend the syntax as necessary, e.g.
@(attempt <assertion_identifier>) covered |= 1;
@(success <assertion_identifier>) covered |= 2;
@(failure <assertion_identifier>) begin $display("More to do ....") ; $finish; end
<assertion_identifier> could be a regular expression, e.g. "$root/.../my_block/*" to find
all instances called "my_block" in the design and all the assertions there.
> 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.
@(failure .../a9) $display("Error at %s",$last_assertion_id());
My point is mostly that it would be a lot more efficient to handle this stuff within SV than
to construct an API so that it can be handled in C. If it can't be done with what we already
have then (IMO) we're missing some functionality in SV.
> ---
>
> 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
As someone told me, accepting the donation does not require us to implement it as donated (or at all).
There is a requirement that users be able to analyse/control the behavior of assertions in the design.
Joao has used an API to C so that the analysis/control can be handled externally. However that approach
is (IMO) predicated on the inability to do the job in the HDL (Verilog <= 2001). By 3.1 SV should have
sufficient power to do the job that was previously done by C (and Perl), since features like associative
arrays and dynamic creation of data allow data to be accumulated and analyzed.
Regards,
Kev.
PS: The ELF stuff is another thread
>
>
> --
> 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 : Thu Oct 03 2002 - 17:56:59 PDT