Not Implementing in Vivado

[JRydTech]

Hello,

This is a wonderful project, but I am new to Vivado and Red Pitaya and am having trouble implementing it.

In the bd.tcl file I changed the version from 2017.2 to 2020.1 which is the version of Vivado I am using. I was able to execute ./make_fpga_project.sh and it seemed to run without issue but the terminal closed abruptly at the end.

After this I open vivado using the command:

source /opt/Xilinx/Vivado/2020.1/setting64.sh vivado

I open the project RedPitayaDAQServer.xpr and then try to generate a bitstream. It's synthesis goes okay but its implementation fails. There is no block diagram to be viewed which also worries me.

Is there a more detailed step by step procedure I could use? Do I need Vivado 2017.2?

Thanks for your help. James

[JRydTech]

Is it possible to make master and slave images without Vivado?

[jonschumacher]

Hi James,

it is not possible to build the FPGA image without Vivado. The build process is currently not well documented. This will change with the merge of #35. The failing build is to be expected to some timing issues which are also (partially) resolved in the PR. If you don’t want to change things, you can resort to the Linux image linked at [1].

Cheers Jonas

[1] https://tknopp.github.io/RedPitayaDAQServer/dev/installation.html

[jonschumacher]

Concerning the change to Vivado 2020.1: This also requires version changes to some IP cores. #35 also tackles this, but switches to 2021.2.

[JRydTech]

Hi Jonas,

Thanks for your replies. I do not wish to change anything, but If I am understanding this correctly, I can't make a master or slave image without Vivado, and therefore cannot cluster them.

Would getting Vivado 2017.2 fix the issue?

Can I simply just cluster them with the image at [1]?

Our goal is to make a cluster of RP with eventually a SDR as the master and 4-5 STEMLabs as slaves via daisy chain ideally. Your merge of #35 would be the ideal system for our need.

[jonschumacher]

Hopefully, we will merge the PR on Monday and then provide an update to the ZIP file. Concerning the image: The documentation on this is outdated, unfortunately. You just need one image, which is also supplied in the current ZIP. Then you place a jumper for selecting the clock.

[nHackel]

Hi James,

as Jonas said I'd recommend using the provided image for now, if you just want to use the project now. Once you can connect to the RedPitaya you can go to apps/RedPitayaDAQServer and checkout this commit 7cd86914a3e3ebc6d9909b398ba132c988eab6ca and execute make.

That is the latest release version with additional bugfixes. After a reboot the server will then load the proper bitfile when you connect to it.

In the following weeks we are going to make a new release that includes the mentioned PR and bugfixes as well as new server features and updated interfaces.

[jonschumacher]

We just merge the PR. Does this solve your initial problem of not being able to build the bitfiles? Out of curiosity: Can you disclose more details about your project?

[JRydTech]

Hey Jonas,

Thanks for the update on the PR merger. I have not updated things yet so I can't answer if it is fixed yet or not. I am so unfamiliar with Vivado, even if it did work, I don't know if I would be able to do anything with it anyhow. I am actually just having trouble getting the standard image to work using the Julia client and provided examples.

I was able follow the directions and have two STEMLab-14s with the right connections in place to cluster them, but now I am stuck. I was able to get the RedPitayaDAQServer clone, and "make" to execute. I downloaded Julia 1.7.2. I have the SATA connections, the external trigger, the jumper for the slave, etc. The master red pitaya has the flashing LED, while the slave does not. The resistors on the slave are in the correct position. I just can't seem to figure out how to load an example in Julia, or what i'm suppose to do next.

It may be we don't need to cluster them at all, but having the continuous data transfer at 15.6MHz is still a great goal. We mostly program in LabVIEW but can't get the data acquisition as fast as we need.

Hardware wise, ideally, we have a SDRLab as the master and 4-5 STEMLab-14 as slaves, but I am very stuck.

Do I need that commit mentioned before to get the standard images working?

It would really save the day to figure out how to control a cluster of these things like you project allows, but the synching may not even be necessary for us.

[tknopp]

Hi @JRydTech, many thanks for your interest. Right now the documentation is likely out of sync with the code since @jonschumacher and @nHackel were heavily on streamlining a new build system. We will test and reach out to you when we are certain that things work.

In any way: your first test should definitely be in non-cluster mode with a single RP.

In what time zone are you? Just in case we need to switch to real-time communication.

[JRydTech]

Hi Tobias, Great to meet you. I love the project. My issues are mainly because I am a beginner, so I appreciate all the help and advice and patience from all of you.

I am in EST (Michigan) time zone.

Thanks!

[tknopp]

Ok, I just made a quick test and the following should work:

1. Use a single STEMLab-125-14 as the master (no slaves).
2. Install this image, that I just uploaded. Put it on the sd card
3. Startup RP and login via ssh (user:root, passw:root)
4. Install the julia client https://tknopp.github.io/RedPitayaDAQServer/dev/installation.html#Setting-Up-the-Julia-Client-Library using the dev method
5. go to ~/.julia/dev/RedPitayaDAQServer/src/examples/julia/ and start julia
6. julia> include("simple.jl") # you might need to install PyPlot

If all works well you should see this image:

(note that SDRLab is currently not supported. It is doable but requires work)

[jonschumacher]

Dear James,

let me elaborate on the last comment of Tobias. The SDRLab has a clock frequency of 122 MHz whereas the STEMLab has a clock frequency of 125 MHz. I assume you chose the SDRLab due to the higher dynamic range of the ADCs, but feeding the SDRLab clock to the STEMLab devices will require changes to the clock management of the slaves. This means you won’t get along without learning some FPGA programming. A possible solution could be to make the SDRLab a slave and use the 125 MHz clock everywhere. One problem might still be the higher bit depth of the SDRLab. We only work with 16 bit integers internally. With a decimation of at least 8 you would lose the equivalent of 3 bit but depending on the ENOB of the ADC this might not be relevant. Another problem is that I am not sure whether a 16 bit ADC is currently supported by the implementation of the FPGA image. Adding the SDRLab is currently out of the focus of our projects since its inputs start above our needed frequency range.

This being said, we might be able to help with this. I work for the Fraunhofer IMTE, which is part the Fraunhofer Society, the biggest organization for applied research and development services in Europe. We might also help with implementing preprocessing algorithms and other related things. If you want to discuss this further, please reach out to me. My contact details can be found here.

Regards Jonas

[JRydTech]

Hi Jonas, Tobias,

Thank you for waiting. My apologies for the delay in response.

Tobias, I tried the steps you written out, but a connection error occurred on the last step. I'm not entirely sure what the issue is, but my supervisors asked me to move on from trying to daisy chain the RPs for now. We are going to use internally clocked ones and simply see if triggering works well enough for the STEMLabs in our project. I truly appreciate the help you provided, and was told I can come back to this later on.

Jonas, Thank you for the insight. Regarding the Fraunhofer IMTE and helping, this is great. I will check about it.

Thank you everyone for the help provided. It means a lot to me that each of you went out of your way to help me. Even writing out step by step instructions. It's rare to find such generosity and passion nowadays. I truly appreciate it. So again, thank you!

Best wishes, James