A growing number of Xilinx® customers are enjoying improved performance, reduced engineering time and design costs, and the ease of use offered by the PlanAhead™ design and analysis tool. These customers are expressing the same realization – a complete paradigm shift in their FPGA design flow.

Over the past several weeks, I have talked with several application engineers at Xilinx about their experiences with PlanAhead software. I found three main hurdles where the PlanAhead design tool offers a significant advantage: when the design fails to meet timing; when the design doesn’t fit into the target device; and when the place and route run time is too long. I also found that many of the engineers use PlanAhead software to view the results from place and route.

In this article, I’ll discuss the processes that these engineers and I use, and provide statistics on what customers are seeing from using PlanAhead software. When doing your own floorplanning, remember that poor floorplanning can give you worse timing, larger device utilization, and longer place and route run times. My goal is to outline the concepts to help you accomplish your performance goals.

Failure to Meet Timing
When we as application engineers receive a design that has difficulty meeting timing, we run the design without any floorplanning constraints. This entails removing existing area groups and larger component physical constraints but keeping pin placement. If the place and route time is very long, then we run TimeAhead, the static timing tool within PlanAhead software, to get an early estimation of the critical paths. The TimeAhead analysis also helps identify areas of the design that need RTL revisions to add registers to pipeline critical paths.

If possible, we run place and route on the design and view the placement and timing results within the PlanAhead environment. The timing results from the placed and routed design show us the critical paths based on actual delays (Figure 1). The device view displays the placed design, along with the timing paths from the TRCE report.

We create Pblocks or area groups based on critical paths of the design from the timing report. These Pblocks can be floating or defined as a specific rectangle or shape. Pblocks can contain logic from anywhere in the design and are not limited to the RTL logic hierarchy. Analyzing the imported placed and routed design, we use the current placement of the elements that make up the Pblock to determine a good starting point for the Pblock rectangle.

Pblocks can direct the flow of the design based on the connectivity of different modules. The connectivity of the I/Os to and between modules is shown for the placed and routed design through net bundles. We create Pblocks to cover the critical paths, which are usually associated with getting on or off the device.

The schematic view also displays the connectivity of the design (Figure 2). Pblocks are created either in the device, schematic, or netlist views. The critical paths and other timing paths relative to the existing floorplanning can be highlighted in the device and schematic views.

Normally, the schematic view is used to examine the critical modules and paths without worrying about the actual placement of those modules. The congestion around existing Pblocks and the resource utilization of a Pblock are seen in the device view. If the timing is critical within the Pblock (indicated by a high resource utilization count) then we resize the Pblock to give the congested logic more room to meet timing by condensing the logic to shorten the interconnect lengths and delays. We can also move the Pblocks to alleviate congestion or merge congested logic into a single Pblock.

We create and place the Pblocks, then run place and route with our floorplanning constraints. We also lock the locations of the larger components and critical logic, which includes block RAMs, DSP48s, and DCMs. Then we run place and route on the design and repeat the process by reviewing the timing report and placement of the design and modifying the constraints (Figure 2). We can also create smaller “child” Pblocks inside other Pblocks to help the grouping of a few components for timing-critical paths.

Place and route is run on individual Pblocks in addition to the entire design. This helps determine if timing can be met inside the module or Pblock without affecting the rest of the design. If we are unable to meet timing on a specific Pblock, we go back to the source code and re-write it.

PlanAhead software can import the updated netlist for any module and keep the Pblocks originally created. After meeting timing requirements, we place location constraints on all of the elements of that Pblock. This helps ensure that timing is retained when the rest of the design is placed and routed.

The majority of timing failures that we see are related to setup violations. We also see hold violations, which are tricky to fix. Most of the time, a hold violation occurs because of the placement of critical clocking components. We get a large number of clock skew and hold violations when the DCM and corresponding global buffer are placed on opposite sides of the device.

PlanAhead software also has a robust set of DRC checks to highlight these types of issues early in the flow. We use the schematic and device views to view the placement of these components. We then move the placement of either the DCM or the global buffer so that these components are near each other.

The Design Doesn’t Fit
When a design has difficulty fitting into the target device, we run it without any floorplanning constraints. Usually, overlapping Pblocks exist, which we remove. We place the large components manually, as we described in the previous section, to help the place and route tools.

If timing is not a critical issue for this design, we then create Pblocks of the major hierarchical blocks of the design. The Pblocks are used to direct the flow of the design based on connectivity of the module with net bundles. The bundles show the amount of connectivity based on the size of the bundle. We place the Pblocks close to the components that drive them based on the net bundles and Pblock statistics. We also place the entire design into a Pblock and use the compression attribute on the Pblock(s) to tell MAP to pack this portion of the design as tight as possible. This attribute opens up more room on the rest of the device for the remaining logic, but has a negative effect on timing.

We also run place and route on the individual Pblocks of the design. This helps ensure that the logic placed in the Pblocks can be placed and routed within the defined Pblock size and eventually in the device specified. We can manually compress the size of the Pblock until MAP fails. Once MAP fails, we revert back to the last known good size of the Pblock.

The statistics of the Pblock may report that we used more than 100%, but MAP will determine if it passes. We repeat this process if other non-timing critical Pblocks exist and use the compression attribute to pack those Pblocks as tight as possible.

At this point, we run place and route on every Pblock as well as the entire design. If it still does not fit, we pick a larger device, or go back to the source code and rewrite it. The majority of the time, we run place and route on a Pblock-by-Pblock basis and import the updated module into the PlanAhead design tool. This process retains the existing Pblock size and physical location constraints. Once the design fits into the desired device, we lock the physical locations for the entire design.

Place and Route Time is Too Long
For the majority of designs received by the application engineers, the previous two issues are the most critical. Because the place and route run time decreases once these issues are resolved, the tools do not require the same long run times necessary to meet performance goals. If none of the previous issues are of concern, we then view the timing report and placed and routed design to create Pblocks of the major modules.

The key to decreased place and route run times is the physical location constraints for the entire design. To find the correct placement constraints for the design, we run place and route on each Pblock and size it according to the timing constraints for each Pblock. This is also possible when utilizing an incremental update approach based on the logical hierarchy in the design. PlanAhead software can selectively update any module in the design with an iterated module netlist. This allows us to take advantage of an incremental synthesis approach. We can determine the placement of Pblocks by the connectivity between modules and the I/O pads and the net bundles for connectivity between modules. The non-timing-critical Pblocks can be compressed manually and the larger components placed.

Place and route is then run on the design, repeating the process by reviewing the timing report and placement of the design and modifying the constraints accordingly. You may have to combine the approaches and try these techniques over several interactions if you have a combination of several of these issues.

View the Design
Many of the application engineers use the PlanAhead design tool as a visual representation of the design before and after running place and route. We use the tool to graphically see the timing paths and placement of the design. The schematic, device, and package views give us different angles on the design (Figure 3). The device view gives us the ability to see the correlation between the SLICE/CLBs and the I/O banks. Timing paths are also clearly displayed and corrective action can be taken.

Through interacting with the application engineers, the vast majority of customers have reported good experiences and results. Table 1 illustrates some customer issues before and after using PlanAhead software.

Conclusion
In this article, I have discussed the ways that Xilinx customers and application engineers are using the PlanAhead design tool to overcome three main areas of concern. These concepts should help you accomplish your performance goals. I hope you will agree with one recent customer, who stated, “PlanAhead software allows us to achieve quicker verification and prototyping, with fewer iterations.”

For more information about the PlanAhead design tool, visit www.xilinx.com/planahead.

Printable PDF version of this article with graphics.  (7/11/05) 250 KB