Random verification Strategy for Microcontroller based Subsystems for faster Convergence

A typical microcontroller-based system often includes multiple interfaces with an ability to support clock gating and other low power features. For such a complex subsystem, finding issues in block level interaction, low power flows and architecture requires exhaustive random test framework at subsystem level along with unit level randomization. There is no standard approach for developing random verification environment for such subsystems, thus resulting in increased time for development and maintenance. Debugging issues wherein concurrent traffic from different interfaces is active, is challenging and time consuming. In order to support multiple projects with different configurations there is need for scalable and structured approach which would help in achieving quality verification without affecting time to market. A novel dashboard style architecture proposed in this paper, provides fully scalable solution for subsystem level random verification with improved debug ability and execution efficiency, thus contributing to High Velocity Development Model (HVDM). With this scalable approach for random verification, bring up time for a new IP in a Sub system random verification environment is seen reduced by 60% and time required for achieving tape-in quality coverage is seen reduced by 40%, as compared to the traditional approach. The results published are derived from the improvement seen by implementation of this methodology in a Low Power Sensor Subsystem that was delivered to multiple SoCs, in time with quality


Introduction
Constrained Random Verification (CRV) is becoming more critical with increase in design size and complexity.Comprehensive verification at Sub System level, involving interaction between multiple IPs, interleaved with different Low Power states, can be achieved only through CRV.The random verification environment is often complex as it involves configuring multiple IPs and intersection of flows to enable entry and exit to different low power states.Maintaining and adding new IPs to existing verification framework is not straightforward which results in addition of lot of custom code.Another problem is the ramp up time for a verification engineer to understand this complex environment and time required in debugging.As time to market (TTM) along with quality verification is very important for the success of product, there is a need for fully scalable standard random test framework with better debug ability and controllability.
Currently there is no standard methodology that provides or guides on such a framework.
This paper provides tools to attack this complex verification challenge in 3 steps: 1. Creation of a Scalable Dashboard Framework 2. Scalable Monitor for easier Debug 3. "Probability Calculator" as a tool for tightening the constraints for better coverage This approach provides random environment that can scale from block level directed test to full system level random test with concurrent traffic and various low power flows.Dashboard structure used in this approach makes it scalable and adding a new flow or a Sub-IP becomes easy.In order to reduce time required for debugging a test, a dashboard monitor is developed.This dashboard monitor provides complete picture of various concurrent flows and helps in narrowing down debug to a specific flow.Typical CRV environment has large number of constraints.Modifying constraints for hitting "hard to reach" coverage is cumbersome, and one needs to run a full regression and then analyse the coverage report.This method may result in several iterations and wastage of compute resource and time.This methodology uses a static probability calculator which iterates over constraints and gives probability of a scenario under all given constraints without having to run any regression thus saving compute resource and time.Using this proposed solution, the time required for bringing up a new flow significantly reduced from ~3days to a one-day effort.Modifying stimulus for hitting complex coverage and debugging a test failure becomes methodical which results in improved speed of execution.This methodology can be used effectively to solve the problem of subsystem random verification with reusability across projects with different configurations.

Overview of the proposed methodology
This paper will use a typical Microcontroller based Subsystem (depicted in Fig. 1.) as an example, to elaborate on the proposed methodology.

Fig. 1. A typical Microcontroller based Subsystem
Architecturally, a typical Sub System would have a single/ dual core that acts as the Main master, along with a DMA which offloads some of the traffic from the core and is the secondary Master.The subsystem would support multiple peripheral IPs which can serve both as masters or slaves.And one or more system memories that sit on a network fabric.There will be a Clocks and reset unit and a Power Management unit to control all the low power states supported by the subsystem.
The verification state space of such a subsystem will entail ability to setup requirements and configurations to enable all the valid masters to generate traffic and enable access to all slaves, concurrently.If the subsystem supports one or more low power states, the verification state space increases multi folds where it needs to cross all the system traffic with low power scenarios as well.Just randomly kicking off all the traffic generators may provide functional coverage w.r.t concurrency of traffic in the subsystem but will not provide the ability to the user to control the traffic streams of interest or the ability to control the entry/exit to/from desired low power states within different windows of interest.It will also not provide fine control to the user to generate wake up at interesting windows in the subsystem to exit the low power states.That fine control can be achieved only if there is a framework that keeps track of state of all the components of the subsystem and has handles to control entry/ exit of the subsystem in and out of active and low power state at desired windows of interest.
This paper proposes such a methodology to develop a framework which provides ample control to the validator of a complex subsystem handling multiple low power states, to achieve desired validation coverage with quality in minimal duration.It also ensures reusability and portability of the different components of the subsystem Random engine to serve different SoCs or even different generations of the same SoC [1].
The fundamental aspect of this proposed methodology is to use constrained random verification along with scalable dashboard mechanism [2].Fig. 2 gives the architectural view of the main components used in this methodology.The two main components are called, the C-Engine and the SV-Engine.Few of the sub-components may vary a little from one subsystem to another however the overall architecture would remain the same.

A. C Engine
C-Engine as name suggest is a random test case software written in C-language that runs on microcontroller core of the subsystem for configuring IPs, initiating low power flows and respond to host-initiated flows.This component is the backbone for scalability and consists of Dashboard (DB), Scheduler and APIs and Interrupt Service Routines (ISR) for controllers within subsystem.Dashboard is a simple C Data structure where in each row corresponds to one controller or low power flow and it has as many rows as number of controllers and low power  For the purpose of discussion in this paper, the example assumes two project static bits: "Vnn Dependency" and "TCG Dependency"."Vnn dependency" bit indicates if the specific Controller/ agent requires Vnn signal to be set before it can generate traffic.And the "Trunk Clock Gating (TCG) dependency" bit indicates if the controller/ agent needs to be in quiescence if the subsystem must enter a low power state.Task Enable (TE) bit if set, means a flow should be enabled.Task Scheduler (TS) bit when set indicates a flow is already triggered.TCG lock bit is used for preventing triggering of a new flow so that the system can enter clock gated state.TE bits are programmed randomly based on a trigger controlled by SV-engine.DB acts as a book keeping and used by scheduler explained below, to schedule tasks based on status bits.DB also contains API pointers that simplifies job of a scheduler.By setting a TE bit for any one agent this fully random test can used as a directed IP test.
Scheduler is a Finite State Machine (FSM) that iterates over DB in random order and calls controller API after its dependency bits are satisfied.

B. SV Engine
SV engine handles 3 main tasks of managing all the randomization needed for covering the subsystem state space: 1. Generating all the legal traffic from external world to the subsystem 2. Creating quiescence condition needed for entering clock gate 3. Generate random constraints for 1 and 2 All the randomization needed by the subsystem, both for internal traffic within the sub-system and external traffic, is achieved by SV engine using weighted constrained randomization.The random data generated by SV engine is backdoor jammed in pre-assigned locations in SRAM and systematically picked up by C engine and used for all internal controller traffic thus saving a lot of microcontroller cycles which would otherwise get consumed in creating randomization through microcontroller.The SV traffic generator manages triggering of all traffic external to the sub-system, like GPIO or IPC that can wake the subsystem.Relaunching of traffic threads is introduced in order to maintain high density of traffic throughout traffic phase.It depicts a system level Manager which triggers and controls all the valid traffic threads on a platform [3].
The SV engine achieves quiescence for Low Power (LP) states by using "anchor mechanism".Anchors are typically, certain microcontroller states, FSM states within the subsystem or some RTL signals of interest.The SV engine lets the subsystem reach a state (anchor) of interest before triggering off external traffic causing the wakeup of the system from the LP state.
C and SV engines work together to make subsystem random test framework.SV engine randomizes agent configuration which is loaded it into the SRAM and initiates trigger for randomly setting TE bits in DB.Scheduler iterates over DB and takes appropriate action as explained above for DMA entry.Once programmed number of loops are done SV engine triggers end of the test.

Debug Efficiency
Debugging test failure at chip level can be complex due to concurrent traffic from different controllers.In order to achieve HVDM, reducing debug time becomes critical.To improve debug time, C-engine and SV engine monitors were developed that gives overall picture of concurrent traffic from both microcontroller side and host-initiated traffic and helps in quickly identifying the source of failure.Fig. 5. below Shows C and SV engine monitors dump.5

Coverage Goal
With the increase in the number of Controllers in the subsystem, supported low power states and number of wake sources, the complexity of the subsystem can grow rapidly.This results in large number of functional Cover Groups, cross coverage and coverage for corner case scenarios.To address this need of meeting complex coverage, finer control is required on the stimulus.With large number of inter dependent constraints, predicting the occurrence of a scenario, becomes extremely essential and difficult at the same time.This problem was addressed by innovating the idea of "Probability Calculator" (PC).PC can be used to statically calculate the probability of a random variable, without running a single cycle of simulation.
By using probabilities of all the random variables including their weightage, it calculates probability of a certain scenario for e.g."A successful entry into Deep Sleep with Memories power Gated and Logic not Power Gated and wakeup by a Ethernet Rx Magic Packet event".Traditional method has been to run regressions, generate and merge coverage and then get feedback from the coverage report to take any corrective actions.But by using this calculator as shown in Fig. 6. turnaround time is reduced from several hours to minutes.Based on the feedback from the Calculator, corrective actions can be taken in terms of either running more seeds upfront or by adjusting the weightage on the random variable constraint, affecting the probability of a scenario.

Summary
The proposed solution helped in achieving High Velocity Development Model with quality verification.Currently no standard framework for subsystem random verification exists which can be reused across different subsystems.
Structured and scalable implementation used in this methodology enabled easy integration of a new IPs and power flows into existing Random Engine.This methodology can be adapted by any microcontrollerbased subsystem with little modification specific to the subsystem.Proposed static probability calculator and innovative debug solution proved very useful in reducing debug efforts and time required for achieving 100% coverage goal.

Fig. 2 .
Fig. 2. Architectural view of the proposed methodology

Fig. 3 .
Fig. 3. Dashboard Structure with Controller flows Scheduler is completely agnostic to different entries in the DB and does a mechanical job of updating DB and calling API's based on current state of DB.Scheduler uses API pointer in a DB to call the correct API.Due to this implementation scheduler need not change with respect to addition or removal of rows in the DB.Fig. 4. Shows the scheduler FSM.

Fig. 4 .
Fig. 4. Scheduler FSM Consider for example a DMA controller entry in DB.Initial state for DMA after DB initialization would be Idle with its Vnn and TCG dependency bits set.When SV engine sets TE bit, state of the entry changes to TaskEn.Scheduler reads this entry and request for Vnn by setting Vnn_req bit as DMA would need Vnn for DRAM data transfer which is indicated by Vnn dependency bit.This changes entry state from TaskEn to SetupVnnandWaitforAck.Once Vnn_ack is received scheduler sets TS bit and invokes corresponding API for configuration of DMA and state changes to CallAPI.When the DMA transfer is over and an interrupt is asserted, ISR clears TE and TS bits and DMA entry enters Cleanup Vnn state.Scheduler now de-asserts Vnn, clearing Vnn_req and Vnn_ack bits in DB and state goes back to Idle.

Table 1
presents improvements measured in various areas of verification with proposed solution for a Subsystem that was delivered to multiple SoCs

Table 1 .
Improvements achieved with proposed solution