WO2006003702A1 - 検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体 - Google Patents

検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体 Download PDF

Info

Publication number
WO2006003702A1
WO2006003702A1 PCT/JP2004/009340 JP2004009340W WO2006003702A1 WO 2006003702 A1 WO2006003702 A1 WO 2006003702A1 JP 2004009340 W JP2004009340 W JP 2004009340W WO 2006003702 A1 WO2006003702 A1 WO 2006003702A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
verification
generated
functional
software
Prior art date
Application number
PCT/JP2004/009340
Other languages
English (en)
French (fr)
Inventor
Qiang Zhu
Original Assignee
Fujitsu Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Limited filed Critical Fujitsu Limited
Priority to CNA2004800435084A priority Critical patent/CN1981288A/zh
Priority to PCT/JP2004/009340 priority patent/WO2006003702A1/ja
Priority to JP2006527616A priority patent/JPWO2006003702A1/ja
Priority to EP04746809A priority patent/EP1770562A4/en
Publication of WO2006003702A1 publication Critical patent/WO2006003702A1/ja
Priority to US11/645,715 priority patent/US7640521B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking

Definitions

  • Verification support device verification support method, verification support program, and recording medium
  • the present invention relates to a verification support apparatus, a verification support method, a verification support program, and a recording medium that support LSI verification.
  • SoCs system “on” chips
  • FIG. 38 is a flowchart showing a conventional LSI development processing procedure.
  • step S3801—step S38 05 is a design flow for designing LSI
  • step S3806—step S3809 is a verification flow for verifying the designed LSI.
  • step S3801 conceptual design is performed in step S3801.
  • a designer creates a requirement specification 3810 in natural language based on a design request from a customer.
  • a requirement specification 3810 written in a natural language is received from a customer.
  • step S3802 functional design is performed.
  • the LSI to be designed is divided into functional blocks from the contents described in the requirement specification 3810, and a functional specification 3820 describing the contents of each functional block is created.
  • step S3803 a structural design is performed.
  • hardware design is performed from the functional specification 3820 to create the structural specification 3830. Specifically Is to design what kind of architecture can be used to realize the functions described in the functional specification 3820.
  • the architecture of a certain functional block is realized by software, and the architecture of a certain functional block is realized by purchasing IP (Intellectual Property).
  • IP Intelligent Property
  • the architecture of the block is created by the designer, and the architecture of a certain functional block is realized by the underbus.
  • step S3804 unit design is performed.
  • unit design a unit specification 3840 is created by dividing each hardware module described in the structural specification 3830 into multiple modules and designing in detail.
  • step S3805 mounting is performed.
  • RTL Registered Transfer Level
  • HDL Hard Descripti on Language
  • step S3806 unit verification is performed.
  • unit verification according to unit verification item 3860, verification of unit specification 3840 for each unit designed by unit design, that is, debugging is performed.
  • step S3807 joint verification is performed.
  • the interface of each unit verified by unit verification is combined according to combined verification item 3870 to verify whether it operates normally.
  • step S3808 functional verification is performed.
  • functional verification verify whether the functional requirements of the system to be designed are satisfied according to functional verification item 3880.
  • step S3809 actual machine verification is performed.
  • LSI is actually mounted on the chip using RTL3850, and it is verified whether it actually operates. It is determined whether the requirement specification 3810 from the customer satisfies the requirement verification item 3890.
  • step S3805 if the implementation (step S3805) is not performed, the LSI verification (steps S3806 S3809) cannot be performed.
  • VCS simulation speed
  • NC_Sim NC_Sim and other EDA vendor tools
  • the present invention has been made in view of the above problems, and a verification support apparatus capable of easily and efficiently realizing improvement of LSI design accuracy and shortening of a verification period.
  • An object is to provide a support method, a verification support program, and a recording medium on which the program is recorded.
  • the verification support apparatus, the verification support method, the verification support program, and the recording medium on which the program is recorded are analyzed for the required specifications related to the design target of the LSI.
  • Input analysis information indicating the result, and based on the input analysis information, the basic function of the design object is modeled, and the concept of the physical architecture and time of the design object is abstracted
  • Generate and enter Based on the analyzed information, a function model is generated by dividing the modules constituting the design object and extracting the parallel or parallelism of the divided modules, and the generated function model
  • it is characterized by verifying, based on the generated conceptual model, whether the module constituting the design object is divided and whether the parallel or parallelism of the divided modules is valid.
  • information regarding a plurality of types of physical architectures also extracts information regarding an arbitrary architecture, and information regarding the extracted architecture is By mapping to a functional model that has been verified to be valid, an operation model that models the operation of the design object is generated, and a module that configures the design object modeled by the generated operation model It is characterized by verifying whether it is valid.
  • the module when it is verified that the operation model is valid, the module is located at a place where the abstraction level between modules constituting the design object modeled by the functional model is different.
  • An ICA model is generated by inserting an interface with a predetermined clock cycle accuracy between them, and whether the clock cycle accuracy of the interface inserted in the generated ICA model is valid is determined in the generated conceptual model. It is characterized by verifying based on.
  • the software modeled to include a task executable by software based on the design object modeled by the functional model A feature is that a model is generated, and whether or not the task included in the generated software model is valid is verified based on the generated conceptual model.
  • the verification support apparatus by introducing verification step by step, it is possible to design a problem that could not be found without generating an RTL until now.
  • the risk can be avoided by removing it at an early stage. Therefore, it is possible to improve the LSI design accuracy and shorten the verification period easily and efficiently.
  • FIG. 1 is a conceptual diagram of verification support that works on an embodiment of the present invention.
  • FIG. 2 is a graph showing the abstraction level of each model shown in FIG.
  • FIG. 3 is a block diagram showing a hardware configuration of a verification support apparatus according to an embodiment of the present invention.
  • FIG. 4 is a block diagram showing a functional configuration of a verification support apparatus according to an embodiment of the present invention.
  • FIG. 5 is a flowchart showing a verification support processing procedure of the verification support apparatus according to the embodiment of the present invention.
  • FIG. 6 is a block diagram showing a hardware configuration of a system LSI including a design object that is relevant to the embodiment of the present invention.
  • FIG. 7 is an explanatory diagram showing specifications of a bus that is an interface of an external device (timing chart at the time of writing).
  • FIG. 8 is an explanatory diagram showing specifications of a bus that is an interface of an external device (timing chart at the time of reading).
  • FIG. 9 is an explanatory diagram showing specifications of a transmitter that is an interface of an external device.
  • FIG. 10 is an explanatory diagram showing specifications of a receiver that is an interface of an external device.
  • FIG. 11 is an explanatory diagram showing a configuration of a packet transmitted / received by a CPU.
  • FIG. 12 is an explanatory diagram showing a configuration of a transmission packet.
  • FIG. 13 is an explanatory diagram showing a request item list of a system LSI which is a request definition.
  • FIG. 14 is a use case diagram of a system LSI that is a requirement definition.
  • FIG. 15 is an analysis class diagram of a system LSI that is a result of a requirement definition.
  • FIG. 16 is a sequence diagram of a system LSI that is a result of a requirement definition.
  • FIG. 17 is a design class diagram of a system LSI including a serial transmission / reception system.
  • FIG. 18 is an explanatory diagram showing the implementation code of the conceptual model.
  • FIG. 19 is an explanatory diagram showing verification items of a system LSI including a serial transmission / reception system.
  • FIG. 20 is an explanatory diagram showing a verification scenario of a system LSI including a serial transmission / reception system.
  • Ser 21 This is a flowchart showing the implementation code generation processing procedure for the functional model of the system LSI including the serial transmission / reception system.
  • FIG. 18 is an explanatory diagram showing a divided design class diagram obtained by dividing the design class diagram shown in FIG.
  • FIG. 23 is an explanatory diagram showing a communication path for connecting modules represented by a divided design class diagram.
  • FIG. 24 is an explanatory diagram showing an example of generating an implementation code of a function model of a system LSI including a serial transmission / reception system.
  • FIG. 25 is an explanatory diagram showing an example of a class diagram of an architecture model of a system LSI including a serial transmission / reception system.
  • G-26 It is an explanatory diagram showing the mapping between the functional model and the architecture model.
  • FIG. 27 is a flowchart showing an implementation code generation processing procedure for an operation model of a system LSI including a serial transmission / reception system.
  • FIG. 29 is an explanatory diagram showing an example of adding the estimated processing time of each module to the implementation code.
  • FIG. 32 is a structural diagram in which an interface wrapper is inserted into the communication path in the structural diagram shown in FIG.
  • FIG. 33 is an explanatory diagram showing an example of the internal structure of an encoder module of an ICA model.
  • FIG. 34 is an explanatory diagram showing an example of an implementation code of an encoder module of an ICA model
  • FIG. 35 is a flowchart showing an implementation code generation processing procedure of a software model of a system LSI including a serial transmission / reception system.
  • FIG. 36 is an explanatory diagram showing an example in which a part of the function model is mapped to the architecture model by software.
  • FIG. 1 is a conceptual diagram of verification support that works on the embodiment of the present invention.
  • the designer performs object-oriented analysis using UML (Unified Modeling Language) on the required specifications 100 from the system LSI customer including the design object, and models the analysis result as a conceptual model 101.
  • UML Unified Modeling Language
  • the conceptual model 101 is a model that represents a conceptual analysis result of a design target.
  • the conceptual model 101 is a model that is completely independent of implementation. Specifically, the concept of physical architecture and time is abstracted and modeled around the basic functions of the design target.
  • the conceptual model 101 is a result of modeling the analysis results of system LSI requirement specifications using UML or C ++, and includes all of the UML model, C ++ model, and verification scenario. It is a generic name. In this conceptual model 101, misunderstandings and mistakes in the requirement specification 100, or verification of the algorithm can be performed.
  • the functional model 102 is a model constructed by extracting, from the conceptual model 101, the division of the modules constituting the system LSI that is the design target, and the parallelism or parallelism of the divided modules. .
  • the functional model 102 has no concept of time. With this functional model, it is possible to verify the correctness of module division, parallelism I, and the accuracy of concurrency.
  • the architecture model 103 is a model representing physical hardware components of an existing design such as a bus or IP (Intellectual Property). Specifically, the architecture model 103 is roughly divided into processing resources and communication resources.
  • the processing resource is a model for mapping the function model 102 module. For example, hardware processing module, processor, RT ⁇ S, DSP, etc.
  • the communication resource is a model obtained by modeling a channel for realizing communication between modules of the function model. For example, signal lines between buses, memories, and hardware modules. Since this architecture model 103 uses physical hardware parts of an existing design, it is not necessary to perform verification.
  • the operation model 104 is a result of conceptually mapping the function model 102 to the architecture model 103. Specifically, the process of the function model 102 is mapped to the processing resource of the architecture model 103, and the communication channel of the function is assembled using the communication resource. In this behavior model 104, it is possible to verify whether or not the behavior (performance) requested by the customer is satisfied.
  • the operation model 104 is divided into HWZSWs, and an ICA (Interface Cycle Accurate) model 105 representing hardware implementation and a software model 106 representing software implementation are generated.
  • ICA Interface Cycle Accurate
  • the ICA model 105 is a model constructed by the cycle accuracy for the interface outside the module and the operation level inside the module.
  • An RTL description 107 is generated by high-level synthesis of the ICA model 105.
  • the ICA model 105 can verify the accuracy of the interface.
  • the software model 106 is a model that divides the tasks of the software that configures the system LSI including the design target and executes it on the virtual OS. By executing code generation processing for the software model 106, the implementation code 108 is generated. In this software model 106, the function of the software can be verified.
  • Fig. 2 is a graph showing the abstraction level of each model 101-106 shown in Fig. 1.
  • the graph in Fig. 2 consists of three axes centered on the origin. Each axis represents the abstraction level of “function”, the abstraction level of “structure”, and the abstraction level of “time”, and the abstraction level increases as the distance from the origin increases.
  • FIG. 3 is a block diagram showing the hardware configuration of the verification support apparatus which is particularly useful for the embodiment of the present invention.
  • the verification support apparatus includes a CPU 301, a ROM 302, a RAM 303, an HDD (hard disk drive) 304, an HD (node disk) 305, and an FDD (flexible disk).
  • a CPU 301 central processing unit 301
  • ROM 302 read-only memory
  • RAM 303 random access memory 303
  • HDD hard disk drive
  • HD node disk
  • FDD flexible disk
  • FD flexible disk
  • display 308 I / F (interface) 309
  • keyboard 310 keyboard 310
  • mouse 311 scanner 312
  • printer And 313 printer And
  • the CPU 301 governs overall control of the verification support apparatus.
  • the ROM 302 takes care of programs such as a boot program.
  • the RAM 303 is used as a work area for the CPU 301.
  • the HDD 304 controls reading / writing of data with respect to the HD 305 according to the control of the CPU 301.
  • the HD 305 stores data written under the control of the HDD 304.
  • the FDD 306 controls reading / writing of data with respect to the FD 307 in accordance with the control of the CPU 301.
  • the FD 307 stores data written under the control of the FDD 306, and causes the verification support apparatus to read data stored in the FD 307.
  • the power of FD307, CD-ROM (CD_R, CD-RW), M0, DVD (Digital Versatile Disk), memory card, etc. may be used.
  • the display 308 displays data such as a document, an image, and function information as well as a cursor, an icon, or a tool box.
  • a CRT, a TFT liquid crystal display, a plasma display, or the like can be adopted.
  • the I / F 309 is connected to a network such as the Internet through a communication line, and is connected to another device through this network.
  • the I / F 309 controls a network and an internal interface, and controls data input / output from an external device.
  • a modem or a LAN adapter can be used as the I / F 309.
  • the keyboard 310 includes keys for inputting characters, numbers, various instructions, and the like, and inputs data. It can also be a touch panel input pad or numeric keypad.
  • the mouse 311 is used to move the cursor, select a range, move the window, and change the size. If it has the same function as a pointing device, it can be a trackball or joystick.
  • the scanner 312 optically reads an image and takes in the image data into the verification support apparatus.
  • the scanner 312 may have an OCR function.
  • the printer 313 Print image data and document data.
  • FIG. 4 is a block diagram showing a functional configuration of the verification support apparatus according to the embodiment of the present invention.
  • the verification support apparatus 400 includes an analysis information input unit 401 and a conceptual model generation unit.
  • the analysis information input unit 401 receives input of information (analysis information) indicating an analysis result of a required specification from a system LSI customer including a design target.
  • the analysis information includes, for example, information that can be read by a computer, such as a use case diagram, a sequence diagram, a class diagram of a design object described in UML, and basic function items required for the design object.
  • the conceptual model generation unit 402 models the basic function of the design target based on the analysis information input by the analysis information input unit 401, and also determines the physical architecture and time of the design target.
  • a conceptual model in which the concept is abstracted, that is, the conceptual model 101 shown in FIG. 1 is generated.
  • the conceptual model generation unit 402 analyzes analysis information such as use case diagrams, and implements the design target implementation code, items to be verified (verification items), and verification by circuit simulation. A verification scenario indicating the processing procedure is generated.
  • the generated implementation code, verification items, and verification scenario are the conceptual model 101 shown in FIG.
  • the function model generation unit 403 extracts the division of the modules constituting the design object and the parallel or parallelism of the divided modules based on the analysis information input by the analysis information input unit 401. By doing so, a modeled functional model is generated. For example, a function that represents the function to be designed based on a class diagram that is analysis information Generate a model.
  • the class diagram input to the conceptual model generation unit 402 is divided into a plurality of functions, and an implementation code is generated for each divided class diagram (divided class diagram).
  • the generated implementation code for each divided class diagram is the function model 102 shown in FIG.
  • the functional model verification unit 404 determines whether the division of the modules constituting the design target and the parallel or parallelism of the divided modules are valid. The verification is performed based on the conceptual model generated by the conceptual model generation unit 402.
  • the simulation result power of the implementation code for each divided class diagram By determining whether the implementation code of the conceptual model matches the simulation result simulated in the verification scenario of the conceptual model, Verify correctness.
  • the simulation result is what kind of output data can be obtained for certain input data.
  • the functional model generation unit 403 corrects the implementation code of the functional model.
  • the architecture information storage unit 405 stores information related to physical hardware components of an existing design such as a bus and IP (Intellectual Property). Specifically, the architecture information storage unit 405 realizes its function by, for example, the ROM 302, RAM 303, HD 305, FD 307, etc. shown in FIG.
  • the architecture information extraction unit 406 extracts the architecture information stored in the architecture information storage unit 405. For processing resources, for example, hardware processing modules, processors, RTOS, and DSP are extracted. On the other hand, for communication resources, signal lines between buses, memories, and hardware modules are extracted.
  • the architecture information power extracted by this architecture information extraction unit 406 corresponds to the architecture model 103 shown in FIG.
  • the behavior model generation unit 407 includes the key extracted by the architecture information extraction unit 406. By mapping the information about the architecture to the function model verified by the function model verification unit 404, an operation model that models the operation of the design object is generated.
  • the functional model 102 is mapped to the architecture model 103 to generate the behavior model 104 to be designed.
  • the process of the function model 102 is mapped to the processing resource of the architecture model 103, and the communication channel of the function is assembled using the communication resource.
  • an implementation code that takes into account the processing time of the module obtained by mapping is generated.
  • the generated implementation code corresponds to the behavior model 104 shown in FIG.
  • the behavior model verification unit 408 verifies whether the operation timing of the module constituting the design target modeled by the behavior model generated by the behavior model generation unit 407 is valid.
  • the simulation result power S of the implementation code generated by the behavior model generation unit 407 whether the implementation code of the conceptual model matches the simulation result simulated in the verification scenario of the conceptual model The validity of the behavior model is verified.
  • the simulation result means what kind of output data can be obtained for a certain input data.
  • the behavior model generation unit 407 modifies the implementation code of the behavior model.
  • the ICA model generation unit 409 includes the module at a place where the abstraction level between the modules constituting the design target modeled by the functional model is different.
  • An ICA model is generated by inserting an interface with a predetermined clock cycle accuracy in between.
  • the operation model 104 is subjected to HW / SW partitioning, and an ICA model 105 representing a hardware implementation is generated.
  • an ICA model 105 representing a hardware implementation is generated. For example, if the abstraction level between modules is different, the module level shown in the class diagram is set so that the abstraction level between the modules is equivalent. Replace the communication path between modules with an interface wrapper.
  • the implementation code of the class diagram replaced with the interface wrapper is generated.
  • the generated implementation code is the ICA model 105 shown in Fig. 1.
  • the RTL description 107 can be generated by high-level synthesis of the implementation code of the ICA model 105.
  • the ICA model verification unit 410 includes an ICA model generated by the ICA model generation unit 409.
  • the result of simulation of the implementation code generated by the ICA model generation unit 409 Determines whether the implementation code of the conceptual model matches the simulation result simulated in the verification scenario of the conceptual model By doing so, the validity of the functional model is verified.
  • the simulation result means what kind of output data can be obtained for a certain input data.
  • the ICA model is valid. Specifically, the interface represented by the replaced interface wrapper is accurate. On the other hand, if there is a mismatch, the replaced interface wrapper will be inaccurate. In this case, the IC A model generation unit 409 corrects the implementation code of the ICA model.
  • the software model generation unit 411 includes a task that can be executed by software based on the design object modeled by the functional model. Generate a modeled software model.
  • the operation model 104 is subjected to HW / SW partitioning to generate a software model 106 (see FIG. 1) representing the software implementation.
  • a software model 106 representing the software implementation.
  • the task that divides the software that constitutes the system LSI including the design object is divided, and the implementation code that can be executed on the virtual S is generated.
  • the software model verification unit 412 determines whether the task power included in the software model generated by the software model generation unit 411 is valid based on the conceptual model generated by the conceptual model generation unit 402. Validate. [0074] Specifically, it is determined whether the simulation result power S of the implementation code generated by the software model generation unit 411 matches the simulation result obtained by simulating the implementation code of the conceptual model in the verification scenario of the conceptual model. To verify the validity of the software model 106.
  • the simulation result means what kind of output data can be obtained with respect to certain input data.
  • the function represented by the implementation code of the software model 106 is valid. Then, the implementation code 108 (see FIG. 1) for the entire design object is generated by incorporating the implementation code of the software model 106. On the other hand, in the case of a mismatch, the function represented by the implementation code of the software model 106 becomes inaccurate. In this case, the software model generation unit 411 corrects the software model implementation code.
  • analysis information input unit 401 the conceptual model generation unit 402, and the functional model generation unit described above.
  • the function is realized by the CPU 301 executing the program recorded in the R0M302, RAM303, HD305, FD307, etc. shown in Fig. 3 or by the I / F309. To do.
  • FIG. 5 is a flowchart showing a verification support processing procedure of the verification support apparatus according to the embodiment of the present invention.
  • the designer analyzes the required specification 100 from the system LSI customer including the design target, and inputs analysis information representing the analysis result (step S501).
  • step S502 based on the input analysis information, conceptual models such as the implementation code of the design object, items to be verified (designation items) for the design object, and verification scenarios that show the verification processing procedure by circuit simulation 101 is generated (step S502). The designer verifies the validity of the generated conceptual model 101.
  • a function demole 102 to be designed is generated (step S503). Specifically, The class diagram input to the justice model generation unit 402 is divided into a plurality of functions for each function, and the implementation code of the function model 102 is generated for each divided class diagram (divided class diagram).
  • step S504 the implementation code of the conceptual model 101 and the implementation code of the functional model 102 are simulated.
  • step S505 it is determined whether the simulation result of the implementation code of the conceptual model 101 matches the simulation result of the implementation code of the functional model 102, that is, the functional model is verified (step S505).
  • step S506 the function model 102 is corrected (step S506). Specifically, for example, the class diagram of the conceptual model 101 is divided again to generate a divided class diagram, and an implementation code is generated for each divided class diagram. Then, the process proceeds to step S5 04.
  • step S505 if they match (step S505: Yes), it is determined that the function model 102 is valid. Then, the architecture model 103 is mapped to the verified function model 102 whose validity has been verified to generate the operation model 104 (step S507). Then, the implementation code of the operation model 104 is simulated (step S508).
  • step S509 it is determined whether the simulation result of the implementation code of the conceptual model 101 and the simulation result of the implementation code of the behavior model 104 match, that is, behavior model verification is performed (step S509).
  • step S510 the behavior model 104 is corrected (step S510). Specifically, for example, the architecture information is extracted again from the architecture information storage unit 405, and the new architecture model 103 is mapped to the verified function model 102 whose validity has been verified. Is generated. Then, the process proceeds to step S5 08.
  • step S509 Yes
  • HWZSW division is performed on the verified operation model 104 whose validity has been verified, and an ICA model 105 and a software model 106 are generated (step S511, step S516).
  • step S512 the generated implementation code of the ICA model 105 is simulated.
  • step S512 the simulation results of the implementation code of conceptual model 101 and the ICA model Judgment is made as to whether the simulation results of the Dell 105 implementation code match, that is, the ICA model is verified.
  • step S513 No
  • the ICA model 105 is corrected (step S514).
  • the ICA model 105 is modified by changing the contents of the interface wrapper. Then, the process proceeds to step S512.
  • step S513 Yes
  • step S513 high-level synthesis is performed (step S515), and an RTL description is generated.
  • step S517 a simulation of the generated implementation code of the software model 106 is performed.
  • step S528 it is determined whether the simulation result of the implementation code of the conceptual model 101 and the simulation result of the implementation code of the software model 106 coincide with each other, that is, software model verification is performed (step S518).
  • step S518 No
  • the software model 106 is corrected (step S518).
  • the software component that constitutes the system LSI including the design target is divided again to generate the implementation code that can be executed on the virtual OS.
  • step S518 Yes
  • step S518 Yes
  • verification is performed step by step for each model. Therefore, a model verified up to immediately before can be used as an effective model without performing verification again. Therefore, no rework occurs in the verification process, and the efficiency of the verification process can be improved.
  • the force to execute the processing procedure j up to step S511 515 and the processing procedure up to step S516 520 in parallel is executed after the processing procedure up to step S511 515.
  • the processing procedure up to steps S516-520 may be executed, and the processing procedure up to steps S511-515 may be executed after the processing procedure up to steps S516-520.
  • FIG. 6 is a block diagram showing a hardware configuration of a system LSI including a design object that is relevant to the embodiment of the present invention.
  • This design object is, for example, information obtained from a customer for design work.
  • the design object is described as a serial transmission / reception system.
  • a system LSI 600 connects a serial transmission / reception system 601, a receiver 602, a transmitter 603, a CPU 604, and other devices 605, which are listed as examples of design objects. And bus 606.
  • the receiver 602 receives the received packet 611 and supplies it to the serial transmission / reception system 601.
  • the transmitter 603 transmits information supplied from the serial transmission / reception system 601 to an external device (not shown) as a transmission packet 612.
  • the serial transmission / reception system 601 performs encoding and decoding with BCH (62, 48).
  • the received packet 611 from the receiver 602 is decoded, and the decoded packet 613 is supplied to the CPU 604. Also, the packet 614 from the CPU 604 is encoded.
  • the CPU 604 executes the function of the system LSI 600 together with the other device 605 using the packet 613 from the serial transmission / reception system 601.
  • FIG. 7 and FIG. 8 are explanatory diagrams showing specifications of a bus that is an interface of an external device.
  • FIG. 7 is a timing chart at the time of writing
  • FIG. 8 is a timing chart at the time of reading.
  • PCLK is an input clock signal having a bit width of 1.
  • PAD DR is an address output signal with a bit width of 32.
  • PWRITE is a read Z write control output signal with a bit width of 1.
  • PSEL is a chip select output signal with a bit width of 1.
  • PENABLE is an output enable signal with a bit width of 1.
  • PRDATA is a data input / output signal having a bit width of 32.
  • FIG. 9 is an explanatory diagram showing specifications of the transmitter 603 that is an interface of the external device.
  • “clk” is an input clock signal having a bit width of 1.
  • “ISTART” is a start pulse input signal with a bit width of 1.
  • IDATA is a data input signal with a bit width of 1.
  • the input specification from the serial transmission / reception system 601 to the transmitter 603 is such that the transmitter 603 captures data one bit at each positive edge of the clock at the same time as detecting the i-clock pulse of the start pulse input signal.
  • the input clock frequency is 100 MHz.
  • FIG. 10 is an explanatory diagram showing the specifications of the receiver 602 that is an interface of the external device.
  • clk is an output clock signal having a bit width of 1.
  • OSTART is a start pulse output signal with a bit width of 1.
  • ⁇ DATA is a data output signal with a bit width of 1.
  • the basic functions required for the serial transmission / reception system 601 are (1) a packet transmission function, (2) a packet reception function, and (3) an initialization function.
  • a packet discard function that notifies the CPU 604 of an error and discards the transmitted packet 612 when the processing is not in time when a large number of packets 614 are continuously transmitted from the CPU 604.
  • a packet discard permission function that allows the received packet 611 to be discarded if a large amount of received packets 611 are sent from the receiver 602 and the processing is not in time.
  • FIG. 11 shows ⁇ ? 11 is an explanatory diagram showing a configuration of packets 613 and 614 transmitted and received by 11604
  • FIG. 12 is an explanatory diagram showing a configuration of a transmission packet 612.
  • packets 613 and 614 are composed of a 16-bit header part 1101 and a 32-bit data part 1102.
  • the header part 1101 is a packet identification number (10101010101010) 2.
  • a transmission packet 612 is a 14-bit redundant code encoded with BCH (62, 48) in the 16-bit header portion 1101 and 32-bit data portion 1102 shown in FIG.
  • the unit 1201 is added.
  • the received packet 611 has a configuration in which an error bit by a communication path is further added to the configuration of the transmission packet 612.
  • the contents of the information shown in FIGS. 6 to 12 are the required specifications 100 required by the customer.
  • FIG. 13 is an explanatory diagram showing a request item list of the system LSI 600 that is a requirement definition
  • FIG. 14 is a use case diagram of the system LSI 600 that is a requirement definition.
  • this system LSI 600 indicates that “maximum double error correction of received packets” (item 1301) and “up to four errors in received packets can be detected.
  • Item 1302 “Received packets can be received via the receiver” (Item 1303), “Received packets can be decoded with BCH (60, 48)” (Item 1304), “Can be initialized from CPU” (Item 1305), “Reset signal power can also be initialized” (Item 1306), “Transmission packet can be transmitted via transmitter” (Item 1307), “Transmission packet is signed with BCH (62, 48)” The function of “I can do it” (item 1308) is required.
  • the use case diagram 1400 shown in FIG. 14 is a diagram describing the functions required by the request item list 1300 shown in FIG. 13, and is described according to UML. .
  • the serial transmission / reception system 601 shown in FIG. 6 has functions “receive packet”, “initialize”, and “transmit packet” represented by use cases 1401-1403.
  • the CPU 1411, the reset signal 1412, the receiver 1413, and the transmitter 1414 are illustrated as actors related to the serial transmission / reception system 601.
  • the use case 1401 receives a packet from the actor 1413.
  • the received packet is transmitted to the actor 1411.
  • Use case 1402 is initialized from actor 1411 and actor 1412.
  • use case 1403 receives an actor 1411 power packet and sends it to actor 1414.
  • FIG. 15 is an analysis class diagram of the system LSI 600 that is a requirement-defined result
  • FIG. 16 is a sequence diagram of the system LSI 600 that is a requirement-defined result.
  • the analysis class diagram 1500 shown in FIG. 15 includes a ⁇ control> class 1501 for managing data procedures necessary for the serial transmission / reception system 601 and processing unique to the system in the serial transmission / reception system 601. Entity> class 1502 1508 is described.
  • the ⁇ control >> class 1501 represents a serious transmission / reception system 601.
  • the ⁇ control >> class 1501 serial transmission / reception system 601 also transmits a packet with the actor 1414 (transmitter 603) power.
  • ⁇ entity >> class 1502 transmission packet 612
  • ⁇ entity >> class 1503 reception packet 611
  • initialization from actor 1412 reset signal
  • a packet is received from the actor 1413 (receiver 602) that received the ⁇ entity> class 1503 (receive packet 611).
  • ⁇ entity >> class 1502 (transmission bucket 612) is ⁇ 6 >> class 1504 (packets 613, 614) and ⁇ entity >> class 1505 (redundant code part) 1201).
  • the ⁇ entity> class 1503 (received packet 611) is a collection of ⁇ 6 >> class 1505 (redundant code part 1201) and ⁇ entity >> class 1506 (error bit).
  • ⁇ 6 >> class 1504 (packets 613, 614) is an aggregation of ⁇ entity >> class 1507 (header part 1101) and ⁇ entity >> class 1508 (data part 1102).
  • sequence diagram 1600 shown in Fig. 16 shows an operation when a packet is normally transmitted.
  • sequence diagram 1600 in order of sequence number, that is, sequence number 1 ⁇ 0 (“create packet ()”) ⁇ sequence number 1.1 (“receive packet 0”), ⁇ sequence number 1 ⁇ 2 (“Sign packet ()”) ⁇ Sequence number 1 ⁇ 3 (“Create transmission packet ()”), Sequence number 1 ⁇ 4 (“Send transmission packet ()”) Indicates that transmission processing is to be performed.
  • FIG. 17 is a design class diagram of a system LSI including a serial transmission / reception system.
  • class 1701 is a class name 1702 in which the name "ECC_SIO" indicating a serial transmission / reception system is described, and an attribute 1703 (member variable) indicating the static properties of class 1701 And an operation 1704 (member function) indicating the dynamic properties of the class 1701. Operation 1704 works with class 1705 indicating CPU and class 1706 indicating sign.
  • the implementation code of the conceptual model 101 is generated.
  • Figure 17 shows the implementation code of Conceptual Model 101. A description example is shown.
  • FIG. 18 is an explanatory diagram showing the implementation code 1800 of the conceptual model 101. This implementation code 1800 is modeled by the C ++ language.
  • FIG. 19 is an explanatory diagram showing verification items of the system LSI including the serial transmission / reception system.
  • the target use case is focused on the use case 1401 shown in FIG.
  • the “basic path” of the item “sequence” indicates normal packet transmission processing, that is, processing up to sequence numbers 1.0 to 1.1 shown in FIG. is doing.
  • FIG. 20 is an explanatory diagram showing a verification scenario of a system LSI including a serial transmission / reception system.
  • This verification scenario 2000 is generated using the sequence diagram 1500 shown in FIG. 15 and the verification item 1900 shown in FIG.
  • the specification error detected by the simulation using the verification scenario 2000 will be described with an example. If a verification result indicating that the CPU is always notified of an error is obtained, the serial transmission / reception system was put into an error state when a packet reception error occurred. A specification error that causes the error state to remain is detected. Therefore, as a correction process, the error status of the serial transmission / reception system is cleared after the CPU receives an error. This eliminates specification errors.
  • FIG. 21 is a flowchart showing the implementation code generation processing procedure of the function model of the system LSI including the serial transmission / reception system.
  • the processing procedure shown in FIG. 21 shows the detailed processing procedure of the processing step shown in step S503 of FIG.
  • FIG. 22 is an explanatory diagram showing a divided design class diagram obtained by dividing the design class diagram shown in FIG.
  • the design class diagram shown in FIG. 17 is related to the split design class diagram 2210 for the top module, the split design class diagram 2220 for the controller module, the split design class diagram 2230 for the encoder module, and the decoder module in FIG. This is divided into the split design class diagram 2240.
  • FIG. 23 is an explanatory diagram showing a communication path that connects modules represented by a divided design class diagram.
  • the top module 2301 f has a port 2311 and 2315.
  • This port 2311 1 2 315 is described in the attribute 2211 of the division design class diagram 2210 for the top module. Specifically, port 2311 indicates “packet_i: sc_fifo_in ⁇ Packet>”, and is an input port for inputting a packet “Packet>” from the CPU.
  • Port 2312 is
  • packet_o sc_fifo_out ⁇ Packet> ”, which is an output port that outputs Packet> to the CPU.
  • Port 2313 indicates “error_o: sc_fifo_out ⁇ ERR_TYPE>”, and is an output port that outputs error type information “ERR_TYPE>” to the CPU.
  • port 231 i “encoded_packet_o: sc_fifo_out ⁇ EncodedPacket>” is shown, which is an output port for outputting an encoded packet.
  • Port 2315 indicates “received_packet_i: sc_fifo_in ⁇ ReceivedPacket>”, and is an input port for inputting a packet KReceivedPacket> received from the outside.
  • the controller module 2302f has ports 2321 and 1327. This port 232 1-1 2327 is described in attribute 2 221 of the divided design class diagram 2220 related to the controller module 2302. Specifically, port 2321 indicates “cpu_packet_i: sc_fifo_in ⁇ Packet>”, and is an input port for inputting a packet “Packet>” from the CPU. Port 23 22 indicates “cpu_packet_o: sc_fifo_out ⁇ packet>”, and is an output port that outputs packet “packet>” to the CPU.
  • Port 2323 indicates “error_o: s fifo_out ⁇ ERR_TYPE>” and is an output port that outputs error type information “ERR_TYPE>” to the CPU.
  • Port 2324 indicates “encoder_packet_o: sc_fifo_out ⁇ Packet>”, and is an output port for outputting the packet “Packet>” to the encoder module.
  • Port 2325 indicates “encoder_status_i: sc_fifo_in ⁇ bool>”, and is an input port for inputting status information “bool>” of the encoder module 2303.
  • Port 2326 indicates “encoder_status_i: sc_fifo_in ⁇ bool>” and is an input port for inputting status information “bool>” of the encoder module 2303.
  • decoder_packet_i sc_fifo_in ⁇ packet> ”, which is an input port for inputting a packet packet> from the decoder module.
  • Port 2327 indicates “decoder_error_i: sc_fifo_in ⁇ ERR_TYPE>” and is an input port for inputting error type information “ERR_TYPE>” from the decoder module.
  • the encoder module 2303f is provided with ports 2331 and 2333.
  • This port 233 1 1 2333 is described in attribute 2 231 of the division design class diagram 2230 for the encoder module 2303.
  • port 2331 indicates “packet_i: sc_fifo_in_if packet>”, and is an input port for inputting packet packet.
  • Port 2332 is
  • EncodedPacket> J which is an output port for outputting the packet KEncodedPacke encoded by the encoder module 2303.
  • the decoder module 2304 has ports 2341 to 2343.
  • the ports 2341 to 2343 are described in the attribute 2241 of the division design class diagram 2240 regarding the decoder module 2304. Specifically, port 2341 indicates “packet_o: sc_fifo_out ⁇ Packet>”, and is an output port that outputs packet ⁇ Packet>.
  • Port 2342 indicates “packet_o: sc_fifo_out ⁇ Packet>”, and is an output port that outputs packet ⁇ Packet>.
  • error_o sc_fifo_out ⁇ ERR_TYPE>
  • ERR_TYPE> is an output port that outputs error type information ERR_TYPE>.
  • Port 2343 indicates “packet_i: sc_fifo_in ⁇ ReceivedPacket>”, and is an input port for inputting a received packet “ReceivedPacket>”.
  • This communication channel 2351-2359f is a communication channel that performs communication using the FIFO method.
  • Step S2103 a function model implementation code is generated ( Step S2103).
  • Step S2103 an example of generating the implementation code of the functional model of the system LSI including the serial transmission / reception system is explained.
  • FIG. 24 is an explanatory diagram showing an example of generating an implementation code of a function model of a system LSI including a serial transmission / reception system.
  • FIG. 24 shows an implementation code 2400 of the encoder module 2303 generated by the split design class diagram 2230 force relating to the encoder module 2303.
  • implementation codes are also generated for the divided design class diagram 2210 for the top module, the divided design class diagram 2220 for the controller module 2302, and the divided design class diagram 2240 for the decoder module 2304, respectively. Then, in step S504 of FIG. 5, the simulation of the implementation code of each divided design class diagram 2210-2240 is executed.
  • step S505 of Fig. 5 the simulation result and the simulation result of the implementation code of the conceptual model are checked for coincidence. If they match (step S505: Yes), The module division shown is valid, and the parallelism and concurrency of the module division are correct.
  • step S505 if they do not match (step S505: No), the module division shown in Fig. 22 is not valid, and it is assumed that the module division parallel IJ and concurrency are incorrect. At this point, the implementation code generated in step S2103 in Fig. 21 is corrected. With this functional model verification, it is possible to confirm that the verification result is the same as that of the conceptual model.
  • FIG. 25 is an explanatory diagram showing an example of a class diagram of a system LSI architecture model including a serial transmission / reception system.
  • the architecture model is a model that represents physical hardware parts of an existing design such as a bus or IP.
  • the bus model is represented.
  • the architecture model is basically prepared in advance and provided as a verified library. In Fig. 25, the verified bus model is described. In this way, this architecture model uses physical hardware parts of an existing design, so There is no need to witness.
  • FIG. 26 is an explanatory diagram showing the mapping between the functional model and the architecture model.
  • the functional model 2600 receives the packet received from the outside, decodes it, and supplies it to the controller 2603.
  • the controller 2 603 outputs the decoded packet to the encoder 2604, and the encoder 2604 encodes the packet.
  • Architecture model 2610 is a model that represents physical hardware components of existing designs such as buses and IP.
  • processor 2611 memory 2612, external input 1 / F2613, external output I / F2614, Hardware 2616, hardware 2616, hardware 2617, and a bus 2618 connecting them.
  • the functional model 2600 is mapped to this architecture model 2610. Specifically, the decoder 2602 is mapped to the hardware 2615, the controller 2603 is mapped to the hardware 2 616, and the encoder 2604 is mapped to the hardware 2617.
  • the contents described with reference to FIG. 25 and FIG. 26 are contents corresponding to the processing step shown in step S507 of FIG.
  • FIG. 27 is a flowchart showing the implementation code generation processing procedure of the operation model of the system LSI including the serial transmission / reception system.
  • the processing procedure shown in FIG. 27 shows the detailed processing procedure of the processing step shown in step S507 of FIG.
  • FIG. 28 is an explanatory diagram showing a divided design class diagram 2210 in which the description in the attribute 2211 is replaced with the description of the bus model.
  • the communication path has been replaced from the FIFO description to the bus model description in the underlined description.
  • a functional model implementation code is generated from the divided design class diagram 2210 2240 replaced with the bus model description (step S2702). Then, the estimated processing time for each module is added to the generated function model implementation code (step S2703).
  • FIG. 29 is an explanatory diagram showing an example of adding the estimated processing time of each module to the implementation code.
  • the estimated processing time of the decoder 2602 and encoder 2 604 is 600 [ns] according to the chart 2900 shown in Fig. 29, the implementation code of the functional model (for example, implementation code 2400 shown in Fig. 24) Add the description 2901 related to processing time shown in Figure 2900.
  • the behavior model mounting code 2902 is generated.
  • step S508 in FIG. 5 a simulation of the behavior model mounting code 2902 is executed.
  • step S508 of Fig. 5 the simulation result and the simulation result of the implementation code of the conceptual model are determined to match. If they match (step S509: Yes), the implementation code of the behavior model 2902 The result of the simulation is that all the required items 1301-1308 in the required item list 1300 shown in Fig. 13 are satisfied, and the mapping between the functional model and the architecture model is valid.
  • step S509 No
  • the simulation result power of the implementation code 2902 of the behavior model All the required items 1301 to 1308 in the required item list 1300 shown in Fig. 13 are satisfied. Therefore, the mapping between the functional model and the architecture model is not correct.
  • step S510 of FIG. 5 the modification processing of the behavior model mounting code 2902 is performed. As a result, it is possible to verify whether or not the operation (performance) requested by the customer is satisfied.
  • FIG. 30 is a flowchart showing the implementation code generation processing procedure of the ICA model of the system LSI including the serial transmission / reception system.
  • the processing procedure shown in FIG. 30 shows the detailed processing procedure of the processing step shown in step S511 of FIG.
  • the ICA model is a model constructed with the cycle accuracy for the interface outside the module and the operation level inside the module. RTL description is generated by high-level synthesis of this ICA model. This ICA model can verify the accuracy of the interface.
  • FIG. 31 is a structural diagram showing a functional model in which a communication path of a system LSI including a serial transmission / reception system is determined.
  • the serial transmission / reception system divides the design class diagram shown in FIG. 17 into parallel and parallel modules (see step S2101 in FIG. 21).
  • This is a system in which a CPU module 3101, a transmitter module 3102, a receiver module 3103 and a power FIFO type communication path 3111-3115 are connected.
  • the inside of the top module 2301 has the same contents as the structural diagram shown in FIG. From the connection relationship of these modules, the communication path that communicates between modules with different abstraction levels is detected.
  • FIG. 32 is a structural diagram in which an interface wrapper is inserted into the communication path in the structural diagram shown in FIG.
  • the communication path 3114 between this module 2302 and 3102 is inserted into the interface wrapper 3201, and the top module Convert the extraction level of Eunoré 2301.
  • the interface wrapper 3201 includes a transaction level interface 3202 connected to the transaction level port 3102a of the transmitter module 3102 and two signal level reports 3203 and 3204 connected to the top module 2301. The this Therefore, the port 2314 of the transaction level is replaced with the transmission level report 3210, 3211.
  • the transaction level ports 2331 and 2333 of the encoder module 2303 inside the top module 2301 can be replaced with the signal level ports 3212 and 3216 ⁇ .
  • the transaction level ports 2 324 and 2325 of the controller module 2302 are also converted to the signal level ports 3217 to 3219 (which are converted).
  • FIG. 33 is an explanatory diagram showing an example of the internal structure of the encoder module of the ICA model.
  • an encoder module 3300 of the ICA model is provided with an encoder 2303 and ports 2331 and 1333 shown in FIG. Then, in order to enable communication between the ports 2331 and 2332 and the ports 3212 to 3214, various wrappers and port force S are inserted. Similarly, various wrappers and ports are inserted to enable communication between the port 2333 and the ports 3215 and 3216.
  • FIG. 34 is an explanatory diagram showing an example of an implementation code of the encoder module 3300 of the ICA model.
  • step S512 of FIG. 5 a simulation of the implementation code 3400 of the ICA model is executed.
  • step S513 in Fig. 5 the simulation result of the implementation code 3400 of the ICA model is matched with the simulation result of the implementation code of the conceptual model. If they match (step S513: Yes), simulation result power S of ICA model implementation code 3400, all requirement items 1301 to 1308 in the requirement item list 1300 shown in Fig. 13 are satisfied, and interface wrapper insertion is valid It will be.
  • Step S513 No
  • the simulation result power of the implementation code 3400 of the ICA model All the required items 1301 to 1308 in the required item list 1300 shown in Fig. 13 are satisfied. Therefore, the interface wrapper is not properly purchased.
  • step S514 shown in Fig. 5 the ICA model implementation code 3400 is modified.
  • the correct process will be performed. As a result, the accuracy of the interface can be verified.
  • FIG. 35 is a flowchart showing the implementation code generation processing procedure of the software model of the system LSI including the serial transmission / reception system.
  • the processing procedure shown in FIG. 35 shows the detailed processing procedure of the processing step shown in step S516 in FIG.
  • the software model is a model that divides the tasks of the software constituting the system LSI including the serial transmission / reception system and executes them on the virtual S.
  • a part of the functional model is first mapped to the architecture model by software (step S 3501).
  • FIG. 36 is an explanatory diagram showing an example in which a part of the function model is mapped to the architecture model by software. Specifically, as shown in FIG. 26, the decoder 2602 maps to the hardware 2615, and the encoder 2604 maps to the hardware 2617. On the other hand, the CPU 2601 and the controller 2603 are mapped to the processor 2611.
  • FIG. 37 is an explanatory diagram showing a design class diagram in the software model.
  • the design class diagram 3700 in the software model is generated based on the divided design class diagram 2210-2240 shown in FIG.
  • the design class diagram 3700 in the software model is divided into the virtual OS model in addition to the split design class diagram 3701 for the top module, the split design class diagram 3702 for the decoder module, and the split design class diagram 3703 for the encoder module. It includes a split design class diagram 3704. Then, a software model implementation code is generated for each design class diagram 3701 3704 (step S3503).
  • step S517 of Fig. 5 simulation of the software model implementation code is performed. -I will execute the Chillon. Then, in step S518 of FIG. 5, a determination is made as to whether the simulation result of the implementation code of the software model matches the simulation result of the implementation code of the conceptual model. If they match (step S518: Yes), the simulation result power S of the software model implementation code S, and all the requirement items 1301 1308 in the requirement item list 1300 shown in FIG. Task division is valid.
  • Step S518 the simulation result power S of the software model implementation code S satisfies all the required items 1301 to 1308 of requirement item ⁇ 1300 shown in Fig. 13. This means that the software task division is not valid.
  • step S519 shown in Fig. 5 the software model implementation code is corrected. In this way, it is possible to verify the accuracy of software task division.
  • specification risk can be avoided at an early stage. Specifically, after analyzing customer requirements with UML, it is possible to verify whether or not the customer's functional requirements are satisfied using an executable model, and it is possible to detect misunderstandings and mistakes of specifications at an early stage. System LSI design based on incorrect specifications can be prevented.
  • the verification support apparatus and the verification support method according to the embodiment of the present invention it is possible to solve the simulation speed bottleneck. Specifically, since the conventional verification method uses an RTL simulator for simulation, the simulation speed is very slow. In this embodiment, simulation is performed using a model with a higher level of abstraction. As a result, the simulation can be executed several hundred times faster than the RTL simulator. Therefore, by improving the simulation speed, the design period including verification work can be shortened.
  • the cost can be reduced.
  • the emulator is used by verifying a model with a high level of abstraction. Drastically reduce the frequency And cost reduction can be achieved.
  • the use of emulators is basically converted into money on an hourly basis, the cost can be reduced by shortening the verification time.
  • Step-by-step verification can be started.
  • the validity of each model can be verified according to the level of detail of the design. In this way, the design process can be significantly shortened compared to the conventional design end ⁇ verification start and check method.
  • system LSI including the serial transmission / reception system has been described as an example.
  • present invention is not limited to this system LSI, and can be applied to various system LSIs. .
  • the verification support method described in this embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer, workstation, or CAD.
  • This program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer.
  • This program is a transmission medium that can be distributed through the network such as the Internet. There may be.
  • the present invention is suitable, for example, for providing a system tool for verifying LSI design data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Design And Manufacture Of Integrated Circuits (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

　検証支援装置（４００）は、概念モデル生成部（４０２）による、顧客の要求仕様に着目した概念モデルを生成することにより、設計の初期段階で仕様のミスや誤解を解消する。また、機能モデル検証部（４０４）による、並列、並行な機能モデルの検証によって、機能モジュール分割の妥当性、並列、並行性の正しさを検証する。また、動作モデル検証部（４０８）による動作モデルの検証によってアーキテクチャの設計の妥当性、性能要件に満足しているかどうかを検証する。また、ＩＣＡモデル検証部（４１０）によってインターフェース設計の正しさを検証する。このように、段階的に検証を導入することによって、これまで、ＲＴＬを生成しないと発見できなかった問題を、設計の早期段階に摘出してそのリスクを回避することができる。

Description

明 細 書
検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体 技術分野
[0001] 本発明は、 LSIの検証を支援する検証支援装置、検証支援方法、検証支援プログ ラムおよび記録媒体に関する。
背景技術
[0002] LSI設計では、 LSIが正常に動作するか否かを検証する検証作業が必要不可欠で あり、特に、大規模化、高機能化、高速化および低消費電力化が要求されている LS Iについては、高品質を維持するためにもこの検証作業は重要である一方、従来から 設計期間の短縮による作業効率化が要求されている。
[0003] 特に、近年は、ソフトウェアとハードウェアが混在しており、従来型の ASICによる単 機能のハードウェアだけではなぐソフトウェアも含めたシステム'オン'チップ（SoC) が主流となっている。また、 MPEGや JPEGなど、本来アプリケーションソフトウェアで 実現される機能がハードウェアで実現するようになっているため、 LSIの機能が複雑 化している。
[0004] ここで、従来の LSIの開発処理について説明する。図 38は、従来の LSIの開発処 理手順を示すフローチャートである。図 38において、ステップ S3801—ステップ S38 05力 LSIの設計をおこなう設計フローであり、ステップ S3806—ステップ S3809力 S 、設計された LSIの検証をおこなう検証フローである。
[0005] まず、設計フローでは、ステップ S3801において、概念設計をおこなう。概念設計 では、顧客からの設計要求に基づいて設計者が要求仕様書 3810を自然言語によつ て作成する。または、顧客から自然言語で記述された要求仕様書 3810を受け取る。
[0006] つぎに、ステップ S3802において、機能設計をおこなう。機能設計では、要求仕様 書 3810に記述された内容から、設計対象となる LSIを機能ブロックごとに分けて、各 機能ブロックの内容を記述した機能仕様書 3820を作成する。
[0007] つぎに、ステップ S3803において、構造設計をおこなう。構造設計では、機能仕様 書 3820からハードウェア設計をおこなって構造仕様書 3830を作成する。具体的に は、どのようなアーキテクチャを導入すれば機能仕様書 3820に記述された機能を実 現できるか、という設計をおこなうことである。
[0008] たとえば、各機能ブロックのうち、ある機能ブロックのアーキテクチャについてはソフ トウエアによって実現し、ある機能ブロックのアーキテクチャにつレ、ては IP (Intellect ual Property)を購入して実現し、ある機能ブロックのアーキテクチャにつレ、ては設 計者が作成し、ある機能ブロックのアーキテクチャについては、アンダーバスによって 実現するということである。
[0009] つぎに、ステップ S3804において、ユニット設計をおこなう。ユニット設計では、構造 仕様書 3830に記述された各ハードウェアモジュールを複数のモジュールに分割して 詳細に設計することによってユニット仕様書 3840を作成する。
[0010] つぎに、ステップ S3805におレ、て、実装をおこなう。実装では、インターフェースの タイミングチャートを用レ、、また、内部ロジックを考慮することにより、最終的な設計対 象となる RTL (Register Transfer Level) 3850の HDL (Hardware Descripti on Language)を用レ、て実装をおこなう。
[0011] つぎに、ステップ S3806において、ユニット検証をおこなう。ユニット検証では、ュニ ット検証項目 3860にしたがって、ユニット設計によって設計されたユニットごとのュニ ット仕様書 3840の検証、すなわち、デバッグをおこなう。
[0012] つぎに、ステップ S3807において、結合検証をおこなう。結合検証では、結合検証 項目 3870にしたがって、ユニット検証によって検証された各ユニットのインターフエ ースを結合して、正常に動作するかを検証する。
[0013] つぎに、ステップ S3808において、機能検証をおこなう。機能検証では、機能検証 項目 3880にしたがって、設計対象となるシステムの機能要求を満たすかどうかを検 証する。
[0014] 最後に、ステップ S3809において、実機検証をおこなう。実機検証では、 RTL385 0を用いて実際にチップ上に LSIを実装して、実際に動作するかどうかを検証する。 顧客からの要求仕様書 3810が、要求検証項目 3890を満足しているかどうかを判断 する。
発明の開示 発明が解決しょうとする課題
[0015] し力 ながら、上述した設計処理では、実装 (ステップ S3805)しなければ、 LSIの 検証（ステップ S3806 S3809)をおこなうことカできな力つた。
[0016] これにより、設計フローの上流のいずれかのステップにおいて仕様書の誤り、記述 の曖昧さ、設計者の誤解釈のためにミスが生じると、そのステップ以降のステップにお レ、てミスが累積されてしまうとレ、う問題があった。
[0017] また、構造設計においては、机上でアーキテクチャを決定しており、その妥当性を 確かめる手法が存在していなかった。したがって、開発リスクの増大によって開発プロ ジェタトの破綻も生じ、開発時間および開発労力が無駄になるという問題があった。
[0018] また、 RTL3850の HDLに対してシミュレーションをおこなうために特別なシミュレ ータ (VCS、 NC_Simなどの EDAベンダーのツーノレ)が必要である力 シミュレーショ ンスピードが遅いために検証効率が低下し、設計期間の長期化を招くという問題があ つた。特に、設計対象が大規模な場合、シミュレーションスピードがネックとなって、所 定の期間内に検証作業を収束させることができなレヽ場合があった。
[0019] 一方、シミュレータより何千倍のスピードで動くエミュレータを導入してシミュレーショ ンの速度の向上を図ることも考えられるが、エミュレータが非常に高価であり、検証費 用が増大するとともに、環境の構築が困難な上に問題発生時にデバッグが難しいた めに結果的に検証期間が増加して、設計期間の長期化を招くという問題があった。
[0020] 本発明は、上記問題点に鑑みてなされたものであって、 LSIの設計精度の向上お よび検証期間の短縮化を、容易かつ効率的に実現することができる検証支援装置、 検証支援方法、検証支援プログラムおよび該プログラムを記録した記録媒体を提供 することを目的とする。
課題を解決するための手段
[0021] 上述した課題を解決し、 目的を達成するため、本発明の検証支援装置、検証支援 方法、検証支援プログラムおよび該プログラムを記録した記録媒体は、 LSIの設計対 象に関する要求仕様の分析結果を示す分析情報を入力し、入力された分析情報に 基づいて、前記設計対象の基本機能がモデル化され、かつ、前記設計対象の物理 的なアーキテクチャおよび時間の概念が抽象化された概念モデルを生成し、入力さ れた分析情報に基づいて、前記設計対象を構成するモジュールの分割、および分 割されたモジュールの並行または並列性を抽出することによってモデル化された機 能モデルを生成し、生成された機能モデルについて、前記設計対象を構成するモジ ユールの分割、および分割されたモジュールの並行または並列性が正当であるかど うかを、生成された概念モデルに基づレ、て検証することを特徴とする。
[0022] また、上記発明は、前記機能モデルが正当であることが検証された場合、複数種類 の物理的なアーキテクチャに関する情報力も任意のアーキテクチャに関する情報を 抽出し、抽出されたアーキテクチャに関する情報を、正当であることが検証された機 能モデルにマッピングすることにより、前記設計対象の動作をモデル化した動作モデ ルを生成し、生成された動作モデルによりモデル化された設計対象を構成するモジ ユールの動作タイミング力 正当であるかどうかを検証することを特徴とする。
[0023] さらに、上記発明は、前記動作モデノレが正当であることが検証された場合、前記機 能モデルによってモデル化された設計対象を構成するモジュール間の抽象度が異 なる箇所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを 挿入することにより ICAモデルを生成し、生成された ICAモデルに挿入されたインタ 一フェースのクロックサイクル精度が正当であるかどうかを、生成された概念モデルに 基づいて検証することを特徴とする。
[0024] また、前記動作モデルが正当であることが検証された場合、前記機能モデルによつ てモデル化された設計対象に基づいて、ソフトウェアによって実行可能なタスクを含 むようにモデル化されたソフトウェアモデルを生成し、生成されたソフトウェアモデル に含まれているタスクが正当であるかどうかを、生成された概念モデルに基づいて検 証することを特徴とする。
発明の効果
[0025] この発明の検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体に よれば、段階的に検証を導入することによって、これまで、 RTLを生成しないと発見 できなかった問題を、設計の早期段階に摘出してそのリスクを回避することができる。 したがって、 LSIの設計精度の向上および検証期間の短縮化を、容易かつ効率的に 実現することができるとレ、う効果を奏する。 図面の簡単な説明
[図 1]この発明の実施の形態に力かる検証支援の概念図である。
[図 2]図 1に示した各モデルの抽象度をあらわすグラフである。
[図 3]この発明の実施の形態に力かる検証支援装置のハードウェア構成を示すブロッ ク図である。
[図 4]この発明の実施の形態に力かる検証支援装置の機能的構成を示すブロック図 である。
[図 5]この発明の実施の形態に力かる検証支援装置の検証支援処理手順を示すフロ 一チャートである。
[図 6]この発明の実施の形態に力かる設計対象を含むシステム LSIのハードウェア構 成を示すブロック図である。
[図 7]外部装置のインターフェースであるバスの仕様（ライト時のタイミングチャート）を 示す説明図である。
[図 8]外部装置のインターフェースであるバスの仕様（リード時のタイミングチャート）を 示す説明図である。
[図 9]外部装置のインターフェースである送信器の仕様を示す説明図である。
[図 10]外部装置のインターフェースである受信器の仕様を示す説明図である。
[図 11]CPUで送受信されるパケットの構成を示す説明図である。
[図 12]送信パケットの構成を示す説明図である。
[図 13]要求定義であるシステム LSIの要求項目リストを示す説明図である。
[図 14]要求定義であるシステム LSIのユースケース図である。
[図 15]要求定義された結果物であるシステム LSIの分析クラス図である。
[図 16]要求定義された結果物であるシステム LSIのシーケンス図である。
[図 17]シリアル送受信システムを含むシステム LSIの設計クラス図である。
[図 18]概念モデルの実装コードを示す説明図である。
[図 19]シリアル送受信システムを含むシステム LSIの検証項目を示す説明図である。
[図 20]シリアル送受信システムを含むシステム LSIの検証シナリオを示す説明図であ る。 園 21]シリアル送受信システムを含むシステム LSIの機能モデルの実装コード生成処 理手順を示すフローチャートである。
園 22]図 17に示した設計クラス図を分割することによって得られた分割設計クラス図 を示す説明図である。
園 23]分割設計クラス図によってあらわされるモジュール間を接続する通信路を示す 説明図である。
[図 24]シリアル送受信システムを含むシステム LSIの機能モデルの実装コードの生成 例を示す説明図である。
[図 25]シリアル送受信システムを含むシステム LSIのアーキテクチャモデルのクラス図 の一例を示す説明図である。
園 26]機能モデルとアーキテクチャモデルとのマッピングを示す説明図である。
[図 27]シリアル送受信システムを含むシステム LSIの動作モデルの実装コード生成処 理手順を示すフローチャートである。
園 28]属性内の記述がバスモデルの記述に置き換えられた分割設計クラス図を示す 説明図である。
[図 29]各モジュールの見積もり処理時間の実装コードへの追加例を示す説明図であ る。
園 30]シリアル送受信システムを含むシステム LSI ICAモデルの実装コード生成処 理手順を示すフローチャートである。
園 31]シリアル送受信システムを含むシステム LSIの通信路が決定された機能モデ ルを示す構造図である。
園 32]図 31に示した構造図内の通信路にインターフェースラッパを揷入した構造図 である。
[図 33]ICAモデルのエンコーダモジュールの内部構造の一例を示す説明図である。
[図 34]ICAモデルのエンコーダモジュールの実装コードの一例を示す説明図である
[図 35]シリアル送受信システムを含むシステム LSIのソフトウェアモデルの実装コード 生成処理手順を示すフローチャートである。 [図 36]アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピングをお こなった例を示す説明図である。
園 37]ソフトウェアモデルにおける設計クラス図を示す説明図である。
園 38]従来の LSIの開発処理手順を示すフローチャートである。
符号の説明
100 要求仕様
101 概念モデル
102 機能モデル
103 アーキテクチャモデノレ
104 動作モデル
105 ICAモデル
106 ソフトウェアモデル
401 分析情報入力部
402 概念モデル生成部
403 機能モデル生成部
404 機能モデル検証部
405 アーキテクチャ情報記憶部
406 アーキテクチャ情報抽出部
407 動作モデル生成部
408 動作モデル検証部
409 ICAモデル生成部
410 ICAモデル検証部
411 ソフトウェアモデル生成部
412 ソフトウェアモデル検証部
発明を実施するための最良の形態
(実施の形態）
以下に、本発明の実施の形態にかかる検証支援装置、検証支援方法、検証支援 プログラムおよび該プログラムを記録した記録媒体について図面を参照しつつ詳細 に説明する。
[0029] (検証支援の概念）
まず、この発明の実施の形態に力かる検証支援の概念について説明する。図 1は、 この発明の実施の形態に力かる検証支援の概念図である。
[0030] 図 1において、設計者は、設計対象を含むシステム LSIの顧客からの要求仕様 100 について、 UML (Unified Modeling Language)を用いてオブジェクト指向分析 をおこない、その分析結果を概念モデル 101としてモデリングする。概念モデル 101 とは、設計対象の概念的な分析結果をあらわすモデルである。概念モデル 101は、 完全に実装依存しないモデルであり、具体的には、物理的なアーキテクチャや時間 の概念が抽象化され、設計対象の基本機能を中心にモデリングされたものである。
[0031] 概念モデル 101は、具体的には、システム LSIの要求仕様の分析結果を、 UMLや C+ +でモデリングした結果物であり、 UMLモデル、 C+ +モデル、および検証シナ リオのすべてを含めた総称である。この概念モデル 101では、要求仕様 100の誤解 やミス、またはアルゴリズムの検証をおこなうことができる。
[0032] また、機能モデル 102は、概念モデル 101から、設計対象であるシステム LSIを構 成するモジュールの分割、分割されたモジュールの並行または並列性を抽出するこ とによって構築されたモデルである。機能モデル 102は、時間の概念が存在しない。 この機能モデルでは、モジュール分割の正当性や、並歹 I」、並行性の正確さを検証す ること力 Sできる。
[0033] また、アーキテクチャモデル 103は、バスや IP (Intellectual Property)などの既 存設計の物理的なハードウェア部品をあらわすモデルである。アーキテクチャモデル 103は、具体的には、処理リソースと、通信リソースとに大別される。処理リソースは、 機能モデル 102のモジュールをマッピングするためのモデルである。たとえば、ハー ドウエア処理モジュール、プロセッサ、 RT〇S、 DSPなどが挙げられる。
[0034] 一方、通信リソースは、機能モデルのモジュール間の通信を実現するためのチャン ネルをモデリングしたモデルである。たとえば、バス、メモリ、ハードウェアモジュール 間の信号線などが挙げられる。このアーキテクチャモデル 103では、既存設計の物 理的なハードウェア部品を用いているため、検証をおこなう必要はない。 [0035] また、動作モデル 104は、概念的に、機能モデル 102をアーキテクチャモデル 103 にマッピングした結果物である。具体的には、機能モデル 102のプロセスをァーキテ クチャモデル 103の処理リソースにマッピングし、機能の通信チャンネルは、通信リソ ースを用いて組み立てる。この動作モデル 104では、顧客が要求した動作 (性能）を 満足するかどうかの検証をおこなうことができる。
[0036] つぎに、動作モデル 104について HWZSW分割をおこなレ、、ハードウェア実装を あらわす ICA (Interface Cycle Accurate)モデル 105とソフトウェア実装をあらわ すソフトウェアモデル 106とを生成する。
[0037] ICAモデル 105は、モジュール外のインターフェースについてはサイクル精度によ つて、モジュール内部は動作レベルによって構築したモデルである。この ICAモデル 105を高位合成することによって RTL記述 107を生成する。この ICAモデル 105で は、インターフェースの正確さの検証をおこなうことができる。
[0038] また、ソフトウェアモデル 106は、設計対象を含むシステム LSIを構成するソフトゥェ ァのタスク分割をおこない、仮想 OS上に実行するモデルである。このソフトウェアモ デル 106についてコード生成処理をおこなうことによって、実装コード 108を生成する 。このソフトウェアモデル 106では、ソフトウェアの機能を検証することができる。
[0039] (各モデルの抽象度）
つぎに、図 1に示した各モデルの抽象度について説明する。図 2は、図 1に示した 各モデル 101— 106の抽象度をあらわすグラフである。図 2のグラフは、原点を中心 とした 3軸によって構成されている。各軸は、それぞれ「機能」の抽象度、「構造」の抽 象度、「時間」の抽象度をあらわしており、原点から離れるにしたがって抽象度が高く なる。
[0040] (検証支援装置のハードウェア構成）
つぎに、この発明の実施の形態にかかる検証支援装置のハードウェア構成につい て説明する。図 3は、この発明の実施の形態に力、かる検証支援装置のハードウェア 構成を示すブロック図である。
[0041] 図 3におレヽて、検証支援装置は、 CPU301と、 ROM302と、 RAM303と、 HDD ( ハードディスクドライブ） 304と、 HD (ノヽードディスク） 305と、 FDD (フレキシブルディ スクドライブ） 306と、着脱可能な記録媒体の一例としての FD (フレキシブルディスク） 307と、ディスプレイ 308と、 I/F (インターフェース） 309と、キーボード 310と、マウ ス 311と、スキャナ 312と、プリンタ 313と、を備えてレヽる。また、各構成咅はノ ス 300 によつてそれぞれ接続されてレ、る。
[0042] ここで、 CPU301は、検証支援装置の全体の制御を司る。 ROM302は、ブートプ ログラムなどのプログラムを記'慮している。 RAM303は、 CPU301のワークエリアとし て使用される。 HDD304は、 CPU301の制御にしたがって HD305に対するデータ のリード/ライトを制御する。 HD305は、 HDD304の制御で書き込まれたデータを 記憶する。
[0043] FDD306は、 CPU301の制御にしたがって FD307に対するデータのリード/ライ トを制御する。 FD307は、 FDD306の制御で書き込まれたデータを記憶したり、 FD 307に記憶されたデータを検証支援装置に読み取らせたりする。
[0044] 着脱可能な記録媒体として、 FD307のほ力、 CD-ROM (CD_R、 CD-RW)、 M 0、 DVD (Digital Versatile Disk)、メモリーカードなどであってもよレ、。ディスプ レイ 308は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情 報などのデータを表示する。このディスプレイ 308は、たとえば、 CRT, TFT液晶ディ スプレイ、プラズマディスプレイなどを採用することができる。
[0045] I/F309は、通信回線を通じてインターネットなどのネットワークに接続され、このネ ットワークを介して他の装置に接続される。そして、 I/F309は、ネットワークと内部の インターフェースを司り、外部装置からのデータの入出力を制御する。 I/F309には 、たとえばモデムや LANアダプタなどを採用することができる。
[0046] キーボード 310は、文字、数字、各種指示などの入力のためのキーを備え、データ の入力をおこなう。また、タツチパネル式の入力パッドやテンキーなどであってもよレヽ 。マウス 311は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変 更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、ト ラックボールやジョイスティックなどであってもよレ、。
[0047] スキャナ 312は、画像を光学的に読み取り、検証支援装置内に画像データを取り 込む。なお、スキャナ 312は、 OCR機能を持たせてもよレ、。また、プリンタ 313は、画 像データや文書データを印刷する。プリンタ 313には、たとえば、レーザプリンタゃィ ンクジェットプリンタを採用することができる。
[0048] (検証支援装置の機能的構成）
つぎに、この発明の実施の形態にかかる検証支援装置の機能的構成について説 明する。図 4は、この発明の実施の形態にかかる検証支援装置の機能的構成を示す ブロック図である。
[0049] 図 4において、検証支援装置 400は、分析情報入力部 401と、概念モデル生成部
402と、機能モデル生成部 403と、機能モデル検証部 404と、アーキテクチャ情報記 憶部 405と、アーキテクチャ抽出部 406と、動作モデル生成部 407と、動作モデル検 証部 408と、 ICAモデル生成部 409と、 ICAモデル検証部 410と、ソフトウェアモデ ル生成部 411と、ソフトウェアモデル検証部 412と、力、ら構成されている。
[0050] 分析情報入力部 401は、設計対象を含むシステム LSIの顧客からの要求仕様の分 析結果を示す情報 (分析情報)の入力を受け付ける。ここで、分析情報とは、たとえば 、 UMLによって記述された設計対象のユースケース図、シーケンス図、クラス図や、 設計対象に要求される基本機能項目など、コンピュータによって読取り可能な情報が 挙げられる。
[0051] また、概念モデル生成部 402は、分析情報入力部 401によって入力された分析情 報に基づいて、設計対象の基本機能がモデル化され、かつ、設計対象の物理的な アーキテクチャおよび時間の概念が抽象化された概念モデル、すなわち、図 1に示し た概念モデル 101を生成する。
[0052] 具体的には、概念モデル生成部 402は、ユースケース図などの分析情報を解析し て、設計対象の実装コードや、設計対象について検証すべき項目（検証項目）、回路 シミュレーションによる検証処理手順を示す検証シナリオを生成する。この生成された 実装コード、検証項目および検証シナリオが、図 1に示した概念モデル 101となる。
[0053] また、機能モデル生成部 403は、分析情報入力部 401によって入力された分析情 報に基づいて、設計対象を構成するモジュールの分割、および分割されたモジユー ルの並行または並列性を抽出することによってモデル化された機能モデルを生成す る。たとえば、分析情報であるクラス図に基づいて、設計対象の機能をあらわす機能 モデルを生成する。
[0054] 具体的には、概念モデル生成部 402に入力されたクラス図を機能ごとに複数に分 割し、分割されたクラス図（分割クラス図）ごとに、実装コードを生成する。この生成さ れた分割クラス図ごとの実装コードが、図 1に示した機能モデル 102となる。
[0055] 機能モデル検証部 404は、機能モデル生成部 403によって生成された機能モデル について、設計対象を構成するモジュールの分割、および分割されたモジュールの 並行または並列性が正当であるかどうかを、概念モデル生成部 402によって生成さ れた概念モデルに基づレ、て検証する。
[0056] 具体的には、分割クラス図ごとの実装コードのシミュレーション結果力 概念モデル の実装コードを概念モデルの検証シナリオでシミュレーションしたシミュレーション結 果と一致するかどうかを判定することによって、機能モデルの正当性を検証する。ここ で、シミュレーション結果とは、ある入力データに対してどのような出力データが得ら れるか、ということである。
[0057] より具体的には、分割クラス図ごとの実装コードのシミュレーション結果が一致する 場合は、機能モデルが正当となる。一方、不一致の場合は、機能モデルの分割、並 行、並列性が正しくないため、機能モデル生成部 403は、機能モデルの実装コード を修正する。
[0058] また、アーキテクチャ情報記憶部 405は、バスや IP (Intellectual Property)など の既存設計の物理的なハードウェア部品に関する情報を記憶する。アーキテクチャ 情報記憶部 405は、具体的には、たとえば、図 3に示した ROM302、 RAM303、 H D305、 FD307などによってその機能を実現する。
[0059] アーキテクチャ情報抽出部 406は、アーキテクチャ情報記憶部 405に記憶されてい るアーキテクチャ情報を抽出する。処理リソースに関しては、たとえば、ハードウェア 処理モジュール、プロセッサ、 RT〇S、 DSPなどを抽出する。一方、通信リソースに関 しては、バス、メモリ、ハードウェアモジュール間の信号線などを抽出する。このァーキ テクチヤ情報抽出部 406によって抽出されたアーキテクチャ情報力 図 1に示したァ ーキテクチヤモデル 103に相当する。
[0060] 動作モデル生成部 407は、アーキテクチャ情報抽出部 406によって抽出されたァ ーキテクチヤに関する情報を、機能モデル検証部 404によって正当であることが検証 された機能モデルにマッピングすることにより、設計対象の動作をモデルィヒした動作 モデルを生成する。
[0061] 具体的には、機能モデル 102をアーキテクチャモデル 103にマッピングすることに よって、設計対象の動作モデル 104を生成する。具体的には、機能モデル 102のプ 口セスをアーキテクチャモデル 103の処理リソースにマッピングし、機能の通信チャン ネルは、通信リソースを用いて組み立てる。この組み立てにより、マッピングによって 得られたモジュールの処理時間を考慮した実装コードを生成する。この生成された実 装コードが、図 1に示した動作モデル 104に相当する。
[0062] 動作モデル検証部 408は、動作モデル生成部 407によって生成された動作モデル によりモデル化された設計対象を構成するモジュールの動作タイミングが、正当であ るかどうかを検証する。
[0063] 具体的には、動作モデル生成部 407によって生成された実装コードのシミュレーシ ヨン結果力 S、概念モデルの実装コードを概念モデルの検証シナリオでシミュレーショ ンしたシミュレーション結果と一致するかどうかを判定することによって、動作モデル の正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してど のような出力データが得られるカ ということである。
[0064] そして、一致する場合は、動作モデルが正当となり、顧客が要求した動作 (性能）を 満足していることとなる。一方、不一致の場合は、動作モデルが、顧客が要求した動 作 (性能）を満足していないこととなる。この場合、動作モデル生成部 407は、動作モ デルの実装コードを修正する。
[0065] ICAモデル生成部 409は、動作モデル検証部 408によって正当であることが検証 された場合、機能モデルによってモデル化された設計対象を構成するモジュール間 の抽象度が異なる箇所に、当該モジュール間に所定のクロックサイクル精度のインタ 一フェースを揷入することにより ICAモデルを生成する。
[0066] 具体的には、動作モデル 104について HW/SW分割をおこなレ、、ハードウェア実 装をあらわす ICAモデル 105を生成する。たとえば、モジュール間の抽象度が異なる 場合に、当該モジュール間の抽象度が同等となるように、クラス図に示された、モジュ ール間の通信路をインターフェースラッパに置換する。
[0067] そして、インターフェースラッパに置換されたクラス図の実装コードを生成する。この 生成された実装コードが、図 1に示した ICAモデル 105となる。そして、この ICAモデ ノレ 105の実装コードを高位合成することにより、 RTL記述 107を生成することができ る。
[0068] ICAモデル検証部 410は、 ICAモデル生成部 409によって生成された ICAモデル
105に揷入されたインターフェースのクロックサイクル精度が正当であるかどうかを、 概念モデル生成部 402によって生成された概念モデル 101に基づいて検証する。
[0069] 具体的には、 ICAモデル生成部 409によって生成された実装コードのシミュレーシ ヨン結果力 概念モデルの実装コードを概念モデルの検証シナリオでシミュレーショ ンしたシミュレーション結果と一致するかどうかを判定することによって、機能モデル の正当性を検証する。ここで、シミュレーション結果とは、ある入力データに対してど のような出力データが得られるカ ということである。
[0070] そして、一致する場合は、 ICAモデルが正当となる。具体的には、置換されたインタ 一フェースラッパによってあらわされるインターフェースが正確であることとなる。一方 、不一致の場合は、置換されたインターフェースラッパが不正確となる。この場合、 IC Aモデル生成部 409は、 ICAモデルの実装コードを修正する。
[0071] ソフトウェアモデル生成部 411は、動作モデル検証部 408によって正当であること が検証された場合、機能モデルによってモデル化された設計対象に基づいて、ソフト ウェアによって実行可能なタスクを含むようにモデル化されたソフトウェアモデルを生 成する。
[0072] 具体的には、動作モデル 104について HW/SW分割をおこなレ、、ソフトウェア実 装をあらわすソフトウェアモデル 106 (図 1を参照。）を生成する。たとえば、設計対象 を含むシステム LSIを構成するソフトウェアのタスク分割をおこなレ、、仮想〇S上に実 行可能な実装コードを生成する。
[0073] ソフトウェアモデル検証部 412は、ソフトウェアモデル生成部 411によって生成され たソフトウェアモデルに含まれているタスク力 正当であるかどうかを、概念モデル生 成部 402によって生成された概念モデルに基づいて検証する。 [0074] 具体的には、ソフトウェアモデル生成部 411によって生成された実装コードのシミュ レーシヨン結果力 S、概念モデルの実装コードを概念モデルの検証シナリオでシミュレ ーシヨンしたシミュレーション結果と一致するかどうかを判定することによって、ソフトゥ エアモデル 106の正当性を検証する。ここで、シミュレーション結果とは、ある入力デ ータに対してどのような出力データが得られる力、、ということである。
[0075] そして、一致する場合は、ソフトウェアモデル 106の実装コードによってあらわされる 機能が正当となる。そして、このソフトウェアモデル 106の実装コードを取り込んだ、設 計対象全体の実装コード 108 (図 1を参照。）を生成する。一方、不一致の場合は、ソ フトウヱァモデル 106の実装コードによってあらわされる機能が不正確となる。この場 合、ソフトウェアモデル生成部 411は、ソフトウェアモデルの実装コードを修正する。
[0076] なお、上述した分析情報入力部 401、概念モデル生成部 402、機能モデル生成部
403、機能モデル検証部 404、アーキテクチャ情報抽出部 406、動作モデル生成部 407、動作モデル検証部 408、 ICAモデル生成部 409、 ICAモデル検証部 410、ソ フトウエアモデル生成部 411およびソフトウェアモデル検証部 412は、具体的には、 たと免ば、、図 3に示した R〇M302、 RAM303, HD305, FD307などに記録された プログラムを CPU301が実行することによって、または I/F309によって、その機能 を実現する。
[0077] (検証支援装置の検証支援処理手順）
つぎに、この発明の実施の形態にかかる検証支援装置の検証支援処理手順につ いて説明する。図 5は、この発明の実施の形態にかかる検証支援装置の検証支援処 理手順を示すフローチャートである。
[0078] 図 5において、まず、設計者は、設計対象を含むシステム LSIの顧客からの要求仕 様 100を分析して、分析結果をあらわす分析情報を入力する (ステップ S501)。
[0079] つぎに、入力された分析情報に基づいて、設計対象の実装コードや、設計対象に ついて検証すべき項目（検証項目）、回路シミュレーションによる検証処理手順を示 す検証シナリオなどの概念モデル 101を生成する（ステップ S502)。生成された概念 モデル 101の正当性については、設計者が検証する。
[0080] つぎに、設計対象の機能デモル 102を生成する（ステップ S503)。具体的には、概 念モデル生成部 402に入力されたクラス図を機能ごとに複数に分割し、分割されたク ラス図（分割クラス図）ごとに、機能モデル 102の実装コードを生成する。
[0081] そして、概念モデル 101の実装コードと機能モデル 102の実装コードのシミュレ一 シヨンをおこなう（ステップ S504)。つぎに、概念モデル 101の実装コードのシミュレ一 シヨン結果と、機能モデル 102の実装コードのシミュレーション結果と力 一致するか どうかの判定、すなわち、機能モデル検証をおこなう（ステップ S505)。
[0082] 不一致の場合（ステップ S505 : No)、機能モデル 102を修正する（ステップ S506) 。具体的には、たとえば、概念モデル 101のクラス図を再度、分割しなおして、分割ク ラス図を生成し、その分割クラス図ごとに実装コードを生成する。そして、ステップ S5 04に移行する。
[0083] 一方、一致する場合 (ステップ S505 :Yes)、機能モデル 102が正当であると判断さ れる。そして、正当性が検証された検証済みの機能モデル 102に、アーキテクチャモ デル 103をマッピングして、動作モデル 104を生成する（ステップ S507)。そして、動 作モデル 104の実装コードのシミュレーションをおこなう（ステップ S508)。
[0084] つぎに、概念モデル 101の実装コードのシミュレーション結果と、動作モデル 104の 実装コードのシミュレーション結果とが、一致するかどうかの判定、すなわち、動作モ デル検証をおこなう（ステップ S509)。
[0085] 不一致の場合（ステップ S509 : No)、動作モデル 104を修正する（ステップ S510) 。具体的には、たとえば、アーキテクチャ情報記憶部 405から再度アーキテクチャ情 報を抽出して、正当性が検証された検証済の機能モデル 102に、あらたなァーキテ クチャモデル 103をマッピングして、動作モデル 104を生成する。そして、ステップ S5 08に移行する。
[0086] 一方、一致する場合（ステップ S509 :Yes)、動作モデル 104が正当であると判断さ れる。そして、正当性が検証された検証済の動作モデル 104に対し HWZSW分割 をおこない、 ICAモデル 105とソフトウェアモデル 106を生成する（ステップ S511、ス テツプ S 516)。
[0087] そして、生成された ICAモデル 105の実装コードのシミュレーションをおこなう（ステ ップ S512)。つぎに、概念モデル 101の実装コードのシミュレーション結果と、 ICAモ デル 105の実装コードのシミュレーション結果と力 一致するかどうかの判定、すなわ ち、 ICAモデル検証をおこなう（ステップ S513)。
[0088] 不一致の場合（ステップ S513 : No)、 ICAモデル 105を修正する（ステップ S514)
。具体的には、たとえば、インターフェースラッパの内容を変更することによって、 ICA モデル 105を修正する。そして、ステップ S512に移行する。
[0089] 一方、一致する場合（ステップ S513 : Yes)、 ICAモデル 105が正当であると判断さ れる。そして、高位合成をおこなって (ステップ S515)、 RTL記述を生成する。
[0090] また、生成されたソフトウェアモデル 106の実装コードのシミュレーションをおこなう（ ステップ S517)。つぎに、概念モデル 101の実装コードのシミュレーション結果と、ソ フトウエアモデル 106の実装コードのシミュレーション結果と力 一致するかどうかの 判定、すなわち、ソフトウェアモデル検証をおこなう（ステップ S518)。
[0091] 不一致の場合（ステップ S518 : No)、ソフトウェアモデル 106を修正する（ステップ S
519)。具体的には、たとえば、設計対象を含むシステム LSIを構成するソフトウェア のタスク分割を再度おこない、仮想 OS上に実行可能な実装コードを生成する。
[0092] 一方、一致する場合 (ステップ S518 :Yes)、ソフトウェアモデル 106が正当であると 判断される。そして、正当であることが検証された検証済のソフトウェアモデル 106の 実装コードを取り込んだ、設計対象全体の実装コード 108を生成する (ステップ S52
0)。
[0093] この検証処理手順によれば、モデルごとに、段階的に検証をおこなうため、直前ま でに検証されたモデルについては、検証のやり直しをおこなうことなぐ有効なモデル として活用することができるため、検証処理において手戻りが発生せず、検証処理の 効率化を図ることができる。
[0094] なお、上述した図 5のフローチャートでは、ステップ S511 515までの処理手 j噴と、 ステップ S516 520までの処理手順とを並列に実行することとしている力 ステップ S511 515までの処理手順のあとに、ステップ S516— 520までの処理手順を実行 することとしてもよく、また、ステップ S516— 520までの処理手順のあとに、ステップ S 511— 515までの処理手順を実行することとしてもよい。
[0095] (検証処理の具体例） つぎに、上述した検証処理の具体例について説明する。
[0096] (システム LSIのハードウェア構成）
まず、設計対象を含むシステム LSIのハードウェア構成について説明する。図 6は、 この発明の実施の形態に力かる設計対象を含むシステム LSIのハードウェア構成を 示すブロック図である。この設計対象は、たとえば、顧客から設計業務を引き受けた 情報であり、ここでは、その設計対象を、シリアル送受信システムとして説明する。
[0097] 図 6において、システム LSI600は、設計対象の一例として挙げられたシリアル送受 信システム 601と、受信器 602と、送信器 603と、 CPU604と、その他デノ イス 605と 、これらを接続するバス 606と、によって構成されている。
[0098] ここで、受信器 602は、受信パケット 611を受信し、シリアル送受信システム 601に 供給する。送信器 603は、シリアル送受信システム 601から供給された情報を送信パ ケット 612として図示しない外部機器に送信する。シリアル送受信システム 601は、た とえば、 BCH (62, 48)で符号化および復号化をおこなう。
[0099] そして、受信器 602からの受信パケット 611を復号し、この復号したパケット 613を C PU604に供給する。また、 CPU604からのパケット 614を符号化する。 CPU604は 、シリアル送受信システム 601からのパケット 613を用いて、その他デバイス 605ととも にシステム LSI600の機能を実行する。
[0100] (外部装置のインターフェース仕様）
つぎに、外部装置（受信器 602、送信器 603、 CPU604、その他デバイス 605)の インターフェース仕様について説明する。図 7および図 8は、外部装置のインターフエ ースであるバスの仕様を示す説明図である。特に、図 7は、ライト時のタイミングチヤ一 トであり、図 8は、リード時のタイミングチャートである。
[0101] 図 7および図 8において、「PCLK」は、ビット幅 1の入力クロック信号である。 「PAD DR」は、ビット幅 32のアドレス出力信号である。 「PWRITE」は、ビット幅 1のリード Z ライト制御出力信号である。 「PSEL」は、ビット幅 1のチップセレクト出力信号である。 「PENABLE」は、ビット幅 1の出カイネーブル信号である。 「PRDATA」は、ビット幅 32のデータ入出力信号である。 CPU604に対するバスの仕様は、バス標準プロトコ ルに準拠しており、 CPU604について組み込みプロセッサコアを採用することとして いる。
[0102] 図 9は、外部装置のインターフェースである送信器 603の仕様を示す説明図である 。図 9において、「clk」は、ビット幅 1の入力クロック信号である。 「ISTART」は、ビット 幅 1のスタートパルス入力信号である。 「IDATA」は、ビット幅 1のデータ入力信号で ある。シリアル送受信システム 601から送信器 603への入力仕様は、スタートパルス 入力信号の iクロックのパルスを検出すると同時に、送信器 603がクロックのポジティ ブエッジごとに 1ビットずつデータを取り込むという仕様である。また、入力クロック周 波数は、 100MHzとしてレヽる。
[0103] 図 10は、外部装置のインターフェースである受信器 602の仕様を示す説明図であ る。図 10において、「clk」は、ビット幅 1の出力クロック信号である。 「OSTART」は、 ビット幅 1のスタートパルス出力信号である。「〇DATA」は、ビット幅 1のデータ出力 信号である。
[0104] (シリアル送受信システムに要求される基本機能）
つぎに、設計対象であるシリアル送受信システム 601に要求される基本機能につい て説明する。シリアル送受信システム 601に要求される基本機能は、 （1)パケットの送 信機能と、（2)パケットの受信機能と、（3)初期化機能である。
[0105] (1)パケットの送信機能は、以下のとおりである。
(i) CPU604が作成したパケット 614を BCH (62, 48)で符号化して送信器 603に 転送する転送機能。
(ii) CPU604が作成したパケット 614の不正を検出して〇？11604にェラーを知らせ る不正検出機能。
(iii) CPU604から連続的に大量なパケット 614が送信されてきた際に処理が間に 合わないとき、 CPU604にエラーを知らせ、送信パケット 612を破棄するパケット破棄 機能。
(vi)送信器 603への出力スループット： 0 1Mbps
また、 （2)パケットの受信機能は、以下の通りである。
(vii) BCH (62, 48)で受信器 602から連続して符号化された受信パケット 611を受 信し、受信パケット 611を復号して CPU604に通知し、復号したパケット 613を CPU 604に受信させる復号機能。
(viii)受信器 602から大量の受信パケット 611を送ってきた際に処理が間に合わな い場合は受信パケット 611の廃棄を許容するパケット廃棄許容機能。
(ix)受信パケット 611の中に誤り訂正ができないパケットが存在する場合、 CPU60 4にエラーを知らせ、受信パケット 611を破棄するパケット破棄機能。
(X)受信パケット 611に対して 2ビットまで訂正可能、 4ビットまでエラーの検出可能 とする訂正'検出機能。
(xi)受信器 602からの入力スループット： 0 1Mbps
さらに、（3)初期化機能は、以下の通りである。
(xii) CPU604から初期化指示するソフトリセット機能。
(xiii)リセット信号力もも初期化指示するハードリセット機能。
[0106] (パケットの構成）
つぎに、〇？11604で送受信されるパケット613, 614の構成について説明する。図 11は、〇？11604で送受信されるパケット613, 614の構成を示す説明図であり、図 1 2は、送信パケット 612の構成を示す説明図である。図 11において、パケット 613, 6 14は、 16ビットのヘッダ部 1101と、 32ビットのデータ部 1102から構成されている。 ヘッダ部 1101はパケット識別番号（1010101010101010) 2とされている。
[0107] また、図 12において、送信パケット 612は、図 11に示した 16ビットのヘッダ部 1101 および 32ビットのデータ部 1102に、 BCH (62, 48)で符号化された 14ビットの冗長 符号部 1201が付加された構成である。また、受信パケット 611は、図示はしないが、 送信パケット 612との構成にさらに通信路によるエラービットが付加された構成である 。この図 6から図 12までの情報の内容が、顧客が要求する要求仕様 100となる。
[0108] (要求定義の内容）
つぎに、図 6から図 12までに示した要求仕様の内容を定義した要求定義について 説明する。図 13は、要求定義であるシステム LSI600の要求項目リストを示す説明図 であり、図 14は、要求定義であるシステム LSI600のユースケース図である。
[0109] 図 13に示した要求項目リスト 1300において、このシステム LSI600には、「受信パ ケットを最大 2重誤り訂正できる」（項目 1301)、「受信パケットの 4重誤りまで検出でき る」（項目 1302)、「受信パケットを受信器経由で受信できる」（項目 1303)、「受信パ ケットを BCH (60, 48)で復号化できる」（項目 1304)、「CPUから初期化できる」（項 目 1305)、「リセット信号力も初期化できる」（項目 1306)、「送信パケットを送信器経 由で送信できる」（項目 1307)、「送信パケットを BCH (62, 48)で符号ィ匕できる」（項 目 1308)の機能が要求される。
[0110] また、図 14に示したユースケース図 1400は、図 13に示した要求項目リスト 1300に よって要求されている機能を図表化したものであり、 UMLにしたがって記述された図 表である。図 14において、図 6に示したシリアル送受信システム 601は、ユースケー ス 1401— 1403によってあらわされる機能「パケットを受信する」、「初期化する」およ び「パケットを送信する」を備えている。また、ユースケース図 1400には、シリアル送 受信システム 601に関連するアクターとして、 CPU1411、リセット信号 1412、受信 器 1413および送信器 1414が図表化されている。
[0111] 図 14に示したユースケース図 1400において、ユースケース 1401は、アクター 141 3からパケットを受信する。そして、受信したパケットをアクター 1411に送信する。また 、ユースケース 1402は、アクター 1411およびアクター 1412から初期化する。さらに 、ユースケース 1403は、アクター 1411力 パケットを受信して、アクター 1414に送 信する。
[0112] (分析情報の内容）
つぎに、図 13および図 14に示した要求定義（要求項目リスト 1300、ユースケース 図 1400)の分析結果を示す分析情報について説明する。図 15は、要求定義された 結果物であるシステム LSI600の分析クラス図であり、図 16は、要求定義された結果 物であるシステム LSI600のシーケンス図である。
[0113] 図 15に示した分析クラス図 1500には、シリアル送受信システム 601に必要なデー タゃ手順などを管理する〈く control》クラス 1501と、シリアル送受信システム 601内部で 当該システム特有の処理を担当するく Entity〉クラス 1502 1508が記述されている。 《control》クラス 1501は、シリアス送受信システム 601をあらわしている。《entity》クラ ス 1502一 1508fま、送信ノヽ。ケット 612、受信ノヽ。ケット 611、 ノ ケット 613, 614、冗長 符号部 1201、エラービット、ヘッダ部 1101、データ部 1102をあらわしている。 [0114] 図 15に示した分析クラス図 1500において、《control》クラス 1501 (シリアル送受信 システム 601)は、アクター 1414 (送信器 603)力もパケットを送信する。また、ァクタ 一 1411 (CPU604)との間で送受信/初期化をおこなう。さらに、《entity》クラス 150 2 (送信パケット 612)の送信、《entity》クラス 1503 (受信パケット 611)の受信、ァクタ 一 1412 (リセット信号)からの初期化をおこなう。また、〈く entity》クラス 1503 (受信パケ ット 611)を受信したアクター 1413 (受信器 602)からパケットを受信する。
[0115] また、図 15に示した分析クラス図 1500において、《entity》クラス 1502 (送信バケツ ト 612)は、《6 》クラス1504 (パケット613， 614)および《entity》クラス 1505 (冗長 符号部 1201)を集約している。また、〈く entity》クラス 1503 (受信パケット 611)は、《 6 》クラス1505 (冗長符号部 1201)および《entity》クラス 1506 (エラービット）を集 約している。さらに、《6 》クラス1504 (パケット613、 614)は、《entity》クラス 1507 (ヘッダ部 1101)および《entity》クラス 1508 (データ部 1102)を集約している。これ により、アクター 1411 (CPU604) ίま、《entity》クラス 1504レヽ°ケット 613、 614)の作 成/受信をおこなっていることがわかる。
[0116] また、図 16に示したシーケンス図 1600は、パケットを正常に送信する場合の動作 を示している。このシーケンス図 1600では、シーケンス番号順、すなわち、シーケン ス番号 1 · 0 (「パケットを作成する（）」）→シーケンス番号1. 1 (「パケットを受信する 0 」）、→シーケンス番号 1 · 2 (「パケットを符号ィ匕する（）」）、→シーケンス番号 1 · 3 (「送 信パケットを作成する（）」）、シーケンス番号 1 · 4 (「送信パケットを送信する（）」）の順 に送信処理がおこなわれることを示してレ、る。
[0117] つぎに、このシリアル送受信システムを含むシステム LSIの設計クラス図について説 明する。図 17は、シリアル送受信システムを含むシステム LSIの設計クラス図である。
[0118] この設計クラス図 1700において、クラス 1701は、シリアル送受信システムを示す名 称「ECC_SIO」が記述されているクラス名 1702と、クラス 1701が持つ静的な性質 を示す属性 1703 (メンバ変数）と、クラス 1701が持つ動的な性質を示す操作 1704 ( メンバ関数）と、を含んでいる。操作 1704は、 CPUを示すクラス 1705と符号ィ匕を示 すクラス 1706に働き力けてレヽる。この図 17に示した設計クラス図 1700を元にして、 概念モデル 101の実装コードが生成される。図 17に概念モデル 101の実装コードの 一記述例を示す。図 18は、概念モデル 101の実装コード 1800を示す説明図である 。この実装コード 1800は、 C+ +言語によってモデル化されているコードである。
[0119] (検証項目の内容）
つぎに、シリアル送受信システムを含むシステム LSIの検証項目について説明する 。図 19は、シリアル送受信システムを含むシステム LSIの検証項目を示す説明図で ある。
[0120] 図 19では、対象ユースケースを、図 14で示したユースケース 1401に着目している 。この検証項目 1900におレヽて、項目『シーケンス』の「基本パス」とは、パケットの正 常な送信処理、すなわち、図 16に示したシーケンス番号 1. 0- 1. 1までの処理を示 している。
[0121] (検証シナリオの内容）
つぎに、シリアル送受信システムを含むシステム LSIの検証シナリオについて説明 する。図 20は、シリアル送受信システムを含むシステム LSIの検証シナリオを示す説 明図である。この検証シナリオ 2000は、図 15に示したシーケンス図 1500と図 19に 示した検証項目 1900を用いて生成される。
[0122] この検証シナリオ 2000を用いたシミュレーションによって検出された仕様上のミスに ついて、例を挙げて説明する。 CPUに常にエラーの通知を行っているという検証結 果が得られた場合、パケット受信エラーが発生したときにシリアル送受信システムをェ ラー状態にしたが、次のパケットを正常に受信してもシステムがエラー状態のままとな る仕様上のミスが検出される。このため、修正処理として、 CPUがエラー受信した後 にシリアル送受信システムのエラー状態をクリアすることとする。これにより、仕様ミス を解消することができる。
[0123] (機能モデルの実装コード生成処理手順）
つぎに、シリアル送受信システムを含むシステム LSIの機能モデルの検証処理手順 について説明する。図 21は、シリアル送受信システムを含むシステム LSIの機能モデ ルの実装コード生成処理手順を示すフローチャートである。図 21に示す処理手順は 、図 5のステップ S503に示した処理ステップの詳細な処理手順を示している。
[0124] まず、ステップ S502において生成された概念モデルの設計クラス図（図 17を参照 。）を、並行、並列なモジュールに分割する（ステップ S2101)。図 22は、図 17に示し た設計クラス図を分割することによって得られた分割設計クラス図を示す説明図であ る。
[0125] 図 17に示した設計クラス図は、図 22において、トップモジュールに関する分割設計 クラス図 2210と、コントローラモジュールに関する分割設計クラス図 2220と、ェンコ ーダモジュールに関する分割設計クラス図 2230と、デコーダモジュールに関する分 割設計クラス図 2240と、に分割されている。
[0126] そして、この分割設計クラス図 2210— 2240によってあらわされるモジュール間を 接続する通信路を決定する（ステップ S2102)。図 23は、分割設計クラス図によって あらわされるモジュール間を接続する通信路を示す説明図である。
[0127] 卜ップモジユーノレ 2301 fま、ポー卜 2311一 2315を有してレヽる。このポー卜 2311一 2 315は、トップモジュールに関する分割設計クラス図 2210の属性 2211に記述されて いる。具体的には、ポート 2311は「packet_i:sc_fifo_inく Packet〉」を示しており、 CPUか らのパケットく Packet>を入力する入力ポートである。ポート 2312は「
packet_o:sc_fifo_outく Packet〉」を示しており、パケットく Packet>を CPUに出力する出力 ポートである。ポート 2313は「error_o:sc_fifo_outく ERR_TYPE>」を示しており、エラータ ィプ情報く ERR_TYPE>を CPUに出力する出力ポートである。
[0128] また、ポート 231 i「encoded_packet_o:sc_fifo_out〈EncodedPacket〉」を示しており、 符号化されたパケットく EncodedPacke を出力する出力ポートである。ポート 2315は 「received_packet_i:sc_fifo_inく ReceivedPacket〉」を示しており、外部から受信されたパ ケッ KReceivedPacket〉を入力する入力ポートである。
[0129] コン卜ローラモジユーノレ 2302fま、ポー卜 2321一 2327を有してレヽる。このポー卜 232 1一 2327は、コントローラモジュール 2302に関する分割設計クラス図 2220の属性 2 221に記述されてレ、る。具体的には、ポート 2321は「cpu_packet_i:sc_fifo_inく Packet〉 」を示しており、 CPUからのパケットく Packet〉を入力する入力ポートである。ポート 23 22は「cpu_packet_o:sc_fifo_outく Packet>」を示しており、パケットく Packet>を CPUに出 力する出力ポートである。ポート 2323は「error_o:s fifo_outく ERR_TYPE〉」を示してお り、エラータイプ情報く ERR_TYPE>を CPUに出力する出力ポートである。 [0130] また、ポート 2324は「encoder_packet_o:sc_fifo_outく Packet>」を示しており、パケットく Packet>をエンコーダモジュールに出力する出力ポートである。ポート 2325は「 encoder_status_i:sc_fifo_inく bool>」を示しており、エンコーダモジュール 2303のステー タス情報く bool〉を入力する入力ポートである。ポート 2326は「
decoder_packet_i:sc_fifo_inく Packet>」を示しており、デコーダモジユーノレからパケットく Packet>を入力する入力ポートである。ポート 2327は「decoder_error_i:sc_fifo_inく ERR_TYPE>」を示しており、デコーダモジュールからエラータイプ情報く ERR_TYPE〉を 入力する入力ポートである。
[0131] エンコーダモジユーノレ 2303fま、ポート 2331一 2333を有してレヽる。このポート 233 1一 2333は、エンコーダモジュール 2303に関する分割設計クラス図 2230の属性 2 231に記述されてレ、る。具体的には、ポート 2331は「packet_i:sc_fifo_in_ifく Packet>」を 示しており、パケットく Packet〉を入力する入力ポートである。ポート 2332は「
status_o:sc_fifo_outく bool〉」を示しており、エンコーダモジュール 2303のステータス情 報く bool〉を出力する出力ポートである。ポート 2333は「packet_o:sc_fifo_out_ifく
EncodedPacket>Jを示しており、エンコーダモジュール 2303によって符号化されたパ ケッ KEncodedPacke を出力する出力ポートである。
[0132] デコーダモジュール 2304は、ポート 2341— 2343を有している。このポート 2341 一 2343は、デコーダモジュール 2304に関する分割設計クラス図 2240の属性 2241 に記述されている。具体的には、ポート 2341は「packet_o:sc_fifo_outく Packet>」を示し ており、パケットく Packet〉を出力する出力ポートである。ポート 2342は「
error_o:sc_fifo_outく ERR_TYPE〉」を示しており、エラータイプ情報く ERR_TYPE〉を出力 する出力ポートである。ポート 2343は「packet_i:sc_fifo_inく ReceivedPacket>」を示して おり、受信されたパケットく ReceivedPacket〉を入力する入力ポートである。
[0133] このように、分割設計クラス図 2210 2240の属性を用いて、ポート 2311 2315 、ポー卜 2321— 2327、ポー卜 2331— 2333、ポート 2341— 2343どうしを接続して、 通信路 2351— 2359を決定する。この通信路 2351— 2359fま、具体白勺 ίこ fま FIFO 方式で通信をおこなう通信路である。
[0134] また、図 21において、通信路を決定した後、機能モデルの実装コードを生成する（ ステップ S2103)。ここで、シリアル送受信システムを含むシステム LSIの機能モデル の実装コードの生成例について説明する。図 24は、シリアル送受信システムを含む システム LSIの機能モデルの実装コードの生成例を示す説明図である。
[0135] 図 24では、エンコーダモジュール 2303に関する分割設計クラス図 2230力、ら生成 した、エンコーダモジュール 2303の実装コード 2400を示している。なお、図示はし ないが、トップモジュールに関する分割設計クラス図 2210、コントローラモジュール 2 302に関する分割設計クラス図 2220、およびデコーダモジュール 2304に関する分 割設計クラス図 2240についても、それぞれ実装コードを生成する。そして、図 5のス テツプ S504では、各分割設計クラス図 2210— 2240の実装コードのシミュレーション を実行することとなる。
[0136] このあと、図 5のステップ S505において、このシミュレーション結果と、概念モデル の実装コードのシミュレーション結果との一致判定をおこなレ、、一致する場合 (ステツ プ S505 :Yes)、図 22に示したモジュール分割が正当であり、また、モジュール分割 の並列、並行性が正確であることとなる。
[0137] 一方、一致しない場合 (ステップ S505 : No)、図 22に示したモジュール分割が正当 でなぐまた、モジュール分割の並歹 IJ、並行性が不正確であるとして、図 5のステップ S506におレヽて、図 21のステップ S2103で生成された実装コードの修正処理をおこ なう。この機能モデル検証により、概念モデルと同一の検証結果になることを確認す ること力 Sできる。
[0138] (シリアル送受信システムを含むシステム LSIのアーキテクチャモデル）
つぎに、シリアル送受信システムを含むシステム LSIのアーキテクチャモデルにつ いて説明する。図 25は、シリアル送受信システムを含むシステム LSIのァーキテクチ ャモデルのクラス図の一例を示す説明図である。アーキテクチャモデルは、バスや IP などの既存設計の物理的なハードウェア部品をあらわすモデルであり、ここでは、バ スモデルをあらわしてレ、る。
[0139] アーキテクチャモデルは、基本的に事前に用意され、検証済みのライブラリとして提 供され、図 25では、検証済みのバスモデルが記述されている。このように、このァー キテクチャモデルでは、既存設計の物理的なハードウェア部品を用いているため、検 証をおこなう必要はない。
[0140] (シリアル送受信システムを含むシステム LSIの動作モデル）
つぎに、シリアル送受信システムを含むシステム LSIの動作モデルについて説明す る。動作モデルは、上述したように、概念的に、機能モデルをアーキテクチャモデル にマッピングした結果物である。図 26は、機能モデルとアーキテクチャモデルとのマ ッビングを示す説明図である。
[0141] 図 26において、機能モデノレ 2600は、図 23に示したように、外部から受信したパケ ットをデコーダ 2602が入力して復号し、コントローラ 2603に供給する。コントローラ 2 603は復号されたパケットをエンコーダ 2604に出力し、エンコーダ 2604はパケットを 符号化する。
[0142] アーキテクチャモデル 2610は、バスや IPなどの既存設計の物理的なハードウェア 部品をあらわすモデルであり、ここでは、プロセッサ 2611、メモリ 2612、外部入力 1/ F2613、外部出力 I/F2614、 ノヽードウエア 2615、 ハードウェア 2616、 ハードウェア 2617、およびこれらを接続するバス 2618から構成されてレ、る。
[0143] そして、このアーキテクチャモデル 2610に、機能モデル 2600をマッピングする。具 体的には、デコーダ 2602をハードウェア 2615に、コントローラ 2603をハードウェア 2 616に、エンコーダ 2604をハードウェア 2617にマッピングする。この図 25および図 26を用いて説明した内容は、図 5のステップ S507に示した処理ステップに相当する 内容である。
[0144] (シリアル送受信システムを含むシステム LSIの動作モデルの実装コード生成処理手 順）
つぎに、シリアル送受信システムを含むシステム LSIの動作モデルの実装コード生 成処理手順について説明する。図 27は、シリアル送受信システムを含むシステム LS Iの動作モデルの実装コード生成処理手順を示すフローチャートである。この図 27に 示す処理手順は、図 5のステップ S507に示した処理ステップの詳細な処理手順を示 している。
[0145] まず、図 26に示したマッピングを実現するため、図 22に示した分割設計クラス図 22 10一 2240の属十生 2211一 2241内の記述を、図 25(こ示したノ スモデノレの記述 (こ置 き換える（ステップ S2701)。図 28は、属性 2211内の記述がバスモデルの記述に置 き換えられた分割設計クラス図 2210を示す説明図である。図 28中、アンダーライン の記述箇所において、通信路が、 FIFO方式の記述からバスモデルの記述に置き換 えられている。
[0146] つぎに、バスモデルの記述に置き換えられた分割設計クラス図 2210 2240から、 機能モデルの実装コードを生成する（ステップ S2702)。そして、生成された機能モ デルの実装コードに、各モジュールの見積もり処理時間を追加する（ステップ S2703
[0147] 図 29は、各モジュールの見積もり処理時間の実装コードへの追加例を示す説明図 である。たとえば、図 29に示した図表 2900により、デコーダ 2602およびエンコーダ 2 604の見積もり処理時間を、それぞれ 600 [ns]とすると、機能モデルの実装コード（ たとえば、図 24に示した実装コード 2400)に、図表 2900に示した処理時間に関す る記述 2901を追加する。これにより、動作モデルの実装コード 2902が生成される。 そして、図 5のステップ S508では、動作モデルの実装コード 2902のシミュレーション を実行することとなる。
[0148] このあと、図 5のステップ S508において、このシミュレーション結果と、概念モデル の実装コードのシミュレーション結果との一致判定をおこない、一致する場合 (ステツ プ S509 : Yes)、動作モデルの実装コード 2902のシミュレーション結果力 図 13に 示した要求項目リスト 1300のすベての要求項目 1301— 1308を満足することとなり 、機能モデルとアーキテクチャモデルとのマッピングが正当であることとなる。
[0149] 一方、一致しない場合（ステップ S509 : No)、動作モデルの実装コード 2902のシミ ユレーシヨン結果力 図 13に示した要求項目リスト 1300のすベての要求項目 1301 一 1308を満足しておらず、機能モデルとアーキテクチャモデルとのマッピングが正 当でないこととなる。この場合、図 5のステップ S510において、動作モデルの実装コ ード 2902の修正処理をおこなうこととなる。これにより、顧客が要求した動作 (性能） を満足するかどうかの検証をおこなうことができる。
[0150] (シリアル送受信システムを含むシステム LSIの ICAモデルの実装コード生成処理手 順） つぎに、シリアル送受信システムを含むシステム LSIの ICAモデルの実装コード生 成処理手順について説明する。図 30は、シリアル送受信システムを含むシステム LS Iの ICAモデルの実装コード生成処理手順を示すフローチャートである。この図 30に 示す処理手順は、図 5のステップ S511に示した処理ステップの詳細な処理手順を示 している。
[0151] ICAモデルは、上述したように、モジュール外のインターフェースについてはサイク ル精度によって、モジュール内部は動作レベルによって構築したモデルである。この ICAモデルを高位合成することによって RTL記述を生成する。この ICAモデルでは 、インターフェースの正確さの検証をおこなうことができる。
[0152] まず、通信路が決定された機能モデルの構造図から、抽象度の異なるモジュール 間を通信する通信路を検出する（ステップ S3001)。図 31は、シリアル送受信システ ムを含むシステム LSIの通信路が決定された機能モデルを示す構造図である。
[0153] 図 31において、シリアル送受信システムは、図 17に示した設計クラス図を、並行、 並列なモジュールに分割された結果（図 21のステップ S2101を参照。）、トップモジュ 一ノレ 2301と、 CPUモジユーノレ 3101と、送信器モジユーノレ 3102と、受信器モジユー ノレ 3103と力 FIFO方式の通信路 3111— 3115によって接続されたシステムである 。また、トップモジュール 2301の内部は、図 23に示した構造図と同一内容である。こ れらのモジュールの接続関係から、抽象度の異なるモジュール間を通信する通信路 を検出する。
[0154] つぎに、検出された通信路を、インターフェースラッパに置換する（ステップ S3002 )。図 32は、図 31に示した構造図内の通信路にインターフェースラッパを挿入した構 造図である。図 32では、図 31において、エンコーダモジュール 2302の抽象度と送 信器モジュール 3102の抽象度が異なっているため、このモジユーノレ 2302、 3102間 の通信路 3114をインターフェースラッパ 3201に揷入し、トップモジユーノレ 2301の抽 象度を変換する。
[0155] インターフェースラッパ 3201は、送信器モジュール 3102のトランザクションレベル のポート 3102aと接続されるトランザクションレベルインターフェース 3202と、トップモ ジユーノレ 2301 ίこ接続される 2つの信号レべノレポート 3203， 3204を備えてレヽる。この ため、トランザクションレべノレのポート 2314を、送信レべノレポート 3210、 3211【こ置さ 换 る。
[0156] また、トップモジュール 2301内部のエンコーダモジュール 2303のトランザクション レべノレのポート 2331一 2333も、信号レべノレのポート 3212一 3216ίこ置き換免る。こ のポート変換により、コントローラモジュール 2302のトランザクションレベルのポート 2 324、 2325も、信号レべノレのポート 3217一 3219(こ変換される。
[0157] このように、エンコーダモジュール 2303のポート数が変更されるため、図 31に示し たエンコーダモジュール 2303を ICAモデルのエンコーダモジュールに変換し（ステ ップ S3003)、エンコーダモジュール 2303自体の抽象度を変換する。図 33は、 ICA モデルのエンコーダモジュールの内部構造の一例を示す説明図である。
[0158] 図 33において、 ICAモデルのエンコーダモジュール 3300は、図 31に示したェンコ 一ダモジユーノレ 2303およびポート 2331一 2333を備えてレ、る。そして、ポート 2331 、 2332と、ポート 3212— 3214との間の通信を可能とするため、各種ラッパやポート 力 S挿人されてレヽる。同様に、ポート 2333と、ポート 3215、 3216との間の通信も可言 とするため、各種ラッパやポートが挿入されている。
[0159] このあと、 ICAモデルのエンコーダモジュール 3300の実装コードを生成する（ステ ップ S3004)。図 34は、 ICAモデルのエンコーダモジュール 3300の実装コードの一 例を示す説明図である。そして、図 5のステップ S512では、 ICAモデルの実装コード 3400のシミュレーションを実行することとなる。
[0160] このあと、図 5のステップ S513において、 ICAモデルの実装コード 3400のシミュレ ーシヨン結果と、概念モデルの実装コードのシミュレーション結果との一致判定をおこ なレ、、一致する場合（ステップ S513 : Yes)、 ICAモデルの実装コード 3400のシミュ レーシヨン結果力 S、図 13に示した要求項目リスト 1300のすベての要求項目 1301— 1308を満足することとなり、インターフェースラッパの揷入が正当であることとなる。
[0161] 一方、一致しない場合（ステップ S513 : No)、 ICAモデルの実装コード 3400のシミ ユレーシヨン結果力 図 13に示した要求項目リスト 1300のすベての要求項目 1301 一 1308を満足しておらず、インターフェースラッパの揷入が正当でないこととなる。
[0162] そして、図 5に示したステップ S514において、 ICAモデルの実装コード 3400の修 正処理をおこなうこととなる。これにより、インターフェースの正確さの検証をおこなうこ とができる。
[0163] (シリアル送受信システムを含むシステム LSIのソフトウェアモデルの実装コード生成 処理手順）
つぎに、シリアル送受信システムを含むシステム LSIのソフトウェアモデルの実装コ ード生成処理手順について説明する。図 35は、シリアル送受信システムを含むシス テム LSIのソフトウェアモデルの実装コード生成処理手順を示すフローチャートである 。この図 35に示す処理手順は、図 5のステップ S516に示した処理ステップの詳細な 処理手順を示している。
[0164] ソフトウェアモデルは、上述したように、シリアル送受信システムを含むシステム LSI を構成するソフトウェアのタスク分割をおこなレ、、仮想〇S上に実行するモデルである 。図 35において、まず、アーキテクチャモデルに機能モデルの一部をソフトウェアに よりマッピングする（ステップ S 3501)。
[0165] 図 36は、アーキテクチャモデルに機能モデルの一部をソフトウェアによりマッピング をおこなった例を示す説明図である。具体的には、図 26に示したように、デコーダ 26 02はハードウェア 2615にマッピングし、エンコーダ 2604はハードウェア 2617にマツ ビングする。一方、 CPU2601およびコントローラ 2603は、プロセッサ 2611にマツピ ングする。
[0166] つぎに、このマッピングにより、ソフトウェアモデルにおける設計クラス図を生成する（ ステップ S3502)。図 37は、ソフトウェアモデルにおける設計クラス図を示す説明図 である。図 37において、ソフトウェアモデルにおける設計クラス図 3700は、図 22に示 した分割設計クラス図 2210— 2240を元にして生成される。
[0167] ソフトウェアモデルにおける設計クラス図 3700は、トップモジュールに関する分割 設計クラス図 3701と、デコーダモジュールに関する分割設計クラス図 3702と、ェン コーダモジュールに関する分割設計クラス図 3703のほかに、仮想 OSモデルに関す る分割設計クラス図 3704を含んでいる。そして、設計クラス図 3701 3704ごとに、 ソフトウェアモデルの実装コードを生成する（ステップ S3503)。
[0168] このあと、図 5のステップ S517において、ソフトウェアモデルの実装コードのシミュレ ーシヨンを実行することとなる。そして、図 5のステップ S518において、ソフトウェアモ デルの実装コードのシミュレーション結果と、概念モデルの実装コードのシミュレーシ ヨン結果との一致判定をおこなう。そして、一致する場合 (ステップ S518 : Yes)、ソフ トウエアモデルの実装コードのシミュレーション結果力 S、図 13に示した要求項目リスト 1300のすベての要求項目 1301 1308を満足することとなり、ソフトウェアのタスク 分割が正当であることとなる。
[0169] 一方、一致しない場合（ステップ S518 : No)、ソフトウェアモデルの実装コードのシ ミュレーシヨン結果力 S、図 13に示した要求項目ジス卜 1300のすベての要求項目 1301 一 1308を満足しておらず、ソフトウェアのタスク分割が正当でないこととなる。
[0170] そして、図 5に示したステップ S519において、ソフトウェアモデルの実装コードの修 正処理をおこなうこととなる。これにより、ソフトウェアのタスク分割の正確さの検証をお こなうこと力 Sできる。
[0171] この発明の実施の形態にかかる検証支援装置および検証支援方法によれば、仕 様リスクの早期回避を図ることができる。具体的には、顧客要求を UMLで分析した上 で、実行可能なモデルを用いて顧客の機能要求に満足するかどうかを検証すること ができ、仕様の誤解やミスを早期に発見することができ、誤った仕様に基づくシステ ム LSIの設計を防止することができる。
[0172] また、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば 、シミュレーションスピードネックの解決を図ることができる。具体的には、従来の検証 手法では RTLのシミュレータを用いてシミュレーションおこなうため、シミュレーション 速度が非常に遅いという問題があった力 この実施の形態では、より抽象度の高いモ デルを用いてシミュレーションを実行するため、 RTLのシミュレータに比べて数百倍 の速度でシミュレーションを実行することができる。したがって、このシミュレーション速 度の向上により、検証作業を含めた設計期間の短縮化を図ることができる。
[0173] さらに、この発明の実施の形態にかかる検証支援装置および検証支援方法によれ ば、コストの削減を図ることができる。具体的には、従来の検証手法では大規模な LS Iの場合に高価なエミュレータを導入する必要があつたが、この発明の実施の形態で は、抽象度の高いモデルの検証によりエミュレータの利用頻度を大幅に減少すること ができ、コストの削減を図ることができる。また、エミュレータの利用は基本的に時間単 位でお金に換算されるケースが多いため、検証時間の短縮化によって費用の低減を 図ること力 Sできる。
[0174] また、この発明の実施の形態にかかる検証支援装置および検証支援方法によれば 、早期仕様のミスをなくすことによって検証工程の短縮化を図ることができる。
[0175] また、従来手法に対するより効果的な改善点として、従来手法では RTLが完成され ていないと検証工程をおこなうことができな力、つた力 この発明の実施の形態では、 設計の初期の段階力 検証を開始することができる。また、設計の詳細度に応じて各 モデルに対してその正当性を検証することができる。これにより、従来における設計 終了→検証スタートとレ、う手法に対して、大幅の設計工程の短縮化を図ることができ る。
[0176] さらに、この発明の実施の形態にかかる検証支援装置および検証支援方法によれ ば、定量的なアーキテクチャ評価をおこなうことができる。具体的には、従来手法では RTLの HDLを完成しない限り、性能評価できないという問題点があった力 RTLの HDLを完成してから性能に満足しないという理由で設計変更をおこなうと、非常に高 レ、コストがかかることとなる。
[0177] これに対し、この発明の実施の形態では、早期の段階で RTLによる抽象度の高い 動作モデルに対してラフな性能 (動作)を見積ることができ、性能 (動作）に満足しな レヽとレ、うリスクの低減を図ることができる。
[0178] また、上述した具体例では、シリアル送受信システムを含むシステム LSIを例に挙 げて説明したが、このシステム LSIには限定されることはなぐ各種システム LSIに適 用すること力 Sできる。
[0179] なお、この実施の形態で説明した検証支援方法は、予め用意されたプログラムをパ ーソナル.コンピュータやワークステーション、 CAD等のコンピュータで実行すること により実現すること力 Sできる。このプログラムは、ハードディスク、フレキシブルディスク 、 CD-ROM, MO、 DVD等のコンピュータで読み取り可能な記録媒体に記録され、 コンピュータによって記録媒体から読み出されることによって実行される。またこのプ ログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体で あってもよい。
産業上の利用可能性
以上のように本発明は、たとえば、 LSIの設計データの検証をおこなうシステムゃッ ールを提供することに適している。

Claims

請求の範囲
[1] LSIの設計対象に関する要求仕様の分析結果を示す分析情報の入力を受け付け る分析情報入力手段と、
前記分析情報入力手段によって入力された分析情報に基づいて、前記設計対象 の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび 時間の概念が抽象化された概念モデルを生成する概念モデル生成手段と、 前記分析情報入力手段によって入力された分析情報に基づいて、前記設計対象 を構成するモジュールの分割、および分割されたモジュールの並行または並列性を 抽出することによってモデル化された機能モデルを生成する機能モデル生成手段と 前記機能モデル生成手段によって生成された機能モデルについて、前記設計対 象を構成するモジュールの分割、および分割されたモジュールの並行または並列性 が正当であるかどうかを、前記概念モデル生成手段によって生成された概念モデル に基づレ、て検証する機能モデル検証手段と、
を備えることを特徴とする検証支援装置。
[2] 複数種類の物理的なアーキテクチャに関する情報を記憶する記憶手段と、
前記機能モデル検証手段によって正当であることが検証された場合、前記記憶手 段力 任意のアーキテクチャに関する情報を抽出する抽出手段と、
前記抽出手段によって抽出されたアーキテクチャに関する情報を、前記機能モデ ル検証手段によって正当であることが検証された機能モデルにマッピングすることに より、前記設計対象の動作をモデル化した動作モデルを生成する動作モデル生成 手段と、
前記動作モデル生成手段によって生成された動作モデルによりモデル化された設 計対象を構成するモジュールの動作タイミング力 正当であるかどうかを検証する動 作モデル検証手段と、
を備えることを特徴とする請求項 1に記載の検証支援装置。
[3] 前記動作モデル検証手段によって正当であることが検証された場合、前記機能モ デルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇 所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入す ることにより ICAモデルを生成する ICAモデル生成手段と、
前記 ICAモデル生成手段によって生成された ICAモデルに挿入されたインターフ エースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成手段に よって生成された概念モデルに基づいて検証する ICAモデル検証手段と、 を備えることを特徴とする請求項 2に記載の検証支援装置。
[4] 前記動作モデル検証手段によって正当であることが検証された場合、前記機能モ デルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能な タスクを含むようにモデル化されたソフトウェアモデルを生成するソフトウェアモデル 生成手段と、
前記ソフトウェアモデル生成手段によって生成されたソフトウェアモデルに含まれて レ、るタスクが正当であるかどうかを、前記概念モデル生成手段によって生成された概 念モデルに基づいて検証するソフトウェアモデル検証手段と、
を備えることを特徴とする請求項 2または 3に記載の検証支援装置。
[5] LSIの設計対象に関する要求仕様の分析結果を示す分析情報を入力する分析情 報入力工程と、
前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象 の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび 時間の概念が抽象化された概念モデルを生成する概念モデル生成工程と、 前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象 を構成するモジュールの分割、および分割されたモジュールの並行または並列性を 抽出することによってモデル化された機能モデルを生成する機能モデル生成工程と 前記機能モデル生成工程によって生成された機能モデルについて、前記設計対 象を構成するモジュールの分害 ij、および分割されたモジュールの並行または並列性 が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデル に基づレ、て検証する機能モデル検証工程と、
を含んだことを特徴とする検証支援方法。
[6] 前記機能モデル検証工程によって正当であることが検証された場合、複数種類の 物理的なアーキテクチャに関する情報の中から、任意のアーキテクチャに関する情 報を抽出する抽出工程と、
前記抽出工程によって抽出されたアーキテクチャに関する情報を、前記機能モデ ル検証工程によって正当であることが検証された機能モデルにマッピングすることに より、前記設計対象の動作をモデル化した動作モデルを生成する動作モデル生成 工程と、
前記動作モデル生成工程によって生成された動作モデルによりモデル化された設 計対象を構成するモジュールの動作タイミング力 正当であるかどうかを検証する動 作モデル検証工程と、
を含んだことを特徴とする請求項 5に記載の検証支援方法。
[7] 前記動作モデル検証工程によって正当であることが検証された場合、前記機能モ デルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇 所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを挿入す ることにより ICAモデルを生成する ICAモデル生成工程と、
前記 ICAモデル生成工程によって生成された ICAモデルに挿入されたインターフ エースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成工程に よって生成された概念モデルに基づいて検証する ICAモデル検証工程と、
を含んだことを特徴とする請求項 6に記載の検証支援方法。
[8] 前記動作モデル検証工程によって正当であることが検証された場合、前記機能モ デルによってモデルィ匕された設計対象に基づいて、ソフトウェアによって実行可能な タスクを含むようにモデル化されたソフトウェアモデルを生成するソフトウェアモデル 生成工程と、
前記ソフトウェアモデル生成工程によって生成されたソフトウェアモデルに含まれて レ、るタスクが正当であるかどうかを、前記概念モデル生成工程によって生成された概 念モデルに基づいて検証するソフトウェアモデル検証工程と、
を含んだことを特徴とする請求項 6または 7に記載の検証支援方法。
[9] LSIの設計対象に関する要求仕様の分析結果を示す分析情報を入力させる分析 情報入力工程と、
前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象 の基本機能がモデル化され、かつ、前記設計対象の物理的なアーキテクチャおよび 時間の概念が抽象化された概念モデルを生成させる概念モデル生成工程と、 前記分析情報入力工程によって入力された分析情報に基づいて、前記設計対象 を構成するモジュールの分害 I および分割されたモジュールの並行または並列性を 抽出することによってモデル化された機能モデルを生成させる機能モデル生成工程 と、
前記機能モデル生成工程によって生成された機能モデルについて、前記設計対 象を構成するモジュールの分害 ij、および分割されたモジュールの並行または並列性 が正当であるかどうかを、前記概念モデル生成工程によって生成された概念モデル に基づいて検証させる機能モデル検証工程と、
をコンピュータに実行させることを特徴とする検証支援プログラム。
[10] 前記機能モデル検証工程によって正当であることが検証された場合、複数種類の 物理的なアーキテクチャに関する情報の中から、任意のアーキテクチャに関する情 報を抽出させる抽出工程と、
前記抽出工程によって抽出されたアーキテクチャに関する情報を、前記機能モデ ル検証工程によって正当であることが検証された機能モデルにマッピングすることに より、前記設計対象の動作をモデル化した動作モデルを生成させる動作モデル生成 工程と、
前記動作モデル生成工程によって生成された動作モデルによりモデル化された設 計対象を構成するモジュールの動作タイミング力 正当であるかどうかを検証させる 動作モデル検証工程と、
を含んだことを特徴とする請求項 9に記載の検証支援プログラム。
[11] 前記動作モデル検証工程によって正当であることが検証された場合、前記機能モ デルによってモデル化された設計対象を構成するモジュール間の抽象度が異なる箇 所に、当該モジュール間に所定のクロックサイクル精度のインターフェースを揷入す ることにより ICAモデルを生成させる ICAモデル生成工程と、 前記 ICAモデル生成工程によって生成された ICAモデルに挿入されたインターフ エースのクロックサイクル精度が正当であるかどうかを、前記概念モデル生成工程に よって生成された概念モデルに基づいて検証させる ICAモデル検証工程と、 を含んだことを特徴とする請求項 10に記載の検証支援プログラム。
[12] 前記動作モデル検証工程によって正当であることが検証された場合、前記機能モ デルによってモデル化された設計対象に基づいて、ソフトウェアによって実行可能な タスクを含むようにモデル化されたソフトウェアモデルを生成させるソフトウェアモデル 生成工程と、
前記ソフトウェアモデル生成工程によって生成されたソフトウェアモデルに含まれて レ、るタスクが正当であるかどうかを、前記概念モデル生成工程によって生成された概 念モデルに基づいて検証させるソフトウェアモデル検証工程と、
を含んだことを特徴とする請求項 10または 11に記載の検証支援プログラム。
[13] 請求項 9一 12のいずれか一つに記載の検証支援プログラムを記録したコンビユー タ読取り可能な記録媒体。
PCT/JP2004/009340 2004-07-01 2004-07-01 検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体 WO2006003702A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CNA2004800435084A CN1981288A (zh) 2004-07-01 2004-07-01 验证支援装置、验证支援方法、验证支援程序以及记录介质
PCT/JP2004/009340 WO2006003702A1 (ja) 2004-07-01 2004-07-01 検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体
JP2006527616A JPWO2006003702A1 (ja) 2004-07-01 2004-07-01 検証支援装置、検証支援方法、および検証支援プログラム
EP04746809A EP1770562A4 (en) 2004-07-01 2004-07-01 VERIFICATION SUPPORT SETUP, VERIFICATION SUPPORT PROCEDURE, VERIFICATION SUPPORT PROGRAM AND RECORDING MEDIUM
US11/645,715 US7640521B2 (en) 2004-07-01 2006-12-27 Model verification support method, apparatus, and computer-readable recording medium storing program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2004/009340 WO2006003702A1 (ja) 2004-07-01 2004-07-01 検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/645,715 Continuation US7640521B2 (en) 2004-07-01 2006-12-27 Model verification support method, apparatus, and computer-readable recording medium storing program

Publications (1)

Publication Number Publication Date
WO2006003702A1 true WO2006003702A1 (ja) 2006-01-12

Family

ID=35782519

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/009340 WO2006003702A1 (ja) 2004-07-01 2004-07-01 検証支援装置、検証支援方法、検証支援プログラムおよび記録媒体

Country Status (5)

Country Link
US (1) US7640521B2 (ja)
EP (1) EP1770562A4 (ja)
JP (1) JPWO2006003702A1 (ja)
CN (1) CN1981288A (ja)
WO (1) WO2006003702A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010231633A (ja) * 2009-03-27 2010-10-14 Fujitsu Ltd 検証支援プログラム、検証支援装置および検証支援方法
JP2010271900A (ja) * 2009-05-21 2010-12-02 Fujitsu Ltd クラス図分割支援方法、クラス図分割支援装置、及びプログラム

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8296739B2 (en) * 2008-03-31 2012-10-23 International Business Machines Corporation Testing soft error rate of an application program
FR2964224A1 (fr) * 2010-08-24 2012-03-02 Thales Sa Procede et dispositif de deploiement et d'aide au deploiement de composants formant un systeme temps reel embarque
US8972928B2 (en) * 2011-08-30 2015-03-03 Uniquesoft, Llc System and method for generating application code
CN104516992B (zh) * 2013-09-27 2017-12-01 华为技术有限公司 一种验证方法及装置
US10853536B1 (en) * 2014-12-11 2020-12-01 Imagars Llc Automatic requirement verification engine and analytics
US10387788B2 (en) * 2016-02-18 2019-08-20 Linkedin Corporation Graph based techniques for predicting results
CN112949234A (zh) * 2021-04-14 2021-06-11 山东高云半导体科技有限公司 Fpga物理模型的软件建模方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002279011A (ja) * 2000-12-28 2002-09-27 Fujitsu Ltd 論理装置の動作シミュレーション方法並びに論理装置の動作シミュレーションプログラム及び同プログラムを記録したコンピュータ読み取り可能な記録媒体
JP2003288378A (ja) * 2002-03-28 2003-10-10 Cats Kk システムｌｓｉ設計支援プログラム、システムｌｓｉ制御回路およびｐｃ用集積回路

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6789054B1 (en) * 1999-04-25 2004-09-07 Mahmoud A. Makhlouf Geometric display tools and methods for the visual specification, design automation, and control of adaptive real systems
US7085688B1 (en) * 1999-10-22 2006-08-01 Shizuo Sumida Non-linear characteristic reproducing apparatus and non-linear characteristic reproducing program storage medium
US7356786B2 (en) * 1999-11-30 2008-04-08 Synplicity, Inc. Method and user interface for debugging an electronic system
KR20000023961A (ko) * 1999-12-22 2000-05-06 김정태 정보 모델링방법 및 데이터베이스 검색시스템
JP3897948B2 (ja) * 2000-02-14 2007-03-28 富士通株式会社 支援システムおよび支援プログラムを記録したコンピュータ読み取り可能な記録媒体
EP1222530A2 (en) * 2000-03-09 2002-07-17 Koninklijke Philips Electronics N.V. Method for developing complex systems
US7389208B1 (en) * 2000-06-30 2008-06-17 Accord Solutions, Inc. System and method for dynamic knowledge construction
US7234126B2 (en) * 2000-08-23 2007-06-19 Interuniversitair Microelektronica Centrum Task concurrency management design method
JP4743944B2 (ja) * 2000-08-25 2011-08-10 鎮男 角田 シミュレーションモデル作成方法及びそのシステムと記憶媒体
US20020124085A1 (en) * 2000-12-28 2002-09-05 Fujitsu Limited Method of simulating operation of logical unit, and computer-readable recording medium retaining program for simulating operation of logical unit
JP3877753B2 (ja) * 2003-10-31 2007-02-07 富士通株式会社 設計支援装置、設計支援方法および設計支援プログラム
JP4001584B2 (ja) * 2004-02-26 2007-10-31 松下電器産業株式会社 シミュレーション装置
US7469201B2 (en) * 2005-06-17 2008-12-23 Dspace Digital Signal Processing And Control Engineering Gmbh Process and means for block-based modeling
JP4445480B2 (ja) * 2006-03-23 2010-04-07 富士通株式会社 シナリオ生成方法、シナリオ生成プログラム、シナリオ生成装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002279011A (ja) * 2000-12-28 2002-09-27 Fujitsu Ltd 論理装置の動作シミュレーション方法並びに論理装置の動作シミュレーションプログラム及び同プログラムを記録したコンピュータ読み取り可能な記録媒体
JP2003288378A (ja) * 2002-03-28 2003-10-10 Cats Kk システムｌｓｉ設計支援プログラム、システムｌｓｉ制御回路およびｐｃ用集積回路

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1770562A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010231633A (ja) * 2009-03-27 2010-10-14 Fujitsu Ltd 検証支援プログラム、検証支援装置および検証支援方法
JP2010271900A (ja) * 2009-05-21 2010-12-02 Fujitsu Ltd クラス図分割支援方法、クラス図分割支援装置、及びプログラム

Also Published As

Publication number Publication date
CN1981288A (zh) 2007-06-13
EP1770562A4 (en) 2009-08-26
EP1770562A1 (en) 2007-04-04
JPWO2006003702A1 (ja) 2008-04-17
US20070106490A1 (en) 2007-05-10
US7640521B2 (en) 2009-12-29

Similar Documents

Publication Publication Date Title
US7640521B2 (en) Model verification support method, apparatus, and computer-readable recording medium storing program
US8205174B2 (en) Integrated circuit modeling method and framework tool
CN101842789B (zh) 用于存储器抽象和使用该存储器抽象来验证的方法和装置
US6536031B2 (en) Method for generating behavior model description of circuit and apparatus for logic verification
US8326592B2 (en) Method and system for verifying electronic designs having software components
KR101770292B1 (ko) 컴퓨터 수행 가능한 모델 역공학 방법 및 장치
EP1913410A2 (en) Method and system for debug and test using replicated logic
JP4481762B2 (ja) 論理検証装置、論理検証方法、論理検証プログラムおよび記録媒体
Goli et al. Scalable simulation-based verification of SystemC-based virtual prototypes
CN115952758A (zh) 芯片验证方法、装置、电子设备及存储介质
US7984403B2 (en) Verification supporting system
CN118052196A (zh) 基于uvm的芯片验证测试方法、装置及电子设备
Zhu et al. System-on-chip validation using UML and CWL
Bombieri et al. On PSL properties re-use in SoC design flow based on Transaction Level Modeling
US8397189B2 (en) Model checking in state transition machine verification
JP5262909B2 (ja) 検証支援プログラム、検証支援装置および検証支援方法
US7207015B1 (en) Translation of an electronic integrated circuit design into hardware
US6668359B1 (en) Verilog to vital translator
US8756543B2 (en) Verifying data intensive state transition machines related application
CN112836455A (zh) 一种soc仿真方法及系统
Bombieri et al. Correct-by-construction generation of device drivers based on RTL testbenches
US20090319983A1 (en) Intellectual property model creating apparatus, intellectual property model creating method, and computer product
Grimm et al. Semiformal verification of software-controlled connections
Castillo et al. SystemC design flow for a DES/AES CryptoProcessor
Araújo et al. A SystemC-only design methodology and the CINE-IP multimedia platform

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480043508.4

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004746809

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11645715

Country of ref document: US

Ref document number: 2006527616

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Ref document number: DE

WWP Wipo information: published in national office

Ref document number: 2004746809

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11645715

Country of ref document: US