Official bladeRF forum

Hello, All

I'm starting to use BladeRF Small REV2 (FPGA Cyclone IV EP4CE40, 40 kLE) with VHDL in Windows 7.
My task is output I/Q examples to the U74 connector (header).

At first step I try to create a bitstream of the FPGA (.rbf file).
For this, I study the "Tutorial: Blinking some LEDs" (https://github.com/Nuand/bladeRF/wiki/F ... nsmit_side) and I try to repeat it
exactly to create a new FPGA image from the source. I use Altera's IDE QuartusII 11.0sp1 Web Edition, because I have 32-bit computer (Lenovo SL510). The Quartus Prime, which is recomended by Nuand, I can not use, becouse it requires a 64-bit computer.

I run [quartus install directory]/nios2eds/nios2_command_shell.sh to get into the appropriate Quartus II environment. From the same terminal, I go to the bladeRF/hdl/quartus directory and run build_bladerf.sh in souch manner:

./build_bladerf.sh -r hosted -s 40


But answer is:

"Could not find Quartus version file"

What is the problem? Why I can't create the FPGA-bitstream?
Can I use for my task QuartusII 11.0sp1 Web Edition?
Is it possible to install any version of Quartus Prime on a 32-bit computer?
How can I output I/Q examples to the U74 connector (header) in the simplest way?


Thanks,
Dmitry_K

P.S. The Nios2_command_shell view:

Greetings,

Here is where that error is coming from... It will return this error if it can't find a version.txt in the QUARTUS_ROOTDIR:

https://github.com/Nuand/bladeRF/blob/m ... sh#L47-L52

So, either QUARTUS_ROOTDIR isn't set in the environment, or there's no version.txt there.

Commenting out the call to check_quartus_version on lines 168 through 171 will bypass this check. Unfortunately, the changes between Quartus versions are not backwards-compatible (or even forwards-compatible), so building with 11.0sp1 will likely fail without significant changes to the build scripts, Qsys, or even the C/VHDL itself.

Your best bet may be to set up a 64-bit environment somewhere else and install 15.0 in there.

I have had good success running Quartus on Linux VMs (e.g. Linode, Digital Ocean, AWS, etc). The Linux install can be challenging on non-RHEL systems due to dependencies on multi-architecture libraries, but it's doable. A Windows VM from Azure or AWS could work, but I've never tried it.

Also, Intel/Altera do have their own cloud offering now, but it sounds like it will only build for Arria 10 FPGAs right now, so it's not helpful (yet): https://www.altera.com/products/design- ... vices.html

Good luck! If you try any of these approaches, please let us know how it works. Thanks!

Dear Rey.

Thank you very much for rapid and detailed reply.

Following your advice, I commented out lines 168 through 171 in build_bladerf.sh file. And I got negative answer from NIOS Command Shell:



I was not too lazy and checked the directory E:\CSI_DSI\SDR\bladeRF\bladeRF-master\bladeRF-master\hdl\fpga\ip\altera\nios_system. I was find nios_system.qsys file and tried open it with my Quartus. In result I get this:



As You can see, the main problems are “can’t find package qsys 15.0/16.0” and “package require –exact qsys 15.0”

What do you think about it? Is it necessary to continue using QuartusII 11.0sp1 Web Edithion for working on the project? Or it will be more correct buy now a 64-bit computer and install the latest version of Quartus IDE in order not to spend time and effort for nothing?

What about second part of my query? How can I output I/Q examples to the U74 connector (header U 74 or “Expansion Header” on BladeRF board) in the simplest way?

I want output rx_sample_corrected_i[15..0] signal on EXP_GPIO[16..1] and rx_sample_corrected_q[15..0] signal on EXP_GPIO[32..17].



For my task solving, I want change lines 1171 through 1190 in bladerf-hosted.vhd file like this.
Before the change:
After the change:
Do I get the right result in that case?

P.S. What is Your opinion think about my English?

Quartus back porting:

Your laptop appears to have a 64-bit CPU, so you could upgrade your version of Windows to 64-bit if that's an option for you. (Note that Windows 10 compatibility is somewhat broken at this point, but we're working to fix that.)

It appears that beginning with Quartus 14.0, only 64-bit operating systems are supported. If you want to stick with 32-bit Windows, consider upgrading your Quartus to v13.x -- it should be somewhat easier to back port our design to v13.x than v11.x.

I will try to outline the general process of back porting the design. However, as I'm not going to test this for you, some steps may be missing or inaccurate. As time goes on, you may find it easier to upgrade your host machine or use a virtual machine as Rey suggested earlier.

First, make sure you have the latest master. Then, take a look at all the _hw.tcl files that Quartus is complaining about and change lines such as:
to read as follows:
One example of this:
https://github.com/Nuand/bladeRF/blob/6 ... hw.tcl#L15

You'll also want to edit (text editor is fine) the nios_system.qsys file. Do a search for "version=" and change anything with a version newer than your version of Quartus. For example, something that reads "version=17.0" you'd replace with "version=11.0" or "version=13.0" if you have Quartus 11 or 13 installed, respectively.

After doing this, I'm almost certain you will have new errors such as unknown ports/parameters/etc. in the Qsys system and/or _hw.tcl files. You'll have to go into each file and manually delete or rename ports/parameters to their Qsys 11.0 or 13.0 equivalents. This is going to be time-consuming and you'll have to do this every time we publish changes to these bits of code. I expect the VHDL to not require anything crazy to back port to an older version of Quartus.

Getting samples out of the GPIO header:

What you have is the right idea, but syntactically incorrect. First, the signal assignment operator on lines 1175 and 1177 is going the wrong way (should be <=). Second, you can't assign a vector to an individual bit. Finally, you'll have an issue using GPIO[1] as an output (it's a clock input only, a limitation of the Cyclone IV FPGA). To make things slightly easier, the upper 4 bits of rx_sample_corrected_* can be ignored -- only bits 11:0 contain actual sample data. (We sign-extend the 12 bits up to 16 bits for future expansion and to make the sample processing more friendly on the host side of things.)

You can simplify the VHDL to look something like the following:
Consider also piping out a clock and data_valid indicator associated with this data stream -- they will be helpful if you intend to analyze this data with external equipment.

Having said all this, if you plan on connecting another microcontroller or FPGA to the GPIO port to read these samples, you'll want to add appropriate timing constraints to keep the data/clock skew within a known, predictable window across FPGA builds. You would do the same on the receiving side (if possible) to avoid metastability issues. Take a look at our constraints/bladerf.sdc for a general idea of what these constraints look like.