Methodology for hardware/software co-verification in C/C++

TLDR: This paper presents a C/C++-based design environment for hardware/software co-verification, and shows how co- Verification can be done efficiently and effectively at the various levels of abstraction.

Abstract: In this paper we present our C/C++-based design environment for hardware/software co-verification. Our approach is to use C/C++ to describe both hardware and software throughout the design flow. Our methodology supports the efficient mapping of C/C++ functional descriptions directly into hardware and software. The advantages of a C/C++-based flow from the verification point of view are presented. The use of C/C++ to model all parts of the system provides great flexibility and enables faster simulation compared to existing methodologies. We show how co-verification can be done efficiently and effectively at the various levels of abstraction, how co-verification can be used to drive co-design through performance estimation and give an example of implementation for the 8051 architecture.

Figures

Figure 2: block diagram of the DW8051 core

Figure 1: (a) untimed and (b) cycle-accurate co-simulation model

Table 1: number of lines for BFM and testbench

Table 2: simulation time (in seconds) and speed (in clock cycles/ second) for the dw8051 system

Figure 3: co-verification with dw8051 bus functional model

Table 3: simulation time for the cycle accurate model (in seconds)

Frequently asked questions

Q1. What have the authors contributed in "Methodology for hardware/software co-verification in c/c++" ?

In this paper the authors present their C/C++-based design environment for hardware/software co-verification. Their approach is to use C/C++ to describe both hardware and software throughout the design flow. The use of C/C++ to model all parts of the system provides great flexibility and enables faster simulation compared to existing methodologies. The authors show how co-verification can be done efficiently and effectively at the various levels of abstraction, how coverification can be used to drive co-design through performance estimation and give an example of implementation for the 8051 architec- 

Q2. What is the purpose of the instruction set simulator?

When an instruction set simulator is used, the software will make calls to the device drivers which will ultimately get converted to execution of memory read/write instructions. 

Q3. What is the purpose of using one language for the description of both hardware and software?

Using one language for the description of both hardware and software makes mapping easier, allows the designer to move functionality from hardware to software and vice versa, thereby allowing the exploration of different architectures and partitions between hardware and software. 

Q4. What is the common architecture in a system-on-chip?

One of the most common architectures in systems-on-chips consists of CPUs and hardware devices connected to one or multiple memory buses. 

Q5. Why does co-simulation have to be used constantly?

Since the hardware and software teams work separately and in parallel, co-simulation has to be used constantly to ensure that the system still works. 

Q6. What is the function that performs the bus transactions?

The BFM performs the appropriate bus transactions and, in the case of a memory read, sends the received data back to the caller of the method. 

Q7. What are the modes of operation of a CPU core?

CPU cores often have multiple modes of operation (e.g. little/ big endian, multiple timer or serial modes, masked interrupts, etc.) according to the value set on the configuration ports and stored in internal configuration registers. 

Q8. What is the function that keeps track of the number of clock cycles used to perform various bus transactions?

The BFM keeps track of the number of clock cycles used to perform various bus transactions and can provide a detailed report at the end of the simulation (or during each bus transaction). 

Q9. How can the authors speed up the codesign process?

By proper design of the BFM and ISS, performance estimates can be obtained for software execution, which can be used to drive the codesign process. 

Q10. What are the types of sc_address and sc_data?

A BFM provides the following methods to read and write memory:void bfm_read_mem(sc_address addr, sc_data *dat,int num_bytes)void bfm_write_mem(sc_address addr, sc_data dat, int num_bytes)The sc_address and sc_data types are types defined in the BFM. 

Q11. What is the function that is provided by the user?

The handler function is provided by the user and when this function is invoked, it is provided with the details of the interrupt through its argument. 

Q12. What is the reason why a BFM is untimed?

Since the software runs on the host processor (on which development is done), this model is untimed because the software execution time is not accurate. 

Q13. What types of BFMs can be specialized inside?

The various pre-defined types like sc_address, sc_data, sc_register, etc. (see below) can be specialized inside each BFM, therefore allowing complete freedom for each BFM to define these types appropriately. 

Q14. How can one ease the verification bottleneck?

In addition, one can also ease the verification bottleneck by reusing the testbenches that were developed during system validation. 

Q15. What is the function to execute for a particular interrupt?

The function to execute for a particular interrupt is specified using the following BFM method:void bfm_register_handler(sc_interrupt intr, void (*handler)(sc_interrupt))