Modifying v0.94 to Add Functionality in JupyterLab?

[sslerose]

Hello,

I am looking to see if it is possible to modify the v0.94 FPGA image (i.e., that which is loaded when executing the from rp_overlay import overlay command in JupyterLab, see here) on the Red Pitaya to add functionality when using JupyterLab. And if so, how could I do this? Would I have to modify the v0.94 build from the Ecosystem and pass the bit.bin file to the RP, or do I need to change the v0.94 build on the RP side?

In essence, I would simply like to add a filtering program written in Verilog to the block design in-between the connections of the Ch1 data stream so that any data passing into Ch1's input is filtered before being passed to Ch1's output. I am hoping that the API commands for retrieving output data based on v0.94 in JupyterLab won't be affected by this addition and should work as normal.

If JupyterLab is not an option, would the solution to my problem simply be modifying v0.94 from the Ecosystem, passing the bit.bin file to the RP, loading the modified v0.94 bit.bin file, and running Python API commands inside the RP Linux?

If you have any other suggestions, please let me know, and thank you in advance for any help!

[redpitaya]

Hello sslerose,

I will move this topic to FPGA. The FPGA developers should be able to answer this better.

The JupyterLab uses the standard v0.94 FPGA image (starting with OS 2.00-30).

As I see it, once you modify the existing FPGA image, you can copy the v0.94 folder in the "/opt/redpitaya/fpga/z10_125" and change the "fpga.bit" and "fpga.bit.bin" files with your own. Make sure the names stay the same, but change the directory name from v0.94 to something else.

Then you should be able to use the overlay structure like this (example for mercury image):

Code: Select all

from redpitaya.overlay.mercury import mercury as overlay

As long as you do not change the existing registry space, there should be no problem with adding a custom module to filter CH1 data (you can easily add custom registers, just do not change the existing ones). The APIs rely on reading and writing data from registers, so if the existing registers stay at the same addresses the APIs should remain fully functional.

Please correct me if I am wrong.

[sslerose]

Hello redpitaya team,

Thank you so much for the clarification. I have a v0.94 project open and I am slowly learning the new structure, but I have a few questions:

1. Where do the CH_1 and CH_2 data streams enter the block design and interface with the Processing System? Before 2.00 this was done by the ADC IP core that created an AXIS interface. However, now it seems that there is an HP interface and no AXIS, so how can I interface with the ADC stream?
2. My previous project depended on having an AXI Interconnect with GPIO cores that allowed me to send parameters to my modules via Jupyter Notebook. This seems like it isn't possible anymore, so how might I interface with my modules?
3. The Master Base Address for all of the HP connections are the same, so how are HP0 and HP1 (or the others) differentiated? Are HP0 and HP1 the connections for CH_1 and CH_2 in a two-input FPGA?

Thank you in advance for any assistance.

[juretrn]

Hi,
v0.94 does not have any ADC IPs and never did. It does use XADC which is only used for temperature monitoring and for the "slow" ADC measurements. Can you be more specific; I am interested which code you are looking at?
In any case, none of v0.94 logic uses AXIS, but AXI3 ports GP0 and GP1.
GP1 only goes to the XADC.
GP0 is used for all register accesses, including internal BRAM which stores acquisitions of all fast ADC channels. I suggest you hook that up to an interconnect and split up GP0 into 2 parts; one goes to the existing code and the other to your module.
HP ports are used to transfer data to RAM in case the user selects DMA acquisition mode.

[sslerose]

juretrn,

My apologies, I must have been confusing parts of the v0.94 build with those in some of the example builds.

GP0 is used for all register accesses, including internal BRAM which stores acquisitions of all fast ADC channels. I suggest you hook that up to an interconnect and split up GP0 into 2 parts; one goes to the existing code and the other to your module.

So what I understand from this is that the master interface for GP0 is responsible for control of both the fast ADC input and output, depending on which API functions are called? Also, how are the channels split up in the GP0? My idea was to use the inputs of both channels: CH1 passes the raw data through the filter and then I would read the output via the API, and then CH2 would accept the raw data and I can read that output separately also via the API. But would this require both the outputs to be passed to the same pinout?

Thank you again.

[juretrn]

Hi,

the GP0 bus is indeed the one that handles all of the API calls.
For a breakdown of the register space, see this link:
https://redpitaya.readthedocs.io/en/lat ... v0.94.html

Each channel currently has its own receive buffer, so you can use each channel as you want.
You don't have to even make one channel be filtered and the other raw. You can add one more buffer to each channel so that you can have both types of data available, or add a switch to select which type of data you want to save into the buffer.

[sslerose]

juretrn,

Would you happen to have a link to the source code of the rp Python package? It may help answer some of my current and future questions.

Nevertheless, I assume that once the acquisition is started by the API command and the trigger is passed, N samples are recorded to the registers starting at 0x40110000. If this is the case, would I be able to read from the register spaces within my module once the spaces have been filled?

Also, does the rp Python package have ways to access registers? I have parameters within my module that would need to be modifiable from the Python side (I previously used a GPIO core and commands similar to those found in some of the non-API examples).

I apologize if my questions are uninformed. I am very new to working with registers in Vivado but I believe the API would be super valuable to my project. Thank you again!

[juretrn]

Hi, I don't know much about the Python API. From what I can tell, our examples call the SCPi functions:
https://github.com/RedPitaya/RedPitaya/ ... les/python

Yes, the acquired data is located at address 0x40110000 (0x40120000 for channel 2). Those addresses are directly mapped as registers and should be available to you through the API.
Unfortunately can't tell you much what happens on the higher levels, I am strictly an FPGA developer; I am not familiar with the software side.

There are functions that you can use to interact with the registers and buffers, but they're C++:
https://github.com/RedPitaya/RedPitaya/ ... pi-app/src

[sslerose]

juretrn,

Perfect, that answers pretty much everything I need. I saw the register access commands just today after realizing you and your team probably thought about that already.

I do have a few more software questions, but I will create a new thread in the Software topic.

I sincerely appreciate your continued help and I look forward to future updates.