A Systematic Approach for Automating the Design and Verification of Power Controllers
Abstract- With increasing complexities in power architecture, both design and verification engineers are spending an inordinate amount of time and effort to control and verify different power-clock state combinations of different power domains. In essence power-aware design and verification is becoming an important bottleneck for successful and timely tape-outs. In this paper we propose a new methodology to systematically generate power controllers that manage different power-clock state combinations of the DUT.
In addition, these power controllers manage power elements such as Level Shifters, Retention Cells, Isolation Cells and Power Switches through a standard protocol. This methodology also includes auto generation of a verification environment for the power controller. In summary we believe that our approach would lead to a significant reduction in the design and verification effort focused on poweraware designs.
Verification of the PULPino SoC Platform Using UVM
A typical System on a chip (SOC) integrates all components into a single integrated chip.
Verification of such SOCs is extremely complex because of various reasons
- SOCs are reasonably complex,
- SOCs have external off-chip busses that needs to be verified for all kinds of complex external traffic,
- SOCs typically have one or more processors.
- compiled object code running on the processor,
- UVM code simulating the external traffic to the SOC.
A typical SOC test contains two important ingredients
One of the interesting challenges that arise when developing such tests is figuring out how one ends the test. In this paper we will present typical techniques that are useful for cleanly ending such tests in a SOC environment. We will use these techniques on an opensource RISC-V based SOC.
Keywords—UVM, SOC, testing,
Controlling On-the-Fly-Resets in a UVM-Based AXI Testbench
Despite being a common requirement, handling hardware resets in a verification environment has always been beset by a host of challenges, including:
- Reset behavior has to be propagated to all testbench components.
- All UVM components such as driver monitor and scoreboard should be capable of reacting to the reset (i.e., they should be made reset aware).
- All pending sequences already scheduled by the test should be removed from all sequencers and virtual sequencers.
- Once the system comes out of reset the traffic should be re-generated to the DUT.
Special reset handling capabilities are especially important for the driver, which needs to stop executing the current sequences and bring the testbench to a known state immediately. This problem gets further exacerbated in AXI environments for two reasons. (i) The AXI interface has multiple channels, each of which work independently, and (ii) the AXI protocol supports out-of-order responses and multiple outstanding transactions. Therefore at any point in time, the driver could be juggling several transactions. When a reset occurs, the driver has to stop activities on "all" AXI channels. The driver needs to ensure a proper handshake with the sequencer to enable continuation of the sequences following the reset action.
The stimulus control thread also needs to be handled properly so as to determine what needs to happen after a reset is encountered (typically the entire traffic needs to be re-generated). Here traffic includes the sequences required to initialize the DUT before the actual test activity is carried on. In UVM, the concept of phase jumps can provide a solution to this problem. However phase jump is undergoing changes in the UVM technical committee. While several solutions have been proposed for handling reset problems in the past, an AXI-like environment can be tricky and often require additional insights. This article describes techniques for modeling UVM testbench components in an AXI-based environment. It also covers handling the stimulus generation unit (uvm_test) required to re-generate the DUT traffic without using phase jumps. Note that this technique can be applicable to other UVM-based testbench environments.