Reusable On-Chip System Level Verification for Simulation Emulation and Silicon

Absolute verification of system on chip (SoC) has become infeasible due to the huge number of chip-level scenarios to cover. System level verification validates the integration of independently-verified components such as cores, peripherals, caches and memories. Some of the most elusive system level bugs can only be detected by scenarios that exercise several components, each in a different configuration. This paper presents a methodology for SoC system level verification, comprised of high level software that simultaneously exercises multiple hardware components. It consists of a light operating system which schedules threads for non-preemptive interleaved runs. Each thread complies with a uniform structure, and activates a specific functionality of the system. The interaction of multiple threads allows for realistic scenarios, testing bus traffic stress, multiplexing, and state machines, reaching unanticipated corner-cases. The OS includes a run time constraint solver for randomly selecting parameters for peripheral configuration. Similar capabilities require dedicated testbenches such as Vera or e which lack compilers and thus cannot be applied to silicon. The described framework is not dependent on a specific tool, but based on C, therefore compiled to chip. Reusability over project life-cycle is achieved by having the same test-cases run on simulation, emulation and silicon, allowing comparison of test results. A simulation speed-up of over 100times is achieved, by replacing RTL core with stub, compiling application code to the host machine, and using an API for the interaction of the design and application. This methodology was applied to the new Quad-Core MSC8144 supporting a very high I/O bandwidth and providing an optimal DSP solution for wireline/wireless infrastructure applications. The same methodology was used in simulation, emulation and silicon modes. It led to high coverage of system level scenarios, and discovery of system level bugs which could hav- e taken much longer to be found by other methodologies