Projects

Handling 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.

When a reset happens, special reset handling capabilities are especially important for the driver. This problem gets further exacerbated in AXI environments for two reasons.

  • The AXI interface has multiple channels, each of which work independently, and /li>
  • the AXI protocol supports out-of-order responses and multiple outstanding transactions.

In this project, we modeled all the UVM testbench components for an AXI-based environment, with a capability to handle on-the-fly resets

For more information about this project, or if you are interested any VIP development, please contact us info@verikwest.com

Running SystemC simulations on cloud-based compute clusters

Regressions are an integral part of any VLSI design process. Every time a design change is implemented in the RTL code, a complex series of regression tests are run to validate the change. The regressions serve to ensure that there are no breakages to the existing functionality of the design. As the design heads towards code freeze deadlines, the demand on the compute-servers that execute these regressions rises exponentially. Sometimes tape-outs are delayed because the regressions could not be completed on-time.

To manage peak load requirements, we have implemented a flexible regression system that can utilize “cloud-based compute clusters” (such as EC2 instances of Amazon Web Services) to provide the additional capacity. Our regression system focusses on the following key features:

  • Flexibility: Regressions can be easily switched to run on
    • Local mode
    • Cloud mode and
    • Mixed mode, involving both cloud and local machines.
  • Security: Job information transmitted to the cloud and simulation results (transmitted back from the cloud) adhere to an acceptable level of security.
  • Local Compilation: Only the executables (.exe files) are shipped to the cloud machines to ensure that the source code is never sent outside the organization.
  • End to End Encryption: All the information transmitted between the local servers and the cloud machines are compressed and encrypted
  • Ease of use: The user could seamlessly pick the available cloud machines from the machine-list file.
  • Automatic polling for job completion: Determines the status of the jobs. The polling frequency is controllable by the user.

  • For more information about this project, or if you are interested any cloud based EDA services, please contact us info@verikwest.com

Verification of a RISC-V based SOC

RISC-V is an open instruction set architecture (ISA) developed at the University of California, Berkeley.. The RISC-V ISA has been designed with small, fast, and low-power real-world implementations in mind, Hence it will be useful for modern devices such as cloud computers, high-end mobile phones and the smallest embedded systems. Such uses demand that the designers consider both performance and power efficiency. The instruction set also has a substantial body of supporting software, including the entire tool chain to successfully compile and run complex code on the ISA.

There are several companies adopting (or planning to adopt) RISC-V architecture for their next SOC design. In this project we have implemented a complete verification framework for a RISC-V based SOC. This framework is designed in UVM and incorporates the following UVM based VIPs.

  • i2c
  • QSPI
  • UART
  • GPIO

We have developed several tests to exercise the entire SOC. Each test contains two parts

  • a "C"-based component which provides the instructions for the CPU to execute
  • an UVM-based component which provides external stimuli through the VIPs and provides overall control of the test

For more information about this project, or if you are interested any SOC verification services, please contact us info@verikwest.com