This document discusses using data flow analysis (DFA) features in ICC/DC Explorer to accelerate floorplan creation for complex chip designs. It describes how DFA was used to analyze data flow at the top level and within partitions to inform floorplan refinements and improve quality of results. DFA provided connectivity analysis, net filtering, and flyline analysis that helped create an initial floorplan capturing the essential data flow. This floorplan was then validated against the vendor's floorplan to ensure correct macro placement and connectivity.
This document discusses using data flow analysis (DFA) features in ICC/DC Explorer to accelerate floorplan creation for complex chip designs. It describes how DFA was used to analyze data flow at the top level and within partitions to inform floorplan refinements and improve quality of results. DFA provided connectivity analysis, net filtering, and flyline analysis that helped create an initial floorplan capturing the essential data flow. This floorplan was then validated against the vendor's floorplan to ensure correct macro placement and connectivity.
This document discusses using data flow analysis (DFA) features in ICC/DC Explorer to accelerate floorplan creation for complex chip designs. It describes how DFA was used to analyze data flow at the top level and within partitions to inform floorplan refinements and improve quality of results. DFA provided connectivity analysis, net filtering, and flyline analysis that helped create an initial floorplan capturing the essential data flow. This floorplan was then validated against the vendor's floorplan to ensure correct macro placement and connectivity.
Accelerating Floorplan Creation using DFA in ICC/DE
Krishna Kumar Gundavarapu, Lai Ping Charles Tang
Cisco Systems Inc., San Jose, USA
www.cisco.com
ABSTRACT
As Cisco designs are being implemented in process nodes 28nm or below, design complexity and size have increased manifold. More partitions and connectivity in the top level has increased the complexity of top-level floorplanning. Also individual partition size has increased making creation of optimal floorplan within partitions a very challenging and time-consuming task. Physical Design- ers are provided limited amount of information about the data flow. When RTL designer resource is limited or unavailable, floorplanning tasks involve iterative cycles of placement, timing/congestion analysis and refinements to find a result that meets functional data flow needs. We have addressed this problem by using the Data Flow Analysis (DFA) feature in ICC/DC Explorer. In this paper, well focus on techniques we used to analyze data flow at the top-level and within partitions and how we apply that knowledge to refine floorplans and drive synthesis to produce the best QoR in physical implementation. Also, well discuss how we use DC Explorer and ICC-DPs Data Flow Analysis to produce a high quality floorplan, the time it took for us to perform these tasks, and share implementation results.
Figure 1 Chip Dataflow (Paper Floorplan) ........................................................................................ 5 Figure 2 Traditional Top Level Floorplan Flow ................................................................................ 6 Figure 3 - Logical Connectivity ............................................................................................................ 7 Figure 3a DFA Showing The Connectivity Between 5 Chiplets ....................................................... 8 Figure 3b DFA With Connectivity Summary .................................................................................... 9 Figure 3c DFA with net details ........................................................................................................ 10 Figure 3d Getting Module Summary report from DFA ................................................................... 10 Figure 3e Example Module Summary report from DFA .................................................................. 11 Figure 3f Net Filter For A Selection ................................................................................................ 11 Figure 3g Global Net Filter .............................................................................................................. 12 Figure 3h Flow for Pipeline Planning .............................................................................................. 13 Figure 3i Example Results For Pipeline Planning ........................................................................... 13 Figure 3j Connectivity Analysis Internal To A Chiplet ................................................................... 14 Figure 3k Initial Floorplan With Help Of DFA ............................................................................... 15 Figure 4 a: Traditional Floorplanning Flow, b: DFA Floorplanning Flow...................................... 17 Figure 4c: ICC-DFA GUI ................................................................................................................... 18 Figure 4d: DFA With Connectivity. ................................................................................................... 18 Figure 4f: Connection Details ............................................................................................................. 19 Figure 4g: Cross-Selection of macros between DFA and floorplan ................................................... 20 Figure 4h: Advance Flyline Analysis (Data Flow Flylines) ............................................................... 21 Figure 4i: Macro-to-Macro Connectivity............................................................................................ 21 Figure 4j: Input/output Ports Connectivity ......................................................................................... 22 Figure 4k: Input to Macro, Macro to Macro and Macro to Output Connectivity of one macro ......... 22 Figure 4L: Floorplan Snapshot of Design I with Macro and IO connectivity highlighted ................. 23 Figure4M: Floorplan Snapshot of Design II with Macro and IO Connectivity highlighted .............. 23 Figure 5a: Design I with cross-selection of macros ............................................................................ 24 Figure 5b: Design I with macro placement corrected ......................................................................... 25 Figure 5c: Design I with cross-selection of macros ............................................................................ 25 Figure 5e: Design II with macro connectivity highlighted ................................................................. 26 Figure 5f: Design II with macro placement corrected ........................................................................ 27
SNUG 2014 4 DE-ICC DFA
1 Introduction
As we enter the advance process nodes 28nm and below, design complexity and size has increased significantly. More functionality is squeezed into one SoC; many components that were previously implemented as separate chips are now integrated into one single chip. This brings more partitions and more top-level connectivity between partitions, making top-level floorplan more confusing and complex. Also the design data path complexity inside each partition has gone up significantly. As a result, both top level and partition level floor planning become more time consuming and challeng- ing than ever. When RTL designer resource to provide details about dataflow is limited, this task becomes hard.
For physical implementation of our designs, we work with ASIC vendors. Initially, we provide a netlist, packaging requirements, guidance for top-level floorplanning, and guidance for partition lev- el floorplanning to the vendor. In the past, the floorplanning guidance is essentially data flow dia- grams from the RTL designers. Given the floorplanning guidance, the vendor performs some place & route iterations then gives us back floorplan data. As our design complexity increased, the number of floorplan iterations based on the vendors place &route experiments also increased. Each time the vendor provides a floorplan, we must take time to check it and see if it meets our data flow needs. This iterative process was taking longer and longer time.
In addition to working out the top-level floorplan, we collaborate with the vendor to produce floor- plans for each partition. The data path complexity in large macro-intensive partitions that need to run at frequencies greater than 750MHz in 28nm and below makes Physical Synthesis an absolute neces- sity for better correlation to Sign-Off. Manual checking of data flow by comparing macro-placement with data flow diagrams takes a lot of time. It becomes practically impossible with the number of partitions is high.
For our latest designs, we are using the Data Flow Analysis (DFA) capabilities of IC-Compiler along with DC-Explorer (DE). We use these to create guidance for top-level and partition level floorplan- ning that we give to our vendor. We also use DFA to help us check the data flow of floorplan data produced by our vendor.
In this paper, well discuss how we use Data Flow Analysis (DFA) within DC Explorer using the IC Compiler Design Planning Link. The paper includes the following sections:
Design Overview: presents relevant statistics of our design DFA for Top-Level Floorplan: presents design challenges we face that affect floorplanning guidance for layout of top-level partitions, various DFA features we use to create top-level floorplanning guidance, results of this work, and a summary of benefits. DFA for Partition-Level Floorplan: presents challenges we face that affect floorplanning of hard macro content within partitions, various DFA features we use to assess macro place- ment and create guidance, results of this work, and a summary of benefits. Enhancement Ideas: presents some of our ideas for more DFA capabilities Conclusions: wraps up what we see as key benefits of using DFA in our design flow
SNUG 2014 5 DE-ICC DFA
2 Design Overview
Complexity of the design includes 160M Gates (~50M instances) and 900MBits (3600 physical in- stances) of memory targeted to 28nm/16nm technology node. The design features the core running at 750MHz speed and it includes many buses of different sizes, shown with different color arrows in the following figure. Some of these buses are as wide as 3000 bits. It has 82 unique partitions, de- fined within 5 logical hierarchies (shown as chiplets in the following figure). Many partitions have 100+ macros.
Figure 1 Chip Dataflow (Paper Floorplan)
3 DFA for Top Level Floorplan
As part of hybrid-ASIC methodology followed in our group, we aim to deliver an initial top-level floorplan to the vendor along with the netlist, as floorplan guidance at very early in the design im- plementation cycle. Similar task is performed for all partitions and the feedback from every partition is put together to refine the top-level floorplan.
SNUG 2014 6 DE-ICC DFA
3.1 Challenges The main challenge was to understand the connectivity between 82 partitions and come up with an optimal floorplan. Networking designs typically have, 1) Latency-sensitive data and control bus and 2) Latency-insensitive diagnostic and initialization bus. So while floorplanning we need to consider the priority of busses accordingly.
In traditional floorplan methods, as described in the figure below, once the netlist is loaded into ICC, and partitions are specified and sized, flyline connectivity and paper dataflow from the RTL archi- tects is used as guidance for partition placement. Due to wide buses, coming up with an optimal floorplan typically requires multiple iterations of top-level place & route, which is resource-intensive and time consuming.
Figure 2 Traditional Top Level Floorplan Flow
SNUG 2014 7 DE-ICC DFA
3.2 DFA Features
Data Flow Analysis feature in ICC-DP eased the process by letting us see detailed dataflow between partitions. This feature is embedded into the same layout window of ICC GUI, making it easy to adjust the placement of partitions and size the channels while seeing DFA data on the side. Integrat- ed GUI also provides cross-probe between the DFA and Floorplan.
DFA is an interactive interface where you can selectively highlight the connectivity making it easier to plan the initial floorplan. You can also color different partitions with different colors, making it visually better for floorplanning. In addition, DFA has net filter capability that allows us to remove visibility of the low-priority buses between blocks and increases the visibility of high-priority func- tional dataflow.
As shown in the orange boxes of the following flow diagram, DFA provides guidance to achieve good top-level floorplan, thus minimizing the number of top-level place & route iterations.
Figure 3 - Logical Connectivity
SNUG 2014 8 DE-ICC DFA
Once the netlist is loaded into ICC, DFA can be opened by going into Layout Window -> Floorplan -> Analyze Logic Connectivity. First it displays the TOP to the left of the Floorplan and the I/O ports. User can select the hierarchy levels to be opened for the logical connectivity analysis.
Figure 3a DFA Showing The Connectivity Between 5 Chiplets
As shown in the Figure 3a, going one level down from TOP, DFA opens up 5 boxes that represent the chiplet hierarchy. Inside each box, name and module info (i.e., utilization, number of hard mac- ros) is displayed. Logical connectivity between the hierarchical modules is displayed as flylines be- tween these boxes. This helps as the first-level guidance for chip floorplan by providing chiplet to chiplet connectivity. Child modules can be expanded until the hierarchy that is planned for a parti- tion is reached. Then DFA enables analysis of dataflow connectivity between partitions.
By placing the cursor on any of the flylines, summary of connectivity (A->B and B-A) is displayed as shown in Figure 3b. DFA Control Center in the left side of layout window provides flexibility to the display only required flylines: Show all module connections or Show selected to selected.
SNUG 2014 9 DE-ICC DFA
Figure 3b DFA With Connectivity Summary
A click on the flyline lists complete net connection between the modules as shown in Figure 3c. These details helped us in understanding the major buses going between modules and prioritize the routes.
SNUG 2014 10 DE-ICC DFA
Figure 3c DFA with net details
Logical Module and connectivity information (i.e., Number of macros/Std. cells/IO pins and Net Connection details) can be saved into a text file using the DFA menu (File -> Write module re- port), which is very useful to exchange the information with RTL designers. This can be written out either at chip-level (chiplet-to-chiplet connectivity information) or at partition-level (partition-to- partition connectivity information). Following Figures 3d and 3e show the module summary written out by selecting all the partition under one of the chiplets. The report contains useful information for each partition, like Number of macros, Macro area, Number of Std Cells, Number of ports and its connectivity to other partitions.
Figure 3d Getting Module Summary report from DFA
SNUG 2014 11 DE-ICC DFA
Figure 3e Example Module Summary report from DFA 3.2.1 Net Filtering During chip-level floorplan stage, high priority needs to be given to functional buses that are latency sensitive and they should be guiding the partition placement. Diagnostic and static programming bits need to be given lowest priority. This is where net filtering capability in DFA is useful.
Figure 3f Net Filter For A Selection
SNUG 2014 12 DE-ICC DFA
Figure 3g Global Net Filter
3.2.2 Register Highlight Utility
After the initial floorplan is provided to the vendor, we proceed to work on the details of top-level implementation. At the clock frequencies above 750MHz and chip floorplan size of 25mm on a side, pipeline flops between partitions become essential to close timing. Based on initial timing analysis, design team incorporates pipeline flop stages between partitions to meet setup time. During top-level implementation, identifying the pipeline flops between blocks and creating place- ment bounds for these flops used to require extensive Tcl scripts and procedures. Reg Highlight feature (available in ICC 2013.12) within DFA Data flow Fly lines provides both interactive and text file capabilities to analyze and plan the implementation.
SNUG 2014 13 DE-ICC DFA
Figure 3h Flow for Pipeline Planning
Figure 3i Example Results For Pipeline Planning
SNUG 2014 14 DE-ICC DFA
Figure 3i depicts the typical flow used to identify the pipeline flop stages between two blocks and analyze their placement. Once the flop stages are identified, their placement can be controlled using bounds to achieve optimal timing result. 3.3 Result
As explained in the Section 2, the design for which we used DFA had 5 chiplets. Floorplan devel- opment happened in two steps: 1) Analyze connectivity at intra-chiplet level and 2) Analyze connec- tivity at internal of each chiplet.
Following pictures show examples of internal connectivity of one of the chiplets. With the help of net filtering, floorplan could be guided by functional data connectivity and rearrange the partitions accordingly. Same exercise was repeated for each of the five chiplets, and we were able to come up with a feasible initial top-level floorplan within few days.
Figure 3j Connectivity Analysis Internal To A Chiplet
SNUG 2014 15 DE-ICC DFA
Figure 3k Initial Floorplan With Help Of DFA
The green blocks shown in Figure 3k are the high-speed chip I/O interfaces, whose placement is guided by the system board requirements. Internal partition placement was delivered to the vendor as initial floorplan guidance along with the netlist. This accelerated the implementation cycle and min- imized iterations. 3.4 Benefits and Usage
Data Flow visual and cross-probing feature along with net filtering capability helped in top-level floorplan for one of our designs. DFA features significantly reduced the floorplan development cycle for the design.
DFA combined with Early Architecture Exploration using ICC (SNUG-2010) is being used in one of our early engagements of 16nm designs to evaluate the architectural and technology trade-offs.
SNUG 2014 16 DE-ICC DFA
4 DFA for Partition Floorplan
Once the top-level floorplanning guidance is handed off to the vendor, it takes some time before they provide their first floorplan to us. When it arrives, we take time to validate the data flow of both the top-level floorplan and the data flow within each partition. To prepare for this effort, we start early planning of floorplans within partitions. Generally, our RTL designers let us know which partitions are likely to be critical many macros, operating at high speeds, etc., so we start performing floor- planning within these partitions. This will enable early start for the Physical Synthesis activity as well for known critical blocks. Our objective is to understand the relative macro placement within a partition likely to provide best QoR considering data flow. Then, when we receive the first floorplan from the vendor, we can quickly assess the quality of macro placements theyve created within the partitions. 4.1 Challenges 4.1.1 Traditional Flow versus DFA Flow
In traditional floor planning method, since physical designers have limited knowledge about the RTL design, early stage floorplanning depends heavily on RTL architects paper data flow diagram. We look at the data flow diagram and plan the macro placement. Sometimes, data flow diagrams are not available or RTL architects are located in a different geography such that direct communication with the RTL architects to understand the dataflow becomes difficult. Even with the dataflow diagram provided, it only provides physical designer a brief idea of modules connectivity. We will have to go through multiple iterations of floor plan experiment to fully understand the connectivity between modules and come up with an optimal floor plan. Considering the run time required for place and route experiments, this process takes days or even up to weeks.
Now using the DFA method, the input of RTL architects data flow diagram becomes optional. Floorplanning now depend less on RTL architects input. DFA provides the data flow information and extract connectivity information based on the RTL. DFA allows physical designers to trace mac- ro and I/O connectivity through registers and standard cell gate. With DFA data flow and connectivi- ty information, physical designers now have a much better understanding and estimation of module placement while floorplanning. This gives physical designers a better initial floorplan to start and avoids the unnecessary initial stage floorplan, place and route experiments.
SNUG 2014 17 DE-ICC DFA
Figure 4 a: Traditional Floorplanning Flow, b: DFA Floorplanning Flow 4.2 DFA Features
Floorplanning with DFA includes mainly two steps: 1. Understanding the dataflow (Logic Connectivity Analysis) 2. Floorplan Refinement (Advance Flyline analysis).
These features are embedded into the same layout window of ICC GUI.
4.2.1 Logic Connectivity Analysis
When the RTL is released, data flow diagram may not be there or is not up to date. DFAs logic connectivity analysis feature eases the problem by providing a logic data flow diagram between macros. The goal of the initial floorplan is to place macros of the same hierarchy together and place macros that are connected close together. Through DFA, we can look at the data flow of logic mod- ules and examine their relative sizes, macro counts, connectivity with each other and its respective weight. DFA highlights different plan groups with different colors and allows users to cross-select macros between the dataflow view and the floorplan.
Usage: Looking at the DFA module in ICC GUI, we place macros that are of the same hierarchy together. If two modules connect closely, then place macros of the two modules close to each other.
a b
SNUG 2014 18 DE-ICC DFA
Figure 4c: ICC-DFA GUI Different logical hierarchies are colored with different colors. Colors are mirrored between DFA window and Floorplan Window. All the macros corresponding to a logical hierarchy are colored the same. Legend is also maintained in the Hierarchy Browser.
Figure 4d: DFA With Connectivity.
SNUG 2014 19 DE-ICC DFA
Red lines show macros to macros connectivity and Yellow lines show I/Os to macro connectivity. The number of connections determines thickness of the lines, thus the weight.
The box for each logical module has number of macros (HM) and placement utilization (U).
Clicking the number on the line shows the connection details between modules.
Figure 4f: Connection Details
SNUG 2014 20 DE-ICC DFA
Figure 4g: Cross-Selection of macros between DFA and floorplan
4.2.2 Advance Flyline Analysis
Once the initial floorplan is created based on the dataflow in DFA, next step will be fine-tuning of macro locations. Now up to this point, the connectivity that is displayed in DFA is based on direct logical module connectivity. Macros that are connected to each other through some number stages of flops or combo gates are not considered. In the traditional flow, we will have to go through multiple iterations of floorplan experiments and examine the module placement map to come up with an op- timal floorplan. DFAs Advance Flyline Analysis feature allows physical designers to trace macro connectivity through flops and combo gates. Now looking at the connectivity in a much detail and concise view, we can get a better estimation of the module placement and save the multiple itera- tions of floorplan experiments.
Analyzing the fly lines between Macros and IOs can help in refining the floorplan. The rule of thumbs is to place macros with higher connectivity closer to each other. Macros with high number of connections to the IO ports will be placed closer to the IO ports.
DFA allows Physical Designers to trace connectivity through registers and combo gates. Users can trace up to 5 registers level and 100 combo gates.
Figure 4k: Input to Macro, Macro to Macro and Macro to Output Connectivity of one macro
SNUG 2014 23 DE-ICC DFA
4.3 Results 4.3.1 Creating initial floorplan
For the two designs below, there were no previous initial floorplan for reference. Floorplanning is started with only the block dimensions and IO locations defined.
Design I has 35 macros and Design II has 138 macros. Using DFA based floorplanning flow, after the first iteration, we observed encouraging results. Timing QoR of both blocks can be closed with reasonable amount of VT swap.
DESIGN I
Figure 4L: Floorplan Snapshot of Design I with Macro and IO connectivity highlighted DESIGN II
Figure4M: Floorplan Snapshot of Design II with Macro and IO Connectivity highlighted
SNUG 2014 24 DE-ICC DFA
QoR Results after first iteration of floorplanning
WNS (reg2reg) TNS (reg2reg) Violation Paths Congestion Design I -0.324 ns -147.239 ns 2767 0.05% H and 0.05% V Design II -0.170 ns -119.193 ns 1236 0.01% H and 0.05%
4.3.2 Vendor floorplan validation
In hybrid-ASIC flow, the vendor does final refinement of partition floorplan and delivers it for Phys- ical Synthesis activity for next phase netlist generation. In traditional approach, floorplan validation is done by manually correlating the dataflow with the floorplan and analysing the module placement results shared by the vendor. However as design becomes complex, with huge number of partitions, this process becomes time consuming and inefficient.
DFAs Advance Flyline Analysis, this analysis can be done much quicker and take corrective ac- tions. The turn-around time and number of iterations can be cut down significantly.
DESIGN I:
As shown in Figure 5a, one macro placed in the right hand top corner is talking to macros on the left. In the other picture selected group of macros are talking to right hand side macros.
Once the incorrect placement of macros is identified based on the cross-selection in Figure 5a, floor- plan can be modified and validated.
Figure 5a: Design I with cross-selection of macros
SNUG 2014 25 DE-ICC DFA
Figure 5b: Design I with macro placement corrected QoR Comparison:
WNS (Reg2Reg) TNS (Reg2Reg) Number of Violating Paths Old Floorplan -0.140ns -1033.4ns 12499 New Floorplan -0.073ns -428.005ns 11070
DESIGN II:
Figure 5c: Design I with cross-selection of macros
Once the incorrect placement of macros is identified based on the cross-selection in Figure 5a, floor- plan can be modified and validated.
SNUG 2014 26 DE-ICC DFA
Figure 5d: Design I with macro placement corrected
QoR Comparison:
WNS (Reg2Reg) TNS (Reg2Reg) Number of Violating Paths Old Floorplan -2.189 ns -16339.668 ns 38185 New Floorplan -0.387 ns -1869.545 ns 7906
DESIGN III:
Figure 5e: Design II with macro connectivity highlighted
As shown in Figure 5c, one macro placed in the left hand top corner is talking to macros on the right. In the other picture selected group of macros are talking to left hand side top macros and IOs.
Based on the DFA feedback, a new floorplan is created which improved the QoR significantly.
SNUG 2014 27 DE-ICC DFA
Figure 5f: Design II with macro placement corrected QoR Comparison:
WNS (Reg2Reg) TNS (Reg2Reg) Number of Violating Paths Old Floorplan -0.197ns -309ns 10705 New Floorplan -0.047 ns -20.37ns 3202
4.4 Benefits and Usage
As discussed above, logical connectivity analysis and Dataflow flyline analysis features of DFA in- side ICC has accelerated the process of: 1. Generating an initial floorplan for subchips 2. Validating the floorplans from the vendor
5 Limitations/Enhancement Requests
We are working with Synopsys R&D to bring more usability related feature enhancements to enable top-level implementation:
1) Ability to trace through pipeline flops if they already exist between subchips before making them as soft macros 2) Cross-probing between DFA and Layout Window for planGroups (blocks) 3) Size the plan groups based on estimated gate-count and memory area, which will help in black-box flow 4) Use the DFA information to quickly suggest floorplans 5) Evaluate the quality of DFA generated floorplans by some metric (total wire length)
SNUG 2014 28 DE-ICC DFA
6 Conclusions
In the hybrid-ASIC flow that we use in our group at Cisco, the Data Flow Analysis feature in DE/ICC helped in accelerating the floorplan development and eventually reducing implementation turn around time.
We were able to improve QoR on few blocks using the information provided by DFA. It also helped in quickly creating initial floorplan for few blocks for which the architecture changed in the last phase of the design and provide the ASIC vendor a floorplan along with netlist.
Overall, high quality floorplan is feasible using DFA features: Logical connectivity analysis Net Filtering capability Detail Connection Report Advance Flyline Analysis for macro/macro and macro/io connections that traces Through registers and logic gates
In addition, the Register Highlight feature in DFA helped in identifying and analyzing the pipeline register placement at top level.
7 Acknowledgments
We would like to thank Mr. Krishna Vittala, SNUG Tech Committee for reviewing this paper and provide feedback.
We would like to thank Mr. Steven Kister, Synopsys R&D, for reviewing the paper and provide val- uable suggestions and feedback.
Thanks to Brian Tran and Sandy Hsu from Synopsys, Inc. for introducing this new feature to us and providing excellent support. Both of them have been instrumental in communicating the enhance- ment requests to R&D and getting them implemented.
8 References
[1] IC Compiler Design Planning User Guide by Synopsys. [2] https://solvnet.synopsys.com [3] IC Compiler Data Flow Analysis Demo (DAC 2013) [4] Early Architecture Exploration using ICC by Krishna Kumar Gundavarapu, Cisco (SNUG 2010)