Trusster Forums

Trusster Forums » General Verification Discussion

1. stephan.krueger@dmos2002.de
   Member

   There are some approaches for the location of a checker/analyser (with external checker, with checker in the monitor, with checker in the interface, with checker in the scoreboard and so on).
   In the richness of approaches i can't see direction and less than ever identify a clear way to put the checkers on the right location.

   Which kind of checker is goot for external checker, monitor, interface, scoreboard and so on?
   Which approach do you follow?

   Where do you check timings like is a signal minimal time at the high level?
   And where do you check timings like comes a positive edge in an time domain/period or outside of of the time domain?

   Posted 1 year ago #
2. Mike Mintz
   Key Master

   Hi Stephan,

   A great question and one this is dear to my heart. I have been working on a taxonomy of checkers for a while now, but it's still not ready for public viewing.

   Let's start with the basic checker flow, which is no data manipulation and in order data arrival. In this case the checker is a simple while loop.

   void start_ () { // a thread
   while (! done_ ()) {
   data_type expected = get_expected_ ();
   data_type actual = get_actual_ ();
   if (expected != actual) {
   log_ << teal_error << "Expected: " << expected << " != " << actual :: teal::endm;
   }
   }
   }

   Note that the done_(), get_expected_() and get_actual_ () are pure virtual methods to be filled in by a derived class. There are examples of this style in the truss/examples directory.

   Going from there, one can handle sweeping to find a lock, out of order reception of actual, and complex models (usually external to the checker).

   As for timing checks, I usually make those checks in the monitor. One exception is when the timing checks extend beyond a simple transaction. For example, I have a control_signal_checker in my current project that checks three different long term signals. It counts pulses per clock and makes sure they are withing the specified tolerances.

   Hope that helps. Ask me more questions!

   Take Care,
   mike

   Posted 1 year ago #
3. stephan.krueger@dmos2002.de
   Member

   Hi Mike,

   It is a great pleasure for me to ask you a great question which is dear to your hear.
   I also ask other expert on Digital design and verification.

   Luca and Alain from Mentor Graphic wrote me following:

   ##########################

   1.
   If you use assertions to implement your checkers, then they cannot reside within the SV class hierarchy of OVM.
   I would have them in the SV interface that connects to the HDL signals being observed.
   For industry standard busses, I would use the existing library of assertion checkers such as QVL
   ("OK, it's the Mentor Graphics Questa Verification Library (QVL) one assertion checker library for assertion-based verification (ABV)").

   2.
   If these checkers are implemented as procedural code, then they can form part of the monitor and / or scoreboard within an OVM environment.
   Typically, a monitor works between the RTL and TLM abstraction level so would be used for checking cycle accuracy or phasing related issues in a bus/interface protocol for instance.
   Scoreboards on the other hand typically work at the transaction level so would have high level code that checks for correct functionality.
   An example could be a C/C++ reference model.

   ##########################

   I put this information in the discussion also in the hope to help you at your work in progress "the taxonomy of checkers".
   For me it makes sense, but I am relative new at the SystemVerilog base class library verification methodology area (wow really many words),
   like Open Verification Methodology (OVM) or Universal Verification Methodology (UVM).
   What's your opinion?

   I try to collect the information and wrote a very basic taxonomy of checkers in the table (below).

   -------------------------------------------------------------------------
   component methodology for example / used for
   -------------------------------------------------------------------------
   -------------------------------------------------------------------------

   interface assertion-based - a signal or signals (bus)
   verification (ABV) went to X or Z
   during a specific
   phase
   signal spikes (to short signals)

   -------------------------------------------------------------------------
   monitor transaction - extend beyond a
   timing checks simple transaction
   - checking cycle accuracy
   - phasing related issues
   in a bus/interface protocol
   for instance

   -------------------------------------------------------------------------
   scoreboard transaction - high level code that checks
   level checks for correct functionality

   -------------------------------------------------------------------------
   external for really complex - exception handling
   checker models/checkings - interrupt service
   (to flux a monitor routine handling
   or scoreboard) - checking the specified
   tolerances for n different
   long term signals
   -------------------------------------------------------------------------

   Feel free to annotate my statements.
   I'm very grateful to hear your arguments.

   Take Care,
   Stephan

   Posted 1 year ago #
4. stephan.krueger@dmos2002.de
   Member

   I hope this stuff (very basic taxonomy of checkers) is more readable.

   --------------------------------------------------------------------------------------------------
   component: interface

   methodology: assertion-based verification (ABV)

   for example / used for: a signal or signals (bus) went to X or Z during a specific phase,
   signal spikes (to short signals)

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

   component: monitor

   methodology: transaction timing checks

   for example / used for: extend beyond a simple transaction,
   checking cycle accuracy,
   phasing related issues in a bus/interface protocol for instance,

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

   component: scoreboard

   methodology: transaction level checks

   for example / used for: high level code that checks for correct functionality.

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

   component: external checker

   methodology: for really complex models/checkings (to flux a monitor or scoreboard)

   for example / used for: exception handling,
   interrupt service routine handling,
   checking the specified tolerances for n different long term signals

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

   Posted 1 year ago #
5. Mike Mintz
   Key Master

   Hi Stephan,

   That a good breakdown. I personally would not use the interface for checking as they are weird enough ;-) I would put the XZ checks in the monitor.

   The monitor and scoreboard notes sound correct. As for external checker, I would classify that as a control signal specific checker (i.e. not data).

   One other point to note is that all of these checks need to be able to be turned off or overridden in some way. I tend to use a filter on the output logger that converts errors for specific modules at specific times in to expected behavior.

   I am not a big fan of Assertion Based Verification. For the simple checks, sure. But for developing interfaces or company specific interfaces, I feel its more work to write the protocol, timing, and XZ checks in assertions. I feel this creates a "priesthood" of people that know and can write complex regular expression and "the rest of us" (and I used to be a "priest").

   Great comments and post !

   Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.