Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/index.php?threads/new-verification-tool-for-constrained-random-test-replay.7201/
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021370
            [XFI] => 1050270
        )

    [wordpress] => /var/www/html
)

New verification tool for constrained random test replay

Daniel Payne

Moderator
[h=1]Regression Test Generator[/h]Writing quality Design-Verification code is quality engineering effort and involves several man hours. Once a design error (colloquially known as “bug”) is spotted by the DV code, it is very important to retain that trace/series of inputs leading to that failure. This is critical for variety of reasons including:
  • Designers will need to re-run the trace few times to analyze the design, fix etc.
  • Verification engineers want to add such bug finding traces to regressions (and score brownie points)
  • Management wants to ensure all such past bugs have been re-verified and do not re-enter
The above requirements are obvious for most involved in the DV process. However repeating a “test” is not as easy it may seem at the first look. There are two important use scenarios that are relevant here: Formal Verification(model checking) with assertions and constrained random verification with SystemVerilog etc. In Formal Verification flow, one may want to be able to reproduce a falsification trace on a simulator.With modern, constrained random verification flow (with or without UVM), a “test” is usually a random series of inputs controlled by a starting seed. In principle, the same seed should produce the same “series” forever. However this theory doesn’t apply well in practical cases often. This is often called “random stability”. There are several reasons to this syndrome:
  • The random space was altered via additional constraints (inside the transaction class for instance)
  • Change of EDA tool/vendor certainly changes the “test scenario”
  • Within the same tool, change of options to the compiler/runtime engine might affect the random stability
This is where our RTGen tool comes into the flow. Given a quality trace as a series of inputs (in the form of a waveform database), RTGen creates a directed test that users can add to the regression suite. Given that the resulting test is “directed” it doesn’t suffer from the factors affecting “random stability” described above.Click here to visit the product site at Verif Works.

VW_RTGen.jpg
 
Back
Top