Skip to content
This repository has been archived by the owner on Mar 9, 2023. It is now read-only.

Review of makefile and readme instructions for qmtech board #15

Closed
somhi opened this issue Feb 12, 2022 · 18 comments · Fixed by #17
Closed

Review of makefile and readme instructions for qmtech board #15

somhi opened this issue Feb 12, 2022 · 18 comments · Fixed by #17
Labels
documentation Improvements or additions to documentation

Comments

@somhi
Copy link

somhi commented Feb 12, 2022

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

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. f4pga/prjxray#14

@somhi
Copy link
Author

somhi commented Feb 12, 2022

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

somhi commented Feb 12, 2022

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

unbtorsten commented Feb 12, 2022

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

somhi commented Feb 12, 2022

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 added a commit that referenced this issue Feb 12, 2022
update based on input from #15
@unbtorsten
Copy link
Contributor

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

@unbtorsten unbtorsten changed the title clarify step 20. Set XRAY_DIR to the path where Project Xray has been cloned and built Review of makefile and readme instructions for qmtech board Feb 12, 2022
@unbtorsten unbtorsten reopened this Feb 12, 2022
@hansfbaier
Copy link
Collaborator

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

@somhi Can you confirm the changes work?

@somhi
Copy link
Author

somhi commented Feb 13, 2022

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

hansfbaier commented Feb 13, 2022

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

somhi commented Feb 14, 2022

I did everything in bin instead of opt

@unbtorsten unbtorsten added the documentation Improvements or additions to documentation label Feb 18, 2022
@rwhitby
Copy link
Contributor

rwhitby commented Feb 20, 2022

@somhi if you change:

PREFIX ?= ~/opt

to

PREFIX ?= ${HOME}/opt

in the Makefile, that should fix your issue.

@somhi
Copy link
Author

somhi commented Feb 21, 2022

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

jrrk2 commented Feb 21, 2022 via email

@unbtorsten
Copy link
Contributor

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. rwhitby#1

@unbtorsten
Copy link
Contributor

unbtorsten commented Feb 22, 2022

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

rwhitby commented Feb 22, 2022

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

unbtorsten commented Feb 22, 2022

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants