bram_int/dsp_int fuzzers: Topmost clock region is not available for Kintex 420T due to bug in Vivado 2017

[hansfbaier]

As soon as I add bram/dsps from the topmost clock region, the design fails,
complaining that more bram/dsps are instantiated than available on the device.
(Although they clearly exist).

[marzoul]

Hi, I had a similar issue when experimenting on artix 35T.
The issue is that the device, here XC7K420T, is same fabric than XC7K480T which is larger.
So Vivado applies the artificial limit on design size for 420T.
My recommendation is to create settings for 480T, and mark the 420T as being same fabric.

[marzoul]

Just like #1871

[hansfbaier]

@marzoul Thank you for the tipp. That really makes sense. I added a new PR here: #1908
And let's hope it works.

[hansfbaier]

@marzoul OK, that seemed to work! But now, when I run the fuzzer 005-tilegrid/generate_full.py for kintex 480t, I get an error with different offsets in the tilegrid for the following sites:
INT_R_X25Y226; orig offset 53, new 51
INT_L_X24Y226; orig offset 51, new 53
INT_L_X24Y226; orig offset 51, new 53
INT_L_X24Y227; orig offset 55, new 53
What do I need to do about those?

[marzoul]

@hansfbaier Sorry this is not an issue that I already faced.
But it might originate from unhandled or partially-handled things in columns that could result in wrong propagation of addresses...

[hansfbaier]

@marzoul Anyway, I was able to make it run using a hack. Now I have the first successful build!
Thanks to your help!
#1908
That means, if I want to build something for 420T, I just use the 480T chip database instead with nextpnr-xilinx?

[marzoul]

@hansfbaier To use the 420T, you will just indicate to nextpnr-xilinx that you target a 420T chip. Internally in nextpnr, this will be handled strictly like the 480T, except at the end the generated bistream will have the chip ID for 420T instead of 480T.