JP2005108007A - LSI design verification apparatus and LSI design verification method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an LSI design verification apparatus and an LSI design verification method that can verify whether results of an operation simulation in an upstream design phase and results of an RTL simulation in a downstream design phase match in an intermediate stage of the RTL simulation or in an LSI circuit to be verified. <P>SOLUTION: The LSI design verification apparatus 1 which executes system architecture design verification and detailed design verification comprises a first simulation part 2 for executing LSI system architecture design verification by operation simulation, an operation history extraction part 3 for extracting an operation history of the operation simulation, an assertion checking means generation part 4 for generating an assertion checking means for monitoring whether operations in simulation for detailed design verification correspond to operations in the extracted operation history, and a second simulation part 5 for executing detailed design verification by simulation using the assertion checking means. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to an LSI design verification apparatus and an LSI design verification method for performing system architecture design verification and detailed design verification of an LSI, particularly a system LSI.

  In recent years, it has become possible to realize a large-scale digital system using a one-chip LSI due to the miniaturization of LSI and the progress of integration technology. Such an LSI is called a system LSI. In the development of system LSIs, it is required to design products from the system specification / operational design to the functions, logics, and layouts in a top-down manner while performing step-by-step verification and to commercialize them at an early stage.

  In particular, in system-level specifications / operations and realization of basic architectures based on the premise of LSI implementation, system LSI processing performance is required before proceeding with detailed design because architecture changes after chip manufacturing involve significant costs. For example, it is required to analyze the bottleneck portion. For this reason, a functional operation description of a system is performed using C language or the like, and after confirming specifications and functions, an architecture for realizing the functions is modeled with appropriate accuracy.

  For example, functional verification of the system architecture has been performed by simulating system operation, data flow, and data transfer on the data bus with transaction accuracy or clock cycle accuracy of a synchronous clock signal. Performance estimation that can be realized with the system architecture and performance constraint analysis are also performed.

  Appropriate design selection is performed based on the plurality of architecture plans obtained in this way, and detailed design of the next step is performed based on a manual using the selected architecture plan as a specification. Detailed design is performed, for example, by functional design based on a register configuration of a circuit called RTL (Register Transfer Level). Further, simulation of clock cycle accuracy or HDL (Hardware Description Language) simulation based on RTL description is performed, and verification in detailed design is performed.

  After such a simulation, the consistency between the high-level abstraction of the design upper level, that is, the operation of the coarse simulation level, and the detailed RTL design result designed manually in the design sub-process Need to verify. Until now, this verification has been performed by comparing the LSI output values in the simulation and confirming the match, or by setting an assertion check for the RTL description based on the higher-level design specification, and violating the specification. It is done by checking whether or not.

  The assertion check is a mechanism that defines an allowable operation of a circuit under a specified condition / environment and issues a warning when it is violated. The assertion check is created in a dedicated manual based on the bus protocol and circuit specifications, and is incorporated into RTL design and software as part of a kind of circuit or embedded software (for example, Patent Document 1, Non-Patent Document). Reference 1 and Non-Patent Document 2).

In addition, the assertion check may be provided for a predetermined assertion as an assertion check tool library (a software module group for directly observing and checking simulation information in combination with an HDL simulator) (non-existing). Patent Document 2).
Japanese Patent Laid-Open No. 10-312311 Hara, Ueki, Hirayama, "Proposal of Embedded Software Test Method by Simulation and Efficient Operation Method of Test Environment", Information Processing Society of Japan, 126th Proceedings of Software Engineering Society, PP. 73-80 (March 2000) R.Ramesh, T. Anderson, "Assertion Methodology for Verilog Design", [online], April 27, 2001 (Isd), The Journal of The Design Process, [Search July 1, 2002], Internet <URL: http://www.eedesign.com/ story / OEG20010427S0083>

  However, when verifying the consistency between the simulation level operation and the RTL design result by comparing the LSI output values in the simulation and confirming the match, the match and mismatch in the operation result are confirmed. However, there is a problem in that it is impossible to detect an operation mismatch that occurs in the middle of the simulation or inside the circuit, that is, an operation that is out of specification in the RTL design.

  When verification is performed by setting a conventional assertion check, since the assertion created or selected by the designer is set at a location designated by the designer, the higher-level verification in the RTL design is performed. There is a problem that it is not possible to confirm the consistency between the operation simulation, in particular, the transaction accuracy operation simulation and the assertion check.

  An object of the present invention is to solve the above-described problem, and the result of the upper-level operation simulation and the result of the lower-level RTL simulation match in the stage of the RTL simulation or in the LSI circuit to be verified. It is an object to provide an LSI design verification apparatus and an LSI design verification method capable of verifying whether or not they are present.

  In order to achieve the above object, an LSI design verification method according to the present invention is an LSI design verification method for performing system architecture design verification and detailed design verification of the LSI in LSI design, and (a) the previously created LSI design verification method Performing a system architecture design verification of the LSI by performing an operation simulation of an LSI system operation model; (b) extracting an operation history of the LSI simulated in the operation simulation; Generating assertion check means for monitoring whether or not the operation of the LSI simulated in the detailed design verification simulation of the LSI corresponds to the operation of the extracted operation history; and (d) the assertion check means Simulation using Performing Shon, and having at least a step of performing the detailed design verification.

  Next, in order to achieve the above object, an LSI design verification apparatus according to the present invention is an LSI design verification apparatus that performs system architecture design verification and detailed design verification of the LSI in LSI design. A first simulation unit that performs system architecture design verification of the LSI by performing an operation simulation of an LSI system operation model; an operation history extraction unit that extracts an operation history of the LSI simulated in the operation simulation; An assertion check means generating section for generating an assertion check means for monitoring whether the operation of the LSI simulated in the detailed design verification simulation of the LSI corresponds to the operation of the extracted operation history; Performing simulation using the insertion checking means and characterized by having at least a second simulation unit for performing the detailed design verification.

  Further, the present invention may be a program for realizing the LSI design verification method according to the present invention. By installing this program on a computer and executing it, the LSI design verification method of the present invention can be executed.

  With the above features, according to the LSI design verification apparatus and the LSI design verification method according to the present invention, the result of the upper-level operation simulation and the result of the lower-level RTL simulation are verified or verified in the middle of the RTL simulation. It is possible to verify whether or not there is a match within the target LSI circuit.

  For this reason, since it is possible to detect design defects that were difficult to detect in the prior art, it is possible to improve the degree of completeness in the detailed design (RTL design). Therefore, it is possible to greatly improve the development loss of design rework when a bug is detected in the design process after the detailed design (for example, layout design) and the evaluation of the sample LSI, and the improvement of the completeness of the LSI design can be improved at an early stage. It can be planned.

  In the LSI design verification method according to the present invention, in the step (b), as the operation history, the output history of signals on the LSI obtained from the operation simulation and the LSI on the LSI obtained from the operation simulation. It is preferable to extract the update history of the storage area.

  In the step (c), the signal on the LSI obtained from the detailed design verification simulation is output at the time when the corresponding signal on the LSI obtained from the operation simulation is output. It is also preferable that an assertion check means that generates the assertion is generated. In this case, the signal on the LSI obtained from the detailed design verification simulation is output in a time zone range based on the output time of the signal on the LSI obtained from the corresponding operation simulation. This can be used as a condition for assertion.

  Furthermore, in the step (c), the time at which the storage area on the LSI obtained from the detailed design verification simulation is updated in the storage area on the LSI obtained from the corresponding operation simulation. In addition, it is preferable that an assertion check unit that generates an assertion that data has been updated with the content of the update history is preferably generated. In this case, the storage area on the LSI obtained from the detailed design verification simulation has a time zone based on the time when the data update occurred in the corresponding storage area on the LSI obtained from the operation simulation. An assertion condition may be that data has been updated with the content of the update history within a range.

  In the LSI design verification method according to the present invention, in the operation simulation in the step (a), the data update in the storage area is performed starting from the output of the signal, and the step (c) In the above, the storage area on the LSI obtained from the simulation of the detailed design verification is the time when the signal that is the starting point of the data update in the storage area on the LSI obtained from the corresponding operation simulation is output. It is also preferable that an assertion check unit that generates an assertion that data is updated with the content of the update history is generated after a preset time has elapsed.

  Further, in the step (c), an assertion check means for determining the presence or absence of the data change is generated based on event information indicating the presence or absence of the data change in the storage area on the LSI obtained from the operation simulation, The assertion check means, when the data change of the storage area on the LSI obtained from the operation simulation has been performed, the storage area on the LSI obtained from the simulation of the detailed design verification corresponding thereto It is also preferable to adopt an aspect in which an update is made with the content of the update history.

  In the LSI design verification method according to the present invention, the operation simulation is performed for each bus transaction in the step (a), and the operation history is stored for each bus transaction in the step (b). It can be set as the aspect extracted.

  In this aspect, in the step (b), as the operation history in the bus transaction unit, the output history of the bus request signal on the LSI obtained from the operation simulation and the address accessed in the operation simulation. It is preferable to extract the update history of the space.

  In this aspect, in the step (c), the bus request signal on the LSI obtained from the simulation of the detailed design verification is the bus request signal on the LSI obtained from the corresponding operation simulation. It is also preferable to generate an assertion check means that asserts that it has been output at the output time. In this case, the bus request signal on the LSI obtained from the detailed design verification simulation is a time zone based on the output time of the bus request signal on the LSI obtained from the corresponding operation simulation. The assertion condition can be output in the range of.

  Further, in this aspect, in the step (c), the address space accessed in the detailed design verification simulation is changed to the time at which the data update of the address space extracted from the corresponding operation simulation occurs. It is also preferable to generate an assertion check means that asserts that data has been updated with the content of the update history. In this case, the address space accessed in the detailed design verification simulation is updated within the time zone range based on the time when the data update of the address space extracted from the corresponding operation simulation occurs. The fact that the data has been updated with the contents of the history can be used as the condition for the assertion.

  In this aspect, in the operation simulation in the step (a), the data update in the address space is performed starting from the output of the bus request signal. In the step (c), the details The address space accessed in the design verification simulation is set in advance after the output time of the bus request signal that is the starting point of data update in the address space extracted from the corresponding operation simulation. It is also preferable to generate an assertion check means that asserts that data has been updated with the content of the update history before the elapsed time has elapsed.

  Further, in this aspect, in the step (c), the assertion check means for determining the presence / absence of the data change is generated based on the event information indicating the presence / absence of the data change in the address space accessed in the operation simulation. And the assertion check means, when the data change of the address space accessed in the operation simulation has been performed, the address space accessed in the simulation of the detailed design verification corresponding thereto is changed to the update history. It is also preferable to make an assertion that the content is updated.

  In the LSI design verification method of the present invention, the system operation model includes a CPU model, and in the step (b), the operation history of the CPU model in the operation simulation is extracted as the operation history. You can also

  In this aspect, it is preferable that the operation history of the CPU model is extracted based on the change in the program counter of the CPU model generated in the operation simulation.

  Furthermore, in this aspect, the program counter of the CPU model stores the address of the instruction extracted when the program to be executed in the CPU model is compiled, the jump destination address of the instruction, the start address of the subroutine, the start of the task It is preferable that the operation history of the CPU model is extracted when at least one of an address, a thread start address, and a process start address is indicated.

  Also, in this aspect, the operation history of the CPU model is a change history of the program counter of the CPU model in the operation simulation and an output history of the signal output accompanying the change of the program counter, ), After the value of the CPU model program counter in the detailed design verification simulation becomes the value of the CPU model program counter in the operation simulation, the CPU model program counter in the detailed design verification simulation It is preferable that an assertion check unit that generates an assertion that a signal output in the case of the value is output with the content of the output history is generated.

  Further, in this aspect, the operation history of the CPU model is a change history of the program counter of the CPU model in the operation simulation and an update history of the storage area used in association with the change of the program counter, In the step c), after the value of the CPU model program counter in the detailed design verification simulation becomes the value of the CPU model program counter in the operation simulation, when a preset time elapses, It is also preferable that an assertion check means is generated that asserts that the storage area used when the CPU model program counter in the detailed design verification simulation has the value is updated with the content of the update history. .

  Hereinafter, an LSI design verification apparatus and an LSI design verification method according to the present invention will be specifically described with reference to the drawings. The LSI design verification apparatus and the LSI design verification method of the present invention are not limited to the following embodiments, and can be implemented in various modes within the scope not departing from the gist.

(Embodiment 1)
Hereinafter, an LSI design verification apparatus and an LSI design verification method according to Embodiment 1 of the present invention will be described with reference to FIGS. In the first embodiment, bus transaction information is extracted as an operation history based on a bus request in an operation simulation, and four types of assertion check means are generated based on the extracted bus transaction information. Show.

  First, the configuration of the LSI design verification apparatus according to the first embodiment will be described with reference to FIGS. FIG. 1 is a diagram showing a schematic configuration of an LSI design verification apparatus according to Embodiment 1 of the present invention.

  As shown in FIG. 1, the LSI design verification apparatus 1 includes a first simulation unit 2, an operation history extraction unit 3, an assertion check means generation unit 4, and a second simulation unit 5. In FIG. 1, an operation description 6 is created by functionally describing a system in C language or the like, and describes a system operation model at a higher design level. The RTL description 7 is created by HDL in the detailed design, and more specifically describes the system operation model in the operation description 6.

  The first simulation unit 2 shown in FIG. 1 reads a system behavior model created in advance from the behavior description 6 and performs an operation simulation using this to perform LSI system architecture design verification. In the first embodiment, the first simulation unit 2 is a simulation device (simulator) that performs system architecture design verification.

  In the first embodiment, as shown in FIG. 9 to be described later, the system operation model uses a data bus on an LSI, and data is transmitted in response to a bus request from a bus master such as a CPU constituting the LSI. Giving and receiving. For this reason, the first simulation unit 2 executes an abstracted operation simulation in which the series of data transfer is collectively performed as a transaction transfer, that is, an operation simulation in units of bus transactions. In addition, the first simulation unit 2 observes bus requests and bus transactions of each bus master during the operation simulation, and operates them in a storage unit (not shown) included in the first simulation unit 2. It is memorized as history.

  The operation history extraction unit 3 illustrated in FIG. 1 extracts the operation history of the LSI simulated in the operation simulation by the first simulation unit 2. The extracted operation history includes an output history of signals on the LSI obtained from the operation simulation and an update history of the storage area on the LSI obtained from the operation simulation.

  In the first embodiment, the operation simulation is executed for each bus transaction as described above. For this reason, the operation history extraction unit 3 extracts the operation history in units of bus transactions, the output history of the bus request signal output from the bus master on the LSI obtained from the operation simulation, and the address accessed in the operation simulation. The update history of the space is extracted. Specifically, the bus transaction information shown in FIG. 2 is extracted as the operation history. FIG. 2 is a diagram illustrating an example of bus transaction information extracted in the first embodiment.

  As shown in FIG. 2, the bus transaction information includes information such as a bus master ID, a bus request time, a target address, an update time indicating a time when the target address is updated, and updated update data (stored information). Yes. The target address indicates address information of an address space that is updated when a transaction is completed.

  The bus master ID is an identifier for identifying a bus request signal output by the bus master. In the first embodiment, the output of the bus request signal specified by the bus master ID becomes the starting point of the transaction. In the first embodiment, it is considered that a bus request is output when the bus request signal output from the bus master becomes active.

  The assertion check means generator 4 shown in FIG. 1 generates assertion check means for monitoring whether or not the LSI operation simulated in the LSI detailed design verification simulation corresponds to the extracted operation history operation. . In the first embodiment, the assertion check means is a program module described as one circuit module using HDL such as Verilog language.

  Moreover, in this Embodiment 1, as above-mentioned, four types of assertion check means are produced (refer below-mentioned FIGS. 4-7). Furthermore, the assertion check means generation unit 4 reads the RTL description 7 and incorporates the created assertion check means. There are cases where all of the generated assertion check means are incorporated in the RTL description 7 and only some are incorporated in the RTL description 7. The structure of the assertion check means will be described below with reference to FIG.

  FIG. 3 is a diagram schematically showing the basic configuration of the assertion check means in the first embodiment. The assertion check means is a circuit module that receives an assertion condition and a signal necessary for determining an operation result, and is described in HDL. In the assertion check means shown in FIG. 3, in the simulation for detailed design, a function for outputting a message when a problem has occurred in the output time of the bus request signal, the update time of the address space, the update data, etc. Can be realized by using a built-in function provided by the HDL description or the HDL simulator to be used. Further, although not shown in FIG. 3, the assertion check means has a storage area (register array) for storing expected values for comparing the signal values of the input signals.

  The second simulation unit 5 shown in FIG. 1 performs a detailed design verification by performing a simulation using an assertion check unit. In the first embodiment, the second simulation unit 5 reads the RTL description 7 in which the assertion check unit is incorporated by the assertion check unit generation unit 4 and uses the same pattern as the higher-level operation simulation, The RTL description 7 is simulated (RTL simulation). Detailed design verification is performed by executing this RTL simulation.

  Note that the “same pattern” mainly means an input signal pattern (so-called test vector) input to the LSI on simulation and an initial value of the memory. In the first embodiment, the operation simulation and the detailed design RTL simulation are executed under the same input conditions.

  Therefore, the assertion check means incorporated in the RTL description 7 determines whether there is an assertion violation. In the first embodiment, the second simulation unit 5 is a simulation device (HDL simulator) that performs detailed design verification.

  Here, a specific example of the assertion check unit generated in the first embodiment will be described with reference to FIGS. 4 to 7 are diagrams showing an example of an assertion check unit and an example of bus transaction information in the first embodiment. The assertion check means shown in FIGS. 4 to 7 are described in HDL, and the types are different.

  FIG. 4 shows an assertion that asserts that the signal output in the simulation for detailed design verification (RTL simulation) is output at the time when the signal output in the corresponding operation simulation is output. An example of checking means is shown. Note that “signal output” in this specification includes activating a signal that has been inactive. In this case, the time when the signal is activated becomes the time when the signal is output.

  In the example of FIG. 4, the assertion check means is composed of the assertion module A1, and is described based on the bus transaction information TR1. Further, the assertion module A1 has the information of the transaction information TR1 as a structure, and refers to the bus request signal indicated by “bus master ID” as an input.

  Further, the assertion module A1 activates the bus request signal of the bus master indicated by the bus master ID in the RTL simulation when the simulation time of the RTL simulation matches the bus request time of the bus transaction information (in the example of FIG. If the state is not defined as “fire”), it is described as an assertion error. The determination of the simulation time is performed by the TIME () function, and the value of the TIME () function is acquired from the HDL simulator (second simulation unit 5).

  As described above, the assertion checking unit shown in FIG. 4 asserts that the bus request in the RTL simulation is output at the time when the bus request included in the bus transaction information TR1 is output.

  FIG. 5 shows that the storage area accessed in the detailed design verification simulation (RTL simulation) is used in this operation simulation at the time when the data update of the storage area accessed in the corresponding operation simulation occurs. An example of an assertion check unit that asserts that data has been updated with the contents of the update history of the storage area is shown.

  In the example of FIG. 5, the assertion check means is composed of the assertion module A2, and is described based on the bus transaction information TR2. Further, the assertion module A2 has information of transaction information TR2 as a structure, and refers to a target address in the RTL simulation by an input variable mem [].

  Further, the assertion module A2 always determines whether or not the update time of the bus transaction information TR2 has been reached while the RTL simulation is being performed (described in “Always () {}”). An assertion check is performed for all target addresses in the RTL simulation corresponding to the target address of the information TR2 (described in “for all () []”).

  Specifically, when the assertion module A2 reaches each update time, if the corresponding address space, that is, the value of the target address in the RTL simulation does not match the value of the update data of the transaction information TR2, the assertion module A2 It is described as

  As described above, the assertion check unit shown in FIG. 5 is used in the operation simulation at the time when the address space used in the RTL simulation is updated in the address space used in the corresponding operation simulation. Assertion is that the data has been updated with the contents of the update history of the address space.

  The assertion module A2 shown in FIG. 5 has an operation description for checking the value of the target address at every time of the RTL simulation. However, as shown in FIG. 8, the simulation process can be made more efficient. You can also. FIG. 8 is a diagram showing a specific example of the assertion check means in which the simulation process is more efficient than the assertion check means shown in FIG.

  As shown in FIG. 8, the assertion module A8 as an assertion check means is described so as to check in advance whether or not there is a data change (event) in the LSI address space (memory module) used in the operation simulation.

  The assertion module A8 does not match the value of the corresponding address space with the updated data value of the address space in which the data change has occurred until the data change has occurred in the address space accessed in the operation simulation. It is described to judge whether or not.

  For this reason, according to the assertion module A8, it is possible to reduce data comparison processing when no data change (event) occurs.

  Further, in the assertion module A8 shown in FIG. 8, the first simulation unit 1 that performs the operation simulation is an event-driven simulator, and event information indicating whether or not the data in the address space used in the operation simulation is changed. It has a function to create and is described on the assumption that this function is used.

  Therefore, as shown in FIG. 8, the assertion module A8 determines the presence / absence of an event at the target address based on EVENT (mem [TR2. Target address]). In FIG. 8, the state when the event occurs is defined as “happen”.

  When the first simulation unit 1 that performs the operation simulation is a simulator that employs a processing method other than the event drive method, the assertion module A8 observes the input of the write enable signal to the memory module. Thus, it can be configured to determine the presence or absence of data change.

  In this case, the assertion module A8 may register the update time of the target address of the assertion module A8 as an event for executing the assertion check.

  In FIG. 6, the storage area used in the detailed design verification simulation is after the output time of the signal (bus request) that is the starting point of the data update in the storage area used in the corresponding operation simulation. An example of an assertion check means that asserts that data has been updated with the content of the update history used in this operation simulation before a preset time has elapsed is shown.

  In the example of FIG. 6, the assertion check means is composed of the assertion module A3 and is described based on the transaction information TR3. The assertion module A3 has transaction information TR3 information as a structure, and refers to the address space used in the RTL simulation corresponding to the target address by the input variable mem [].

  The assertion module A3 uses a static variable time to count the passage of time in the RTL simulation. Further, the assertion module A3 determines whether the time from when the bus request is output until the data of the address space used in the RTL simulation is updated has reached a preset time by the constant Delay. Is judged. In the example of FIG. 6, the constant Delay is set to “N”. “N” is a unit time in simulation.

  Specifically, when the bus request signal is activated in the RTL simulation (defined by “fire”), the assertion module A3 sets “Delay + 1” in the static variable time, and sets this value as the time. It is described to be decremented as time passes.

  Further, the assertion module A3, when the unit time N elapses, that is, when the value of the decremented time variable becomes 1, the values of all target addresses in the RTL simulation corresponding to the target address of the transaction information TR3. However, if it does not match the update data value of the transaction information TR3, it is described as an assertion error.

  As described above, the assertion check means shown in FIG. 6 is the time when the bus request from which the address space used in the RTL simulation is the starting point of the data update of the address space used in the corresponding operation simulation is output. Assume that the data has been updated with the contents of the update history of the address space used in this operation simulation after the preset time has elapsed.

  In FIG. 7, the signal output in the simulation for the detailed design (RTL simulation) is output in the time zone range based on the output time of the signal output in the corresponding operation simulation. An example of an assertion check means that asserts the fact is shown.

  The assertion check means shown in FIG. 7 extends the determination time of the association condition in the assertion check means shown in FIG. 4 to the time zone range including the time when the signal is output.

  Note that the assertion check means shown in FIG. 7 is a time zone range in which the storage area used in the detailed design verification simulation is based on the time when the data of the storage area used in the corresponding operation simulation is updated. Thus, it may be an assertion check means that asserts that data has been updated with the content of the update history.

  That is, the assertion check unit shown in FIG. 7 may extend the determination time of the association condition in the assertion check unit shown in FIG. 5 to a time range including the time when the signal is output.

  In the example of FIG. 7, the assertion check means is composed of the assertion module A4 and is described based on the bus transaction information TR4. Further, the assertion module A4 has information of the bus transaction information TR4 as a structure, and refers to the bus request signal indicated by the “bus master ID” as an input.

  In addition, the assertion module A4 uses a static variable flag in order to determine whether it is within the above-described time zone range in the RTL simulation. Furthermore, the assertion module A4 determines whether or not it is within the time zone range based on the time when the signal is output (the time of the bus request time) based on the constant range. In the example of FIG. 7, the constant range is set to “K”.

  Normally, when a detailed design is performed from a higher-level function, operation, and architecture design, the result of the detailed design is allowed to deviate within a certain range from the operation of the higher-level design that is the specification. “K” is a unit time on the simulation indicating the range of this deviation. In the first embodiment, the value of “K” can be appropriately set by the designer according to the circuit properties and the design target, and is set to a value such as a clock cycle or several cycles, for example. .

  Specifically, when the simulation time of the RTL simulation referred to by the TIME () function comes before the unit time K of the bus request time in the bus transaction information TR4, the assertion module A4 sets the static variable flag to 1 and sets the period It is described that the bus request signal specified by the bus master ID is monitored between “bus request time−K + 1” to “bus request time + K−1”.

  Further, the assertion module A4 is described so as to reset the flag when the bus master ID takes the value of fire, and to generate an assertion error if the flag is not reset when the simulation time is “bus request time + K”. Yes.

  Although examples of assertion check means have been described with reference to FIGS. 4 to 8 as described above, in the first embodiment, only a part of these assertion check means may be created.

  For example, if only the assertion check means (assertion check module A1) shown in FIG. 4 is generated, target address information, update time, and update data may not be extracted as transaction information. . The assertion check means in the present invention is not limited to the assertion check means shown in FIGS.

  Next, the LSI design verification method according to the first embodiment will be described with reference to FIGS. However, the LSI design verification method according to the first embodiment is implemented by operating the LSI design verification apparatus according to the first embodiment shown in FIG. Therefore, the LSI design verification method will be described by describing the operation of the LSI design verification apparatus with appropriate reference to FIG.

  FIG. 9 is a block diagram showing a configuration of an LSI to be verified in the first embodiment. FIG. 10 is a time chart showing the generation of bus requests and transactions in the LSI shown in FIG. FIG. 11 is a diagram showing a list of transactions generated in the LSI shown in FIG.

  As shown in FIG. 9, the LSI to be verified in the first embodiment includes a CPU 11, a DMA controller (hereinafter referred to as “DMAC”) 12, a bus controller 13 that performs bus allocation control, and data. It is configured by a buffer 14 that temporarily stores, a large-capacity memory 15, and a system bus 17. In FIG. 9, “16” indicates the path of the bus request signal.

  In the LSI shown in FIG. 9, each of the CPU 11 and the DMAC 12 serving as a bus master outputs a bus request to the bus controller 13 by activating the bus request signal. The bus request ID of the bus request output by the CPU 11 is set to “1”, and the bus request ID of the bus request output from the DMAC 12 is set to “2”.

  In the LSI operation simulation shown in FIG. 9, first, a bus transaction ETR1 for writing data from the CPU 11 to the Buffer 14 occurs. Subsequently, a bus transaction ETR2 for writing a DMA transfer instruction from the CPU 11 to the setting register of the DMAC 12 occurs.

  Further, this DMA transfer instruction generates a transaction ETR3 in which data written to the Buffer 14 in the bus transaction ETR1 is written to the Memory 15.

  As shown in FIG. 10, in the LSI to be verified, bus transactions ETR1, ETR2, and ETR3 occur when the simulation times are T1, T2, and T3, respectively. Each bus transaction described in FIG. 9 and FIG. 10 is summarized by items such as bus transaction name, transmission, reception, access address area (address space), and bus request ID as shown in FIG.

  An LSI design verification method according to the first embodiment targeting such an LSI will be described with reference to FIG. FIG. 12 is a flowchart showing operations of the LSI design verification method according to the first embodiment of the present invention and the LSI design verification apparatus according to the first embodiment.

  As shown in FIG. 12, first, the first simulation unit 2 reads the LSI behavior model shown in FIG. 9 from the behavior description 6 and performs an operation simulation (step S1). As a result, bus transactions ETR1, ETR2, and ETR3 are generated as described in the description of FIG.

  The first simulation unit 2 observes the bus request output from the CPU 11 and the DMAC 12 and the bus transactions ETR1, ETR2, and ETR3, and stores them as an operation history.

  Next, the bus history information stored in the first simulation unit 2 is extracted as the operation history by the operation history extraction unit 3 (step S2). In the first embodiment, as shown in FIG. 13, bus transaction information is extracted in units of bus transactions.

  FIG. 13 is a diagram showing bus transaction information extracted by the LSI design verification method according to the first embodiment. FIGS. 13A to 13C show bus transactions for each bus request having different bus request times. Information is shown.

  As shown in FIGS. 13A to 13C, the latency is different for each bus transaction. In each transaction, data transfer is executed in units of 32 bits.

  Next, the assertion check means generation unit 4 generates assertion check means (step S3). In the LSI design verification method according to the first embodiment, the assertion check means generation unit generates the assertion check means shown in FIG. 14 and incorporates it in the RTL description 7. FIG. 14 is a diagram illustrating an example of an assertion check unit created by the LSI design verification method according to the first embodiment.

  The assertion check means shown in FIG. 14 is the same as the assertion check means shown in FIG. 4, and the bus request signal output in the RTL simulation is output at the bus request time in the bus transaction information (bus request This is an assertion check means that asserts that the signal is active.

  In FIG. 14, the assertion check means including the assertion modules A1-ETR1 and having the information of the bus transaction information ETR1 as a structure is shown. However, the assertion check means having the bus transaction information ETR2 and ETR3 is also created. The

  In the first embodiment, the assertion check means having the bus transaction information ETR2 as a structure is composed of the assertion modules A1-ETR2, and the assertion check means having the bus transaction information ETR3 as a structure is the assertion modules A1-ETR3. It is configured.

  FIG. 15 is a block diagram showing an LSI indicated by an RTL description in which assertion check means is incorporated. As shown in FIG. 15, by incorporating assertion check means into the RTL description, assertion modules A1-ETR1 and A1-ETR2 that receive bus request 1 and bus request 2 are input to the LSI block to be verified. Are connected to the assertion modules A1-ETR3.

  The LSI shown in FIG. 15 is configured in the same manner as the LSI shown in FIG. 9 except that the assertion modules A1-ETR1 to A1-ETR3 are connected.

  Next, the second simulation unit 5 reads out the RTL description in which the assertion check modules A1-ETR1, A1-ETR2, and A1-ETR3 are incorporated, and the RTL simulation is performed using the RTL description (step S4). . As a result, it is confirmed whether there is an assertion violation.

  FIG. 16 is a diagram showing a time chart when the RTL simulation of the LSI shown in FIG. 15 is executed. As shown in FIG. 16, in this RTL simulation, the generation of the bus transaction ETR2 is different from that in the operation simulation of step S1 shown in FIG.

  That is, in the operation simulation of step S1, the bus transaction ETR2 occurs at time [T2], whereas in the RTL simulation of step S4, it occurs at time [T2 + 3]. For this reason, the assertion modules A1-ETR1 and A1-ETR3 do not output an error message, but the assertion modules A1-ETR2 output an error message because no bus request has occurred at time [T2].

  As described above, according to the LSI design verification apparatus and the LSI design verification method of the first embodiment, for each bus transaction that occurs at different times, in the middle of the RTL simulation or in the LSI circuit to be verified Thus, it is possible to verify whether the result of the upper-level operation simulation matches the result of the lower-level RTL simulation.

  For this reason, since it is possible to detect design defects that have been difficult to detect in the past, it is possible to improve the completeness in the detailed design (RTL design), and to improve the completeness of the LSI design at an early stage.

  Next, in the LSI design verification method shown in FIG. 12, an example in which the same assertion means as the assertion means shown in FIG. 6 is used will be described. FIG. 17 is a diagram showing another example of assertion check means created in the LSI design verification method according to the first embodiment.

  The assertion check unit shown in FIG. 17 checks that the address space of the transfer destination is updated when a certain time has elapsed after the bus request is generated, similarly to the assertion check unit shown in FIG. The assertion check means shown in FIG. 17 includes an assertion module A3-ETR2, and has a structure ETR2 described based on the transaction information ETR2.

  In the structure ETR2, a bus request ID, a bus request time, a target address, an update time, and update data are set. Also in the assertion modules A3-ETR2, the elapse of a certain time after the bus request output is determined by the constant Delay, as in the assertion module A3 shown in FIG. In the example of FIG. 17, the constant Delay is set to unit time 10.

  As shown in FIG. 15, the assertion check module A3-ETR2 is incorporated in an LSI block to be verified. A time chart obtained as a result of the execution of the RTL simulation is shown in FIG. FIG. 18 is a diagram showing a time chart when the RTL simulation is executed by incorporating the assertion check means shown in FIG.

  FIG. 18 shows the transactions ETR1, ETR2, and ETR3 generated by the bus request 1 or 2, the value of the variable time of the assertion modules A3-ETR2, and whether or not an error message has occurred.

  As shown in FIG. 18, the data at the address 1024 is updated when the unit time 5 elapses from the time when the bus request 1 occurs at time T2 + 3, and the data at the address 1028 is updated when the unit time 9 elapses. Yes. For this reason, in the example of FIG. 18, at time T2 + 10 when the value of the variable time becomes 1, the assertion module A3-ETR2 does not output an error message.

  As described above, in the example shown in FIGS. 17 and 18, it is possible to confirm whether the execution of the transaction and the update of the storage area are correctly performed in the middle of the RTL simulation. For this reason, also in the examples shown in FIGS. 17 and 18, since it is possible to detect design defects that were difficult to detect in the prior art, it is possible to improve the completeness in the detailed design (RTL design).

  In the first embodiment, an example in which the assertion check means of the type shown in FIGS. 4 and 6 is incorporated in the RTL description is shown. For example, the assertion check means of the type shown in FIG. 5 (FIG. 8). Even in the case of using the assertion check means shown in FIG. 17, as in the example shown in FIGS. 17 and 18, in the middle of the RTL simulation, transaction execution and storage area update are performed. You can check whether it is done correctly.

  Further, when the assertion check means shown in FIG. 7 is used, since the assertion can include an operation condition in a predetermined time zone based on the bus request time, the timing within an allowable range can be included. It is possible to prevent an error from being output for the deviation. Therefore, in this case, generation of unnecessary pseudo errors and generation of unnecessary analysis man-hours can be suppressed.

  The LSI design verification apparatus according to the first embodiment can also be realized by installing a program for realizing steps S1 to S4 shown in FIG. 12 on a computer and executing the program. .

  In this case, a central processing unit (CPU) of the computer functions as the first simulation unit 2, the operation history extraction unit 3, the assertion check means generation unit 4, and the second simulation unit 5 to perform processing. Note that these units may be realized by separate computers.

(Embodiment 2)
Next, an LSI design verification apparatus and an LSI design verification method according to the second embodiment of the present invention will be described with reference to FIGS.

  First, the configuration of the LSI design verification apparatus according to the second embodiment will be described. The LSI design verification apparatus according to the second embodiment is configured similarly to the LSI design verification apparatus according to the first embodiment shown in FIG. 1, and includes a first simulation unit, an operation history extraction unit, and an assertion check means generation unit. And a second simulation unit (see FIG. 1).

  However, unlike the LSI design verification apparatus in the first embodiment, the LSI design verification apparatus in the second embodiment generates assertion check means based on the history of the CPU model program counter in the operation simulation.

  For this reason, in particular, in the second embodiment, the function of the operation history extraction unit is different from that in the first embodiment. In the second embodiment, the operation history extraction unit extracts the operation history of the CPU model based on the change of the program counter of the CPU model generated in the operation simulation.

  Specifically, in the second embodiment, the operation history extraction unit is configured to set a preset instruction address, an instruction jump destination address, and a subroutine based on a software compilation result of a program executed in the CPU model. A start address, a task start address, a thread start address, a process start address, and the like are extracted as program address information.

  Further, the operation history extraction unit extracts the operation history (CPU operation information) of the CPU model when the CPU model program counter indicates the extracted address in the operation simulation by the first simulation unit.

  The CPU model operation history (CPU operation information) includes, for example, a CPU model program counter change history (program counter value, change time, etc.) in the operation simulation, and a signal output from the CPU model when the program counter is changed. Output history, update history (update time, update data, etc.) of the storage area (address space) used in association with the change of the program counter. A specific example of the operation history (CPU operation information) of the CPU model will be described later.

  Next, an LSI design verification method according to the second embodiment will be described with reference to FIGS. However, the LSI design verification method according to the second embodiment is also implemented by operating the LSI design verification apparatus according to the second embodiment, similarly to the LSI design verification method according to the first embodiment. Therefore, also in the second embodiment, the LSI design verification method will be described by explaining the operation of the LSI design verification apparatus.

  FIG. 19 is a flowchart showing operations of the LSI design verification method according to the second embodiment of the present invention and the LSI design verification apparatus according to the second embodiment. As shown in FIG. 19, first, the operation history extracting unit extracts program address information based on the software compilation result of the program executed in the CPU model (step S11).

  Next, the behavior model of the LSI including the CPU model is read from the behavior description by the first simulation unit, and the behavior simulation is performed (step S12). At this time, in the first simulation unit, the CPU model program counter, the signal output from the CPU model when the program counter is changed, and the storage area (address space) used when the program counter is changed The value is observed and the observation result is stored.

  Next, when the operation history extraction unit determines whether the program counter of the CPU model points to the address extracted in step S11 in the operation simulation by the first simulation unit, and points to the extracted address Extracts CPU operation information (step S13).

  FIG. 20 is a diagram showing a configuration of CPU operation information extracted in the second embodiment. As shown in FIG. 20, in the second embodiment, the CPU operation information includes the CPU model program counter value, its change time, observation period, and the output of the signal output from the CPU model as the program counter changes. It is composed of a signal name / address as a history, an update time and an update value / update data as an update history of the address space used in association with the change of the program counter. The observation period is a period for observing the change of the signal and the address space, and is set in advance.

  Thereafter, the assertion check means generation unit generates assertion check means (step S14). Similarly to the first embodiment, the assertion check means in the second embodiment is a program module described as one circuit module using HDL such as Verilog language.

  Further, the basic configuration of the assertion check means in the second embodiment is the same as that shown in FIG. 3 in the first embodiment. The generated assertion check means is incorporated into the RTL description by the assertion check means generation unit.

  FIG. 21 is a diagram illustrating an example of an assertion check unit and an example of CPU operation information according to the second embodiment. FIG. 21 shows the state of the CPU model in the RTL simulation after a preset time has elapsed after the value of the CPU model program counter in the RTL simulation has reached the value of the CPU model program counter in the operation simulation. An example of an assertion check unit is shown in which the address space used when the program counter is the above value is updated with data updated with the contents of the CPU operation information.

  In the example of FIG. 21, the assertion check means is composed of an assertion module AP and is described based on CPU operation information. The assertion module AP has CPU operation information as a structure, and is output from the CPU model as the program counter value and program counter are changed in the RTL simulation by the input variables PC, sig [], and mem []. The signal name / address of the received signal and the update value / update data of the address space used in accordance with the change of the program counter are referred to.

  The assertion module AP uses a static variable time in order to count the passage of time in the RTL simulation. First, when the simulation time of the RTL simulation (returned by the TIME () function) coincides with the change time of the CPU operation information, the assertion module AP compares the value of the variable PC with the program counter value of the CPU operation information. The assertion module AP then outputs an error message if these values do not match.

  On the other hand, if these values match, the CPU operation information observation period +1 is set to the static variable time, and the value of the time variable decremented after the observation period has elapsed, that is, with the lapse of the simulation time. When the value becomes 1, the search is performed for update values / update data for all signal names / addresses included in the CPU operation information. As a result of the search, if the searched value and the corresponding update data value in the operation simulation are not the same value, an error message is output.

  Next, the RTL description in which the assertion check module AP is incorporated is read out by the second simulation unit, and an RTL simulation is performed using the RTL description (step S15). As a result, it is confirmed whether there is an assertion violation. This RTL simulation is performed using the same pattern as the higher-level operation simulation, as in the first embodiment.

  As described above, in the LSI design verification apparatus and the LSI design verification method according to the second embodiment, as in the first embodiment, the design is performed in the middle of the RTL simulation or inside the LSI circuit to be verified. It is possible to verify whether the result of the upper operation simulation matches the result of the RTL simulation lower than the design. For this reason, since it is possible to detect design defects that have been difficult to detect in the past, it is possible to improve the completeness in the detailed design (RTL design), and to improve the completeness of the LSI design at an early stage.

  In the second embodiment, the start address of each task of software that performs multitask operation is extracted as CPU operation information, and an assertion check can be performed based on the CPU operation information. In this case, it is possible to verify whether a task change has occurred in both the operation simulation and the RTL simulation.

  Furthermore, in the second embodiment, when the program executed in the CPU model is a program that accesses the outside and enters an interrupt wait state, the program counter value when the external access instruction address is pointed and its execution It can be set as the aspect which extracts time as CPU operation information. In this aspect, since the RTL simulation can be verified using the generation of an interrupt signal generated within a certain period as an assertion check, the accuracy of the operation in the detailed design can be easily confirmed.

It is a figure which shows schematic structure of the LSI design verification apparatus in Embodiment 1 of this invention. 6 is a diagram illustrating an example of bus transaction information extracted in the first embodiment. FIG. FIG. 3 is a diagram schematically showing a basic configuration of assertion check means in the first embodiment. It is a figure which shows an example of the assertion check means in Embodiment 1, and an example of bus transaction information. It is a figure which shows the other example of the assertion check means in Embodiment 1, and the other example of bus transaction information. It is a figure which shows the other example of the assertion check means in Embodiment 1, and the other example of bus transaction information. It is a figure which shows the other example of the assertion check means in Embodiment 1, and the other example of bus transaction information. It is a figure which shows the specific example of the assertion check means by which the efficiency of the simulation process was achieved with respect to the assertion check means shown in FIG. 3 is a block diagram showing a configuration of an LSI to be verified in the first embodiment. FIG. 10 is a time chart showing generation of bus requests and transactions in the LSI shown in FIG. 9. FIG. 10 is a diagram showing a list of transactions generated in the LSI shown in FIG. 9. It is a flowchart which shows operation | movement of the LSI design verification method in Embodiment 1 of this invention, and the LSI design verification apparatus in this Embodiment 1. FIG. 14 is a diagram showing bus transaction information extracted by the LSI design verification method in the first embodiment, and FIGS. 13A to 13C each show bus transaction information for each bus request having a different bus request time. ing. 5 is a diagram illustrating an example of an assertion check unit created by the LSI design verification method according to Embodiment 1. FIG. It is a block diagram which shows LSI shown by the RTL description in which the assertion check means was incorporated. FIG. 16 is a diagram showing a time chart when an RTL simulation of the LSI shown in FIG. 15 is executed. It is a figure which shows the other example of the assertion check means produced in the LSI design verification method in this Embodiment 1. FIG. It is a figure which shows the time chart at the time of incorporating the assertion check means shown in FIG. 17, and performing RTL simulation. It is a flowchart which shows operation | movement of the LSI design verification method in Embodiment 2 of this invention, and the LSI design verification apparatus in this Embodiment 2. FIG. 10 is a diagram illustrating a configuration of CPU operation information extracted in the second embodiment. It is a figure which shows an example of the assertion check means in Embodiment 2, and an example of CPU operation information.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 LSI design verification apparatus 2 1st simulation part 3 Operation | movement history extraction part 4 Assertion check means production | generation part 5 2nd simulation part 6 Operation | movement description 7 RTL description 11 CPU
12 DMAC
13 Bus controller 14 Buffer
15 Memory
16 Bus Request Signal Route 17 System Bus

Claims (23)

An LSI design verification method for performing system architecture design verification and detailed design verification of the LSI in LSI design,
(A) performing a system architecture design verification of the LSI by performing an operation simulation of the system operation model of the LSI created in advance;
(B) extracting an operation history of the LSI simulated in the operation simulation;
(C) generating an assertion check means for monitoring whether the operation of the LSI simulated in the detailed design verification simulation of the LSI corresponds to the operation of the extracted operation history;
(D) An LSI design verification method comprising at least a step of performing a detailed design verification by performing a simulation using the assertion check means.   2. In the step (b), as the operation history, an output history of signals on the LSI obtained from the operation simulation and an update history of storage areas on the LSI obtained from the operation simulation are extracted. The LSI design verification method described. In the step (c),
Assertion check means for asserting that the signal on the LSI obtained from the simulation of the detailed design verification is output at the time when the signal on the LSI obtained from the corresponding operation simulation is output. The LSI design verification method according to claim 2, which is generated. In the step (c),
The signal on the LSI obtained from the simulation of the detailed design verification was output in a time zone range based on the output time of the signal on the LSI obtained from the corresponding operation simulation. 3. The LSI design verification method according to claim 2, wherein assertion check means using the assertion is generated. In the step (c),
The storage area on the LSI obtained from the simulation of the detailed design verification is updated with the contents of the update history at the time when the data update in the storage area on the LSI obtained from the corresponding operation simulation occurs. 3. The LSI design verification method according to claim 2, wherein assertion check means for generating the assertion is generated. In the step (c),
The storage area on the LSI obtained from the simulation of the detailed design verification is in a time zone range based on the time when the data update occurred in the storage area on the LSI obtained from the corresponding operation simulation. 3. The LSI design verification method according to claim 2, wherein assertion check means for generating an assertion that data has been updated with the content of the update history is generated. In the operation simulation in the step (a), the data update of the storage area is performed starting from the output of the signal,
In the step (c),
After the output time of the signal, the storage area on the LSI obtained from the detailed design verification simulation is the starting point of the data update in the corresponding storage area on the LSI obtained from the operation simulation. 3. The LSI design verification method according to claim 2, wherein assertion check means for generating an assertion that data has been updated with the content of the update history is generated before a preset time elapses. In the step (c),
Assertion check means for determining the presence or absence of the data change is generated based on event information indicating the presence or absence of the data change in the storage area on the LSI obtained from the operation simulation,
The assertion check means, when the data change of the storage area on the LSI obtained from the operation simulation has been performed, the storage area on the LSI obtained from the simulation of the detailed design verification corresponding thereto 3. The LSI design verification method according to claim 2, wherein an assertion is that the update history is updated. In the step (a), the operation simulation is performed in units of bus transactions,
2. The LSI design verification method according to claim 1, wherein in the step (b), the operation history is extracted for each bus transaction. In the step (b),
10. The output history of the bus request signal on the LSI obtained from the operation simulation and the update history of the address space accessed in the operation simulation are extracted as the operation history in units of the bus transaction. LSI design verification method. In the step (c),
Assertion that the bus request signal on the LSI obtained from the detailed design verification simulation is output at the time when the bus request signal on the LSI obtained from the corresponding operation simulation is output. 11. The LSI design verification method according to claim 10, wherein assertion check means is generated. In the step (c),
The bus request signal on the LSI obtained from the simulation of the detailed design verification is in a time zone range based on the output time of the bus request signal on the LSI obtained from the corresponding operation simulation. 11. The LSI design verification method according to claim 10, wherein assertion check means for generating an assertion based on the output is generated. In the step (c),
Assertion that the address space accessed in the detailed design verification simulation has been updated with the contents of the update history at the time when the data update of the address space extracted from the operation simulation corresponding thereto has occurred. 11. The LSI design verification method according to claim 10, wherein assertion check means is generated. In the step (c),
The address space accessed in the detailed design verification simulation is in the range of the time zone based on the time when the data update of the address space extracted from the corresponding operation simulation occurred, and the contents of the update history 11. The LSI design verification method according to claim 10, wherein assertion check means for generating an assertion that data has been updated is generated. In the operation simulation in the step (a), the data update in the address space is performed starting from the output of the bus request signal,
In the step (c),
The address space accessed in the detailed design verification simulation is after the output time of the bus request signal that is the starting point of the data update in the address space extracted from the corresponding operation simulation, 11. The LSI design verification method according to claim 10, wherein assertion check means for generating an assertion that data has been updated with the content of the update history is generated before a preset time elapses. In the step (c),
Assertion check means for determining the presence or absence of the data change is generated based on event information indicating the presence or absence of the data change in the address space accessed in the operation simulation,
When the data change of the address space accessed in the operation simulation has been performed, the assertion check means includes the address space accessed in the detailed design verification simulation corresponding to the content of the update history. 11. The LSI design verification method according to claim 10, wherein the assertion is that the update is performed in step (a). The system operation model includes a CPU model;
2. The LSI design verification method according to claim 1, wherein in the step (b), an operation history of a CPU model in the operation simulation is extracted as the operation history.   18. The LSI design verification method according to claim 17, wherein an operation history of the CPU model is extracted based on a change in a program counter of the CPU model generated in the operation simulation.   The CPU model program counter extracts the instruction address extracted when the program executed in the CPU model is compiled, the instruction jump destination address, the subroutine start address, the task start address, the thread start address, 19. The LSI design verification method according to claim 18, wherein an operation history of the CPU model is extracted when pointing to at least one of a process start address. The operation history of the CPU model is a change history of the program counter of the CPU model in the operation simulation and an output history of a signal output accompanying the change of the program counter,
In the step (c),
After the value of the CPU model program counter in the detailed design verification simulation becomes the value of the CPU model program counter in the operation simulation, the CPU model program counter in the detailed design verification simulation is the value. 19. The LSI design verification method according to claim 18, wherein assertion check means is generated that asserts that the output signal is output with the content of the output history. The operation history of the CPU model is a change history of the program counter of the CPU model in the operation simulation and an update history of the storage area used in association with the change of the program counter,
In the step (c),
After the value of the CPU model program counter in the detailed design verification simulation becomes the value of the CPU model program counter in the operation simulation, when the preset time elapses, the detailed design verification simulation 19. The LSI design verification method according to claim 18, wherein an assertion check means is generated that asserts that the storage area used when the CPU model program counter is the value is updated with the contents of the update history. . An LSI design verification apparatus for performing system architecture design verification and detailed design verification of the LSI in LSI design,
A first simulation unit that performs system architecture design verification of the LSI by performing an operation simulation of the system operation model of the LSI created in advance;
An operation history extraction unit that extracts an operation history of the LSI simulated in the operation simulation;
An assertion check means generating section for generating an assertion check means for monitoring whether the operation of the LSI simulated in the detailed design verification simulation of the LSI corresponds to the operation of the extracted operation history;
An LSI design verification apparatus comprising at least a second simulation unit that performs a detailed design verification by performing a simulation using the assertion check means. A program for causing a computer to perform system architecture design verification and detailed design verification of the LSI in designing the LSI,
(A) performing a system architecture design verification of the LSI by performing an operation simulation of a system operation model of the LSI created in advance;
(B) extracting an operation history of the LSI simulated in the operation simulation;
(C) generating an assertion check means for monitoring whether or not the operation of the LSI simulated in the detailed design verification simulation of the LSI corresponds to the operation of the extracted operation history;
(D) A program that includes a command that causes the computer to execute a step of performing a detailed design verification by performing a simulation using the assertion check means.

Images