Database having a hierarchical structure utilized for designing system-on-chip integrated circuit devices and a method of designing the same

[0002] The present invention relates to a database used for design of an integrated circuit device and a method for designing an integrated circuit device using such a database. More specifically, the present invention relates to design technology for supporting system-on-chip implementation.

[0003] Conventionally, semiconductor devices for an electronic apparatus are fabricated in the following manner. LSIs prepared individually for each type such as a memory and a processor are formed on respective semiconductor chips, and such semiconductor chips are packaged on a motherboard such as a printed board.

[0004] In recent years, in an attempt of utilizing electronic apparatuses in a wider range of fields, semiconductor devices used for electronic apparatuses have been requested to reduce the size, weight, power consumption, and cost thereof. This trend is particularly evident in the field of digital information home appliances. In order to respond to such requests from the electronic apparatus industry, the semiconductor industry has been forced to shift the keystone thereof from emories to system LSIs. A system LSI is practically implemented by mounting memories and various logical circuits on one chip. Such system-on-chip implementation naturally requires process technology for enabling elements such as transistors having different structures to be formed on a common substrate. In addition, it requires great innovation in design technology.

[0005] As design technology for supporting such system-on-chip implementation, proposed is a design technique where data for designing a block composed of a plurality of cells for implementing a certain function (for example, one called a function block) is prepared beforehand, and such data is utilized to design a desired system LSI composed of a combination of such blocks. According to this technique, since the structure for implementing the function of each function block has been determined, only design of wiring between function blocks and peripheral circuits is required in the design of the entire semiconductor device. In this way, substantial improvement of design efficiency is intended.

[0006] However, the above conventional design technique only includes determining which blocks out of those obtained by lower-level design such as logic design and layout design should be used and how these blocks should be arranged and interconnected. It does not allow for flexible use of the respective blocks, such as using only some components of each block. This technique therefore may fail to fully satisfy a variety of requests directed to system LSIs such as size reduction.

[0007] In view of the above-noted problems with the prior art techniques, the present invention was made to construct a novel design system replacing the conventional design technique using blocks as described above. Specifically, an object of the present invention is to provide a database for design of an integrated circuit device where data usable for system verification is stored in a flexibly utilizable state, and a method for designing an integrated circuit device using such a database.

[0008] The database for design of an integrated circuit device according to the present invention includes a virtual core cluster including a plurality of virtual cores for storing data required for designing the integrated circuit device, the virtual core cluster being arranged in a hierarchical structure of a plurality of layers according to the levels of abstraction. The database further includes, for a target integrated circuit device to be designed and the other integrated circuit device that performs signal transmit/receive behavior with the target integrated circuit device, a test cluster for storing data required for verifying the function of the virtual cores and the function of a system constructed using the virtual cores, the test cluster being arranged in a hierarchical structure of the same number of layers as the virtual core cluster in correspondence with the respective hierarchical layers of the core cluster.

[0009] In the above database for design of an integrated circuit device, the test cluster preferably includes at least one of a test bench, a test scenario, a task, and a model.

[0010] The database for design of an integrated circuit device may further include a system verification database for verifying a system when the integrated circuit device is constructed by combining the virtual cores, the system verification database being arranged in a hierarchical structure of the same number of layers as the virtual core cluster in correspondence with the respective hierarchical layers of the virtual core cluster. In this case, the test cluster may be located in the system verification database.

[0011] The test cluster may be linked to the virtual core cluster.

[0012] In the database for design of an integrated circuit device, the virtual core cluster may include: specification/behavior virtual cores for storing data in specification/behavior levels required for constructing the integrated circuit device; and register transfer virtual cores for storing data in a function level required for satisfying the specification/behavior specified by the data stored in the specification/behavior virtual cores. In this case, the test cluster is arranged in a hierarchical structure of a specification layer, an behavioral layer, and a function layer.

[0013] In the above case, the test cluster may include in the specification layer a description relating to the input/output relationship between the target integrated circuit device and the other integrated circuit device that performs signal transmit/receive behavior with the target integrated circuit device.

[0014] In the case where the test cluster is located outside the virtual core cluster for the target integrated circuit device, the test cluster may include in the behavioral layer a description for generating data for activating a sequence in the behavioral layer of the virtual core cluster for the target integrated circuit device. This makes it possible to automatically verify the behavioral layer for the target integrated circuit device. In the above case, also, the test cluster may include in at least one of the behavioral layer and the function layer a description for receiving results of a sequence in the behavioral layer of the virtual core cluster for the target integrated circuit device. This makes it possible to further ensure the verification in the behavioral layer for the target integrated circuit device.

[0015] In the case where the test cluster is located inside the virtual core cluster for the target integrated circuit device, the test cluster may include in the function layer a description for controlling a sequence in the behavioral layer of the virtual core cluster for the target integrated circuit device.

[0016] The method for designing an integrated circuit device according to the present invention is a method for designing an integrated circuit device using a database for design. The database for design includes a plurality of virtual core clusters each including a plurality of virtual cores for storing data required for designing the integrated circuit device, each of the virtual core clusters being arranged in a hierarchical structure of a plurality of layers according to the levels of abstraction. The database further includes, for a target integrated circuit device to be designed and the other integrated circuit device that performs signal transmit/receive behavior with the target integrated circuit device, a test cluster for storing data required for verifying a system when the integrated circuit device is constructed by combining virtual cores in the virtual core clusters, the test cluster being arranged in a hierarchical structure of the same number of layers as the virtual core cluster in correspondence with the respective hierarchical layers of the virtual core cluster. The method includes the step of: when verification is performed for one layer among the plurality of layers of the virtual core cluster for the target integrated circuit device, performing signal transmit/receive behavior between layers in the same level as the one layer among the plurality of layers of the test clusters for the target integrated circuit device and the other integrated circuit device.

[0017] By the above method, the target integrated circuit device can be verified not only alone but also as the entire system in consideration of the matching with peripheral apparatuses. In addition, the following functions can be added.

[0018] The test cluster preferably includes at least one of a test bench, a scenario, a task, and a model.

[0019] When a given layer among the plurality of layers of the virtual core cluster is to be particularized into the next lower layer of the virtual core cluster and the test cluster, parameters may be supplied to the virtual core cluster and the test cluster and data in the next lower layer of the test cluster may be used.

[0020] In the above case, the virtual core cluster and the test cluster of the next lower layer may be selected from a table in the database for design.

[0021] Data in a given layer of the test cluster for the target integrated circuit device and data in any one of the plurality of layers of the test cluster for the other integrated circuit device may be used to generate data in the layer next lower than the given layer of the test cluster for the target integrated circuit device.

[0022] By using a description regarding a procedure of verification in addition to the data in the next lower layer of the test cluster for the target integrated circuit device, data and a description regarding a procedure of verification in the layer next lower than the next lower layer of the test cluster for the target integrated circuit device are generated.

[0023] FIG. 1 is a conceptual view of the construction of a virtual core design system (VCDS) for system LSI design in an embodiment of the present invention.

[0024] FIG. 2 is a view illustrating a basic task flow in the VCDS in the embodiment of the present invention.

[0025] FIG. 3 is a block circuit diagram of a functional portion of the system shown in FIG. 1.

[0026] FIG. 4 is a view illustrating the function of a virtual core (VC) cluster in the embodiment of the present invention.

[0027] FIG. 5 is a view showing the structure of a VC in the embodiment of the present invention.

[0028] FIG. 6 is a view illustrating the relationship between data and performance information of a VC in each layer in the embodiment of the present invention.

[0029] FIG. 7 shows an example of design data described in SDL format in the embodiment of the present invention.

[0030] FIG. 8 shows an example of data generated in a hardware section in the embodiment of the present invention.

[0031] FIG. 9 shows an example of data generated in a software section in the embodiment of the present invention.

[0032] FIG. 10 shows an environment used for verification of an behavioral layer in the embodiment of the present invention.

[0033] FIG. 11 shows an environment used for verification of a RT layer in the embodiment of the present invention.

[0034] FIG. 12 shows examples of meta data and instance data in the RT layer in the embodiment of the present invention.

[0035] FIG. 13 is a conceptual block diagram of processing done by a toggle analysis and circuit optimization section shown in FIG. 1.

[0036] FIG. 14 is a view illustrating an example of details of purpose-specific function verification models in the embodiment of the present invention.

[0037] FIG. 15 is a view illustrating use of a synchronization model in the purpose-specific function verification models in the embodiment of the present invention.

[0038] FIG. 16 is a view illustrating a flow (test scenario) of a test using a shared test cluster and a periphyral model cluster in a system verification database in the embodiment of the present invention.

[0039] FIG. 17 is a block diagram illustrating a method for optimizing the fault inspection strategy in the embodiment of the present invention.

[0040] FIG. 18 is a block diagram illustrating the behavior of a function verification assist section in the embodiment of the present invention.

[0041] FIG. 19 is a schematic view illustrating a general simulation procedure using VCs in the specification, behavior, and function layers in the embodiment of the present invention.

[0042] FIG. 20 is a view illustrating a model generation method employed by a synchronization model generation section in the function verification assist section in the embodiment of the present invention.

[0043] FIG. 21 is a block diagram illustrating descriptions in a simulation model for the shared test cluster, a RT level circuit, and a memory model in the VCDB in the embodiment of the present invention.

[0044] FIGS. 22(a) and 22(b) are timing charts of simulation models (in the function layer) before and after being synchronized by the synchronization model generation section, respectively.

[0045] FIG. 23 is a view illustrating a model generation method employed by a description optimization model generation section in the function verification assist section in the embodiment of the present invention.

[0046] FIG. 24 illustrates an example of processing used when generating a circuit for simulation in the embodiment of the present invention.

[0047] FIG. 25 is a view illustrating a model generation method employed by a description optimization model generation section in the function verification assist section in the embodiment of the present invention.

[0048] FIG. 26 illustrates an example of processing used when generating a circuit for simulation and information on circuit diagram conversion in the embodiment of the present invention.

[0049] FIG. 27 is a view illustrating a model generation method employed by another description optimization model generation section in the function verification assist section in the embodiment of the present invention.

[0050] FIG. 28 illustrates an example of processing used when generating a circuit for simulation including a RT level circuit in the embodiment of the present invention.

[0051] FIG. 29 is a view illustrating a model generation method employed by yet another description optimization model generation section in the function verification assist section in the embodiment of the present invention.

[0052] FIG. 30 illustrates an example of processing used when generating a circuit for simulation including a RT level circuit in the embodiment of the present invention.

[0053] FIG. 31 is a block diagram illustrating a verification check method in the embodiment of the present invention.

[0054] FIG. 32 is a schematic view of the construction of a circuit including I/O pins to be verified in the embodiment of the present invention.

[0055] FIG. 33 is a schematic view of the construction of a circuit including an internal state to be verified in the embodiment of the present invention.

[0056] FIGS. 34(a) and 34(b) are a schematic view of the construction of a circuit to be verified and a signal timing chart, respectively, in the embodiment of the present invention.

[0057] FIG. 35 is a block diagram illustrating a design method using a VC interface synthesis section in the embodiment of the present invention.

[0058] FIG. 36 is a view illustrating a flow of implementation of the interface synthesis method shown in FIG. 35 to a bus I/F as an interface between a bus and a VC.

[0059] FIG. 37 is a block diagram of the structure of a VC (RT layer) including a bus I/F in the VCDB in the embodiment of the present invention.

[0060] FIG. 38 shows the bit width, the read/write cycle, and the maximum bus clock frequency for bus I/Fs (bus I/F-A, B, C, X, Y) in the form of a table.

[0061] FIG. 39 is a flowchart showing an interface synthesis procedure in the embodiment of the present invention.

[0062] FIG. 40 shows the specifications of CPUs for interface synthesis in the form of a table in the embodiment of the present invention.

[0063] FIG. 41 is a block diagram illustrating the connection state among RT-VCs selected during the interface synthesis in the embodiment of the present invention.

[0064] FIG. 42 is a block diagram illustrating the entire structure of test clusters arranged hierarchically in correspondence with the VC cluster in the embodiment of the present invention.

[0065] FIG. 43 is a partial enlarged view illustrating in detail the construction of the specification layer and the behavioral layer in FIG. 42.

[0066] FIG. 44 is a partial enlarged view illustrating in detail the construction of the function layer in FIG. 42.

[0067] FIG. 45 is a partial enlarged view illustrating in detail the construction of the protocol layer in FIG. 42.

[0068] FIG. 46 is a block diagram schematically illustrating a method for generating a test cluster between the specification layer and the behavioral layer in the embodiment of the present invention.

[0069] FIG. 47 is a partial enlarged view illustrating in detail the parts for test cluster generation shown in FIG. 46.

[0070] FIG. 48 is a partial enlarged view illustrating in detail the generated test cluster and test scenario shown in FIG. 46.

[0071] FIG. 49 is a block diagram schematically illustrating a method for generating a test cluster between the behavioral layer and the function layer in the embodiment of the present invention.

[0072] FIG. 50 is a partial enlarged view illustrating in detail the parts for test cluster generation shown in FIG. 49.

[0073] FIG. 51 is a partial enlarged view illustrating in detail the generated test cluster and test scenario shown in FIG. 49.

[0074] FIG. 52 is a block diagram schematically illustrating a method for generating a test cluster between the function layer and the protocol layer in the embodiment of the present invention.

[0075] FIG. 53 is a block diagram of the construction of a VC interface model in the embodiment of the present invention.

[0076] FIG. 54 is a block diagram illustrating an example of a system simulation model generated using the VCDB with the VC interface model stored therein in the embodiment of the present invention.

[0077] FIG. 55 is a block diagram illustrating the role of a second VC interface model in the system simulation model.

[0078] Hereinbelow, an embodiment of the present invention will be described with reference to the accompanying drawings. First, the definition of concepts such as VC, VCDS, and VCDB as used herein will be described, followed by the outline of the construction of the VCDS and detailed description of respective components.

[0079] [Concept of VC, VCDS, and VCDB]

[0080] The term “virtual core (VC)” as used herein, which is a concept different from the “VC” as “virtual component” often used synonymously with “IP” (function block), is meant to be used for design of a system LSI constructed of one collective block and, in particular, refers to reusable data including hardware and software. The term “virtual core design system (VCDS)” as used herein is meant to refer to the entire system for optimizing hardware and software of a system LSI using the VC. The term “virtual core database (VCDB)” as used herein is meant to refer to a database used for the VC-using design.

[0081] [Outline of construction of VCDS]

[0082] FIG. 1 is a conceptual view of a virtual core design system (VCDM) for design of a system LSI in an embodiment according to the present invention.

[0083] Referring to FIG. 1, the VCDS in this embodiment includes a virtual core database (VCDB) 100 for storing data for system design and a VCDB management system (VCDBMS) 200 that is a control system for performing optimization of the VCDB 100 and the like.

[0084] The VCDB 100 includes a VC cluster 300 as a collective of VCs, architecture information 401 for determining the structure of the VCs in the VC cluster 300, and a system verification database 402.

[0085] The VC cluster 300 includes a body section generally composed of a specification layer for VCs storing data described in the specification form (specification VCs 301), an behavioral layer for VCs storing data described in the behavior form (behavioral VCs 302), and a function layer for VCs storing data described in a register transfer (RT) level in (RT-VCs 303). The VC cluster 300 also includes: a test cluster 304 that has parameterized test patterns and performs circuit simulation; and performance information 350 for evaluating the performance of the VCs by simulation and the like.

[0086] The performance information 350 includes performance indicators that are parameters such as the area and the speed, for example. With these performance indicators, considerably accurate calculation of a value is possible in the RT level, for example. In addition, if hardware implementation has been actually done in the RT level, the results can also be incorporated as an information indicator.

[0087] The VC cluster 300 further includes the following components linked to one or more VCs in the body section: a toggle analysis model 310 linked to the specification VCs 301 (specification layer), the behavioral VCs 302 (behavioral layer), and the RT-VCs 303 (function layer); a purpose-specific function verification models 320 linked to the RTVCs 303 (function layer); and fault inspection technique information 330 linked to the RT-VCs 303 (function layer) including information on the type of test such as scanning and BIST available for the VCs, and the like.

[0088] The architecture information 401 includes information on how the respective VCs should actually be used. For example, if a certain task is to be implemented by software, the architecture information 401 includes various items of information required for the system LSI, such as “what processor should be used to execute the task”, “What bus (interface) should be used”, “how the power and clock supply scheme should be”, “what test scheme should be used for logical synthesis”, and “how about restrictions in the naming rules (restrictions on tools and rules for preventing overlap naming)”.

[0089] The system verification database 402 serves as a database base for verifying the function of an LSI obtained by combining VCs, and includes a shared test cluster 410, a periphyral model cluster 420, and a VC interface model.

[0090] The shared test cluster 410 and the test cluster 304 in the VC cluster 300 respectively include a test bench, a test scenario, and a function model. The test bench includes a system structure for test and a function model. The test scenario refers to a flow of verification in the system level, i.e., a system behavioral sequence. The task refers to a task for initializing a VC or executing a specific function. The model refers to a link to a simulation model, a VC model, or a periphyral simulation model to be used in the construction of the test bench. Concrete examples of the constructions of the test clusters will be described hereinafter.

[0091] The periphyral model cluster 420 includes models for periphyral of VCs used during system verification, such as models describing an external medium, an external memory, a transmission route in the case of a communication LCI, and a sensor. By combining the VCs with these periphyral models, the entire system can be verified smoothly. The VC interface model serves as a model for coupling respective VCs during system simulation.

[0092] The VCDBMS 200 performs registration with the VCDB 100, external retrieval from the VCDB 100, generation of instances, and other various types of processing described below. The registration includes, not only registering a new core, but also generating a new VC based on an existing VC, modifying the function of the VC, adding data to the VC, storing associated difference management information, and the like. The retrieval is done based on what type of information in which level of VC is desired.

[0093] The VCDBMS 200 includes: a function verification assist section 500 for generating test scenarios, purpose-specific function verification models (simulation models), system verification models (system simulation models), and the like; a toggle analysis and circuit optimization section 600; a VC interface synthesis section 700; and a fault inspection strategy optimization section 800 for selecting/optimizing a VC fault inspection scheme and planning a fault inspection schedule.

[0094] FIG. 2 shows a basic design flow in the VCDS in this embodiment. As shown in FIG. 2, in all of the specification level, the behavioral level, and the RT level, VCs are generated, modified, or otherwise processed in the sequence of “description”, “verification”, “evaluation”, and “synthesis”. For example, in the specification level, existing specification VCs S1 and S2 are retrieved, or a new VC S3 is generated. In this occasion, data flows in the direction indicated by the arrows in the figure for description, verification, and evaluation of the data. The evaluation results are fed back. In the behavioral level, behavioral VCs D1, D2, and D3 respectively corresponding to the specification VCs S1, S2, and S3 are generated, each of which is functionally divided into hardware and software. In the RT level, RT-VCs R1, R2, and R3 respectively corresponding to the behavioral VCs D1, D2, and D3 are generated, together with a CPU, a memory, buses for connecting these VCs, and the like. Thus, in this level, the system becomes more concrete.

[0095] Each task is described by means of external input/output, a specification VC, state transfer, and the like. Each specification VC is described with a language or graphics capable of representing state transfer, logic, a truth table, and the like.

[0096] Thus, by arranging VCs in the respective hierarchical layers and managing these VCs collectively, a flexibly usable database can be provided, unlike the conventional function blocks.

[0097] FIG. 3 is a block circuit diagram of functional part of the system shown in FIG. 1, showing an input section for supplying information to a database storage section where VC clusters are stored, an output section for receiving output information from the database storage section, and a control section for controlling the database storage section, the input section, and the output section. Each VC cluster includes a specification/behavior layer composed of a specification layer for generating specification VCs and an behavioral layer for generating behavioral VCs, and a RT layer for generating RT-VCs. The specification layer and the behavioral layer are put together in this case as the specification/behavior layer since they are not clearly distinguished from each other in some cases. The “behavior” as used herein refers to allocating one specification to software and hardware. In general, a plurality of behaviors exists for one specification. The “register transfer (RT)” as used herein refers to hardware implementation of the behavior. In general, a plurality of different methods exist for implementing one behavior depending on the parameter on which importance is placed, and the like. In other words, in general, a plurality of behavioral VCs exists for one specification VC, and a plurality of RT-VCs exists for one behavioral VC in a hierarchical manner. It should however be noted that the specification and the behavior as used herein both represent functional concepts and thus it may be difficult to distinguish one from the other. In such a case, it is possible to prepare a database for specification/behavior VCs.

[0098] Hereinbelow, the components of the VCDS shown in FIG. 1 will be described individually in detail in structure, function, and the like.

[0099] [Construction of VC cluster]

[0100] (Construction of body section of VC cluster)

[0101] FIG. 4 is a view illustrating the function of the body section of the VC cluster. Referring to FIG. 4, when a specification VC S-VC representing a certain function exists in the specification layer, a plurality of behavioral VCs D-VC1, D-VC2 for implementing the specification VC generally exist in the behavioral layer downstream of the specification layer. In the RT layer downstream of the behavioral layer, a plurality of RT-VCs RT-VC1a, RT-VC1band RT-VC2a, RT-VC2bfor implementing the behavioral VCs O-VC1 and O-VC2 generally exist. For example, for one specification of “multiplication”, a plurality of behaviors generally exist because the behavior for implementing the multiplication is a combination of a plurality of unit behaviors such as additions and shifts. There is of course a case where only one behavioral VC exists for one specification VC. In the example shown in FIG. 4, for one specification VC of “multiplication”, the behavioral VC O-VC1 represents a method that places importance on the delay and the behavioral VC O-VC2 represents a method that places importance on the occupation area, for example. Each layer is provided with the function of generating an instance VC and adding it thereto. In the example shown in FIG. 4, one or more instance VCs are generated in the RT-VCs RT-VC1a, RT-VC1b, RT-VC2a, and RT-VC2b.

[0102] FIG. 5 shows the structure of a VC in the specification, behavior, and RT layers in this embodiment. The VC includes: design data (graphics) to be described hereinafter; verification data such as a test vector; performance information such as the area and delay (and power consumption, as required); hierarchical information to be used as link information regarding a higher-level layer VC having a superordinate concept and a lower-level layer VC having a subordinate concept, with respect to the object VC; derived information regarding a VC in the same layer to which reference was made during generation of the object VC and a VC that made reference to the object VC; shared information, if any, shared by VCs in the same layer (e.g., in the behavioral layer); details of modification if addition or correction was made; and interface information for generating buses such as parallel, serial, or PCI paths.

[0103] FIG. 6 shows the relationship between data and performance information of a VC in each layer. On the right side of the figure there are shown examples of VC performance information in the respective layers obtained by using the occupation area and the delay as parameters for performance evaluation. On the left side there should exist design data and verification data for the respective layers as described hereinafter, which are however omitted in FIG. 6 for simplification of the description. The respective layers are now described in detail.

[0104] Specification Layer

[0105] The specification layer is the portion where the basic input/output (I/O) relationship, that is, the “function” of the system is defined. Therefore, design data in the specification layer includes the type of an I/O signal, text-base data, a standard such as a protocol, performance such as target performance for conforming to a given standard, and a function specification in the form of a document. A specification verification model includes a specification description (language or graphics) represented by finite state machine (FSM), a control flow graph (CFG), a data flow graph (DFG), or the like. Concrete examples of the format include VHDL, SDL, LOTOS, and C/C++. FIG. 7 shows an example of design data described in the format of SDL.

[0106] Behavioral Layer

[0107] The behavioral layer includes architecture information, a hardware section, and a software section. The architecture information includes the names of the object processor and OS, a hardware and software communication method, and the like. For example, in the case of combining a processor, an OS, and a simulation, the processor to be used may be Sparc, Pentium, or the like, the OS to be used may be UNIX, Windows, or the like, and the hardware and software communication method to be used may be IPC, PLI, or the like. An appropriate combination of these components, as well as required preconditions, are described as the architecture information. Note that CPU may not be required. The hardware section describes the function in the form of document in a more concrete manner than that in the specification layer. More specifically, the behavioral layer includes details of an behavioral mode that are not described in the specification layer. FIG. 8 shows an example of data stored in the hardware section, which is described with a hardware descriptive language such as VerilogHDL and VHDL. FIG. 9 shows an example of data stored in the software section, which is described with a source code (e.g., C/C++).

[0108] FIG. 10 is a view illustrating an environment used during verification of the behavioral layer, including the hardware section (HW), the software section (SW), a CPU if any, and a communication section. Optionally, an OS may exist between the communication section and the software section. In this state of the behavioral layer, therefore, bus connection is undetermined.

[0109] RT Layer

[0110] The RT layer basically includes architecture information, a hardware section, and a software section, as in the behavioral layer. In this layer, however, as shown in FIG. 11, buses are formed connecting among the hardware section (HW), the CPU, a memory (MEM), and the software section (SW) including the OS. In this layer, therefore, the communication method is made concrete to such a degree that how to connect these components is known. The design data can now be embodied as hardware, that is, can be logically synthesized. Both the hardware section and the software section include meta data and instance data. The instance data as used herein refers to data obtained by replacing a variable in the meta data described as a parameter with a constant. FIG. 12 shows examples of meta data and instance data in the RT layer.

[0111] The architecture information of the RT layer includes the following.

[0112] Processor (CPU) information: a coordinating verification model used in the behavioral layer and the RT layer, which exists for each processor.

[0113] Bus (I/F) information: information on the type and width of a signal on a bus, and a protocol of a bus (timing), which includes data for connecting the processor to respective hardware components.

[0114] Test scheme information: information on the test scheme together with the function/specification required (e.g., dedicated terminals and additional circuits). In a full scan method, for example, information on Sin (scan in), Sout (scan out), Sclk (scan clock), TE signals, and the like is required. If JTAG, one of boundary scan test schemes, is employed, information on the control terminal, the TAP controller circuit, and the like is required. If respective cores are directly tested from outside separately, information on the test mode terminal, the selector circuit, and the like is required.

[0115] As the naming rules, included are: a restriction for each EDA tool that processes generated instance VCs, for instance, “the module name should include not more than 16 alphanumeric small characters”; and a restriction for preventing generation of different instance VCs having the same name, for instance, “code, “A981005 N, should be prefixed to the module name.”

[0116] Performance Information In Respective Layers

[0117] Assume that the specification VC S-VC exists in the specification layer as shown in FIG. 4. If the performance of this specification VC is represented by the area and the delay, the range of the performance corresponds to the hatched portion shown in the upper right graph of FIG. 6. For this specification VC, the behavioral layer provides the delay-stressing behavioral VC O-VC1 and the area-stressing behavioral VC O-VC2 as shown in FIG. 4. The ranges of the performances of the behavioral VCs O-VC1 and O-VC2 correspond to the hatched smaller-delay and smaller-area portions shown in the middle right graph of FIG. 6, respectively. For these behavioral VCs O-VC1 and O-VC2, the RT layer provides RT-VCs RT-VC1aand RT-VC1b, and RT-VC2aand RT-VC2b, respectively, as shown in FIG. 4. The area and delay of each of the RT-VCs are now determined as a point on the concrete curve as shown in the lower right graph of FIG. 6.

[0118] In reality, since the performance information includes a number of parameters, the performance information in each layer is represented by a multidimensional coordinate system, not the planar coordinate system as shown in FIG. 6. Thus, the performance information is actually represented as a range or a point in the RT layer or as a range in the specification or behavioral layer, in a multidimensional coordinate system.

[0119] (Construction Of VC Cluster Other Than Body Section)

[0120] Toggle Analysis Model

[0121] FIG. 13 is a conceptual block diagram of the processing done by the toggle analysis and circuit optimization section shown in FIG. 1. The length of an inter-block net tends to be larger than that of an inner-block net. Accordingly, if an interconnect having a high toggle exists between blocks, such an interconnect may be incorporated inside a block. This reduces the capacitance of the interconnect and thus reduces power consumption. In addition, the toggle in a module may be reduced by dividing a circuit into parallel-arranged circuits to disperse the circuit behavior. When there exist a plurality of pins that can output the same results even if input information is exchanged therebetween, nets connected to the pins may be exchanged. This reduces the internal toggle. Moreover, by equalizing the transition of signals on the nets connected to such pins, degradation of the circuit can be minimized. In addition, net wiring may be designed in consideration of the toggle, which had been designed only in consideration of the total length thereof in the floor planning. This allows for reduction in toggle as long as the delay restriction is not violated. By incorporating a model for executing the above processing in the VCDB 100, design of an LSI with reduced power consumption and high reliability is possible.

[0122] Purpose-Specific Function Verification Model

[0123] FIG. 14 shows an example of details of the purpose-specific function verification models 320. As shown in FIG. 14, the RT-VCs 303 in the VC cluster body section include RT-VC1, RT-VC2, . . . that are RT-level design descriptions representative of actual circuits. The purpose-specific function verification models 320 are prepared for each of RT-VC1, RT-VC2, . . . as verification models (simulation models) allowing for verification for specific purposes. A set of the purpose-specific function verification models 320 include, for example, a synchronization model 321, a description optimization model 322, the behavior checker incorporation model 324, and the like arranged in parallel.

[0124] The synchronization model 322 performs verification only every cycle of a synchronous clock signal for a model that operates at a normal unit time cycle. This is applied to such a type of verification that does not require so high accuracy as that required for actual behavior. Instead, this model intends to perform high-speed simulation while omitting minor delicate behavior, delay, and the like.

[0125] The description optimization model 322 is provided for the following purpose. While a description allowing for logical synthesis is required for implementation of a circuit, if such a description is used for verification simulation, the simulation may become too slow. In such a case, the description is changed for use in simulation, to obtain a highspeed model that is optimized for simulation although being inferior in the circuit synthesis. The description optimization model 322 is provided with a reference 323 for associating the description optimization model 322 with the original circuit description in the corresponding RT-VC in the VC cluster body section.

[0126] The behavior checker incorporation model 324 is a model indicating how to detect a VC when the VC is used, as described hereinafter. For example, the simulation model incorporates therein a prohibition such as that a certain signal pattern must not be included in an input signal and that transition of the inner state in a certain sequence is prohibited. The behavior checker incorporation model incorporates therein a mechanism that returns error information if any of such prohibitions occurs during the simulation. The behavior checker incorporation model 324 is provided with check result analysis information 325 for analyzing the meaning of an error when the error occurs. In other words, verification is performed, not using the design data of each VC in the VC cluster body section relating to an actual circuit directly, but using a model provided for performing optimum verification specific to a purpose.

[0127] FIG. 15 is a view focusing on the use of the synchronization model 321 among the purpose-specific function verification models 320. The synchronization model 321 in this embodiment is a model for allowing verification in synchronization with only the clock cycle as described above. Actually, however, the synchronization for high-speed verification is often difficult only with the existence of the synchronization model 321 in the VC cluster body section. Therefore, a synchronization test cluster 411 and a synchronization model 421 which have the same degree of precision as the synchronization model 321 in the VC cluster body section are provided for RT-VCs in the shared test cluster 410 and for the periphyral model cluster 420, respectively. How to generate these synchronization models will be described hereinafter.

[0128] System Verification Database

[0129] FIG. 16 is a view illustrating the flow (scenario) of tests performed using the shared test cluster 410 and the periphyral model cluster 420 in the system verification database. Referring to FIG. 16, the shared test cluster 410 includes an application layer 411. (specification level), an architecture layer 412 (behavioral level), and a function layer 413 (RT level) in a hierarchical arrangement. The periphyral model cluster 420 includes an application layer 421 (specification level), an architecture layer 422 (behavioral level), and a function layer 423 (RT level) in a hierarchical arrangement. The system verification database 402 also includes specification-level system verification models, behavioral-level system verification models, and RT-level system verification models for effecting simulations between the shared test cluster 410 and the periphyral model cluster 420 in the respective levels corresponding to the VCs 301, 302, and 303 in the VC cluster body section.

[0130] Fault Inspection Strategy Optimization Section

[0131] FIG. 17 is a block diagram illustrating a method for optimizing the fault inspection strategy by the fault inspection strategy optimization section 800. As shown in FIG. 17, upon receipt of a design request, the fault inspection strategy optimization section 800 selects a VC in the RT layer (RT-VC) and a fault inspection method from the VCDB 100. The design request includes specifications required for the system LSI (area, number of pins, test time, information on priority, restriction, and weighting, etc.) and VC information among others. The fault inspection strategy optimization section 800 executes optimization behavior in consideration of various parameters with reference to fault inspection strategy knowledge, to generate an optimum fault inspection strategy and a one-chip fault inspection control circuit.

[0132] The VCDB 100 includes a plurality of VC clusters that have the same function but require different test schemes. Also, the VCDB 100 includes in one VC cluster a plurality of test schemes that have the same function but are different in test pattern. Information relating to the test cost of the plurality of test schemes is also stored in the VCDB 100. This information includes, for example, the number of pins used by the IC device, the test pattern length, the area of the IC device, the fault detection rate, the test time, the man-hour for design, and the yield of the IC device. Information relating to the test restriction is also stored in the VCDB 100. This information includes, for example, the state of pins, restriction on being dynamic or static, and division of the test pattern.

[0133] Measures for minimizing the test cost will be described. Assume that the test cost is evaluated by three parameters, i.e., the area, the test time, and the design man-hour. Then, the total test cost ctotl is expressed as the sum of the area cost Csize, the test time cost Ctime, and the man-hour cost Cproc, that is,

[0134] Ctotl=Csize+Ctime+Cproc.

[0135] In consideration of the prohibitions and the trade-off relationship as described above, weights may be added to the area cost, the test time cost, and the man-hour cost, respectively, depending on the degree of importance placed by the user, so that restriction-considering cost evaluation is realized. As a result, the evaluation function for minimizing the test cost is represented by the following equation.

[0136] Ctotl=Csize+Ctime+Cproc

[0137] Thus, a test scheme for minimizing the test cost can be selected based on the above equation. It would be understood that parameters other than the above three may also be used for the construction of the evaluation function.

[0138] By providing the fault inspection optimization section 800, it becomes possible to minimize the test cost under restricted conditions such as that a prohibited combination of test types are selected and that test types in the trade-off relationship are selected.

[0139] VC Synthesis Interface Model

[0140] The VC interface models are simulation models for effecting VC-base system LSI simulation in a combination of VC models in different layers (for example, the specification layer and the RT layer) in the VC cluster.

[0141] In general, simulation is performed in a top-down manner starting from a higher level of abstraction, i.e., in the order of the specification layer, the behavioral layer, and the RT layer. However, depending on how to proceed on the design, simulation of the entire circuit may be desired under the condition where, while RT-VCs to be used have already been determined for some VCs, only specification VCs have been determined for other VCs. If only simulation for VCs in the same layer is permitted, simulation cannot be easily performed for the system LSI in the case where VCs in the RT layer is partly incorporated at the stage of designing VCs in the specification and behavioral layers, and in the case where VCs in the specification layer is partially incorporated at the stage of designing VCs in the RT layer. This prevents improvement in design efficiency.

[0142] In addition, in the case where the requested degree of precision in simulation varies with the VCs, the simulation had better be performed at a level with a higher level of abstraction, to realize higher speed simulation.

[0143] According to the present invention, by using an architecture-layer VC interface, for example, it is possible to combine models in different levels, such that the RT level is used for VC-A, B, C, the behavioral level is used for VC-X, and the specification level is used for VC-Y, for executing simulation. The VC interface model is a coupling model used to combine models in different levels for simulation. That is, the VC interface model is a model serving like a state transition diagram in the context of microcomputer control, when viewed from the application layer and the architecture layer.

[0144] FIG. 53 is a block diagram illustrating a construction of the VC interface model. As shown in FIG. 53, the VC interface model includes: a specification layer input section, an behavioral layer input section, and a RT layer input section for receiving data in the specification layer, the behavioral layer, and the RT layer, respectively, in the VC cluster; a transfer rate conversion section for converting the transfer rate of the input data in correspondence with the data transfer rate at the destination; a data precision conversion section for converting the precision of the data in correspondence with the data precision at the destination; a protocol conversion section for converting the protocol of the data in correspondence with the data protocol at the destination; and a specification layer output section, an behavioral layer output section, and a RT layer output section for outputting the data converted by the respective conversion sections to the specification layer, the behavioral layer, and the RT layer, respectively, in the VC cluster. For example, the I/O for the specification layer is handled in the form of a data file using real numbers, the I/O for the behavioral layer is handled in the form of synchronous transfer using integers, and the I/O for the RT layer is handled in the form of synchronous transfer using a finite bit allay, synchronous signal, and enable signal control.

[0145] FIG. 54 is a block diagram illustrating an example of the system simulation model generated (by the function verification assist section 500, for example) when the system is simulated using the VCDB 100 including VC interface models. Referring to FIG. 54, the VCDB 100 includes VC interface models and the VC clusters such as a controller VC cluster, a signal compression VC cluster, and a memory VC cluster. The function verification assist section 500 generates as a system simulation model the following components, for example: a controller behavioral VC using an behavioral VC in the controller VC cluster in the VCDB 100; a signal compression specification VC using a specification VC in the signal compression VC cluster in the VCDB 100; and a memory RT-VC using a RT-VC in the memory VC cluster in the VCDB 100. The function verification assist section 500 also generates: a first VC interface model using an interface VC model in the VCDB 100 for coupling the two VCs in different layers generated in the system simulation model, i.e., the controller behavioral VC and the signal compression specification VC; and a second VC interface model for coupling the three VCs in different layers generated in the system simulation model, i.e., the controller behavioral VC, the signal compression specification VC, and the memory RT-VC.

[0146] FIG. 55 is a block diagram illustrating the role of the second VC interface model in the system simulation model. As described above, the I/O for the specification layer is handled in the form of a data file using real numbers, the I/O for the behavioral layer is. handled in the form of synchronous transfer using integers, and the I/O for the RT layer is handled in the form of synchronous transfer using a finite bit allay, synchronous signal, and enable signal control. In order to couple the signal compression specification VC and the memory RT-VC, for example, the second VC interface model is provided with functions such as parallel/serial transfer conversion, synchronous reading, and rounding up to a finite bit width. The second VC interface model provided with these functions actually performs data transmit/receive behavior with the signal compression specification VC in the form of a data file with a delay time of 0 using real numbers, while performing data transmit/receive behavior with the memory RT-CT in the form of synchronous transfer with a finite bit width (e.g., 16 bit width) with a bus protocol.

[0147] With the above VC interface models, it becomes possible to construct a simulation model with VC models in different layers easily and flexibly in the top-down design of a system LSI.

[0148] [Means for function verification and generated models]

[0149] Hereinbelow, the management schemes carried out by the respective sections included in the VCDBMS 200 shown in FIG. 1, as well as the resultantly generated verification models, will be described. The generated models are in principle included anywhere in the VCDB 100 shown in FIG. 1 although they are not necessarily included therein.

[0150] (Function Verification Assist Section)

[0151] Outline Of Construction

[0152] FIG. 18 is a block diagram illustrating the behavior of the function verification assist section 500. First, a verification request (parameters) for desired verification (simulation) is input into the function verification assist section 500. That is, as the verification request, parameters are input, including VCs to be verified, the level of the VCs, the model to be used among the synchronization model, the description optimization model, the behavior checker incorporation model, and the like (model designation), the test scenario to be used, and the test bench to be prepared. On receipt of the request, the function verification assist section 500 retrieves information on the VC cluster corresponding to the verification request, information on the shared test cluster and the periphyral model cluster, and the like from the VCDB 100, to generate a test bench, a test scenario, and a task for simulation and a simulation model (e.g., a purpose-specific function verification model and a system purpose-specific function verification model and a system verification model). The generated model can be stored in the VCDB 100.

[0153] FIG. 19 schematically illustrates a general simulation procedure using VCs in the specification, behavior, and RT levels. When simulation circuit conditions are input into the VCDB 100, a logic simulator executes simulation using pre-designed circuits for simulation and a newly-designed circuit if required, and outputs simulation results.

[0154] Example Of Generation Of Synchronization Model

[0155] FIG. 20 is a view illustrating a model generation method employed by a synchronization model generation section 510 as part of the function verification assist section 500. The synchronization model generation section 510 generates a synchronization model in response to the input of simulation circuit conditions relating to designation of the circuit, memory, and test cluster to be used, designation of parameters defined therein, and the like, with reference to descriptions in simulation models for the RT-VC, the memory model, the test cluster (function layer), and the like. The synchronization model generation section 510 includes a timing analysis part 511 and a circuit change part 512, which generate a synchronization model in the procedure described below to generate a circuit for simulation including a RT level circuit, a memory model, and a test cluster (function layer)

[0156] FIG. 21 is a block diagram illustrating descriptions in simulation models for a test cluster, a RT level circuit, and a memory model in the VCDB 100. Assume that a signal tb-out output from the test cluster to the RT level circuit is turned to “1” in the lapse of 220 ns and to “0” in the lapse of 420 ns. Also assume that a clock clk that is inverted every 50 ns is output from the test cluster to the RT level circuit. The RT level circuit receives the signal tb-out as an input signal cir-inl and outputs a memory request signal cir-outl to the memory model via a synchronous circuit basically composed of a flipflop. Assume that the memory model has a delay time of 120 ns from receipt of the memory request signal as an input signal mem-in until output of a memory output signal mem-out. The RT level circuit receives the signal mem-out as an input signal cir-in2 and outputs a signal cir-out2 via an asynchronous circuit basically composed of a latch. The test cluster receives the signal cir-out2 as an input signal tb-in.

[0157] FIGS. 22(a) and 22(b) are timing charts of the simulation models (function level) before and after being synchronized by the synchronization model generation section 510, respectively. For example, the rise and fall timings, 220 ns and 420 ns, of the signal tb-out in the original simulation model are changed to 200 ns and 400 ns, respectively, that are multiples of the half cycle of the clock, 50 ns. Also, the delay time, 120 ns, of the memory model in the original simulation model is changed to 100 ns that is a multiple of 50 ns. It would be appreciated that a minute displacement of edges of the clock is allowed.

[0158] In general, a circuit to be designed operates under complicate timing control. In the conventional simulation method, a simulation model is prepared according to the timing in the real behavior. In the case of simulation for function verification, however, no inconvenience is likely to arise actually when the timing of the half cycle of the clock is used for processing ignoring a minute delay time and the like, unlike the actual behavior. This serves to enhance the speed of the simulation.

[0159] In the above example, the timing of the simulation was synchronized with the multiple of the half cycle of the clock. It may also be synchronized with a multiple of another cycle synchronizing with the clock, such as the quarter cycle of the clock.

[0160] Example 1 of Generation of Description Optimization Model

[0161] FIG. 23 is a view illustrating a model generation method employed by a description optimization model generation section 520A as part of the function verification assist section 500. The description optimization model generation section 520A generates a description optimization model in response to the input of simulation circuit conditions relating to designation of the circuit and test cluster to be used, and the like, with reference to descriptions in simulation models on the RT-VC, the shared test cluster, and the like. The description optimization model generation section 520A includes a circuit retrieval part 521 and a circuit change part 522, which generate a description optimization model in the procedure described below to generate a circuit for simulation including a RT level circuit and a test cluster.

[0162] FIG. 24 illustrates an example of the processing by the description optimization model generation section 520A. First, the circuit retrieval part 521 retrieves from the VCDB 100 a description of a circuit VC and a description of a test cluster VC on the setting of the value of a conditional signal line. Assume that the description of the circuit VC includes the condition that if flgl is “1” execute processing 1aotherwise execute processing 1b, and that it is found from the description of the test cluster VC that flg1 varies but flg2 does not vary (#0, #100 in the test cluster VC description represent time). It is found from these descriptions that since flg2 is kept “0”, processing 2ais never executed in this simulation but processing 2bis invariably executed. Finding this fact, the circuit change part 522 deletes the processing 2aand the conditional sentence in the control description 2, to generate a modified simulation model. As a result, in the control description 2 in the circuit VC description for simulation, it is read that processing 2bbe executed irrespective of whether or not flg2 is “0”. By this change in description, however, the correspondence with the original circuit description may be lost. A reference is therefore additionally prepared as information for retrieving the correspondence with the original description. That is, for example, although the value of flg2 is not mentioned in the modified circuit description, it can be recognized to be invariably “0” by referring to this reference.

[0163] By modifying the circuit description as described above, the time that may otherwise be wasted by the processing unnecessary for simulation can be saved, whereby the circuit description for simulation is optimized.

[0164] Example 2 of Generation of Description Optimization Model

[0165] FIG. 25 is a view illustrating a model generation method employed by a description optimization model generation section 520B as part of the function verification assist section 500. The description optimization model generation section 520B generates a description optimization model in response to the input of the simulation circuit conditions relating to designation of the circuit and test cluster to be used, with reference to descriptions in simulation models on the RT-VC, the test cluster, and the like. The description optimization model generation section 520B includes a hierarchy information retrieval part 523 and a hierarchy expansion part 524, which generate a description optimization model in the procedure described below to generate a circuit for simulation including a RT level circuit and a test cluster as well as circuit diagram conversion information.

[0166] FIG. 26, illustrates an example of the processing by the description optimization model generation section 520B. Assume that a module MA exists in the highest level, modules MB and MC in the lower level, and a module MD in the lowest level in the hierarchical order. The hierarchy information retrieval part 523 retrieves the hierarchy of circuit data and signal line connection information before hierarchy expansion. As a result, the following are recognized. A signal supplied from an element in the module MB to an element in the module MC includes signal processing B1 in the module MB, signal processing A1 in the module MA, and signal processing C1 in the module MC. A signal supplied from an element in the module MC to an element in the module MB includes signal processing C2 in the module MC, signal processing A2 in the module MA, and signal processing B2 in the module MB. A signal supplied from an element in the module MC to an element in the module MD includes signal processing C3 in the module MC and signal processing D1 in the module MD. A signal supplied from an element in the module MD to an element in the module MC includes signal processing D2 in the module MD and signal processing C4 in the module MC. The signal line connection information includes descriptions corresponding to the above data.

[0167] The signals B1, A1, and C1 actually refer to one signal flowing on one signal line. These different names for the respective modules are used to facilitate the design. During simulation, this distinction of names is unnecessary. The hierarchy expansion part 524 therefore generates a circuit where overlap signal lines are united into a common signal line by expanding the hierarchy. The signal line carrying the same signal over different levels is named after the signal name used in the highest level. As a result, the original ten names of signals can be reduced to four in the simulation model after the hierarchy expansion. This increases the simulation speed.

[0168] The module name may be prefixed to the signal line name for a lower-level signal line. A reference list indicating the correspondence between the signal lines before and after the hierarchy expansion may be prepared, so that the original signal names before the hierarchy expansion can be used after debugging.

[0169] Example 3 of Generation of Description Optimization Model

[0170] FIG. 27 is a view illustrating a model generation method employed by a description optimization model generation section 520C as part of the function verification assist section 500. The description optimization model generation section 520C generates a description optimization model in response to the input of simulation circuit conditions relating to designation of the circuit and simulator to be used, with reference to a description in a simulation model on the RT-VC in the VCDB 100. The description optimization model generation section 520C includes a circuit description analysis part 525, a circuit conversion part 526, simulator specific information, and circuit conversion rules. The circuit description analysis part 525 and the circuit conversion part 526 generate a description optimization model in the procedure described below to generate a circuit for simulation including a RT level circuit.

[0171] FIG. 28 illustrates an example of the processing by the description optimization model generation section 520C. RT-VCs in the VCDB 100 have been formed to have descriptions convertible according to the circuit conversion rules. In general, unmodified RT-VC simulation models include “case” sentences and “if” sentences in a mixed manner depending on the type of processing. In some cases, simulation is faster by processing according to an “if” sentence for a certain simulator, while it is faster by processing according to a “case” sentence for another simulator.

[0172] Assume in this example that a simulator A provides faster simulation by processing according to a “case” sentence and a simulator B provides faster simulation by processing according to an “if” sentence. When the simulator B is used, therefore, the circuit description analysis part 525 analyzes and searches whether or not a “case” sentence exists in the simulation model. The circuit conversion part 526 converts the “case” sentence existing in the simulation model to an “if” sentence with reference to the simulator specific information and the circuit conversion rules to be observed at case-if conversion.

[0173] As a result, there is generated a circuit for simulation allowing for higher-speed processing when the simulator B is used.

[0174] Example 4 of Generation of Description Optimization Model

[0175] FIG. 29 is a view illustrating a model generation method employed by a description optimization model generation section 520D as part of the function verification assist section 500. The description optimization model generation section 520D generates a description optimization model in response to the input of simulation circuit conditions relating to designation of the circuit to be used and the input on the function unused for simulation, with reference to a description in a simulation model on the RT-VC in the VCDB 100. The description optimization model generation section 520D includes a function analysis part 527 and a circuit conversion part 528, which generate a description optimization model in the procedure described below to generate a circuit for simulation including a RT level circuit.

[0176] FIG. 30 illustrates an example of the processing by the description optimization model generation section 520D. There is a region in a circuit that does not contribute to the behavior of the circuit during simulation. Assume that the function analysis part 527 has analyzed the function of the RT-VC shown in FIG. 30 and found that in the levels lower than a module MA, modules MB and MC operate influencing the output but a module MD does not operate at all. In other words, although the module MD is included in the data, it does not influence the simulation results at all. Notified of this fact, the circuit conversion part 528 deletes the circuit description on the module MD and instead incorporates a circuit that returns an error when the module MD is accessed. In other words, such a circuit for simulation that can automatically generate a simulation model detaching the module MD is generated.

[0177] As a result, during simulation using a workstation or the like, reduction in simulation speed that may otherwise be caused due to the occupation of the module MD in the memory is avoided. Simulation becomes slow by merely a change in an input signal even if the module MD does not operate. This problem can also be avoided.

[0178] Since there is a possibility that the module MD is accessed, an access check circuit is formed for checking a mistake access to the module MD. Such a circuit has a capacitance too small to affect the simulation speed.

[0179] (Check Model for Verification)

[0180] Hereinbelow, the check function will be described. The check function includes the check on whether or not each VC itself normally operates during verification and the check on whether or not each VC is correctly used in VC-incorporated verification. The behavior checker incorporation model 324 as part of the purpose-specific function verification models 320 executes this function.

[0181] FIG. 31 is a block diagram illustrating the verification check method. A model including a time phase check model 341, an internal state check model 342, and an I/O data check model 343 is included in the VCDB 100. According to a conversion program, a check mechanism is incorporated in an actual simulation model depending on the check type. While simulation is being executed according to the conversion program using a language tool and a function or logic simulator, various checks as described below are also performed.

[0182] The I/O data check model 343 includes a description for effecting a check as follows. Consider a circuit as shown in FIG. 32 where outputs 01, 02 are output in correspondence with inputs A1, A2. The I/O data check model 343 examines whether or not the restriction on the state values of I/O pins for each VC is observed. For example, the I/O data check model 343 includes a description defining to watch during simulation whether or not a combination of inputs prohibited for the VC is received, or in reverse, whether or not an output in the prohibited state is output during the simulation in the VC-utilizing design.

[0183] The internal state check model 342 includes a description for effecting a check as follows. Consider a circuit as shown in FIG. 33 where internal states S1, S2, and S3 exist. The internal state check model 342 includes a description defining to watch during simulation whether or not an internal state prohibited for the VC exists in a signal inside the VC or during the simulation in the design.

[0184] The time phase check model 341 includes a description for effecting the check on the time phase logic of I/O pins and internal pins as follows. Consider a circuit as shown in FIG. 34(a) where input signals A1, A2 have waveforms as shown in FIG. 34(b). If there is a restriction that when the input signal A1 shifts from HIGH to LOW the input signal A2 must be HIGH before the input signal Al becomes HIGH next, the time phase check model 341 includes a description defining to watch whether or not the restriction is observed.

[0185] In simulation using the conventional test pattern, if an abnormal state occurs in an internal deep region, such occurrence may not be reported to external pins during simulation n some cases. With the provision of the check models 341, 342, and 343 shown in FIG. 31, an abnormal phenomenon can be instantly detected at the very place and time of the occurrence of such a phenomenon. In addition, when an error occurs, which rule the error violates can be determined.

[0186] The above three check items may conventionally be described using HDL or the C language. However, describing these check items itself is considerably difficult, and more-over the amount of description becomes great. In contrast, by storing the above check models in the VCDB 100 as in this embodiment, these checks can be done with improved easiness and precision.

[0187] (Synthesis of VC Interface)

[0188] If the conventional technique is applied to the VCDS without any change, the LSI designer will not be able to use VCs in the VCDB as they are. More specifically, in the design of a circuit in combination of VCs, if such VCs have data I/O interfaces different in specification or procedure (protocol), signal transmission between these VCs is not attained by just connecting the VCs via signal lines. For example, a bus interface (I/F) placed between a VC and a bus must be modified to match with a host (e.g., CPU) used in order to use the VC in the design. This means that the number of bus I/Fs equal to the number of VCs used must be modified. This modification work may cause a human error.

[0189] The VC interface synthesis section 700 (see FIG. 1) produces an “interface circuit” that has a function of automatically matching interfaces having different procedures.

[0190] FIG. 35 is a block diagram illustrating a design method using the VC interface synthesis section 700. As a result of simulation of a circuit designed, VCs in the RT layer are selected from the VCDB 100. Also from the simulation, parameters (e.g., the number of access bits and the buffer size) of an interface are known. The VC interface synthesis section 700 selects or synthesizes proper VCs while properly matching the parameters, to determine VCs having an optimum interface.

[0191] For example, if the number of access bits is different between interfaces,.signal transmission is not possible. If the buffer size is different between interfaces, signal transmittance at a constant speed is not possible. The VC interface synthesis section 700 determines proper VCs while attempting to match these parameters with each other. In this way, it becomes possible to design using VCs automatically provided with optimum interfaces.

[0192] Application to Bus I/F

[0193] FIG. 36 illustrates a flow of implementation of the interface synthesis method shown in FIG. 35 to a bus I/F between a bus and a VC.

[0194] First, optimum VCs (RT layer) are selected. Concretely, VCs (VC1, VC2, . . . ) are selected from the VCDB 100 in conformity with the bus protocol of the host (e.g., CPU) used in the simulation. At this time, from the bus protocol of the host, parameters such as the number of access bits and the buffer size are known. On receipt of such information, the VC interface synthesis section 700 automatically determines interfaces conforming to the bus protocol of the host for the respective VC1, VC2, . . . More specifically, the VC interface synthesis section 700 receives conditions such as parameters output exclusively from the simulations in the behavioral level, the specification level, and the like, and automatically defines the parameters so that the specification of the bus protocol requested by the host and the specification of the interfaces possessed by the VCs themselves match with each other, in other words, so that the interfaces are absorbed. If an appropriate VC is found among those retrieved from the VCDB 100, the VC is selected. Otherwise, an appropriate VC is generated. In this way, VCLA, VC2A, . . . having matched interfaces are generated, which are then used for a one-chip implementation.

[0195] Example of Bus I/F

[0196] FIG. 37 is a block diagram illustrating structures of VCs (RT layer) in the VCDB 100 in this example. As shown in FIG. 37, each VC has bus I/Fs separated from a function base, so that the function base is kept irrespective of the timing and the like in the bus I/Fs. Various bus I/Fs conforming to the bus protocol of the host used are generated. In the example shown in FIG. 37, VC1 in the VCDB 100 includes three bus I/Fs (bus I/F-A, B, C) and a function base, and VC2 includes two bus I/Fs (bus I/F-X, Y) and a function base.

[0197] FIG. 38 shows the bit width, the read/write cycle, and the maximum bus clock frequency for the respective bus I/Fs (bus I/F-A, B, C, X, Y) in the form of a table. By preparing a plurality of bus I/Fs for each VC as in this example, the parameter matching during interface synthesis can be done more swiftly.

[0198] FIG. 39 is a flowchart showing an interface synthesis procedure. Referring to FIG. 39, the procedure for automatically generating bus I/Fs will be described.

[0199] First, at step ST701, a target specification (function, operating frequency, etc.) is determined, and VCs* for the CPU and the periphyral are selected.

[0200] At step ST702, simulation in the specification/behavior levels is executed. At step ST703, whether or not a selected VC* satisfies the target specification is determined.

[0201] If the VC* does not satisfy the target specification, the process proceeds to step ST704, where whether or not there remains a VC* that has not been subjected to the simulation at step ST702 is determined. If YES, the process returns to step ST701, and the processing at steps ST701, ST702, and ST703 is repeated until a VC* that satisfies the target specification is found. If there no more remains a VC* that has not been subjected to the simulation at step ST702 although no selected VC* has satisfied the target specification, the target specification is changed at step ST705. The process then returns to step ST701.

[0202] The above processing is repeated until a VC* satisfying the target specification is found. Once such VC* is found, the VC to be used, as well as the bus I/F to be used for the VC, are determined at step ST706.

[0203] Assume that CPU-2 among three CPUs (CPU-1, 2, 3) shown in FIG. 40 has been selected as a result of simulation. The bus protocol of CPU-2 prepared for the VC in the function layer (RT-VC) is as shown in FIG. 40. The bus I/F matching with the bus protocol of CPU-2 is selected from the bus I/Fs in VC1 and VC2 shown in FIG. 38. As a result, bus I/F-B for VC1 and bus I/F-X for VC2 are selected.

[0204] Referring back to FIG. 39, in the RT layer in the VCDB 100, three RT-VCs of CPU-2, VC1′ including bus I/F-B and the function base, and VC2′ including bus I/F-X and the function base are generated.

[0205] FIG. 41 is a block diagram illustrating the connection state between the generated RT-VCS. The two VCs, VC1′ and VC2′, are connected with CPU-2 via a CPU-2 dedicated bus. Since the bus parameters (the number of bits, the operating frequency, etc.) of VC1′, VC2′, and the host (CPU-2) are matched with one another, proper signal transmission is ensured among VC1′, VC2′, and CPU-2. Thus, automatic design is realized.

[0206] (Structure for System Verification)

[0207] Hereinbelow, hierarchical test clusters in the system verification model will be described. As described above, the test cluster includes a test bench, a test scenario, a task, and a model. The test bench includes a system structure and a function model for testing. The test scenario refers to a flow of verification in the system level, i.e., a system behavioral sequence. The task refers to a task for initializing a VC or executing a specific function. The model refers to a link to a simulation model, a VC model, or a periphyral simulation model to be used by the structure of the test bench.

[0208] As shown in FIG. 1, the VC cluster body section in the VCDB 100 has the hierarchical structure composed of the layers of specification VCs 301, the behavioral VCs 302, and the RT-VCs 303. Hereinbelow, hierarchical test clusters generated for system verification will be described.

[0209] Hierarchical Arrangement of Test Cluster

[0210] FIG. 42 is a block diagram illustrating the entire structure of hierarchical test clusters. FIGS. 43, 44, and 45 are detailed block diagrams illustrating the structures of the test clusters in the specification/behavior layers, the function layer, and a protocol layer, respectively. Parameters P-1 to 10, test clusters, sequence models S1 to S4, and components S3-1 to 6 schematically shown by codes in FIG. 42 are specifically illustrated in FIGS. 43 to 45.

[0211] The above test clusters may be obtained from the test cluster 304 belonging to the VC cluster 300 shown in FIG. 1, or may be generated using the shared test cluster 410 including test scenarios and periphyral models already prepared. For example, there are test scenarios and periphyral models common to a plurality of VC clusters and those stored in the system verification database 402 outside the VC cluster 300.

[0212] Apparatuses may be wired-connected or wireless-connected for transferring sound, for example, as data medium. FIGS. 42 to 45 show, in the form of block diagrams, a system for transferring sound data from an apparatus A to an apparatus B in a wired or wireless manner, as an example. In the following description, it is assumed that a circuit for wireless data transfer is to be designed.

[0213] In the specification layer, tasks such as converting wired transferred data to wireless data and then to sound for output, for example, are performed. Once such a task is put into an abstract expression, it can be verified. Verification in the specification layer includes verification of only behavior in such a level that sound data is input and simply transferred transversely, for example.

[0214] In the behavioral layer, the sequence control in the wireless data transfer section is particularized into VC clusters having constructions A, B, C, . For example, the VC cluster of construction A includes, as models operating in the sequence, Timer (S1), CPU (S2), IrDA (S3) (a general interface using infrared standardized by Infrared Data Association, a standardization organization in U.S.), and DMA (S4).

[0215] Further, in the behavioral layer, the wired data transfer section is particularized into a test cluster 1 (TB-1), a test cluster 2 (TB-2), and the like. For example, the test cluster 1 has parameters such that the transfer form is serial, the transfer speed is 1 Mbps, and the transfer type is bulk transfer. The voice conversion section is particularized into a test cluster a (TB-a), a test cluster b (TB-b), and the like. For example, the test cluster TB-a has parameters such that the conversion speed is 100 bps and the compression rate is 90%. The constructions A, B, C, . . . of the VC clusters have respective initialization test clusters (I-TB-A, B, C, . . . ). Thus, by entering the parameters P-1 to 3 in the specification layer, the corresponding VC cluster in the wireless data transfer section and test clusters in the wired data transfer section and the voice conversion section are selected from a table in the behavioral layer.

[0216] In the behavioral layer, the control becomes complicated, having respective sequences. For example, assume that data is input into the VC cluster having the construction A from the test cluster a on the wireless side. The procedure in the VC cluster having the construction A in this instance is expressed in a mere sequence level so that the models S1 to S4 operate in the sequence of “notifying receipt of data—announcement of transfer—transfer in response to transfer permission”. In the actual transfer, the VC cluster having the construction A starts transfer of data to the test cluster 1 in the wired data transfer section. Likewise, when data is input into the VC cluster having the construction B from the test cluster b in the voice conversion section, the models in the VC cluster operate in sequence to output the results to the test cluster 2 in the wired data transfer section.

[0217] Next, the expansion from the behavioral layer to the function layer will be described. For example, when the IrDA, one of the models in the VC cluster having the construction A in the behavioral layer, is expanded, there are obtained components of the IrDA model in the function layer, i.e., controller (S3-1), transmit/receive framer (S3-2), CRC calculation (S3-3), DMA I/F (S3-4), 16-bit host I/F (S3-5), and serial I/F (S3-6). These components represent concretely the functions of the infrared communication IrDA, such as the bit width and the error correction method. In the function layer, also, test clusters T-TB, H-TB, D-TB are provided for Timer (S1), CPU (S2), and DMA (S3), respectively. For example, for the Timer model, an 8-bit Timer test cluster (T-TB1) and a 16-bit Timer test cluster (T-TB2) are provided. For the CPU model, a 16-bit host I/F test cluster (H-TB1) and a 32-bit host I/F test cluster (H-TB2) are provided. For the DMA model, a demand DMA test cluster (D-TB1) and a single DMA test cluster (D-TB2) are provided. These test clusters are selected by table retrieval by entering the parameters P-4 to 9. Specifically, the test clusters are retrieved from the database in which models and tasks of the test clusters are stored. Thus, parts have been prepared for the environment of testing. This stage indicates that components have been prepared as database.

[0218] The voice conversion section and the wired data transfer section in the function layer have test clusters that are further particularized from the behavioral layer. For example, while the test cluster a in the voice conversion section in the behavioral layer only indicates the conversion speed and the compression rate, the test cluster in the function layer includes using ADPCM (Adaptive Differential Pulse Code Modulation) sound CODEC conversion as the conversion method as a parameter. As a result, a database storing models and tasks corresponding to ADPCM is prepared for the ADPCM test cluster in the voice conversion section in the function layer. Likewise, the wired data transfer section in the function layer is provided with a USB test cluster that includes as a parameter using a USB (Universal Serial Bus) general interface as a communication protocol, and a 1394 test cluster that includes as a parameter using an IEEE 1394 general interface. Thus, the environment for testing has been prepared.

[0219] As described above, the system verification database includes hierarchical test clusters, not only for the object circuit to be designed, but also for both the input-side circuit supplying signals to the object circuit and the outputside circuit receiving signals from the object circuit. With this arrangement, actual signal transmit/receive flow through the object circuit to be designed, the input-side circuit, and the output-side circuit in the same hierarchical level, as well as the corresponding behavior such as sequence behavior, can be verified.

[0220] For example, as for the constructions A, B of the VC clusters in the behavioral layer, the mere existence of the models in the constructions A, B allows for verification inside the respective constructions, but does not allow for verification of the entire system. On the contrary, in this example, the constructions A, B of the VC clusters are provided with signal transmit/receive functions of receiving data from the test clusters a, b in the voice conversion section and outputting data to the test clusters 1, 2 in the wired data transfer section. In this way, verification of the entire system becomes possible.

[0221] This is also applicable to one model in the construction A. For example, as for the IrDA model, the fact that the IrDA model receives some data and outputs some data allows for verification of the design of this portion, but does not allow for verification how this IrDA portion operates in the entire system. By using the hierarchical test clusters as in this example, each model can be verified in the state matching with an actual system. This is also applicable to the lower-level layer such as the function layer.

[0222] The protocol layer is provided for verifying the detailed protocol relating to data transmit/receive behavior and the details of timings. For example, as shown in FIGS. 42 and 45, the 16-bit host I/F is particularized in relation to the protocol and the timing, using 16-bit PCI and 32 MHz as parameters, to obtain 16-bit PCI I/F (32 MHz) and a 16-bit PCI I/F test cluster as the test cluster thereof.

[0223] Generation Method Of Test Cluster

[0224] FIG. 46 is a block diagram illustrating a method for generating test clusters between the specification layer and the behavioral layers. FIGS. 47 and 48 are partial enlarged views illustrating the parts for generating test clusters and the generated test clusters shown in FIG. 46, respectively. FIGS. 46 to 48 are based on the system of the hierarchical test clusters shown in FIGS. 42 to 45.

[0225] The test cluster in the wireless data transfer section includes components of a wireless transfer model, initialization, transmit/receive frequency setting, data transmit, and data receive. The test scenario in the wireless data transfer section is divided into the transmit-side and the receive-side each having the steps of initialization, transmit (receive) frequency setting, and data transmit (receive). The test cluster in the wireless data transfer in the behavioral layer is generated by using the test clusters 1, 2 in the wired data transfer section in the behavioral layer, the initialization test cluster for the construction A, and the test clusters a, b in the voice conversion section in the behavioral layer.

[0226] The test cluster in the behavioral layer is generated by combining the test cluster in the wireless data transfer section with the test clusters 1, 2, a, b and the initialization test cluster for the construction A. More specifically, along with the test scenario in the wireless data transfer section, models for tasks of initialization, transmit (receive) frequency setting, and data transmit (receive) are sequentially generated for a model 1 in the test cluster 1 in the wired data transfer section in the behavioral layer, a model b in the test cluster a in the voice conversion section in the behavioral layer, and the construction A of the VC cluster in the wireless data transfer section. For example, the initialization of transmit in the test scenario in the wireless data transfer in the specification layer is turned to a detailed command by combining the initialization of the model 1, the initialization of the model b, and the initialization of the construction A.

[0227] By the above method, a lower-level test cluster can be constructed from a higher-level test cluster during the particularization of the test cluster in the specification layer. In other words, in the conventional method, test clusters, that is, tasks in the respective levels need to be generated individually. In contrast, the method according to the present invention prepares not only shared test clusters (test clusters and test scenarios) for the object circuit to be designed, but also hierarchical test clusters for both the input-side circuit supplying signals to the object circuit and the output-side circuit receiving signals from the object circuit, to generate the lower-level test cluster using the test clusters in the input-side and output-side circuits as well as the higher-level test cluster. Thus, the higherlevel test cluster can be effectively utilized. By this sequential generation of test clusters from the higher level to the lower level, the environment required for verification of the entire system is prepared.

[0228] FIG. 49 is a block diagram illustrating a method for generating test clusters between the behavioral layer and the function layer. FIGS. 50 and 51 are partial enlarged views illustrating the parts for generating test clusters and the generated test clusters shown in FIG. 49, respectively. FIGS. 49 to 51 are also based on the system of the hierarchical test clusters shown in FIGS. 42 to 45.

[0229] At this stage, although detailed description on the procedure is omitted, test clusters for the wireless data transfer section in the function layer are generated using: the test clusters in the wireless data transfer section in the behavioral layer; the 8-bit Timer test cluster (T-TB1) and the 16-bit Timer test cluster (T-TB1) and the 16-bit Timer test cluster-(T-TB2), the 16-bit host I/F test cluster (HTB1) and the 32-bit host I/F test cluster (H-TB2), and the demand DMA test cluster (D-TB1) and the single DMA test cluster (D-TB2) in the VC clusters in the function layer; the ADPCM test cluster in the voice conversion section in the function layer; and the USB test cluster and the 1394 test cluster in the wired data transfer section in the function layer.

[0230] FIG. 52 is a block diagram illustrating a method for generating test clusters between the function layer and the protocol layer.

[0231] At this stage, although detailed description on the procedure is omitted, test clusters for the wireless data transfer section in the protocol layer are generated using: the test clusters in the wireless data transfer section in the function layer; and the 16-bit PCI I/F test cluster and the 16-bit APB I/F test cluster in the VC cluster in the protocol layer. PCI is for Peripheral Component Interconnect that is a high-speed standardized local bus, and APB is for Advanced Peripheral Bus that is a local bus used by ARM Corp.

[0232] The thus-generated test clusters may be stored in the VCDB 100 or may be kept in a place other than the VCDB 100 only during verification.

[0233] While the present invention has been described in a preferred embodiment, it will be apparent to those skilled in the art that the disclosed invention may be modified in numerous ways and may assume many embodiments other than that specifically set out and described above. Accordingly, it is intended by the appended claims to cover all modifications of the invention that fall within the true spirit and scope of the invention.