use outside of uTCA

[sbourdeauducq]

Can this card be used in a housing composed of a bare 6U Eurorack crate plus a fan tray, in order to avoid the expense, complications, and unreliability of uTCA?

Also, would there be a solution for putting other 3U cards into the 6U crate? For instance, have a Kasli, EEM modules and some RFSoC cards in the same crate.

Do we really need a larger card and is 3U (potentially 220mm) not an option anyway? Here is a 3U RFSoC module: https://www.abaco.com/products/vp430-rfsoc-board

[gkasprow]

Yes, it can be used stand-alone. There is a Molex connector for 12V and backplane adapter with SATA cables. The idea behind MTCA was that one can reuse AFE concept from SAYMA. The RFSOC has 8 ADC + 8 DAC channels. The SoC is so expensive that 6-slot MTCA chassis is a small fraction of it.

[gkasprow]

However, 3U in MTCA is not the same as 3U in Eurocard. There is also 6U CPCIS and Eurocard and all 6U MTCA boards could be easily updated to fit this standard because 6U CPCIS is much bigger than 6U mTCA.

[gkasprow]

I have a concept of unifying both systems. We simply use CERN open source DIOT crate and make it as 6U, It uses already existing Eurocard hardware and open-source backplane. We keep the backplane, the same supply and make the chassis 6U. Then we can use MTCA adapter.

[sbourdeauducq]

The idea behind MTCA was that one can reuse AFE concept from SAYMA.

How about a 3U card with the PCB centered on the front panel, and a FMC AFE on each side?

I have a concept of unifying both systems. We simply use CERN open source DIOT crate and make it as 6U,

This takes a lot of space.

The main advantages of RFSoC are compactness and efficiency. If we're making monster uTCA-style systems, we might as well put traditional ADCs/DACs and not deal with the often unsavory application-specific silicon designs from Xilinx.

I also worry about the reliability of all these connectors. On several occasions, Sayma has driven me mad with some new unexplained bug, which was "solved" by unplugging and replugging the RTM. The SMP connectors were another bad experience...

[gkasprow]

We can try to fit the AFEs on both sides of the PCB. There will be issues with fixing holes of the connectors and mounting screws. How would you connect these RFSOCs together? One of the applications we build this module are SC applications. We need both PCIe/10Gb ETH fabric and DRTIO; as well as direct board-to-board low latency LVDS links. MTCA meets all of these requirements. If we go for the EEM form-factor, we would need to make all these connections by cables.

[sbourdeauducq]

Have you reviewed/measured the latency of RFSoC silicon? If it is anything like previous Xilinx designs (Zynq PS/PL AXI, transceivers, DDR controller...) you'll get hundreds of nanoseconds in various critical paths that you cannot do anything about, and those LVDS links may not do much. Who's writing the software and gateware for these SC applications?

[sbourdeauducq]

Just what I suspected. https://forums.xilinx.com/t5/Versal-and-UltraScale/RF-SOC-ADC-latency/td-p/874365

No documentation, no characterization, things that "can't be shared", and, it would seem, a minimum of 190 sample clocks...

[sbourdeauducq]

If you care about ultra low latency then you should probably use something like this: https://www.teledyne-e2v.com/shared/content/resources/File/documents/broadband-data-converters/EV12DS480/Preliminary%20DS%2060S%20217580_EV12DS480AZP_rev%20A.pdf

Then µTCA is perhaps less inappropriate for a large PCB with those DACs and support circuitry.

[gkasprow]

We measured latency. It is 120ns including DMA

[gkasprow]

If you combine 8 ADCs + 8 DACs + very large FPGA then you will end up wich a much high price tag than RFSOC. These discrete ADCs and DACs consume a lot of IOs and current. The RFSOC with all ADCs and DACs (and no logic) consume much less than 10W of power. Anyway, we got funding for the RFSOC module in MTCA form factor.

[gkasprow]

We have two applications (and clients) for RFSOCs so far

• superconducting QC. Here we need both PCIe/10GE and RTIO/WR. We deliver the base platform and the client does the rest of the coding. DRTIO/WR sits in dedicated timing FPGA so the RFSOC is maintained by the client.
• massive MIMO SDR, here we need both sync and high bandwidth PCIe/10GE. We already have working GNU Radio support.
• so far we got very little interest from ion trappers. If there is interest, we can consider making more appropriate form factor.

[b-bondurant]

Sorry if I'm late to the party, but in the long term I think there is interest from ion trappers. At Duke we currently have 5 experiments that I know of using the RFSoC in one form or another for gates. 3 using the ZCU-111 eval board and 2 using the Pentek 5950s.

Our current gateware is from Sandia (and therefore closed-source), and the execution model is very AWG-like -- pulse sequences have to be pre-compiled and uploaded and then the runtime component is just a TTL trigger. In terms of output, it's basically a 2-tone DDS with cubic splines for the coefficients. There are a few other gateware features like crosstalk cancellation and the ability to do feed-forward based on the repetition rate of our pulse laser via one of the ADC channels.

I say "long term" because it would be tough to convince any current experiments to move away from a working solution, but for future experiments I think better integration with ARTIQ/the coredevice would be a big selling point.

[gkasprow]

@b-bondurant We are currently designing a more affordable RFSOC in 3U form factor that does not need an expensive MTCA environment.

[sbourdeauducq]

What a fantastic idea that is