RapidWright Placer

[coherent17]

Hi RapidWright experts,

We’re currently struggling with Vivado placement on a partial netlist. The placer appears to be very aggressively wirelength‑driven (assume we can’t change the placer options). As a result, the router often fails or runs for more than 20 hours on Versal devices, especially when multiple pblock constraints overlap.

Given a partial netlist with high connectivity to the IOs, does RapidWright provide a way to pre‑place that portion of the design (fixing cell/BEL locations) and then hand the full design off to Vivado for full‑chip place and route?

More concretely, is the following workflow realistic?

1. Use RapidWright to place and fix a highly connected sub‑netlist near the IOs (leveraging RapidWright’s knowledge of Vivado’s placement rules).
2. Import the complete design into Vivado and let Vivado place and route the remaining logic around that fixed region.

Any guidance or experience you can share on this approach would be greatly appreciated. If there are example RapidWright placer flows, pointers would be very helpful. Alternatively, do you think this is better handled purely within Vivado using incremental placement?

Thanks,
Coherent

[clavin-xlnx]

Hi Coherent,

We actually have several solutions that address similar scenarios as to what you are describing. In designs that have challenging implementation and also multiple instances of the same cell, we can use a "copy and paste" approach. In this techniques we leverage Vivado to place and route a challenging cell in a pblock in an out-of-context run. In a smaller context, Vivado can spend more effort trying to refine the implementation and has a greater chance of discovering a good implementation. Often we will run multiple Vivado builds in parallel to explore the search space. Once a good implementation is found, we can then apply that solution to multiple instances of that cell like a stencil, replicating the placed and routed solution to multiple cell instances. I wrote up a tutorial on how to choose pblocks and prepare cells for this process here: https://www.rapidwright.io/docs/PreImplemented_Modules_Part_I.html and https://www.rapidwright.io/docs/PreImplemented_Modules_Part_II.html.

RapidWright has the concept of adding a level of hierarchy to the physical netlist called a Module and it can be instantiated in a design as a ModuleInst. We have a couple of tools that aid in the ability to copy and paste these ModuleInst objects.

1. ArrayBuilder (in current development): This tool will take a post-synthesized netlist and, given a specific cell or kernel that you want optimized, it can take as input a pblock and invoke multiple runs of Vivado to discover a good implementation. Then, it can identify the instances of that cell in the top netlist and "copy and paste" the placement and routing of the cell into the multiple instances of the design.
2. RelocationTools: This is a simpler tool, but allows you to take a DCP and relocate it to another compatible location on the fabric.

If the design does not have replicated logic, we have run some experiments with using Vivado to create a "shell" or "overlay" of sorts. Often what happens is that there is infrastructure logic that doesn't change as often and can be locked down. Another part of the design can change frequently and the idea is that you could use the shell or overlay logic as a starting point and place and route the frequently changing logic around it. I wrote up a tutorial on this approach here https://www.rapidwright.io/docs/ReusingTimingClosedLogicAsAShell.html. Unfortunately, in our experiments, some conditions may prevent it from working, but if this is an attractive route, we can explore it with you.

Let us know if one of these options matches what your current design needs are and we can help you get started.

Chris

[coherent17]

Hi Chris,

Thanks again for the guidance. I’ll spend some time digging into the example you provided once I’m back from military leave in about two months. I’ve done a quick pass over it and it makes sense conceptually, but I’d like to try it hands‑on when I have time.

I’m also wondering whether placement can be done entirely in RapidWright, without relying on Vivado’s placer.
The flow I have in mind is roughly:

• The full design = a “partial” netlist (the part I care about) + the rest of the netlist.
• RapidWright takes the partial netlist plus pblock constraints on those cells, and runs a (ideally routability‑driven) placement within those pblocks, producing fixed leaf cell→BEL mappings.
• A separate script/tool then reads those fixed coordinates and invokes Vivado to perform full‑chip place and route around that pre‑placed region. (I can handle this part)

Coherent

[clavin-xlnx]

Hi Coherent,

In theory, full placement is possible in RapidWright. One of the parts that probably needs to be improved is automatic legalization of the placement of cells into sites. For example, flip flops (FDRE cells. or similar) have certain requirements around their control set signals that add some complication to placement. RapidWright doesn't have a holistic fully automated way to place these flip flops legally without having to check that the control set signals are compatible first.

There have been some efforts to perform full placement in RapidWright:

• Simulated annealing (site-based) that depends on the sites being packed first (avoids the legalization part) https://github.com/TotoroTron/place-and-route
• DREAMPlaceFPGA - GPU accelerated placement https://github.com/rachelselinar/DREAMPlaceFPGA/tree/main/IFsupport

We're happy to explore options for you as well when you have the time.

Chris