openXC7 / xc7k325t-blinky-nextpnr

BSD 3-Clause "New" or "Revised" License
42 stars 9 forks source link

Review of makefile and readme instructions for qmtech board #15

Closed somhi closed 2 years ago

somhi commented 2 years ago

I'm at step 20. Set XRAY_DIR to the path where Project Xray has been cloned and built

It took me a while to figure it out I still need to clone and build this https://github.com/SymbiFlow/prjxray Adding a link to the prjxray project would help beginners

Step 1 of prjxray tells me to install Vivado 2017.2!!!! Is it really true I need to install Vivado 2017.2 ?

It took me a long time to arrive to step 20 just to discover I need to install Vivado 2017.2. Please tell me it's not true!!

unbtorsten commented 2 years ago

Thank you for pointing clone+build of prjxray out. I will add it to the list. You will only need Vivado if you plan to run the fuzzers. Using prjxray-db does not require any Vivado installation. Oh, and yes, you would need version 2017.2, cf. SymbiFlow/prjxray#14

somhi commented 2 years ago

Thanks. Now is much more clear.

I'm having problems though following steps from prjxray documentation. step 6 and 7 fails as I don't have installed Vivado Step 8 is for downloading the chip database again ? Is this really needed?

somhi commented 2 years ago

Last step of Readme could be indicaded an example like: make BOARD=qmtech

I assume my Yosys install is too old (v 0.9) because is giving me command syntax errors

unbtorsten commented 2 years ago

I'm having problems though following steps from prjxray documentation. step 6 and 7 fails as I don't have installed Vivado

Right.. it's been a while since I set the system up on my end. Could you try following only steps until step 4 (and possibly downloading the latest db as indicated in step 8)? This may be sufficient.

Last step of Readme could be indicaded an example like: make BOARD=qmtech

@hansfbaier, can you add the corresponding line, please? I don't have a QMTech board at hand, so I would not be able to say what to do here.

I assume my Yosys install is too old (v 0.9)

Correct. I ran into issues with a Yosys 0.9 from Debian stable/bullseye as well. Things are fine if you make use of backports, download the project binaries or compile from source. The latter two options should provide you with Yosys 0.13+28 or higher. Those have worked fine for several of us here.

somhi commented 2 years ago

I finally generated the blinky.bit bitstream and it works!!!!

I installed Yosys 0.14+34

As I said I still not done the steps 6 and 8 of prjxray install instructions.
Step 7 is giving errors. Is command source settings/kintex7.sh needed to be executed each time before doing make ?

I did need also to modify makefile to make it work:

/bin/bash: 1: .: Can't open ~/bin/prjxray/utils/environment.sh this is where it stops make I modified line 32 to @. ~/bin/prjxray/utils/environment.sh and that is working

I also needed to add full path to lines 33 and 36 as it did not find binaries fasm2frames and xc7frames2bit

Ok, but the important thing is that I have a blinky working!!!!!

unbtorsten commented 2 years ago

@hansfbaier Looks like the $XRAY_DIR path variable is not yet used in the new Makefile?! The path is required for fasm2frames and xc7frames2bit

hansfbaier commented 2 years ago

@unbtorsten Yes, the XRAY_DIR variable is used. The PREFIX variable in the makefile was set to /opt instead of ~/opt, which might have been the source of the problem. Fixed.

hansfbaier commented 2 years ago

@somhi Can you confirm the changes work?

somhi commented 2 years ago

I'm working with bin instead of opt PREFIX = ~/bin this is what I had yesterday when I tested

As stated above the error I was having is: /bin/bash: 1: .: Can't open ~/bin/prjxray/utils/environment.sh

I modified line 32 to @. ~/bin/prjxray/utils/environment.sh and that is working which is strange because it's exaclty the same path

hansfbaier commented 2 years ago

@somhi It's because you have not cloned the prjxray repository in ~/bin If that is the case, then you must set XRAY_DIR to where you cloned it.

somhi commented 2 years ago

I did everything in bin instead of opt

rwhitby commented 2 years ago

@somhi if you change:

PREFIX ?= ~/opt

to

PREFIX ?= ${HOME}/opt

in the Makefile, that should fix your issue.

somhi commented 2 years ago

Ok, now my first error is solved with the PREFIX ?= ${HOME}/opt

Now I only have following errors. First errors are Ok as I have not installed Vivado I solved fasm2frames command not found modifying makefile like this, and same for xc7frames2bit:

${XRAY_DIR}/env/bin/fasm2frames ${XRAY_DIR}/build/tools/xc7frames2bit

/home/jordi/bin/prjxray/utils/vivado.sh: line 12: vivado: command not found
/home/jordi/bin/prjxray/utils/environment.sh: line 52: [: !=: unary operator expected
fasm2frames --part xc7k325tffg676-1 --db-root /home/jordi/bin/nextpnr/prjxray-db/kintex7 blinky.fasm > blinky.frames
/bin/bash: fasm2frames: command not found
make: *** [Makefile:35: blinky.frames] Error 127
jrrk2 commented 2 years ago

You can comment out the Vivado stuff. Fasm2frames may be found in the prjxray/env/bin directory after running make build in that project.

Sent from my iPhone

On 21 Feb 2022, at 18:53, somhi @.***> wrote:



Ok, now my first error is solved with the PREFIX ?= ${HOME}/opt

Now I only have following errors. First errors are Ok as I have not installed Vivado I solved fasm2frames command not found modifying makefile like this, and same for xc7frames2bit:

${XRAY_DIR}/env/bin/fasm2frames ${XRAY_DIR}/build/tools/xc7frames2bit

/home/jordi/bin/prjxray/utils/vivado.sh: line 12: vivado: command not found /home/jordi/bin/prjxray/utils/environment.sh: line 52: [: !=: unary operator expected fasm2frames --part xc7k325tffg676-1 --db-root /home/jordi/bin/nextpnr/prjxray-db/kintex7 blinky.fasm > blinky.frames /bin/bash: fasm2frames: command not found make: *** [Makefile:35: blinky.frames] Error 127

— Reply to this email directly, view it on GitHubhttps://github.com/kintex-chatter/xc7k325t-blinky-nextpnr/issues/15#issuecomment-1047152247, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE6VVM5UO3AF4D3GSJXNJC3U4KCZBANCNFSM5OHFC73Q. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.Message ID: @.***>

unbtorsten commented 2 years ago

Amending the makefile as mentioned

${XRAY_DIR}/env/bin/fasm2frames ${XRAY_DIR}/build/tools/xc7frames2bit

is the way to do it. Unfortunately, this part was lost during the transition from the initial makeit.sh to a Makefile that the latest commit offers. This is already worked on and will be resolved soon, cf. https://github.com/rwhitby/xc7k325t-blinky-nextpnr/pull/1

unbtorsten commented 2 years ago

@rwhitby Another hint for you as you adapt the Makefile: the custom nextpnr-xilinx is not put on the path at this time and needs to be adapted as well. In summary, changing the fasm/frames/bit sections of the Makefile as follows works for me:

${PROJECT_NAME}.fasm: ${PROJECT_NAME}.json
    ${PREFIX}/nextpnr/bin/nextpnr-xilinx --chipdb ${CHIPDB_DIR}/${PART}.bin --xdc ${PROJECT_NAME}-${BOARD}.xdc --json $< --write ${PROJECT_NAME}_routed.json --fasm $@ --verbose --debug

${PROJECT_NAME}.frames: ${PROJECT_NAME}.fasm
    ${XRAY_DIR}/env/bin/fasm2frames --part ${PART} --db-root ${DB_DIR}/kintex7 $< > $@

${PROJECT_NAME}.bit: ${PROJECT_NAME}.frames
    ${XRAY_DIR}/build/tools/xc7frames2bit --part_file ${DB_DIR}/kintex7/${PART}/part.yaml --part_name ${PART} --frm_file $< --output_file $@
rwhitby commented 2 years ago

Since we are setting NEXTPNR_DIR and XRAY_DIR explicitly in the Makefile, I wonder whether the sourcing of environment.sh (which is causing issues due to the "optional" dependency on Vivado, which is what we are all here to get away from) is really needed. In any case, sourcing on one line and then expecting the results of the source to be available on a separate line in a Makefile simply does not work - each line is an independent invocation of the shell.

unbtorsten commented 2 years ago

In any case, sourcing on one line and then expecting the results of the source to be available on a separate line in a Makefile simply does not work - each line is an independent invocation of the shell.

Sounds like we can disregard those lines altogether then. Make process runs smoothly for me without them affecting the following line, respectively.

Update: I can explicitly confirm a successful build and upload of the bitstream after removing the lines mentioned above. I have updated the Makefile excerpt above accordingly.