With a freshly cloned artiq repo (version 8 branch), the firmeware build

python -m artiq.gateware.targets.kasli test.json

fails with

Command: write_bitstream -force top.bit
...
ERROR: [DRC PDCN-2721] IBUFDS_GT_loads_clock_region: IBUFDS_GTE2 IBUFDS_GTE2 drives MMCME2_ADV MMCME2_BASE in a different clock region and must do so using local routing resources which may negatively affect clock performance. Use CLOCK_DEDICATED_ROUTE set to FALSE to indicate this is intended.
ERROR: [DRC PDCN-2721] IBUFDS_GT_loads_clock_region: IBUFDS_GTE2 IBUFDS_GTE2 drives PLLE2_ADV PLLE2_BASE in a different clock region and must do so using local routing resources which may negatively affect clock performance. Use CLOCK_DEDICATED_ROUTE set to FALSE to indicate this is intended.

when generating the top bit. This happens for all master/satman/kasli HW version configurations I came up with including this minimal test build (test.json):

{
  "target": "kasli",
  "variant": "test",
  "hw_rev": "v2.0",
  "base": "satellite",
  "peripherals": [
    {
      "type": "dio",
      "board": "DIO_BNC",
      "ports": [
        0
      ],
      "hw_rev": "v1.2",
      "bank_direction_low": "input",
      "bank_direction_high": "output"
    }
  ]
}

I did not find an issue in the git. So is it only me having this issue? Could it be Vivado configuration or something? Any help would be appreciated.

    choelzl

    What Vivado version are you using? (And yes, release-8 otherwise builds successfully with that .json).

      I am using Vivado 2024.1. Well interesting, I will try tomorrow on another machine

        choelzl

        Vivado versions have historically been finicky, so it's possible that that's the problem. The version M-Labs currently uses to build gateware is 2022.2. (See also the manual section on Vivado installation). Interesting to know that 2024.1 fails, if that turns out to be the issue.

          I had installed both and it somehow unintentionally used the 2024.1 . Indeed it now works with forcing the 2022.2. It seems to be an error with 2024.1. I checked also with the 7 branch and the beta branch. Both fail with the same error.

          Can you check what placement and clock routing each version ends up producing? It could be that 2022.2 also produces the suboptimal configuration but simply does not throw an error about it.

          5 days later

          I have not worked with vivado before so I have no idea what to look out for. But I guess it should be the same for your setup