JP2007018440A - Architecture verification apparatus - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To obtain an architecture verification apparatus capable of easily correcting a hardware model. <P>SOLUTION: Each of hardware models 200a, 200b performs simulation based on description indicating the operation, data processing unit and timing of hardware. As the description, algorithm operation description 211, data access description 212 and timing generation description 213 are separately constituted. Consequently, the correction of operation description is not required for the change of a data processing unit and the change of operation timing. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an architecture verification device that verifies the architecture of a system composed of hardware and software.

In general, when a logic device such as an LSI (Large Scale Integrated circuit) is designed, an operation simulation is performed for the purpose of verifying its function and performance.
By mapping the algorithm verification C program to a hardware model that matches the architecture to be realized as an LSI and performing an architecture-level simulation, the performance of the realized LSI, the required memory capacity, and the degree of bus congestion are evaluated before logical design It becomes possible to do. In such architecture verification, for example, as described in Patent Document 1, the architecture configuration is changed such as software / hardware processing division, hardware block processing unit, bus bit width / arbitration, and the like. This makes it possible to derive an optimum architecture.

JP 2004-38390 A

  However, when the algorithm verification C program is simply mapped to the hardware model, a great amount of labor is required to correct the hardware model by changing the architecture configuration. In addition, data transfer between each hardware block that is an element of the architecture is performed via the bus, but transferring data to the hardware model of the bus at the time of simulation causes the simulation execution to be delayed. .

  The present invention has been made to solve the above-described problems, and an object of the present invention is to provide an architecture verification apparatus that can easily modify a hardware model.

  The architecture verification device according to the present invention divides a description into an algorithm operation description and a data access description when a simulation is performed with a hardware model based on a description indicating a hardware operation, a data processing unit, and timing. It is a thing.

  In the architecture verification apparatus of the present invention, since the description of the hardware model is divided into the algorithm operation description and the data access description, the hardware model can be easily corrected.

Embodiment 1 FIG.
FIG. 1 is an explanatory diagram of a hardware model in the architecture verification apparatus according to Embodiment 1 of the present invention. Prior to this description, the concept in the architecture verification apparatus will be described.
FIG. 2 is an explanatory diagram for mapping an algorithm verification C program in the architecture verification apparatus.

  The algorithm verification C program 1 without a hardware image is divided into software processing and hardware processing, the software processing is assigned to the CPU 100, and the hardware processing is assigned to the hardware models 200a, 200b, and 200c of each hardware block. The data area referred to by the CPU 100 and the hardware models 200a, 200b, and 200c is assigned to the main memory model 300, the register 101 of the CPU 100, the individual memory 201 and the register 202 in each hardware model 200a, 200b, and 200c. Data is referred to via the bus model 400.

  The operation of the algorithm verification C program 1 is assigned to the CPU 100 and the hardware models 200a, 200b, and 200c, and the data area is assigned to the main memory model 300, the individual memory 201, and the registers 101 and 202. If the entire operation can be simulated in the unit of time, the same operation as that of the realized LSI can be simulated.

  As a result, the operation of the realized LSI can be confirmed at the architecture design stage before the logic design of the LSI, and the performance of the LSI processing speed, memory usage, and bus congestion can be evaluated. By performing this evaluation, it becomes possible to clarify the processing capability of the LSI to be realized, problems such as bottlenecks, and improvements. If problems and improvements are clarified, the architecture can be changed (software and hardware division change, hardware processing unit change, bus data width / processing priority change), and the optimal LSI architecture can be achieved. It is possible to find out.

  In the configuration as described above, when the algorithm verification C program 1 is simply mapped to the hardware models 200a, 200b, and 200c, the description of each hardware model 200a, 200b, and 200c includes the operation, data processing unit, and timing. It takes a lot of effort to modify the hardware model due to the architecture change. Therefore, in the present invention, as shown in FIG. 1, the description of each hardware model 200a, 200b is divided into an algorithm operation description 211, a data access description 212, and a timing generation description 213.

  In FIG. 1, an algorithm operation description 211 is a description showing operations / functions realized by LSI and the order of operations. For example, it is a description indicating that the variable A and the variable B are added, and if the result is a positive value, the addition result and the variable C are multiplied and stored in the variable M.

  The data access description 212 is the following description. That is, in architecture verification, it is not always necessary to describe details of the variable reference procedure and storage procedure, but it is necessary to indicate whether each variable is a register or a memory. It is necessary to indicate whether it is a register that exists in the hardware model that is being used or a register that exists in another hardware model. Therefore, a data access description is prepared as a description indicating such variable reference and storage.

  The timing generation description 213 is the following description. That is, the algorithm operation description 211 and the data access description 212 described above describe logical operations, and do not describe the number of cycles that are processed in the realized LSI. Therefore, a timing generation description 213 is prepared to designate such timing. The timing generation description 213 includes a timing generation description for data access and a timing generation description for algorithm operation.

  In the hardware model as shown in FIG. 1, when the data unit processed by the hardware is changed, the operation itself is not changed, but the data access unit is changed. The synchronization timing with is changed.

  For example, in image data processing, there are two cases where data for one screen is read at a time and data processing is performed, and data processing is performed by reading data line by line. A plurality of hardware blocks exist in an LSI, and each has a unique processing function. When processing one screen of data at a time, one hardware block processes all the data of one screen and then transfers the data to another hardware block. On the other hand, when data is read and processed line by line, a process is performed in which data is transferred line by line to another hardware block.

  In both cases, the processing contents (operations) are the same for the entire LSI, but when processing with one screen of data, data transfer occurs until each hardware block finishes processing all of the one screen. Therefore, the synchronization timing becomes longer and the data transfer amount (= access unit) per time increases. On the other hand, in the case of processing with data for each line, data transfer occurs after the processing for one line, so the timing for synchronization is shortened and the amount of data transferred at one time is also smaller than in the case of each screen.

  Further, the synchronization timing of the hardware model is changed depending on the hardware circuit to be realized. For example, in a pipeline control of a specific hardware block, when a circuit processed in a three-stage pipeline is changed to a four-stage pipeline, the generation of a pipeline synchronization signal in the hardware block is 3 The processing is changed from processing with one unit as one unit to processing with four units as one unit. As a result, the access frequency to the memory is also changed.

  Even when the unit of data processed by hardware is changed or when it depends on the hardware circuit to be realized, in this embodiment, the algorithm operation description 211, the data access description 212, Since the timing generation description 213 is described separately, a simulation can be performed by changing only the data access description or the timing generation description without changing the description of the entire model when the architecture is changed.

  As described above, according to the architecture verification apparatus of the first embodiment, based on the description indicating the hardware operation, the data processing unit, and the timing, in the architecture verification apparatus that performs the simulation with the hardware model, the description is Since the algorithm behavior description and the data access description are separated, it is not necessary to modify the behavior description for the change of the data processing unit, and it is possible to cope by modifying only the data access description. There is an effect that it can cope without changing the description of the entire model.

  In addition, according to the architecture verification apparatus of the first embodiment, in the architecture verification apparatus that performs the simulation with the hardware model based on the description indicating the hardware operation, the data processing unit, and the timing, the description is converted into the algorithm operation description. Since the timing description is divided into the timing description, it is not necessary to modify the behavior description for the change of the operation timing, and it is possible to cope with the modification of only the timing generation description. There is an effect that it can cope without changing the description.

Embodiment 2. FIG.
FIG. 3 is an explanatory diagram illustrating the architecture verification apparatus according to the second embodiment.
In the figure, a memory area 501 and a register area 502 are memory / register areas provided in common for a plurality of hardware models 200a and 200b, respectively. The access priority control 401 in the bus model 400 is equivalent to a function generally called arbitration. That is, when an access request to the bus is generated from a plurality of hardware models 200a and 200b and another access request is generated before the processing of a specific access request is completed, the access request generated later is in a waiting state. It becomes. Therefore, when there are a plurality of waiting access requests, this access priority control 401 is a control that determines which access request in the waiting state is processed with priority. This control is for determining the processing order of waiting access requests, and does not consider the time (timing) for processing the access requests.

  The timing generation descriptions 402a and 402b of the bus model 400 are timing generation descriptions corresponding to the timing generation descriptions 213 of the hardware models 200a and 200b, and basically have functions similar to those of the timing generation descriptions 213. It is. In FIG. 3, the CPU 100, main memory model 300, and algorithm verification C program 1 shown in FIG. 2 are not shown.

  In the architecture verification apparatus configured as described above, the hardware models 200a and 200b do not transfer data to the bus model 400 in the simulation for the data transfer operation between the hardware via the bus, and the hardware models 200a and 200b have a common memory. By transferring data to the / register areas 501 and 502, simulation time can be shortened.

  For example, when the hardware model 200b reads the register value of the hardware model 200a. If a simulation according to the actual hardware operation is executed, the register value of the hardware model 200a is once transferred to the bus model 400, and then the register value in the bus model 400 is read by the hardware model 200b. become.

  On the other hand, as shown in FIG. 3, if each hardware model 200a, 200b has a common register area 502 and can read and write to this register area 502, in the above example, the hardware model 200b has a common register area. It is only necessary to read from 502. According to the present embodiment, data transfer between the hardware models 200a and 200b only needs to be read and written to the common memory area 501, and it is not necessary to simulate the actual data flow via the bus.

  By the way, in this embodiment, since no data flows on the bus, if the data transfer processing time of the bus is ignored, a large error occurs in the processing time of the entire hardware, and the degree of congestion of the bus is also evaluated. become unable. Therefore, in the bus model 400, only processing of access timing from the hardware models 200a and 200b to the bus is performed. This synchronizes the timing between the timing generation description 213 of each hardware model 200a, 200b and the timing generation description 402a, 402b of the bus model 400 by a request / permission (req / ack) signal. In the bus model 400, the access priority control 401 controls the order of generating bus access permission signals for the timing generation descriptions 402a and 402b in the bus model 400, thereby matching the timing of the entire hardware. Is possible.

  In other words, in the second embodiment, since data is not sent to the bus, the bus model 400 does not perform an operation necessary for data transfer processing actually performed by hardware. For this reason, in the case of data transfer that requires several or tens of cycles for data transfer in hardware, the bus model 400 performs processing in 0 cycles (this is an error in processing time). . Therefore, in the processing of access timing to the bus, a cycle necessary for data transfer processing is consumed, so that the processing cycle (processing time) is matched in the total data transfer processing of the bus.

  A data access library 600 shown in FIG. 3 indicates a function library used in the data access description 212 of the hardware models 200a and 200b. The data access library 600 reads and writes data in the memory area 501 and the register area 502 in accordance with the data amount specified by the data access description 212.

For example, in C program 1 for algorithm verification,
a = b [3];
When the data is referred to (read) as described above, the algorithm operation description 211 is a description using a read function to the memory defined by the data access description 212. Note that b [3] means the third element in the array named b (a set of variables). Assuming that the read function to the memory for the array b defined in the data access description 212 is read_mem_b (), the data reference is described as follows in the algorithm operation description.
a = read_mem_b (3);

  In the data access description 212, data of one element or a plurality of elements including b [3] is read from the memory area 501, and only the value of b [3] is returned to a. When the data processing unit is one element of b, read_mem_b () reads only b [3] from the memory area 501, and when the data processing unit is 10 elements of b, b [] including b [3] 10 elements (example: b [0] -b [9]) are read from the memory area 501. If the data processing unit is 10 elements of b (b [0] -b [9]) and read_mem_b (5) is accessed after read_mem_b (3), reading from the memory area 501 is performed. Without returning, the value of b [5] obtained when b [3] is read from the memory area 501 is returned.

  Read_mem_b () defined in the data access description 212 is read from the memory area 501 using a direct read / write function to the memory area 501 defined in the data access library 600. As described above, the data access library 600 reads / writes data from / to the memory area 501 and the register area 502 according to the data amount specified by the data access description 212. In the case of reading, the data access library 600 reads from the memory area 501. Return the data.

  As described above, according to the architecture verification device of the second embodiment, in a simulation in which a plurality of hardware models are provided with a common memory area and a register area, and a plurality of hardware models transfer data via a bus. Since the data transfer is performed using at least one of the common memory area and the register area, the simulation time can be shortened.

It is explanatory drawing which shows the architecture verification apparatus by Embodiment 1 of this invention. It is explanatory drawing in the case of mapping C program for algorithm verification with the architecture verification apparatus by Embodiment 1 of this invention. It is explanatory drawing which shows the architecture verification apparatus by Embodiment 2 of this invention.

Explanation of symbols

1 Algorithm verification C program, 200a, 200b, 200c Hardware model, 211 Algorithm operation description, 212 Data access description, 213 Timing generation description, 400 Bus model, 501 Memory area, 502 Register area

Claims (3)

In an architecture verification device that performs a simulation with a hardware model based on a description indicating the hardware operation, data processing unit, and timing,
An architecture verification apparatus characterized in that the description is divided into an algorithm operation description and a data access description. In an architecture verification device that performs a simulation with a hardware model based on a description indicating the hardware operation, data processing unit, and timing,
An architecture verification apparatus, wherein the description is divided into an algorithm operation description and a description indicating timing. A common memory area and register area are provided for multiple hardware models.
The data transfer is performed using at least one of the common memory area and the register area in a simulation in which the plurality of hardware models transfer data via a bus. Or the architecture verification apparatus of Claim 2.

Images