JP5492704B2 - Hardware-software co-verification system, method, and program - Google Patents

Description

  The present invention relates to a hardware-software co-verification method for embedded system development, and more particularly to a co-verification method for an FPGA (Field Programmable Gate Array) board and a software simulator.

  With the recent enhancement of functionality and performance of embedded systems, hardware and software to be developed are becoming more and more complex, and the development period and cost tend to increase. On the other hand, the development cycle is becoming shorter, and there is a need for shorter and lower cost embedded system development.

  In order to solve the above problems, a virtual prototyping technique is used. The virtual prototyping method is a method that enables software and firmware to be verified on the virtual SoC before the completion of SoC (System on Chip), which enables software and system integration at the early stage of development. -It has the effect of reducing costs and improving quality.

  Specifically, the above method creates a model that simulates the actual operation of hardware such as a CPU and memory on a software simulator that can generate a clock and perform operation verification with cycle accuracy. A virtual SoC having the same function as is created. Software and firmware can be verified on the virtual SoC in parallel with hardware development.

  However, the hardware that makes up the SoC (virtual SoC) on the software simulator must be modeled, and the hardware assets described in the existing RTL (Register Transfer Level) can be handled on the software simulator. There was no problem.

  In order to solve the above-mentioned problem, a method for implementing (programming) existing hardware assets in the FPGA of the FPGA board and performing cooperative verification of the operation of the FPGA board (implemented circuit) and the software simulator (virtual SoC) ( "Hardware-software co-verification method") is used. In this collaborative verification method, it is not necessary to create a hardware model, and the existing hardware assets and IP (Intellectual Property) can be used as they are, and the FPGA can be executed at high speed (circuit operation). There is a merit.

  However, the cooperative verification method has the following problems. The hardware mounted on the FPGA board operates on the clock in the FPGA (second time axis), while the hardware on the software simulator operates on the clock in the software simulator (first time axis). (The clock on the FPGA side is faster). In the independent control of these two systems with different time axes, these two systems operate asynchronously with different clocks, and should be synchronized with each other, especially in an environment that requires high-precision and high-speed verification such as a mechanism. Has become an issue.

  In order to deal with the above problems, there are (1) a cycle-by-cycle synchronization method, (2) a transaction synchronization method, and Japanese Patent Application Laid-Open No. 2009-3583 (Patent Document 1).

  (1) In the cycle-by-cycle synchronization method, the clock generated by the software simulator is given to the FPGA board mounting circuit (circuit mounted by FPGA), and the operation is verified while synchronizing both in every cycle (clock unit). It is a method. In this method, synchronization is performed every cycle, so that highly accurate verification is possible.

  (2) The transaction synchronization method is a method in which access from the software simulator to the FPGA board mounting circuit is performed in transaction units (command units such as READ / WRITE). When a transaction (command) is issued from the software simulator, a transactor circuit mounted on the FPGA board analyzes the command, converts it to a cycle level signal, and operates the FPGA board mounting circuit. In this system, synchronization between hardware and software can be performed by issuing a multi-cycle synchronous execution instruction (for example, synchronous execution for 50 cycles) as a transaction (command).

  Patent Document 1 gives a start condition and an end condition as conditions for synchronization from the software side for activation of the hardware side (FPGA board mounting circuit) from the software side (software simulator). A technique for synchronizing each cycle in a section in which is taken is disclosed.

JP 2009-3583 A

  The hardware-software co-verification method of the background art has the following problems.

  (1) The cycle-by-cycle synchronization method has a merit that high-accuracy verification can be performed because synchronization is performed for each cycle. However, since the cycle-by-cycle communication is required between hardware and software, the simulation speed decreases. Problem.

  (2) Since the transaction synchronization method is synchronized in units of multiple cycles (transaction units), there is an advantage that high-speed verification is possible. Since the hardware side performs processing (operation) with a high-speed clock, processing (operation) in units of a plurality of cycles within one transaction is sufficient. On the other hand, when an event such as an interrupt occurs from the FPGA board mounting circuit, it is difficult for the software simulator to acquire the event (event information) at an accurate timing, and thus there is a problem of a decrease in verification accuracy. The prior art does not consider the means for the software side to properly acquire and process the generated event (event information) from the hardware side, and the cycle time after the cycle time at which the generated event (event information) was acquired The accuracy of verification is low because

  Moreover, in patent document 1, when there are many sections to synchronize, there exists a problem that a simulation speed falls. Further, as in the method (2), since the software simulator does not consider means for appropriately acquiring and processing events from the FPGA board, there is a problem that verification accuracy is lowered.

  In view of the above, the object of the present invention is based on the above-described transaction synchronization method (method for synchronizing in a plurality of cycles) in the cooperative verification between hardware (FPGA board mounting circuit) and software (simulator). In this way, high-speed and short-time verification is realized, and the software side properly acquires and processes the event (event information) generated from the hardware side (a mechanism for processing the event information at an accurate timing). It is to provide a technology that can realize high-precision verification by providing, that is, a technology that can realize high-speed and high-precision verification.

  In order to achieve the above-described object, a representative embodiment of the present invention is configured such that a target system (in cooperation with a software simulator and a circuit mounted (programmed) on a programmable hardware circuit (FPGA board or the like). A hardware-software co-verification system or the like that verifies the operation of an embedded system (SoC, etc.), and has the following configuration.

  In this system, a hardware circuit and a software simulator are connected by a communication medium and operate with each clock, and a transaction is performed between an interface model configured in the software simulator and a transactor circuit configured in the hardware circuit. Synchronize with

  This system (1) issues a pre-operation instruction transaction with designation of the number of synchronous cycles from the software simulator (interface model) to the hardware circuit (transactor circuit), and the hardware circuit (connection Circuit) has a first function of confirming in advance information including the presence / absence of an event and the number of event occurrence cycles in units of a plurality of synchronization cycles.

  In this system, (2) if there is an event, the system adjusts the number of synchronization cycles according to the number of the event occurrence cycles, and changes from the software simulator (interface model) to the hardware circuit (transactor circuit). On the other hand, it has a second function of issuing an operation instruction transaction with designation of the adjusted number of synchronization cycles, operating a hardware circuit (connection circuit) according to the operation instruction, and acquiring and processing event information. .

  According to the representative embodiment of the present invention, in the hardware-software collaborative verification, the above-mentioned transaction synchronization method is basically assumed to realize verification at high speed and in a short time. High-precision verification can be realized by providing a means (a mechanism for processing event information at an accurate timing) on the software side to appropriately acquire and process an event generated from the hardware side.

BRIEF DESCRIPTION OF THE DRAWINGS It is a figure for demonstrating the outline | summary of the system (hardware-software co-verification system) of one embodiment of this invention, (a) is between hardware (FPGA board mounting circuit) and software (software simulator). An outline of the operation at the time of cooperative verification (simulation) is shown, and (b) shows an example such as the number of synchronization cycles. It is a figure which shows the structural example of the system of one embodiment of this invention. It is a figure which shows the structural example of the required function on the software side (FPGA board I / F model) and the hardware side (transactor circuit). It is a figure which shows the processing flow of an FPGA board I / F model. It is a figure which shows the processing flow of a transactor circuit. It is a figure for demonstrating the application result (effect) of this Embodiment. It is a figure for demonstrating the problem of the conventional transaction synchronization system.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that components having the same function are denoted by the same reference symbols throughout the drawings for describing the embodiment, and the repetitive description thereof will be omitted. Hereinafter, HW: hardware, SW: software, TR: transaction, E: event, etc. are abbreviated as appropriate.

<Overview>
An overview of a system (HW-SW cooperative verification system) according to an embodiment of the present invention will be described with reference to FIG. This method (HW-SW cooperative verification method) is an operation / process (HW-SW cooperative verification method shown in FIGS. 1, 4 and 5) on the system configuration (verification environment) shown in FIGS. (Procedure). 6 and 7 show examples and effects of verification by this method in comparison with the prior art.

  FIG. 1A shows an outline of operations and processes between the SW simulator (FIGS. 2 and 100) and the FPGA board mounting circuit (FIGS. 2 and 200). FIG. 1B shows an example of the number of synchronization cycles (M).

  (A0) At the time of verification, the SW simulator (FIG. 2, 100) sends a single command (C0) in the cooperative verification method that synchronizes with the FPGA board I / F model (FIG. 2, 101) in multiple cycles. Issue. C0 is accompanied by designation of the number of synchronization cycles (M = M1). In the FPGA board I / F model, based on the command (C0), the following two types of commands (C1, C2) are issued as transactions to the transactor circuit (FIG. 2, 201) of the FPGA board mounting circuit in order. To do.

  (A1-1) First, in the first transaction, a command C1 for a prior operation instruction is issued. C1 is a command for confirming an event in advance by a prior operation. C1 is issued together with the specified number of synchronization cycles (M = M1).

  (B1-1) The transactor circuit receives C1 {M1}. (B1-2) The transactor circuit saves the state of the connection circuit (user circuit B) before the preliminary operation according to C1. (B1-3) The transactor circuit pre-operates the connection circuit (user circuit B) for a plurality of cycles (M1) according to C1 {M1}, so that the presence / absence of events in the plurality of cycles and the number of event generation cycles (M2) ) Is confirmed and saved. (B1-4) The transactor circuit restores the state of the connection circuit (user circuit B) to the state before the pre-operation after the pre-operation. (B1-5) After the pre-operation, the transactor circuit notifies the FPGA board I / F model of the C1 result response indicating completion of the pre-operation and the presence / absence of an event.

  (A1-2) The SW simulator (FPGA board I / F model) receives the notification (C1 result). (A1-3) The FPGA board I / F model can acquire the presence / absence of an event and the number of event occurrence cycles (M2) from the C1 result, that is, the event advance confirmation can be performed.

  (A2-1) The FPGA board I / F model then issues this operation instruction command C2 as a second transaction in accordance with the result of the preceding confirmation. At this time, the number of synchronization cycles M is adjusted according to the event status (the presence or absence of an event), and C2 is issued by specifying the adjusted number of synchronization cycles M. When there is no event, the synchronization cycle number M is kept M1, and when there is an event, the synchronization cycle number M is changed to M2.

  (B2-1) The transactor circuit receives C2 {M1 / M2}. (B2-2) The transactor circuit operates the connection circuit (user circuit B) by the number of synchronization cycles M (M1 / M2) designated by C2. (B2-3) The transactor circuit notifies the C2 result response. (A2-2) The SW simulator (FPGA board I / F model) receives the notification (C2 result) and acquires and processes the event information.

  In FIG. 1B, the designation of the number of synchronization cycles M at C0 is 50, for example. The designation of the number of synchronization cycles M1 in C1 is also 50. If there is an event due to a prior action (event advance confirmation) by C1, the event generation cycle number M2 is set to 20, for example. In response to this, the designation of the number of synchronization cycles (M2) of C2 becomes 20.

<System>
In the configuration example of the present system (verification environment) illustrated in FIG. 2, the PC 10 and the FPGA board 20 are configured to be connected via a communication medium 30 (such as a cable or wireless). The PC 10 is an execution environment for the SW simulator 100. The FPGA board 20 includes an FPGA (mounting circuit) 200 as a hardware simulator (programmable circuit).

  The SW simulator 100 is software that can construct a virtual SoC 110 (target system) by combining software models that simulate actual operations of hardware such as a CPU and a memory, and can verify the operation of the target system.

  The SW simulator 100 inputs parameter information 106 such as the number of synchronization cycles M. M can be arbitrarily specified. The user (verifier) of the PC 10 can input and set parameter information 106 and instructions. The output (verification status, verification result, etc.) by this system is displayed on the screen of the PC 10, for example.

  In the SW simulator 100 (virtual SoC 110), a CPU model 104, a memory model 105, a user circuit A102, and an FPGA board I / F (interface) model 101 are connected to the bus model 103. The user circuit A102 is set as a SW model by the user.

  In the FPGA 200 of the FPGA board 20, a transactor circuit 201 and a user circuit B 202 (existing circuit, IP, etc.) are mounted (programmed). The user circuit B 202 is an existing hardware asset such as an RTL existing circuit or a mounting circuit (connection circuit) based on IP, and is set by a user and is a verification target.

  Communication (transaction) is performed between the FPGA board I / F model 101 and the transactor circuit 201 of the FPGA 200. Details are shown in FIG.

  At the time of verification, an operation instruction to the FPGA 200 mounting circuit (user circuit B 202) is started when the SW simulator 100 issues a transaction or its instruction (transaction information) to the FPGA board I / F model 101. As a result, the FPGA board I / F model 101 issues a transaction (corresponding command signal or the like) to the transactor circuit 201, thereby executing the operation of the user circuit B 202 via the transactor circuit 201. For a transaction issued from the SW simulator 100, the FPGA board I / F model 101 and the transactor circuit 201 operate and process in synchronization with each other in units of a plurality of cycles (M ≧ 1) by the designated number of synchronization cycles M. . In this system, the FPGA board I / F model 101 and the transactor circuit 201 are provided with necessary functions in order to acquire the event (E information) issued by the user circuit B 202 at the accurate timing on the SW simulator 100 side. (Figure 3).

<Conventional problems>
FIG. 7 shows problems of the conventional transaction synchronization method. In the SW simulator (upper side, first time axis T1 (cycle time point)) and the FPGA mounting circuit (lower side, second time axis T2 (cycle time point)), the number of synchronization cycles M = 50 for each transaction. A case where operation and verification are performed in synchronization will be described as an example.

  An operation instruction (M = 50) transaction (TR) is issued from the SW simulator to the FPGA mounting circuit from the simulation start (0 cycle time) to N cycle time (701) (702). Upon receiving this operation instruction, the FPGA mounting circuit starts an operation for M = 50 cycles (703). In the FPGA mounting circuit, it is assumed that an event is issued (705) at the time of N + 20 cycles (704) after 20 cycles from the start (703). As a result, a signal indicating the occurrence event is sent to the software side (706). Subsequently, at the time of N + 50 cycles (707), the FPGA mounting circuit completes the operation for M = 50 cycles, thereby issuing an operation completion notification (response to the operation instruction) to the software side (708).

  The SW simulator receives a notification (708) from the hardware side at the time of N + 50 cycles (707), determines the presence / absence of an event, and acquires event information (709).

  Here, as a problem of the prior art, although the FPGA implementation circuit has already issued an event at the time of N + 20 cycle (704) (706), the SW simulator can acquire and confirm the event at the time of N + 50 cycle ( 707), which is delayed by 30 cycles. Due to this delay, the verification accuracy is lowered.

  In order to solve the above problems, in this embodiment, the FPGA board I / F model 101 and the transactor circuit 201 of FIG. 2 have the functions shown in FIG. A characteristic verification method such as adjustment is realized.

<Function>
FIG. 3 particularly shows a configuration example of functions (processing units) included in the FPGA board I / F model 101 and the transactor circuit 201 (an arrow indicates an example of a processing relationship between functions). Each of these functions is realized by program processing on the FPGA board I / F model 101 side, and the transactor circuit 201 side is realized by a mounting circuit.

  The FPGA board I / F model 101 includes a transaction information analysis function 401, a transactor circuit signal conversion function 402, a prior operation instruction function (= event advance confirmation function) 403, an operation instruction function 404, an event information acquisition / issue function 405, and the like. Is provided.

  The TR information analysis function 401 analyzes TR information issued from the host (SW simulator 100), issues a command (C0) such as WRITE, READ, and multi-cycle synchronous operation, and necessary information associated with execution of the issued command (Parameter information 106) and the like are acquired.

  The transactor circuit signal conversion function 402 converts the TR information acquired by the TR information analysis function 401 into a signal for issuing a transaction (such as a corresponding command) to the transactor circuit 201.

  The pre-operation instruction function 403 includes an event advance confirmation function, and gives the transaction signal converted by the transactor circuit signal conversion function 402 to the transactor circuit 201 as a pre-operation instruction (first command: C1). . The signal of C1 is accompanied by designation of the number of synchronization cycles (M1). The pre-operation instruction function 403 can acquire information such as the occurrence of an event and the number of occurrence cycles (M2) based on the result (notification) returned from the hardware side, and can confirm the event in advance.

  The operation instruction function 404 gives the transaction signal converted by the transactor circuit signal conversion function 402 to the transactor circuit 201 as an operation instruction (second command: C2). Here, according to the information such as the presence / absence of an event obtained by the prior operation instruction function 403 as the number M of synchronization cycles specified by C2, if there is no event, the number of synchronization cycles (M1) specified by the prior operation instruction (C1) Is set as it is, and when there is an event, it is set to change to the number of event occurrence cycles (M2).

  The event information acquisition / issuance function 405 is a function for performing processing related to an event with a host (SW simulator 100). When there is an event, the event information is acquired from the transactor circuit 201, and the SW simulator 100 is Issue an event such as an interrupt (giving event information).

  The transactor circuit 201 includes a transaction information analysis function 501, a cycle level signal conversion function 502, a state saving function 503, a connection circuit preliminary operation function 504, a state restoration function 505, a connection circuit operation function 506, a storage area 520, and the like.

  The TR information analysis function 501 analyzes a signal of a transaction issued from the FPGA board I / F model 101, issues an issue command such as WRITE, READ, and multi-cycle operation, and information necessary for executing the issue command (parameter information 106). Etc.).

  The cycle level signal conversion function 502 converts the transaction information acquired by the TR information analysis function 501 into a cycle level signal for operating the circuit (user circuit B202) connected to the transactor circuit 201.

  The state saving function 503 stores (saves) the current state of the target connection circuit (user circuit B202) in the storage area 520 as connection circuit state restoration information 511. The connection circuit state restoration information 511 is information for restoring the state of the connection circuit to the state immediately before the pre-operation.

  The connection circuit pre-operation function 504 includes an event advance confirmation function, and the connection circuit (user circuit B 202) is pre-operation (P1 for distinction) for the number of synchronization cycles (M = M1) acquired by the transaction information. Let When an event occurs within the number of synchronization cycles (M1), information (512) of the number of event occurrence cycles (M2) in which the event has occurred is stored in the storage area 520.

  The state restoration function 505 uses the connection circuit state restoration information 511 stored in the storage area 520 to restore (return) the state after the pre-operation in the connection circuit to the state before the pre-operation.

  The connection circuit operation function 506 operates the connection circuit (user circuit B202) by the number of synchronization cycles (M = M1 / M2) acquired from the transaction information (P2 for distinction).

  In addition, the method / means relating to the above-described saving / restoration (acquisition of connection circuit state restoration information 511, etc.) is not particularly limited. Examples include a method of using the FPGA readback function or a configuration in which the connection circuit has a state saving function.

<Conditions>
Based on FIG. 1 etc., conditions (premises), examples, etc. are as follows regarding the verification (simulation) processing and circuit configuration in the system of the present embodiment. In the present embodiment, one command (C0) is issued from the upper level (SW simulator 100) for one multi-cycle synchronous operation, and in response to this, the lower level (FPGA board I / F model 101, transactor) In the circuit 201), two processes of a first command (C1) that is an instruction for a prior operation (event advance confirmation) and a second command (C2) that is an instruction for this operation are automatically performed.

  With respect to transaction information issued from the SW simulator 100 to the FPGA board I / F model 101, a command (C0) of “multiple cycle synchronous operation” is issued at a certain cycle time N (time N cycles after the start of simulation). The The command (C0) is accompanied by designation of the number of synchronization cycles M. As an example, M = 50. Transaction information including C0, M = 50 is issued to the FPGA board I / F model 101.

  In the transaction from the FPGA board I / F model 101 to the transactor circuit 201, the first instruction (C1) and the second instruction (C2) are sequentially performed based on C0. The number M of synchronization cycles designated by each is M1 for C1 and M1 / M2 for C2. Corresponding to these, the pre-operation (P1) and the main operation (P2) are sequentially performed on the FPGA 200 side.

  Further, as a premise / example, the user circuit B 202 on the FPGA 200 side is a circuit in which an event occurs at an N + 20 cycle point, for example, 20 cycles after the N cycle point due to the command issuance (operation start) (FIG. 1 ( b), FIG. 6) described later. The presence / absence of an event occurrence is “present”, and the event occurrence cycle number (M2) is 20.

<Processing flow>
A processing flow based on the above conditions will be described. FIG. 4 shows the processing of the FPGA board I / F model 101 and FIG. 5 shows the processing of the transactor circuit 201 (corresponding to FIG. 1, FIG. 3, FIG. 6 and the like). Hereinafter, S401 and the like indicate processing steps.

  S401: In FIG. 4, when the FPGA board I / F model 101 receives transaction information (including C0, M, etc.) from the upper level at the time of N cycles, the TR information analysis function 401 analyzes the TR information. That is, information such as an issue command: C0 and the number of synchronization cycles: M = 50 is acquired. If necessary, the cycle level signal conversion function 502 converts the signal into a signal corresponding to the clock on the hardware side.

  S402: The transactor circuit signal conversion function 402 performs processing to convert the signal to be issued to the transactor circuit 201 using the acquired information (C0, M).

  S403: The pre-operation function 403 issues, as a first command: C1 (first transaction), a pre-operation instruction for the designated number of synchronization cycles (M1 = 50) to the transactor circuit 201 using the above signal. To do.

  S404: The FPGA board I / F model 101 (preliminary operation instruction function 403) waits for notification of the C1 result from the transactor circuit 201. This notification is a notification of advance operation completion (event advance confirmation) and includes at least information indicating the presence or absence of an event. Upon receiving this notification, the FPGA board I / F model 101 (preliminary operation instruction function 403) obtains the information by referring to the information on the number of event occurrence cycles (M2) in the storage area 520 of the transactor circuit 201 in FIG. As described above, since the connection circuit (user circuit B202) issues an event at the time of N + 20 cycles, 20 is acquired as the number of event occurrence cycles (M2). Note that not only the presence / absence of an event but also the number of event occurrence cycles (M2) may be notified together in the notification of the C1 result.

  S405: The prior operation instruction function 403 determines (confirms) the presence / absence of an event based on the notification (event information). If there is an event (Y), the process proceeds to S406, and if there is no event (N), the process proceeds to S409.

  S409: When there is no event (N), the operation instruction function 404 uses the operation instruction command 404 to specify the operation instruction command (C2) with the number of synchronization cycles (M = 50) initially specified (C0, C1). The transaction is issued to the transactor circuit 201.

  S406: When there is an event (Y), before issuing the operation instruction command (C2) by the operation instruction function 404, the designated number of synchronization cycles (M) is adjusted to the number of event issuance cycles (M2 = 20). To change.

  S407: The operation instruction function 404 designates the number of synchronous cycles (M2 = 20) after the change, and issues an operation instruction command (C2) to the transactor circuit 201 as a second transaction.

  S408: Since there is an event, an event has just occurred after the operation for the cycle of M2. The event information acquisition / issuance function 405 acquires event information based on the event information and issues the event information to the SW simulator 100.

  S410: The operation instruction function 404 receives the C2 result (notification) in S409 or S408, and ends the process.

  S501: In FIG. 5, a transaction from the FPGA board I / F model 101 is issued to the transactor circuit 201 (a corresponding command or the like is received). The TR information analysis function 501 acquires a pre-operation instruction (C1) (M1 = 50) or an operation instruction (C2) (M1 = 50 or M2 = 20) by analysis.

  S502: The transactor circuit 201 determines whether the acquired command is C1 or C2. In the case of C1 (Y), the process proceeds to S503, and in the case of C2 (N), the process proceeds to S510.

  S503: The state saving function 503 saves (saves) the current state of the connection circuit (user circuit B202) in the storage area 520 as connection circuit state restoration information 511.

  S504: The connection circuit preliminary operation function 504 causes the connection circuit (user circuit B202) to perform a preliminary operation (P1) for the number of synchronization cycles (M1 = 50) designated by C1.

  S505: With the pre-operation of C1, the connection circuit pre-operation function 504 acquires event information when there is an event that occurs in the connection circuit (user circuit B 202).

  S506: If there is an event based on the event information (Y), the process of S507 is performed. In the example described above, the connection circuit (user circuit B202) generates an event at, for example, N + 20 cycles.

  S507: The connection circuit preliminary operation function 504 sets information on the number of event occurrence cycles (M2 = 20) in the storage area 520 for the occurrence event.

  S508: The state restoration function 505 restores the state of the connection circuit (user circuit B202) to the state before the pre-operation (the state at the N cycle) using the information (511) saved in S503.

  S509: On the other hand, in the case of the operation instruction (C2), the connection circuit operation function 506 operates the connection circuit (user circuit B202) for the number of synchronization cycles (M1 = 50 or M2 = 20) designated by C2. P2).

  S510: The transactor circuit 201 notifies the FPGA board I / F model 101 of the result of the pre-operation (P1) of S504 or the operation (P2) of S509 as a response.

<Effects>
According to the present embodiment, since synchronization can be achieved in a plurality of cycles, high-speed and short-time verification can be realized, and the software side appropriately acquires and processes an event generated from the hardware side ( Since it has a function of event advance confirmation (pre-operation) as a mechanism for processing event information at an accurate timing), highly accurate verification can be realized.

  In the conventional cycle-by-cycle synchronization method, the number of transactions between HW-SWs increases for verification of a plurality of cycles, so the verification speed is slow. On the other hand, in this embodiment, two transactions C1 and C2 are sufficient for verification of a plurality of cycles, so that the verification speed is increased. In addition, in the conventional transaction synchronization method, since the occurrence of an event is different from the processing timing, the verification accuracy is low. On the other hand, in the present embodiment, since the processing can be performed at the timing according to the occurrence of the event, the verification accuracy is increased.

  An example will be described with reference to FIGS. FIG. 6 shows the application result of the method of this embodiment in comparison with the conventional transaction synchronization method of FIG. In FIG. 6, at the time of verification, the SW simulator 100 issues an instruction (C0) (M = 50) of “multiple cycle synchronous operation” at the N cycle time (601) from the start of the simulation. At this time, by issuing a pre-operation instruction (C1) (M1 = 50) for event advance confirmation from the FPGA board I / F model 101 to the transactor circuit 201 (first transaction), event information (event Yes, M2 = 20) is already acquired. According to the result of the event advance confirmation, the synchronization cycle number M is adjusted, and the operation instruction (C2) (M2 = 20) is issued from the FPGA board I / F model 101 to the transactor circuit 201 (second transaction). ) (602). As a result, the connection circuit (user circuit B 202) of the FPGA 200 is operated just until the event occurs. In the connection circuit of the FPGA 200, an event is issued (605) at an N + 20 cycle point (604) after 20 cycles from the operation start (603) at the N cycle point (601), and an operation completion notification is made (606). The SW simulator 100 receives the notification (606) at the time of N + 20 cycles (604), and can acquire and process event information (607).

  In the prior art of FIG. 7 described above, the event acquisition and processing are at the time of N + 50 cycles, whereas in the present embodiment of FIG. 6, events can be acquired and processed immediately at the time of N + 20 cycles. Verification accuracy is increased.

  The number M of synchronization cycles can be controlled by the parameter (106). As another embodiment, the number of synchronization cycles M (M1 specified by C1) is not set to a constant value but is variably controlled by the parameter (106) in the case of multiple synchronizations. For example, the next preferred M1 value is determined in consideration of the result (event occurrence status) up to the previous time. Thereby, verification in consideration of cycle accuracy and operation time becomes possible.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiment. However, the present invention is not limited to the embodiment, and various modifications can be made without departing from the scope of the invention. Needless to say.

  The present invention can be used for verification systems, FPGA boards, software simulators, and the like in embedded system development.

  DESCRIPTION OF SYMBOLS 10 ... PC, 20 ... FPGA board, 30 ... Communication medium, 100 ... Software simulator, 101 ... FPGA board I / F model, 102 ... User circuit A, 103 ... Bus model, 104 ... CPU model, 105 ... Memory model, 106 ... parameter information, 110 ... virtual SoC, 200 ... FPGA (mounting circuit), 201 ... transactor circuit, 202 ... user circuit B, 401 ... transaction information analysis function, 402 ... signal conversion function for transactor circuit, 403 ... pre-operation instruction function , 404 ... Operation instruction function, 405 ... Event information acquisition / issue function, 501 ... Transaction information analysis function, 502 ... Cycle level signal conversion function, 503 ... State save function, 504 ... Connection circuit pre-operation function, 505 ... State restoration function 506: Connection circuit operation function 51 DESCRIPTION OF SYMBOLS 1 ... Connection circuit state restoration information, 512 ... Number of event generation cycles, 520 ... Storage area.

Claims (6)

A hardware-software co-verification system for verifying the operation of a target system by coordinating a circuit programmed with a programmable hardware circuit and a software simulator,
The hardware circuit and the software simulator are connected by a communication medium and operate with respective clocks, and a transaction is performed between an interface model configured in the software simulator and a transactor circuit configured in the hardware circuit. Synchronized with
(1) Issuing a transaction by a first command, which is a pre-operation instruction with designation of the number of synchronous cycles, from the interface model of the software simulator to the transactor circuit of the hardware circuit, A first function for confirming in advance information including the presence / absence of an event occurrence and the number of event occurrence cycles in a plurality of cycles of the synchronization cycle number by performing a prior operation;
(2) According to the preceding confirmation, if there is an event, the number of synchronization cycles is adjusted in accordance with the number of event generation cycles, and the adjustment is made to the transactor circuit of the hardware circuit from the interface model of the software simulator. A second function for issuing a transaction by a second command, which is an operation instruction accompanied with designation of the number of synchronization cycles, operating the hardware circuit according to the instruction, and acquiring and processing generated event information. A hardware-software co-verification system characterized by the above. The hardware-software co-verification system according to claim 1,
A single command for instructing synchronous operation in units of multiple cycles is issued from the software simulator to the interface model,
In accordance with the single command, the interface model issues a first command for the pre-operation instruction to the transactor circuit, receives a result of the first command, and then receives the result of the first command from the interface model. A hardware-software co-verification system characterized by issuing a second command of the operation instruction to a transactor circuit and receiving a result of the second command. The hardware-software co-verification system according to claim 1,
The software circuit interface model notifies the software simulator interface model of the occurrence of the event, and the notification causes the software simulator interface model to transmit the event generation cycle count from the hardware circuit transactor circuit. A hardware-software co-verification system characterized by acquiring information. The hardware-software co-verification system according to claim 2,
Upon receipt of the first command, the transactor circuit of the hardware circuit performs the preliminary operation after saving the state of the connection circuit, and then changes the state of the connection circuit based on the save to the state of the preliminary operation. A hardware-software co-verification system characterized by restoring to a previous state. A hardware-software co-verification method for verifying the operation of a target system by coordinating a circuit programmed with a programmable hardware circuit and a software simulator,
The hardware circuit and the software simulator are connected by a communication medium and operate with respective clocks, and a transaction is performed between an interface model configured in the software simulator and a transactor circuit configured in the hardware circuit. Synchronized with
(1) Issuing a transaction by a first command, which is a pre-operation instruction with designation of the number of synchronous cycles, from the interface model of the software simulator to the transactor circuit of the hardware circuit, A first processing step of confirming in advance information including the presence / absence of an event occurrence and the number of event occurrence cycles in a plurality of cycles of the number of synchronization cycles by performing a prior operation;
(2) According to the preceding confirmation, if there is an event, the number of synchronization cycles is adjusted in accordance with the number of event generation cycles, and the adjustment is made to the transactor circuit of the hardware circuit from the interface model of the software simulator. A second processing step of issuing a transaction by a second command which is an operation instruction accompanied with designation of the number of synchronization cycles performed, operating the hardware circuit according to the instruction, and acquiring and processing generated event information; A hardware-software co-verification method characterized by comprising: A program for realizing the software simulator in a hardware-software co-verification system that verifies the operation of a target system by coordinating a circuit programmed with a programmable hardware circuit and a software simulator,
The hardware circuit and the software simulator are connected by a communication medium and operate with respective clocks, and a transaction is performed between an interface model configured in the software simulator and a transactor circuit configured in the hardware circuit. Synchronized with
(1) Issuing a transaction by a first command, which is a pre-operation instruction with designation of the number of synchronous cycles, from the interface model of the software simulator to the transactor circuit of the hardware circuit, A first process for confirming in advance information including the presence / absence of an event occurrence and the number of event occurrence cycles in a plurality of cycles of the synchronization cycle number by performing a prior operation;
(2) According to the preceding confirmation, if there is an event, the number of synchronization cycles is adjusted in accordance with the number of event generation cycles, and the adjustment is made to the transactor circuit of the hardware circuit from the interface model of the software simulator. A second process of issuing a transaction by a second command, which is an operation instruction accompanied with designation of the number of synchronized cycles, operating the hardware circuit according to the instruction, and acquiring and processing the generated event information. A program characterized by having the program executed.

Images