Good morning
While waiting for the HW to arrive I was trying to get up to speed with the currently available SW.
I have downloaded Quartus II from Altera, the web edition and installed on a Kubuntu 12.04 machine.
Got the current SW version grom GIT using git clone https://github.com/Nuand/bladeRF.git
Quartus starts, managed to open the Qsys part and compile it (it does says that it needs to update domponents)
When I go to import the project into the Eclipse NIOS II develepment I am stuck since I cannot follow the part of instructions that say
"Browse to checkout root directory -> check both lms_spi_controller and lms_spi_controller_bsp"
I did try to do a find for the given names but I cannot find something that can later be imported into eclipse.
Am I missing something ?
Thanks, Damiano
Quartus II v.13 and FPGA code compilation
-
- Posts: 15
- Joined: Fri Mar 01, 2013 11:28 am
Re: Quartus II v.13 and FPGA code compilation
Example is hard link to files (in many parts of nios).
Change on its way to the file and it will work
Change on its way to the file and it will work
-
- Posts: 13
- Joined: Sat Jun 01, 2013 3:20 am
Re: Quartus II v.13 and FPGA code compilation
Hello everybody
I just updated the bladerf SW doing a fresh git clone and I have a problem with Qsys now.
Let me remind you that I am on Kubuntu 12.4 with Quartus II 13.0
Attached there is the error that Qsys is telling me.
Any help or suggestion is appreciated...
Thanks
I just updated the bladerf SW doing a fresh git clone and I have a problem with Qsys now.
Let me remind you that I am on Kubuntu 12.4 with Quartus II 13.0
Attached there is the error that Qsys is telling me.
Any help or suggestion is appreciated...
Thanks
-
- Posts: 303
- Joined: Mon Mar 04, 2013 4:53 pm
Re: Quartus II v.13 and FPGA code compilation
There seem to be some things afoot. I accidentally called the device an I2C master, but it's really an Avalon MM slave on the bus - it only masters the I2C. We will make that change in a commit this weekend.
I used 12.1 to create this, but this picture shows it open in 13.0 on my machine. Somehow it looks like we have some slight differences? Did you create your own component for it? The way mine looks is attached and is defined in the fpga/ip/opencores/i2c/qsys directory.
I used 12.1 to create this, but this picture shows it open in 13.0 on my machine. Somehow it looks like we have some slight differences? Did you create your own component for it? The way mine looks is attached and is defined in the fpga/ip/opencores/i2c/qsys directory.
-
- Posts: 13
- Joined: Sat Jun 01, 2013 3:20 am
Re: Quartus II v.13 and FPGA code compilation
I deleted the bladeF directory and did a git clone again
Started QUartus II, open quartus project as defined in the README
Started Qsys and opened the file in the readme, this is qhat I get, maybe I should reinstall Quartus ?
Started QUartus II, open quartus project as defined in the README
Started Qsys and opened the file in the readme, this is qhat I get, maybe I should reinstall Quartus ?
-
- Posts: 13
- Joined: Sat Jun 01, 2013 3:20 am
Re: Quartus II v.13 and FPGA code compilation
I am still waiting for quartus 12.1 download, in the meantime I managed to reinstall and play with the 13.0 version
Fixed the missing connections on i2c and managed to create a sample application for the given NIOS2
Atached a couple of screenshot
Fixed the missing connections on i2c and managed to create a sample application for the given NIOS2
Atached a couple of screenshot
-
- Posts: 13
- Joined: Sat Jun 01, 2013 3:20 am
Re: Quartus II v.13 and FPGA code compilation
While digging for the issue I am having I found out that there are absolute paths in the project
damiano@damiano-BM5242:~/work/altera/bladeRF$ grep -r "z:" hdl
Binary file hdl/fpga/ip/opencores/i2c/doc/i2c_specs.pdf matches
Binary file hdl/fpga/ip/opencores/i2c/doc/src/I2C_specs.doc matches
hdl/quartus/bladerf.qsf:set_global_assignment -name SEARCH_PATH "z:\\work\\nuandrelease\\release\\hdl\\fpga\\ip\\altera\\nios_system\\nios_system\\synthesis\\submodules"
hdl/quartus/bladerf.qsf:set_global_assignment -name SEARCH_PATH "z:\\work\\nuandrelease\\release\\hdl\\fpga\\ip\\altera\\nios_system\\nios_system\\synthesis"
hdl/quartus/bladerf.qsf:set_global_assignment -name SEARCH_PATH "z:\\work\\nuandrelease\\release\\hdl\\fpga\\ip\\opencores\\i2c\\rtl\\vhdl"
hdl/quartus/bladerf.qsf:set_global_assignment -name SEARCH_PATH "z:\\work\\nuandrelease\\release\\hdl\\fpga\\ip\\opencores\\i2c"
hdl/quartus/bladerf.qsf:set_global_assignment -name SEARCH_PATH "z:\\work\\nuandrelease\\release\\hdl\\fpga\\ip\\opencores\\i2c\\qsys"
The above is from a fresh git clone and it is surely an issue for anybody that is not on a windows machine or does not have a mapped Z: drive
I hope it can be easily fixed, thanks !
damiano@damiano-BM5242:~/work/altera/bladeRF$ grep -r "z:" hdl
Binary file hdl/fpga/ip/opencores/i2c/doc/i2c_specs.pdf matches
Binary file hdl/fpga/ip/opencores/i2c/doc/src/I2C_specs.doc matches
hdl/quartus/bladerf.qsf:set_global_assignment -name SEARCH_PATH "z:\\work\\nuandrelease\\release\\hdl\\fpga\\ip\\altera\\nios_system\\nios_system\\synthesis\\submodules"
hdl/quartus/bladerf.qsf:set_global_assignment -name SEARCH_PATH "z:\\work\\nuandrelease\\release\\hdl\\fpga\\ip\\altera\\nios_system\\nios_system\\synthesis"
hdl/quartus/bladerf.qsf:set_global_assignment -name SEARCH_PATH "z:\\work\\nuandrelease\\release\\hdl\\fpga\\ip\\opencores\\i2c\\rtl\\vhdl"
hdl/quartus/bladerf.qsf:set_global_assignment -name SEARCH_PATH "z:\\work\\nuandrelease\\release\\hdl\\fpga\\ip\\opencores\\i2c"
hdl/quartus/bladerf.qsf:set_global_assignment -name SEARCH_PATH "z:\\work\\nuandrelease\\release\\hdl\\fpga\\ip\\opencores\\i2c\\qsys"
The above is from a fresh git clone and it is surely an issue for anybody that is not on a windows machine or does not have a mapped Z: drive
I hope it can be easily fixed, thanks !
-
- Posts: 303
- Joined: Mon Mar 04, 2013 4:53 pm
Re: Quartus II v.13 and FPGA code compilation
Yeah, I noticed that as well. The current build scripts in the repository rebuild the project every time using local absolute paths. The process for building the FPGA will be something like this:
The first script will build a Quartus project with multiple revisions - hosted, headless, etc. This is for ease of development for people who want to modify the guts of the FPGA. The main top level interface doesn't change much while the insides do change, which is where Altera's Revisions comes in handy.
The size option is for people who are targeting the x40 or x115.
We're still in the process of wrapping the binary images in a little wrapper so that we can do some sanity checks on the file before we re-flash the hardware.
Code: Select all
$ cd hdl/quartus
$ mkdir work
$ cd work
$ quartus_sh -t ../bladerf.tcl
$ quartus_sh -t ../build.tcl -rev hosted -size 40
The size option is for people who are targeting the x40 or x115.
We're still in the process of wrapping the binary images in a little wrapper so that we can do some sanity checks on the file before we re-flash the hardware.
-
- Posts: 3
- Joined: Fri Mar 01, 2013 8:20 am
Re: Quartus II v.13 and FPGA code compilation
I've been having path issues as well Windows 7 x64). Like the OP, I did a git clone and tried Quartus 13.0 first then 12.1 when that failed. I was also able to fix the wiring issues in 13, but couldn't get the design to compile in either version. In the mean time I'll play around with writing programs for the NIOSII target.
I'll wait for git to be updated then try this process again.
I'll wait for git to be updated then try this process again.
-
- Posts: 303
- Joined: Mon Mar 04, 2013 4:53 pm
Re: Quartus II v.13 and FPGA code compilation
Have you tried using the commandline to build? If it bombs out, can you pastebin or post the reports to here?
-
- Posts: 13
- Joined: Sat Jun 01, 2013 3:20 am
Re: Quartus II v.13 and FPGA code compilation
I wish to share what works for me, no real testing on the result, yet...
- I use quartus 13, it is much more updated on Linux and seems ok
- Bladerf is on quartus 12.1 and so all components needs to be updated, when you start Qsys and open the project thay will be updated
This will result in an "nconnected" bits in i2c master since apparently the original opencore one is not compatible with the alter one.
Click on the unconnected pins and connect them to reset and data source
Also use tools and remove dangling connections
Generate the Qsys project
- Now back on Quartus, the default bladerf goes nowhere, select another file eg: fsk_modulaor and make it a top level entity
You can now generate that and as far as I know it produces something (with tons of warnings....)
- On the Eclipse side, the best thing I have found so far is to create a new "bsb and simple project" and then copy paste the original code.
This seems for me the only way to geneate a "clean" BSP that actually works.
I understand that is is more solid to generate things using tcl, however, the GUI is needed to actually manage the project and make sense of the whole structure.
(yes, if you are advanced wizard you probably are faster using the tcl scripts, but we are not all advanced wizards, we are willing to become one
All in all I wish that Quartus 13 will be used in the future or alternatively, when I have a board I can share my version of the project on quartus 13
(this means I wish to contribute to the project, not that I wish to split/fork it)
Have a nice weekend you all
- I use quartus 13, it is much more updated on Linux and seems ok
- Bladerf is on quartus 12.1 and so all components needs to be updated, when you start Qsys and open the project thay will be updated
This will result in an "nconnected" bits in i2c master since apparently the original opencore one is not compatible with the alter one.
Click on the unconnected pins and connect them to reset and data source
Also use tools and remove dangling connections
Generate the Qsys project
- Now back on Quartus, the default bladerf goes nowhere, select another file eg: fsk_modulaor and make it a top level entity
You can now generate that and as far as I know it produces something (with tons of warnings....)
- On the Eclipse side, the best thing I have found so far is to create a new "bsb and simple project" and then copy paste the original code.
This seems for me the only way to geneate a "clean" BSP that actually works.
I understand that is is more solid to generate things using tcl, however, the GUI is needed to actually manage the project and make sense of the whole structure.
(yes, if you are advanced wizard you probably are faster using the tcl scripts, but we are not all advanced wizards, we are willing to become one
All in all I wish that Quartus 13 will be used in the future or alternatively, when I have a board I can share my version of the project on quartus 13
(this means I wish to contribute to the project, not that I wish to split/fork it)
Have a nice weekend you all
-
- Posts: 13
- Joined: Sat Jun 01, 2013 3:20 am
Re: Quartus II v.13 and FPGA code compilation
I finally have a board to play with, managed to have it running with osmocom_fft and to display some meaningful data for a 868 transmiter that I have.
Next step is to actually have some understanding of the FPGA development..
I am kindly asking for nuand to provide the schematics of the FPGA extension board, I bought one and the first experiment is to actually be able to interact with some simple IO.
(USB programming cable is in transit, that should make reprogramming much faster, although there should be a way to go from the altera generated file to the down-loadable one)
The next question that will benefit everybody is related to the current building mechanism.
First of all, I did try to use it with quartus II version 13.1 (yes there is an update to version 13) but no "revisions" appears in the gui after the script is run and the compilation does not complete.
(yes, I did change dash to bash link)
Second: as far as I understand the only "import" needed to create a new "project" is the one of the pin planner, all the rest is "optional" and really, pin plan is not something that can change.
(the point being that the exported csv of the pin planner is the common denominator of all projects)
The question: Is it possible, logical to have an easier to understand quartus II 13.1 project that has only the "hosted" version ?
I am willing to herald it, meaning actually get it to work and share it, if any of the leaders say it is actually doable and worthy of interest.
Any comments ?
Next step is to actually have some understanding of the FPGA development..
I am kindly asking for nuand to provide the schematics of the FPGA extension board, I bought one and the first experiment is to actually be able to interact with some simple IO.
(USB programming cable is in transit, that should make reprogramming much faster, although there should be a way to go from the altera generated file to the down-loadable one)
The next question that will benefit everybody is related to the current building mechanism.
First of all, I did try to use it with quartus II version 13.1 (yes there is an update to version 13) but no "revisions" appears in the gui after the script is run and the compilation does not complete.
(yes, I did change dash to bash link)
Second: as far as I understand the only "import" needed to create a new "project" is the one of the pin planner, all the rest is "optional" and really, pin plan is not something that can change.
(the point being that the exported csv of the pin planner is the common denominator of all projects)
The question: Is it possible, logical to have an easier to understand quartus II 13.1 project that has only the "hosted" version ?
I am willing to herald it, meaning actually get it to work and share it, if any of the leaders say it is actually doable and worthy of interest.
Any comments ?
-
- Posts: 62
- Joined: Fri Mar 01, 2013 3:58 am
- Location: Silicon Valley
- Contact:
-
- Posts: 13
- Joined: Sat Jun 01, 2013 3:20 am
Re: Quartus II v.13 and FPGA code compilation
Hello all
I may be wrong, but I believe that the schematics of the GPIO expansion board has the numbering of the connector flipped.
Meaning that the odd numbered pins are really the even numbers
Attached an image with some scribbling showing the number change.
Can anybody please verify and let us know ?
Thanks
I may be wrong, but I believe that the schematics of the GPIO expansion board has the numbering of the connector flipped.
Meaning that the odd numbered pins are really the even numbers
Attached an image with some scribbling showing the number change.
Can anybody please verify and let us know ?
Thanks
-
- Posts: 13
- Joined: Sat Jun 01, 2013 3:20 am
Re: Quartus II v.13 and FPGA code compilation
Hello all
I think I am the only one willing to play with quartus II 13.1, at least for now
For any of you willing to help this is what I discovered so far.
1) the script bladerf.tcl is in theory in charge of creating the project and the revisions, as far as I can tell it does not work with quartus 13.1 on linux
meaning that the various revisions do not appear on the revision navigator in quartus, and project compilation fails in any case due to issues on upgrading nios component (i2c master)
What I am trying to do is to dig up in the config files and import the pieces that make up the hosted revision
I am however puzzled on why revisions are created by a tcl script instead of being part of the project from the beginning.
Maybe the FPGA wizards can explain this choice ?
Congratulation for the whole project, it is surely a complicated thing !!
I think I am the only one willing to play with quartus II 13.1, at least for now
For any of you willing to help this is what I discovered so far.
1) the script bladerf.tcl is in theory in charge of creating the project and the revisions, as far as I can tell it does not work with quartus 13.1 on linux
meaning that the various revisions do not appear on the revision navigator in quartus, and project compilation fails in any case due to issues on upgrading nios component (i2c master)
What I am trying to do is to dig up in the config files and import the pieces that make up the hosted revision
I am however puzzled on why revisions are created by a tcl script instead of being part of the project from the beginning.
Maybe the FPGA wizards can explain this choice ?
Congratulation for the whole project, it is surely a complicated thing !!