KR20080015691A - Method and apparatus for verifying system on chip model - Google Patents

Abstract

A method and an apparatus for verifying an SOC(System On Chip) module are provided to be extended to process various protocols and estimate reliability of a TL(Transaction Level) model simulator by using information of cycle accuracy. An apparatus for verifying an SOC module includes a TL waveform reader(604), an RTL(Register Transfer Level) waveform reader(606), a user information input unit(602), protocol analyzers(608,610), and a comparator(614). The TL waveform reader receives output signals of a TL simulator. The RTL waveform reader receives output signals of an RTL simulator. The user information input unit receives file names, signal names, valid information from a user and transmits user information to indicate signal values to be read from the output signals to the TL waveform reader and the RTL waveform reader. The protocol analyzers extract valid signals from the signal values output by the TL simulator and the RTL waveform reader based on the file names, the signal names, the valid information received from the user information input unit to push the extracted valid signals to a TL FIFO(First Input First Output) buffer(612) and an RTL FIFO buffer(616). The comparator compares whether the signal values stored in the TL FIFO buffer and the RTL FIFO buffer correspond to each other.

Description

METHOD AND APPARATUS FOR VERIFYING SYSTEM ON CHIP MODEL}

1 is a diagram illustrating a downward approach and an upward approach used when designing a general SoC system.

2 is a diagram illustrating a modeling process using simulation methods in a general SoC design;

FIG. 3 is a diagram illustrating a result of simulating reading data from a memory for implementing an SoC. FIG.

4 is a diagram illustrating a process of comparing HADDR, HTRANS, HRDATA, and HREADY signals every cycle to verify a general SoC model simulation result.

5 is a method flow diagram for comparing sequences to verify general SoC model simulation results;

6 is a detailed configuration diagram of a comparison unit for comparing signal output values of an RTL model simulator and a TL model simulator according to an embodiment of the present invention;

7 is a diagram illustrating a handshaking protocol for extracting valid information by a TL model protocol interpreter and an RTL model protocol interpreter according to an embodiment of the present invention;

8 is a diagram conceptually illustrating a process of calculating a cycle accuracy by a comparator according to an embodiment of the present invention;

9 is an operation flowchart of an RTL model protocol interpreter according to an embodiment of the present invention;

10 is an operation flowchart of a TL model protocol interpreter according to an embodiment of the present invention;

FIG. 11 is a flowchart illustrating an operation of a comparator comparing a TL model simulation result and an RTL model simulation result based on information extracted by a TL model protocol interpreter and information extracted by an RTL model protocol interpreter according to an exemplary embodiment of the present invention.

The present invention relates to a system-on-chip (SoC) design, and more particularly, to a method and apparatus for modeling a model required for a simulation performed in advance to design a system-on-chip.

System-on-a-chip (SoC) consists of many elements such as a processor, timer, interrupt controller, bus, memory, and embedded software (eSW). It was implemented on a single board a few years ago, but now with advances in semiconductor technology it can all be implemented in one circuit.

System design for today's SoC designs requires the proper automation tools needed to analyze system structures and verify hardware and software.

In addition, the design complexity of SoC is increasing as the process technology is advanced and the chip density is increasing, and the design time of SoC is increasing and the time to market is shortened and the design is timely. The need for design quality has increased. Due to this necessity, various methodologies for various SoC modeling have been proposed, and a typical Transaction Level (TL) model methodology is proposed. The TL model is a methodology that abstracts the Register Transfer Level (RTL) model to increase design productivity and speed up simulation.

Using the TL model, the simulation speed is faster, allowing for architecture exploration and performance estimation, resulting in higher design quality.

The design methodology using the TL model is a top-down approach and a bottom-up approach.

1 is a diagram illustrating a downward approach and an upward approach used when designing a general SoC system.

Top-down approach (100) is a first approach to design by the TL model 104 at a high level, then refined (refine) it to implementation. This can be useful when developing a new block. In contrast, the bottom-up approach 102 is an approach to modeling an existing RTL model 106 in a higher level language to make it a TL model 104. This is useful when simulating a higher level when a block is already developed with an RTL model. That is, transaction level modeling (TLM) is a high level modeling method that deals with the implementation of a functional unit or communication mechanism and communication between modules separately. In order for the TLM and RTL (Register Transfer Level) models to communicate with each other, a transactor is required. A transactor is responsible for converting the presentation level from a transaction to an RTL signal and vice versa.

To ensure that the results of TL model simulation are reliable, whether the SoC designer uses a downward approach (100) or an upward approach (102) when modeling, the identities of the results of the TL model 104 and the RTL model 106 are Equivalence should be guaranteed.

In general, in SoC design, the TL model may match the behavior of the RTL model according to the modeling purpose, but the cycle by cycle operation may not be completely identical. In addition, since the TL model is modeled only by some functions of the RTL model when used for software development, it uses a formal equivalence check that compares whether the mathematical model is the same by mathematically modeling the behavior of the actual model, not simulation. it's difficult. Therefore, in this case, as shown in FIG. 2, the result identicality between the TL model and the RTL model is compared through a method of checking whether the same output occurs when the same input is applied using a simulation method. .

2 is a diagram illustrating a modeling process using simulation methods in a general SoC design.

The test vector 200 refers to input required to verify the SoC simulation modeling method, and is input to the TL model simulator 202 and the first transactor # 1 206. The first translator 206 outputs the received test vector to the RTL model simulator 204. In this case, since the role of the first translator 206 requires more detailed information than the input test vector 200 in order to perform the lower level RTL model, additional information is added to the RTL model simulator 204. Will output

As described above, the TL model simulator 202 is faster than the RTL model because it is at a higher level. Therefore, after receiving the test vector 200 directly without a transactor, the TL model simulator outputs the result of the TL model simulator to the second translator # 2 208. In this case, since the output of the TL model simulator 202 is at the upper level, the second translator 208 has a lower level of the simulator result of the input level to maintain the same level as the output of the RTL model simulator outputting at the lower level. Create to level.

If the comparison result is the same in the comparison unit 210, the output of the RTL model simulator 204 of the same level and the simulation result of the second translator 208 are the same, it is found that modeling for successful simulation is performed. Will be.

However, an unexpected corner case may occur when the simulation method shown in FIG. 2 is used to perform modeling method verification for the aforementioned SoC design. To prevent such corner cases, a large amount of test vectors, such as a constrained random test vector, which is a tool that automatically generates test vectors randomly, are required. After simulating such a large test vector, it is almost impossible for a human to see and compare the results. Therefore, an automated tool is required, and the cycle by cycle behavior of the RTL model simulator 204 and the TL model simulator 202 perfectly matches each other even when verification is performed using such commercially available automated tools. It is difficult to automate because of its non-existent nature.

3 below is a timing diagram illustrating an output when the same test vector 200 is input to the current RTL model simulator 202 and the TL model simulator 204.

The results obtained through the general SoC design simulation results as shown in FIGS. 2 and 3 are the same as the test vectors input to the TL model simulator 202 and the RTL model simulator 204. To read the same data.

In general, when interpreting the advanced high-performance bus (AHB) bus protocol, the simulation results of the RTL model and the simulation results of the TL model are consistent with each other.

Figure 3 shows the results of a simulation of reading data from memory for SoC implementation.

In FIG. 3, each signal is a signal used in the AHB bus, and HADDR, HTRANS, HRDATA, and HREADY are the result values of the TL / RTL model simulator, and each definition is as follows.

HADDR: address of memory.

HTRANS: Control signal indicating whether HADDR is valid.

HRDATA: Data read from real memory by TL / RTL model simulator.

HREADY: A control signal that indicates whether the data read from the physical memory is valid. (For example, "1" is valid. "0" is not valid.)

The clock CLK 300 is input to the TL / RTL model simulator together with the test vector.

Referring to the examples of the RTL model simulator 204 and the TL model simulator 204 in FIG. 3, both models respectively store data D0, D1, D2, D3, and D4 at the memory addresses A2, A3, A4, A8, and AC. You can see that it reads.

4 is a diagram illustrating a process of comparing HADDR, HTRANS, HRDATA, and HREADY signals every cycle in order to verify a general SoC model simulation result. That is, in FIG. 4, the signal is read from the waveform every cycle and its values are compared.

In operation 400, the RTL model simulator 204 and the TL model simulator 202 read the HADDR, HTRANS, HRDATA, and HREADY signals in FIG. 3 from the waveform of the input signals every cycle. If the next cycle is started in step 402, the comparator 210 compares the values of the signals read by the RTL model simulator 204 and the TL model simulator 202.

However, as described above, even though the RTL model simulator 204 and the TL model simulator 202 compare the same signals in each cycle simply to check whether they match, the results of the two simulations are not the same each time. It may not. For example, even if only the HADDR of FIG. 3 shows that the clock cycle is C1, the HADDR of the RTL model simulator 204 is A0 but the TL model simulator 202 is 9C.

As described above, in addition to the results of comparing the results of the RTL model simulator and the TL model simulator for each cycle, there is also a method of comparing only the sequence as shown in FIG. 5.

5 is a method flow diagram comparing sequences to verify general SoC model simulation results. First, when comparing sequences, the RTL model simulator 204 and the TL model simulator 202 read the signals from the waveform in step 500, and the signal values are changed in step 504 whenever the signal value of the waveform changes in step 502. Push to FIFO (First Input First Output). In operation 506, when the comparator 210 reads and compares the signal values pushed to the FIFO, sequences may be compared.

However, the method of comparing the sequences shown in FIG. 5 is also inaccurate. Referring to the timing diagram of FIG. 3, the sequence of HADDR among the output signal values of the RTL model simulator 204 is 9C, A0, A2, A3, A4, A8, AC, B0 and HADDR among the output signal values of the TL model simulator 202. It can be seen that the sequence of 9C, A2, A3, A4, A8, AC, B0. That is, since the sequence of the HADDR which is the output signal of the RTL model simulator 204 and the sequence of the HADDR which is the output signal of the TL model simulator 202 are different, this fact cannot be known by the present method even if the modeling result is identical. .

The present invention provides an apparatus and method for verifying modeling of a SoC design simulator.

The present invention provides an apparatus and method for comparing result values of modeling of a SoC design simulator.

An apparatus for verifying simulation modeling for system-on-chip design according to the present invention includes a transaction level waveform reader receiving an output signal of a transaction level simulator, a register transaction level waveform reader receiving an output signal of a register transfer level simulator; A file name and a signal name to be read by the transaction level waveform reader and register transfer level waveform reader among the signals output from the transaction level simulator and the register transfer level simulator, and a protocol interpreter is used by the transaction level waveform reader and register transfer level. A user information input unit for transmitting valid information indicating which of the signals output from the waveform reader should be extracted; the file name, signal name, received from the user information input unit; The protocol interpreter which extracts a valid signal from signal values output by the transaction level waveform reader and the register transfer level waveform reader based on the valid information and pushes the valid signal to a transaction level picobuffer and a register transfer level picobuffer, and the transaction level And a comparator for comparing whether the signal values stored in the PIF buffer and the register transfer level PIF buffer match.

The method for verifying simulation modeling for system on chip design according to the present invention includes a process in which a transaction level waveform reader receives an output signal of a transaction level simulator; And a process in which a register transaction level waveform reader receives an output signal of a register transfer level simulator, and a user information input unit outputs signals output from the transaction level simulator and the register transfer level simulator. Transmitting a file name and a signal name to be read by the transaction level waveform reader and register transfer level waveform reader, and wherein the user information input unit adds a protocol interpreter to the transaction level waveform reader and register transfer level waveform reader. Transmitting valid information indicating which of the signals output from the signal is to be extracted; and the transaction level waveform reader based on the file name, signal name, and valid information received by the protocol interpreter from the user information input unit. And extracting valid signals from the signal values output by the register transfer level waveform reader and pushing them into a transaction level picobuffer and a register transfer level picobuffer, and a comparator stored in the transaction level picobuffer and the register transfer level picobuffer. And comparing the signal values with each other.

DETAILED DESCRIPTION Hereinafter, detailed descriptions of preferred embodiments of the present invention will be described with reference to the accompanying drawings. In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

In the following embodiment of the present invention, the cycle by comparing the results in consideration of the interface protocol for accessing the memory in the comparison unit comparing the output signal values (Signal Value) of the RTL model simulator and the TL model simulator We propose a technique to check whether the results of the RTL model simulator and the TL model simulator are the same even if the cycle by cycle operation does not match completely. Also, when the operation of the RTL model simulator and the TL model simulator is the same, and the cycles are different, we propose a method to quantitatively calculate how different the cycles of the signals output by the two models are.

6 is a detailed block diagram of a comparison unit 600 for comparing signal output values of the RTL model simulator 204 and the TL model simulator 202 according to an embodiment of the present invention.

The comparison unit 600 according to an exemplary embodiment of the present invention includes a user information input unit 602, a TL model waveform reader 604, an RTL model waveform reader 606, a TL model protocol interpreter 608, and an RTL model. A protocol interpreter 610, a TL FIFO buffer 612, an RTL FIFO buffer 616, and a comparator 614.

 In the present invention, first, it is assumed that the handshaking protocol is modeled as a protocol for accessing the memory in the TL model simulator 202 and the RTL model simulator 204. Therefore, TL model and RTL model model master and slave and store the modeling result. Such details will be described later with reference to the drawings below.

The user information input unit 602 receives a file name, a signal name, and valid information indicating a valid signal from the user. The TL model waveform reader 604 is a TL model. User information for indicating which signal value to read from the output signal of the simulator 202 is transmitted. In this case, the user configuration includes a file name and a signal name information. For example, if there is an HTRANS signal of AMBA AHB, which signal corresponds to the HTRANS signal in the output signal of the TL model simulator 202 and the signal corresponding to HTRANS in the output signal of the RTL model simulator 204. Tells you which signal is.

The TL model waveform reader 604 reads a signal corresponding to the file name and signal name received from the user information input unit 602 from the TL model simulator 202 and outputs the signal to the TL model protocol interpreter 608.

In fact, the signal read by the TL model waveform reader 604 is a low level signal value output from the second translator 208. In addition, the user information input unit 602 also transmits the file name, signal name, and valid information (Valid Information) indicating which signal is valid to the RTL model waveform reader 606 together.

The RTL model waveform reader 606 reads a signal corresponding to the file name and signal name received from the user information input unit 602 from the output signal of the RTL model simulator 204 and outputs the signal to the RTL model protocol interpreter 610. .

The TL protocol interpreter 608 extracts only valid information among the signals received from the TL model waveform reader 604 in consideration of the bus protocol for accessing the memory. The valid information and the method of extracting the valid information vary depending on the protocol, but in general, a handshaking protocol is used. In this case, the TL protocol analyzer 608 receives valid information indicating which of the signals received from the TL model waveform reader 604 is a valid signal from the user information input unit 602. The handshaking protocol will be described with reference to FIG. 7 below.

That is, the TL protocol interpreter 608 selects valid signal values among the signals output from the TL model waveform reader 604 based on the file name, signal name, and valid information received from the user information input unit 602. Stored in the buffer 612. In the embodiment of the present invention, since the protocol is assumed to be a handshaking protocol, the valid signal values are a request signal, a request information signal, a response signal, and a response information signal.

The RTL protocol interpreter 610 extracts only valid information among the signals received from the RTL model waveform reader 606 in consideration of the bus protocol for accessing the memory. The valid information and the method of extracting the valid information vary depending on the protocol, but in general, a handshaking protocol is used. In FIG. 6, the TL model protocol interpreter 608 and the RTL model protocol interpreter 610 are illustrated as separate blocks, but may be configured as one block.

The first input first output (FIFO) buffer 612 stores signal values output from the TL model protocol interpreter 608 according to an index on a first-in first-out basis. The signal values stored in the TL FIFO buffer 612 are called elements, and are request values, request information signals, which are signal values determined by the TL model protocol interpreter 608 to be valid information. A response signal and a response information signal are stored.

The RTL FIFO buffer 616 stores signal values output from the RTL model protocol interpreter 610 according to an index on a first-in first-out basis. Similarly, the RTL FIFO buffer 616 includes a request signal, a request information signal, a response signal, and response information, which are signal values determined as valid information by the RTL model protocol interpreter 610. The signal is stored and these signal values will be referred to as elements.

Comparator 614 compares the function of the elements stored in the TL FIFO buffer 612 and the RTL FIFO buffer 614. Comparing the function of the elements according to an embodiment of the present invention means that the request signal, the request information signal, the response information signal, the response signal stored in the TL FIFO buffer 612 is the RTL FIFO buffer 614 Means that the request signal, the request information signal, the response information signal, and the response signal stored in the C-1 are matched. The request signal, the request information signal, the response information signal, and the response signal will be described below with reference to FIG. 7. If the functions of the elements are the same, the comparator 614 compares the cycle accuracy of the TL model simulator 202 and the RTL model simulator 204. In addition, the comparator 614 outputs the result according to the comparison result of the element functions of the two FIFO buffers 612 and 616 and the comparison result of the cycle accuracy to the user through the display unit 618.

In addition, in the embodiment of the present invention, it is assumed that the TL FIFO buffer 612 and the RTL FIFO buffer 616 have N sizes (from index 0 to index N-1), and the comparator 614 first The element function of index 0 of the RTL FIFO buffer 616 and the N-1 th element function of index 0 of the TL FIFO buffer 614 are compared. The function of index 1 of the RTL FIFO buffer 616 and the N-1 th element function of index 0 of the TL FIFO buffer 614 are compared. The comparator 9614 compares the element values in the FIFIO buffer in this manner and outputs the result to the display unit 618.

7 is a diagram illustrating a handshaking protocol for extracting valid information by the TL model protocol interpreter 608 and the RTL model protocol interpreter 610 according to an exemplary embodiment of the present invention.

 In the present invention, as described above, it is assumed that the handshaking protocol is modeled as a protocol for accessing the memory in the TL model simulator 202 and the RTL model simulator 204. Therefore, TL model and RTL model model master and slave and store the modeling result.

6 and 7, protocol interpreters 608 and 610 according to an embodiment of the present invention extract the request and response signals from the results of modeling the master and slave by the TL simulator 202 and the RTL simulator 204. To the FIFO buffers 612 and 606, respectively.

In FIG. 7, when the data is transmitted or received, the first transfer is the master 700 and the slave 702 responds when the transfer comes from the master 700. . Transfer refers to a bundle of a plurality of request signals and response signals, and the same as reference numeral 720 in FIG. 7.

First, in order for the master 700 to start the transfer to the slave 702, information about the transfer must be transmitted to the slave 702. If the transfer requires data, the master 700 needs to inform the slave 702 of what data is required and what kind of transfer is required. Information about such a transfer is represented as a request information signal in FIG. 7. That is, the request information signal is a bundle of signals necessary for the slave 702 to understand the request signal of the master 700.

In FIG. 7, a signal represented as a request 704 is a signal indicating when the request information 706 is valid. The request signal 704 is also used to send a request information signal only to a specific slave when several slaves share the request information signal. When the slave 702 receives the request signal 704, the slave 702 interprets the request information signal 706 and displays a corresponding response.

If the slave 702 has requested data from the master 700, the slave 702 should send the corresponding data and inform the master 700 of the error if an error has occurred. The response of the slave 702 is represented as a response information 710 signal in FIG. 7. In other words, the response information signal 710 is a bundle of signals corresponding to the response of the slave 702 to the request signal 704 of the master 700.

It is necessary to inform the master 700 when the response information signal 710 sent by the slave 702 to the master 700 is also valid. In FIG. 7, a signal denoted as a response 708 is a signal indicating to the master 700 when the response information 710 is valid.

The request / response signal may be implicit. As in the case of memory access, when the master 700 sends a request signal and waits for a certain access time without a special response signal from the slave 702, access is performed. This is the case assuming success. In this case, the request signal is inactive for a certain access time, and the request signal is inactive since the access time is inactive. The time point may be regarded as the time point at which the response information signal is valid.

The present invention does not compare whether the master 700 and the slave 702 operate according to the protocol, and request information signals exchanged between the master 700 and the slave 702 modeled by the RTL model simulator 204 are not compared. And whether the master 700 and the slave 702 modeled by the TL model simulator 202 are also exchanged.

That is, the master 700 and the slave 702 send and receive response information signals, such as the same request information signal, by determining the results of the RTL model simulator 204 and the TL model simulator 202.

That is, according to the present invention, when the same request signal and request information are input to the TL model simulator 202 and the RTL model simulator 204, the same response signal and response information ( The response information is compared against the bus protocol for accessing the memory.

Considering the protocol means that the response information when the response signal is active while ignoring the response information signal in which the response signal is not active ( response information) compares only signals and checks for equality Since the response information signals are compared based on the response signals, there is no problem in comparing the cycles. This is because considering the protocol, we can know when the data is valid even if the cycles are different.

The present invention also calculates cycle accuracy for cycle accuracy verification of the TL model simulator 202 and the RTL model simulator 204. According to an embodiment of the present invention, the cycle accuracy calculated by the comparator 614 is composed of the following two informations.

Latency accuracy and duration accuracy.

Conceptually showing the above bar is as shown in Figure 8 below.

8 is a diagram conceptually illustrating a process of calculating a cycle accuracy by a comparator 614 according to an embodiment of the present invention.

First, the terms used below will be defined before explaining FIG. 8.

Transfer: Bundle of multiple request and response signals.

Initial (820): The time point at which the first request signal occurs in the transfer.

Finish (822): When the last response signal occurs during transfer.

Latency Accuracy (800, 802): A measure of the equality of cycles between when the first request signal occurs in the RTL model simulator 204 and when the first request signal occurs in the TL model simulator 202. (For master). The measured value of the cycle between the time when the first response signal occurs in the RTL model simulator 204 and the time when the first response signal occurs in the TL model simulator 202 (for the slave).

Duration accuracy 804: Length of when the first Requset signal is generated and the final response signal is generated in the RTL model simulator 204 and when the first Requset signal is generated in the TL model simulator 202. A measure of how much the length of a time point and the time of the final response signal is generated.

From the point of view of the bus, the starting point of the occupancy of the bus is called the initial point, and the release point is called the finish point.

Latency accuracy 800, 802 indicates how accurate the timing of transfer is initiated in TL model simulator 202 and RTL model simulator 204. Reference numeral 806 denotes a point in time at which the request signal 806 occurs first of the RTL transfers 818, that is, an initial point. In the case of reference numeral 810, the first request signal 810 of the TL transfers 816 is generated. Since the point of occurrence, that is, the initial point, the comparator compares the two points as shown by reference numeral 820 to measure the latency accuracy 800 at the master 700.

The RTL transfer 818 is a bundle of request signals and response signals generated in the RTL model simulator 204, and the TL transfer 816 is a bundle of request signals and response signals generated in the TL model simulator 202.

That is, the comparator 614 according to the embodiment of the present invention measures the latency accuracy 800 of the master 700, and thus, the initial point of the RTL transfer 818 and the TL transfer 816. Compare the initial points. To compare the latency accuracy 802 of the slave 702, the finish point 822 of the TL model simulator 202 and the RTL model simulator 204 is compared. That is, a time point 812 at which a finish signal is generated last in the TL transfer 816 is compared with a time point 814 at which a finish signal last occurred in the RTL transfer 818.

Latency accuracy is an indicator that can be used to predict the accuracy of the performance estimation results of the SoC system. Duration accuracy indicates how accurate the duration is from the transfer to the finish after the initialization is initiated.

When verifying the master, the TL model simulator 202 and the RTL model simulator 204 receive the same response. However, finalizing the transfer can be different from the response, so the duration accuracy also makes sense when verifying the master. Duration accuracy can be used to predict the accuracy of utilization of an interface shared by multiple masters and slaves, like a bus.

Also, because duration affects the performance of the SoC system, duration accuracy is also used to predict the accuracy of performance estimation results.

In order for the comparator 614 to calculate cycle accuracy, the TL model protocol interpreter 608 and the RTL model protocol interpreter 610 may cycle through the TL model waveform reader 604 and the RTL model waveform reader 606, respectively. Cycle information should also be extracted.

Cycle information is information indicating the number of cycles between the initiate and finish cycles. Cycle information may include a time point at which a transfer is initiated and a time point at which the transfer is completed. Knowing only these two points in time, the comparator 614 can calculate the latency accuracy and the duration accuracy.

The TL model protocol interpreter 608 and the RTL model protocol interpreter 610 transmit cycle information at the time when the transfer is initiated and finished together with the response information to the comparator 614. do.

The comparator 614 first checks whether the element functions of the two FIFO buffers 612 and 616 are the same as described above. If the functions are the same, cycle accuracy is calculated using the cycle information. The comparator 614 uses Equations 1 and 2 below when calculating cycle accuracy.

First, latency accuracy is calculated using Equation 1 below.

(Master)where

(Master)

(Slave)or

(Slave)

Duration Accuracy is calculated as shown in Equation 2 below.

where

In Equation 1 and Equation 2, InitiateCycle _TL and InitiateCycle _RTL mean an initiation cycle of transfer in the TL model simulator 202 and the RTL model simulator 204, respectively. Similarly, FinishCycle _TL and FinishCycle _RTL represent the finish cycles of TL model simulator 202 and RTL model simulator 204, respectively. The end cycle is information indicating which cycle the finish is in. The comparator 614 may calculate a latency error and a duration error using an initialize cycle and a finish cycle. In addition, the error rate can be calculated by accumulating all the errors and dividing by the total simulation cycle, and subtracting this from 1 calculates the accuracy.

TotalSimulationCycle _RTL is the total cycle for which RTL simulation is performed. In this case, since it indicates how accurate the RTL model simulator 204 is, the simulation cycle of the RTL model simulator 204 is used. Cycle accuracy depends on the input test vector. Therefore, when calculating the cycle accuracy, it is desirable to calculate the accuracy for each function to be tested.

9 is a flowchart illustrating an operation of the RTL model protocol interpreter 610 according to an exemplary embodiment of the present invention.

First, in step 900, the RTL model protocol interpreter 610 receives a signal from the RTL model waveform reader 606. The RTL model protocol interpreter 610 receives a file name, a signal name, and valid information received from the user information input unit 602 to extract a request information signal, a response information signal, and cycle information.

In operation 902, the RTL model protocol analyzer 610 checks whether a request signal is activated among the signal values received from the RTL model waveform reader 604. The request signal may be mapped 1: 1 with one signal or may be a combination of several signals. If the request signal is activated in step 902, the request information and cycle information are extracted from the signals received from the RTL waveform reader 606 in step 904, and the extracted request information and the request information in step 906. An initial cycle is pushed to the RTL FIFO buffer 616. Information on which signal is request information and when is an initial cycle is received from a user information input unit 602.

In step 908, the RTL model protocol interpreter 610 receives a signal from the RTL model waveform reader 606. Hereinafter, an operation for checking whether the response signal is activated and extracting the response information and the end cycle information is performed. In step 910, the RTL model protocol interpreter 610 checks whether the response signal is activated. If the response signal is activated in step 910, the RTL model protocol interpreter 610 extracts a response information signal and an end cycle in step 912. Information on which signal is a response information signal and when is a finish cycle is also received from the user information input unit 602 as well.

In step 914, the RTL model protocol interpreter 610 pushes the extracted response information and the end cycle to the RTL FIFO buffer 616.

10 is an operation flowchart of the TL model protocol interpreter 608 according to an embodiment of the present invention.

First, in step 1000, the TL model protocol interpreter 608 receives a signal from the TL model waveform reader 604. The TL model protocol interpreter 608 receives the file name, signal name, and valid information received from the user information input unit 602 to extract the request information signal, the response information signal, and the cycle information.

In step 1002, the TL model protocol analyzer 608 checks whether a request signal (Request) of the signal values received from the TL model waveform reader 604 is activated. The request signal may be mapped 1: 1 with one signal or may be a combination of several signals. If the request signal is activated in step 1002, the request information and cycle information are extracted from the signals received from the TL waveform reader 604 in step 1004, and in step 1006, the request information and the request information are extracted. An Initial Cycle is pushed into the TL FIFO buffer 612. Information on which signal is request information and when is an initial cycle is received from a user information input unit 602.

In step 1008, the TL model protocol interpreter 608 receives a signal from the TL model waveform reader 604. Hereinafter, an operation for checking whether a response signal is activated and extracting response information and end cycle information is performed. In step 1010, the TL model protocol interpreter 608 checks whether the response signal is activated. If the response signal is activated in step 1010, the TL model protocol interpreter 608 extracts a response information signal and an end cycle in step 1012. Information on which signal is a response information signal and when is a finish cycle is also received from the user information input unit 602 as well.

In step 1014, the TL model protocol interpreter 608 pushes the extracted response information and the end cycle to the TL FIFO buffer 612.

In the embodiment of the present invention, the protocol interpreters 608 and 610 are separately separated according to the TL model and the RTL model for convenience of description, but may be implemented as one protocol interpreter in practice.

Referring back to the operation of the protocol interpreters 608 and 610, which are the core of the present invention described with reference to Figs. 9 and 10, the waveforms from the RTL model waveform reader 606 and the TL model waveform reader 604 are respectively shown. The necessary information is read out and pushed to the FIFO buffers 612 and 616. The protocol interpreters 608 and 610 receive the required signal values from the RTL model waveform reader 606 and the TL model waveform reader 604, and request information, response information, and cycle information. Configuration information required to extract cycle information is obtained from a user information input unit.

 The protocol interpreters 608 and 610 read the signals from the RTL model waveform reader 606 and the TL model waveform reader 604 to determine whether the request signal is active. The request signal may be mapped 1: 1 with one signal or may be a combination of several signals.

Information about which signal corresponds to the request signal or in which combinations produce the request signals is received from the user information input unit 602. When the request signal is activated, the protocol interpreter 608 and 610 extracts the request information and the initial cycle at the time and pushes the push signal into the FIFO buffers 612 and 616. push). The user information input unit 602 also receives which signal is request information and when it is an initial cycle. The protocol interpreter 608 and 610 waits until the response signal is activated and pushes response information and a finish cycle to the FIFO buffers 612 and 616 when the response signal is activated. At this time, like the request, the RTL model waveform reader 606, the TL model waveform reader 604, and the user information input unit 602 are provided with necessary information.

11 is a comparator comparing a TL model simulation result and an RTL model simulation result based on information extracted by the TL model protocol interpreter 608 and information extracted by the RTL model protocol interpreter 610 according to an exemplary embodiment of the present invention. An operation flow chart of 614 is shown.

The comparator 614 according to an embodiment of the present invention starts to operate when both FIFO buffers 612 and 616 are pushed more than one. The elements pushed from both FIFO buffers 612 and 616 are compared one by one to see if there are the same elements. When the same element is identified, the cycle accuracy is calculated using Equation 1 and Equation 2, and the identified elements are deleted from the FIFO buffers 612 and 616.

The operation of the comparator 614 will now be described in detail with reference to FIG. 11.

First, in step 1100, the comparator 614 checks the sizes of the TL FIFO buffer 612 and the RTL FIFO buffer 616. That is, the comparator 614 checks how many actual data are in the TL FIFO buffer 612 and the RTL FIFO buffer 616. In step 1102, the comparator 614 checks whether the sizes of the TL FIFO buffer 612 and the RTL FIFO buffer 616 are larger than '0', and thus, the result of the check, the TL FIFO buffer 612 and the RTL FIFO buffer. If the sizes of 616 are all greater than zero, the flow proceeds to step 1104.

In steps 1104 and 1106, the comparator 614 initializes a variable that stores the indexes of the TL FIFO buffer 612 and the RTL FIFO buffer 616. The 'Index_RTL' variable of FIG. 11 is a variable for storing the number of data of the RTL FIFO buffer 616 by the comparator 614, and the 'Index_TL' variable is the comparator of the data of the TL FIFO buffer 612. As a variable for storing whether 614 has compared, each variable stores an index of a FIFO buffer.

In step 1104, the comparator 614 initialized the index of the RTL FIFO buffer 616 to '0' and the index of the TL FIFO buffer 612 to '0' in step 1106. Read the 'Index_RTL' th element from the (). In operation 1110, the comparator 616 reads the 'Index_TL' th element from the TL FIFO buffer 612. Elements in steps 1108 and 1110 indicate request information and response information stored in the respective FIFO buffers 612 and 616.

In step 1112, the comparator 616 compares whether the read elements have the same function. Here, the function comparison of the elements means that the RTL model protocol interpreter 610 and the TL model protocol interpreter 608 extract and compare the request information and the response information pushed to the FIFO buffers 612 and 616, respectively. That is, the request information extracted and pushed by the RTL model protocol interpreter 610 and the request information extracted and pushed by the TL model protocol interpreter 608 are compared, and the response information extracted and pushed by the RTL model protocol interpreter 610 and pushed. The comparison of the extracted response information extracted by the TL model protocol interpreter 608 with each other is used to mean that element functions are compared in FIG. 11.

In step 1114, the comparator 616 checks whether the functions between the two elements are correct, and if the function is the same between the two elements, the comparator 618 reports to the user that the functions between the two elements are the same. In step 1114, the comparator 616 comparing the functions between the two elements compares the cycle accuracy using Equation 1 and Equation 2 in step 1116.

In step 1118, the comparator 616 checks whether the Index_RTL of the RTL FIFO buffer 616 is '0'. If the index_RTL is not '0' in operation 1118, the controller proceeds to operation 1120 and reports to the user via the display unit 618 that the function is different in the elements before the Index_RTL in the RTL FIFO buffer 616. If the results of the TL simulator and the RTL simulator are completely identical, the Index_RTL should always be '0' in step 1118. In other words, if Index_RTL is not '0', the result of the RTL simulator is different from that of the TL simulator. Therefore, report this element to the user.

On the other hand, if the Index_RTL is '0' in step 1118, the comparator 616 proceeds to step 1122 and checks whether the Index_TL is '0'. If the index_TL is not '0' as a result of the check in step 1122, the process proceeds to step 1124, and the TL FIFO buffer 612 reports to the user through the display unit 618 that the functions of the elements before the Index_TL are different. If the results of the TL simulator and the RTL simulator are completely identical, the Index_TL should always be '0' in step 1124. If Index_TL is not '0', the result of the TL simulator is different from that of the RTL simulator. Therefore, report this element to the user.

In operation 1126, the comparator 614 pops all elements from the RTL FIFO buffer 616 and the TL FIFO buffer 612 to Index_RTL and Index_TL.

In step 1128, the comparator 614 checks whether the IndeX_TL variable is counted up to the maximum size of the TL FIFO buffer 612. If the index_TL variable counts up to the maximum size of the TL FIFO buffer 612 as a result of the check in step 1128, the process proceeds to step 1132 and determines whether the Index_RTL variable counts up to the maximum size of the RTL FIFO buffer 616. If the index_TL variable in step 1128 is the maximum size of the TL FIFO buffer 612, the comparator 614 increases the index_TL variable by '1' in step 1130 and then proceeds to step 1110.

On the other hand, if the Index_RTL variable is smaller than the maximum size of the RTL FIFO buffer 616 in step 1132, the comparator 614 proceeds to step 1134 to increase the Index_RTL variable by '1' and proceeds to step 1106, and step 1132 If the Index_RTL variable is the maximum size of the RTL FIFO buffer 616, the process proceeds to step 1100.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the appended claims, but also by the equivalents of the claims.

According to the present invention, the functional equivalence can be checked even though the cycle accuracy of the two SoC system design simulators to be compared is not guaranteed, unlike the conventional equivalent check method. have. Therefore, in the exemplary embodiment of the present invention, it is useful to check the function-accurate level equivalence between models that cannot guarantee cycle accuracy because the RTL model simulator and the abstraction level are different, as in the TL model simulator. The present invention is extensible to handle various protocols and can predict the reliability of the TL model simulator results using cycle accuracy information calculated by the present invention.

Claims (10)

An apparatus for verifying simulation modeling for system on chip design, Transaction level waveform reader that receives the output signal of the transaction level simulator, A register transaction level waveform reader that receives an output signal from a register transfer level simulator, Among the signals output by the transaction level simulator and the register transfer level simulator, a file name and a signal name to be read by the transaction level waveform reader and the register transfer level waveform reader, and a protocol interpreter is used by the transaction level waveform reader and register transfer level waveform. A user information input unit for transmitting valid information indicating which of the signals output from the reader should be extracted; Based on the file name, signal name, and valid information received from the user information input unit, a valid signal among the signal values output by the transaction level waveform reader and the register transfer level waveform reader is extracted, and a transaction level picobuffer and a register transfer level are extracted. The protocol analyzer that pushes into the buffer buffer, And a comparator for comparing whether the signal values stored in the transaction level picopbuffer and the register transfer level picopbuffer match. The method of claim 1, wherein the protocol analyzer, A transaction level protocol interpreter for extracting a valid signal among signal values output by the transaction level waveform reader based on the file name, signal name, and valid information received from the user information input unit, and outputting the valid signal to a transaction level picobuffer; A register transfer level protocol interpreter for extracting a valid signal among the signal values output by the register transfer level waveform reader based on the file name, signal name, and valid information received from the user information input unit and outputting the valid signal to a register transfer level pipebuffer; System on a chip model verification device, characterized in that it comprises a. The method of claim 2, The comparator uses latency accuracy and duration accuracy to determine the cycle accuracy of the transaction level simulator and the register transfer level simulator if the elements pushed in the RTL FIFO buffer and the TL FIFO buffer match. System on a chip model verification device, characterized in that it further comprises a check box. The method of claim 3, The comparator is a system on chip model verification device, characterized in that for calculating the latency accuracy (Latency Accuracy) using Equation 3 below,

where

(Master) or

(Slave) In Equation 3, InitiateCycle _TL and InitiateCycle _RTL are initial cycles of transfer in the transaction level model simulator and register transfer level model simulator, respectively, and FinishCycle _TL and FinishCycle _RTL are the transaction level model simulator and register, respectively. The end cycle in the transfer level model simulator, and TotalSimulationCycle _RTL means the total number of times the register transfer level simulation was performed. The method of claim 3, The comparator is a system-on-chip model verification device, characterized in that the duration accuracy (Latency Accuracy) is calculated using Equation 4 below;

where

In Equation 4, InitiateCycle _TL and InitiateCycle _RTL mean initial cycles of transfer in the transaction level model simulator and register transfer level model simulator, respectively, and FinishCycle _TL and FinishCycle _RTL are the transaction level model simulator and register, respectively. The end cycle in the transfer level model simulator, and TotalSimulationCycle _RTL means the total number of times the register transfer level simulation was performed. A method for verifying simulation modeling for a system on chip design, A process in which a transaction level waveform reader receives an output signal of a transaction level simulator, A process in which a register transaction level waveform reader receives an output signal of a register transfer level simulator, Transmitting, by the user information input unit, a file name and a signal name to be read by the transaction level waveform reader and the register transfer level waveform reader among the signals output by the transaction level simulator and the register transfer level simulator; Transmitting, by the user information input unit, valid information indicating which signal of a signal output from the transaction level waveform reader and the register transfer level waveform reader is to be extracted by a protocol interpreter; The protocol interpreter extracts a valid signal among signal values output by the transaction level waveform reader and the register transfer level waveform reader based on the file name, signal name, and valid information received from the user information input unit. And push to register transfer level pipebuffer, And a comparator comparing the signal values stored in the transaction-level level buffer and the register transfer level level buffer. 7. The process of claim 6, wherein the protocol interpreter pushes the valid signal to the transaction level picopbuffer and the register transfer level picopbuffer, A transaction level protocol interpreter extracting a valid signal among signal values output by the transaction level waveform reader based on the file name, signal name, and valid information received from the user information input unit, and outputting the valid signal to a transaction level picobuffer; The register transfer level protocol interpreter extracts a valid signal from the signal values output by the register transfer level waveform reader based on the file name, signal name, and valid information received from the user information input unit, and outputs the valid signal to the register transfer level picobuffer. A method for verifying a system on a chip model, comprising the procedure. The method of claim 7, wherein The comparator uses latency accuracy and duration accuracy to determine the cycle accuracy of the transaction level simulator and the register transfer level simulator if the elements pushed in the RTL FIFO buffer and the TL FIFO buffer match. System on a chip model verification method further comprising the step of checking. The method of claim 8, The comparator includes a method for calculating the latency accuracy (Latency Accuracy) using the following equation (5), characterized in that the system-on-chip model verification method,

where

(Master) or

(Slave) In Equation 5, InitiateCycle _TL and InitiateCycle _RTL are initial cycles of transfer in the transaction level model simulator and register transfer level model simulator, respectively, and FinishCycle _TL and FinishCycle _RTL are the transaction level model simulator and register, respectively. The end cycle in the transfer level model simulator, and TotalSimulationCycle _RTL means the total number of times the register transfer level simulation was performed. The method of claim 8, The comparator is a system-on-chip model verification method, characterized in that the duration accuracy (Latency Accuracy) is calculated using the following Equation (6),

where

In Equation 6, InitiateCycle _TL and InitiateCycle _RTL are initial cycles of transfer in the transaction level model simulator and register transfer level model simulator, respectively, and FinishCycle _TL and FinishCycle _RTL are the transaction level model simulator and register, respectively. The end cycle in the transfer level model simulator, and TotalSimulationCycle _RTL means the total number of times the register transfer level simulation was performed.

Images