Why the kintex7'dbs exist in prjxray-db but the symbiflow can't use k7's device? #1780
Comments
|
There are couple answers to your questions, but the first part is the easiest. The reason no kintex7 parts are in symbiflow-arch-defs is those parts were not the initial targets. The Digilent boards we've been using as platforms are mostly artix7 and zynq7 parts, so that is where initial support was added and tested. You pointed out correctly that the IOB18 is not currently supported, and that is primarily because IOB18 fuzzing is not in place in prjxray! So in terms of adding k7 support, you can totally help us move this along! Steps you can follow to help!
Once a blinky example is stood up, you could try more complicated designs. If you are interested, please let us know! |
|
The Digilent Genesys 2 board would be an excellent first target for Kintex 7 support. The Xilinx Kintex-7 FPGA KC705 Evaluation Kit would be another good default option to start Kintex 7 work on. |
One downside of Genesys2 is that I believe it isn't part of WebPack? |
|
BTW - The Digilent Genesys 2 board is $999 USD and the KC705 is $1,695 USD. I don't know of any super cheap Kintex-7 boards, but the Numato Skoll board could potentially work? |
I noticed that the steps you offered were all involved in prjxray(minitests and fuzzers). Did it mean that adding Kintex7 part into symbiflow only need a complete Kintex 7 database. Do the xml files used by vpr need to be modified to adapt to Kintex7(eg. iob18)? |
|
@the-centry - There is no point trying to add xml files to symbiflow-arch-defs until Project X-Ray supports them first. |
If I wanna try whether Kintex7's db could be used in symbiflow firstly, could symbiflow run with the current Kintex7's db? |
It is possible. However, I definitely recommend you make a minitest to prove it to yourself. This is an easy step, and will give you confidence in the current state of the database. |
|
@litghost @mithro |
|
So that doesn't look too bad. As expected, there are some missing bits that will need to be investigated. Based on past experience, most of those are bits are likely from the IO tiles, but you'd need to confirm. What did you do with the IOB18 tiles? If you only copied the segbits, that wouldn't be enough. You need to update |
Yea,Through the tilegrid.json genereted by 005,I found that the base addressess of IOB18 exist,but the IOI18 you mentioned did't exist and it maybe is IOI in tilegrid.json.In my mind, it maybe the problem of 030,because I only changed the 030 to generate IOB18's segbits_iob18.db.Whether the problem is the incomplete of the segbits_iob18.db generated by 030.The second question is that whether I could use this database to run symbiflow and then complets the dababase little by little. |
Please create a PR with your initial changes. It sounds like a good start, and something that can be built on.
You would need to do some analysis to determine where the missing bits are. If all of the missing bits are in the IO columns to the left and right of the chip, then you could potential create an ROI that excludes the IO columns. Creating an ROI is somewhat fragile, and we've pretty much deprecated support for ROI's that have unknown bits in them. However you could recreate some of that to support your use case. My strong recommendation is to first get your test design fully decoding before you attempt to stand up arch-defs. This is not required, but will make it much easier to debug what is going on if designs output from arch-defs are not working. |
OK!Thanks so much! |
I noticed that an roi parameter(design.json) is used when creating synth_tiles.json. Should I create a design.json, if I want to create an ROI? |
|
Logic for building the harness is located at:https://github.com/SymbiFlow/prjxray/tree/master/minitests/roi_harness
|
When I tried to generate a design.json for kintex7 through minitest, I found that void wires appeared, such as follows:
|
|
@the-centry hi, have you added iob1.8 and ioi for k7 sucessfully? I saw EXCLUDE_ROI is null in kintex7.sh. |
|
Hopefully interesting links;
|
|
@the-centry I started implementing an IOB18-fuzzer and we already (with manual hacks) got a blinky (button on IOB18 -> LED on IOB33) running. See this pull request: f4pga/prjxray#1867 |
|
I'm not sure why this issue was closed since k7 devices are still not part of the arch-defs yet. I'm new to this flow, so it's hard to understand how I might do this myself. |
|
You can use the openXC7 toolchain for Kintex. |
According to my tried, there were some wrong data in the timing data and bells.json. And it seems that this flow has been abandoned, scholars research on nextpnr. |
Such a greate work, I am soory for getting the information so late! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I found that the kintex7'dbs exist in prjxray-db,however symbiflow's cmakelist didn't use kintex7? whether the reason is the loss of primitives in some IP source such as iob18(in the dir of xc/common/primitives),or the incompleteness of the K7’ database. Or some other reasons?
The text was updated successfully, but these errors were encountered: