WP_Term Object
(
    [term_id] => 140
    [name] => Breker Verification Systems
    [slug] => breker-verification-systems
    [term_group] => 0
    [term_taxonomy_id] => 140
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 8
    [filter] => raw
    [cat_ID] => 140
    [category_count] => 8
    [category_description] => 
    [cat_name] => Breker Verification Systems
    [category_nicename] => breker-verification-systems
    [category_parent] => 157
)
            
semiwiki banner 1b
WP_Term Object
(
    [term_id] => 140
    [name] => Breker Verification Systems
    [slug] => breker-verification-systems
    [term_group] => 0
    [term_taxonomy_id] => 140
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 8
    [filter] => raw
    [cat_ID] => 140
    [category_count] => 8
    [category_description] => 
    [cat_name] => Breker Verification Systems
    [category_nicename] => breker-verification-systems
    [category_parent] => 157
)

Build More and Better Tests Faster

Build More and Better Tests Faster
by Bernard Murphy on 08-27-2019 at 5:00 am

Breker has been in the system test synthesis game for 12 years, starting long before there was a PSS standard. Which means they probably have this figured out better than most, quite simply because they’ve seen it all and done it all. Breker is heavily involved in and aligned with the standard of course but it shouldn’t be surprising that they continue to leverage their experience in extensions beyond the standard. This is evident for example in their support for path constraints to prevent or limit creation of certain paths and to bias towards other paths during test synthesis.

Build better tests faster

The value of path constraints becomes apparent when you look at the coverage view the Breker tools generate following simulation/emulation/ etc. In the image a red action was not tested, orange was tested once, green multiple times and blue a lot of times. You could imagine running multiple times, randomizing each time, to see if you could hit all the actions with sufficient frequency. You really want an equivalent to constrained random, but it needs to be more than simply randomizing fields (what PSS currently provides). Path constraints provide a better way for you to steer randomization to improve hit frequency for more comprehensive coverage along paths that are meaningful to real system usage.

Eileen Honess, tech specialist at Breker, recently delivered a SemiWiki-hosted webinar on the objective of these flows, together with a demo. I can’t blog demos so instead I’ll tell you what really stood out for me from this session. What Breker is doing is all about accelerating high-value test generation. Whether or not you are enamored with PSS, you certainly get the value of generating 10k high-value tests, getting you to 95% coverage (because you can better control how to get to high coverage), in 2 weeks. This is versus manually creating 500 tests in 2.5 months which only get you to 87% coverage (stats based on real customer case).

Along similar lines, Breker support accelerated testing through pre-packaged apps. The app concept was most notably introduced by Jasper as a method to pre-package formal verification for dedicated use-models. Breker have built on that idea in four domains – cache coherency checking, power verification, security and an ARMv8 app focused on typical processor test issues (there is a rumor of a RISC-V app on the horizon also). I’ll touch on a couple of these. For cache coherency checking, you’re probably heard that formal methods are extensively used. These play an important role in verifying control logic sequencing but that alone isn’t enough. Directed/randomized testing also plays a big role in verifying inter-operation of caches and the bus together with the controller. The Breker approach is a perfect application for this class of testing, providing a mechanism to capture the potential graph of actions, then generate randomized tests over that graph. This has to be substantially easier than building such tests from scratch in UVM. It should also be much easier to review how effectively you are covering the problem.

Verifying power management is another area where an app can accelerate test development and is also a natural for a PSS approach. After all, the power state-machine is – a state machine. It’s a graph defining the various possible states and what drives transitions between those states. You can build that model in UVM but why not start with a model already built from the UPF power state table?

Evidence that Breker are enjoying success with approach is apparent in their customer list, including companies like Broadcom, Altera, IBM, Huawei among others, including 8 out of the top 10 semis I’m told. They’re also proven with pretty much every tool I know of in the functional verification flow:

    • Simulation: Questa, VCS and Xcelium
    • Emulation: Palladium, Veloce and ZeBu
    • FPGA prototyping: HAPS, Virtualizer and custom FPGA boards (curiously no mention of Protium, maybe an oversight)
    • Virtual prototyping: Imperas and QEMU
    • Debuggers: Verdi naturally plus the other standard platforms
    • VIP: Synopsys, Cadence and Avery

So if you’re into PSS, you should check these guys out because they have a pretty advanced solution. If you’re a PSS sceptic, you should check them out because you can build more tests faster to get to higher coverage. Just ignore that it’s PSS-based. You can watch the webinar HERE for more details.


Comments

3 Replies to “Build More and Better Tests Faster”

You must register or log in to view/post comments.