Patent Application
20060225015
Aspects of embodiments described herein apply to the development process of electronic systems, especially Systems on a Chip.
In computer networks, internetworking, communications, integrated circuits, etc., where there is a need to communicate information, there are 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 incorporating floor planning information into a configuration process by generating a definition of a floor plan that groups interconnect components during a front-end view design process for the interconnect. Further, a user is permitted to combine components from separate IP block representations of interconnects during the front-end view design process, based upon physical location on a chip of the groups of the components making up the interconnects on the chip.
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:
a illustrates a flow process of the steps for an embodiment of merging two distinct IP blocks into a single block of IP.
b illustrates a detailed flow process of an embodiment of
In the following description, numerous specific details are set forth, such as examples of specific protocol commands, named components, connections, types of burst simulations, 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.
A System on a Chip (SOC) may comprise multiple Intellectual Property (IP) blocks. Each IP block is capable of functioning independent from other components or IP blocks on the SOC. An SOC may contain a single interconnect core that is responsible for connecting and allowing each IP block to communicate. It may also be possible for an SOC to have two or more discreet interconnect cores. In general, floor planning information may be incorporated into an electronic system configuration process by generating a definition of a floor plan of groups of interconnect components during a front-end view design process for the electronic system. Further, a user is permitted to combine components from two or more separate Intellectual Property (IP) block representations of interconnects during the front-end view design process, based upon a physical location on a chip of the groups of components making up the interconnects on a chip. Thus, chip area information may be discerned and utilized during the architectural design stages of System on a Chip design. The same design hierarchy description may be used during the front-end view design process and the back-end file design process. The initial netlist generated includes the floor plan of groups of interconnect components information.
Each group within IP blocks 101 and 102 also contain one or more individual components. These components can be one of multiple things. For example group ia1 contains four components. Component 110 is a bridge, component 111 is an initiator agent (IAH), component 112 is a request relay station (req RS), and component 112 is a response relay station (resp RS). In one embodiment, each group from “ia” in block 101 is an instance of ia. Therefore group ia0 contains the same components as group ia1. In another embodiment ia0 and ia1 might not contain the same components. In another example, group ia1 from block 102 contains component 120, which is a target agent I/O block (TAIO) and component 121, which is a target agent (TA). In one embodiment each group from “ia” in block 102 is an instance of ia. Therefore group ia0 contains the same components as group ia1. In another embodiment ia0 and ia1 might not contain the same components.
Thus, permitted an SOC design engineer to combine components from two or more separate Intellectual Property (IP) block representations of interconnects during the front-end view design process, based upon a physical location on a chip of the groups of components making up the interconnects on a chip provides several benefits. This allows the dynamic addition of flexible components into the design description by combining sub-components from different IP blocks and different levels in the design hierarchy. Later in the SOC design stages, this allows flexible traversals (i.e. simulation and testing) of the design hierarchy depending on the stage of the design flow: with or without dynamic components. The SOC IP generator may allow different views of the design hierarchy to co-exist so that the floor plan grouping of information can be incorporated into the front-end design process. This allows the initial netlist generated to include floor plan grouping information without the need for an additional netlist re-organization step.
Next there is root IP block 102, which sits on the same level as root IP block 101. One level below (Level 2) there are eight groups: mi0, rt0, ia0, ia1, ia2, ia3, ta0 and ta1 which all sit below IP block 102. One level below (Level 3) are groups 120 and 121, which sit below and inside of ia1. They also reside in ia0, but are not shown in
Another benefit of merging both IP blocks is to reduce the amount of physical chip space required for placement of the groups, their components and the interconnects connecting them. For example, the physical space required for system 300 of
In
a illustrates a flow process for an embodiment of dynamically designing a System on a Chip (SOC). Traditionally, there exist two major stages of SOC design: front-end processing and back-end programming. Front-end processing consists of the design and architecture stages, which includes design of the SOC schematic. The front-end processing may include connecting models, configuration of the design, simulating and tuning during the architectural exploration. The design is simulated and tested. Front-end processing traditionally includes simulation of the circuits within the SOC and verification that they work correctly. The integration of the electronic circuit design may include packing the cores, verifying the cores, simulation and debugging.
Back-end programming traditionally includes programming of the physical layout of the SOC such as placing and routing, or floor planning, of the circuit elements on the chip layout, as well as the routing of all interconnects between components. Thus, the floor plan may be generated imported and edited. After this, the design may be outputted into a Netlist of one or more hardware design languages (HDL) such as Verilog, VHDL or Spice. A Netlist describes the connectivity of an electronic design such as the components included in the design, the attributes of each component and the interconnectivity amongst the components. After the netlist is generated synthesizing may occur. Accordingly, back-end programming further comprises the physical verification of the layout to verify that it is physically manufacturable and the resulting SOC will not have any function-preventing physical defects. If there are defects, the placement of circuit elements and interconnect routing is revisited, which requires one or more revisions to the Netlist. Such a process can lead to increased design time, since the physical placement of the components happens much later in the design stages.
An improvement over the prior art allows for portions of the back-end programming to concurrently occur during the front-end processing. This avoids making revisions to the Netlist, which saves time. In essence, the floor planning information is incorporated into the front-end configuration processing. Thus, the SOC may be tuned with floor plan data imported for edit before a Netlist is created and ready for synthesis. Further, reductions in chip area and timing are possible during the design and configuration processes through the incorporation of floor plan information into the design description.
In one embodiment,
The first step in
There is no limit to the number of group templates that may be created, or the size and complexity of each group template. Further it is possible to create groups within another group. For example: a group type called “xb” may be created in which group type “ia”, “ta” and “rt” may exist inside of group “xb”. In one embodiment, there may only be a single group consisting of a single component. In another embodiment there could be hundreds of groups, with each group containing multiple components and many groups existing inside other groups.
In the next step, instances of groups are created 520 as well as defining how each component will connect to each other during a merge from two distinct IP block into one. During this step, instances of each group type are created along with the specific details of the parameters of each group type. For example, IP block 101 contained a group template named “ia” that was defined in step 510. In this step, two instances of group template “ia” are created. They are called ia0 and ia1. Each one contains the six components that were defined in step 510 in regards to group template “ia”. So group instance ia0 and ia1 will each have a bridge, an IAH, a req RS a resp RS, a TA and a TAIO.
Further, this step includes the defining of interconnects between each component and the parameters (e.g. bandwidth, number of pipes, etc) of the interconnects. For example, there may be an interconnect between the bridge from ia1 in IP block 101 and TA from ia1 in IP block 102.
The other important part of step 520 is defining how components from each group in IP block 101 and 102 will be merged. For example, IP block 101 contains a group ia1 which comprises a bridge, IAH, req RS and resp RS. IP block 102 also has a group ia1, which comprises components TA and TAIO. Defining how the components will be merged may state that components TA and TAIO from IP block 102 will be merged into ia1 from IP block 101. Hence, the resulting merged group ia1 would comprise components bridge, IAH, req RS, resp RS, TA and TAIO. This can be seen in
However, a key portion of step 520 is that a user is permitted to combine components from two or more separate Intellectual Property (IP) block representations of interconnects based upon a physical location on a chip of the groups of components making up the interconnects on the chip. Thus, chip area information may be discerned and utilized during the architectural design stages of System on a Chip design. The same design hierarchy description used during this front-end view design process can be used again during the back-end file design process.
In the next step, design configuration 530 occurs. User-specific details of each component are defined. The user is not required to know how the merged IP blocks will look. The user may only have to see the two independent blocks of IP and define the configuration details with this knowledge. Once the merge occurs, the user-specified parameters will be incorporated automatically without the user needing to be involved. The design hierarchy may be traversed through simulation and testing. However, the area and timing constraints supplied also incorporate floor plan information into the design hierarchy description.
In the next step, the component groups are connected together 540 based on their eventual physical layout after the merge occurs. At this point in the flow process of
b illustrates a detailed flow process of an embodiment of step 540 from
Once the flow process of
Another aspect of the Netlist generation of step 560 is that component groups are treated as dynamic and not static. This allows for components within a group to easily be moved to other groups if the design changes. In the prior art, components within a group are static. Hence, once they are defined, they cannot be moved to other groups.
Another advantage of the Netlist generation of step 560 is that multiple views or representations of the hierarchy can be maintained. For example, in
Another advantage over the prior art is that the resulting Netlist is synthesizable. In the prior art, Netlists only contained high-level constructs of the overall design. High-level constructs would then have to be converted to gate-level details when the design is submitted to manufacturing. Having synthesizable Netlists containing gate-level details increases efficiency in the manufacturing stage by eliminating the high-level to gate-level conversion step. Thus, the initial Netlist incorporates component and structural information that is synthesizable down to a gate level.
The example System on a Chip may have 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.
