Source: http://www.google.com/patents/US6510541?dq=oakley+5,387,949&ei=4yI4T8nkLYa80QG0xqnWAg
Timestamp: 2017-11-25 08:45:55
Document Index: 255705937

Matched Legal Cases: ['art 511', 'art 512', 'art 521', 'art 522', 'art 521', 'art 522', 'art 523', 'art 524', 'art 523', 'art 525', 'art 526', 'art 525', 'art 526', 'art 525', 'art 526', 'art 527', 'art 528', 'art 527', 'art 528']

Patent US6510541 - Database having a hierarchical structure utilized for designing system-on ... - Google Patents
When a circuit to be designed performs data transmit/receive behavior with other circuits such as a voice codec and a transmitter, not only the circuit to be designed but also the other circuits are provided with test clusters arranged in a hierarchical structure of a specification layer, an behavioral...http://www.google.com/patents/US6510541?utm_source=gb-gplus-sharePatent US6510541 - Database having a hierarchical structure utilized for designing system-on-chip integrated circuit devices and a method of designing the same
Publication number US6510541 B1
Application number US 09/560,868
Publication number 09560868, 560868, US 6510541 B1, US 6510541B1, US-B1-6510541, US6510541 B1, US6510541B1
Inventors Makoto Fujiwara, Kazuyoshi Takemura
Patent Citations (11), Referenced by (19), Classifications (7), Legal Events (5)
Database having a hierarchical structure utilized for designing system-on-chip integrated circuit devices and a method of designing the same
US 6510541 B1
When a circuit to be designed performs data transmit/receive behavior with other circuits such as a voice codec and a transmitter, not only the circuit to be designed but also the other circuits are provided with test clusters arranged in a hierarchical structure of a specification layer, an behavioral layer, and a function layer as in the VC cluster for the circuit to be designed. The test clusters include data describing the I/O relationship between the circuit to be designed and the other circuits in the specification layer, and data for activating sequence control in the other circuits in the behavioral layer. The VC cluster for the object to be designed includes test clusters for sequence control to be particularized in the function layer. Using the test clusters in the VC cluster, test clusters in the lower-level layer can be generated.
1. A database for design of an integrated circuit device, comprising 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 comprising, 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,
wherein the hierarchical structure increases the level of detail of the data in each successive layer of the plurality of layers of the virtual core cluster.
2. The database of claim 1, wherein the test cluster includes at least one of a test bench, a test scenario, a task, and a model.
3. The database of claim 1, further comprising 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,
wherein the test cluster is located in the system verification database.
4. The database of claim 1, wherein the test cluster is linked to the virtual core cluster.
5. The database of claim 1, wherein the virtual core cluster includes: 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, and
the test cluster is arranged in a hierarchical structure of a specification layer, an behavioral layer, and a function layer.
6. The database of claim 5, wherein the test cluster includes 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.
7. The database of claim 5, wherein the test cluster is located outside the virtual core cluster for the target integrated circuit device, and
the test cluster includes 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.
8. The database of claim 5, wherein the test cluster is located outside the virtual core cluster for the target integrated circuit device, and
the test cluster includes in the behavioral layer a description for receiving results of a sequence in the behavioral layer of the virtual core cluster for the target integrated circuit device.
9. The database of claim 5, wherein the test cluster is located inside the virtual core cluster for the target integrated circuit device, and
the test cluster includes 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.
10. A method for designing an integrated circuit device using a database for design, the database for design comprising 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 comprising, for a target integrated circuit device to be designed and the other integrated circuit device that performs signal transmit/receive behavioral 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 comprising 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,
wherein each test cluster is arranged so as to have a corresponding layer to each layer of the hierarchical structure of the virtual core cluster, each lower layer of the test cluster exhibiting an increase in the detail of the data relative to an upper layer of the test cluster, and each layer of the test cluster including data such that the corresponding layer of the virtual core cluster can be verified utilizing the data.
11. The method of claim 10, wherein the test cluster includes at least one of a test bench, a scenario, a task, and a model.
12. The method of claim 10, wherein, 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 are supplied to the virtual core cluster and the test cluster and data in the next lower layer of the test cluster is used.
13. The method of claim 12, wherein, in the particularization, the virtual core cluster and the test cluster of the next lower layer are selected from a table in the database for design.
14. The method of claim 10, wherein 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 are used to generate data in the layer next lower than the given layer of the test cluster for the target integrated circuit device.
15. The method of claim 14, wherein 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.
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.
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.
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.
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.
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.
The test cluster may be linked to the virtual core cluster.
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.
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.
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.
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.
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.
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.
The test cluster preferably includes at least one of a test bench, a scenario, a task, and a model.
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.
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.
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.
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.
FIG. 10 shows an environment used for verification of an behavioral layer in the embodiment of the present invention.
FIG. 11 shows an environment used for verification of a RT layer in the embodiment of the present invention.
FIG. 13 is a conceptual block diagram of processing done by a toggle analysis and circuit optimization section shown in FIG. 1.
FIG. 14 is a view illustrating an example of details of purpose-specific function verification models in the embodiment of the present invention.
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.
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.
FIG. 17 is a block diagram illustrating a method for optimizing the fault inspection strategy in the embodiment of the present invention.
FIG. 18 is a block diagram illustrating the behavior of a function verification assist section in the embodiment of the present invention.
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.
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.
FIG. 24 illustrates an example of processing used when generating a circuit for simulation in the embodiment of the present invention.
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.
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.
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.
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.
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.
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.
FIG. 31 is a block diagram illustrating a verification check method in the embodiment of the present invention.
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.
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.
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.
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.
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.
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.
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.
Hereinbelow, the components of the VCDS shown in FIG. 1 will be described individually in detail in structure, function, and the like.
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-VC1 a, RT-VC1 b and RT-VC2 a, RT-VC2 b for 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-VC1 a, RT-VC1 b, RT-VC2 a, and RT-VC2 b.
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.
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.
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.
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.
Processor (CPU) information: a coordinating verification model used in the behavioral layer and the RT layer, which exists for each processor.
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.”
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-VC1 a and RT-VC1 b, and RT-VC2 a and RT-VC2 b, 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.
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.
Purpose-Specific Function Verification Model
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.
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.
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.
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.
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.
System Verification Database
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.
Fault Inspection Strategy Optimization Section
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.
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.
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.
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.
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.
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.
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.
[Means for function verification and generated models]
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.
(Function Verification Assist Section)
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.
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)
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.
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.
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.
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 1 a otherwise execute processing 1 b, 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 2 a is never executed in this simulation but processing 2 b is invariably executed. Finding this fact, the circuit change part 522 deletes the processing 2 a and 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 2 b be 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.
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.
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.
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.
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.
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.
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.
As a result, there is generated a circuit for simulation allowing for higher-speed processing when the simulator B is used.
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.
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.
(Check Model for Verification)
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.
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.
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.
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.
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.
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.
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.
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.
First, at step ST701, a target specification (function, operating frequency, etc.) is determined, and VCs* for the CPU and the periphyral are selected.
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.
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.
(Structure for System Verification)
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
US5685006 Dec 28, 1994 Nov 4, 1997 Kabushiki Kaisha Toshiba Application specific integrated circuit having hierarchical structure and method of organizing such circuit using inheritance information
US6388329 * Nov 6, 2000 May 14, 2002 Mitsubishi Denki Kabushiki Kaisha Semiconductor integrated circuit having three wiring layers
US6785876 * Nov 2, 2001 Aug 31, 2004 Matsushita Electric Industrial Co., Ltd. Design method for semiconductor integrated circuit device
US7617469 * Aug 21, 2007 Nov 10, 2009 Kabushiki Kaisha Toshiba Assertion description conversion device, method and computer program product
US20080059928 * Aug 21, 2007 Mar 6, 2008 Kabushiki Kaisha Toshiba Assertion description conversion device, method and computer program product
U.S. Classification 716/106, 716/137
Cooperative Classification G06F17/5045, H01L2924/0002
Apr 28, 2002 AS Assignment
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FUJIWARA, MAKOTO;TAKEMURA, KAZUYOSHI;REEL/FRAME:013161/0689