Data processing: structural design – modeling – simulation – and em – Simulating electronic device or electrical system – Target device
Reexamination Certificate
1999-10-28
2004-01-13
Thomson, W. (Department: 2123)
Data processing: structural design, modeling, simulation, and em
Simulating electronic device or electrical system
Target device
C714S033000, C714S039000, C714S735000, C714S736000, C714S737000, C714S741000, C714S742000, C703S014000, C703S015000, C703S017000, C703S016000, C716S030000, C716S030000, C716S030000, C716S030000
Reexamination Certificate
active
06678645
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to a method and apparatus for examining design integrity of an SoC (System-on-a-Chip) IC having a plurality of functional cores, and more particularly, to a method and apparatus for SoC design validation in which design validation can be evaluated as to an intended function of each core, timings in each core, interface among the cores, and an overall system operation of the SoC IC.
BACKGROUND OF THE INVENTION
In the last 5-years, ASIC technology has evolved from a chip-set philosophy to an embedded core based system-on-achip (SoC) concept. These system-chips are built using predesigned models of complex functions known as “cores” (also known as Intellectual Property or IP) that serve a variety of applications. These cores are generally available either in high-level description language (HDL) such as in Verilog/HDL (known as soft-core), or in transistor level layout such as GDSII (known as hard-core). A system-chip may contain combinations of hard and soft cores for on-chip functions such as microprocessors, large memory arrays, audio and video controllers, modem, internet tuner, 2D and 3D graphics controllers, DSP functions, and etc.
Many times, these cores are purchased from core provider companies and integrated together to make an SoC. When a core is purchased from outside, the core provider provides the design netlist along with the simulation testbench of the core. Thus, when the core is integrated in an SoC, it is desirable to directly apply the core's testbench without any modification to verify its operation in the integrated SoC design.
At the present time, design is described in blocks and sub-blocks using a high-level language such as Verilog/VHDL and simulated by behavioral/gate-level Verilog/VHDL simulators. Such simulation is targeted to check the functionality before design is fabricated into a silicon IC. Design validation is one of the most important and difficult tasks in SoC design because without full functional verification design errors are neither found nor removed. Because of the slow simulation speed and large size of SoC design, SoC level design validation is almost an impossible task with the present day tools and methodologies.
Verification implies checking against an accepted entity. For system design, it means checking the design against the specification. Verification is done to verify that, during system design, the translation from one abstraction level to other is correct. The objective is to find out, within the practical limits, whether the system will work as intended after implementation and manufacturing the design. System-on-a-chip is a single hardware component with multiple embedded cores. Hence, design validation of SoC consists of verification of cores, verification of interconnects among the cores and verification of the combined system operation.
At the present time, along with the development of SoC specification, behavioral models are developed so that simulation testbenches can be created for design validation or the verification of the system operation. The system level verification is done based on the design hierarchy. First, the leaf level blocks, normally at the core level, are checked for correctness in a stand-alone way. Then, the interfaces between those cores are checked for correctness in terms of transaction types and in data contents. The next step is to run application software or equivalent testbenches on the fully assembled chip. This involves hardware/software co-verification (M. Keating and P. Bricaud, “Reuse methodology manual”, Kluwer Academic Press, 1998; J. Stcunstrub and W. Wolf, “Hardware-software co-design”, Kluwer Academic Press, 1997). Software can only be verified by runtime executions of the software code, and therefore, a hardware-software co-simulation has to be performed. Often a hardware prototype either in ASIC (application specific IC) form or using FPGAs (field programmable gate arrays) is also developed and used for the verification of the overall system operation.
Functional Verification
FIG. 1
illustrates the core design at different levels of abstraction and what type of verification methodology is used today at each level. From the highest to lowest abstraction levels,
FIG. 1
shows behavioral HDL level
21
, RTL (register transfer language) level
23
, gate level
25
and physical design level
27
. Verification methods corresponding to such different abstraction levels are listed in a block
28
of FIG.
1
. The basic types of verification tests may include the following:
(1) Compliance testing which is testing to confirm compliance to design specification.
(2) Corner testing which is testing for complex scenarios and corner cases such as in the minimum and maximum conditions in voltage, temperature and process.
(3) Random testing which is basically non-targeted testing that could detect very obscure bugs.
(4) Real code testing which is done by running a real application on the design so that any misrepresentation in functionality can be corrected.
(5) Regression testing which is done by running a collection of tests after any modification in the design. Each bug fix generally requires addition of a new test case with additional test conditions.
Development of testbench depends on the function of the core and the target SoC. For example, a testbench for a processor would execute a test program based on its instruction set, while a testbench for a bus controller interface core, such as a PCI core, would use bus functional models and bus monitors to apply stimulus and check the simulation output results. The problem in this approach is that the behavioral testbenches are extremely slow.
After generating the test cases (stimulus or pattern), it is required to check whether the output responses are correct or not. Today, it is done manually by looking at the output waveform, but as changes occur to the design, this manual checking becomes impossible. Another way to verify output responses is to run the actual software application, which is basically a hardware/software co-simulation. This approach is very inefficient in today's computational resources. Further in such a testbench, actual transactions between the application and core are only a small fraction of the total cycles being simulated. Hence, only a small fraction of functionality is verified.
Interface Verification
In SoC design, the interfaces between the cores need to be verified. Usually the interfaces have a regular structure with address and data connecting the cores either core-to-core or on-chip global buses. The interfaces also have some form of control mechanism and signals such as request/grant protocol and bus controller. The regular structure of these interfaces can be defined by the transaction of limited number of sequences of data and control signals.
Interface verification requires a list of all possible transactions at each interface, thus, it is an impossible task because all possible test cases cannot be generated. Thus, limited verification is done. After this limited verification, the next task is to verify that the core behaves correctly for all values of data and for all sequences of data that each core would receive. Such verification is again impossible, hence, a grossly incomplete verification is done today because all different data values in a transaction are prohibitively too large.
Timing Verification
Timing verification is even harder task than functional verification. Static timing analysis is the most widely available method today. Static timing analysis is performed on representative netlist of cores that have been synthesized with various technology libraries. Static timing analysis tends to be pessimistic because false paths are not properly filtered out. Removal of false paths is a manual process and thus, it is subjected to errors. Gate-level simulation provides a reasonable check for these types of errors but it is not a complete solution since it would take excessive amount of time to develop stimulus and to simulate all the timing p
Rajsuman Rochit
Yamoto Hiroaki
Advantest Corp.
Muramatsu & Associates
Thomson W.
LandOfFree
Method and apparatus for SoC design validation does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for SoC design validation, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for SoC design validation will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3239771