Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Which Vivado project base is to be used for custom filters on the FPGA? #107

Closed
Yatekii opened this issue Mar 19, 2017 · 2 comments
Closed

Comments

@Yatekii
Copy link

Yatekii commented Mar 19, 2017

Hi!

As the title states, I am unsure with what project base I should start.

There is quite a palette of different choices:
http://redpitaya.readthedocs.io/en/latest/fpga/fpga.html#fpga-sub-projects

But the statements made here:
#88
Say that the buffer is quite small. I mean 16kS is NOTHING.

With what project should I start?
Also is there a better explanation somewhere on how to interface ADC/DAC code other than the source files and the really short explanations in the wiki?

Best regards
Yatekii

@jeras
Copy link
Contributor

jeras commented Mar 20, 2017

Current development is done on the mercury branch on the FPGA subproject of the same name. The code is still under heavy development and not stable. All other FPGA subprojects will not be developed further.

The mercury FPGA code is an attempt to write a cleaner FPGA code with more features. This are just a few changes:

  1. generator and scope modules can be mapped by SW individually, so one app can use oscilloscopes and the other generators, even more fine grained options are possible.
  2. Trigger distribution is not somehow centralized, so each trigger drain can use each trigger source. This is actually difficult to explain in a few words, I will have to document it properly.
  3. Calibration will be moved into HW, making related SW simpler.

For now 16k-sample buffers are used, DMA access to main memory will take some time to code properly.

There are Jupyter applications for generator and oscilloscope, they are not fully tested, since their main purpose is testing HW and the API (written entirely in Python for now).

Regarding ADC/DAC interfaces. If you have a look at the mercury FPGA code:
https://github.com/RedPitaya/RedPitaya/blob/mercury/fpga/prj/mercury/rtl/red_pitaya_top.sv
At the beginning of the file ADC/DAC interfaces are defined:

axi4_stream_if #(.DT (SBA_T)) str_adc [MNA-1:0] (.ACLK (adc_clk), .ARESETn (adc_rstn));
axi4_stream_if #(.DT (SBG_T)) str_dac [MNG-1:0] (.ACLK (adc_clk), .ARESETn (adc_rstn));

Both use the AXI4-Stream protocol. For he ADC the TVALID signal is active all the time for DAC the TREADY signal is active all the time.

For now there will be not much more then the code itself as documentation. Later we plan to write demo projects, where this streaming interfaces will be available in the Vivado block design editor, and it will be possible to connect them directly to other Xilinx streaming IP.

Regards,
Iztok

@Yatekii
Copy link
Author

Yatekii commented Mar 20, 2017

Thanks for your fast response!

Why I asked is because we are doing our bachelor thesis with your FPGA board and thus are depending on it.

Since we are reliant on your provided software framework & FPGA framework I was kinda shocked to find that few resources to a Project that was launched 2013, partly because I expected to have a kinda big userbase doing FPGA stuff. But all I really found was a Tutorial on how to get an LED to blink and some brief description of the Verilog components. Maybe I am just not good enough at Google ;)

I have no troubles reading through the sources, even tho I am not savy of Verilog, but using it analogous to VHDL I am sure I will be able to understand enough. As a head start it would be nice if I knew HOW unstable the mercury branch is and or it's even worth planning for the old code.
I would prefer a partly unstable code which is still maintained.

We are going to need the ADC in the first place, including it's Triggering logic. So my specific question here is: is that part of the code stable and/or can we use it?
We were planning on inserting our downsampling filter between your ADC code and the part that streams the bits to the network effectively replacing your downsampling filter (I read there was one, not sure if this is still the case for the mercury branch).

I have no troubles implementing part of the needed functionality myself but since you have a framework for closed hardware I am kinda hesitant and I would be very glad if you could give me some pointers.

Also on the 16kS part: I guess I could easily upsize the buffer right? I guess I wouldn't even have to fiddle with the device tree but rather just some constants in the Verilog code?
For lower datarates I can surely stream the data to the pc but for higher datarates that's just impossible.

Using Jupyter is a great pleasure, even tho I will implement a Scope App using ES6, WebGL and WebAudio in the end. So I will be looking forward to use your Jupyter Demos & Tests!

Kind regards from Switzerland
Yatekii

@b-swat b-swat closed this as completed Jul 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants