Today we have UVM, the universal verification methodology. This is great for verifying IP blocks. But when it comes to verifying at the system level, something higher level is required, something that allows verification to move up to the system level too. At the system level the challenges are things like multi-core I/O and cache consistency, resource distribution (starvation etc), scheduling, low-power use cases (clock and power down, DVFS), performance tuning. Of course the IP blocks on the chip are required to implement all this functionality, but really this is verification of the interaction of the blocks, starting from the assumption that the blocks work as expected. For example, one thing you might want to check is that the power management doesn't interfere with multi-core cache consistency: Generate some cache transactions from multiple CPUs Power down one or more of the CPUs Generate more cache transactions from multiple CPUs Power the CPUs back up Generate more cache transactions and check that cache-coherency was maintained across the power down sequence Another challenge at the system level is that different engineers (or teams) have different views of the chip and don't have deep understanding of the concerns of the others. Architects, hardware developers, software developers, verification engineers, software test engineers, post-silicon verification engineers. For example, the above scenario requires "generate some cache transactions" which probably requires running some code. But software engineers don't know much about cache coherency (the whole point of it is so that they don't have to, plus some performance gains). The memory architecture engineers probably don't know that much about software. There is also the issue of horizontal reuse, where SoC verification teams would like reuse their verification content across different platforms. It should be reusable across virtual platforms, simulators, emulation and FPGA prototypes. Even on the final silicon once it is back from the fab. Once again, there are rarely engineers who are experts on all of these verification platforms.. Vertical reuse is another important aspect. Once the IP is verified, we need to move up to subsystems, to the chip with some basic software to exercise the hardware, then a full-blown operating system , up to the networking and audio stacks etc above. We want to be able to reuse any investment that we make at the lower levels when we get to the higher levels. One of the fundamentals of simulation is that you can't get more than an order of magnitude or two from throwing away detail. For example, you can't get to gate-level from SPICE, or to RTL from gate. You need to create a new representation. But once you have that, you can do things that you couldn't do with the lower level. RTL is not just "faster SPICE", it allows you to analyze the design at a higher level, do things like RTL power reduction or formal verification. In the same way, you can't get all the way to the system level from SystemVerilog. This is where the Perspec System Verifier comes in. One customer who saw a presentation on the product said “Yes it is true that Perspec easily gives a 10X or more productivity increase, but the more important point is the reality is we have no good way to create the kind of tests Perspec can generate since it is too complicated and would be too time-consuming to create those types of tests by hand”. Perspec does require some up front effort in creating a model of the scenario space of your SoC but it is a very abstract model which does not require a lot of details… Then Perspec can reason about the design without a lot of input. If you say you want to test video into the GPU, it already knows the sources of video. Perspec uses UML diagrams to show how it is linking up the blocks and exercising them. For example, here is the UML for the power/cache example discussed at the beginning: Perspec is a little like constrained random in UVM. Except it is not just the data that is randomized, the control paths are too, and the time at which operations are sequenced. Here are some of the real bugs that customers have discovered using Perspec: 2 processors granted exclusive access to the same memory region. In practice this would show up as a memory corruption, very hard to debug ARM big.LITTLE cluster where one little-cluster core glitched when the big core-cluster was going through power down and up (due to a hardware error) processor ignores interrupt when in standby state and so cannot be woken up The next post on Perspec, later this week, will be about how the models are created, what reasoning Perspec can do about them, and how it can generate test code in SystemVerilog and/or C. Previous: Verification Technology Update![]()
![]()
↧