Patent Application
20070083830
Aspects of embodiments described herein apply to the development process of electronic systems, especially Systems on a Chip (SOC).
In computer networks, internetworking, communications, integrated circuits, etc., where there is a need to communicate information, there may be interconnections established to facilitate the transfer of the information. Interconnects may provide the physical communication network between two agents such as agents of Intellectual Property (IP) blocks. When designing systems that comprise such IP blocks and interconnects, the physical layout of IP blocks and its corresponding interconnects typically occur after the design/architecture and simulation stages are complete. Such an approach can potentially require revisions to the original design and simulation stages if it is not physically possible to place the components in such a way as to properly represent the original design. For example, a System on a Chip design may require the placement of components in such a way that is not physically possible to connect the various IP blocks in the manner when the architectural design was generated for this System on a Chip. Thus, one design hierarchy description may be used during the front-end design process and then possibly manually re-organized into a different design hierarchy description for use in the back-end design process. Under the traditional approach, such a problem may not be noticed until after the design and simulation stages have completed. The design would then have to be revised as well as further simulation testing. This approach could drastically increase the overall timeline of a development project. Another approach may be needed, where the physical layout of components may be incorporated into the architectural design stage. Such an approach may catch potential design problems earlier on, such that revisions to the original design, additional simulation and regeneration of Netlists are avoided.
Methods and apparatuses are described for an Intellectual Property (IP) Generator for estimating timing, area and power constraints in an electronic design system. The IP Generator receives a user-supplied file having data describing a configuration of an intellectual property (IP) design, the data includes one or more configuration parameters. The IP Generator further enables a transformation of the user-supplied file into a register transfer level design description. Next, the IP Generator receives user-supplied technology parameters and data-flow information. The technology parameters describe a configuration of the IP design. Next, the IP Generator executes a timing module based on the configuration of the IP design as well as executes a timing model for each hierarchical level in the IP design. The timing model predicts timing paths of a final logic circuit. Further, a result of the timing model is provided to the user prior to enabling a transformation of a register transfer level design into the simulation of a gate-level circuit design. Lastly, after the timing model has been executed, is the enablement of the transformation of the register transfer level design into the simulation of the gate-level circuit design.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
In the following description, numerous specific details are set forth, such as examples of specific protocol commands, named components, connections, types of burst capabilities, etc., in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well known components or methods have not been described in detail but rather in a block diagram in order to avoid unnecessarily obscuring the present invention. Thus, the specific details set forth are merely exemplary. The specific details may be varied from and still be contemplated to be within the spirit and scope of the present invention.
In a highly configurable System on a Chip (SOC) interconnect, many configuration options enable a user to make trade-offs between Timing (latency and frequency), Area (logic gate/transistor and wire routing), and Power (dynamic and static) characteristics. It is therefore valuable to have a mechanism for enabling the user to estimate the impact of their configuration decisions on the Timing, Area and Power (TAP) characteristics of the finished SOC interconnect. Some traditional methods for TAP estimation require detailed physical implementation work, including synthesis, place and route, extraction and back-annotation, and application scenario-dependent power analysis. Such traditional methods prevent accurate TAP modeling during the architectural design stage since TAP estimates are not available until substantial physical implementation of the design has been established. This requires much time and cost, especially when numerous physical renditions may be required to accomplish acceptable TAP values for a given SOC interconnect.
A traditional design flow of an SOC interconnect design may begin with taking a register transfer level (RTL) description of a logic design and feeding it into a logic synthesis tool. Generally, an RTL description describes what intermediate information (i.e. information stored between clock cycles in a digital circuit) is stored in registers, where it is stored within the design, and how that information moves through the design as it operates. Generally, a logic synthesis tool transforms an SOC interconnect description from one level of abstraction to a lower level, usually towards some physical implementation. In one embodiment, logic synthesis translates an RTL design into a gate-level design. Traditionally, once an SOC interconnect design has been synthesized to a gate-level design, analysis may be done for TAP characteristics. It would be beneficial to have a method where such TAP estimates may be accomplished before an SOC interconnect is reduced to a gate-level design through logic synthesis. Such a method may drastically reduce the time and cost spent on such a design.
In the first step, the user supplies a file that describes the configuration of an IP design(s) using a set of pre-defined parameters 210. Thus, the user creates an RTL design file with configuration parameters of the IP.
In the second step, the analysis tool translates the file into a register-level design description 220. Hence, the tool generates IP sub components of an electronic system design as an executable behavioral model. In one embodiment, the tool receives the user design and generates a configured IP design based on parameters in the received configuration file. In another embodiment, the register-level description of a digital electronic circuit is an intermediate level of an electronic design system between the functional description (e.g., register-level design) of the system and an actual physical layout of the electronic design system (e.g., gate-level design). Registers store intermediate information between clock cycles in a digital circuit, so an RTL description describes what intermediate information is stored, where it is stored within the design, and how that information moves through the design as it operates.
Next, user-specified technology parameters and data-flow information for timing, area and power consumption estimates are received 230. The user provides information that describes the important parameters of the silicon process technology. Thus, the user provides parameters describing the desired configuration of the IP design based on TAP values.
Next, for each sub-unit in the IP design, separate TAP models are executed 240. The analysis tool executes separate TAP models and reports the results to the user. In one embodiment, the separate timing, area and power modules are sub-modules of the larger analysis tool. Each model takes in user supplied technology parameters from step 230 and the configuration parameters derived from the RTL design file 210. Thus, for each design sub-unit in the IP, a parameterized model is executed which produces data on the timing, area and power of the unit. The TAP models may be built into the software that generates the IP sub-components as executable models. These models are used very early in the design flow to make trade-offs in the design parameters. These models are highly configurable. Execution of the models produces predictions of the timing, area and power consumption of the final logic circuit.
Next, the results of the executable TAP models are reported to the user 250. If the results are acceptable to the user, the design is finalized and is ready to be passed into the next design flow stage (e.g., logic synthesis).
If the performance results are not acceptable, or the user wants to continue making trade-offs, the design is modified 260 (by modifying the RTL design file) and steps 220-250 are repeated. Thus, the RTL design file may be continuously modified and steps 220-250 reprocessed until an acceptable TAP model is constructed.
Once the TAP models are accepted by the user, the logic synthesis tool translates the RTL into a gate-level circuit 270. Once a gate-level circuit exists, actual TAP measurements may be reported. Thus, the actual TAP characteristics which result after step 270 should be substantially similar to the TAP estimates compiled in step 250.
The advantages of the design flow illustrated in
SOCCOMP 310 passes empty data structures, user-defined and internally derived parameters 321 to Timing Module 1320. Timing Module 1320 is a first instance of a timing module based on the first sub-unit within the RTL design. For each sub-unit within the RTL design a new instance of a timing module will be created. So there will be N timing modules 325 for N sub-units in the RTL design. Based on the received parameters and data structures, Timing Module 1320 processes the information and populates the data structures. Timing Module 1320 passes the populated data structures 322 back to SOCCOMP 310. SOCCOMP uses the received data structures to generate the actual timing estimates. Generation of the timing estimates are accomplished by determining the time frame to travel through each input and output of each IP sub component and aggregating the times for each IP sub component. In another embodiment, the timing module estimates a time frame to travel through each sub component in the electronic design system prior to processing the post logic synthesis estimates of the electronics system design. In another embodiment timing estimates are generated by determining the longest time frame to travel through each IP sub component. In another embodiment, the estimation of travel times are determined independent of using an actual circuit in a cell library. For each N timing module instance, empty data structures and parameters are passed 327 to Timing Module N 325, In turn, Timing Module N 325 returns. the populated data structures 326 to SOCCOMP 310.
Next, SOCCOMP 310 passes data structures, user-defined and internally derived parameters 331 to Area Module 1330. Area Module 1330 is a first instance of an area module based on the first sub-unit within the RTL design. For each sub-unit within the RTL design a new instance of an area module will be created. So there will be N area modules 335 for N sub-units in the RTL design. Based on the received parameters and data structures, Area Module 1330 processes the information and populates the data structures. Area Module 1330 passes the populated data structures 332 back to SOCCOMP 310. SOCCOMP uses the received data structures to generate the actual area estimates by aggregating the area estimates of all the IP sub components. In another embodiment, SOCCOMP 310 aggregates area estimates of all the IP sub components in the electronic system design prior to calculating the post logic synthesis estimate of the electronic system design. In another embodiment, the aggregation of the area estimates of all the IP sub components are done independent of using a design of an actual circuit in a cell library. For each remaining N area module instance, empty data structures and parameters are passed 336 to Timing Module N 335, with populated data structures returned 337 to SOCCOMP 310.
Next, SOCCOMP 310 passes data structures, user-defined and internally derived parameters 341 to Power Module 1340. Power Module 1340 is a first instance of a power module based on the first sub-unit within the RTL design. For each sub-unit within the RTL design a new instance of a power module will be created. So there will be N power modules 345 for N sub-units in the RTL design. Based on the received parameters and data structures, Power Module 1340 processes the information and populates the data structures. Power Module 1340 passes the populated data structures 342 back to SOCCOMP 310. SOCCOMP uses the received data structures to generate the actual power estimates by aggregating the power consumption estimates for all the IP sub components. In another embodiment SOCCOMP 310 aggregates the power consumption estimates of all the IP sub components in the electronics system design prior to calculating the post logic synthesis estimates of the electronic design. For each N power module instance, empty data structures and parameters are passed 346 to Power Module N 345, with populated data structures returned 347 to SOCCOMP 310.
In another embodiment, SOCCOMP 310 also contains a module to perform the post logic synthesis estimates of the electronic system design. These estimates enable a transformation of a circuit description from an abstraction layer to a physical implementation layer.
In another embodiment, a timing model is executed 365 for each hierarchical level of the IP design. Hence, if the IP design contains 4 levels of hierarchy, the timing model is executed 4 times. For each level of hierarchy, the timing model predicts timing paths of the final logic circuit to be later implemented in a gate level design. The results of the timing model are provided to the user 370 prior to enabling the transformation of the register transfer level design into a simulation of gate-level circuit design. After the execution of the timing model, the transformation of the register transfer level design into a simulation of the gate-level circuit design is enabled 375. As stated above, the transformation of the RTL design into a simulation of a gate-level circuit design may be accomplished by an external module.
It is possible for a design to comprise multiple levels of hierarchy. In such a case, the models may be executed hierarchically. A multi-level hierarchy is made up of multiple modules. Each module can exist within other modules. As an example, module A may contain an instance of module B. Area and power models may be calculated for all parts of module A that exist within that level of hierarchy. Module B may be at one level lower in the hierarchy than A. The area and power models may be calculated for each instance of module B. In another embodiment, Module B may also contain additional modules. However, in this example each module has its area and power models sequentially calculated until all levels of the hierarchy are done. This means that all modules in level A may be calculated before moving on to level B. Once all the models from each level of hierarchy have been calculated, the totals are summarized. These totals may be reported as a single total, or may be broken into sub-totals for each level in the hierarchy.
The example System on a Chip may have multiple IP cores such as a CPU core, a MPEG encoder/decoder core, a memory core, a Digital Signal Processor core, a Universal Service Bus core, a blue tooth core, a first interconnect IP core facilitating communications between a first set of IP cores, and a second interconnect IP core facilitating communications between a second set of IP cores as well as communications between the two IP interconnect cores.
In one embodiment, the software used to facilitate aspects of SOC design process can be embodied onto a machine-readable medium. A machine-readable medium includes any mechanism that provides (e.g., stores and/or transmits) information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read merely memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; DVD's, electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, EPROMs, EEPROMs, FLASH, magnetic or optical cards, or any type of media suitable for storing electronic instructions. The information representing the apparatuses and/or methods stored on the machine-readable medium may be used in the process of creating the apparatuses and/or methods described herein. For example, the information representing the apparatuses and/or methods may be contained in an Instance, soft instructions in an IP generator, or similar machine-readable medium storing this information.
The IP generator may be used for making highly configurable, scalable System On a Chip inter-block communication systems that integrally manages data, control, debug and test flows, as well as other applications. In an embodiment, an example intellectual property generator may comprise the following: a graphic user interface; a common set of processing elements; and a library of files containing design elements such as circuits, control logic, and cell arrays that define the intellectual property generator. In an embodiment, a designer chooses the specifics of the interconnect configuration to produce a set of files defining the requested interconnect instance. An interconnect instance may include front-end views and back-end files. The front-end views support documentation, simulation, debugging, and testing. The back-end files, such as a layout, physical LEF, etc are for layout and fabrication.
