JP2013020425A - Hardware and software cooperative verification method using open source software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a hardware emulator obtained by suppressing initial introduction cost at lost cost and to provide technology in which a hardware model and the hardware emulator are easily connected.SOLUTION: A hardware and software cooperative verification method using open source software achieves a PC emulator of open source software including means for performing data I/O of a hardware model through a TLM interface for connecting a Qemu and a hardware model by modifying the Qemu being open source software, means for showing the hardware model as a PCI device connected to a PCI bus emulated on the Qemu, and means for starting the Qemu from a System C simulator.

Description

  The present invention relates to a hardware / software co-verification technique, and more particularly to a hardware emulator used in hardware / software co-verification.

  Hardware / software co-verification is a technique for verifying the entire system including software running on the embedded system and LSI, which is hardware, from the design stage prior to completion of the embedded system actual machine. Currently, in LSI design such as SoC (System on Chip) or ASIC (Application Specific Integrated Circuit), software development and hardware development are performed separately, and after the LSI prototype is completed, the software is integrated into the system. Thus, the operation of the LSI is verified. In this case, defective LSIs are often detected when an integrated test is performed after the prototype is completed. If a rework at the end of the development process occurs, especially if an LSI is rebuilt, the development cost or The development period will increase significantly. The purpose of hardware / software co-verification is to verify the entire system including software and hardware LSIs before the embedded system is completed, identify system failures at an early stage before the completion of the actual machine, and The purpose is to avoid rework, in particular, LSI rework (see, for example, Non-Patent Document 1).

  As a hardware / software co-verification method, generally, a hardware model implemented in a system level design language such as SystemC or SpecC and embedded software are operated together on a hardware emulator to verify the entire system. The method of doing is known. There are a plurality of commercial hardware emulators for performing such verification, but the initial introduction cost is generally very high. On the other hand, Qemu is known as a PC emulator of open source software, but Qemu has only a PC emulator function and cannot be used for hardware / software co-verification as it is.

  SystemC is one of system level design languages that are generally popular. SystemC is not strictly a language but a class library defined in the C ++ language, and a hardware model is described in a C ++ language using a SystemC class library (hereinafter referred to as a SystemC library). The hardware model described using the SystemC library can be compiled by a generally used compiler such as gcc. The object file generated as a result of compiling can be executed as a hardware simulator (hereinafter referred to as a SystemC simulator) by linking with the SystemC library. SystemC is so-called open source software and can be obtained and used free of charge.

  A basic block in the structure of the hardware model description by SystemC is called a module. In general, a TLM (Transaction Level Modeling) interface is widely used for interconnection between modules. In order to use the SystemC and TLM interfaces, the SystemC library and the TLM library provided by OSCI (Open SystemC Initiative) are used. These libraries are the core technologies of hardware / software co-verification, and are widely applied to hardware / software co-design and hardware performance evaluation.

http://techon.nikkeibp.co.jp/article/WORD/20090107/163726/

  As mentioned above, the initial installation cost of hardware emulators used for hardware / software co-verification is generally very high, and there are a sufficient number of hardware / software co-verification environments compared to the scale of system development. There is a problem that it is difficult to align. Also, the method of connecting a hardware emulator and a hardware model (for example, a hardware model described in SystemC) differs depending on the hardware emulator, and it is necessary to rewrite a part of the hardware model when performing hardware / software co-verification. There is.

  An object of the present invention is to provide a hardware emulator that can reduce the initial introduction cost at a low cost, and to provide a technique for easily connecting a hardware model and a hardware emulator.

  In order to achieve the above object, the present invention provides a hardware emulator based on open source software having a generally used TLM (Transaction Level Modeling) interface.

  In other words, the present invention is a hardware / software co-verification method using open source software, and by modifying Qemu, which is open source software, via a TLM interface connecting Qemu and a hardware model. Means for performing data I / O on the wear model, means for showing the hardware model as a PCI device connected to the PCI bus emulating on Qmu, and means for starting Qmu from the SystemC simulator A PC emulator of open source software provided is realized.

  According to the present invention, since a PC emulator of open source software is modified and used, it is possible to construct a hardware / software co-verification environment at a low initial introduction cost as compared with the conventional one. A hardware model using the TLM library can be connected to a hardware emulator without modification. The hardware model using the TLM library can be directly recognized from the OS as a PCI device. As a result, the embedded software can perform Memory Mapped I / O and Port Mapped I / O on the LSI (hardware model) in the same manner as the actual machine. The hardware emulator and the hardware model can be easily connected by writing code of several to several tens of steps and executing compilation.

Overview of hardware / software co-verification environment realized in this embodiment Relay module class definition implementation example Flow chart showing the flow of processing at the start of hardware / software co-verification environment operation Flowchart showing the flow of Qemu main loop processing Flow chart showing the flow of instantiating a virtual machine The flowchart which shows the flow of initialization processing of Qemu Example of setting partial areas of various tables

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  In the present embodiment, based on Qem, which is a PC emulator of open source software, the source code of the Qemu is changed, and the hardware model is connected via the TLM interface that connects the Qemu and the hardware model to be verified. A means for performing data I / O is added. Also, by changing the Qemu source code, a means to show the hardware model as a PCI device connected to the PCI bus emulated on Qemu is added, and Qemu is started from the SystemC simulator. Add a means to do.

  FIG. 1 is an overall schematic diagram of a hardware / software co-verification environment realized in this embodiment. Each block in FIG. 1 is realized by executing software on a computer. That is, each of these blocks is realized by being read from a storage device such as an HDD to a main storage device such as a memory and executed by a calculation unit such as a CPU.

  The hardware / software co-verification environment of this embodiment includes a Qemu portion 100 which is a PC emulator of open source software, a PCI bus portion 101 emulated on Qemu, and a PCI device connected on the PCI bus portion 101. A part 102, a relay module part 103 that relays Qemu and a hardware model, a hardware model part 104 that is a hardware / software co-verification target, a software part 105 that is a hardware / software co-verification target, and software And an OS portion 106 that serves as an operation platform of the portion 105. Reference numeral 107 denotes a CPU portion emulating on Qemu, 108 denotes an MCH (Memory Control Hub) portion emulating on Qemu, and 109 denotes a memory portion emulating on Qemu.

  107 to 109 are realized by using the function of emulating the CPU, MCH, and memory that the Qemu 100 has conventionally provided. Regarding PCI buses and PCI devices, some basic PCI devices of general-purpose PCs and PCI buses for connecting them are realized by the functions of Qumu100. In FIG. 1, such a basic PCI device is not shown. In this embodiment, a part corresponding to the PCI device 102 for connecting the hardware model 104 to be verified needs to be added to the Qemu 100. Further, in order to connect the PCI device 102 to the PCI bus, it is necessary to modify a part corresponding to the PCI bus 101 of the Qemu 100. The PCI device 102 and the PCI bus 101 are realized by modifying Qemu described in C language.

  The Qemu 100 and the hardware model 104 are connected via the relay module 103. The relay module 103 is a SystemC module (that is, a C ++ layer) described in SystemC, and is connected to the hardware model 104 through a TLM interface. Also, the connection between the relay module 103 and the PCI device 102 is realized by a method in which a callback function pointer is passed to the PCI device 102. Since the PCI device 102 implemented in the Qemu 100 is a C language layer and the relay module 103 is a C ++ layer, the PCI device 102 cannot call a method of the relay module 103 as it is, and the PCI device 102 passes through the relay module 103. Data cannot be written to or read from the hardware model 104. Therefore, when data is transferred from the PCI device 102 to the relay module 103, a function is issued by a function pointer for callback and data is transferred. Data transfer from the relay module 103 to the PCI device 102 is the same method. In terms of the actual hardware configuration, the PCI device portion 102 corresponds to a PCI card, and the hardware model 104 corresponds to an LSI mounted on the PCI card.

  The hardware model 104 to be verified uses what is described using the SystemC and TLM interfaces. Since the SystemC and TLM interfaces are used in a number of conventionally known hardware simulators, if such a hardware model has already been created, it can be used as it is.

  FIG. 2 is a class definition implementation example of the relay module 103. The relay module 103 is created in advance by the user using SystemC. 2 is a connection socket with the hardware model 104, 202 is a data write method called back from the PCI device 102, 203 is a data read method called back from the PCI device 102, 205 is The constructor of the relay module 103, 206 in FIG. 2 is a method issued from the implementation of the data write method 202, and 207 is a method issued from the implementation of the data read method 203.

  When an object is created from the class of the relay module 103 in FIG. 2, a constructor 205 is executed, thereby securing various table areas and initial settings. Although an implementation example of the constructor 205 is omitted here, an initial setting process after step 502 in FIG. 5 described later is realized by the implementation of the constructor 205.

  FIG. 3 is a flowchart showing the flow of processing at the start of the operation of the hardware / software co-verification environment of FIG. The emulation process by Qemu is executed by the main loop process of Qemu shown in FIG. 4 to be described later, but before the main loop process is started, processes 310 and 320 of FIG. 3 are executed.

  The pre-processing 310 is a process for realizing a means for showing the hardware model 104 as the PCI device 102 connected to the PCI bus 101 emulating on the Qmu from the OS 106. This processing is issued before main () is issued by the GNU gcc extension function_attribute _ ((constructor)).

  In step 311, an area of the DeviceInfo table is secured and attributes are set. The DeviceInfo table is a structure used to emulate the PCI device 102.

  FIG. 7C shows a setting example of a partial area of the structure of the DeviceInfo table (Table 3). The “PCI device identification name character string” is a character string of an identification name that identifies the PCI device 102 for connecting the hardware model 104. The “PCI device description character string” is a character string that describes the PCI device 102. “PCIID device table size” is the size (number of bytes) of the PCI device table (described later in FIG. 7D) corresponding to the PCI device 102. The “PCI device initialization function pointer” is a pointer indicating a function for executing initialization of the PCI device 102.

  The DeviceInfo table shown in FIG. 7 (c) is a table corresponding to the PCI device 102, but there are PCI devices that a general-purpose PC basically includes in addition to the PCI device 102, and all of the devices emulated by Qmu are included. A DeviceInfo table corresponding to the PCI device is secured for each PCI device. All these DeviceInfo tables are connected by a chain, and by accessing this chain, it is possible to realize access to the DeviceInfo table corresponding to each PCI device. This chain is referred to as a DeviceInfo table chain. The “DeviceInfo table chain pointer” is a pointer that points to the next DeviceInfo table connected in the DeviceInfo table chain.

  Returning to FIG. 3, after step 311, in steps 312 to 315, in the DeviceInfo table, the PCI device identification name character string, the PCI device description character string, the PCI device table size (number of bytes), and the initial PCI device name of the PCI device 102. Set the function pointer. Next, in step 316, the DeviceInfo table is added to the DeviceInfo table chain.

  The next pre-process 320 is a process for realizing a means for starting Qemu 100 from the SystemC simulator. As described above, the object file of the hardware model 104 linked with the SystemC library operates as a SystemC simulator. Therefore, a main function that is an entry point of the program is mounted in advance in the SystemC library. On the other hand, Qemu also has a main function that is an entry point. Therefore, the source of Qemu is remodeled, the main function that is the original entry point of Qmu is commented out, and the system is modified so that Qemu is started from the SystemC simulator as indicated by 320 in FIG.

  In this mechanism, since the main function which is the entry point of the program is mounted in advance in the SystemC library, this main function is started in step 321. In step 322, the sc_elab_and_sim function, which is also implemented in the SystemC library, is issued from the main function. In step 323, a function named sc_main is issued from the sc_elab_and_sim function. The entry point of the SystemC simulator is defined as the sc_main function according to the description rules of the SystemC, and the user of the SystemC simulator implements the sc_main function. In the present embodiment, the Qemu 100 is activated from this sc_main function.

  In order to start the Qemu 100, in step 324, the virtual machine is instantiated. This process will be described in detail with reference to FIG.

  Next, in step 325, the hardware model (LSI hardware design description) 104 is instantiated. In step 326, the virtual machine and the hardware model 104 are connected to each other by the Qemu 100. Next, in step 327, the SC_START function implemented in the SystemC library is issued. As a result, processing registered in the sensitivity list (SC_THREAD) is started. The sensitivity list (SC_THREAD) is a list used to control the execution of each process for emulating a hardware model. As will be described later, since the Qemu main loop processing is also registered in the sensitivity list (SC_THREAD), the processing registered in the sensitivity list (SC_THREAD) is started in step 327, so that the hardware / software co-verification in FIG. Environment operation begins.

  FIG. 4 shows the Qemu main loop process (step 401) started at step 327. In the process of the Qemu main loop in step 402, each process registered in SC_THREAD is executed, and if it is a loop process, it is repeatedly executed. When termination is instructed, Qumu termination processing is executed in step 403.

  FIG. 5 shows a flow of processing of instantiating the virtual machine (step 501) in step 324 of FIG. In step 502, the relay module 103 is instantiated. This is an instantiation of the class of the relay module 103 described with reference to FIG. 2, and thus the emulation of the relay module 103 is realized.

  A process 503 is a process for realizing a means for performing data I / O on the hardware model 104 via the TLM interface that connects the Qemu 100 and the hardware model 104. In step 511, a data I / O handler table area is secured.

  FIG. 7A shows a setting example of a partial area of the structure of the data I / O handler table (table 1). In the data I / O handler table, the instance address of the class of the relay module 103 is set. In addition, a memory mapped write function pointer, a memory mapped read function pointer, a port mapped write function pointer, and a port mapped read function pointer to the hardware model 104 are set. These function pointers are callback function pointers from the C ++ layer to the C language layer and correspond to I / O handlers.

  Returning to the processing of FIG. 5, when the area of the data I / O handler table (table 1) is secured in step 511, in step 512, the memory mapped I / O handler is set in the data I / O handler table. In 513, the port mapped I / O handler is set in the data I / O handler table. As a result, data such as each I / O handler function pointer in the data I / O handler table of FIG. 7A is set.

  In step 504, processing up to immediately before the Qemu main loop is executed as initialization processing of the Qemu 100. This process will be described in detail with reference to FIG. In step 505, the Qemu main loop process is registered in the sensitivity list (SC_THREAD).

  FIG. 6 shows the flow of the initialization process (step 601) of the Qemu 100 in step 504 of FIG. A process 602 is a process for realizing a means for showing the hardware model 104 as the PCI device 102 connected to the PCI bus 101 emulating the Qumu 100 from the OS 106.

  First, in step 611, a PCI bus model is created. This is Qemu's original process and is a process of creating a PCI bus table.

  FIG. 7B shows a setting example of a partial area of the PCI bus table (table 2). In the PCI bus table, the head address of a chain list (PCIID chain list) obtained by chaining the PCI device tables corresponding to all the PCI devices connected to the PCI bus 101 is set. Accordingly, the PCI device table corresponding to each PCI device can be accessed by tracing the PCI device chain list from the PCI bus table of FIG. As described above, the DeviceInfo table chain corresponding to each PCI device can be accessed by following the DeviceInfo table chain. By using the DeviceInfo table and the PCI Device table corresponding to each PCI device, the operation of each PCI device can be emulated.

  FIG. 7D shows a setting example of a partial area of the PCID device table (table 4). The PCI Device table includes various PCI configuration register information storage area start addresses, a port mapped I / O handler function pointer (write), a port mapped I / O handler function pointer (read), and a memory mapped I / O. An O handler function pointer (write) and a memory mapped I / O handler function pointer (read) are set.

  Returning to FIG. 6, after creating the PCI bus table of FIG. 7B in step 611, in step 612, an area of the PCI device table corresponding to the PCI device 102 is secured. The same applies to other PCI devices. In this process, the DeviceInfo table corresponding to each PCI device is accessed in order from the top of the DeviceInfo table chain, and the area of the PCI Device table corresponding to the PCI device is secured in order. In step 613, the PCI device table address is set in the PCI device chain list to which the PCI bus model is connected. This process is a process of setting the PCI device table address corresponding to each PCI device secured in step 612 in the PCI device chain list and connecting the PCI device table corresponding to each PCI device in a chain. The order of connection in the chain is the same as the order of PCI devices connected in the DeviceInfo table chain.

  Next, in step 614, the PCI device initialization function pointer of the DeviceInfo table (FIG. 7C) corresponding to each PCI device is read in order from the top of the DeviceInfo table chain, and initialization functions for various PCI devices are issued. . As a result, an initialization function is also issued for the PCI device 102. In step 615, various PCI configuration register information such as the vendor ID, device ID, revision ID, and class code of the PCI device 102 is stored in a predetermined PCI configuration register information storage area, and the address of that area is stored in the PCI Device table ( The various PCI configuration register information storage area start addresses in FIG. In step 616, the port mapped I / O handler is set in the port mapped I / O handler function pointer (write) and the port mapped I / O handler function pointer (read) of the PCID device table. In step 617, the memory mapped I / O handler is set to the memory mapped I / O handler function pointer (write) and the memory mapped I / O handler function pointer (read) of the PCID device table.

  After the initial setting as described above, for example, when performing memory writing from the verification target software 105 to the hardware model 104, the Qemu 100 receives the write command and receives the callback of FIG. A data write method is issued using a function pointer (memory mapped write function pointer to the hardware model 104). Although an implementation example of the data write method is omitted, memory write is emulated by the implementation of the data write method. Memory read, port write, and port read for the hardware model 104 are emulated in a similar manner. Thereby, a means for writing data to and reading data from the hardware model 104 from the Qemu 100 is realized.

  Also, the structures described in FIGS. 7B to 7D are prepared, and the initialization process 310 in FIG. 3 and the initialization process 602 in FIG. 6 are performed, whereby the hardware model 104 is transferred to the PCI bus 101. A means for showing as the PCI device 102 connected to is realized.

  100: Qemu part, 101: PCI bus part emulating on Qemu, 102: PCI device part connected on the PCI bus part 101, 103: Relay module part relaying hardware model with Qemu, 104: Hardware model part to be subjected to hardware / software co-verification, 105: Software part to be subjected to hardware / software co-verification, 106: OS part to be an operation platform of the software part 105, 107: Emulated on Qemu 108: MCH (Memory Control Hub) part emulating on Qemu, 109: Memory part emulating on Qemu.

Claims (1)

A hardware / software co-verification method using open source software,
By modifying Qumu, which is open source software,
Means for performing data I / O to the hardware model via a TLM interface connecting the Qemu and the hardware model;
Means to show the hardware model as a PCI device connected to a PCI bus emulating on Qumu;
A hardware / software co-verification method using open source software, characterized by realizing a PC emulator of open source software comprising means for starting Qemu from a SystemC simulator.

Images