add XC7K420T/XC7K480T

[hansfbaier]

420Ts are available quite affordably probably from retired mining hardware.
So it is a very compelling part to support.
Also they have no high speed banks like all the smaller FPGAs of the series,
(they have transceivers instead), so making them actually the easiest to support from the kintex series.

[hansfbaier]

@acomodi Also db-prepare does not contain non-Webpack parts here

[hansfbaier]

@acomodi @mithro removing the WIP from the title, because I was able to run a successful build today!
Please review and merge!

[hansfbaier]

I think for review especially this commit might need some attention: a5ee3b6

[acomodi]

Hi @hansfbaier, thanks for all the contributions.

The Xilinx server license addition was added here, but with the transition to GH actions this was probably not integrated. I am not quite sure how to get the tunnel key that was used in kokoro, but once that is present as a GH secret we "might" be able to restore the connection to the server license from the GH actions runs. cc @mithro.

Regarding commit a5ee3b6, I am not quite sure why those INT tiles do have a wrong offset. Those seem to be located in a quite "regular" place, where there should be no special tiles that might affect the overall offset calculation for some blocks.

It may be helpful to understand what steps of the tile grid generation causes this error (if no workaround is present) are executed and have an execution traceback, at least to get an idea of where the bug, if any, might be.

[hansfbaier]

@acomodi License is still not working here.

[tmichalak]

@hansfbaier I see that there is an assertion in the kintex7 CI job. Did it work locally for you? Maybe you forgot to push something.

[hansfbaier]

@hansfbaier I see that there is an assertion in the kintex7 CI job. Did it work locally for you? Maybe you forgot to push something.

@tmichalak That error message just means that the Vivado license is not working.

[kgugala]

The license is there, it looks like the Vivado version available in the CI does not support the part. I'm updating the tool. Once this is done I'll restart the checks in this PR

[kgugala]

@hansfbaier I've bumped the tools and landed #1918. This PR has to be rebased on top of that to be able to use updated tool and access the license server.
Can you do this? If not I can rebase the PR (looks like I should be able to push to your branch)

[hansfbaier]

Hi Karol, many thanks for the changes, I will rebase as soon as I am done with my day job. Best regards, Hans

…

On Tue, Oct 25, 2022, 14:06 Karol Gugala ***@***.***> wrote: @hansfbaier <https://github.com/hansfbaier> I've bumped the tools and landed #1918 <#1918>. This PR has to be rebased on top of that to be able to use updated tool and access the license server. Can you do this? If not I can rebase the PR (looks like I should be able to push to your branch) — Reply to this email directly, view it on GitHub <#1908 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABEI75OP2457GHGG722TWDWE6BI5ANCNFSM5TUKBHSQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kgugala]

ehh, looks like we got hit by concurrent license limit of 10. One option here is to limit the run for bigger parts to -j10. I will certainly increase the runtime above 6h (so we need to change the default timeout)

[kgugala]

or even simpler - since we call Vivado with this wrapper https://github.com/f4pga/prjxray/blob/master/utils/vivado.sh, we can extend it to check if a license is available and wait until it is. Still, we'll need to extend the timeout for the whole CI.

[hansfbaier]

@kgugala @tmichalak @mithro There still are issues with the license server:

2022-10-25T10:56:38.0473964Z 10:56:38 | 2022-10-25T10:56:38 - xc7k480tffg1156-2/001-part-yaml             -    8s: ERROR: [Common 17-345] A valid license was not found for feature 'Synthesis' and/or device 'xc7k480t-ffg1156'. Please run the Vivado License
 Manager for assistance in determining
2022-10-25T10:56:38.0474755Z 10:56:38 | 2022-10-25T10:56:38 - xc7k480tffg1156-2/001-part-yaml             -    8s: which features and devices are licensed for your system.
2022-10-25T10:56:38.0475916Z 10:56:38 | 2022-10-25T10:56:38 - xc7k480tffg1156-2/001-part-yaml             -    8s: Resolution: Check the status of your licenses in the Vivado License Manager. For debug help search Xilinx Support for "Licensing FAQ". 
2022-10-25T10:56:38.0477300Z 10:56:38 | 2022-10-25T10:56:38 - xc7k480tffg1156-2/001-part-yaml             -    8s: make[4]: *** [../../Makefile.specimen:5: design.perframecrc.bit] Error 1
2022-10-25T10:56:38.0478600Z 10:56:38 | 2022-10-25T10:56:38 - xc7k480tffg1156-2/001-part-yaml             -    8s: make[3]: *** [Makefile:21: build_xc7k480tffg1156-2/specimen_001] Error 2
2022-10-25T10:56:38.0479753Z 10:56:38 | 2022-10-25T10:56:38 - xc7k480tffg1156-2/001-part-yaml             -    8s: make[2]: *** [Makefile:31: run] Error 2
2022-10-25T10:56:38.0480739Z 10:56:38 | 2022-10-25T10:56:38 - xc7k480tffg1156-2/001-part-yaml             -    8s: 

[ghyghy123]

Hello, when I was running xc7k420t, there was an error as shown in the figure, and the problem looks like 072 ordered_ wires, have you encountered similar issues before? Is there any solution?

[hansfbaier]

That doesn't show the real error. You would have to scroll further back, or better, look in the logfile in the build directory of the fuzzer. Or even easier, use the database from openXC7.
https://github.com/openXC7/db-workspace-for-kintex7

[ghyghy123]

That doesn't show the real error. You would have to scroll further back, or better, look in the logfile in the build directory of the fuzzer. Or even easier, use the database from openXC7. https://github.com/openXC7/db-workspace-for-kintex7

Hello, I have reviewed the logs according to your suggestion, as shown in the figure below. It seems that there is a problem with the return value. Do you have any solution? The log file is attached


logs_xc7k480tffg1156-2.zip