What to Run on Day One in SoC Simulation

Two recent blog posts discussed what you should run when you first map your system-on-chip (SoC) design into an emulation platform and when you have your first fabricated chips from the foundry in your bring-up lab. We pointed out that trying to boot an operating system and run applications should not be the first step because production software is not designed to find and debug lingering hardware design errors. We recommended running the multi-threaded, multi-processor, self-verifying C test cases generated and optimized for hardware platforms by our TreSoC-Si product.

As you may know, TrekSoC uses the same graph-based scenario models as TrekSoC-Si, but optimizes the generated test cases for virtual prototypes, simulation, and simulation acceleration. In this post, we ask a similar question: what should you run in simulation when you first have the RTL for your SoC assembled and ready to be verified? Of course our answer will be the test cases generated by TrekSoC.  However, there are some advantages of simulation over hardware platforms that foster a more extensive methodology for verification with Breker’s products.

As with emulation and the bring-up lab, trying to boot the operating system is not the place to start full-SoC verification. The same warning about the difficulties of control and debug apply, while production software is even less likely to be available at this early stage of the project. There is an additional wrinkle: some SoC simulations are so big and run so slowly that the verification team never tries to run production code. In fact, as we blogged recently, some projects never even assemble the complete SoC before they tape it out.

The test cases generated by TrekSoC provide an excellent solution. They run on bare metal, so do not require booting an operating system, kernel, or monitor of any kind. They are carefully crafted to run efficiently in simulation, offloading as much as possible from the SoC model. For example, results checking is performed in zero simulation time by the TrekBox run-time utility rather than by running code in your SoC’s processors.  TrekBox also provide extensive debug information to find and fix the source of the RTL errors uncovered by the test cases.

As we pointed out in the previous posts, the test cases our tools generate do an extremely good job of exercising your design. We can stress the interactions between your processors, memories, caches, and on-chip buses, fabric, or network-on-chip (NoC). Parallel threads will hop from processor to processor, exercising your design far more thoroughly than hand-written tests or production software ever could. If your chip requires cache coherency, our Cache Coherency TrekApp will generated additional tests specifically designed to stress cache corner-case conditions.

Everything we’ve described so far can be accomplished with just the Cache Coherency TrekApp and no user-specified scenario models at all. You provide simple setup information on the number of processors and caches plus the memory map for your SoC. From this, the TrekApp uses a pre-built scenario model that captures the verification to be performed. The same high level of turnkey processor-cache-memory test cases can be generated for any platform. The level of exercise is often sufficient to gather realistic performance metrics.

Most likely your SoC contains other types of blocks, and it surely has some I/O interfaces. You can add bus/fabric/NoC verification IP (VIP) models to factor in the effects of these blocks as well on performance. If you want to extend the coverage of the test cases to include other blocks in your SoC, you will need to work with us to create graph-based scenario models for those parts of the design. The graph approach is intuitive for designers and verification engineers, but it does take some work. The happy result is incremental returned value for this incremental effort.

Once you have scenario models for your interfaces, you can use your existing UVM (or other) VIP to connect to TrekBox. TrekSoC can then generate test cases that send data on and off chip, stress individual blocks, and string blocks together into realistic user scenarios. Easy access to chip I/O is an advantage of simulation; more effort is usually required to run such test cases in hardware platforms such as emulators of real chips in the bring-up lab. With Breker’s solution, you can run powerful test cases on Day One and easily extend them to cover your entire SoC.

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: acceleration, Breker, bring-up lab, cache coherency, EDA, emulation, functional verification, graph, graph-based, portable stimulus, scenario model, simulation, SoC verification, test generation, TrekApp, TrekSoC-Si, use cases

This entry was posted on Thursday, February 5th, 2015 at 6:11 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.