4 ms·

I'm pretty excited by this announcement. Not for storage but for software defined radios. If Xilinx upgrades their RFSOC (which is an Zynq Ultrascale variant wi

I'm pretty excited by this announcement. Not for storage but for software defined radios. If Xilinx upgrades their RFSOC (which is an Zynq Ultrascale variant with built in ADCs and DACs) to this core from the current A53 core it will allow much more sophisticated base band processing in software that is currently done with FPGA gates in the fabric. And while reconfigurable FPGAs are nice, software can change modes much more quickly than reconfiguring an FPGA can.

dragontamer 6y ago
Question: are GPUs a consideration in the SDR world? I'm no expert on SDR, but it seems to me that SDRs are the high bandwidth and parallel workloads where GPUs excel in. (GPUs can perform fourier transforms very efficiently) The only possible qualm would be the latency of a GPU. But I don't imagine that SDR workloads are very latency sensitive? Or am I mistaken there? GPU kernels are just software, but the parallel nature of GPUs means that it's better if most of the GPU is sharing the same code (very small L1 code cache per thread). So it's far more flexible than a FPGA but somewhat less flexible than a CPU (where different cores and threads can be executing very different code with large and unique L1 caches)
- ChuckMcM 6y ago
  Yes! There is a very active community of using Cuda to do signal processing[1]. Latency is an interesting thing, its always part of the SDR pipeline since you have filter delays and processing delays. Most digital streams are uni-directional so you get the bits out, just shifted by 'x' nS. Since the 'x' is deterministic you can plan for it. [1] https://github.com/rapidsai/cusignal https://github.com/rapidsai/cusignal
  - CamperBob2 6y ago
    That's pretty cool. I don't know anyone who does realtime signal processing work in Python, though, least of all myself. Are there C bindings for all of that stuff?
    - ksaj 6y ago
      I'm not sure if this is precisely what you are looking for, but it's been on my radar for a while for a potential upcoming project. It has limitations (64-bit Windows only, for one) which is why I haven't acted on it yet. But it is part of my pre-project research just the same. https://github.com/taroz/GNSS-SDRLIB https://github.com/taroz/GNSS-SDRLIB
    - ChuckMcM 6y ago
      Nearly all of the "heavy lifting" as it were are C or C++ libraries. Python is just the 'plumbing' level. It is not dissimilar to using MATLAB where the drivers are all optimized code but the connection between them is MATLAB. This design pattern is a common of nearly all SDR frameworks (Gnuradio, Redhawk, Pothos, Etc.) The "interconnect" between processing elements is typically shared memory, and that is why it lends itself to GPU work as well. That said, since my head is most comfortable thinking in C, I tend to write stuff in C rather than Python :-).
- mhh__ 6y ago
  I've seen it done on the PC side, but (at least on my budget) implementing a GPU, and an FPGA, and the actual SDR I haven't seen. It's definitely a good idea but whereas I could definitely do a decent spec arm board with enough time and prototypes to get it right, I don't even know where to start when it comes to even getting a GPU to boot.
- 01100011 6y ago
  NVIDIA and Ericsson are already working on leveraging GPUs for 5G: https://www.ericsson.com/en/blog/2020/4/hardware-acceleration-5g-vran https://www.ericsson.com/en/blog/2020/4/hardware-acceleratio... I don't know if this involves baseband processing or just protocols and tighter coupling of applications to the network to reduce overall latency. This effort is certainly driving a reduction in jitter which is currently an issue with many realtime GPU applications.
bfrog 6y ago
They probably won't though, because the R core I don't believe has an MMU for Linux
- idiot900 6y ago
  From the article: "Another big change to the microarchitecture is the inclusion of an MMU"
  - bfrog 6y ago
    This is pretty massive! If fpga vendors provide this, what a great addition.
    - ChuckMcM 6y ago
      Hence my enthusiasm :-)
      - sitkack 6y ago
        What level of interposition can one do with these hard cpu cores? Are the cache eviction policies pluggable? Is "user code" in the path between the cpu and main memory?
        ChuckMcM 6y ago
        On the Ultrascale Zynq's you can build RAM that is attached to the fabric and available to the processor across the AMBA bus. It isn't something I personally have played with a whole bunch so I can't give you a better answer then to look at the Zynq data sheets. I do know you can make user hardware "appear" as memory to the main CPU.
        sitkack 6y ago
        Neat. I am stoked to play with the new PolarFire RISC-V Icicle board. https://www.microsemi.com/existing-parts/parts/152514 https://www.microsemi.com/existing-parts/parts/152514 https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit https://www.crowdsupply.com/microchip/polarfire-soc-icicle-k...
noipv4 6y ago
I would be keen to see if GNSS-SDR can run on a multicore version of this CPU. We are developing fully software GPS / Galileo receivers using the Analog devices AD9364, and are able to run it on a quad core Kaby lake laptop.
rurban 6y ago
Why do you need more than 2GB in real-time? In real-time the less the better. 64bit puts a huge burden on everything, the MMU also. Now people will start using operating systems which are not built for RT, like Linux, and wonder why the cycles start failing and the system constantly reboots. Driver availiability of course which drives down HW costs, but best use an extremely limited IO and only one fast IO to meet your cycle goals. I see that it's better than a custom FPGA, but a normal 32bit rt cpu with half the memory pressure and pointer size looks much better to me.
- ChuckMcM 6y ago
  I take it you haven't processed SAR data :-). In the Zynq Ultrascale series you can have DDR hanging off the fabric that is accessible through the AMBA bus to the processor. Having multiple cores doing overlapping convolutions on spectral data in RAM can run fast enough to give real time tracking latencies.

dragontamer 6y ago

Question: are GPUs a consideration in the SDR world? I'm no expert on SDR, but it seems to me that SDRs are the high bandwidth and parallel workloads where GPUs excel in. (GPUs can perform fourier transforms very efficiently) The only possible qualm would be the latency of a GPU. But I don't imagine that SDR workloads are very latency sensitive? Or am I mistaken there? GPU kernels are just software, but the parallel nature of GPUs means that it's better if most of the GPU is sharing the same code (very small L1 code cache per thread). So it's far more flexible than a FPGA but somewhat less flexible than a CPU (where different cores and threads can be executing very different code with large and unique L1 caches)

ChuckMcM 6y ago
Yes! There is a very active community of using Cuda to do signal processing[1]. Latency is an interesting thing, its always part of the SDR pipeline since you have filter delays and processing delays. Most digital streams are uni-directional so you get the bits out, just shifted by 'x' nS. Since the 'x' is deterministic you can plan for it. [1] https://github.com/rapidsai/cusignal https://github.com/rapidsai/cusignal
- CamperBob2 6y ago
  That's pretty cool. I don't know anyone who does realtime signal processing work in Python, though, least of all myself. Are there C bindings for all of that stuff?
  - ksaj 6y ago
    I'm not sure if this is precisely what you are looking for, but it's been on my radar for a while for a potential upcoming project. It has limitations (64-bit Windows only, for one) which is why I haven't acted on it yet. But it is part of my pre-project research just the same. https://github.com/taroz/GNSS-SDRLIB https://github.com/taroz/GNSS-SDRLIB
  - ChuckMcM 6y ago
    Nearly all of the "heavy lifting" as it were are C or C++ libraries. Python is just the 'plumbing' level. It is not dissimilar to using MATLAB where the drivers are all optimized code but the connection between them is MATLAB. This design pattern is a common of nearly all SDR frameworks (Gnuradio, Redhawk, Pothos, Etc.) The "interconnect" between processing elements is typically shared memory, and that is why it lends itself to GPU work as well. That said, since my head is most comfortable thinking in C, I tend to write stuff in C rather than Python :-).
mhh__ 6y ago
I've seen it done on the PC side, but (at least on my budget) implementing a GPU, and an FPGA, and the actual SDR I haven't seen. It's definitely a good idea but whereas I could definitely do a decent spec arm board with enough time and prototypes to get it right, I don't even know where to start when it comes to even getting a GPU to boot.
01100011 6y ago
NVIDIA and Ericsson are already working on leveraging GPUs for 5G: https://www.ericsson.com/en/blog/2020/4/hardware-acceleration-5g-vran https://www.ericsson.com/en/blog/2020/4/hardware-acceleratio... I don't know if this involves baseband processing or just protocols and tighter coupling of applications to the network to reduce overall latency. This effort is certainly driving a reduction in jitter which is currently an issue with many realtime GPU applications.

bfrog 6y ago

They probably won't though, because the R core I don't believe has an MMU for Linux

idiot900 6y ago
From the article: "Another big change to the microarchitecture is the inclusion of an MMU"
- bfrog 6y ago
  This is pretty massive! If fpga vendors provide this, what a great addition.
  - ChuckMcM 6y ago
    Hence my enthusiasm :-)
    - sitkack 6y ago
      What level of interposition can one do with these hard cpu cores? Are the cache eviction policies pluggable? Is "user code" in the path between the cpu and main memory?
      - ChuckMcM 6y ago
        On the Ultrascale Zynq's you can build RAM that is attached to the fabric and available to the processor across the AMBA bus. It isn't something I personally have played with a whole bunch so I can't give you a better answer then to look at the Zynq data sheets. I do know you can make user hardware "appear" as memory to the main CPU.
        sitkack 6y ago
        Neat. I am stoked to play with the new PolarFire RISC-V Icicle board. https://www.microsemi.com/existing-parts/parts/152514 https://www.microsemi.com/existing-parts/parts/152514 https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit https://www.crowdsupply.com/microchip/polarfire-soc-icicle-k...

noipv4 6y ago

I would be keen to see if GNSS-SDR can run on a multicore version of this CPU. We are developing fully software GPS / Galileo receivers using the Analog devices AD9364, and are able to run it on a quad core Kaby lake laptop.

rurban 6y ago

Why do you need more than 2GB in real-time? In real-time the less the better. 64bit puts a huge burden on everything, the MMU also. Now people will start using operating systems which are not built for RT, like Linux, and wonder why the cycles start failing and the system constantly reboots. Driver availiability of course which drives down HW costs, but best use an extremely limited IO and only one fast IO to meet your cycle goals. I see that it's better than a custom FPGA, but a normal 32bit rt cpu with half the memory pressure and pointer size looks much better to me.

ChuckMcM 6y ago
I take it you haven't processed SAR data :-). In the Zynq Ultrascale series you can have DDR hanging off the fabric that is accessible through the AMBA bus to the processor. Having multiple cores doing overlapping convolutions on spectral data in RAM can run fast enough to give real time tracking latencies.