PhysicalNetlistToDcp doesn't appear to respect site pip selection in some cases

[litghost]

As part of bring up of the FPGA interchange on nextpnr, the initial site router is avoiding use of local inverters. It was expected that the FPGA interchange physical netlist would be able to specify site routing that is sub-optimal with respect to constant networks and local inverters to allow an easier initial implementation. However that doesn't appear to be the case.

In the attached file, ram_test.tar.gz, there is an example of a physical netlist (and DCP) where the non-inverting path is taken for GLOBAL_LOGIC0, see snippet from YAML:

        branches:
          - routeSegment:
              pip:
                tile: INT_L_X6Y45
                wire0: GFAN0
                wire1: CTRL_L1
                forward: true
                isFixed: false
            branches:
              - routeSegment:
                  pip:
                    tile: BRAM_L_X6Y45
                    wire0: BRAM_CTRL1_0
                    wire1: BRAM_RAMB18_RSTREGB
                    forward: true
                    isFixed: false
                branches:
                  - routeSegment:
                      sitePin:
                        site: RAMB18_X0Y19
                        pin: RSTREGB
                    branches:
                      - routeSegment:
                          belPin:
                            site: RAMB18_X0Y19
                            bel: RSTREGB
                            pin: RSTREGB
                        branches:
                          - routeSegment:
                              sitePIP:
                                site: RAMB18_X0Y19
                                bel: RSTREGBINV
                                pin: RSTREGB
                                isFixed: false
                                isInverting: false
                            branches:
                              - routeSegment:
                                  belPin:
                                    site: RAMB18_X0Y19
                                    bel: RAMB18E1
                                    pin: RSTREGB
                                branches: []

However the DCP generated uses the inverting path (e.g. BEL pin RSTREGB_B) for the site routing mux RAMB18_X0Y19/RSTREGBINV. The key here is BEL pin RSTREGB_B vs RSTREGB. The documentation for addSitePIP indicates that the equivalent command in Vivado would be:

set_property MANUAL_ROUTING [get_property SITE_TYPE $site] $site;set_property SITE_PIPS "[get_property SITE_PIPS $site] $sitePIP" $site;set_property MANUAL_ROUTING {} $site

That property does not appear to be site in the DCP generated from the physical netlist attached. I've tried swapping the order of site pip (which uses addSitePip) versus BEL pin (which uses routeIntraSiteNet). I've also tried using routeIntraSiteNet to route the relevant net directly to the input site PIP BEL pin. None of this appear to cause the DCP to respsect the original intent.

Is this a limitation in RapidWright? A straight forward bug in the PhysNetlistReader?

[litghost]

So it does appear that I'm wrong, and the properties are set, but Vivado (2019.2) doesn't respect them?

set site [get_selected_objects ]
RAMB18_X0Y19
get_property SITE_PIPS $site
set_property MANUAL_ROUTING [get_property SITE_TYPE $site] $site
get_property SITE_PIPS $site
RSTREGARSTREGINV:RSTREGARSTREG RSTRAMBINV:RSTRAMB ENBWRENINV:ENBWREN ENARDENINV:ENARDEN CLKARDCLKINV:CLKARDCLK RSTREGBINV:RSTREGB RSTRAMARSTRAMINV:RSTRAMARSTRAM CLKBWRCLKINV:CLKBWRCLK 

[clavin-xlnx]

Yes, I can confirm that all the properties are set to indicate a fully routed GND path, however, somehow Vivado has overridden the input site wire to be mapped to VCC.

Perhaps because there are dedicated routing paths from VCC to the pin, Vivado is trying to minimize routing (power consumption, etc)? I would have to dig deeper to find out the reason for this behavior.

[litghost]

Perhaps because there are dedicated routing paths from VCC to the pin, Vivado is trying to minimize routing (power consumption, etc)? I would have to dig deeper to find out the reason for this behavior.

Yes, there are dedicated routing paths from VCC, but the hope was that the less optimal GND routing would be possible. If it isn't allowed, I'll have to finish implementing "best constant" routing.

[clavin-xlnx]

Unfortunately, I don't see a way to change the behavior of Vivado in the short term. Sorry, it is disappointing that it must have some built-in behavior that doesn't necessarily respect the settings.

[litghost]

Unfortunately, I don't see a way to change the behavior of Vivado in the short term. Sorry, it is disappointing that it must have some built-in behavior that doesn't necessarily respect the settings.

I just wanted to check that this was a limitation of RapidWright, rather than a latent bug in the tooling. We hit this exact issue with the VPR based flow, so it doesn't really surprise me we are hitting it again in the FPGA interchange/nextpnr flow. We have the "best constant" metadata to specifically handle this case, I'd just hoped that I wouldn't need to solve this particular feature right away.