SatDump integrated demod ("Symbiosys")

[Derisis13]

Hi!

Tezuka works great with SatDump, it's one of the platforms that have code to leverage the extra sample rate provided by Tezuka (by going down to 8 bit values). As I've hinted to it in the SatDump discord/matrix server, I'm interested in taking this a step further and bring Tezuka and SatDump into a "Symbiosys" (the name I coined for the project).

The idea is to put the demodulator front-end into FPGA, and channel decoding into the firmware. SatDump lends itself very well to this concept: it has three levels of processing: baseband to soft (symbols), soft to cadu, cadu to product. Currently, it's possible to run the first two steps in "server mode", and the third on a different machine. This is being used by people to build receivers into remote places and minimize traffic between the bulk storage and the stations.

The main limitation of Zynq-based SDRs is - as far as I know - the gigabit ethernet interface. If we could reduce traffic - similar to the case above - the AD9361 could go up to 61.44 MHz (with reports of users over-clocking it to 122MHz on USRP B210 clones). The two arm cores of the Zynq 7010 or 7020 can't handle this bandwidth (most x86 machines have a hard time with processing tens of megasamples per second live), but the FPGA fabric should easily be able to acheive 60 MSPS if architected carefully. The processor would have to deal only with soft-symbols, which can be packed more densly than 8-bit samples. Decoding the soft-symbols into bits condenses the data even further, making it possible to break free from the gigabit bottleneck.

This would allow real-time decoding of X-band signals (notorius for their high bandwidth requirements and high data rates), something that's not trivial to do with current software decoding (although there have been some developments on that front). The requirement of fast and plentiful storage to record a pass' worth of data would be eliminated, and the requirements for SDRs would be lowered (currently the cheapest option that can do enough bandwidth is the hamgeek b210 clone at 300$ whereas 7020 options can be found for 133$ and 7010 are starting at 100$).

Modifications to SatDump would be minimal, but it has to be able to configure the FPGA with the correct demodulator and receive soft symbols from it, while decoding them into cadu level and serving them with the existing server protocol.
This SatDump stub needs to be built into Tezuka, along with the drivers that configure the functions implemented in FPGA.
And obviously the demodulator hdl needs to be implemented and integrated into the existing maia-hdl project.

I feel proficient enough in HDL development so that I can undertake this part of the project, but I don't know much about yocto, petalinux, kernel drivers or even the structure of Tezuka and SatDump. This is where I'll need help from both projects, which is why I'm starting this discussion.

At this phase, I'd like to set down a preliminary design: understand the major architecture of the pieces present, figure out where it'd make sense to include my code, get some idea on the hdl-software interface and set some performance goals. I want to keep my design as flexible as possible, so that adding new functionality (e.g. new satellite pipelines) will be easy, and moving functionality into FPGA gradually is possible (for step-by-step testability).
For now I'd like to hear some feedback about the project, where am I wrong, what are the possible points of failure, which parts don't seem feasible at all?

[Derisis13]

The first thing I've done so far is to decipher the maia-hdl toplevel module's RX path.
maia_hdl_block_diagram.drawio.pdf
On this much simplified block diagram it's easy to discuss where to include my module which is critical to determine to what kinds of interfaces I shall use on its input and output.

The input can be either taken directly from the input or the maia decimator. Since the satellites transmit at each their own distinct symbol rates, a generic resampler is unavoidable. For this reason I think it's better to take the input from the ADC FIFO directly.

The output is a more difficult story. Maia-hdl as-is makes use of only two of the four AXI-HP buses of the processor. My guess based on the Zynq documentation is that this is due to there only being two DMA engines associated with these ports, thus using more than two AXI-HP interfaces doesn't increase the available bandwidth.
This means that symbiosys will need to share the DMA either with the maia-fft or the ADC/DAC/recorder trio. My suggestion is to keep the FFT and multiplex the demodulator output with the ADC/DAC. The reason for this is that streaming IQ while also serving decoded data would probably be beyond the processor's capabilities, and it still wouldn't be able to do the high data rates which'll be the speciality of symbiosys.
On the other hand, having an FFT for tracking is the minimum requirement for receiving LEO satellites, with constellation diagram, SNR graph and "magic eye" being nice-to-have features. (This is solely my opinion, who has only tracked LEO sats twice with a wide beam dish, and even then I couldn't follow it properly...)

Please let me know if I misinterpreted anything or my assumptions are wrong somewhere. In any case, I'll start working on the HDL toplevel design with an axi-stream (or similar) input and an axi-hp output. I'll also dive into the documentation of the Zynq 7000 series in the hopes of learning more about the DMA system and the processor side of things.

[PA3AEF]

Interesting thought, but from an architectural point of view would it be good to put parts of an application into the firmware of a device? Think of modularity, dependencies, etc. That is a consideration you need to take. What are the pros and cons?

Peter

[Derisis13]

I was thinking about this, it'd be great for example if error correction could be done from firmware (but I'm not 100% sure if the processor can handle it at full rate) and if not, I can always do it in FPGA, but the algorithms used are often memory hogs and the processor has much more of that.
Still deframing should definitely be done in firmware. There's just no reason to do it in FPGA.

As for dependencies and modularity, I'm not sure what the main concern is. Is it a goal to keep the image as small as possible? Is it to keep the build process as simple as possible?