What are the Benefits of Area Constraints?

Objectives Create effective Area Constraints using PlanAhead tool Identify Floorplanning Methodologies Avoid the most common design and synthesis mistakes during floorplanning Gain timing closure with the PlanAhead™ tool Place the dedicated hardware resources Note: The guidelines in this module are not specific to any particular synthesis tool or Xilinx FPGA family.

Definition of Floorplanning (Area Constraints) In the past, the term “ Floorplanning” meant to make placement constraints on CLB logic (assign it to specific locations) The term “ floor planning“ in the ASIC world still means to place (assign) gates in a specific location on an array Floorplanning is NOT necessary in an FPGA but can help to improve timing Xilinx recommends the use of area constraints, rather than the use of placement constraints However, this does require some skill Floorplanning is now commonly referred to as “placing Area constraints” So whenever you see “Floorplanning” we mean “Area Constraints” Floorplanning improves timing by reducing route delay. It does not change the gates in the design. Certain timing problems are better solved by re-synthesizing the netlist. As a general rule, engineers should floorplan hierarchy not gates. A gate-level floorplan is time consuming and is very hard to do correctly. Hierarchical floorplanning is much easier, serves as a guide to place and route, and has more success. Timing-critical hierarchy will be examined first. The hierarchy is floorplanned to a region on the device, chosen by the engineer after some chip and design analysis. This brings a certain level of repeatability to subsequent place and route runs even if the netlist changes. Sometimes it can be a good idea to floorplan some timing non-critical logic to get it out of the way of the critical logic, or for IP reuse.

Reasons to Floorplan with Area Constraints Floorplanning is considered when the design has not met timing or does not meet timing consistently Floorplanning condenses and contains critical logic to improve performance Reduce routing congestion Isolate non-critical logic Create a data flow-based floorplan Use unique Pblock capabilities in the PlanAhead tool Improve module-level performance and area Improve implementation run time and consistency with Partitions Floorplanning improves timing by reducing the routing delays associated with an area constraint. It does not change the gates in the design. As a rule, engineers should floorplan hierarchy and components not gates (that is LUTs and CLBs). A gate-level floorplan is time consuming and is very hard to do correctly. Hierarchical floorplanning (with area constraints) is much easier, serves as a guide to place and route, and has more success. Some designers plan to floorplan early, while others take a wait-and-see approach.

Design and Synthesis Recommendations Set up your synthesis tool to preserve the hierarchy in the netlist Flattened netlists may be optimal from a synthesis perspective, but they make it very difficult to reliably floorplan and constrain placement Structure the RTL logic so that critical timing paths are confined to individual modules Critical paths that span large numbers of hierarchical modules can be difficult to floorplan Register the outputs of all the modules to help limit the number of modules involved in a critical path Replicate the drivers of nets that will be separated on the die Synthesis may need an attribute to preserve equivalent logic These recommendations are important if you are going to use area constraints to improve your design speed or use partitions to maintain some of your results.

Design and Synthesis Recommendations Intermingled critical paths can be difficult to floorplan Consider dividing large critical blocks into smaller and separate hierarchical blocks If the design is expected to change often, consider an incremental approach to synthesis In an incremental approach, individual blocks can be synthesized separately or the synthesis attributes (SYN_HIER=HARD) can be used to preserve the hierarchy Hierarchy preservation helps an incremental flow but may hurt performance because global optimizations across hierarchy are disabled

Design and Synthesis Recommendations Consider using the synthesis option to rebuild the hierarchy For XST, use –netlist_hierarchy = rebuilt If using the PlanAhead tool for synthesis, the PlanAhead tool default synthesis strategy includes this option Long paths in single large hierarchical block can make floorplanning difficult Divide large hierarchical blocks in the RTL

Re-Use Flow Methodology Can help a design that meets timing only some of the time The idea is to re-use some of the block RAM and DSP slice placements from a successful implementation Synthesize the design Run implementation many times with only timing constraints and pin assignments Choose the result that has met timing and had the fastest implementation time Fix the placement of the block RAMs and DSP slices Either by manually placing them or using the Find command With a little experience you may want to manually place them Re-implement as needed Note that this flow does not guarantee that with significant changes it will continue to meet timing; it is just a good starting point. Also note that if the names of the components change, the placement constraints may need to be done again.

Hierarchical Methodology Synthesize the design Run implementation with only timing constraints and pin assignments If it fails to meet timing (many paths fail across many components) Make the area constraints based on the highest levels of your design hierarchy Possibly constrain the entire design Ask yourself these questions What are the timing failures? What are the critical hierarchical blocks? Are changes to the floorplan or critical logic going to be sufficient to meet timing? Does anything else need to be floorplanned? Can just the critical hierarchies be floorplanned? Where should my logic be placed? This method works best when you have a high performance design with most clocks running at high speed. This flow is generally planned on being used from the beginning.

Placement of Dedicated Resources Placing dedicated hardware is a terrific strategy The implementation tools do not always do the best job Consider placing block RAMs and DSP slices This works well when you make area constraints Placement of dedicated resources guides the implementation tools to move CLB logic closer to the desired location Place area constraints near the I/O pins and dedicated hardware you plan to use Block RAM Block RAM

Where are the Dedicated Hardware Resources? Virtex-6 FPGAs Spartan-6 FPGAs 760K Logic Cell Device 150K Logic Cell Device Common Resources LUT-6 CLB The dedicated resources will vary by device family. In general, designers are planning their device pinout early in the design cycle and they are planning to use the pins nearest the dedicated hardware resources to minimize routing delay. This is equally important when you use area constraints to place CLB logic near your chosen pin assignments and dedicated hardware. The key dedicated hardware resources include clocking resources (DCMs and PLLs), block RAMs, DSP slices, HSS transceivers, PCI™ interface blocks, dedicated memory controllers, and tri-mode Ethernet MACs. In the Spartan®-6 FPGA, the high-speed serial transceivers are located on the left edge. This is only available in the LXT subfamily. The LX subfamily has regular I/O on the left edge of the die. Note that the Virtex®-6 FPGA FIFO logic is placed with the block RAM resources. You should be in the habit of making area constraints that make sense to the placement of your dedicated hardware. Note also that the placement of dedicated hardware varies considerably by device family and density. Area constraints that work for one device will need to be altered if the design will move to another device. Block RAM DSP Slices High-performance Clocking FIFO Logic Parallel I/O Hardened Memory Controllers Tri-Mode EMAC HSS Transceivers* 3.3 Volt Compatible I/O System Monitor PCIe® Interface

Assigning LOC Constraints Most logic objects can be manually assigned to a specific site Click the Create Site Constraint Mode toolbar button (to place) Note that placed logic has a blue bar Logic is easily found with the Find command and then dragged to be placed Cursor indicates legal placement sites Right-click allows you to un-place When you assign LOC constraints to primitives, no DRC is performed. This means that you can accidentally break carry chains and other design rules. Be aware of any placement restrictions when you are assigning LOCs to primitives.

Assigning BEL (Basic Elements) Constraints Click the Create BEL Constraint Mode toolbar button Drag a LUT or FF primitive from the Find menu or Netlist view onto a specific slice Primitives with LOC constraints are displayed in the Netlist view with blue striped icons Click the Assign Instance Mode toolbar button to return to floorplanning mode

LOC Constraint Applications To clear LOC constraints Select Tools > Clear Placement Many options to selectively clear LOCs Separate controls for I/O ports Importing an implementation result leaves the logic unfixed Importing LOCs from a UCF file is considered manually assigned and remains placed Right-click a placed object to Fix Instances (LOC) I/O interfaces or cores, for example Lock down non-slice-based logic (block RAMS, or DSP, for example) Maximize module performance and consistency Export constraints with File > Export Constraints The tool has a concept of fixed versus unfixed logic. You will want to place some objects (I/O, block RAMs, DSP slices, for example); these LOCs are considered “fixed”. For analyzing place and route timing, it is useful to see where the implementation tools place these objects. For the tools to do this their placement must be “unfixed”. Before exporting the placement for an implementation run or to a UCF, the tool will ask if you want a LOC constraint in the UCF for all gates (fixed and unfixed) or just the user-placed fixed logic.

Summary Area constraint guidelines Use the timing report to identify logic to floorplan Leverage the implementation results to guide placement of area constraints Placement of dedicated resources can guide the implementation tools Be sure to make an area constraint with the associated logic and assign it near the dedicated hardware to improve performance Placement improves implementation consistency between each iteration

More Information To learn more, visit the PlanAhead tool web site www.xilinx.com/planahead Articles, documentation, white papers, and training enrollment User Guide PlanAhead Software Tutorial, Design Analysis and Floorplanning for Performace, UG676 Floorplanning Methodology Guide, UG633 View the PlanAhead tool video demonstrations Quick Tour of the PlanAhead Design and Analysis Tool I/O pin planning with PinAhead Technology Improve Design Performance with the PlanAhead Design and Analysis tool

Where Can I Learn More? Xilinx Education Services courses www.xilinx.com/training Xilinx tools and architecture courses Hardware description language courses Basic FPGA architecture, Basic HDL Coding Techniques, and other free Videos! How to make Area Constraints with PlanAhead tool Video!

Trademark Information Xilinx is disclosing this Document and Intellectual Property (hereinafter “the Design”) to you for use in the development of designs to operate on, or interface with Xilinx FPGAs. Except as stated herein, none of the Design may be copied, reproduced, distributed, republished, downloaded, displayed, posted, or transmitted in any form or by any means including, but not limited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of Xilinx. Any unauthorized use of the Design may violate copyright laws, trademark laws, the laws of privacy and publicity, and communications regulations and statutes. Xilinx does not assume any liability arising out of the application or use of the Design; nor does Xilinx convey any license under its patents, copyrights, or any rights of others. You are responsible for obtaining any rights you may require for your use or implementation of the Design. Xilinx reserves the right to make changes, at any time, to the Design as deemed desirable in the sole discretion of Xilinx. Xilinx assumes no obligation to correct any errors contained herein or to advise you of any correction if such be made. Xilinx will not assume any liability for the accuracy or correctness of any engineering or technical support or assistance provided to you in connection with the Design. THE DESIGN IS PROVIDED “AS IS" WITH ALL FAULTS, AND THE ENTIRE RISK AS TO ITS FUNCTION AND IMPLEMENTATION IS WITH YOU. YOU ACKNOWLEDGE AND AGREE THAT YOU HAVE NOT RELIED ON ANY ORAL OR WRITTEN INFORMATION OR ADVICE, WHETHER GIVEN BY XILINX, OR ITS AGENTS OR EMPLOYEES. XILINX MAKES NO OTHER WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, REGARDING THE DESIGN, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NONINFRINGEMENT OF THIRD-PARTY RIGHTS. IN NO EVENT WILL XILINX BE LIABLE FOR ANY CONSEQUENTIAL, INDIRECT, EXEMPLARY, SPECIAL, OR INCIDENTAL DAMAGES, INCLUDING ANY LOST DATA AND LOST PROFITS, ARISING FROM OR RELATING TO YOUR USE OF THE DESIGN, EVEN IF YOU HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE TOTAL CUMULATIVE LIABILITY OF XILINX IN CONNECTION WITH YOUR USE OF THE DESIGN, WHETHER IN CONTRACT OR TORT OR OTHERWISE, WILL IN NO EVENT EXCEED THE AMOUNT OF FEES PAID BY YOU TO XILINX HEREUNDER FOR USE OF THE DESIGN. YOU ACKNOWLEDGE THAT THE FEES, IF ANY, REFLECT THE ALLOCATION OF RISK SET FORTH IN THIS AGREEMENT AND THAT XILINX WOULD NOT MAKE AVAILABLE THE DESIGN TO YOU WITHOUT THESE LIMITATIONS OF LIABILITY. The Design is not designed or intended for use in the development of on-line control equipment in hazardous environments requiring fail-safe controls, such as in the operation of nuclear facilities, aircraft navigation or communications systems, air traffic control, life support, or weapons systems (“High-Risk Applications”). Xilinx specifically disclaims any express or implied warranties of fitness for such High-Risk Applications. You represent that use of the Design in such High-Risk Applications is fully at your risk. © 2012 Xilinx, Inc. All rights reserved. XILINX, the Xilinx logo, and other designated brands included herein are trademarks of Xilinx, Inc. All other trademarks are the property of their respective owners.