search

SymbiFlow / nextpnr

nextpnr portable FPGA place and route tool
ISC License
20 stars 2 forks source link

[interchange] Site pin conflicts in RAM test #287

Closed gatecat closed 3 years ago

gatecat commented 3 years ago

Run make test-fpga_interchange-ram_basys3-dcp in nextpnr and open the DCP in Vivado. There are routing issues (nets in yellow rather than green), report_route_status reports the following:

  GLOBAL_LOGIC0
    Unrouted Nodes (not associated with pins or ports):
      BRAM_L_X6Y30/BRAM_FIFO18_WEBWE4
      BRAM_L_X6Y30/BRAM_FIFO18_WEBWE5
      BRAM_L_X6Y30/BRAM_FIFO18_WEBWE6
      BRAM_L_X6Y30/BRAM_FIFO18_WEBWE7
  GLOBAL_LOGIC1
    Unrouted Nodes (not associated with pins or ports):
      BRAM_L_X6Y30/BRAM_FIFO18_REGCLKARDRCLK
      BRAM_L_X6Y30/BRAM_FIFO18_REGCLKB
    Conflicts with Site Pins: BRAM_L_X6Y30/BRAM_FIFO18_REGCLKB (RAMB18_X0Y12/REGCLKB)
  ram.rdclk
    Conflicts with Site Pins: BRAM_L_X6Y30/BRAM_FIFO18_REGCLKB (RAMB18_X0Y12/REGCLKB)

An illustration of some of the routing problems:

Screenshot from 2021-05-04 14-20-01

It appears like the cell-bel pin mapping isn't correct.

Design files: ram_basys3.zip

cc @acomodi - are the examples in nextpnr still supposed to work, or in practice are they deprecated and I should be using fpga-interchange-tests instead?

gatecat commented 3 years ago

This is affecting fpga-interchange-tests as well, actually. It is probably a good idea to get CI with Vivado up and running sooner rather than later....

gatecat commented 3 years ago

Oops, my RapidWright was out of date. With that fixed it works fine.

acomodi commented 3 years ago

@gatecat I think that the tests in nextpnr are still valid from a PnR point of view so that we know that everything is fine there, but the validation of these should happen in fpga-interchange-tests.

I'll soon add the DRC validation step for xc7 in fpga-interchange-tests so we can catch these kinds of issues.

In general I'd say that we should have all the tests in nextpnr working (aka valid DCP are generated) and a way to frequently check this in fpga-interchange-tests. The problem is that at the moment the nextpnr, interchange-schema and python-interchange need to be manually updated to the latest versions, and here a bot might be required to get to update regularly and automatically the versions of the various tools, such that, if some change either in one of the tools causes the validation step to fail, we can catch it ASAP.