WP_Term Object
(
    [term_id] => 15
    [name] => Cadence
    [slug] => cadence
    [term_group] => 0
    [term_taxonomy_id] => 15
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 484
    [filter] => raw
    [cat_ID] => 15
    [category_count] => 484
    [category_description] => 
    [cat_name] => Cadence
    [category_nicename] => cadence
    [category_parent] => 157
)
            
14173 SemiWiki Banner 800x1001
WP_Term Object
(
    [term_id] => 15
    [name] => Cadence
    [slug] => cadence
    [term_group] => 0
    [term_taxonomy_id] => 15
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 484
    [filter] => raw
    [cat_ID] => 15
    [category_count] => 484
    [category_description] => 
    [cat_name] => Cadence
    [category_nicename] => cadence
    [category_parent] => 157
)

Verification IP for Systems? It’s Not What You Think.

Verification IP for Systems? It’s Not What You Think.
by Bernard Murphy on 11-05-2020 at 6:00 am

When I think of verification IP (VIP), I think of something closely tied to a protocol standard – AMBA, MIPI or DDR for example. Something that will generate traffic and run protocol compliance checks, to verify correct operation of an IP or as a model to use in SoC verification. What would a VIP for systems be? Systems support multiple protocol interfaces. And they generate traffic and require checks that depend as much on the purpose of the SoC as on those interfaces. Moshik Rubin, a PM group director at Cadence helped me reinterpret the VIP concept for systems.

Verification IP for Systems

A superstructure for SoC verification

The goal is not to check a specific function but to provide a front-to-back superstructure for SoC-specific verification tasks, from test assembly and traffic generation to performance analysis and score boarding. This complements rather than replaces your existing verification investment (UVM libraries, etc). It looks conceptually familiar to existing verification components: test-bench assembly and VIP, PSS test generation, performance analyzer and score boarding. However, Moshik says they redesigned these from the ground up for the needs of modern heterogenous SoCs.

The purpose is to simplify stressing the system, to provide more automation for a very complex task. You want to ensure for example that you full stress the interconnect, maximizing load. That you fully load from the PCIe interface and you cover all the memory subsystem corner cases. The system maintains cache coherence across many masters, some with native CHI interface, some with legacy ACE interfaces from 3rd party suppliers. That data integrity is maintained across chip networks as packets are sliced and diced in the middle and reassembled later. And that you can flip these analyses back and forth between software-driven testing in emulation and FPGA prototyping and simulation as needed.

Assembly, traffic libraries reinvented

You were able to do some of this before for Arm-based designs, more exactly designs using Arm cores and interconnect fabrics. Now the solution works with any interconnect fabrics, including a mix – Arm NICs and coherent fabrics, NoCs, coherent NoCs and meshes, along with complex cache and memory architectures. And the design no longer has to be Arm-centric. It can be based on RISC-V or x86. Testbench assembly can start, as before, with an IP-XACT or CSV description. Build your own descriptions in Excel, parametrize them with Visual Basic if you are up for that. (Try it. It can be fun!)

Traffic is described through PSS, for which System VIP provides a predefined set for cache coherency, performance, PCIe and others. I asked Moshik about other traffic generators. He said they’ve provided built-in libraries where they see a lot of uniformity between customer needs. For other generators, such as Ethernet where they see a lot more variability, customers can easily add their own PSS models. Or use existing UVM components. Reinforcing that this is an overlay, not a replacement for your proven testbench infrastructure. All tests will generate for simulation, emulation or post-silicon, directed to either UVM or C++ generation.

Analysis and scoreboarding

The system performance analyzer equally has been redesigned to work with heterogenous designs (cores and on-chip networks). And to look at the whole SoC, not just the interconnect, so you can start with high-level views of performance bottlenecks and drill down anywhere. The system verification scoreboard also is IP-vendor agnostic. For example, now you can observe traffic in PCIe, CXL or DDR, check cache coherency, data coherency. These checks are no longer limited to interconnect boundaries.

A customer experience

Renesas presented on this topic at CadenceLIVE recently. The speaker commented that previously testbench creation, allocating and configuring active and passive VIPs could take weeks. Then generating test patterns with multiple masters driving competing threads could take a few days per test pattern. They saw improvements in efficiency of testbench creation and analysis very consistent with Cadence’s claim of up to 10X. If you watch the talk, this was just before the System VIP official release, which Moshik tells me is why the speaker still uses the old product names.

To learn more about Cadence System VIP, click HERE.

 

Share this post via:

Comments

There are no comments yet.

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