Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent Application
20010025369
Kind Code
A1
Chang, Henry ; et al.
September 27, 2001
Block based design methodology
Abstract
A method and apparatus for designing a circuit system, including selecting a plurality of pre-designed circuit blocks to be used to design the circuit system, collecting data reflecting the experience of the designer regarding the pre-designed circuit blocks, the designer's experience being adaptable to a processing method, accepting or rejecting a design of the circuit system in a manner based on the designer's experience data and acceptable degree of risk, upon acceptance, forming block specifications containing criteria and modified constraints for each of the circuit blocks, upon acceptance, forming block specifications for deploying the circuit blocks on a floor plan of a chip, as a system on a chip, in compliance with the criteria and modified constraints, and substantially without changing the selected circuit block and the processing method.
Inventors:
Chang; Henry
(Sunnyvale, CA)
, Cooke; Larry
(Los Gatos, CA
)
, Hunt; Merrill
(Escondido, CA
)
, Ke; Wuudiann
(Cupertino, CA
)
, Lennard; Christopher K.
(Sunnyvale, CA
)
, Martin; Grant
(Pleasanton, CA
)
, Paterson; Peter
(Mission Viejo, CA
)
, Truong; Khoan
(Milpitas, CA
)
, Venkatramani; Kumar
(Saratoga, CA
)
Correspondence Name and Address:
CROSBY, HEAFEY, ROACH & MAY Two Embarcadero Center, Suite 2000 P. O. Box 7936
John W. Carpenter, Esq.
San Francisco
CA
94120-7936
US
Series Code:
754725
Filed:
January 4, 2001
U.S. Current Class:
716/18
U.S. Class at Publication:
716/18
Intern'l Class:
G06F 017/50
Claims
What is claimed is:
1. A method for designing a circuit system, the method being executed by a designer, the method comprising the steps of: (a) selecting a plurality of pre-designed circuit blocks to be used to design the circuit system; (b) collecting designer's data (including experience data, estimation data, and/or implementation data) regarding the pre-designed circuit blocks, the designer's data being adaptable to a processing method; (c) accepting or rejecting a design of the circuit system in a manner based on the designer's data and acceptable degree of risk; (d) upon acceptance, forming block specifications containing criteria and modified constraints for each of the circuit blocks (FEA); (e) upon acceptance, forming block specifications for deploying the circuit blocks on a floor plan of a chip, in compliance with the criteria and modified constraints without changing the selected circuit block and the processing method.
2. The method of claim 1, wherein the specification includes bus identification information.
3. The method of claim 1, wherein the specification includes test strategies.
4. The method of claim 1, further comprising the step of: (f) upon acceptance, deploying the circuit blocks on the floor plan of the chip by adding standard and system specific interface for the circuit blocks.
5. The method of claim 4, further comprising the step of: (g) forming glue circuits for interconnecting the circuit blocks.
6. The method of claim 1, further comprising the step of: (f) forming a top-level plan for fabricating the selected circuit blocks into the chip based on the circuit specifications.
7. The method of claim 5, further comprising the step of: (h) verifying the proper execution of each of steps (c), (d), (e), (f), and (g), before completing the process.
8. A method for designing a circuit system, the method being executed by a one or more designer, the method comprising the steps of: (a) selecting a plurality of pre-designed circuit blocks to be used to design the circuit system; (b) collecting data reflecting the experience of the designer regarding the pre-designed and yet to be designed circuit blocks, the designer's experience being adaptable to a processing method; (c) accepting or rejecting a design of the circuit system in a manner based on the designer's experience data and acceptable degree of risk; (d) upon acceptance, forming block specifications containing criteria and modified constraints for each of the circuit blocks; and (e) upon acceptance, creating forming block specifications and glue logic for clocks, power, and bus communication to for deploying the circuit blocks on a floor plan of a chip, in compliance with the criteria and modified constraints meet the design objectives without changing the selected circuit block and the processing method.
9. The method of claim 8, further comprising the step of: (f) upon acceptance, forming block specifications for deploying the circuit blocks on a floor plan of a chip, in compliance with the criteria and modified constraints without changing the selected circuit block and the processing method.
10. The method of claim 9, the step (f) further comprising forming virtual circuit specifications for each of the circuit blocks, to deploy the circuit blocks on the floor plan of the chip.
11. The method of claim 8, the designer's data experience including at least one member of the group consisting of: field of use, simulation, and partial or full implementation of at least one of the pre-designed blocks.
12. The method of claim 9, further comprising the step of (g) forming glue logic for interconnecting the circuit blocks.
13. The method of claim 9, further comprising the step of (g) forming collar interfaces for interconnecting the circuit blocks.
14. The method of claim 9, the step (f) further comprising: upon acceptance, forming a top-level plan for fabricating the selected circuit blocks into the chip based on the virtual circuit specifications.
15. The method of claim 9, further comprising the step of: verifying the proper execution of each of steps (c), (d), (e), and (f) before completing the process.
16. The method of claim 14, further comprising the step of: generating and verifying the resulting physical layout, mask and test data necessary to fabricate said chip.
17. A method for expanding an existing methodology for assessing feasibility of a circuit design based on a predetermined type of parameter, the method comprising the steps of: (a) selecting a plurality of circuit blocks to be used in the circuit design; (b) receiving the predetermined type of parameter for the circuit blocks; (c) assessing a first feasibility using the existing methodology based on the predetermined type of parameter, the first feasibility including a first risk indicator and first time/cost indicator; (d) receiving at least a second type of parameter that has not been used in the existing methodology; (e) processing the second type of parameter to accommodate the existing methodology; and (f) assessing a second feasibility using the existing methodology based on the predetermined type of parameter and the second type of parameter, the second feasibility including a second risk indicator, and a second time/cost indicator, wherein the second risk indicator has not been substantially increased compared with the first risk factor due to the use of the existing methodology, and the second time/cost factor has been increased compared with the first time/cost factor due to the impact of the second type of parameter.
18. The method of claim 17, wherein the predetermined type of parameter is field of use data, and the second type of parameter is either estimation data or implementation data.
19. A method for expanding an existing methodology for assessing feasibility of a circuit design based on a predetermined type of parameter, the method comprising the steps of: (a) selecting a plurality of circuit blocks to be used in the circuit design; (b) receiving the predetermined type of parameter for the circuit blocks; (c) assessing a first feasibility using the existing methodology based on the predetermined type of parameter, the first feasibility including a first risk indicator and first time/cost indicator; (d) receiving at least a second type of parameter that has not been used in the existing methodology; (e) changing the existing methodology to accommodate the second type of parameter; and (f) assessing a second feasibility using the changed methodology based on the predetermined type of parameter and the second type of parameter, the second feasibility including a second risk indicator, and a second time/cost indicator, wherein the second risk indicator has been increased compared with the first risk factor due to the change of the existing methodology, and the second time/cost factor has not been substantially increased compared with the first time/cost factor due to the change of the existing methodology.
20. The method of claim 19, wherein the predetermined type of parameter is field of use data, and the second type of parameter is either estimation data or implementation data.
21. A method for expanding an existing methodology for assessing feasibility of a circuit design based upon a predetermined set of design characteristics, the method comprising the steps of: (a) determining to be the field of use a set of design characteristics for which design risk is known and acceptably small; (b) selecting a plurality of circuit blocks to be used in the circuit design; (c) receiving predetermined design characteristics for the circuit blocks; (d) assessing a first feasibility using the existing methodology based upon the field of use characteristics, the first feasibility including a first risk indicator and first time/cost indicator; (e) receiving at least a second design characteristic which has not been used in the existing methodology; (f) processing the second design characteristic to accommodate the existing methodology; and (g) assessing a second feasibility using the existing methodology based on the field of use characteristics and the second design characteristic, the second feasibility including a second risk indicator, and a second time/cost indicator, wherein the second risk indicator has not been substantially increased compared with the first risk factor due to the use of the existing methodology, and the second time/cost factor has been increased compared with the first time/cost factor due to the impact of the second design characteristic.
22. The method of claim 21, where in the predetermined design characteristics are within the definition of the field of use data, and the error-risk associated with correct prediction of the second type of design characteristic being known from either estimation data or implementation data.
23. A method for expanding an existing methodology for assessing feasibility of a circuit design based upon a predetermined set of design characteristics, the method comprising of: (a) determining to be the field of use a set of design characteristics for which design risk is known and small; (b) selecting a plurality of circuit blocks to be used in the circuit design; (c) receiving predetermined design characteristics for the circuit blocks; (d) assessing a first feasibility using the existing methodology based upon the field of use characteristics, the first feasibility including a first risk indicator and first time/cost indicator; (e) receiving at least a second design characteristic which has not been used in the existing methodology; (f) changing the existing methodology to accommodate the second type of design characteristic; (g) assessing the second feasibility using the changed methodology based on the field of use design characteristics and the second type of design characteristic, the second feasibility including a second risk indicator, and a second time/cost indicator, wherein the second risk indicator has been increased compared with the first risk factor due to the change of the existing methodology, and the second time/cost factor has not been substantially increased compared with the first time/cost factor due to the change of the existing methodology.
24. The-method of claim 23, where in the predetermined design characteristics are within the definition of the field of use data, and the error-risk associated with correct prediction of the second type of design characteristic being known from either estimation data or implementation data.
25. A method for performing a feasibility assessment for a circuit design, comprising the steps of: (a) receiving requirements and constraints for the circuit design; (b) selecting a plurality of pre-designed circuit blocks to be used in the circuit design; (c) collecting field of experience data for the circuit blocks; (d) forming a first level decision rule using the field of experience data for the circuit blocks, the first level decision rule including an acceptance region, a rejecting region, and an uncertain region; (e) making a first level predication using the requirements and constraints based on the first level decision rule; (f) accepting the circuit design if the first level predication is within the acceptance region of the first level decision rule, and rejecting the circuit design if the first level predication is within the rejecting region of the first level decision rule; and (g) forming a second level decision rule for making a second level predication for the circuit design, if the first level prediction is within the uncertain region of the first level decision rule.
26. The method of claim 25, further comprising the steps of: (h) collecting estimation data for the circuit blocks, wherein the second level decision rule in (g) is formed using the estimation data, the second level decision rule including an acceptance region, a rejecting region, and an uncertain region; (i) making the second level predication using the requirements and constraints based on the second level decision rule; (j) accepting the circuit design if the second level prediction is within the acceptance region of the second level decision rule, and rejecting the circuit design if the second level predication is within the rejecting region of the second level decision rule; and (k) forming a third level decision rule for making a third level predication for the circuit design, if the second level prediction is within the uncertain region of the second level decision rule.
27. The method of claim 26, further comprising the steps of: (L) collecting implementation data for the circuit blocks, wherein the third level decision rule in (k) is formed using the implementation data, the third level decision rule including an acceptance region, a rejecting region, and an uncertain region; (m) making the third level prediction using the requirements and constraints based on the third level decision rule; (n) accepting the circuit design if the third level prediction is within the acceptance region of the third level decision rule, and rejecting the circuit design if the third level predication is within the rejecting region of the third level decision rule.
28. The method of claim 27, wherein: the estimation data has a higher cost of collection and a higher accuracy than the field of experience data; and the implementation data has a higher cost of collection and a higher accuracy than the estimation data.
29. A method for refining a first decision rule for a circuit design, comprising the steps of: (a) receiving requirements and constraints of a circuit design; (b) selecting a plurality of pre-designed circuit blocks to be used in the design; (c) identifying at least one of the circuit blocks as a critical circuit block and the rest of the circuit blocks as non-critical circuit blocks; (d) collecting field of experience data for the non-critical circuit blocks, and collecting estimation data and/or implementation data for the critical circuit block; and (e) forming a refined first decision rule by combining the field of experience data with the estimation data or implementation data.
30. The method of claim 29, the decision rule including an acceptance region, a rejecting region, and an uncertain region, the method further comprising the steps of: (f) making a prediction using the requirements and constraints based on the refined decision rule in (e); and (g) accepting the circuit design if the predication is within the acceptance region, and rejecting the circuit design if the predication is within the rejecting region.
31. The method of claim 30, wherein: the estimation data has a higher cost of collection and a higher accuracy than the field experience data; and the implementation data has a higher cost of collection and a higher accuracy than the estimation data.
32. A method for forming a second decision rule for a circuit design, comprising the steps of: (a) receiving requirements and constraints of the circuit design; (b) selecting a plurality of pre-designed circuit blocks; (c) identifying at least one of the circuit blocks as a critical block and the rest of the circuit blocks as non-critical circuit blocks; (d) collecting estimation data for the non-critical circuit blocks, and collecting implementation data for the critical circuit block; and (e) forming a refined second decision rule by using the estimation data and the implementation data.
33. The method of claim 32, the decision rule including an acceptance region, a rejecting region, and an uncertain region, the method further comprising the steps of: (f) making a predication using the requirements and constraints based on the refined decision rule in (e); and (g) accepting the circuit design if the prediction is within the acceptance region, and rejecting the circuit design if the predication is within the rejecting region.
34. The method of claim 33, wherein: the implementation data has a higher cost of collection and a higher accuracy than the estimation data.
35. A method for organizing experience data of a designer regarding a plurality of pre-designed circuit blocks to be used to design a circuit system, wherein the method is executed by the designer and the experience data is used to perform a feasibility assessment for the circuit system design, the method comprising the steps of: (a) defining a set of parameters by which experience data can be measured; (b) identifying experience data of the designer regarding the circuit blocks; (c) classifying the identified designer's experience data into a plurality of classes, wherein the experience data classes correspond to the circuit blocks; (d) using the designer's experience data to form a decision rule, the decision rule including an acceptance region, a rejecting region, and an uncertain region; and (e) making a prediction using the requirements and constraints based on the decision rule.
36. The method of claim 35, further comprising the step of: (f) accepting the circuit system design if the estimation is within the acceptance region of the decision rule, and rejecting the circuit system design if the estimation is within the rejecting region of the decision rule.
37. The method of claim 35, further comprising the step of: (f) refining the classes of the experience data to minimize feasibility assessment error.
38. The method of claim 35, further comprising the step of: (f) certifying the experience data.
39. The method of claim 35, wherein the identified experience data includes at least one of predicted experience data or collated experience data.
40. The method of claim 35, further comprising the step of: (f) building a model upon the identified designer's experience data to predict similar parameters of a similar design.
41. For execution in an integrated circuit device design scheme, wherein a device design comprises a plurality of pre-existing design blocks, a method of increasing glue logic distribution efficiency, the method comprising the steps of: copying a selected glue logic element, thereby creating a duplicate element set including said selected element and its copy; distributing said duplicate element set to the plurality of design blocks.
42. For execution in an integrated circuit device design scheme, wherein a device design comprises a plurality of pre-existing design blocks, a method of distributing a plurality of glue logic elements among the design blocks, the method comprising the steps of: if a first glue logic element includes an output net driving a plurality of loads, splitting the first element into a plurality of derivative glue logic elements; and distributing said derivative elements to the plurality of design blocks.
43. The method of claim 42, wherein each derivative element includes only a single output load.
44. The method of claim 42, wherein if a first glue logic element includes a plurality of inputs, the split element is the first element.
45. The method of claim 42, wherein a derivative element includes only two-inputs.
46. For execution in an integrated circuit device design scheme, wherein a device design comprises a plurality of pre-existing design blocks, a method of distributing a plurality of glue logic elements among the design blocks, the method comprising the steps of: analyzing the plurality of elements for a selected quality; merging a selected glue logic element into a selected block in a manner based upon the analysis.
47. The method of claim 46, wherein the selected block is selected in a manner based upon its functional affinity to the selected element.
48. The method of claim 47, wherein said functional affinity comprises whether the merger would reduce the number of physical I/O elements required for the proper function of said circuit device design.
49. The method of claim 46, wherein if two or more design blocks are equal candidates for the merger, the block having the lowest pin density is chosen.
50. The method of claim 47, wherein said functional affinity comprises whether a selected element and a selected block together have improved chip level timing characteristics.
51. For execution in an integrated circuit device design scheme, wherein a device design comprises a plurality of pre-existing design blocks, a method of distributing glue logic, the method comprising the steps of: identifying a plurality of elements that can be neither copied and distributed among the design blocks or merged with the design blocks; clustering the identified plurality of elements.
52. The method of claim 51, wherein each of the clustered elements includes multiple loads on input nets and multiple loads on output nets.
53. The method of claim 51, wherein the plurality of elements include inputs having similar function.
54. For execution in an integrated circuit device design scheme, wherein a device design comprises a plurality of pre-existing design blocks, a method of distributing glue logic among the design blocks, the method comprising the steps of: identifying a first feature of a first glue logic element; identifying a second glue logic element having a second feature making the second glue logic element compatible with the first glue logic element; merging said first glue logic element with the identified second glue logic element.
55. The method of claim 54 wherein said first feature comprises the number of pins required by said first glue logic element.
56. The method of claim 54 wherein said first feature comprises the input structure of said first glue logic element.
57. The method of claim 54 wherein said first feature comprises the output structure of said first glue logic element.
58. The method of claim 54 wherein the second glue logic element is a design block.
59. A method for converting a specific interface of a circuit block, the method comprising the steps of: (a) defining a standard interface; and (b) connecting a collar interface to the circuit block, the interface having a first portion connectable to the circuit block, a second portion in compliance with the standard interface, and a third portion for converting the specific interface into the standard interface.
60. The method of claim 59, wherein the collar interface can be in hard, soft, or firm format.
61. The method of claim 59, wherein the circuit block is a memory, a processor, a random logic, or an analog/mixed signal.
62. The method of claim 59, wherein the collar interface includes multiple layers, including a block-specific standard layer and a system-specific layer.
63. A method for connecting a first circuit block and a second circuit block, the first circuit block having a first specific interface and the second circuit block having a second specific interface, the method comprising the steps of: (a) defining a standard interface for connecting the first and second circuit blocks; (b) connecting a first collar interface to the first circuit block, the first interface having a first portion connectable to the first circuit block, a second portion in compliance with the standard interface, and a third portion for converting the first specific interface into the standard interface; (c) connecting a second collar interface to the second circuit block, the second collar interface having a first portion being able to be connected to the second circuit block, a second portion in compliance with the standard interface, and a third portion for converting the second specific interface into the standard interface; and (d) connecting the first and second circuit blocks using the standard interface.
64. The method of claim 63, wherein the first and second collar interfaces can be in hard, soft, or firm format.
65. The method of claim 63, wherein the first and second circuit block is a memory, a processor, a random logic, or an analog/mixed signal.
66. The method of claim 63, wherein the first and second collar interfaces include multiple layers, including a block-specific standard layer and a system-specific layer.
67. A collar interface for converting a specific interface of a circuit block into a standard interface the collar interface comprising: (a) a first portion containing components connectable to the specific interface of the circuit block; (b) a second portion in compliance with the standard interface; and (c) a third portion for converting the specific interface into the standard interface.
68. The collar interface of claim 67, wherein the apparatus can be in hard, soft, or firm format.
69. The collar interface of claim 67, wherein the circuit block is a memory, a processor, a random logic, or an analog/mixed signal.
70. The collar interface of claim 67, wherein the collar includes multiple layers, including a block-specific standard layer and a systemspecific layer.
71. An interface system for connecting a first circuit block and a second circuit block through a standard interface, the first circuit block having a first specific interface and the second circuit block having a second specific interface, the interface system comprising: (a) a first collar interface connected to the first circuit block, the first collar interface including (1) a first portion containing components connectable to the specific interface of the first circuit block, (2) a second portion in compliance with the standard interface, and (3) a third portion containing components for converting the first specific interface into the standard interface; and (b) a second collar interface connected to the second circuit block, the second collar interface including (10) a first portion containing components connectable to the specific interface of the second circuit block, (2) a second portion in compliance with the standard interface, and (3) a third portion containing components for converting the second specific interface into the standard interface.
72. The interface system of claim 71, wherein the first and second collar interfaces can be in hard, soft, or firm format.
73. The interface system of claim 71, wherein the first and second circuit block is a memory, a processor, a random logic, or an analog/mixed signal.
74. The interface system of claim 71, wherein the first and second collar interfaces include multiple layers, including a block-specific standard layer and a system-specific layer.
75. In a circuit design method, wherein a circuit under design comprises a plurality of pre-existing design blocks, a method of selecting a circuit bus, the method comprising the steps of: observing data transactional behavior between the plurality of design blocks; deriving from the observed transactional behavior a plurality of bus criteria; selecting a bus structure from a library of available bus design blocks in a manner based upon said plurality of bus criteria; integrating said selected bus structure into said circuit.
76. The method of claim 75, wherein said plurality of bus criteria comprise at least one member of the group consisting of bus size, bus bandwidth, bus performance level, and signal latency.
77. The method of claim 75 further comprising, before selecting a bus, clustering the plurality of design blocks according to a plurality of communication requirements between the blocks, thereby forming a plurality of block clusters.
78. The method of claim 77, wherein assigned to each formed cluster is a bus selection criteria comprising at least one member of the group consisting of bus size, bus bandwidth, bus performance level, and signal latency.
79. The method of claim 75, wherein the deriving step comprises deriving requirements for communications between at least one of the blocks and an I/O structure within the circuit.
80. The method of claim 75, further comprising mapping the selected bus structure into the circuit by modifying its bus interface logic.
81. The method of claim 75, wherein said deriving step comprises:creafing a data transfer matrix, including a plurality of data transfer count entries; and organizing the data transfer matrix by moving the largest of the counts toward a central axis in the matrix;
82. The method of claim 81, wherein said deriving step further comprises: weighting the count entries according to a selected weighting criteria.
83. The method of claim 77, wherein said deriving step comprises creating a cluster value matrix, including a plurality of data representing distribution of data flow within the bus to be selected; optimizing data flow within the bus to be selected by selectively reorganizing said distribution data.
84. The method of claim 75, wherein the step of observing data transactional behavior is performed on a behavioral model.
85. The method of claim 84, wherein the behavioral model includes a plurality of design blocks and an I/O structure.
86. The method of claim 84, wherein the behavioral model is modified to collect transaction data.
87. In a block based design methodology for realizing a circuit design, the design comprising a plurality of pre-existing design blocks, a method of designing a device embodying the design and enabling testing of the device after manufacture, the method comprising the steps of: establishing a test development framework; developing, in compliance with the framework, a plurality of test blocks for testing the design blocks; mapping the plurality of test blocks to develop, in compliance with the framework, a test for the circuit design.
88. The method of claim 87, wherein the establishing step comprises identifying the plurality of pre-existing design blocks according to a set of qualifiers, said qualifiers comprising at least one entry from the group consisting of a test model, a test method, a test data, and a test interface.
89. The method of claim 88, wherein the set of qualifiers comprises an abstraction of the design blocks, enabling top-down test planning.
90. The method of claim 87, wherein the framework comprises a test budget for each of the blocks.
91. The method of claim 87, further comprising enabling concurrent testing on more than one of the blocks.
92. The method of claim 91, wherein said enabling step comprises expanding a device-level test interface.
93. The method of claim 91, wherein said enabling step comprises manipulating a tester timeset to minimize tester setup time between test blocks.
94. The method of claim 87, further comprising packaging the framework and a block test as a test-ready design block for test re-usability.
95. A method of designing an integrated circuit device for post-manufacturing testability, the circuit comprising a plurality of pre-existing design blocks, the method comprising the steps of: abstracting each of the pre-existing blocks to establish a circuit test development framework; formulating a design scheme, including a plurality of tests, for the device while maintaining a predictable estimation of the overall testability of the circuit design.
96. The method of claim 95, wherein the circuit testing framework is optimized for a plurality of test objectives.
97. The method of claim 95, wherein the circuit testing framework will be rejected if a risk level of reaching a pre-determined block testability level is greater than an acceptable level.
98. The method of claim 95, wherein the framework comprises test cost budgeting criteria.
99. The method of claim 98, further comprising the execution of test efficacy exchanges by adding a test to the design scheme.
100. The method of claim 98, further comprising the execution of test efficacy exchanges by removing a test from the design scheme.
101. The method of claim 95, further comprising refining the design scheme within designated tolerances.
102. The method of claim 95, further comprising enabling concurrent test development as part of the design scheme, by allowing each block to be tested with a selected suitable test method.
103. The method of claim 95, wherein the design scheme includes a test interface and the interface is compatible with a plurality of dissimilar test protocols.
104. The method of claim 95, further comprising simplifying a test scheduling portion of the design scheme by concurrently executing more than one block test.
105. The method of claim 95, further comprising duplicating test vectors among design blocks, thereby reducing the elapsed time between test blocks with the design scheme.
106. The method of claim 95, wherein a plurality of similar test blocks are executed consecutively, thereby reducing elapsed test time.
107. The method of claim 95, further comprising using designer feedback to update the design scheme for adaptation to a plurality of circuit designs.
108. A method of verifying the proper function of a circuit design, the design comprising a plurality of pre-existing design blocks, the method comprising the steps of: obtaining a circuit design model and a circuit test bench; partitioning the circuit design model into a plurality of block models; creating a bus model interconnecting the plurality of block models; creating a plurality of test benches for verifying the plurality of block models and bus model; using the test benches to verify the function of the plurality of block models and the bus model.
109. The method of claim 108, wherein the circuit design model includes a top level.
110. The method of claim 108, wherein the bus model comprises glue logic circuitry from the block models.
111. The method of claim 108, wherein verifying the function of a block model comprises register transfer language verification.
112. The method of claim 108, wherein verifying the function of a block model comprises pre-layout netlist verification.
113. The method of claim 108, wherein verifying the function of a block model comprises post-layout netlist verification.
114. The method of claim 108, wherein after attempting to verify the plurality of block models, the plurality of block models are modified for cycle accuracy.
115. The method of claim 108, further comprising the steps of: developing a test bench for the circuit design; and attempting to verify the function of the circuit design.
116. The method of claim 115, wherein verifying the function of the circuit design comprises register transfer language verification.
117. The method of claim 115, wherein verifying the function of the circuit design comprises pre-layout netlist verification.
118. The method of claim 115, wherein verifying the function of the circuit design comprises post-layout netlist verification.
119. The method of claim 108, wherein after attempting to verify the circuit design, the circuit test bench is modified for cycle accuracy.
120. A method for evolving an initial behavioral level test bench with no timing content into a cycle accurate test bench suitable for functional verification of all timing accurate views of the design, the method comprising the steps of: determining invariant output of execution of the design on the test bench; modifying the test bench to include clocks; executing the modified test bench on a timing accurate model; and comparing the invariant output of the test bench.
121. A method of verifying the proper function of a circuit design, the design comprising a plurality of pre-existing design blocks, the method comprising the steps of: obtaining a circuit design model including a top level and a plurality of block models; obtaining circuit test bench; creating a bus model interconnecting the plurality of block models; creating a plurality of test benches for verifying the plurality of block models and bus model; using the test benches to verify the function of the plurality of block models and the bus model.
122. A method for evolving an initial behavioral level test bench without timing content into a cycle accurate test bench suitable for functional verification of substantially timing-accurate views of a design, the method comprising the steps of: determining an invariant output of execution of the design on the test bench; modifying the test bench to include clocks; executing the modified test bench on a substantially timing-accurate model; and comparing the invariant output of the testbenches.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application depends for priority upon commonly assigned U.S. Provisional Patent Application No. 60/102,566, entitled BLOCK-BASED DESIGN METHODOLOGY, filed Sep. 30, 1998, which is incorporated herein in its entirety by reference.
FIELD OF THE INVENTION
[0002] The present invention relates generally to integrated circuit ("IC") device design, and more specifically to the design of systems re-using pre20 designed circuit blocks.
BACKGROUND OF THE INVENTION
[0003] In recent years, constant innovation in silicon process technology has drastically reduced the price and increased the performance and functionality of integrated circuit devices, thus stimulating the development of the electronics manufacturing and information processing industries. In turn, these fast growing industries impose increasing demands on the integrated circuit design system developers for still faster and cheaper devices. As a result, the design industry is now undergoing drastic changes, including:
[0004] (1) Chip designs are getting larger and more complex. For example, in 1997, a typical integrated circuit contained from 100-500K gates. In 1998, the typical device contained one to two million gates.
[0005] Technology in 1999 has shown the continuation of this trend with devices of four to six million gates being built.
[0006] (2) Chip designs are becoming more application-specific. In the early days of IC design, device manufactures would produce various "off-the-shelf" chips, which end users would design into their electronic products. Currently, electronic product manufactures more often order custom chip designs to perform specific functions.
[0007] (3) Electronic product development is now primarily driven by consumer demand, which has shortened product life cycles and, therefore shortened allowed design time and resources. For example, in 1997, the average design cycle was between 12-18 months. In 1998, that average time decreased to 10-12 months and in 1999 the industry is pushing towards 8-10 month design-cycle times.
[0008] (4) Design time constraints require parallel design effort. Formerly, critical design decisions for upstream system components could wait until downstream system component designs were verified. Design managers no longer have the luxury of sequentially performing design tasks. Several system components may have to be developed concurrently. Thus, design managers are required to make crucial predictions before at least some system component designs are complete.
[0009] To address these demands, electronic system design is now moving to a methodology known in the art as Block Based Design ("BBD"), in which a system is designed by integrating a plurality of existing component design blocks (also referred to in the art as "intellectual property blocks" or "IP blocks"). These pre-designed blocks may be obtained from internal design teams or licensed from other design companies, and may be supported by fundamentally different design structures and environments. Moreover, pre-designed blocks may be developed to meet different design requirements and constraints.
[0010] Another challenge faced by designers using BBD is the front-end (project acceptance) delays and risk brought about by uncertainty in determining system design feasibility. Current ASIC (application-specific integrated circuit) designs are primarily presented at the RTL (register transfer level) stage, and some even earlier, at specification level, to designers by customers. These designs are then partitioned in a manner based upon the limitations of available synthesis technology, according to the area, performance, and power tradeoffs required to provide cost15
effective implementation. In this manner, the designer accepts a system specification as input and ultimately provides a netlist-level design for physical implementation (including design place, route, and verification). If design specifications are within the capabilities of the intended or available processing technology, including clocking, power, and size specifications, the available design methodology is reasonably predictable and works well with available circuit design tools.
[0011] However, the RTL-level design and the system-level design activities are typically uncoupled or loosely coupled, meaning there is no coherent link from the system-level functional definition to the ASIC (RTL) level. The RTL-level design is developed based upon a paper ASIC specification and verified by a newly formed test suit created around the ASIC interface. Thus, available design and implementation methodologies for ASIC design present a number of problems, which hamper efficient block integration.
[0012] First, current methodologies do not provide a top-down approach to comprehensively evaluate and ensure compatibility to integrate a plurality of design blocks provided by multiple sources having differing design considerations, while providing hierarchical verification and short assembly time within tight time-to-market constraints.
[0013] Also, existing methodologies for ASIC design do not provide scalability. A significant number of existing methodologies are focused around a flat design. This approach has led to significant problems in the length of time required to assemble the top-level design for a system having more than one million gates.
[0014] In addition, existing ASIC design methodologies are not suitable for reuse of pre-designed circuit blocks. Available schemes do not provide guidelines to solve the timing, clock, bus, power, block arrangement, verification, and testing problems associated with integrating circuit design blocks within specific device architectures. Thus, without a comprehensive approach to block reuse, existing methodologies bring about an ad-hoc and unpredictable design approach, reduce design realization feasibility, increase cost and time to delivery, and often trigger performance-reducing modifications to the pre-designed circuit blocks themselves in order to fit them into the designed system. Furthermore, existing methodologies do not provide performance trade-off analysis and feedback of critical design parameters, such as clock frequency, and area versus risk of successfully and predictably completing chip designs and implementations.
[0015] There is, therefore, a need for a methodology that can satisfy the evolving environment and address the shortcomings of the available art.
[0016] There is also a need for a suitable methodology for using and re-using pre-designed circuit blocks from multiple sources in a circuit design.
[0017] Combining IP blocks also brings about the need for "glue" logic, the logic that allows the blocks to work together on a single device. Glue logic is the logic primarily responsible for interconnecting design blocks, and normally resides between the blocks, dispersed throughout the design. Glue logic elements can be added to a design during various stages of chip planning, or can reside at the outermost boundary of each block within a design to act as an interconnect mechanism for the host block. Regardless of its source, glue logic must be optimally placed within the design to minimize wire congestion and timing complications which arise from placement of glue logic between blocks, introducing delays which may not have been contemplated by the original block designer.
[0018] There is therefore a need in the art to which the present invention pertains for an improved method of placing and distributing glue logic in a block based design.
[0019] There is also a need for a glue logic distribution mechanism that takes into account the functional affinity of various glue logic elements, and groups them into new design blocks.
[0020] There is also a need in the relevant art for a glue logic distribution mechanism that returns an optimized amount of glue logic to existing designs.
[0021] In addition, existing ASIC design methodologies are not suitable for reuse of pre-designed circuit blocks. Available schemes do not provide guidelines to solve the timing, clock, bus, power, block arrangement, verification, and testing problems associated with integrating circuit design blocks within specific device architectures. Since the circuit blocks are from multiple inconsistent sources, the challenge is how to integrate these circuit blocks into a circuit system in a fashion suitable to block-based design.
[0022] Therefore, there is a need for a method and apparatus suitable to inter-connect the circuit blocks from multiple inconsistent sources in a fashion suitable to block-based design.
[0023] There is another need for a method and apparatus to provide interfaces for converting the circuit blocks having different interfaces into the ones having standardized interfaces.
[0024] Of course, all ICs, even those containing an entire system on a single chip, must pass a series of tests to verify that the chip meets performance requirements and that there are no hidden manufacturing defects. If a manufacturing defect is missed, the faulty chip may not be discovered until after the assembly process or, worse yet, in the field. The cost of such "test escapes" in terms of their effect on customer satisfaction can be devastating to a product line.
[0025] Generally, there are three types of tests for detecting defects: DC parametric tests, AC parametric tests, and functional ("PLL") tests. In DC parametric tests, the inputs, outputs, input-to-output transmission, total current, and power consumption of the chip are measured. In AC parametric tests, the rising and falling times of the input and output signals, delay time in propagation between input and output terminals, minimum clock pulse width, and operation frequency of the chip are measured. In functional tests, the chip is tested to see if it functions as designed under prescribed operating conditions. Typically, applying a test pattern to an input terminal ("test vectors") and comparing an output pattern detected at an output terminal with an expected pattern carries out a functional test.
[0026] Before the advent of Design for Test ("DFT") methodologies, designers created and assembled a chip, then passed the completed design to test designers. The test designers then added package-level test logic, and sent the chip to the manufacturer (the "fab"). The fab testers then probed the chip and ran a board test protocol including the abovedescribed tests on the package-level logic. The available Scan Design methodology is a simple example of a highly effective and widely used method for applying a "single" test method to the entire chip with predictable and consistent test result. Other ad hoc methods may be used to handle nonscannable design styles.
[0027] Today, logic previously contained in a whole chip is now used as a single virtual component (VC) or design block to be included in a larger chip. Thus, tests can no longer be designed after circuit design is complete. Designers must plan how to test each design block, as well as the whole packaged chip, throughout the design process. The design process must therefore ensure testability by applying one or more test methods as appropriate.
[0028] The benefits of DFT are well known. DFT logic and test vector verification functions allow shorter, production-ready tests early in a production cycle. Also, DFT scan paths provide access to chip and system states that are otherwise unavailable. A good DFT plan thereby shortens time-to-market and reduces testing cost by easing the front-end design process and the development of manufacturing tests.
[0029] There are therefore four needs presented by the available art. First, a new DFT for BBD must be able to make effective use of the pre-designed test data among other dissimilar test methods, to share limited test access, and to meet the overall SOC level test objectives. test suites are used to verify a multi-block design. Each test in the suite is used to test each of the blocks before they are integrated. Then, after integration of the blocks, significant effort is required to adjust the test suite to enable functional verification at the system level. The process of testing and debugging may need to be repeated for a number of iterations before a final, full system verification can be confidently provided.
[0030] One available approach to this problem is the substitution of implementation modules for their corresponding behavioral models, thereby allowing chip level simulation and testing in a mixed mode situation. While this approach can offer desirable results if performed effectively, and can be less costly than the iterative block-based simulations described above, this approach is still quite expensive and slow, since the entire chip must be simulated to obtain reliable functional verification.
[0031] An especially acute challenge is presented in multi-block designs by the need to functionally verify bus structures. In the available art, bus verification is achieved in either of two ways. The bus may be debugged and verified as an integral part of the overall chip, or it may be verified using bus functional models for the pre-defined blocks, taking into account the detailed implementation provided by newly authored blocks. However, integral bus verification can be slow and costly. The entire chip must be used to verify the bus design, and integral bus verification can only be executed late in the design cycle, when debugging is difficult and time consuming due to the level of detail and the potential for finding no bus-related bugs. The bus functional model approach eases some of these problems, but requires implementation detail for the newly authored blocks. Moreover, the bus functional models may be error prone
SUMMARY OF THE INVENTION
[0032] To addresses the shortcomings of the available art, the present invention provides a method and apparatus for designing a circuit system, the method, comprising the steps of:
[0033] (a) selecting a plurality of pre-designed circuit blocks to be used to design the circuit system;
[0034] (b) collecting data reflecting the experience of the designer regarding the pre-designed circuit blocks, the designer's experience being adaptable to a processing method;
[0035] (c) accepting or rejecting a design of the circuit system in a manner based on the designer's experience data and acceptable degree of risk;
[0036] (d) upon acceptance, forming block specifications containing criteria and modified constraints for each of the circuit blocks (FEA);
[0037] (e) upon acceptance, forming block specifications for deploying the circuit blocks on a floor plan of a chip, in compliance with the criteria and modified constraints without changing the selected circuit block and the processing method.
BRIEF DESCRIPTION OF THE DRAWINGS
[0038] FIG. 1 is a flowchart illustrating a design process based on the block-based design methodology, in accordance with the present invention;
[0039] FIG. 2 is a flowchart illustrating the steps of front-end access, in accordance with the present invention;
[0040] FIG. 3 illustrates a clock-planing module, in accordance with the present invention;
[0041] FIG. 4 illustrates a bus identification and planing module, in accordance with the present invention;
[0042] FIG. 5 illustrates a power-planning module, in accordance with the present invention;
[0043] FIG. 6 illustrates the I/O and analog/mixed-signal requirements, in accordance with the present invention;
[0044] FIG. 7 illustrates a test-planning module, in accordance with the present invention;
[0045] FIG. 8 illustrates a timing and floor-planning module, in accordance with the present invention;
[0046] FIG. 9 shows meta flow of a block design, in accordance with the present invention;
[0047] FIG. 10 illustrates data flow of a chip assembly, in accordance with the present invention;
[0048] FIG. 11 illustrates task flow of a chip assembly, in accordance with the present invention; and
[0049] FIGS. 12, 13, 14, and 15 illustrate functional verification flow in accordance with the present invention.
[0050] FIG. 28 shows a classification collapse curve, in accordance with the present invention.
[0051] FIG. 29 shows a plurality of design blocks in a circuit design, wherein glue logic interferes with optimal design block placement.
[0052] FIG. 30 illustrates a first type of glue logic distribution, in accordance with the present invention.
[0053] FIG. 31 illustrates second and third types of glue logic distribution, in accordance with the present invention.
[0054] FIG. 32 shows a collaring process of embedding a circuit block into a collar, in accordance with the present invention.
[0055] FIG. 33 illustrates creating a complete set of abstracts for a block, to be used in a design in accordance with the present invention;
[0056] FIG. 34 is a flowchart illustrating the collaring process, in accordance with the present invention.
[0057] FIG. 35 shows a collar having two layers, in accordance with the present invention.
[0058] FIG. 36 illustrates the logic view between a collar and a circuit block, in accordance with the present invention;
[0059] FIG. 37 illustrates the physical view between a collar and a circuit block, in accordance with the present invention.
[0060] FIG. 38 shows a system design without using the collaring process of the present invention.
[0061] FIG. 39 shows a system design using the collaring process of the present invention.
[0062] FIG. 40 shows a computer system for performing the steps in the collaring process of FIG. 34, in accordance with the present invention.
[0063] FIG. 41 illustrates a series of steps comprising the bus identification and planning scheme of the present invention.
[0064] FIG. 42 illustrates the internal structure of an interconnection section of a behavioral model constructed according to method of the present invention.
[0065] FIGS. 43-47 and 49-56 are tables illustrating improved delay times through bus modifications implemented using the system and method of the present invention.
[0066] FIG. 48 illustrates a bus bridge used in the method and system of the present invention.
[0067] FIG. 57 illustrates a bus bridge used in the method and system of the present invention.
[0068] FIG. 58 illustrates a bus bridge including a FIFO used in the method and system of the present invention.
[0069] FIG. 59 is a table illustrating bus utilization and latency characteristics for a variety of bus types.
[0070] FIG. 60 illustrates an Exemplary Consistency Check truth table
[0071] FIG. 61 illustrates the top-level hierarchy of a chip from the DFT perspective using the method of the present invention.
[0072] FIG. 62 illustrates a design made up of functional blocks and socket access ports ("SAPs").
[0073] FIG. 63 is a table illustrating appropriate test methods for a variety of design architectures.
[0074] FIG. 64 is a flowchart illustrating the top-level architecture specification procedure for the method and system of the present invention.
[0075] FIG. 65 illustrates a socketization procedure of the method and system of the present invention.
[0076] FIG. 66 illustrates a block level test development procedure of the method and system of the present invention.
[0077] FIG. 67 illustrates a chip level test development procedure of the method and system of the present invention.
[0078] FIG. 68 illustrates a test flow from planning to chip assembly according to the method and system of the present invention.
[0079] FIG. 69 illustrates a designer's view of the front-end acceptance verification tools of the present invention.
[0080] FIG. 70 illustrates a designer's view of moving from chip planning to block design.
[0081] FIG. 71 illustrates a designer's view of the evolving bus block model and test bench generation of the method and system of the present invention.
[0082] FIG. 72 illustrates a designer's view of a block test bench and a chip test bench.
[0083] FIG. 73 is a designer's view of block and chip logical verification models.
DETAILED DESCRIPTION PREFERRED AND ALTERNATIVE EMBODIMENTS
[0084] To overcome the shortcomings of the available art, the present invention discloses a novel methodology and implementation for block5
based design ("BBD").
[0085] Referring to FIG. 1, a flowchart 100 illustrating a design process based on the block-based design (BBD) methodology in accordance with the present invention is shown. As shown in FIG. 1, the design process includes front-end acceptance design stage 102, chip planning design stage 104, block design stage 106, chip assembly design stage 108, and verification design stage 110.
[0086] Front-end acceptance design stage 102 enables a system integrator (chip designer) to evaluate the feasibility of a prospective design project. At front-end acceptance design stage 102, the designer receives a specification from a customer including functional and other requirements (such as delivery time and budget) for designing an ASIC. The customer may also provide some pre-designed circuit blocks and test benches for these circuit blocks. Along with the customer supplied blocks, the designer utilizing front end acceptance design stage 102 may accept, as input, circuit blocks from different sources, some of which may be supplied by a third party, some of which may be legacy circuit blocks, and some of which may be newly authored. These selected circuit blocks can be in a soft, firm, or hard design state. (Note that: soft state is at RTL level; hard is at GDSII level; and firm is between soft and hard, such as at gate level or netlist level). Front-end acceptance design stage 102 then collects the designer's available experiences, including field of use data, estimation data through behavior simulation, and/or partial implementation data. The process of front-end acceptance design stage 102 then provides an assessment to help the designer decide whether to accept the design project based on the design property parameters, including the customer's requirements, the designer's available experience , and the designer's acceptable degree of risk. Furthermore, based on the functional specification, the result of front-end acceptance design stage 102 dictates the final set of pre-designed circuit blocks to be used in the circuit design.
[0087] Front-end acceptance design stage 102 provides for three phases of assessment: coarse-grained assessment, medium-grained assessment, and fine-grained assessment. If an assessment at one phase is not satisfactory, front-end acceptance design stage 102 enables refinement of design property parameters and makes a further assessment at the next phase.
[0088] If the proposed design project is found acceptable, front-end acceptance design stage 102 provides comprehensive steps to ensure that problems in the design ahead are detected early, and to ensure that these problems can be solved in a comprehensive manner within the bounds defined by project requirements, the designer's available experience, and the processing method selected. Front-end acceptance design stage 102
generates a design specification defining a processing methodology including selected pre-designed circuit blocks, design criteria, and inter-dependant design constraints.
[0089] Chip planning design stage 104 translates the design specification from the output of front-end acceptance design stage 102 into block specifications for each of the selected circuit blocks. Tasks executed in chip planning design stage 104 include: (1) developing plans for chip design, assembly, and implementation focused on predictability of delays, routability, area, power dissipation, and timing, and (2) identifying and adjusting constraints. Specifically, based on the design criteria and interdependant constraints provided as the output of front-end acceptance design stage 102, chip planning design stage 104 provides chip planning within the bounds (such as requirements and constraints) dictated at front-end acceptance. The inventive chip planning design stage 104
considers one constraint at a time, and yet meets the overall design criteria as specified by front-end acceptance design stage 102. Chip planning design stage 104 achieves this by forming the budget for each of the circuit blocks selected in front-end acceptance design stage 102, revising the specification for the circuit block, and adjusting constraints within the processing method specified by front-end acceptance design stage 102. In contrast to the chip planning design stage of the present invention, existing methodologies either generate new functional blocks or change the processing technology to meet the design criteria, increasing design time and raising project risk. Chip planning design stage 104 also generates specifications for glue logic (i.e. the hardware that is required to interconnect the selected circuit blocks), discussed in further detail below. Chip planning design stage 104 provides as output three types of glue logic, including new glue logic blocks that occupy one or more areas in a chip, distributed glue logic distributed into the selected circuit blocks, and top level block glue logic elements.
[0090] To seamlessly interconnect the selected circuit blocks, if necessary, block design stage 106 embeds an interface (called a collar) around each circuit block to form a standard interface. Since a circuit block can be soft, firm, or hard, each collar may be soft, firm, or hard as well. Block design stage 106 output provides that: (1) all circuit blocks in the chip meet the constraints and budget, and fit into dictated chip design plans and architectures; (2) chip assembly design stage 108
is provided with all required models and views of all circuit blocks; (3) the design is enabled for developing methodologies and flows for authoring the new circuit blocks generated in the chip planning design stage 104, adapting legacy circuit blocks, and adapting third party circuit blocks; and (4) the design fits into given chip architectures and budgets.
[0091] Chip assembly design stage 108 integrates circuit blocks to tapeout the top-level design for design stage fabrication. Chip assembly design stage 108 includes the final placement of hard blocks and chip bus routing, as well as the completion of any global design details. Chip assembly design stage 108 does not begin until all circuit blocks are designed, modified, and integrated into the chip plan. Inputs for chip assembly design stage 108 include power, area, and timing margin specifications received from the front-end acceptance design stage 102 or chip planning design stage 104.
[0092] Verification design stage 110 ensures that the design at each stage meets the customer functional requirements as detailed in the functional specification and chip test bench supplied at front-end acceptance design stage 102. Verification design stage 110 includes functional verification 112, timing verification 114, and physical verification 116.
[0093] Functional verification step 112 ensures that the logic functions and chip test benches for the selected circuit blocks at each stage of the design meet the functional requirements of the customer specification. Functional verification can be performed during front-end acceptance design stage 102, chip planning design stage 104, block design stage 106, or chip assembly design stage 108. Timing verification ensures that signal timing at each stage of the design is appropriate to generate the logic functions and pass the tests specified in the customer's specification. Timing verification can be performed during front-end acceptance design stage 102, chip planning design stage 104, block design stage 106, or chip assembly design stage 108. Physical verification ensures that the physical layout for the circuit design meets the customer specification.
[0094] During the design process, front-end acceptance design stage 102, chip planning design stage 104, block design stage 106, and chip assembly design stage 108 not only perform their intended functions, but also generate the information needed for functional verification 112, timing verification 114, and physical verification 116 which, together, comprise verification function 110. If any errors occur during verification at a particular stage of the design process, these errors are preferably corrected before going to the next stage.
[0095] Thus, at chip assembly design stage 108, the design process not only generates a top-level design for fabricating a chip, but also completes verifications of chip test benches for each of the circuit blocks used in the design and the overall chip test bench for the chip.
[0096] FIGS. 2-15 will now be described in summary form. Each of these figures provides a high level description of materials discussed in greater detail below.
II. FRONT END ACCEPTANCE 102
[0097] Referring to FIG. 2, flowchart 200 illustrates the steps 210-216 of front-end acceptance design stage 102, in accordance with the present invention.
III. CHIP PLANNING 104
[0098] Chip planning design stage 104 includes the following modules:
[0099] (1) clock planning;
[0100] (2) bus identification and planning;
[0101] (3) power planning;
[0102] (4) I/O and analog/mixed-signal requirements;
[0103] (5) test planning;
[0104] (6) timing and floor planning; and
[0105] (7) bus verification.
[0106] Referring to FIG. 3, there is shown the clock-planning module, in accordance with the present invention.
[0107] Referring to FIG. 4, there is shown the bus identification and planing module, in accordance with the present invention.
[0108] Referring to FIG. 5, there is shown the power-planning module, in accordance with the present invention.
[0109] Referring to FIG. 6, there is shown the I/O and analog/mixed-signal requirements, in accordance with the present invention.
[0110] Referring to FIG. 7, there is shown the test-planning module, in accordance with the present invention.
[0111] Referring to FIG. 8, there is shown the timing and floor-planning module, in accordance with the present invention.
IV. BLOCK PLANNING 106
[0112] Referring to FIG. 9, there is shown the flow of the block design stage, in accordance with the present invention.
V. CHIP ASSEMBLY 108
[0113] Referring to FIG. 10, there is shown the data flow of the chip assembly design stage, in accordance with the present invention.
[0114] Referring to FIG. 11, there is shown the task flow of the chip assembly design stage, in accordance with the present invention.
VI. VERIFICATION 110
[0115] Referring to FIGS. 12, 13, 14, and 15, there is shown the functional verification flow for the verification design stage of the present invention.
SCALABLE METHODOLOGY FOR FEASIBILITY ASSESSMENT
[0116] Turning first to front-end assessment, FIG. 16 illustrates the inventive methodology to assess feasibility of a circuit design using a plurality of pre-designed circuit blocks, in accordance with the present invention.
[0117] In FIG. 16, the inputs for the methodology are originally designed to use field of use data as inputs. However, in assessing a new design project, new types of inputs 1, 2, and 3 need to be used to assess the feasibility of the new design project. To accommodate the methodology, the new types of inputs are processed so that the methodology can use the new types of inputs to perform feasibility assessment for the new design project.
[0118] FIG. 17 shows the feasibility assessment result using the methodology shown in FIG. 16, in accordance with the present invention. FIG. 17 indicates risk on the vertical axis and time/cost along the horizontal axis. According to the risk indicator, the risk of using these three types of new data increases slightly compared with the risk presented when only using the field of use data. Also from FIG. 17, it can be seen that a type 3 input has the greatest impact on risk. However, according to the time/cost indicator, by using these three types of new data, the time/cost increases greatly compared with the risk created by using only field of use data. By considering the ramifications of the inventive risk v. time/cost calculus indicated in FIG. 17, the pre-staged blocks are pre-designed and qualified for proper use in the design methodology. The pre-staged design plan is preferably a section of an existing methodology, for example, a block-authoring piece.
[0119] FIG. 18 shows a methodology to assess the feasibility of a circuit design using a plurality of pre-designed circuit blocks, in accordance with the present invention. In FIG. 18, the inputs for the methodology are originally designed to use field of use data as inputs. However, in assessing a new design project, new types of inputs X, Y, Z need to be used to assess the feasibility of the new design project. To accommodate the new input types, the methodology is modified so that the new inputs can be used to perform feasibility assessment for the new design project.
[0120] FIG. 19 illustrates the assessed feasibility obtained using the inventive methodology shown in FIG. 18, in accordance with the present invention. FIG. 19 indicates risk along the vertical axis and time/cost along the horizontal axis. According to the risk indicator, the risk provided when using the three new input types increases greatly in comparison with the risk provided when only using field of use data. Also from FIG. 19, we can see that a type Z input has the greatest impact on risk. However, according to the time/cost indicator, the time/cost provided by additionally using these three types of new inputs increases moderately comparing with the time/cost by only using the field of use data.
[0121] The new types of inputs can be estimation data or implementation data for the pre-designed circuits. Based on the results shown in FIGS. 16-19, a system integrator can make tradeoff decisions.
FEASIBILITY ASSESSMENT IN THE FRONT END ACCEPTANCE
[0122] The front-end acceptance (FEA) design stage 102 in FIG. 1 involves feasibility and risk assessment of a proposed design. A design is feasible if the assessed criteria are within allowable risk tolerance.
[0123] In a sense, the FEA is a process of design refinement to a point at which the system integrator can assume the risk of accepting a proposed design. As such, it is the process of reduction of lack-of-knowledge and, therefore, error in the requested design's final outcome. As a starting point, the FEA process receives a set of design requirements delivered by a customer, the integrator's risk profile for accepting a design, a set of pre-designed blocks, and the integrator's previous knowledge of and experience with the pre-designed blocks. The pre-designed blocks can be at various levels of resolution (hard, soft or firm). The resolution, previous experience and understanding of a block give rise to a large range of error-bounds in the prediction of area, power, performance, etc., across the blocks.
[0124] For each of the blocks, the design refinement may be presented in three levels of resolution:
[0125] (1) integrator's field of experience (FOE),
[0126] (2) estimation using actual models and tools to execute those models, and
[0127] (3) dip by taking a block into a higher level of design resolution than that at which it was received.
[0128] It should be noted that three levels of design resolution are arranged in ascending order as: soft, firm, and hard. Efficiency is achieved by providing a mechanism to conduct feasibility assessment without needlessly refining all block and interconnect criteria predictions.
[0129] FIG. 20 shows a flow diagram for an FEA process in accordance with the present invention.
[0130] In FIG. 20, the FEA process includes three phases of feasibility assessment, reflecting the three levels of design refinement discussed above. These three phases are: coarse-grained assessment, mediumgrained assessment, and fine-grained assessment.
[0131] Coarse-grained assessment is a field of experience dominated assessment based upon the design integrator's previous experience with similar designs. Coarse-grained assessment is especially suited to ten's of blocks and system design options, and to situations where design estimation-error tolerance is on the order of fifty percent or more. Coarse analysis can be used to make a cursory examination of blocks being considered, where the estimation of interaction between blocks is non-critical. At this phase, it is most likely that not all blocks being considered are used in the final design.
[0132] Medium-grained assessment is an estimation-dominated assessment, to estimate by analytic formulation of behavior through equation or simulation. It is suitable for from two to ten system design options, and to a situation where acceptable design estimation-error tolerance is on the order of 20%, and the integrator has an understanding of how the blocks interact. It can be used to examine the interaction between blocks critical to operational sufficiency of the design. In this phase, all blocks in consideration have a high probability of being used in the final design.
[0133] Most refined (fine-grained) assessment is a design-dip-dominated assessment to make measurements from a refinement of block design. Dipping is a process in which a new block is transformed into a soft block, a pre-designed soft block into a firm block, and a pre-defined firm
[0134] A key part of the FEA process illustrated in FIG. 20 is how to calculate the acceptable global error (or overall error) in the prediction of system criteria, and identify which few blocks require estimate refinement to bring the global error to within acceptable bounds. This calculation process requires three parameters:
[0135] (1) Estimate of the acceptable global error for making a decision;
[0136] (2) Estimate of the global error which will result from current system analysis; and
[0137] (3) The sensitivity of the global error to the error in estimating a particular block in the design (also referred to as the block-error impact).
[0138] The first parameter is defined by the risk-profile of the system integrator, the constraints supplied by the customer, and a good prediction of the global error, which will result from basing a system prediction upon the current state of data. The second and third parameters are all derived from building accurate Error Impact Curves. Referring to FIG. 21, there is illustrated the driving of the refinement process, given the error impact curves, in accordance with the present invention.
[0139] To further define the FEA process, the present invention uses four basic assessment techniques:
[0140] 1. FEA Decision Process: Defining Data-In, Data-Out and the Decision Process based upon Data-Out. (i.e., How is Data-Out related to the assessment of acceptable risk?);
[0141] 2. FEA Data Extraction Process: Moving from a complete set of Data-In for the abstraction level being considered to the generation of Data-Out;
[0142] 3. FEA Block-Refinement Identification: Defining a common mechanism for establishing the SystemEstimation Impact, given the Estimation-Error and Block Criticality within a system design. (i.e., Highest potential impact blocks are refined further if the acceptance criteria for the Decision Process are not met); and
[0143] 4. FEA Assessment-Axes Metrics: Defining the actual metrics to be used for each of the axes-of-acceptance associated with FEA. (i.e., defining how the criticality of a block within a system is defined).
[0144] In the method and system of the present invention, a set of estimate correctness curves are used to validate the FEA process. Each of the estimate correctness curves is presented over an FEA axes, which visually provides the elements and criteria for validating the FEA process. To better explain the function of an estimate correctness curve, the following elements and criteria are defined. Collectively, these elements and criteria are referred to as the FEA Axes of Acceptance. These definitions apply to both blocks and the overall system.
1
Power per mode of operation (e.g., mW) Performance intra-cycle delay (e.g., ps/ns/us) latency (e.g., ns/us/ms) throughput (objects/second-e.g., 50 kB/sec) Area area including: gates, routing, perimeters, unused white-space (e.g., mils) Cost Non-recurrent engineering cost (e.g., U.S. $) Cost per Unit (e.g., U.S. $) Schedule Resource allocation (e.g., man-years) Deliverable timelines (time) Risk Possibility of error (%) Impact of errors (U.S. $, and/or time)
[0145] Before conducting the FEA process, the customer provides the system integrator with as much of the following information as possible:
[0146] (1) A set of circuit blocks which are either in soft, firm, or hard format;
[0147] (2) A set of simulators (estimators) or previous-experience estimates for the blocks, along with error-tolerances for the estimates;
[0148] (3) A set of specifications describing the overall chip functionality and performance requirements; and
[0149] (4) A set of stipulations regarding acceptable schedule, cost, and risk for the project.
[0150] The customer may also provide:
[0151] (5) Behavioral definitions for any new blocks to be incorporated into the chip; end
[0152] (6) Identification of known critical issues.
[0153] Before conducting the FEA process, the system integrator should:
[0154] (1) Determine a risk profile by which design suitability is assessed, including:
[0155] a. Guard-Bands--The integrator's over-design margin for each of the FEA axes;
[0156] b. Acceptance Risk--Certainty that design will satisfy requirements prior to accepting a customer request. This is simply expressed as a standard-deviation measure--the A.sigma. design-acceptance risk; and
[0157] c. Rejection Risk--Certainty that specified design is unable to be assembled and fabricated with available blocks. Note that rejection is actually a risky behavior for the system integrator: the risk being taken is that the rejected design was actually feasible even though initial assessment made it appear doubtful. This is also expressed as a standard-deviation measure--the R.sigma. design-rejection risk.
[0158] (2) Verify that the submitted blocks, in combination with any new or third party blocks, are sufficient to meet the project constraints within acceptable limits of risk.
[0159] Referring to FIG. 22, an exemplary correctness curve estimate is shown, in accordance with the present invention. The horizontal axis is an FEA axis, which can represent any customer constraints or the overall constraint for the system. To facilitate explanation, assume that the FEA axis represents power. The vertical axis represents estimate correctness. According to FIG. 22, the guardband of the power constraint is between the constraint-initially specified by the customer and the constraint modified by the FEA process. Note that, in the example given, the design is rejected because the power constraint modified by the guardband lies within the rejection region. This is true even though the power constraint initially specified is not in the rejection region.
[0160] If the modified power constraint had been between the A.sigma. and R.sigma. markers, the FEA refinement process would have proceeded. This process would continue to reduce the expected error variance (i.e., the power-error variance, in this example) until an accept or reject decision can be made based on a refined estimate correctness curve.
[0161] Referring to FIG. 23, a process to validate an FEA is shown, in accordance with the present invention. The inventive FEA validation process includes four phases:
[0162] 0. Pre-FOE Phase (not shown):
[0163] Obtain the customer design constraints for each of the FEA axes of acceptance. Modify each of these constraints by the required guard-band. These modified customer constraints are used only for verification of the FEA process, and are referred to simply as the design constraints.
[0164] 1. FOE Dominant Phase:
[0165] The system integrator commences FEA by combining together the FOE estimates and estimate-error tolerances to determine whether the required constraints are guaranteed (confidence is higher than defined by: A.sigma. for a pass, or R.sigma. for a fail) to be met.
[0166] (a) If, despite consideration of third party blocks, constraints are still violated, then the design is not possible. The system integrator must return to the customer with a set of options and the constraints met by these configurations.
[0167] (b) If the constraints are met to within acceptable risk, the FEA process is complete.
[0168] (c) If there exists less-than-acceptable confidence of predicting the passing or failure of the design, then the estimation phase must commence. To enter the estimation phase, the set of "most-likely-to-pass" design configurations (i.e., best) must be selected.
[0169] 2. Estimation Dominant Phase:
[0170] For the set of best designs derived from the FOE stage, an identification of criticality must be made; i.e., given the error tolerances on each of the blocks involved, which are statistically the most likely to validate that the design has passed constraint validation. This will be a product of both the size of the variance of the FOE specification prediction for a block, and the impact that block has upon the design constraint in question. Estimation should proceed by stubbing-out as much of the non-critical design as possible, and generating design specific estimates for that which remains.
[0171] (a) Violation: Similar to procedure 1(a) discussed above.
[0172] (b) Satisfaction:: If the level of indeterminacy is unlikely to be reduced further by increasing the accuracy of estimation (reducing the amount of stubbing will not improve the estimate in any statistically significant way, due to the fact that the error-tolerance is dominated by blocks already included in the estimation), or a full estimate of the SOC design has been built given existing block models, then the best design must pass onto the dipping phase.
[0173] 3. Design-Dip Dominant Phase:
[0174] Refine the block estimate to which the global error is most sensitive, then proceed as per the estimation phase. Continue iterating this process until the FEA is confirmed or denied. The definition of statistical criticality is similar.
[0175] Referring to FIG. 24, a refined estimate correctness curve using the inventive FEA design-property refinement process of the present invention is shown. Through the refinement process of moving from FEA phases O
[0176] It should also be noted that to keep the inclusion of the criticality measures C.sub.block neutral relative the system inequalities expressed above (i.e, .sigma..sub.system is formulated from an expression which combines the criticality scaled block errors: C.sub.blocks..sigma.block), the criticality measures are normalized such that: .SIGMA..sub.blocks(Cblock).sup.2=1. The process for assessing this varies slightly depending upon the class of system-property being assessed. From the perspective of FEA, there are three classes of system-properties each described below:
[0177] Absolute (Block) Constraints (e.g., Intra-Cycle Delay, Throughput)
[0178] Relative (Block) Constraints (e.g., Power, Area, Latency, Cost, Schedule)
[0179] Mixed (Block) Constraints (e.g., Quality)
[0180] For simplicity, for an FEA Criteria .beta. define BDC as the Block Design Constraint where: BDC.sub.block=A.C.sub.block..sigma.block in the case of test for design acceptance, and BDC.sub.block=R.C.sub.block..sigm- a.block in the case of test for design rejection. Then, for each FEA Criteria:
[0181] a. Absolute Constraint: To achieve a decision-quality result each block, or each block immersed in its immediate environment (e.g., including routing load, etc.), must pass the DDC for the Absolute Constraint . Mathematically, achievement of a decision-quality result on an Absolute Constraint implies:
[0182] For all blocks .epsilon. in the system, BDC.sub.block<DDC
[0183] b. Relative Constraints: A decision quality result is achieved if the square summation of block-design constraints throughout the system is less than the square of the DDC. The term relative is used as the acceptable error of assessment for this constraint has the flexibility of being partitioned amongst the blocks, which make up the entire system. Note that some assessment criteria of the Relative type may have multiple constraints. An example of this is Latency, as there may be several critical paths, which contribute to a valid assessment of the complete system. Mathematically, achievement of a decision-quality result on a Relative Constraint implies .SIGMA..sub.blocks(BDC.sub.block).sup.2<DD- C.sup.2, assuming that all block-errors are Gaussian-distributed, independent random-variables.
[0184] c. Mixed Constraints: A mixed constraint is a type that involves both the relative and absolute types of constraint. For example Quality is a mixed constraint. No block within a design can exceed a specified bound on its measure of quality, but the summation of all quality assessment across the system must also fall to within a specified range. In this case there is both a DDC.sub.block for the blocks, as well as a DDC.sub.system for the overall system. Mathematically, for a mixed-constraint system-property two criteria need to be satisfied:
[0185] (i) For All: block .delta. system, BDC.sub.block<DDC.sub.block
[0186] (ii) .SIGMA..sub.blocks(BDC.sub.block).sup.2<(DDC.sub.system).su- p.2
[0187] Referring to FIG. 26, there is shown a process of identifying the need 20 for block-estimate refinement, in accordance with the present invention.
[0188] As shown, there are three steps in FEA Block-Refinement Identification, including:
[0189] 1: For each FEA assessment criteria of the Absolute or Mixed Constraint type, the level of work required to achieve the absolute error tolerances (CIC's) is determined. As a by-product of refining a model to satisfy the need of Absolute Constraints, some error-bounds associated with Relative Constraints may also be reduced.
[0190] 2: Based upon the error predicted after the models are refined to satisfy the Absolute Constraints, and Absolute part of the Mixed Constraint Type, the remaining system-error tolerance (CIC) for the system are determined and partitioned amongst the separate IP blocks. The partitioning will be defined in such a way as to minimize the work required to build an estimate. The flexibility of this partitioning is moderated by the defined criticality of contribution for each of the blocks within the assembled system. This defines the notion of error impact. Note that this problem must simultaneously optimize necessary work against acceptable error-tolerance along each FEA axis.
[0191] 3: If at any stage system suitability cannot be determined using the proposed CIC's, these need to be tightened further and the process re-iterated either:
[0192] (a) for the block, if a specific absolute constraint is insufficient, or
[0193] (b) for the system, if a relative constraint for the chip is insufficient.
[0194] Referring to FIG. 27, there is shown an FEA Assessment-Axes Metric, containing a table defining the concept of Assessment-Axis Criticality (AAC), in accordance with the present invention and including, where appropriate, exemplary criticality measures. The AAC relates to Expected System-Impact (ESI) through Expected Estimation Error (EEE) based upon the following relation: ESI=AAC*EEE.
[0195] As shown in FIG. 27, the table contains five columns, as the following:
2
(1) Assessment Axis FEA is measured based upon these criteria (2) Constraint Type Each FEA Assessment Axis may have one or multiple constraint-types associated with it (3) Constraint Class Class as defined above (4) Routing Refinement Type of routing-refinement necessary to ensure that the impact of chip routing is of the same degree of error as the specified block and system constraints (5) Criticality Measure Standardized way of measuring the criticality of a property associated with an FEA Assessment Axis
[0196] Some elements of the table make reference to Routing Criticality. Routing Criticality is defined for any output pin of a block or chip input pad as Pin Routing Criticality=(Expected Net Length)*(Capacitance/Unit Length). Block Routing Criticality is the sum of Pin Routing Criticality across the output pins of a block.
[0197] The symbol: .alpha. denotes an effective-routing-area scalar whereby: .alpha.*(Routing Criticality) translates units and the scale of Routing Criticality into an area-applicable number.
[0198] Power consumed as a consequence of routing requires an estimate of activity on the lines. This can be done at a block or pin level of resolution. When applied to the block, the activity estimate is derived from the average activity on the output lines of the block, denoted: E.sub.block.
[0199] A point connection counts as any fanout point unless several fanout points are connected by use of a shared bus. A shared bus counts as a single distinct block. Routing criticality is a measure of the expected difficulty in routing connections to a pin and, therefore, it is a measure of FEA uncertainty.
[0200] Note that many of the assessment axes might be identified as mixed constraints at some level of resolution; e.g., an area may be defined as mixed after initial floor plan is defined and used to partition the SOC design chip-level constraints into block-level constraints. However, the dominant constraint type used during the rapid FEA period is listed.
[0201] The term Error used in the table refers to the bound on error as relates to the property in question.
[0202] Organizing the Field of Experience Data
[0203] Designer experience is a crucial part in the system-decision process of the BBD methodology. The BBD methodology extends the concept of experience associated with a single key designer or architect to the concept of "company design experience". This general "pool" of experience is referred to as the BBD Field of Experience (FOE) of the present invention.
[0204] It is the purpose of BBD method to propose four concepts and mechanisms for the building and use of FOE. These concepts are:
[0205] a) Data Gathering--Definition of rigorous processes for obtaining and initiating FOE data.
[0206] b) Data Classification--Information classification and mechanisms for developing relevant classifications. Such classification guarantees that gathered data may be statistically analyzed, extrapolated, and globally refined as the amount of accumulated design-knowledge increases.
[0207] c) Data Certification--Definition of a process that builds the correct assurance of "trust" in what might otherwise be referred to as "rule-of-thumb" numbers. Certifying FOE data will guarantee that estimates built from the FOE database are statistically well bounded.
[0208] d) Data Application--The mechanism for application of FOE to the design process. This is a part of Front End Acceptance for BBD.
[0209] Field of Experience Definition
[0210] In BBD, Field of Experience can be defined as compiled data from measurement of prior designs classified according to design styles, design purpose, and critical measurements of design characteristics. Critical characteristics may include: area, throughput, power and latency. The definition of Experience-Based Estimation is systematic prediction based upon experience with similar designs or design behaviors. It follows that the definition of FOE Estimation is Experience-Based Estimation using FOE data.
[0211] It should be noted that this is distinct from BBD Estimation in that it does not imply the specific analysis of the design in question, or--where the hardware design is actually known from previous exposure--specific analysis of a new behavior requested of that hardware. For example, a DSP core may have been developed within a company and an FIR-Filter embedded routine run upon it in a previous instantiation of the core. It may then be requested that feasibility of an FFT algorithm running on that same core be considered. If that first rule-of-thumb is based solely upon the previous algorithmic efficiency observed when executing the FIR operation upon the design, but without entering into the details highly specific to the FFT algorithm, then this is an FOE estimate.
[0212] Field of Experience must explicitly draw upon information derived during a set of previous design projects. FOE data must be able to be catalogued, stored and accessed through a standard database.
[0213] There are three different classes of experience-based data used in design, each form of data being associated with a specific error profile:
[0214] a) Project Data--Designer-requested estimate at project time. The designer does not draw upon the experience of others as logged in the FOE database, but more upon his own uncatalogued design experience. Error in the design estimate is given by a Designer-Error Variance, which has been observed for general designs. Designer-Error Variance is built from measuring a general history of designers' ability to accurately predict results.
[0215] b) Predicted Data--Within a design classification but without a specific project in mind, a designer is requested to give his best-guess parameter-relationships for extending existing FOE data. In this case, the FOE data being extended may consist of as little as a single design-point. Error for this is in part specified by the designer's best guess at the parameterization error, but also modified by the history of designers' ability to accurately predict results. Assuming statistical independence, these error variances would be summed.
[0216] c) Collated Data--Collected, classified and parameterized data from a set of design experiences. There is a possibility of measurement error directly associated with this data, but this is likely to be minor. The main error is defined as the difference between measured results and those predicted by the variation of data-parameters.
[0217] Note the Project Data is not a form of FOE data as it provides no mechanism to extend the current estimates to future designs. Furthermore, as Project Data is gathered at the commencement of a project, not the completion, it is not verifiable against catalogued design experience. This implies that it is not certified. Any data gathered from Final Measurement of the design may be entered into the FOE database, and the accuracy of the Project Data versus Final Measurement be used to refine Designer Error Variance for the company.
[0218] Predicted Data are referred to as FOE seed-data. Predicted Data may be immediately applied to FOE estimation on like designs.
[0219] A common classification of the types of data received must apply to both of the above sources of FOE data. Such common classification permits the quick identification and cataloging of received data. Initial classification-specification is regarded as the planning stage for FOE, and the entering/gathering of data is the building stage. As the amount of information in the FOE database grows, the refinement process is applied to reduce error tolerances to within those being observed statistically. In parallel with all three of these stages is the FOE certification process.
[0220] The parameters listed above are used to extrapolate from existing, general FOE data to derive project-specific FOE estimates. Such a relationship between extrapolated estimates and FOE data is preferably defined for each design classification. Each parameter FOE relationship may be defined by a designer's personal experience (see Predicted Data above), or may be empirically specified through curve-fitting the FOE data if sufficient information is available. Parameters might include such technical variables as pipeline depth, degree of parallelism, bit-width, and clocking-speed.
[0221] It should be noted that FOE applies not only to design blocks, but also to the interconnect between the blocks. In such cases, FOE may be specified as the cost of routing between blocks of one classification and blocks of another. Like the application to blocks, FOE estimates for interconnect may also be parameterized.
[0222] Estimating with Maximum Accuracy:
[0223] A key aspect of FOE is the generation of estimates of maximum accuracy given the data provided. This is a twofold process:
[0224] a) Refinement--As mentioned above, refinement is the process of reducing the error-of-estimate to within that being observed statistically. That is, when the amount of FOE data in a specific category is small, the error tolerance for the data is large. This is not due to an inherent error, but rather to the unknown (or untested) applicability of the parameterized data to other specific designs. As the number of examined designs increases, the statistical spread of data can be measured directly against parameterized predictions.
[0225] When a large number of cases are catalogued for a specific classification of design, then the accuracy of the parameterization method will be well established. Identification of large correlated error (as opposed to random spread of data) could motivate the rethinking of the parameter relationships.
[0226] b) Classification Collapse--The different classifications of designs may be related-by proximity to one another. For example, the Butterfly FFT implementation may be one classification of design, but all FFT blocks may be regarded as closely proximal to this design. If the number of data associated with a particular classification of interest is too small to be statistically significant, then close proximity FOE data may be collapsed together to reduce the overall estimation error. The collapsing of classifications together will itself induce an error due to the slight difference in design types, but the statistical improvement in terms of number of designs considered may overwhelm this difference-error. It is preferable to compute a curve such as that shown in FIG. 28, and from that pick the configuration of best error.
[0227] The process/use model for FOE is therefore as follows:
[0228] I. Choose Block Classifications applicable to block being assessed
[0229] II. Does enough data exist for that classification? (i.e., is the Expected Error sufficient?)
[0230] Yes--Return the best FOE estimate and END
[0231] No--Proceed
[0232] III. Collapse categories of close proximity until estimate error ceases to improve
[0233] IV. Is the Expected Error sufficient for FOE estimation?
[0234] Yes--Return the best FOE estimate and END
[0235] No--Proceed
[0236] V. Ask the designer to generate his best guess for the design. (This may be a dip into the Estimation Phase of BBD.)
[0237] FOE Certifying
[0238] Certification of FOE is the process by which the FOE information gathered is shown to be reliable. This certification process will establish the error of estimation during the Building and Refinement stages.
[0239] There are two aspects of certification:
[0240] a) Certification of Completeness--all FEA metrics must be measurable through the parameterization schemes provided.
[0241] b) Certification of Accuracy--including experience measures for designer, and the definition of process to ensure accuracy of collected data.
[0242] Glue Logic
[0243] The present invention further discloses an improved glue logic distribution and reduction methodology. The combination of three alternative glue logic distribution mechanisms comprises a preferred embodiment of the present invention. First, glue logic that is not incorporated into predesigned blocks can be duplicated into multiple copies for distribution to the existing blocks. Second, logic that has no affinity to a block at the top level can be left as small blocks, optimally placed to minimize effective gate monopolization, wiring congestion, and floorplanning impact. Third, where the number of blocks exceeds the block place and route limitations, glue logic may be clustered into glue cluster blocks until the block count is reduced to an acceptable level.
[0244] Referring to FIG. 29, there is illustrated a circuit design view wherein glue logic 2910 resides disadvantageously between interconnected blocks, thereby rendering inefficient the use of significant areas of silicon real estate and creating significant wiring congestion.
[0245] Referring to FIG. 30, we will begin with a description of the present method for creating multiple copies of glue logic for distribution to larger top-level blocks. If an element 3010 has output nets driving multiple loads, the element is split into multiple elements 3012, each having only a single load on the output. In turn, each input "cone" (not shown) driving the duplicated element is copied as well, until all block outputs are reached. Similarly, large input gates are reduced to trees of non-inverting two-input gates, with a two-input gate of the original function at the top of the tree. In this way, substantially more logic is dedicated to the previously much smaller glue logic function. However, by removing glue logic from the areas between the larger blocks, the larger blocks can be more efficiently placed, resulting in a net efficiency increase.
[0246] Any glue logic element that cannot be effectively duplicated for distribution is then preferably merged into a larger block having the closest affinity to the placed element. Glue logic merger is executed in a manner based on a number of criteria, the most significant of which is whether the merger reduces the number of top-level pin-outs. Thus, when multiple copies are created, since most of the resulting logic is comprised of two-input gates, merging such gates into blocks wherein one pin is connected to the block reduces the pin count by two. When two or more blocks are equal candidates for merger, the block having the lowest pin density is preferably chosen. Finally, the lowest priority preferably goes to timing considerations.
[0247] Next, referring to FIG. 31, gates and small blocks 3110 that cannot be merged are clustered into clusters 3112. Gates that cannot be merged most likely have multiple loads on both their input and output nets. By recombining gates with inputs having similar function, gate count can be reduced.
[0248] The present invention further discloses a method to convert pre1
designed circuit blocks into circuits having standardized interfaces.
[0249] The tasks performed in the block design stage 106 in FIG. 1
include: (1) creating any missing abstracts for the selected circuit blocks, (2) embedding the circuit blocks into their respective standardized interfaces known as collars, and (3) creating a complete set of abstracts for the collared circuit blocks.
[0250] Referring to FIG. 32, a collaring process of embedding a circuit block into a collar is shown, in accordance with the present invention.
[0251] In the BBD methodology, selected circuit blocks are the primary input components at the chip-level. The collaring process places a collar around each of the circuit blocks to create a standard interface around the boundary of the circuit block. To successfully integrate collared blocks into the chip-level, a complete set of abstracts has to be created for the collared blocks. Before creating the complete set of abstracts for the collared blocks, the system of the present invention first forms any missing abstracts for the selected blocks, where abstracts are models or views of the block, or collared block designs required by chip-level assembly or planning tools. Exemplary abstracts include
[0252] (1) Static Timing Abstraction--TLF
[0253] (2) Layout Blockage File--LEF
[0254] (3) Models for Verification--Bolted-Bus-Block model
[0255] (4) Block layout constraints to the system
[0256] Referring to FIG. 33, creating a complete set of abstracts of a circuit block is illustrated, in accordance with the present invention, while FIG. 34 illustrates a combination of the features illustrated in FIGS. 32 and 33.
[0257] We will move next to a description of the collaring process, wherein it is assumed that a standard interface has been defined for each type of the blocks to be used in design.
[0258] At a first step, the process checks whether each of the blocks has a completed block abstraction. If any of the blocks does not have a complete block abstraction, the process forms a complete block abstraction for the block.
[0259] Next, the process identifies a block type for each of the blocks. Specifically, a block can be: a memory type, a processor type, a power type, or an analog/mixed signal type. However, a type of circuit blocks from different sources may have different interfaces that require different designs to connect other circuit blocks. For example, the processors designed by different vendors may have different interfaces and bus structure.
[0260] Next, the process associates the identified block with its respective interface standard.
[0261] Thereafter, the process creates a first collar portion containing the components connectable to the specific interface of the identified block.
[0262] At a next step, the process creates a second collar portion in compliance with the standard interface associated with the identified circuit block.
[0263] The process then creates a third collar portion containing the components for converting the specific interface into a format connectable to the standard interface and connecting the first collar portion with the second collar portion.
[0264] A block collar can be comprised of multiple layers. Currently, two collar layers (a block standard collar and a system-specific collar) have been defined for BBD and SOC, respectively. Referring to FIG. 35, a collar containing two layers is shown, one collar being standard for a particular block, and the other being specific to the particular system in which the block is to be deployed. The block standard collar contains those interface components that can be defined without the knowledge of the specific system or the specific context in which it is being integrated. For example, in the context of BBD, a particular design group may decide that a JTAG-standard test interface is required in a design. Thus, for all blocks to be used in any of the systems being designed, a JTAG test interface is a standard and, thus, belongs in the block standard collar. The system-specific collar (or adaptation collar) contains interface components which belongs to the block, but are system or context specific. For example, the standard set for data lines may not require a parity bit, but for a particular system being designed a parity bit is required on all data lines. The logic to generate the parity bit is associated with the block during chip planning and should reside in the system-specific collar.
[0265] Another distinction between the two collar layers in BBD is that the block standard collar can be put on prior to front end acceptance and chip planning (chip pl