Need help for setting up xc7s50t #1789
Comments
|
@mithro Thanks, but I've yet to reach the fuzzing steps, I'm stuck at I'll try to manually write that And why is Vivado's version an issue in my case? 2017.2 does support |
|
Oops my bad, the contents of NOT: Notice the extra with the correct I'll proceed and continue to report my progress/issues in this thread. After so many stagnated trials to support Spartan-7, let's hope this time we can really get it done! |
|
I have an interest in this too, but a lack of time. I'll keep an eye on this and if somehow I can be of assistance I'll try to help out. |
|
Update: 000, 001, 005, 007 completed successfully. Do I just run 010- 101 sequentially or is there any order I should follow? The Guide says I should complete 000, 001, 005, 072, 073, 074, and 075 first, but |
|
Hi @MidsummerNight! The eval calls in the Makefile specify also the fuzzer's dependency. Take the following for instance: This runs the In general, the 072 to 075 are used to get general information on the device, for instance 074 dumps all the information regarding tiles and their connections, and generates the In theory you could directly run |
|
Update: 072, 073 completed successfully, while 074 failed as expected I'll try to figure out what wires to ignore tomorrow. I expect all fuzzers save for 051 should pass since I'm basically trying to replicate @MaksRawski's results with the latest Project X-Ray code at the moment. Thanks for the heads-up @acomodi ! Is 071 also used for general info on the device like 072 - 075 ? Am I right to think that 000 - 007 are preparation steps, 010 - 066 test different FPGA logic elements, and 071 - 075 extracts general info on the device? And where can I learn more about each fuzzer? Unfortunately I find the official documentation to be very vague for me. |
|
Update: 074 passed by following the guide, along with 075, 010~034. 034 requires 071 to be finished first. Will take a break with prjxray this weekend and continue next week. |
|
Update : 035~060 all completed successfully (as in having generated the Is this because Spartan-7 chips lack PCIe to start with? Also can anyone help me check if my spartan7_50.sh is correct? I don't know how should I set the values starting from Another question is I see |
|
I can't say if it's correct or not, but this is the script I used for the extraction run I did and it produced valid enough results, but could not get 100% coverage: export XRAY_DATABASE="spartan7"
export XRAY_PART="xc7s50csga324-1il"
export XRAY_ROI_FRAMES="0x00000000:0xffffffff"
# All CLB's in part, all BRAM's in part, all DSP's in part.
# tcl queries IOB => don't bother adding
export XRAY_ROI_TILEGRID="SLICE_X0Y0:SLICE_X65Y99 SLICE_X0Y100:SLICE_X57Y149 RAMB18_X0Y0:RAMB18_X1Y59 RAMB36_X0Y0:RAMB36_X1Y29 RAMB18_X2Y0:RAMB18_X2Y39 RAMB36_X2Y0:RAMB36_X2Y19 DSP48_X0Y0:DSP48_X1Y59"
export XRAY_EXCLUDE_ROI_TILEGRID=""
# These settings must remain in sync
export XRAY_ROI="SLICE_X0Y100:SLICE_X35Y149 RAMB18_X0Y40:RAMB18_X0Y59 RAMB36_X0Y20:RAMB36_X0Y29 DSP48_X0Y40:DSP48_X0Y59 IOB_X0Y0:IOB_X0Y49"
# Most of CMT X0Y2.
export XRAY_ROI_GRID_X1="10"
export XRAY_ROI_GRID_X2="58"
# Include VBRK / VTERM
export XRAY_ROI_GRID_Y1="0"
export XRAY_ROI_GRID_Y2="49"
export XRAY_PIN_06="R12"
export XRAY_PIN_05="V12"
export XRAY_PIN_04="U11"
export XRAY_PIN_03="T11"
export XRAY_PIN_02="R11"
export XRAY_PIN_01="T13"
export XRAY_PIN_00="T12"
source $(dirname ${BASH_SOURCE[0]})/../utils/environment.shI did not run 061 in my setup, because the Spartan7 does not have PCIe. |
|
(fwiw I also had no idea how to set the ROI frames, I think I just did some wild flailing around guesses until things seemed to work) |
|
@bunnie Could the reason be you're using And how did you check how valid your results are? My plan is to (assuming all fuzzers run well) run the SymbiFlow Architecture Definitions flow with all the xc7s50 data generated as its input, produce the chip's @acomodi @mithro @kgugala Can you help explain how to correctly setup the shell script and how to create the By the way, just for reference my |
|
I'm specifically using an So far I have not seen any failures in the results, and fwiw, the locations on the S7 basically line up with those or the Artix for this particular ROM implementation, so I have fairly high confidence in the outcome. My prjxray directory ate up 83G total, before I had sufficient coverage to extract the bits I needed. Like I said, the run didn't complete 100%, but it got far enough to map out the bits I needed, so I stopped running it. Like you, I had to migrate this off of a VM that I was running this in and move it to a dedicated box that we were using for CI of our designs, and it pretty much munched away for a couple days before getting the results we needed. |
|
It wouldn't be unusual for the prjxray to end up >100gb disk usage. |
|
@MidsummerNight With the work on the FPGA Interchange proceeding, I think that you might try that flow instead of going through SymbiFlow arch defs, which, as you say, might add too much overhead for your needs. You may look into https://github.com/SymbiFlow/fpga-interchange-tests, which is used to test the interchange format, for now using With the Interchange tests you would not need to worry as much for the RR graph and arch.timing.xml data generation as it is already present in the interchange device file provided by RapidWright. I think you just might need to provide the spartan7 device definition, similarly to what happens for the artix7, the board you want to test with, and enable the tests for that board (provided you put a valid XDC in the test directory with the same name as the board). The flow should take you down to the FASM generation from which you can potentially get a bitstream using the database containing the
|
|
@bunnie I see. My goal is to allow SymbiFlow to be able to generate bitstreams targeting Spartan-7 from user HDL designs, preferrably using the Yosys-VPR-FASM-Bitstream flow (which would require me to get the RR graph and arch.timing.xml) since it already supports a few Artix-7 parts, while @acomodi Thanks! I'll look into this Interchange thing. |
|
Update: 062, 063 failed, 065, 065b succeeded, 066 failed, 076, 100 and 101 succeeded. Things might slow down for a while as I figure out what to do with all the generated data. |
|
@MidsummerNight I believe that it is great progress. I suggest that you might soon put together a PR and let CI run all the fuzzers, so we have even more data on what is failing/succeeding and possibly help finding out what is happening. For what I see, all the failing fuzzers are not "critical" as they are for documenting features for advanced hard blocks, which are not relevant for initial simple designs. |
|
Update: Made a pull request. Hopefully this gets merged soon! |
|
A new prjxray-db was published with this initial spartan7 support @ https://github.com/SymbiFlow/prjxray-db/tree/master/spartan7 The HTMLified version can be found at https://symbiflow.github.io/prjxray-db/#database-for-spartan7 with the HTML rendered tile graph found at spartan7.
|
|
@mithro @acomodi Great! Now what should I do to improve Spartan-7 support? I see 2 tasks in my sight:
|
|
@MidsummerNight I believe that the "Relatively short term" task can be split in two: 2a. (Even shorter term) Try to get to place and route a design using the Interchange format which currently is supported by nextpnr and support to VPR is being added as well. You may make use of this repository which has a much simpler CMake structure. You may need to add some definition for the Spartan7 device, board and add it to a test. 2b. (Getting Spartan7 into symbiflow-examples) SymbiFlow-examples still relies on the At a first glance, the Spartan7 device seems pretty much similar to an Artix7 one, therefore it may just work out of the box. One difference I saw is for instance the absence of GTP hard blocks, which you may omit in the definition of the device.
|
|
@acomodi Okay I'll look into those. But what about the long term task? How can I make xc7s50's bitstream documentation more complete, or will it simply become more complete with the CI automatically running the fuzzers over and over again (which doesn't seem to be the case, as most of SymbiFlow/prjxray-db's data is quite old)? |
|
In general, the fuzzers are pretty stable at this point and they cannot discover missing bits. It is not a matter of computation time, but rather of fuzzer completeness. The usual strategy to understand how a db is complete is to increasingly test features, and understand how many missing bits are there. To do so, you can start with simple designs, use Vivado to place and route them, and than use the prjxray bit2fasm tool with the verbosity option enabled (if I recall correctly) and this will give you the amount of bits missing from the DB. Once you get some tests that do have some missing bits, the investigation part begins to understand what those correspond to and what fuzzer needs an update or to be written from scratch. |
|
So improve the fuzzers it is then. Thanks for the heads up! |
|
I'm closing this issue as |
|
@KKtiandao The interchange tests use the interchange python library that contains a FASM generator to output FASM out of the physical and logical netlist that are produced by the synthesis and place&route flow. The FASM file will than be used by the prjxray-tools to generate the bitstream.
The interchange support in VPR is currently being worked on. The interchange device data can be directly read into the internal VPR data structures, as well as the RR graph (the RR graph support is still in a PR at the moment). The idea of the Interchange is that it provides a common structure and definition on how to define an architecture and how to represent the synthesized and placed&routed netlists, so that different tools such as RapidWright, VPR or nextpnr can read and write the same data "interchangeably".
Yes, RapidWright outputs the interchange device data starting from the devices from the Xilinx database, which actually can also be accessible from Vivado. |
|
@acomodi Got it, Thanks! |
Hi, I'm trying to add support for xc7s50t to Project X-Ray. Naturally I refered to the Guide to adding a new device to an existing family and tried to pick up where #1534 left. However it seems that the Project X-Ray toolchain has changed quite a bit since #1534 and the guide is about how to add devices to existing families instead of adding new devices of new families, so I'm currently stuck at where I'm supposed to
make db-prepare-artix7. For context, I'm on Ubuntu 20.04.3 with Vivado 2017.2 installed and successfully ran Step 9 (the010-clb-initfuzzer) of the Getting Started section of Project X-Ray's documentations (ran./download-latest-db.shin Step 8) forartix7. A minor problem occured when runningmake envof Step 5 (see my comments on #1521 ) but that didn't prevent me from proceeding.Here's what I did after completing
010-clb-initforartix7:prjxray/settings. The content was mostly copied from/prjxray/settings/spartan7.shand/prjxray/settings/spartan7_50.shin thespartan7_50branch of @litghost'sprjxrayfork./prjxray/setting/spartan7.spartan7as a new argument to update_parts.py and update_resources.py in/prjxray/utils.Then in a new terminal, following the instructions in Guide to adding a new device to an existing family, I ran
make db-prepare-spartan7and got the following output:Which already looks wrong, compared to what
make db-prepare-artix7gave me:Then
source settings/spartan7.shreturned this:Because
prjxray/database/spartan7/mapping/parts.yamlcontains only{}and nothing else.Did I miss something? How should I solve this? Thanks!
The text was updated successfully, but these errors were encountered: