Browse Prior Art Database

Methods of C and Verilog Hybrid Simulation for SOC Verification

IP.com Disclosure Number: IPCOM000245263D
Publication Date: 2016-Feb-23

Publishing Venue

The IP.com Prior Art Database

Abstract

At present, IC verification can be separated into two levels. One is module (IP) level and the other is SOC level. In this article, "SOC" indicates the chips have a CPU core and can run C programs). Generally, module level uses Verilog or System Verilog to create test cases, and C language is the foundation of SOC level test cases. This article introduces three methods to reuse the module level resources, include checkers, tasks, functions and even test cases, to SOC level directly and then makes SOC level verification task more efficient.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 40% of the total text.

Page 01 of 10

Methods of C and Verilog Hybrid Simulation for SOC Verification

ABSTRACT

At present, IC verification can be separated into two levels. One is module (IP) level and the other is SOC level. In this article, "SOC" indicates the chips have a CPU core and can run C programs). Generally, module level uses Verilog or System Verilog to create test cases, and C language is the foundation of SOC level test cases. This article introduces three methods to reuse the module level resources, include checkers, tasks, functions and even test cases, to SOC level directly and then makes SOC level verification task more efficient.

KEYWORDS

C-V Hybrid simulation, virtual bus master, bus function model, verification

Introduction

At present, IC verification can be separated into two levels. One is module (IP) level and the other is SOC level. Generally speaking, module level verification focuses on the function of the module itself and using Verilog or System Verilog to create test cases. The SOC level verification concerns the connectivity and timing between modules to modules, CPU or IO port. Usually we use C language to create SOC level test cases.

Although the SOC level verification doesn't need to be concerned with the detail functions and corner cases of a certain module, the basic functions still need be covered. Take ANT link layer, a kind of 2.4GHz wireless communication protocol controller, for example. This module supports 4


Page 02 of 10

kinds of packet length. In addition the CRC and data whiten function are configurable. All of the combinations of packet length and data process functions should be covered in module level verification. At SOC level, however, we only need to choose 2~3 kinds of packet to verify when a packet is transmitted or received, an interrupt should be handled by CPU.

In fact the content of a module level test case and a SOC level test case may be very similar (Figure 1).

Figure1: A typical flow chart of ANT RX test case


Page 03 of 10

In the regular SOC design flow, a new IP can only be released to SOC design team with a complete module level verification. Why we not reuse the module level verification resources for SOC?

The limitation here is that the module level test cases often written by Verilog or SystemVerilog but in SOC level we usually need C test cases. On this occasion, we must make a decision. One is to create C test cases and use previous SOC verification flow. Another is to use BFM (Bus Function Model) replace the CPU core and then we can use Verilog/SystemVerilog test cases to do verification task. However, this way is much harder than creating new C test cases, in addition it will also affect the whole SOC verification flow, and thus this seems an unwise option.

This article finds some ways to break the limitation between C and Verilog, that allow us to reuse the module level verification resources for SOC.


Page 04 of 10

Method1: Add a virtual bus master port

Here is a fact that, for most of periphera...