Design Article
The best of both worlds
Jafar Safdar, Synopsys, Inc.
5/31/2011 3:40 AM EDT
Costs of custom datapath design
Flow complexity
It is quite common to see datapath designers use their unique flow to implement datapath structures. This flow, typically a combination of a proprietary language and GUI, helps meet PPA targets but is hard to share across teams and to provide as IP to external customers. This is because the combination of a standalone custom datapath stage and a traditional place-and-route (P&R) tool yields a complex and inefficient flow. Designers first create a datapath structure and then need to ensure that it is preserved through the full place and route flow in the context of the rest of the design implementation. As shown in Figure 3, this flow requires many optimization loops to meet the targeted PPA. Changes in cell selection made in one part of the design affect other parts of the design and, in turn, might alter the structure of the physical datapath. Picking cells with the correct drive specifications and size (height/width) to fix timing or logic design rule constraints without disturbing the datapath structure requires extensive design and tool knowledge. The bottom line is that in the custom flow, the cost of design changes is very high.
Figure 3: Typical datapath flow requires multiple iterations to meet PPA targets
Design knowledge requirements
Custom datapath designers need to have detailed knowledge of datapath blocks, which requires access to the design at an early stage of the flow. Not every function or block is suitable for structured placement. Designers need to know the dataflow, input-output connections and loads when making major cell placement decisions. Typically datapath designs have large buses (64/128/256 bit); therefore knowing the fan-in logic of input and output loads and the size of the buses (64/128/256 bit) is important from a routing resources standpoint.
Project schedules
Implementing high-performance custom datapath design is time consuming, primarily due to the handcrafted placement stage and the iterations between custom datapath and traditional place and route. Depending on the design complexity, the number and size of datapath blocks, and the technology node, custom datapath design teams’ development schedules are long and harder to predict.
What do designers want?
Designers developing cores for processors, DSP or other applications design them knowing their IP will be used in multiple products at different process nodes. These designers want IP that is portable, easy to use, and predictable and meets the PPA targets of the end users. Mainstream designers, especially those developing mobile and multimedia applications, require powerful processing engines and the capacity to handle increasing graphics content. To meet these requirements, they use on-chip processor cores, DSP cores and small memories. Mainstream designers want a solution that helps them create datapath structures for the IP blocks as well as handle standard cells in the design seamlessly. These designers also want a solution that can help them create register banks, clock structures, multiplexers, crossbar switches, etc. that are more efficient and help meet PPA objectives. In summary, designers want an automated solution based on traditional place and route tools that delivers custom PPA but with a shorter and predictable design schedule.
Automated datapath solution
Physical datapath technology in IC Compiler provides logic designers with a predictable, production proven flow in a single unified environment. With the support of Design Compiler during the front-end synthesis phase, RTL designers can create datapath structures and then pass them to IC Compiler for place and route. As needed, designers in IC Compiler can also create datapath structures to specify the relative column and row positions of instances by using simple built-in Tcl commands. These specific commands are called relative placement (RP) constraints. During placement, legalization and optimization, datapath structures are physically preserved and are placed as a single entity in the context of the rest of the design.
Relative placement is usually applied to datapath blocks and registers but can also be applied to any cells in the design, which require some regularity. Examples of commonly used datapath structures are adders, register banks, coders, decoders, multiplexers, etc. Figure 4 displays the design matrix as an RP group after placement.
Flow complexity
It is quite common to see datapath designers use their unique flow to implement datapath structures. This flow, typically a combination of a proprietary language and GUI, helps meet PPA targets but is hard to share across teams and to provide as IP to external customers. This is because the combination of a standalone custom datapath stage and a traditional place-and-route (P&R) tool yields a complex and inefficient flow. Designers first create a datapath structure and then need to ensure that it is preserved through the full place and route flow in the context of the rest of the design implementation. As shown in Figure 3, this flow requires many optimization loops to meet the targeted PPA. Changes in cell selection made in one part of the design affect other parts of the design and, in turn, might alter the structure of the physical datapath. Picking cells with the correct drive specifications and size (height/width) to fix timing or logic design rule constraints without disturbing the datapath structure requires extensive design and tool knowledge. The bottom line is that in the custom flow, the cost of design changes is very high.
Figure 3: Typical datapath flow requires multiple iterations to meet PPA targets
Design knowledge requirements
Custom datapath designers need to have detailed knowledge of datapath blocks, which requires access to the design at an early stage of the flow. Not every function or block is suitable for structured placement. Designers need to know the dataflow, input-output connections and loads when making major cell placement decisions. Typically datapath designs have large buses (64/128/256 bit); therefore knowing the fan-in logic of input and output loads and the size of the buses (64/128/256 bit) is important from a routing resources standpoint.
Project schedules
Implementing high-performance custom datapath design is time consuming, primarily due to the handcrafted placement stage and the iterations between custom datapath and traditional place and route. Depending on the design complexity, the number and size of datapath blocks, and the technology node, custom datapath design teams’ development schedules are long and harder to predict.
What do designers want?
Designers developing cores for processors, DSP or other applications design them knowing their IP will be used in multiple products at different process nodes. These designers want IP that is portable, easy to use, and predictable and meets the PPA targets of the end users. Mainstream designers, especially those developing mobile and multimedia applications, require powerful processing engines and the capacity to handle increasing graphics content. To meet these requirements, they use on-chip processor cores, DSP cores and small memories. Mainstream designers want a solution that helps them create datapath structures for the IP blocks as well as handle standard cells in the design seamlessly. These designers also want a solution that can help them create register banks, clock structures, multiplexers, crossbar switches, etc. that are more efficient and help meet PPA objectives. In summary, designers want an automated solution based on traditional place and route tools that delivers custom PPA but with a shorter and predictable design schedule.
Automated datapath solution
Physical datapath technology in IC Compiler provides logic designers with a predictable, production proven flow in a single unified environment. With the support of Design Compiler during the front-end synthesis phase, RTL designers can create datapath structures and then pass them to IC Compiler for place and route. As needed, designers in IC Compiler can also create datapath structures to specify the relative column and row positions of instances by using simple built-in Tcl commands. These specific commands are called relative placement (RP) constraints. During placement, legalization and optimization, datapath structures are physically preserved and are placed as a single entity in the context of the rest of the design.
Relative placement is usually applied to datapath blocks and registers but can also be applied to any cells in the design, which require some regularity. Examples of commonly used datapath structures are adders, register banks, coders, decoders, multiplexers, etc. Figure 4 displays the design matrix as an RP group after placement.
Figure 4: Structured placement of physical datapath using RP constraints
|
|
|
|
|
Navigate to related information
Daniel Payne
6/2/2011 10:32 AM EDT
Good article, datapath and compiled layout makes a lot of sense. In fact an entire company was formed around this very concept called Silicon Compilers in the 1980s, then acquired by Mentor in the early 1990s. There were two compiler tools: Genesil and GDT. Earlier while at Intel I wrote my own layout compilers to produce parts of a Graphics Chip automatically.
Sign in to Reply