Closed litghost closed 3 years ago
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
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.
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.
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.
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.
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:However the DCP generated uses the inverting path (e.g. BEL pin
RSTREGB_B
) for the site routing muxRAMB18_X0Y19/RSTREGBINV
. The key here is BEL pinRSTREGB_B
vsRSTREGB
. The documentation foraddSitePIP
indicates that the equivalent command in Vivado would be: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 usesrouteIntraSiteNet
). I've also tried usingrouteIntraSiteNet
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
?