Issue with rewiring: Unrouted Pins exist after Routing

[braju4280]

I was trying to rewire after post placement. I followed below steps to rewire/connect.

• Invoked RW after placement
• removed the EDIFPortInst (edifPortInst) from one EDIFNet(edifNet1) [used api is edifNet1.removePortInst(edifPortInst)]
• add edifPortInst to other EDIFNet (edifNet2) [api : edifNet2.addPortInst(edifPortInst)]
• And the generated dcp and loaded into vivado
• route_design

I can see rewiring is happened in UI, but pins corresponding to edifPortInst’s which we touched became unrouted.

[clavin-xlnx]

It sounds like the site routing would need to be redone---route_design assumes site routing is complete (happens during place_design). Generally, you can call SiteInst.routeSite() or Design.routeSites() to accomplish this. However, without looking at the specific example, its not always clear if there could be something else going on. From your description, you are successfully modifying the logical netlist, but the physical netlist (site routing) would also need to be adjusted accordingly.

Feel free to post the design/example code if you believe there are other issues going on.

[braju4280]

example : PipelineGenerator.java

` orgNet : bus1[0] target Net :bus1[1] sinkPort : d_1_0/D

            orgNet.removePortInst(sinkPort);
            targetNet.addPortInst(sinkPort);
            EDIFCellInst cell = sinkPort.getCellInst();
            Cell phyCell = phyToLogical.get(cell);
            SiteInst site = phyCell.getSiteInst();
             design.routeSites();`

This is simple code i used for rewiring, It shows the below error Exception in thread "main" java.lang.RuntimeException: ERROR: Unable to route bus1_[1] in site SLICE_X46Y70 at com.xilinx.rapidwright.design.SiteInst.routeSite(Unknown Source)

Rewing without design.routeSites();

[clavin-xlnx]

The error is due to the physical net orgNet not being unrouted before attempting to route the site. Just changing the EDIFPortInst in the logical netlist will not update/change the state of the site routing. The site routing corresponding to the sinkPort can be unrouted by removing the SitePinInst from the physical net with the following commands:

Cell physCell = d.getCell("d_1_0"); // Get's the physical FF placed cell
SitePinInst physSitePin = physCell.getSitePinFromPortInst(sinkPort, null); // Gets the corresponding SitePinInst from our EDIFPortInst
Net physicalNet = d.getNet("bus1_[0]"); // Gets the corresponding physical net
physicalNet.removePin(physSitePin); // Removes the SitePinInst and associated site routing

Although modifying a placed and routed netlist is possible in RapidWright, it can be tricky to remember to modify both physical and logical representations. Ideally, we could have more APIs that automate this behavior, however, there are many use cases that we haven't mapped out yet. Perhaps this is one and we welcome insight into others.

[braju4280]

Thanks for your time, effort and suggestion!

[shivnandanpandey]

Can we Modify only the placed netlist?? I am facing the issue while modifying the placed netlist. Physical nets are not connected to SitePins (after placement, basically unrouted nets ). when I am trying to get net.getPins() , I am getting the empty list .

The code, which is mention above by you is not helping. physCell.getSitePinFromPortInst(sinkPort, null); // this is always returning null SitePin

my flow is similar. place_design-> RW->place_design-> route_design|| I am getting the error at end of route_design ( depositing route pins), it is saying conflicting source net for the site. I actually manipulated ( logically changed the assignment ) both the nets. Now it looks like both are still pointing to the same SitePin I am not able to modify the physical net ( in an only placed netlist).

Just wanted to confirm that is it possible or not?

Thanks, Shivnandan

[clavin-xlnx]

Hi @shivnandanpandey ,

Yes, modification of the logical and physical netlist is certainly possible in RapidWright. The error you are seeing is because there is an inconsistency between the logical and physical netlist somewhere and Vivado is having trouble rectifying the difference. Here are a few points to consider (item 2 seems most likely to be the cause of the error, but it is difficult to say without seeing the error message/design):

1. SitePinInst objects or site pins that connect to physical nets do not get included in the DCP. They are not represented, Vivado reconstructs them upon loading the design. They are just helper objects that help in RapidWright to navigate routing. Your flow will not have any as currently they are only present in a routed design. However, you can create them by calling DesignTools.createMissingSitePinInsts(Design design). This probably won't affect the error your are seeing, but explains the empty list you mentioned.
2. During Vivado's place_design, the sites are routed. Site routing consists of mapping physical nets to the site wires found within a site. Site routing will connect site pins to the bel pins of the placed cells. If the site routing is incorrect or not present, this can cause problems during route_design. If you are making ECO-type changes to the placed netlist, the site routing should also be modified accordingly (replace old site routing with new net). You can use SiteInst.routeSite() to call an automatic site router in RapidWright on the site instance after being modified, or you can use a directed API such as SiteInst.routeBELPins(BELPin source, BELPin sink, Net net). Hint: If you just need to route a single site wire, you can set the BELPins source==sink.
3. There is an internal map in EDIFNetlist that can become out of date if the netlist is being changed. If you make changes and want to route SiteInst.routeSite(), you'll need to call EDIFNetlist.resetParentNetMap() before so that it can reflect your most recent netlist changes.
4. The names of physical nets in RapidWright attempt to follow the same naming convention as Vivado, that is a physical net is named after the hierarchical source pin name. When modifying the netlist, that name can change and should be updated accordingly (see item 3). This is also called the "parent net" as many logical nets can map to the same physical net. For an illustration of this concept, see Figures 5 and 6 of this paper.

Hope that helps.