JP2006023852A - Method for creating software validation model - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To increase simulation accuracy by taking cache errors with a cache memory or the like into account, relating to a method for creating the software validation model required to perform the co-validation of hardware and software installed in a semiconductor device. <P>SOLUTION: A runtime insert statement whose parameter is a runtime calculated between control points of a Basic Block is added. A call for a procedure to determine whether or not an instruction cache memory has been hit is inserted and an instruction tag memory part in the instruction cache memory determines whether or not the instruction cache memory has been hit. Upon the detection of a cache error, a procedure with the function of identifying an instruction cache hit by adding the time of a cache line fill is provided. Upon the execution of a procedure for invalidating an instruction cache, an entry in the instruction tag memory part is invalidated. A software component described in a C-based language and obtained through the series of processes mentioned above is outputted as a validation model. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

The present invention uses a host CPU (Central Processing Unit) having a cache memory, and considers the operation of the cache memory while cooperating with hardware and software installed in a semiconductor device (Co-verification). The present invention relates to a software verification model generation method for generating a software verification model necessary for executing (1).
Here, the cache memory refers to a memory for storing data for the purpose of performing high-speed transfer of data frequently read and written by the host CPU between the host CPU and the main storage device (main memory). Yes.

  In recent years, devices equipped with SoC have become widespread. SoC is an abbreviation for System on a Chip, and refers to a technology that packs the main functions of a computer into a single chip (semiconductor device), or a chip in which the main functions of a computer are mounted using the technology.

  FIG. 1 is a diagram showing an upstream design flow of such SoC. As shown in the figure, after the system level design is completed, the process moves to the architecture level design. In the architecture level design, the selection of basic components such as CPU, OS (Operating System) represented by RTOS (Real-Time Operating System), bus (Bus), etc., division of functions into application hardware and software, and Hardware design and software design are performed. Then, hardware / software co-verification based on the verification model is executed on the basic components, hardware components, and software components obtained by the architecture level design.

  Here, the RTOS refers to an OS that implements various functions in real time and has a function for this purpose. Computers that control digital devices such as mobile phones and digital televisions require response time to be within a certain range, so various functions for realizing real-time performance for the above RTOS Is needed.

FIG. 2 is a data flow diagram for explaining a conventional hardware / software co-verification method, and FIG. 3 is a schematic diagram for explaining a state of adding timing budget processing by the conventional hardware / software co-verification method. It is.
In general, in order to realize high-performance co-simulation with hardware and software mounted on a semiconductor device, it is necessary to create a verification model by modeling basic components, hardware components, and software components. .

  As shown in FIG. 2, the software component RTOS is usually written in ANSI-C and assembly language. Based on the RTOS source code described in ANSI-C and assembly language, modeling for executing task control and data access control and modeling for executing task switching are performed manually and executed. A verification model (that is, a C base model) described in the C base language before the time is added is created. Thereafter, a timing budget is added to the verification model before the execution time is added, and a verification model (that is, a C base model) described in the C base language after the execution time is added is generated. In this specification, the “C base language” means any one of ANSI-C / C ++ extended languages, SpecC, and SystemC.

  On the other hand, software / application software is usually written in ANSI-C. However, in the interrupt handler and device driver in the application software, their design logic may include a description in assembly language in addition to the description in ANSI-C. Model for executing task control and data access control and task switching based on the ANSI-C alone or the source code of application software written in ANSI-C and assembly language The verification model (ie, the C base model) described in the C base language before the execution time is added is created. Thereafter, a timing budget is added to the verification model before the execution time is added, and a verification model (that is, a C base model) described in the C base language after the execution time is added is generated.

  On the other hand, for hardware parts, a verification model (ie, a C base model) written in a C base language is created. This C-based model is a verification model based on a behavior description or an RTL (Register Transfer Level) description. The behavioral description describes the behavior of the circuit, while the RTL description describes how the register values transition.

  Furthermore, a method for creating a hardware component verification model will be described. For basic components, the CPU and CPU-specific verification model are not created, and the IRS (Interrupt Routine Scheduler), which makes the interrupt processing unit independent in the ISS (Instruction Set Simulator), newly introduced as part of the RTOS verification model Is done. This IRS is written in a C-based language. A bus verification model is newly created in a C-based language.

  Also, behavior description hardware components logically designed using C-based language are automatically converted from C-based language description to Fixed I / O Behavior model by using the extension function of behavioral synthesis tool. The verification model (C base model) is generated by the conversion. This Fixed I / O Behavior model is equivalent to the hardware model using Basic Block.

  Also, RTL (Register Transfer Level) description hardware parts logically designed using Verilog / VHDL are converted from RTL description to RTL-C base language model using HDL Import (CoWare tool). The verification model (C-based model) is generated by automatically converting the RTL-C-based language model in which one state of FSM (Finite State Machine) is one clock. It represents an action.

  The conventional hardware as shown in FIG. 2 is added to the verification model (basic parts, hardware parts, and software parts) composed of the C base model as described above by adding a C base simulator that controls the operation of the entire simulation. / A collaborative verification system (software configuration) for executing the software collaborative verification method is configured.

  In the budget addition unit (also referred to as a budget addition tool) in FIG. 2, when generating a verification model of a software component, a source code part (C code) only from the ANSI-C description from the C base model before the execution time is added. The timing budget (Timing Budget) addition process as shown in FIG. 3 is performed. This timing budget addition processing is performed in the following order (for example, Japanese Patent Application No. 2003-024706 (filed on January 31, 2003) in the prior art document (Patent Document 1 described later)). reference).

  First, the control point is inserted by recognizing the basic block and inserting the control point for the part of the C code extracted from the C base model before the execution time is added. Output C code. This Basic Block indicates a portion where RTOS and application software programs run sequentially without branching. Then, control points are inserted before and after the recognized basic block.

  More specifically, for the C code portion shown in FIG. 3A, node a and node b are recognized as one basic block, and node c, node d and node e are one basic block. Node c and node f are recognized as one basic block, and node g is recognized as one basic block. Therefore, as shown in FIG. 3B, control is performed between the node b and the node c, between the node e and the node g, between the node f and the node g, and after the node g, respectively. A point is inserted.

  Secondly, the target CPU binary code is generated by compiling the C code portion in which the control points are inserted. In this specification, the “target CPU” means a CPU (for example, an ARM processor or an SH processor) mounted on a semiconductor device such as an SoC to be verified.

Third, as a result of the above-described compilation, the execution time between the control points is calculated based on the generated target CPU binary code (instruction code). The calculation is
kΣ [number of cycles for each instruction]
It is performed based on the following arithmetic expression. Here, the coefficient k is an overhead coefficient caused by a cache memory miss (also called a cache miss: that there is no desired data in the cache memory). Here, since a model relating to the cache memory is not provided, the overhead coefficient as described above is introduced in order to enable correction of execution time by statistical processing.

  Fourthly, an execution time insertion statement (in the case of SpecC, a waitfor statement) having a timing budget as a parameter to each control point of the C code portion in which the control point is inserted is used as a parameter. It is added and output as a verification model of the C base language description (C base model after execution time is added). In the above-mentioned prior art documents, the C base model before the execution time is added is referred to as “Untimed software component”, and the C base model after the execution time is added by adding the budget process is referred to as “Timed software component”. ing.

  For example, the execution times of the nodes a and b shown in FIG. 3B are calculated as t1, the execution times of the nodes c, d and e are calculated as t2, and the execution times of the nodes c and f are calculated. Is calculated as t3, and the execution time of the node g is calculated as t4. In this case, as shown in FIG. 3C, waitfor (t1) is added as an execution time insertion statement to the control point between the nodes b and c. Similarly, waitfor (t2) is added as an execution time insertion statement to the control point between node e and node g, and waitfor (t3) is added as an execution time insertion statement to the control point between node f and node g. ) Is added, and waitfor (t4) is added as an execution time insertion statement to the control point after node g.

  FIG. 4 is a schematic diagram for explaining the C-based simulation based on the verification model of the C-based language description created in this way. By compiling the verification model of the C base language description and generating the binary code for the host CPU, it becomes possible to perform C base simulation using the C base simulator in the host CPU. Here, the “host CPU” means a CPU (for example, a Pentium (registered trademark) processor) mounted on a personal computer (PC) or a work station (WS) that executes cooperative verification.

  In other words, when a software component verification model is generated by adding a budget process as shown in FIGS. 3 and 4, the control block is inserted by recognizing the basic block of the C code portion, and between each control point. The host CPU binary code generated by compiling the verification model of the C-based language description obtained by adding the execution time insertion statement with the execution time of the above as a parameter is executed on the host CPU. In such a software verification model generation method, compared with a simulation using a conventional ISS (Instruction Set Simulator) that executes a simulation by interpreting the content of each instruction code, the simulation performance ( The number of instructions / second) is improved by about 100 to 1000 times, and the simulation speed in hardware / software co-verification can be increased.

  On the other hand, when a waitfor statement appears in the simulation process, the simulator interprets the content of the waitfor statement so that the instruction execution time can be managed, so that the simulation accuracy of timing can be maintained to some extent. That is, after execution of the instruction code corresponding to the node b, the accumulated processing time T1 = t1 is obtained by interpreting the instruction code of waitfor (t1). Similarly, the accumulated processing time T2 = t1 + t2 is obtained after execution of the instruction code corresponding to the node e, while the accumulated processing time T2 = t1 + t3 is obtained after execution of the instruction code corresponding to the node f.

  Then, after execution of the instruction code corresponding to the node g, if the program runs along the route of the node c, the node d and the node e, the accumulated processing time T3 = t1 + t2 + t4 is obtained, while the program is obtained by the node c and the node f. In the case of traveling on the route, the accumulated processing time T3 = t1 + t3 + t4 is obtained.

  Furthermore, in Japanese Patent Application No. 2004-107207 (filed on March 31, 2004) of another prior art document (Patent Document 2), execution between each control point inserted in the Basic Block of the C code portion A timefor is calculated and a waitfor statement with the integrated value as a parameter is added to the software component only when the integrated value obtained by integrating the execution time is determined to be greater than or equal to the specified value. . By such a method, the frequency of adding a waitfor statement is reduced as compared with the case of Patent Document 1, and the simulation execution speed is faster than that of Patent Document 1, and the simulation performance is improved. In this case, when it is determined that the integrated value is greater than or equal to the specified value, a waitfor statement using the integrated value as a parameter is added, and the C-based simulator interprets the waitfor statement and manages the instruction execution time. Therefore, compared with the case of patent document 1, simulation accuracy does not fall so much.

Here, for reference, in addition to Patent Document 1 related to FIGS. 2 to 4 and Patent Document 2 in which a method of partially modifying the software verification model generation method of Patent Document 1 is described, conventional hardware / Some prior art documents related to software co-verification methods are listed.
In addition to the following Patent Documents 3 to 5, the following Non-Patent Documents 1 and 2 exist as prior art documents related to cooperative verification using ISS. The following Non-Patent Document 3 relates to the above-mentioned “Basic Block”, and Non-Patent Documents 4 to 6 relate to the “Fixed I / O Behavior Model” described above, and Non-Patent Documents 7 to 9. Relates to technical trends in the design and verification of C-based languages.

Japanese Patent Application No. 2003-024706 (filed on January 31, 2003) Japanese Patent Application No. 2004-107207 (filed on March 31, 2004) Japanese Unexamined Patent Publication No. 2000-259445 Japanese Patent Laid-Open No. 2001-256072 JP 2002-175344 JP Kazutoshi Wakabayashi: LSI design using C language-behavioral synthesis and HW / SW collaborative verification, NE Embedded Symposium 2002. Kurokawa, Ikegami, Otsubo, Asao, Kirigaya, Mitsumata, Takahashi, Kawazu, Nitta, Kasa, Wakabayashi, Tomobe, Takahashi, Mukaiyama, Takenaka: Effects analysis and discussion of system LSI design methods using C-based behavioral synthesis, IEICE 15th Karuizawa Workshop, pp. 131-142, Apr. 2002. Alfred Aho, Ravi Sethi and Jeffrey Ullman, “Compilers: Principals, Techniques and Tools”, Addison-Wesley, 1986. D. W. Knapp, T. Ly, D. MacMillen and R. Miller, “Behavioral Synthesis Methodology for HDL-Based Specification and Validation”, Proc. Design Automation Conf., June 1995. T. Ly, D. W. Knapp, R. Miller and D. MacMillen, “Scheduling using Behavioral Templates”, Proc. Design Automation Conf., June 1995. D. W. Knapp, “Behavioral Synthesis: Digital System Design using the Synopsys Behavioral Compiler”, Prentice Hall PTR. L. Gauthier, S. Yoo and A. A. Jerraya, “Automatic Generation and Targeting of Application Specific Operating Systems and Embedded Systems Software”, Proc. Design Automation and Test in Europe, Mar. 2001. D. Lyonnard, S. Yoo, A. Baghdadi and A. A. Jerraya, “Automatic Generation of Application-Specific Architectures for Heterogeneous Multiprocessor System-on-Chip”, Proc. Design Automation Conf., June 2001. S. Yoo, G. Nicolescu, L. Gauthier and A. A. Jerraya, “Automatic Generation of Fast Timed Simulation Models for Operating Systems in SoC”, Proc. Design Automation and Test in Europe, Mar. 2002.

  In general, in an embedded system using a target CPU such as an ARM processor or an SH processor, a cache memory is provided on the host CPU side in order to speed up access to instruction codes and data with a main storage device (main memory). There are many. This cache memory is normally used by being built in the target CPU.

  However, in the conventional hardware / software co-verification method as described in the above-mentioned Patent Document 1 or Patent Document 2, etc., based on the verification model generated by the target CPU, the C-base is used using the host CPU. When calculating the execution time when the simulation is executed, only the statistical processing of the cache memory operation is performed, and detailed operations due to cache misses of the cache memory are not considered. For this reason, when the execution time of the target CPU with the built-in cache memory is estimated, particularly when cache misses of the cache memory frequently occur, the accuracy of the estimation of the execution time is lowered and the simulation accuracy is lowered. The problem has arisen.

  The present invention has been made in view of the above-described problems. When calculating an execution time when a C-based simulation is executed based on a verification model generated by a target CPU, a cache miss of a cache memory, etc. It is an object of the present invention to provide a software verification model generation method that makes it possible to improve simulation accuracy over conventional methods by considering the above.

  In order to achieve the above object, according to the first aspect of the present invention, hardware of a semiconductor device on which at least one target CPU and one OS are mounted using a host CPU having an instruction cache memory, and When generating a software verification model to perform software collaborative verification, input software parts of C-base language description, extract source code part by ANSI-C description, recognize Basic Block, and control A step of inserting a point, a step of generating a source CPU binary code by compiling a portion of the source code according to the ANSI-C description in which the control point is inserted, and the Basic Block A step of calculating an execution time between the control points and the execution time as a parameter A step for adding a line time insertion statement to the control point after the Basic Block and a procedure call for determining whether or not the instruction cache memory is hit in the Basic Block unit are called after the Basic Block. Inserted into the control point of the instruction, the assembler code for invalidating the instruction cache memory is converted into the source code in the ANSI-C description for calling the instruction cache invalidation procedure, and held in the instruction cache memory To determine whether or not the instruction cache memory is hit by using the instruction tag memory portion that has been executed, and to execute a cache line fill when it is detected that the instruction cache memory is not hit Providing a procedure having an instruction cache hit determination function for adding the execution time of When the instruction cache invalidation procedure is executed, the step of invalidating the entry in the instruction tag memory unit and the C-based language description software component obtained in the series of steps are output as the verification model. A method for generating a software verification model is provided. Here, the cache line indicates a unit for replacing the contents of the cache memory, and is normally set to a fixed length of about 32 bytes or 64 bytes. A cache line fill refers to an operation for loading data into an instruction cache line (or data cache line).

  Preferably, in the software verification model generation method according to the first aspect of the present invention, when an instruction address conversion buffer for converting an instruction address from a virtual address to a physical address is provided in the target CPU, It is determined whether or not the instruction address exists in the instruction address conversion buffer in units of the Basic Block, and when it is detected that the instruction address does not exist in the instruction address conversion buffer, The method further includes the step of adding a time for loading the instruction address conversion entry into the instruction address conversion buffer.

  Further preferably, the software verification model generation method according to the first aspect of the present invention checks the presence / absence of a protection function of the instruction address, and detects a violation of access protection in the instruction address conversion buffer. And a step of notifying that an exception of the instruction cache memory access protection has occurred.

  On the other hand, according to the second aspect of the present invention, hardware verification and software verification of a semiconductor device on which at least one target CPU and one OS are mounted are performed using a host CPU having a data cache memory. When generating a software verification model, the software part of the C base language description is input, the source code part by ANSI-C description is extracted, the Basic Block is recognized, and the control point is inserted. A step of generating a binary code for a target CPU by compiling a source code portion according to the ANSI-C description in which the control point is inserted, and between each control point of the Basic Block A step of calculating the execution time of the execution time, and an execution time insertion statement using the execution time as a parameter A step for adding to the control point after the Basic Block and a procedure for determining whether or not the data cache memory is hit in a portion where data access is required in the source code according to the ANSI-C description. Stored in the data cache memory, a step of inserting an assembler code for invalidating the data cache memory, a step of converting the assembler code for invalidating the data cache memory into an ANSI-C description source code for calling the data cache invalidation procedure, To determine whether or not the data cache memory is hit by using the data tag memory unit, and when it is detected that the data cache memory is not hit, the cache line fill is executed. Data cache hit judgment function that adds execution time Providing a procedure to perform, invalidating an entry in the data tag memory unit when the data cache invalidation procedure is executed, and C-based language description software obtained in the series of steps A method for generating a software verification model is provided that includes outputting a part as the verification model.

  Preferably, in the software verification model generation method according to the second aspect of the present invention, when a data address conversion buffer for converting a data address from a virtual address to a physical address is provided in the target CPU, It is determined whether or not the data address exists in the data address conversion buffer at a portion where data access is required in the source code according to the ANSI-C description, and the data address is used for the data address conversion. The method further includes a step of adding a time for loading the data address conversion entry into the data address conversion buffer when it is detected that the buffer does not exist in the buffer.

  Further preferably, the software verification model generation method according to the second aspect of the present invention checks whether or not the data address protection function is present, and if a violation of access protection in the data address conversion buffer is detected. And a step of notifying that an access protection exception of the data cache memory has occurred.

  On the other hand, according to the third aspect of the present invention, using a host CPU having an instruction cache memory and a data cache memory, hardware of a semiconductor device on which at least one target CPU and one OS are mounted, and When generating a software verification model to perform software collaborative verification, input software parts of C-base language description, extract source code part by ANSI-C description, recognize Basic Block, and control A step of inserting a point, a step of generating a source CPU binary code by compiling a portion of the source code according to the ANSI-C description in which the control point is inserted, and the Basic Block Calculating the execution time between the control points of the Add the execution time insertion statement for the basic block to the control point after the basic block, and call the procedure to determine whether the instruction cache memory is hit in the unit of the basic block. And a call to a procedure for determining whether or not the data cache memory is hit at a portion where data access is required in the source code according to the ANSI-C description. Inserting the assembler code for invalidating the instruction cache memory and the data cache memory into a source code according to ANSI-C description for calling the instruction cache invalidation procedure and the data cache memory invalidation procedure. A software verification model generation method is provided.

  Further, the software verification model generation method determines whether the instruction cache memory is hit by using the instruction tag memory unit held in the instruction cache memory, and hits the instruction cache memory. Providing a procedure having an instruction cache hit determination function for adding an execution time for executing a cache line fill when it is detected that there is not, and a data tag held in the data cache memory Uses the memory unit to determine whether the data cache memory is hit, and adds execution time to execute cache line fill when it is detected that the data cache memory is not hit Provides a procedure with a data cache hit judgment function A step of invalidating entries of the instruction tag memory unit and the data tag memory unit when the instruction cache invalidation procedure and the data cache memory invalidation procedure are executed, and the series of steps described above. And outputting the C-based language description software component obtained in step 1 as the verification model.

  Preferably, in the software verification model generation method according to the third aspect of the present invention, an instruction address conversion buffer for converting an instruction address from a virtual address to a physical address is provided in the target CPU. It is determined whether or not the instruction address exists in the instruction address conversion buffer in units of the Basic Block, and when it is detected that the instruction address does not exist in the instruction address conversion buffer, A step for adding time for loading an instruction address conversion entry into the instruction address conversion buffer and a data address conversion buffer for converting a data address from a virtual address to a physical address are provided in the target CPU. The source code according to the ANSI-C description above. When it is determined that the data address does not exist in the data address conversion buffer, it is determined whether or not the data address exists in the data address conversion buffer. And a step of adding a time for loading the data address conversion entry into the data address conversion buffer.

  Further preferably, the software verification model generation method according to the third aspect of the present invention checks whether or not the instruction address protection function is present, and if a violation of access protection of the instruction address conversion buffer is detected. The step of notifying that the instruction address conversion buffer access protection exception has occurred and the presence / absence of the data address protection function are checked, and when a violation of the data address conversion buffer access protection is detected. And a step of notifying that an exception of the access protection of the data address conversion buffer has occurred.

  In summary, in the present invention, firstly, the execution time between each control point inserted in the Basic Block of the software component of the C base language description is calculated, and at the same time, it is incorporated in the target CPU in units of Basic Block. Judge whether the instruction cache memory is hit or not, and if a cache miss (no instruction cache memory hit) is detected, source the procedure call that adds the execution time for executing the cache line fill A procedure for determining the instruction cache hit as described above is prepared by being inserted into the code and compiled together with the source code so as to execute a simulation in hardware and software collaborative verification. In this way, when the instruction cache memory is built in the target CPU, the execution time for executing the cache line fill in the case of a cache miss in the instruction cache memory is added, so that the execution time is longer than the conventional method. The accuracy of estimation is increased and the accuracy of simulation is improved.

  In this case, whether or not the instruction cache memory is hit is determined not in units of instructions but in units of Basic Blocks, so it is possible to reduce the processing load in a C-based simulator or the like that controls the operation of the entire simulation. become.

  Further, according to the present invention, secondly, when an instruction address conversion buffer (for example, TLB (Translation Look-aside Buffer)) is provided in the target CPU, the instruction address conversion is performed. When a buffer buffer error (instruction address does not exist in the instruction address conversion buffer) is detected, the time for loading the instruction address conversion entry into the instruction address conversion buffer is added. Therefore, it is possible to execute a high-precision simulation including a time for loading an instruction address conversion entry when an instruction address conversion buffer is missed.

  Further, according to the present invention, thirdly, when a violation of the access protection of the instruction address conversion buffer is detected, the C base simulator or the like is notified that an access protection exception of the instruction address conversion buffer has occurred. This makes it possible to reliably detect violations of access protection of the instruction address conversion buffer during simulation.

  Furthermore, in the present invention, fourthly, the execution time between arbitrary control points inserted in the basic block of the software component of the C base language description is calculated, and at the part where data access is necessary, it is built in the target CPU. It is determined whether or not the data cache memory is hit, and if a cache miss (data cache memory is not hit) is detected, a procedure call is added that adds the execution time for executing the cache line fill. A procedure for inserting data cache hits as described above is prepared by being inserted into the source code, compiled together with the source code, and a simulation for hardware and software collaborative verification is executed. As described above, even when the data cache memory is built in the target CPU, the execution time for executing the cache line fill in the case of a cache miss of the data cache memory is added, so that the execution time is longer than the conventional method. The accuracy of the estimation is increased, and the accuracy of the simulation is improved.

  Furthermore, in the present invention, fifthly, when a data address conversion buffer (for example, TLB) is provided in the target CPU, a data address conversion buffer miss (data address is in the data address conversion buffer). The time for loading the data address conversion entry into the data address conversion buffer is added. Therefore, it is possible to execute a high-precision simulation including the time for loading the data address conversion entry when the data address conversion buffer is missed.

  Further, according to the present invention, sixthly, when a violation of access protection of the data address conversion buffer is detected, the C base simulator or the like is notified that an access protection exception of the data address conversion buffer has occurred. This makes it possible to reliably detect violations of the access protection of the data address conversion buffer during simulation.

  Further, according to the present invention, seventhly, the execution time between the control points inserted in the Basic Block of the software component of the C base language description is calculated, and the instruction cache built in the target CPU is calculated in Basic Block units. Determine whether the memory is hit, insert a procedure call that adds the execution time for executing the cache line fill when a cache miss is detected, and determine the instruction cache hit as described above Prepare the procedure to compile with the source code, and on the other hand, determine whether the data cache memory built in the target CPU is hit at the part that requires data access, and cache miss A procedure call that adds the execution time to execute the cache line fill when Insert the Sukodo, so that by providing a procedure for performing data cache hit determination as described above to compile with the source code to perform the simulation.

  As described above, even when both the instruction cache memory and the data cache memory are built in the target CPU, the cache line fill is executed in the case of a cache miss of the instruction cache memory and a cache miss of the data cache memory. By adding the execution time for this, the accuracy of the estimation of the execution time becomes higher than that of the conventional method, and the accuracy of the simulation is significantly improved.

  Further, according to the present invention, eighthly, when an instruction address conversion buffer and a data address conversion buffer are provided in the target CPU, an instruction address conversion is performed when a mistake in the instruction address conversion buffer is detected. The time to load the data address conversion buffer is added to the instruction address conversion buffer, and the time to load the data address conversion entry to the data address conversion buffer is added when a miss in the data address conversion buffer is detected. I have to. Therefore, it is possible to execute a more accurate simulation including the time to load the instruction address conversion entry and the data address conversion entry when the instruction address conversion buffer and the data address conversion buffer are missed.

  Furthermore, in the present invention, ninthly, when a violation of access protection of the instruction address conversion buffer and the data address conversion buffer is detected, an exception of access protection of the instruction address conversion buffer and the data address conversion buffer is detected. By notifying the C-base simulator or the like of the occurrence, it is possible to more reliably detect violations of the access protection of the instruction address conversion buffer and the data address conversion buffer when executing the simulation.

Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings.
FIG. 5 is a block diagram illustrating a hardware environment for implementing the software verification model generation method according to the present invention. Hereinafter, the same components as those described above are denoted by the same reference numerals.

  As illustrated in FIG. 5, a software verification model generation method (or hardware / software co-verification method) according to the present invention includes a central processing unit (described as a host CPU in FIG. 5) 912, a cache memory 916, and a main memory. A normal personal computer comprising a computer main body 910 having a device (MS) 914 (abbreviated as main memory in FIG. 5), an external storage device (HD) 930 comprising a display 920, a keyboard 922, a mouse 924, a hard disk device, etc. (PC) or work station (WS).

  Here, a high-performance host CPU 912 is required to execute the software verification model generation method according to the present invention at high speed. In order to respond to this request, a cache memory 916 is provided between the host CPU 912 and the main storage device 914. The cache memory 916 stores (writes) the data from the host CPU 912 and temporarily stores the data that the host CPU 912 frequently reads / writes to / from the main storage device 914 at a high speed, or It has a function of loading the data from the main storage device 914 and temporarily storing it (also called downloading). The cache memory 916 and the main storage device 914 are connected to each other via a bus 918. As will be described later with reference to FIG. 6, the cache memory 916 includes at least one of an instruction cache memory and a data cache memory, or both, and is built in the computer main body 910.

  The host CPU 912 operates as a host CPU that executes software verification model generation (or hardware / software co-verification), and is, for example, a Pentium processor. A program for generating a software verification model (or hardware / software co-verification) described below is executed by the host CPU 912. Various data, files, and the like are loaded from the external storage device 930 to the main storage device (MS) 914 and processed.

  FIG. 6 is a block diagram illustrating an example of connection between an instruction cache memory and a data cache memory in an embedded system using a target CPU. Here, an example of an expanded connection of an embedded system having an instruction cache memory and a data cache memory is shown.

  In FIG. 6, a cache memory 16 is an instruction cache memory 16-1 that temporarily stores the contents of instructions (also called "data" in a broad sense), or a data cache memory 16- that temporarily stores the contents of data. 2 or both. The instruction cache memory 16-1 and the data cache memory 16-2 are preferably used by being incorporated in the target CPU 12. In the configuration shown in FIG. 6, the cache memory is simply abbreviated as “cache”, the instruction cache memory is simply abbreviated as “instruction cache”, or the data cache memory is simply abbreviated as “data cache”. Sometimes.

  The hardware / software co-verification system using the target CPU 12 of FIG. 6 has a function of calculating the execution time between the control points inserted in the basic block of the software component by the budget addition tool, and An emulation function by the cache memory 16 (the instruction cache memory 16-1 and the data cache memory 16-2) is added. Here, the target CPU 12 executes an operation to fetch the contents of the instruction from the instruction cache memory 16-1 (instruction fetch operation) or loads data to the data cache memory 16-2 in executing the instruction to the cache memory. Instructions for loading and storing (load instructions / store instructions).

  More specifically, the target CPU 12 determines whether or not the instruction cache memory 16-1 is hit (whether or not desired data (instruction contents) exists in the instruction cache memory), and a cache miss ( When it is detected that there is no desired data in the instruction cache memory), the data is read from the main memory 14 and loaded into the instruction cache line of the instruction cache memory 16-1. Here, the instruction cache line represents a data load unit to the instruction cache memory 16-1. As described above, the operation of loading data into the instruction cache line is called a cache line fill. In this case, the target CPU 12 waits until the cache line fill of data for one instruction cache line is completed. The waiting time resulting from the waiting state of the target CPU 12 is referred to as “cache miss penalty”.

  On the other hand, the target CPU 12 determines whether or not the data cache memory 16-2 is hit (whether or not desired data exists in the data cache memory), and cache miss (desired in the data cache memory). Is detected), the data is read from the main memory 14 and loaded into the data cache line of the data cache memory 16-2. Here, the data cache line represents a data load unit to the data cache memory 16-2. As described above, an operation for loading data into the data cache line is referred to as a cache line fill. In this case, the target CPU 12 waits until the cache line fill of the data for one data cache line is completed. The waiting time resulting from the waiting state of the target CPU 12 is called “cache miss penalty” as in the case of the instruction cache memory described above.

  7 is a block diagram showing a specific configuration example of the instruction cache memory 16-1 or the data cache memory 16-2 in FIG. 6, and FIG. 8 shows an instruction cache memory 16-1 in FIG. FIG. 10 is a time chart for explaining how a cache miss penalty occurs due to a cache miss in the data cache memory 16-2. FIG.

  In FIG. 7, the instruction cache memory 16-1 or the data cache memory 16-2 is constituted by a set of ways including a plurality of instruction cache lines or data cache lines (hereinafter simply referred to as cache lines). Composed. In a cache line of one line, a valid bit (Valid Bit) indicating whether or not the contents of the cache line are valid and data loaded into the cache line from the main storage device first are rewritten by the CPU. A dirty bit (Dirty Bit) indicating whether or not the data in the cache line belongs to and a tag portion (in FIG. (Abbreviated as (Tag)). Normally, the valid bit, dirty bit, and tag portion are stored in a tag memory 16-3 composed of a plurality of ways as shown in the figure. However, in the instruction cache memory 16-1, once loaded data is not rewritten by the CPU, the dirty bit is actually unnecessary. On the other hand, addresses (instruction addresses or data addresses corresponding to the instruction cache memory 16-1 or the data cache memory 16-2, respectively) 31 are provided corresponding to the respective cache lines. . The address 31 includes a tag (Tag) indicating which address the corresponding cache line belongs to, an index (Index) indicating the index value of the cache line, and an offset value from the position of the start address of the cache line. Inline offset (Inline Offset) is included.

  The cache line memory 16-4 shown in FIG. 7 is a memory for storing the contents of the cache line loaded from the main memory, and each cache line has a one-to-one correspondence with the valid bit and tag portion of the tag memory 16-3. ing. In this collaborative verification environment, when a cache miss is detected during the simulation, it is only necessary to obtain the execution time required for the cache line fill, so in practice, the simulation model of the cache line memory 16-4 is unnecessary. .

  In the tag memory 16-3 of FIG. 7, a comparator 32 is provided for each way of the tag memory 16-3. The comparator 32 has a function of comparing the tag 31 included in the address with the tag read from the tag memory 16-3 and determining whether or not there is an address that matches the specific address.

  Further, in FIG. 7, a cache hit detection unit 34 for determining whether or not the cache memory is hit for each cache line is provided. The cache hit detection unit 34 has a function of determining whether or not desired data exists in the cache memory for each cache line based on the determination result by the comparator 32 using the address of the cache line as a parameter.

  If the cache hit detection unit 34 detects a cache miss in the instruction cache memory 16-1 or the data cache memory 16-2 (the desired data does not exist in the cache memory), the cache line fill of the cache line is detected. Execution time (CPU waiting time due to occurrence of cache miss penalty) is added. As shown in FIG. 7, the execution time for executing the cache line fill of the cache line may be referred to as “line fill time”.

  FIG. 8 shows how the cache line fill is executed when such a cache miss penalty occurs (data transfer to the cache line with respect to time (t)). In a software verification model generated by a target CPU such as an ARM processor, when a cache miss in the instruction cache memory 16-1 or the data cache memory 16-3 is detected, the software verification model is synchronized with the clock CLK that is the basis of the system operation. The cache line fill executed in this way is started from the start address of the cache line. Depending on the implementation of the instruction cache memory 16-1, when the contents of the instruction corresponding to the address where a cache miss is detected are loaded, the loading to the cache line and the instruction execution by the CPU are performed in parallel. There are also things. In this case, the apparent cache line fill execution time is reduced.

Therefore, the cache miss penalty of the instruction cache memory is expressed by the following equation.
Tinit + Tword * Line Size-Texe
Here, Tinit is the time from when a cache miss is detected until the start of loading of the first head word, Tword is the load time for each word, Line Size is the number of words in one cache line, Texe Indicates an instruction time executed by the CPU during the cache line fill operation among instruction cache lines in which a cache miss is detected. For example, when the line size is 8 words (= 32 bytes) and the word width to be loaded at one time is 4 bytes, instructions in units of words (first word, next word,...) Are successively cache line memory 16. Will be loaded 8 times.

  In other words, in the embodiment of the present invention, as shown in FIG. 7, an instruction tag memory emulation function of the instruction cache memory is prepared, and it is determined whether or not the instruction cache memory is hit with the instruction address as a parameter. The execution time for executing the cache line fill in the case of a cache miss in the instruction cache memory is added as a cache miss penalty.

  On the other hand, in the embodiment of the present invention, a data cache memory emulation function is prepared, and it is determined whether or not the data cache memory is hit by using the data address as a parameter. The execution time for executing the cache line fill is added as a cache miss penalty.

Note that the cache line fill operation when a cache miss in the data cache memory occurs is executed in either the store-through mode or the store-back mode. Should.
Here, the “store-through mode” is to update the contents of the data cache memory 16-2 and the contents of the main storage device at the same time when the store (write) operation to the data cache memory 16-2 is performed. Refers to the mode. In this store-through mode, the bus 18 is used every time the contents of the data cache memory 16-2 and the main storage device 14 are updated, so that the target CPU 12 waits until the store operation for the main storage device 14 is completed. . Therefore, in the store-through mode, it is necessary to wait for the execution of the target CPU for the execution time for writing to the main storage device 14 every time the store operation is performed. Depending on the implementation of the data cache memory 16-2, a store buffer for temporarily storing a request for such a store operation may be prepared. In such a case, when performing a store operation, it is necessary to wait for execution of the target CPU 12 only when a store request still remains in the store buffer. In this case, when the cache line fill is executed, the main storage device 14 has already been updated. Therefore, an appropriate cache line is selected from the way indicated by the index of the address 31, and the main storage device is assigned to this cache line. Since it is only necessary to load the contents of the line loaded from 14, the cache miss penalty of the data cache memory is expressed by the above formula.

  On the other hand, “store / back mode” means that when the store operation is performed on the data cache memory 16-2, only the contents of the data cache memory 16-2 are updated and the contents of the main storage device remain unchanged. It points to the mode to keep. In this store-back mode, the dirty bit is set to “1” when a store operation is performed on the data cache line. Next, when a data cache line in which the dirty bit is “1” is replaced due to the occurrence of a data cache miss, it is necessary to first purge the contents of the updated data cache line to the main storage device. Thereafter, the data cache line is replaced by loading the updated contents of the data cache line that has missed the cache (store-back operation). As described above, in the store-back mode that requires data cache line replacement, the store-back operation as described above is executed in addition to the execution time when the cache line fill is executed in the store-through mode. Execution time is added. If a store buffer that holds a store / back request for the data cache line is implemented, the contents of the data cache line to be evicted are stored in the store buffer, and then the contents of the data cache line that has been cache missed are immediately stored. It can be loaded from the storage device 14. In such a case, it is only necessary to add an execution time when the cache line fill is executed. Also in this case, when the previous store back request still remains in the store buffer, the process waits until the store buffer becomes empty.

  FIG. 9 is a first part of a flowchart for explaining a processing procedure of a program for executing a procedure having an instruction cache hit determination function according to the present invention, and FIG. 10 shows a procedure having an instruction cache hit determination function according to the present invention. Part 2 of the flowchart for explaining the processing procedure of the program to be executed, and FIG. 11 are schematic diagrams for explaining the software verification model generation method by adding a procedure having an instruction cache hit determination function according to the present invention. is there.

  Hereinafter, referring to FIGS. 9 to 11, when the instruction cache memory 16-1 is built in the target CPU 12, the instruction cache hit determination function according to the present invention is performed based on the software component 50 of the C base language description. A processing procedure of a program that executes a procedure having the above will be described.

  First, in step 105 of FIG. 9, the software component 50 described in the C base language before the execution time is added is input, and the source code portion (the C code portion) only by the ANSI-C description is input from this software component. Take out). Next, in step 110, the C code portion (ANSI-C description) 52 in which the control point is inserted by recognizing the Basic Block (basic block) for this C code portion and inserting the control point. Is output. This Basic Block refers to the part where the program runs sequentially without branching. Then, control points are inserted before and after the recognized basic block.

  More specifically, for the C code portion shown in FIG. 11A, node a and node b are recognized as one Basic Block, and node c, node d and node e are one Basic Block. Node c and node f are recognized as one basic block, and node g is recognized as one basic block. Therefore, as shown in FIG. 11B, control is performed between the node b and the node c, between the node e and the node g, between the node f and the node g, and after the node g, respectively. A point (a portion marked with ● in FIG. 11B) is inserted.

  Further, in step 120, the target CPU binary code 54 is generated by compiling the portion of the C code in which such control points are inserted.

  In step 130, Basic Blocks are sequentially extracted from the C code portion 52. In step 135, it is determined whether there is a basic block to be extracted. If it is determined that there is a Basic Block to be extracted, the control point of the Basic Block extracted in Step 130 based on the target CPU binary code (instruction code) 54 generated as a result of the above-described compilation in Step 140. Calculate the execution time between. On the other hand, if it is determined that there is no Basic Block to be extracted, the software component of the C base language description obtained in steps 105 to 135 described above is output as the verification model 56, and the processing of this program is terminated.

The calculation of the execution time between the control points of the Basic Block in the above step 140 is as follows:
Σ [number of cycles for each instruction]
It is performed based on the following arithmetic expression.

  Further, in step 145, an execution time insertion statement (with the calculated execution time as a parameter) is sent to each control point of the portion of the C code where the control point is inserted (that is, the control point after each Basic Block). In the case of SpecC, it is a waitfor statement), and is output as a C-based language description verification model (C-based model after the execution time insertion statement is added) 56.

  For example, based on the relationship between basic block recognition and control point insertion in FIG. 11B, the execution times of the nodes a and b shown in FIG. 11B are calculated as t1, and the node c , The execution time of node d and node e is calculated as t2, the execution time of node c and node f is calculated as t3, and the execution time of node g is calculated as t4. In this case, as shown in the verification model of the C base language description in FIG. 11C, waitfor (t1) is added as an execution time insertion statement to the control point between the nodes b and c. Is done. Similarly, waitfor (t2) is added as an execution time insertion statement to the control point between node e and node g, and waitfor (t3) is added as an execution time insertion statement to the control point between node f and node g. ) Is added, and waitfor (t4) is added as an execution time insertion statement to the control point after node g.

  Further, in step 150 of FIG. 10, in order to determine whether or not the instruction cache memory is hit in units of Basic Block extracted in step 130 of FIG. 9 (instruction cache hit determination: instruction cache memory miss determination). Insert a call to the procedure. Further, in step 155 of FIG. 10, an assembler code for invalidating the instruction cache memory when a cache miss in the instruction cache memory is detected is called an instruction cache invalidation procedure for invalidating the instruction cache memory. Is converted into source code (that is, C code) based only on the ANSI-C description.

  Further, in step 160 of FIG. 10, it is determined whether or not the instruction cache memory is hit according to the procedure inserted in step 150 described above, and a procedure having an instruction cache hit determination function is given. In this instruction cache hit determination function, when it is determined whether or not the instruction cache memory is hit using the instruction tag memory portion held in the instruction cache memory, a cache miss of the instruction cache memory is determined. Is detected, the execution time for executing the cache line fill is added as a cache miss penalty.

  Further, in step 165 of FIG. 10, when the instruction cache invalidation procedure called in step 155 described above is executed, the entry in the instruction tag memory portion held in the instruction cache memory is invalidated. The CPU is kept waiting for the required execution time, and the contents of the valid bit of the instruction cache memory are cleared.

  Through the series of steps 105 to 165 described above, an execution time insertion statement is added to the control point after each Basic Block for the software component in the C base language description, and instruction cache hit determination is performed in units of Basic Block. When a cache miss is detected, a cache miss penalty is added. Finally, the software component of the C base language description obtained in the series of steps is output as the verification model 56 of the C base language description.

  For example, as shown in the verification model of the C base language description in FIG. 11C, the C code portion is compiled into the instruction of the target CPU, and the basic block start address Ai (i is an arbitrary positive integer: Here, i = 1 to 4) and the basic block length Li are calculated, and the execution time insertion statements (waitfor (t1) to waitfor (t4)) already inserted at the control point after each Basic Block are calculated. Immediately after that, an instruction cache hit determination call statement (fetch_icache (Ai, Li): i = 1 to 4 in this case) for determining an instruction cache hit for instruction fetch is inserted. In this case, if a cache miss (the instruction content corresponding to the instruction address does not exist in the instruction cache memory) is detected as a result of the instruction cache hit determination, the cache line fill execution time (line fill time) ) Is called as an execution time insertion statement (waitfor statement).

FIG. 12 is a schematic diagram for explaining C-based simulation based on the verification model of the C-based language description generated in FIG.
By compiling the verification model of the C base language description and generating the binary code for the host CPU, it becomes possible to perform C base simulation using the C base simulator in the host CPU. Here, as described above, the “host CPU” means a CPU mounted on a personal computer (PC) or a work station (WS) that executes cooperative verification.

  In the left part of FIG. 12, an execution time insertion statement (waitfor (t1) to waitfor (t4)) is inserted at the control point of the Basic Block of the software component of the C base language description and the instruction cache hit determination call statement (fetch_icache) (Ai, Li): Here, a verification model of a C-based language description is created by inserting i = 1 to 4).

  On the other hand, in the right part of FIG. 12, the execution time between each control point is calculated based on the execution time insertion statement inserted at the control point of the Basic Block, and inserted in the unit of Basic Block. Based on the instruction cache hit determination call statement, an execution time (line fill time) for executing the cache line fill is added when a cache miss in the instruction cache memory is detected.

  In other words, when the instruction cache memory is built in the target CPU, an execution time insertion statement (waitfor (t1) to waitfor (t4)) and an instruction cache hit determination call statement (shown in FIG. 11 and FIG. 12) When generating a software component verification model based on fetch_icache (Ai, Li)), an execution time insertion statement with the execution time between each control point of the Basic Block in the C code part as a parameter is added. Compile a verification model of C base language description obtained by adding an instruction cache hit judgment call statement in Basic Block units. By executing the host CPU binary code generated by this compilation on the host CPU, it is possible to execute a C-based simulation using a C-based simulator.

  When the simulation is executed based on the execution time insertion statement inserted at the control point of the Basic Block and the instruction cache hit determination call statement using the C-based simulator of FIG. 12, the accuracy of the estimation of the instruction execution time by the simulation is It becomes higher than the conventional method, and the time management of the instruction execution time can be performed more accurately.

  More specifically, in the instruction cache hit determination call statement (fetch_icache (Ai, Li): i = 1 to 4 in FIG. 12), instructions corresponding to instruction addresses in the range of addresses Ai to Ai + Li−1. Is determined in the instruction cache memory, and a cache miss is detected if a cache miss (the instruction corresponding to the instruction address does not exist in the instruction cache memory) is detected. The number of cycles of the cache line fill execution time (line fill time) is inserted as many times as the number of occurrences. Here, an execution time insertion statement (waitfor statement) with the line fill time as a parameter is called.

  On the other hand, in the simulation process, after executing the instruction codes corresponding to the nodes a and b, the execution time t1 is obtained by interpreting the instruction code of waitfor (t1), and the simulation time is advanced by the time t1. be able to. Further, by interpreting fetch_icache (A1, L1), when an instruction cache memory cache miss is detected in the range of addresses A1 to A1 + L1-1, the cache line fill execution time (the number of cache miss occurrences) Line fill time) can be inserted.

  Similarly, after executing the instruction code corresponding to node e from node c, the execution time t2 is obtained by interpreting the instruction code of waitfor (t2), and the simulation time can be advanced by time t2. Further, by interpreting fetch_icache (A2, L2), when an instruction cache memory cache miss is detected in the range of addresses A2 to A2 + L2-1, the line fill time is inserted as many times as the cache miss occurs. Can do.

  Similarly, after executing the instruction codes corresponding to the nodes c and f, the execution time t3 is obtained by interpreting the instruction code of waitfor (t3), and the simulation time can be advanced by the time t3. Further, by interpreting fetch_icache (A3, L3), when an instruction cache memory cache miss is detected in the range of addresses A3 to A3 + L3-1, the line fill time is inserted as many times as the cache miss occurs. Can do.

  Similarly, after executing the instruction code corresponding to the node g, the execution time t4 is obtained by interpreting the instruction code of waitfor (t4), and the simulation time can be advanced by the time t4. Further, by interpreting fetch_icache (A4, L4), when an instruction cache memory cache miss is detected in the range of addresses A4 to A4 + L4-1, the line fill time is inserted as many times as the cache miss occurs. Can do.

  Generally speaking, the probability that an instruction cache memory cache miss is detected when an instruction cache hit determination is performed by an instruction cache hit determination call statement (fetch_icache (Ai, Li)) is only a few percent. Only when a cache miss in the instruction cache memory is detected, an execution time insertion statement (waitfor statement) using the cache line fill execution time (line fill time) as a parameter is called. Therefore, even when an instruction cache hit determination call statement (fetch_icache (Ai, Li)) is additionally inserted in the unit of Basic Block, it is possible to maintain a simulation execution speed almost equal to that of the conventional method.

  Preferably, an instruction address conversion buffer (for example, a TLB (translation lookaside buffer)) for converting an instruction address of the instruction cache memory from a virtual address to a physical address is provided in the target CPU. In the instruction cache hit determination call statement (fetch_icache (Ai, Li)), a memory management unit function is added.

  In this memory management unit function, it is determined whether or not an instruction address exists in the instruction address conversion buffer in units of Basic Block, and it is detected that the instruction address does not exist in the instruction address conversion buffer. At this time, the time for loading the instruction address conversion entry into the instruction address conversion buffer is added. Such a memory management unit function makes it possible to execute a high-precision simulation including the time to load an instruction address conversion entry when a command address conversion buffer is missed.

  More specifically, in order to enable the addition of the memory management unit function described above, a TLB holding the contents of the instruction address conversion buffer is prepared in advance, and a page table holding the contents of the virtual memory mapping information is prepared. Prepare in advance in the main memory.

  Based on the instruction cache hit determination call statement (fetch_icache (Ai, Li)), whether or not the content of the instruction corresponding to the instruction address in the range from the address Ai to Ai + Li−1 exists in the instruction address conversion buffer. Judgment is made. As a result of this determination, if a cache miss in the instruction address conversion buffer is detected (the instruction content corresponding to the instruction address does not exist in the instruction address conversion buffer), the instruction address conversion buffer entry The contents are updated to the values loaded from the page table in the main memory, and the number of cycles for loading the instruction address conversion buffer is inserted. Here, an execution time insertion statement (waitfor statement) is called with the time to load into the instruction address conversion buffer as a parameter.

  Further, preferably, when executing the memory management unit function, the presence / absence of the instruction address protection function is checked. Here, when a violation of access protection is detected in the instruction address conversion buffer, it is informed that an access protection exception has occurred. This makes it possible to reliably detect violations of access protection in the instruction address conversion buffer during simulation.

  FIG. 13 is a diagram showing an example in which a procedure call related to instruction cache hit determination according to the present invention is inserted into C source code. However, the example of FIG. 13 is different from the example of the C code portion described with reference to FIGS. 11 and 12.

  In the upper left part of FIG. 13, the C source code part by ANSI-C description is illustrated. By analyzing this C source code portion, as shown in Patent Document 1 or Patent Document 2, an execution time insertion statement (for example, the lower left in FIG. 13) is added to the control point after each Basic Block by a budget addition tool. Insert a waitfor statement such as waitfor (2), waitfor (4), and waitfor (5) as shown in the section. That is, the C source code portion at the upper left of FIG. 13 is cross-compiled so as to be expanded into an assembler output by the assembly language description of the target CPU as shown on the right side of FIG. By analyzing the branch destination and branch instruction occurrence location in the assembler output, it is surrounded by a basic block (for example, a plurality of blocks (each block has a capacity of 8 bytes to 20 bytes) on the right side of FIG. 13). Can be recognized. The basic block of this assembler output is collated with the C source code, and the C source code is generated by inserting an execution time insertion statement (waitfor statement) at the control point at the end of each Basic Block of the C source code. To do.

  In this patent, an instruction cache hit determination procedure call statement (fetch_icache call statement) is additionally inserted into this control point together with an execution time insertion statement (waitfor statement).

  That is, the assembler output on the right side of FIG. 13 is analyzed and collated with the C source code, and at the control point after each Basic Block of the C source code, the execution time insertion statement (waitfor statement) and the instruction cache After additionally inserting the call statement (fetch_icache call statement) of the hit determination procedure, it is converted into the C source code portion (that is, the C code portion) by the updated C language description as shown in the lower left portion of FIG. To do. The updated C code portion has a format in which an instruction cache hit determination call statement (fetch_icache call statement) is additionally inserted at a control point after each Basic Block by a budget addition tool. More precisely, the lower left part of FIG. 13 shows a verification model of a C-based language description that is finally output by compiling the updated C code part.

  More specifically, in the verification model of the C-based language description in FIG. 13, the execution time insertion statements (waitfor (2), waitfor (4), and waitfor () inserted at the control point after each Basic Block. Immediately after 5)), an instruction cache hit determination call statement (fetch_icache (stringcpy + 8, 20), fetch_icache (stringcpy + 28, 16), fetch_icache (stringcpy + 28, 16), Insert fetch_icache (stringcpy + 44, 8) and fetch_icache (stringcpy + 52, 8)). Here, the two parameters of the fetch_icache call are the start address of Basic Bclock and its length (number of bytes). When a cache miss is detected as a result of calling the instruction cache hit determination procedure for each Basic Block, an execution time insertion statement with the cache line fill execution time (line fill time) as a parameter in the Basic Block A call is made.

  FIG. 14 is a flowchart for explaining a processing procedure of a program for executing a procedure having a data cache hit determination function according to the present invention, and FIG. 15 shows a procedure having a data cache hit determination function according to the present invention. FIG. 16 of the flowchart for explaining the processing procedure of the program to be executed, FIG. 16 is a schematic diagram for explaining a software verification model generation method by adding a procedure having a data cache hit determination function according to the present invention.

  Hereinafter, referring to FIGS. 14 to 16, when the data cache memory is built in the target CPU, the procedure having the data cache hit determination function according to the present invention based on the software component 60 of the C base language description will be described. A processing procedure of the program to be executed will be described. Here, it should be noted that the processing procedure of steps 205 to 245 in FIG. 14 is substantially the same as the processing procedure of steps 105 to 145 in FIG. 9 described above.

  First, in step 205 in FIG. 14, the software component 60 described in the C base language before the execution time is added is input, and the source code portion (the C code portion) based only on the ANSI-C description is input from the software components. Take out). Next, at step 210, the C code portion (ANSI-C description) 62 in which the control point is inserted is recognized by recognizing the Basic Block (basic block) for this C code portion and inserting the control point. Is output. This Basic Block refers to a portion where the program runs sequentially without branching. Then, control points are inserted before and after the recognized basic block.

  More specifically, for the C code portion shown in FIG. 16A, node a and node b are recognized as one Basic Block, and node c, node d and node e are one Basic Block. Node c and node f are recognized as one basic block, and node g is recognized as one basic block. Therefore, as shown in FIG. 14B, control is performed between the node b and the node c, between the node e and the node g, between the node f and the node g, and after the node g, respectively. A point (a portion marked with ● in FIG. 16B) is inserted.

  Further, in step 220, the target CPU binary code 64 is generated by compiling the portion of the C code in which such control points are inserted.

  Further, in Step 230, Basic Blocks are sequentially extracted from the C code portion 62. In step 235, it is determined whether there is a basic block to be extracted. If it is determined that there is a Basic Block to be extracted, the control point of the Basic Block extracted in Step 230 based on the target CPU binary code (data code) 64 generated as a result of the above-described compilation in Step 240. Calculate the execution time between. On the other hand, if it is determined that there is no Basic Block to be extracted, the software component of the C base language description obtained in steps 205 to 235 described above is output as the verification model 66, and the processing of this program is terminated.

The calculation of the execution time between the control points of the Basic Block in the above step 240 is as follows:
Σ [number of cycles for each instruction]
It is performed based on the following arithmetic expression.

  Further, in step 245, an execution time insertion statement (in which the calculated execution time is used as a parameter) is set to an arbitrary control point in the portion of the C code where the control point is inserted (that is, an arbitrary control point after the Basic Block). In the case of SpecC, it is a waitfor statement) and is output as a verification model (C base model after execution time insertion statement addition) 66 of the C base language description.

  At this time, in step 250 of FIG. 15, the target CPU assembly code generated as a result of the above-described compilation is analyzed to detect a data access instruction (load instruction and store instruction), and the load instruction and store instruction are generated. Whether the data cache memory is hit at the part of the C code corresponding to the generated load instruction and store instruction (that is, the part that requires data access of the C code). Insert a procedure call for determining whether or not (data cache hit determination: data cache memory miss determination). At this time, as shown in FIG. 16B, a load_dcache data cache hit determination procedure is inserted in the C source code portion where the load instruction is generated, as shown in FIG. The data cache hit determination procedure of store_dcache is inserted into the C source code portion where is generated. Further, in step 255 in FIG. 15, an assembler code for invalidating the data cache memory when a cache miss in the data cache memory is detected is called a data cache invalidation procedure for invalidating the data cache memory. Is converted into source code (that is, C code) based only on the ANSI-C description.

  Further, in step 260 of FIG. 15, it is determined whether or not the data cache memory is hit according to the procedure inserted in step 250 described above, and a procedure having a data cache hit determination function for the load instruction and the store instruction is given. To do. In this data cache hit determination function, when it is determined whether or not the data cache memory is hit using the data tag memory portion held in the data cache memory, a cache miss of the data cache memory is determined. Is detected, the execution time for executing the cache line fill is added as a cache miss penalty.

  Further, in step 265 of FIG. 14, when the data cache invalidation procedure called in the above-described step 250 is executed, the entry of the data tag memory portion held in the data cache memory is invalidated. The CPU is kept waiting for the required execution time, and the contents of the valid bit of the data cache memory are cleared.

  Through the series of steps 205 to 265 described above, a data miss hit is determined at the portion of the C code corresponding to the load instruction and the store instruction generated by the cross-compilation for the software component of the C base language description, and the cache miss is detected. A cache miss penalty will be added when detected. Finally, the software component of the C base language description obtained in the series of steps is output as the verification model 66 of the C base language description.

  For example, as shown in the verification model of the C-based language description in FIG. 16C, the C code portion is cross-compiled, and the data address operand Ai of the load instruction or the store instruction (i is an arbitrary positive integer) And the data length (number of bytes) Li are obtained. The data address operand Ai is a variable name or stack address of data in C source code loaded or stored by a load instruction or a store instruction. The data length Li is an operand length when performing a load instruction or a store instruction. For example, in the case of ARM CPU assembly code, the operand length is 1 byte if the load instruction mnemonic is LDRB, 2 bytes if LDRH, 4 bytes if LDRW, and the store instruction If the mnemonic is STRB, it is 1 byte long, if it is STRH it is 2 bytes long, and if it is STRW it is 4 bytes long. In the example shown in FIG. 16A, the variable name loaded by the load instruction is “p”, and the variable name of the data stored by the store instruction instruction is “q”. In this case, it is assumed that the data length pointed to by these variables is 4 bytes (that is, although not shown, an LDRW or STRW instruction is generated in the case of an ARM CPU assembler instruction. ). As a result, a data cache hit determination call statement (load_dcache (p, 4)) for performing a data cache hit determination for a load instruction and a data cache hit determination call statement (store_dcache ( q, 4)) and are inserted. Here, if a cache miss is detected as a result of the data cache hit determination for the load instruction and the store instruction (the data content corresponding to the data address does not exist in the data cache memory), the cache line fill The execution time insertion statement (waitfor statement) is called with the execution time (line fill time) as a parameter.

  More specifically, in the data cache hit determination call statement (load_dcache (Ai, Li)) for the load instruction of FIG. 16, the data contents corresponding to the data addresses in the range of addresses Ai to Ai + Li−1 are the data cache memory. If there is a cache miss (the content of the data corresponding to the data address does not exist in the data cache memory) is detected, the cache line is returned as many times as the cache miss has occurred. The number of cycles of fill execution time (line fill time) is inserted. Here, in the store-back mode that requires replacement of the data cache line, the number of execution time cycles for executing the store-back operation is also inserted.

  On the other hand, the data cache hit determination call statement (store_dcache (Ai, Li)) for the store instruction in FIG. 16 is the same as the data cache hit determination call statement (load_dcache (Ai, Li)) for the load instruction. In addition, it is determined whether or not the data corresponding to the data address in the range from address Ai to Ai + Li−1 exists in the data cache memory, and if a cache miss is detected, a cache miss has occurred. The number of cache line fill execution times is inserted as many times as the number of times.

  However, the data cache hit determination call statement (store_dcache (Ai, Li)) for the above store instruction is compatible with the store-through mode. )).

  In store-through mode, the data cache line is not replaced, but the store buffer is full (the memory in the store buffer is full) each time a store instruction is executed. The check is done. This check of whether or not the store buffer is full is executed by comparing the time when the value of the desired data is set in the store buffer with the current time. On the other hand, in the store-back mode, the cache line fill operation is executed as necessary, and the dirty bit of the data cache line is set (for example, the dirty bit is set to “1”). In a verification model for a C-based language description generated by a target CPU such as an ARM processor, when a cache miss is detected, the CPU waits until the cache line fill is completed.

  In other words, when the data cache memory is built in the target CPU, the software component verification model is generated based on the data cache hit determination call statement for the load instruction and the store instruction as described in FIGS. When inserting, a data cache hit determination call statement (load_dcache (Ai, Li)) is inserted into the C code portion corresponding to the load instruction, and a data cache hit determination call statement is inserted into the C code portion corresponding to the store instruction. Compile a verification model of C-based language description obtained by inserting (store_dcache (Ai, Li)). By executing the host CPU binary code generated by this compilation on the host CPU, it is possible to execute a C-based simulation using a C-based simulator.

  Using this C-based simulator, a data cache hit determination call statement (load_dcache (Ai, Li)) and a data cache hit determination call statement (store_dcache (store_dcache ()) inserted in the portions of the C code corresponding to the load instruction and the store instruction, respectively. Ai, Li))), the execution time for executing the cache line fill in the case of a cache miss in the data cache memory is added. It becomes higher than the method, and the time management of the execution time can be performed more accurately.

  Preferably, when a data address conversion buffer (for example, TLB (translation lookaside buffer)) for converting a data address of the data cache memory from a virtual address to a physical address is provided in the target CPU. The memory management unit function is added to the data cache hit determination call statement (load_dcache (Ai, Li)) for the load instruction and the data cache hit determination call statement (store_dcache (Ai, Li)) for the store instruction.

  In this memory management unit function, it is determined whether or not the data address exists in the data address conversion buffer at the portion of the C code corresponding to the generated load instruction and store instruction. When it is detected that it does not exist in the conversion buffer, the time for loading the data address conversion entry into the data address conversion buffer is added. Therefore, it is possible to execute a high-precision simulation including the time for loading the data address conversion entry when the data address conversion buffer is missed.

  More specifically, in order to make it possible to add the memory management unit function described above, a page memory which prepares a cache memory holding the contents of the data address conversion buffer in advance and holds the contents of the virtual memory mapping information Are prepared in advance in the main memory.

  Based on the data cache hit determination call statement (load_dcache (Ai, Li)) for the load instruction, it is determined whether or not a data address in the range from address Ai to Ai + Li-1 exists in the data address conversion buffer. I do. As a result of this determination, if a cache miss in the data address conversion buffer (the content of the data corresponding to the data address does not exist in the data address conversion buffer) is detected, the entry of the data address conversion buffer entry The contents are updated to the values loaded from the page table in the main storage device, and the number of cycles for loading the data address conversion buffer is inserted. Here, an execution time insertion statement (waitfor statement) is called with the time to load into the data address conversion buffer as a parameter.

  Similarly, based on the data cache hit determination call statement (store_dcache (Ai, Li)) for the store instruction, whether or not a data address in the range of addresses Ai to Ai + Li−1 exists in the data address conversion buffer. Judgment is made. As a result of this determination, when a cache miss in the data address conversion buffer is detected, the contents of the data address conversion buffer entry are updated to the values loaded from the page table in the main memory, and the data address conversion buffer is updated. Insert the number of cycles for loading. In this case as well, an execution time insertion statement (waitfor statement) is called with the time to load into the data address conversion buffer as a parameter.

  Further, preferably, when the above-mentioned memory management unit function is executed, the presence / absence of a data address protection function is checked. Here, when a violation of the access protection of the data address conversion is detected, it is notified that an access protection exception has occurred. This makes it possible to reliably detect violations of data address translation access protection during simulation.

  FIG. 17 is a diagram showing an example in which a program relating to data cache hit determination according to the present invention is inserted into C source code. However, the example of FIG. 17 is different from the example of the C code portion described with reference to FIG.

  In the upper left part of FIG. 17, a C source code part by ANSI-C description is illustrated. The generation of load instructions and store instructions generally depends on cross compiler optimization options. For example, when cross-compiling without an optimization option, local variables appearing in C source code are also allocated to the stack area, and a load instruction and a store instruction are generated each time the local variable is accessed. Therefore, as far as the C source code portion is seen, the portion of the C source code corresponding to the portion that generates the load instruction and the store instruction (for example, the portion surrounded by a plurality of blocks in the upper left of FIG. 13). It is difficult to recognize, and the location where the data cache hit judgment call statement (load_dcache (Ai, Li)) for the load instruction and the data cache hit judgment call statement (store_dcache (Ai, Li)) for the store instruction should be inserted It is difficult to specify.

  Therefore, the C source code portion at the upper left of FIG. 17 is cross-compiled and expanded into an assembler output by an assembly language description as shown on the right side of FIG. By analyzing the assembler output, it is possible to recognize a portion (for example, a portion surrounded by a plurality of blocks on the right side in FIG. 17) corresponding to the generated load instruction and store instruction. In this way, the data cache hit determination call statement (load_dcache (Ai, Li)) for the load instruction and the data cache hit determination call statement (store_dcache (Ai, Li)) for the store instruction are specified. It becomes possible easily.

  Further, in the assembler output on the right side of FIG. 17, a data cache hit determination call statement (load_dcache (Ai, Li)) for the load instruction is inserted at a position corresponding to the generated load instruction, and the generated store instruction Insert a data cache hit determination call statement (store_dcache (Ai, Li)) for the store instruction at the location corresponding to. Thereafter, the data is converted into a C source code portion (that is, a C code portion) based on the updated C language description as shown in the lower left portion of FIG. The updated C code part is loaded into the data cache hit determination call statement (load_dcache (Ai, Li)) for the load instruction and the data cache hit determination call statement (store_dcache (Ai, Li) for the store instruction by the budget addition tool. )) Is inserted. More precisely, the lower left part of FIG. 17 shows a verification model of a C-based language description that is finally output by compiling the updated C code part.

  More specifically, in the verification model of the C-based language description in FIG. 17, the data cache hit determination call statement (load_dcache (q, q,) for the load instruction is added to the portion of the C code corresponding to the generated load instruction (* q ++). 1)) is inserted, and a data cache hit determination call statement (store_dcache (q, 1)) for the store instruction is inserted into the portion of the C code corresponding to the generated store instruction (* p ++, * p). Here, when a cache miss is detected as a result of the cache hit determination for each load instruction and store instruction, execution of the cache line fill is performed at the portion of the C code corresponding to the portion where the cache miss is detected. An execution time insertion statement with time (line fill time) as a parameter is called.

  Next, a processing procedure of a program that executes a procedure having an instruction cache hit determination function and a data cache hit determination function according to the present invention when both the instruction cache memory and the data cache memory are built in the target CPU will be described. .

  In this case, the C-based language description having the instruction cache hit determination function and the data cache hit determination function according to the present invention is performed in accordance with the flowcharts of FIG. 9 and FIG. 10 and the flowcharts of FIG. 14 and FIG. The verification model is generated.

More specifically, a verification model for a C-based language description having an instruction cache hit determination function and a data cache hit determination function according to the present invention is generated by the following steps (1) to (11).
(1) A step of inputting a software component of C base language description, extracting a source code portion by ANSI-C description, recognizing a Basic Block, and inserting a control point (2) ANSI- in which the control point is inserted Step of compiling a source code portion by C description to generate binary code for target CPU (3) Step of calculating execution time between control points of Basic Block for each Basic Block (4) Execution time Step of adding an execution time insertion statement with the parameter as a parameter to the control point after the Basic Block (5) Insert a procedure call to determine whether or not the instruction cache memory is hit in units of the Basic Block (6) A portion (data) corresponding to a load instruction and a store instruction in the source code according to ANSI-C description Access is required part), inserting a call procedure for a determination of whether the data cache memory is hit

(7) A step of converting the assembler code for invalidating the instruction cache memory and the data cache memory into source code according to ANSI-C description for calling the instruction cache invalidation procedure and the data cache memory invalidation procedure. The instruction tag memory part held in the instruction cache memory is used to determine whether or not the instruction cache memory is hit, and when it is detected that the instruction cache memory is not hit, the cache A step of providing a procedure having an instruction cache hit determination function for adding execution time for executing line fill. (9) The data cache memory is hit using the data tag memory unit held in the data cache memory. Whether or not A step of providing a procedure having a data cache hit determination function for adding an execution time for executing a cache line fill when it is detected that the data cache memory is not hit (10) The instruction cache A step of invalidating an entry in the instruction tag memory unit and the data tag memory unit when the invalidation procedure and the data cache memory invalidation procedure are executed. (11) C base obtained in the series of steps Step of outputting the language description software component as the verification model

  In the verification model of the C-based language description having the instruction cache hit determination function and the data cache hit determination function as described above, the execution time between each control point inserted in the Basic Block is calculated, and the basic block unit is used. , Determine whether the instruction cache memory built into the target CPU is hit, insert a procedure call in the source code to add the execution time for executing the cache line fill when a cache miss is detected, Prepare a procedure for determining the instruction cache hit and compile it with the source code. On the other hand, determine whether or not the data cache memory built into the target CPU is hit where data access is required. Cache line fill when a cache miss is detected The procedure calls for adding the execution time of the order is inserted into the source code, to prepare a procedure for performing data cache hit determination compiled together with the source code, so that to perform the simulation.

  As described above, even when both the instruction cache memory and the data cache memory are built in the target CPU, the cache line fill is executed in the case of a cache miss of the instruction cache memory and a cache miss of the data cache memory. By adding the execution time for this, the accuracy of the estimation of the execution time becomes higher than that of the conventional method, and the accuracy of the simulation is significantly improved.

  Of course, an instruction address conversion buffer (for example, TLB) for converting the instruction address from the virtual address to the physical address is provided in the target CPU, and the data address is changed from the virtual address to the physical address. Even when a data address conversion buffer (for example, TLB) is provided in the target CPU, an instruction cache hit determination call statement (fetch_icache (Ai, Li)) and a data cache hit determination for a load instruction The memory management unit function as described above is added to the call statement (load_dcache (Ai, Li)) and the data cache hit determination call statement (store_dcache (Ai, Li)) for the store instruction.

  In this memory management unit function, it is determined whether or not an instruction address exists in the instruction address conversion buffer in units of Basic Block, and it is detected that the instruction address does not exist in the instruction address conversion buffer. When the instruction address conversion entry is loaded into the instruction address conversion buffer, the data address is converted to the data address at the portion of the C code corresponding to the generated load instruction and store instruction. The time to load the data address conversion entry into the data address conversion buffer when it is detected that the data address does not exist in the data address conversion buffer is determined. I try to add. Therefore, it is possible to execute a more accurate simulation including the time to load the instruction address conversion entry and the data address conversion entry when the instruction address conversion buffer and the data address conversion buffer are missed.

  Preferably, when executing the memory management unit function, the presence / absence of the protection function of the instruction address and the data address is checked. Here, when a violation of access protection of at least one of the instruction cache memory and the data cache memory is detected, it is notified that an access protection exception of at least one of the instruction cache memory and the data cache memory has occurred. Yes. This makes it possible to more reliably detect violations of the access protection of the instruction cache memory and the data cache memory when the simulation is executed.

  FIG. 18 is a diagram showing an example in which a program relating to instruction cache hit determination and data cache hit determination according to the present invention is inserted into C source code when both the instruction cache memory and the data cache memory are built in the target CPU. It is.

  In the upper left part of FIG. 18, the part of the C source code by ANSI-C description is illustrated. In this C source code portion, as in the case of FIG. 13 described above, the assembly language description as shown on the right side of the same block is shown in order to recognize the control point after each Basic Block by the budget addition tool. Is expanded to assembler output.

  By analyzing this assembler output, the C source code is divided into Basic Blocks, the last control point of the Basic Block is recognized, and an execution time insertion statement (for example, waitfor as shown in the lower left part of FIG. 18). (2), waitfor statements such as waitfor (4) and waitfor (5)) and an instruction cache hit determination call statement (fetch_icache statement) are additionally inserted.

  The updated C code portion is in a format in which an instruction cache hit determination call statement (fetch_icache statement) is additionally inserted at a control point after each Basic Block by a budget addition tool.

  On the other hand, by analyzing the assembler output based on the assembly language description as shown on the right side of FIG. 18, the locations corresponding to the generated load instruction and store instruction can be recognized. In this way, the data cache hit determination call statement (load_dcache (Ai, Li)) for the load instruction and the data cache hit determination call statement (store_dcache (Ai, Li)) for the store instruction are specified. It becomes possible.

  Further, in the assembler output on the right side of FIG. 18, a data cache hit determination call statement (load_dcache (Ai, Li)) for the load instruction is placed at a position corresponding to the generated load instruction, as in the case of FIG. A data cache hit determination call statement (store_dcache (Ai, Li)) for the store instruction is additionally inserted at a location corresponding to the generated store instruction. Thereafter, the data is converted into a C source code portion (that is, a C code portion) based on an updated C language description as shown in the lower left portion of FIG. The updated C code portion is inserted with an instruction cache hit determination call statement (fetch_icache statement) in units of Basic Block by a budget addition tool and a data cache hit determination call statement (load_dcache (Ai, Li)), and a data cache hit judgment call statement (store_dcache (Ai, Li)) for the store instruction is inserted. More precisely, the lower left part of FIG. 18 shows a verification model of a C-based language description that is finally output by compiling the updated C code part.

  More specifically, in the verification model of the C-based language description in FIG. 18, the execution time insertion statement (waitfor (2) inserted in the control point after each Basic Block, as in the case of FIG. 13 described above. ), Waitfor (4), and waitfor (5)) immediately after the instruction cache hit determination call statement (fetch_icache (stringcpy, 8), fetch_icache (stringcpy + 8, 20), fetch_icache (stringcpy + 28, 16), fetch_icache (stringcpy + 44, 8), and fetch_icache (stringcpy + 52, 8)) are inserted. In this example, the judgment condition for the end condition of the for statement (i <len part) is recognized as one Basic Blcok, so the execution time control statement (waitfor (2) statement) and instruction cache are included in this part. A hit judgment call statement (fetch_icache (stringcpy + 44, 8) statement) is inserted immediately before this end condition judgment expression to determine the end condition of waitfor (2), fetch_icache (stringcpy + 44, 8), i <len Converted to an expression. Here, when a cache miss is detected as a result of the instruction cache hit determination for each Basic Block, an execution time insertion statement with the cache line fill execution time (line fill time) as a parameter in the Basic Block. Is called.

  Further, in the verification model of the C-based language description in FIG. 18, as in the case of FIG. 17, the data cache hit determination for the load instruction is performed at the portion of the C code corresponding to the generated load instruction (* q ++). A call statement (load_dcache (q, 1)) is inserted, and a data cache hit determination call statement (store_dcache (p, 1) for the store instruction is inserted in the portion of the C code corresponding to the generated store instruction (* p ++, * p). 1) Insert). Again, when a cache miss is detected as a result of the cache hit determination for each load instruction and store instruction, execution of the cache line fill is performed at the portion of the C code corresponding to the portion where the cache miss is detected. An execution time insertion statement with time (line fill time) as a parameter is called.

  The present invention provides high-precision hardware / software co-verification based on a verification model after the design of a semiconductor device (chip) equipped with the main functions of a computer that controls a digital device such as a mobile phone or a digital television is completed. It is possible to apply to a hardware / software co-verification system for executing

It is a flowchart which shows the upstream design flow of SoC. It is a data flowchart for demonstrating the conventional hardware / software co-verification method. It is a schematic diagram for demonstrating the state of the timing budget process addition by the conventional hardware / software co-verification method. It is a schematic diagram for demonstrating C base simulation based on the verification model of the C base language description produced | generated in FIG. It is a block diagram which illustrates the hardware environment for enforcing the software verification model generation method concerning this invention. It is a block diagram which shows the example of a connection of the instruction cache memory and data cache memory in the embedded system using target CPU. FIG. 7 is a block diagram illustrating a specific configuration example of an instruction cache memory or a data cache memory in FIG. 6. 8 is a time chart for explaining how a cache miss penalty occurs due to a cache miss in the instruction cache memory or the data cache memory in FIG. 7. It is a flowchart (the 1) for demonstrating the process sequence of the program which performs the procedure which has the instruction cache hit determination function based on this invention. It is a flowchart (the 2) for demonstrating the process sequence of the program which performs the procedure which has the instruction cache hit determination function based on this invention. It is a schematic diagram for demonstrating the software verification model production | generation method by addition of the procedure which has the instruction cache hit determination function concerning this invention. It is a schematic diagram for demonstrating C base simulation based on the verification model of the C base language description produced | generated in FIG. It is a figure which shows the example which inserted the procedure call regarding the instruction | command cache hit determination which concerns on this invention in C source code. It is a flowchart (the 1) for demonstrating the process sequence of the program which performs the procedure which has a data cache hit determination function based on this invention. It is a flowchart (the 2) for demonstrating the process sequence of the program which performs the procedure which has a data cache hit determination function based on this invention. It is a schematic diagram for demonstrating the software verification model production | generation method by addition of the procedure which has a data cache hit determination function based on this invention. It is a figure which shows the example which inserted the program regarding the data cache hit determination which concerns on this invention in C source code. It is a figure which shows the example which inserted the program regarding instruction cache hit determination and data cache hit determination which concerns on this invention in C source code.

Explanation of symbols

12 Target CPU
DESCRIPTION OF SYMBOLS 14 Main memory 16 Cache memory 16-1 Instruction cache memory 16-2 Data cache memory 18 Bus 31 Address 32 Comparator 34 Cache hit detection part 910 Computer (PC or WS) main body 912 Host CPU (central processing unit)
914 Main memory (MS)
916 Cache memory 918 Bus 920 Display 922 Keyboard 924 Mouse 930 External storage device (hard disk device)

Claims (9)

Software verification that uses a host CPU having an instruction cache memory to generate a software verification model to perform hardware and software collaborative verification of a semiconductor device on which at least one target CPU and one OS are mounted A model generation method,
Inputting a software component of C-base language description, extracting a source code part by ANSI-C description, recognizing Basic Block, and inserting a control point;
Compiling a portion of the source code according to the ANSI-C description in which the control points are inserted to generate binary code for the target CPU;
For each of the Basic Blocks, calculating an execution time between control points of the Basic Block;
Adding an execution time insertion statement with the execution time as a parameter to a control point after the Basic Block;
Inserting a procedure call for determining whether or not the instruction cache memory is hit in the unit of the Basic Block into a control point after the Basic Block;
Converting assembler code for invalidating the instruction cache memory into source code in ANSI-C description for calling an instruction cache invalidation procedure;
It is determined whether or not the instruction cache memory is hit using the instruction tag memory portion held in the instruction cache memory, and when it is detected that the instruction cache memory is not hit, Providing a procedure having an instruction cache hit determination function for adding an execution time for executing a cache line fill;
Invalidating an entry in the instruction tag memory unit when the instruction cache invalidation procedure is executed;
A method of generating a software verification model, comprising: outputting a software component of the C-based language description obtained in the series of steps as the verification model.   When an instruction address conversion buffer for converting an instruction address from a virtual address to a physical address is provided in the target CPU, the instruction address exists in the instruction address conversion buffer in units of the Basic Block. When it is detected that the instruction address does not exist in the instruction address conversion buffer, a time for loading an instruction address conversion entry into the instruction address conversion buffer is added. The method according to claim 1, further comprising a step.   Checking the presence / absence of a protection function of the instruction address, and notifying that an exception of the access protection of the instruction address conversion buffer has occurred when a violation of access protection of the instruction address conversion buffer is detected. 3. The software verification model generation method according to claim 2, further comprising: Software verification that uses a host CPU having a data cache memory to generate a software verification model to perform collaborative verification of hardware and software of a semiconductor device on which at least one target CPU and one OS are mounted A model generation method,
Inputting a software component of C-base language description, extracting a source code part by ANSI-C description, recognizing Basic Block, and inserting a control point;
Compiling a portion of the source code according to the ANSI-C description in which the control points are inserted to generate binary code for the target CPU;
Calculating an execution time between control points of the Basic Block;
Adding an execution time insertion statement with the execution time as a parameter to a control point after the Basic Block;
Inserting a procedure call for determining whether or not the data cache memory is hit in a portion where data access is required in the source code according to the ANSI-C description;
Converting assembler code for invalidating the data cache memory into source code in ANSI-C description for calling a data cache invalidation procedure;
It is determined whether or not the data cache memory is hit using the data tag memory portion held in the data cache memory, and when it is detected that the data cache memory is not hit, Providing a procedure having a data cache hit determination function for adding an execution time for executing a cache line fill;
Invalidating an entry in the data tag memory unit when the data cache invalidation procedure is executed;
A method of generating a software verification model, comprising: outputting a software component of the C-based language description obtained in the series of steps as the verification model.   In the case where a data address conversion buffer for converting a data address from a virtual address to a physical address is provided in the target CPU, data access is required in the source code according to the ANSI-C description. It is determined whether or not the data address exists in the data address conversion buffer, and when it is detected that the data address does not exist in the data address conversion buffer, an entry for data address conversion is displayed. 5. The software verification model generation method according to claim 4, further comprising a step of adding a time for loading to the data address conversion buffer.   Checking the presence / absence of the data address protection function and, if a violation of access protection of the data address conversion buffer is detected, notifying that an access protection exception of the data address conversion buffer has occurred 6. The software verification model generation method according to claim 5, further comprising: Using a host CPU having an instruction cache memory and a data cache memory, a software verification model is used to perform cooperative verification of hardware and software of a semiconductor device on which at least one target CPU and one OS are mounted. A software verification model generation method for generating,
Inputting a software component of C-base language description, extracting a source code part by ANSI-C description, recognizing Basic Block, and inserting a control point;
Compiling a portion of the source code according to the ANSI-C description in which the control points are inserted to generate binary code for the target CPU;
For each of the Basic Blocks, calculating an execution time between control points of the Basic Block;
Adding an execution time insertion statement with the execution time as a parameter to a control point after the Basic Block;
Inserting a procedure call for determining whether or not the instruction cache memory is hit in the unit of the Basic Block into a control point after the Basic Block;
Inserting a procedure call for determining whether or not the data cache memory is hit in a portion where data access is required in the source code according to the ANSI-C description;
Converting the assembler code for invalidating the instruction cache memory and the data cache memory into source code according to ANSI-C description for calling the instruction cache invalidation procedure and the data cache memory invalidation procedure;
It is determined whether or not the instruction cache memory is hit using the instruction tag memory portion held in the instruction cache memory, and when it is detected that the instruction cache memory is not hit, Providing a procedure having an instruction cache hit determination function for adding an execution time for executing a cache line fill;
It is determined whether or not the data cache memory is hit using the data tag memory portion held in the data cache memory, and when it is detected that the data cache memory is not hit, Providing a procedure having a data cache hit determination function for adding execution time for executing a cache line fill;
Invalidating entries in the instruction tag memory unit and the data tag memory unit when the instruction cache invalidation procedure and the data cache memory invalidation procedure are executed;
A method of generating a software verification model, comprising: outputting a software component of the C-based language description obtained in the series of steps as the verification model. When an instruction address conversion buffer for converting an instruction address from a virtual address to a physical address is provided in the target CPU, the instruction address exists in the instruction address conversion buffer in units of the Basic Block. When it is detected that the instruction address does not exist in the instruction address conversion buffer, a time for loading an instruction address conversion entry into the instruction address conversion buffer is added. Steps,
In the case where a data address conversion buffer for converting a data address from a virtual address to a physical address is provided in the target CPU, data access is required in the source code according to the ANSI-C description. It is determined whether or not the data address exists in the data address conversion buffer, and when it is detected that the data address does not exist in the data address conversion buffer, an entry for data address conversion is displayed. 8. The software verification model generation method according to claim 7, further comprising a step of adding time for loading to the data address conversion buffer. Checking whether the instruction address protection function is present, and in the case where a violation of the access protection of the instruction address conversion buffer is detected, notifying that an access protection exception of the instruction address conversion buffer has occurred,
Checking whether the data address protection function is present, and notifying that an access protection exception of the data address conversion buffer has occurred when a violation of access protection of the data address conversion buffer is detected; 9. The software verification model generation method according to claim 8, further comprising:

Images