Access to FPGA

[Konstantin]

Hi,
Im using bladerf with different configurations and I would like you to ask you, how can i get the direct access to FPGA from ubs if its possible or not?, because i want to transmit and receive signals with my own parameters .
what should i change in bladerf driver or how to get this access ?

[jynik]

Could you be more explicit about what you'd like to do? It isn't entirely clear to me what you're asking.

[Konstantin]

I mean that the whole scheme looks like on the picture[img ] and im curious about the direct access to FPGA and skip cypress usb controller.it is possible to send the direct signals to FPGA via USB connection?

[jynik]

Hi Konstantin,

No, there are no FPGA pins are directly connected to the USB connector.

One of the FX3's primary tasks is to handle USB packets to/from the parallel GPIF interface via its DMA engine. Note that these DMA engine is only configured for buffers of specific sizes; it does not care what the format of the data is. So, if you're changing the steam of IQ samples to some special format, I don't believe the FX3 should prevent this.

I think I'm still unclear as to what your objective is, or why you believe the FX3 is interfering with your objectives. If you can describe your application in a bit more detail, I might be able to better help define the scope of changes you'd need to make and points you to relevant source code and/or vendor documentation.

Best regards,
Jon

[Konstantin]

Dear Jon,
what we are trying to do is rather straightforward:
1. get a way to send instructions directly to our custom-built FPGA firmware, bypassing libbladerf altogether. It does not mater if FX3 is involved or not.
2. Make sure that FPGA can run its own MAC protocol (i.e. synthesize its own samples)
3. Make a linux kernel driver to use the new mac as a USB network interface.
If you can, point us in the right direction.
Thank You!

[jynik]

Hi Konstantin,

It sounds like you're probably going to be developing both custom FX3 firmware and an FPGA image.

For command and control, you'll likely want to develop this as control (or even bulk) transfers to the FX3, which will then use I/O pins and the UART to control and communicate to the FPGA. You may be able to reduce the amount of code here by leveraging the fact that the LMS6 functions can be built into the FPGA's NIOS II. (We still need to ensure the Si5338 code can be built for this, and this is a welcome contribution.)

For high-throughput streaming data, I suggest you look at Cypress AN65974: Designing with the EZ-USB® FX3™ Slave FIFO Interface, as the bladeRF GPIF configuration may be too specific to its current use-case for your application.

For prototyping in user-space, I think libusb will get you a long way, until you're ready to hitch things up to the networking subsystem.

Good luck! I hope that you will be able to share some of your results with us and the community!

- Jon

[Konstantin]

Hi Jon,
I would like to share patch with community,because when you install SDK for FX3 you should do some manipulations/i think this patch help someone.and also I would like to ask questions about how to upgrade or upload new firmware for FX3.because we tried to do it in RAM and it doesnt work/do you have some tutorials or videos?

https://dl.dropboxusercontent.com/u/560 ... d%29.patch its a link for patch

[jynik]

Hi Konstantin,

Would you mind summarizing the issue you encountered and what that patch solves? Admittedly, I don't use the GUI tools enough to know what you're addressing in that patch.

When working on FX3 firmware, I generally have 3 approaches, listed below. You can further consult some of the FX3 documentation referenced below. Based on what you need after that, I can either explain further or write something up. Let me know what exactly you're looking to do and what your current approach is. I'm not quite sure how you're currently trying to download code to RAM, and whether the method you're using is dependent upon the FX3 example code and/or bootloader.

1: Downloading code to RAM and Debugging via JTAG
I take this approach when I'm doing a lot of debugging and plan to set set breakpoints, inspect memory, etc. I use a Segger J-Link for this.

For this, I believe the existing Eclipse project file should be configured properly. If that's no longer true (which might be possible, since we upgraded to FX3 SDK 1.3.3), I can take a look and see what needs fixing.

Alternatively, it's possible to just use GDB and GDB Server if you're like me and prefer just use the command line interface instead of Eclipse. There is a gdbinit_sample that's intended to be used as a .gdbinit file.

There's a EZUsbSuite_UG.pdf in the FX3 SDK v1.3.3 that describes the JTAG debugging setup. In the Linux version, this document is located in: cyfx3sdk/doc/firmware/


2: Resetting the bladeRF into bootloader mode and executing test firmware from RAM

If I don't plan on debugging much, but do plan on re-loading firmware frequently, I will typically opt to reset the device into bootloader mode. At each power-on the device will enter the Cypress bootloader, and I'll upload firmware to RAM via the bladeRF-cli program.

This can be done by running the jump_to_boot command in the bladeRF-cli, and then restarting the device.

Firmware can then be booted to ram via the recover and then open commands in the CLI:

Code: Select all

$ bladeRF-cli -i
NOTE: One or more FX3-based devices operating in bootloader mode
      were detected. Run 'help recover' to view information about
      downloading firmware to the device(s).


No bladeRF device(s) available.

If one is attached, ensure it is not in use by another program
and that the current user has permission to access it.

bladeRF> help recover

Usage: recover [<bus> <address> <firmware file>]

Load firmware onto a device running in bootloader mode, or list all
devices currently in bootloader mode.

With no arguments, this command lists the USB bus and address for
FX3-based devices running in bootloader mode.

When provided a bus, address, and path to a firmware file, the
specified device will be loaded with and begin executing the provided
firmware.

In most cases, after successfully loading firmware into the device's
RAM, users should open the device with the "open" command, and write
the firmware to flash via "load fx3 <firmware file>"


bladeRF> recover

  FX3 bootloader devices:
  ---------------------------------------------------------
    Backend:    libusb
    Bus:        1
    Address:    22

  Use 'recover <bus> <addr> <firmware>' to download and boot
  firmware to the specified device.

bladeRF> recover 1 22 ~/.config/Nuand/bladeRF/bladeRF_fw_v1.9.0.img 

  Success! Use "open" to switch to this device.
  Note that a "load fx3 <firmware>" is required to write the firmware to flash.

bladeRF> open

bladeRF> info

  Serial #:                 e3f9dbf3143e436542cb0f3ae947caab
  VCTCXO DAC calibration:   0x8fa0
  FPGA size:                40 KLE
  FPGA loaded:              yes
  USB bus:                  1
  USB address:              23
  USB speed:                Hi-Speed
  Backend:                  libusb
  Instance:                 0

bladeRF> 

3: Writing firmware to flash

When done debugging or infrequently uploading firmware, I'll simply write it to flash. This is describe here on the wiki.

[Konstantin]

Dear Jon,
could you please tell me how to get the stdout (or any other text output) from FX3 if using method 2? I have also edited the patch and added the description in the original post.

[jynik]

Hi Konstantin,

To the best of my knowledge, using CyU3PDebugPrint() requires either a JTAG connection or that you can dedicate pins to a debug UART. The latter is not possible in the case of the bladeRF; the FX3 uses the same pins for the UART and SPI, which are used for FPGA control requests and SPI flash, respectively.

However, firmware v1.9.0 includes this recent commit in which I added support for a simple logging mechanism. This allows you to record where in your program an event occurred, along with a 16-bit value. (For including a 32-bit value in debug code, I'd log each half back-to back).

On the host side, you can access this log in the bladeRF-cli via the fw_log command (added in this commit), optionally saving the log to a file.

Best regards.
Jon

[Konstantin]

Hi Jon,
Could you please tell me how to upload our new custom FPGA firmware and where i can find default FPGA firmware ?

[jynik]

You can find binaries here:

• Official FPGA bitstreams
• Official FX3 firmware

Custom FPGA bitstreams can be loaded manually via:

Code: Select all

bladeRF-cli -l <your bitstream.rbf>

Make sure you're removed any hostedx40/115.rbf files from the autoload locations.


Custom FX3 firmware can be written to flash:

Code: Select all

bladeRF-cli -f <your firmware.img>
# Reboot the platform for this to take effect

[Konstantin]

Hello Jon,
I have another question for you.if its possible to upload firmware.rbf to Altera using Quartus?

[jynik]

Hi Konstantin,

Let's be careful with our nomenclature here to avoid getting confused (or confusing others):

• Let's use "firmware" when talking about the FX3 firmware (the ARM code running on the USB 3.0 peripheral controller.)
• We'll use "bitstream" when referring to the Cyclone IV (FPGA) configuration

Yes, it is possible to load FPGA bitstream in Quartus, using the Programmer under the Tools menu. You will need to purchase a Terasic Blaster to use this.

[Konstantin]

Hi Jon,
Thanks,yes now i will use proper nomenclature.
I have altera usb blaster,this is also ok for load bitstream ?and one more question about jampers,I should change something in case with altera bitstream,because in case with FX3 we need to do it