1. Introduction

    As the complexity of SoC designs grows, it takes longer to do functional verification. Tests run, way longer than they used to - a few hours to days - and there are thousands of them to run. It is not surprising to see a long-drawn out design verification cycle.

    One of the common characteristics of functional verification of today’s complex designs is that they go through some sort of initial setup phase, whether it is design initialization, reset state, configuration phase, or sequence initialization. This initial setup phase is typically common for all the tests, or for a particular set of tests or a set of test configurations. In addition, this setup phase itself takes a substantially large amount of cycles with respect to overall length of the simulation for a test, and these cycles must be repeated over and over again for all subsequent tests.

    This paper will discuss how to write the design so that the common initial setup phase simulation is done once and then used as a foundation to run different tests later on, including the ability to change test stimulus to simulate different test behaviors. We will also discuss what type of designs (Verilog, VHDL, SystemVerilog, UVM-based, SystemC, C/C++ models, PLI/FLI/VPI etc.) will fit in this methodology and what a designer can do to make his design fit for such methodology.

    Also covered:

    • Constraints that need to be followed in order for this methodology to work, the design factors that might prevent a designer or verification teams from adopting this methodology (and how to overcome them).
    • Co-simulation verification environment (simulation-emulation) requirements and discuss how the same methodology would work with either simulation or co-simulation verification.
    • Examples from real world designs to show how this methodology can be used successfully, what changes are required to unblock some of the design factors, and elaborate on the potential gain and regression throughput that is
      possible.

    Designers of complex designs (SoC, FPGA, Processor, PCIe link etc.), may go through a common initial setup phase for all their tests. This setup phase could be either executing the exact same sequence of simulation steps or programming their design to reach the same initialization or reset state.

    This approach is plausible for designs that have:

    • An onboard PHY component, which requires a long initialization, calibration, and bring-up time.
    • DDR4 or similar SDRAM interface, which requires an initial calibration and training sequence before actual transfer can take place.
    • Many configuration registers, such as a video/graphics controller, requiring setup after reset.

    Once the tests complete this common setup/initialization/reset phase, then they would diverge to run subsequent different tests/sequences/instructions from this point onwards. This common setup phase could consume anywhere from 20%- 90% of the total simulation time for a test.

    It is efficient to re-factor this initial setup phase so that what is common for a set of design tests is separated out from regular simulation cycle. Thus, each test need not redundantly run this common phase. Instead, this phase can be
    performed only once for a whole set of regression tests and the design state is checkpointed. All subsequent tests could reuse this checkpointed state from an already initialized setup phase. If a system is created to be able to perform different tests from this point onwards, it would result in a huge amount of throughput gain for a large and complex design verification system by avoiding repeated reruns of the initial setup phase for the individual tests.

  2. Download Paper