Kintex7 xc7k325 support #1794
Kintex7 xc7k325 support #1794
Conversation
|
@kgugala Who should review this? |
|
The build failed, but a necessary step: 'make db-prepare-kintex7' |
|
I believe that |
|
Actually maybe I'm wrong... |
|
|
|
This is what I get running locally: Perhaps there is a problem getting the license for non-webpack parts ? |
|
The CI system only currently has access to WebPack parts. |
|
Is the |
|
Looks like only |
|
Perhaps we need two X-Ray databases, one that can be generated from WebPack, another (for larger parts) that has to be generated by owners of suitable boards (that come with an unlimited number of node-locked and device-locked threads). Another way would be to affiliate with an academic institution that has access to bulk licenses. Meanwhile, I will try and get a bitstream running on a real board to see if we have something usable. |
|
I committed my new database here (https://github.com/jrrk2/prjxray-db/tree/k325). I suppose that means that eventually anybody can use this part license-free.
|
|
jrrk2 makes a good point here; for example, the 7k325t and 7k420t dev kits are actually cheaper on aliexpress than the 7k160t. I suspect this because the larger parts are more popular in the supply chain, and 160t can fetch a higher price as the latest webpack can be used. Using these parts without a vivado license is actually a major reason I am interested in the open source FPGA tooling. |
|
Furthermore the 7k325t part is used in the frequently encountered KC705 board from Xilinx and the Genesys2 board from Diligent. The latter comes with a Vivado node/device-locked license which may be used to generate the open-source database. |
|
I'm very close to being able to access our license server on our Kokoro system. |
|
Thanks for the heads-up but this will not take us much further forward unless support is added for kintex7 in the symbiflow-arch-defs repo. I'm not familiar with CMake config files nor can I find any documentation on how to do this. In addition the Python support seems to be Ubuntu/Debian specific. I tried it on Fedora-35 and it didn't work. |
|
@jrrk2 Did you log a bug about it not working on Fedora-35 somewhere? |
|
@jrrk2 - @acomodi was providing some guidance for the Spartan 7 part @ #1789 (comment) |
|
Kintex 7 failed really fast. First |
|
Could the change to https://github.com/SymbiFlow/prjxray/pull/1794/files#diff-2aea961e96499d96f980a17a1110978f3bf66bcc1e4ec1e772aaec71f6932614 be breaking the
|
|
I'm a little unclear here, but it seems like the |
|
(FYI - I sent #1811 to be a bit clearer about this section of the Makefile.) |
|
Perhaps this anomaly would be explained by the DSP location limits being wrong in the environment configuration file ? |
|
In order to test if the DSP fuzzer really is broken on Kintex7 (apart from the new part addition), I created #1816 |
|
As #1811 was passing, it has been merged. I rebased this pull request onto the merge and are now rerunning the CI to see if we still get the |
|
With the current limited set of changes, I don't see any reason that this change should affect the runs for the |
|
Signed-off-by: Jonathan Kimmitt <jonathan@kimmitt.uk> Signed-off-by: Tim 'mithro' Ansell <tansell@google.com>
|
The Kintex 325T support isn't really experimental anymore and has proven to work quite reliably. |
|
I don’t have that hardware any more but if there is anything I can do ? |
|
@jrrk2 Could you change the title (remove 'experimental') |
|
@jrrk2 Thanks! |
I followed the guide to add new parts, more or less, some experimental features had to be commented out. No validation on real hardware has been done, this is just to establish if the pull request changes can run