Scalable Verification Environment Using OCP Compliant Cores and eRM Compliant eVCs

By Maulik Shah, Project Lead eInfochips, ASIC Group

reprinted with permission by OCP-IP (C) Copyright 2003 OCP-IP

With the increasing number of transistors on a chip, design complexity expands constantly and the required verification effort to validate these designs grows exponentially. Conventional verification methodologies cannot meet the time-tomarket demands of verifying the current multimillion gate System-on-Chips (SoCs). Recent industry research has already raised flags that lack of breakthroughs in presently used verification methodologies, and hence the inadequate verification capabilities, will be the main cause restricting design complexity, rather than the technology.

To overcome the verification bottleneck, eInfochips has developed a verification solution for verifying multimillion gate SoCs that uses state-of-theart verification techniques and tools and leverages design as well as verification intellectual property (IP) reuse. This paper describes the verification environment that eInfochips successfully developed for one of its U.S. based clients to verify a complex Digital Signal Processor (DSP) Voice over Packet (VoP) SoC with a fairly intricate architecture.

The SoC has multiple interfaces (Sonet, Ethernet and PCI) for transmitting and receiving packets from different networks. At the core of the SoC are three DSPs performing operations on the voice packets. The SoC contains one MIPS processor for control functions, a large on-chip memory for packet storage and uses Sonics, Inc.’s Silicon Backplane® (SB) bus for data transfers between all the IP/cores. The interfaces have DMA engines attached to them on the bus side to transfer the data back and forth from the memory. All cores are connected to the SB using Open Core Protocol (OCP) compliant interfaces.

Figure 1 shows a block diagram of the system-level verification environment. The highlighted block shows block-level verification environment integrated into system-level environment by configuring the OCP eVC as a monitor (passive component).

Using OCP compliant interfaces enables easy integration of the pre-verified IP/cores (either bought from a third party or legacy cores obtained from a company’s in-house IP repository) into the SoC without modifying the interfaces to connect them to the on-chip bus.

Verification of any IP/core’s compliance to OCP may require an OCP interface emulator. An OCP eVC can be modeled as a system, thereby eliminating the need of an emulator as it can generate and respond to the OCP transfers and transac tions for block-level verification. For example, it generates and responds to the OCP transfers and transactions for MII DMA as shown in Figure 2.

Benefits of the OCP eVC:

• • Offers maximum flexibility in such that it can be integrated within verification environments with C/C++/SystemC models or with any other eVC
• • Substantially increases the verification leverage, as it comprises reusable elements viz. Sequence drivers, BFMs, Monitors and Checkers within the entire verification environment
• • Constraint-based random test generation, data and assertion checking and functional coverage analysis make the test scenarios reusable, such that they can be used at the block-level as well as for chip-level and systemlevel verification
• Can be configured as a Master OCP agent or a Slave OCP agent, thus enabling it to either drive the signals or monitor the output
• When configured as a Slave agent, it contains a sparse RAM to store data at the addressed location for write request from the Master OCP interface and can respond with deterministic or random data for read requests
• When plugged into the systemlevel SoC verification environment, the OCP eVC:
• Can act as a monitor and detect OCP errors, collect functional coverage information and log OCP transfers and transactions during test run for statistical analysis
• Can be used as memory model in place of onchip memory to achieve improved simulation performance to verify an interface’s OCP compliance, eliminating HDL-based memory modeling
• The OCP eVC is pre-verified at the block-level and system-level, thus reducing verification risk and improving design quality
• The OCP eVC is eRM compliant, providing scalability of verification environment from blocklevel to system-level verification and the much required consistent user interface to increase productivity

Figure 2 shows a block diagram of the block-level verification environment.

For block-level verification (as shown in Figure 2) the Gigabit Ethernet (GBE) eVC and OCP eVC act as active agents by driving and responding to the stimuli from the MII IP core. Automated verification flow is set up by using the GBE eVC to generate and inject Ethernet frames to the MII DMA. The GBE eVC also adds the injected frame to the scoreboard in the verification environment. The DMA extracts the payload from the frame and writes the payload data by issuing write requests on the Master OCP interface at the system side. The OCP eVC accepts the write data sent by the DMA and stores it into the sparse RAM. By configuring the DMA in loop-back mode (specifically designed for verification), the DMA issues read requests on the OCP interfaces from the memory locations addressed by the earlier write requests. The DMA forms the frame from read data and sends the frame back to the MII interface. The GBE eVC collects the Ethernet frames and provides it the scoreboard for comparing injected and collected frames. The scoreboard issues an error if injected and collected frame payload data do not match.

Since the eVCs can be configured as active agents or passive agents, they offer the highest scalability to the entire verification environment. For instance, when block-level verification environment is reused at system-level verification (as shown in Figure 1), the GBE eVC continues to act as an active agent, but the OCP eVC acts as a passive agent by only monitoring the OCP interface for protocol errors, while collecting functional coverage and logging OCP transfers and bursts for statistical purposes rather than driving any OCP signals.

Since eVCs are eRM compliant, they can be reused in a system-level environment with no interference between eVCs and are easier to reuse, as they have common look and feel, similar activation and similar documentation.

Tools used for this scalable verification include (but are not limited to) Verilog-NC simulator, Specman Elite, Synopsys CoverMeter, 0-In Check (for assertion based verification) and 0-In Search (dynamic formal verification).

To summarize, using OCP compliant cores and eRM compliant eVCs makes it possible to handle verification challenges imposed by ever-growing design complexity. The desirable minimization of time to market is achieved by rapidly building up the verification environment and, more importantly, scaling the verification environment, thus helping thoroughly verify all important and interesting functional scenarios of the SoC at different levels.