Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add XC7K420T/XC7K480T #1908

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

add XC7K420T/XC7K480T #1908

wants to merge 7 commits into from

Conversation

hansfbaier
Copy link
Collaborator

@hansfbaier hansfbaier commented Apr 17, 2022

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
Copy link
Collaborator Author

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

@hansfbaier hansfbaier mentioned this pull request Apr 18, 2022
@hansfbaier hansfbaier changed the title WIP add XC7K420T/XC7K480T add XC7K420T/XC7K480T Apr 18, 2022
@hansfbaier
Copy link
Collaborator Author

hansfbaier commented Apr 18, 2022

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

@hansfbaier
Copy link
Collaborator Author

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

@acomodi
Copy link
Contributor

acomodi commented Apr 19, 2022

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
Copy link
Collaborator Author

@acomodi License is still not working here.

@tmichalak
Copy link
Contributor

@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
Copy link
Collaborator Author

@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
Copy link
Contributor

kgugala commented Oct 24, 2022

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
Copy link
Contributor

kgugala commented Oct 25, 2022

@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
Copy link
Collaborator Author

hansfbaier commented Oct 25, 2022 via email

@kgugala
Copy link
Contributor

kgugala commented Oct 26, 2022

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
Copy link
Contributor

kgugala commented Oct 26, 2022

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
Copy link
Collaborator Author

hansfbaier commented Nov 4, 2022

@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
Copy link

image
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
Copy link
Collaborator Author

hansfbaier commented Jun 15, 2023

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
Copy link

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
image

logs_xc7k480tffg1156-2.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants