![\"\"](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2018\/02\/PortableStimulus_1.png\")
<\/a><\/p>\nWhen it comes to test portability, there are two key things to consider: test intent and test realization. Test intent is all about the big-picture view of what<\/strong> is being tested. Test realization is the details of how<\/strong> it is verified. Accellera\u2019s Portable Stimulus standard really focuses on making test intent portable, which is a very useful thing. This allows us to apply the same highly-automated test scenarios in our IP-level environment and in our SoC environment. All we have to do is provide the appropriate test realization layer. What if you need Portable Realization?<\/strong><\/p>\n Hardware IP increasingly has software content and requiring tight interaction with software. Developing this firmware early and reusing it across the verification flow both boosts productivity and helps to find hardware\/software interface bugs early while they\u2019re easiest to debug and fix. In this situation, needing to re-create the test realization layer for each environment isn\u2019t just wasteful, but doesn\u2019t allows us to test what we need to test.<\/p>\n
\nLet\u2019s say we\u2019re testing a DMA controller. Our test intent would specify test scenarios that we want to exercise on the DMA controller \u2013 things like running transfers of various sizes, and running parallel transfers on different channels with the same and different priorities. Notice that we haven\u2019t said anything about how<\/strong> we will exercise the DMA controller. That\u2019s where our test realization comes into play. In a UVM environment, our test realization might use the UVM register model to access the DMA engine\u2019s registers and use a UVM agent to intercept interrupts. In a bare-metal embedded software environment, we would use C code statements to access the DMA engine\u2019s registers and an interrupt handler to react to interrupts.<\/p>\n<\/a><\/p>\n
\nIn many cases, this scenario is ideal since it allows the same test intent to be reused across very different environments and very different test realization layers. In some cases, though, reusing test realization is also very helpful.<\/p>\n