kasli backplane

[hartytp]

As discussed earlier, pasting Greg's suggestion for the Kasli BP:

To define backplane structure we first have to think of communication channel for backplane enabled devices. IMHO we should reserve backplane option for special use cases. Individual IO channels like SMA, BNC, RJ45 need dedicated LVDS links and IDCs do the job nicely. Backplane enabled modules will benefit from clock distribution so we can install there DDS, RF generators, DACs, ADCs that need external synchronization.
For backplane devices we can make dedicated VHDCI adapter that supports high speed MLVDS.
So we can define backplane as MLVDS bus with limited number of supported protocols.
In this way all modules may have identical pinout and routed i.e. 16 LVDS lines + one dedicated selection line.
The interface that fits best both simple and complex devices is SPI over LVDS with multiple incarnations like QSPI, double QSPI. It resembles MMC interface where clock, chip select and 8 data lines are used.
With such interface running across the backplane, we can insert as many devices as the rack fits and obtain scalable transfer rate. It has one more benefit - we can mix 4HP and 8HP modules without loosing too many Kasli IO lines - only single chip select is not used.
For simple DACs we simply use standard SPI and ignore remaining data lines.
For applications that require hundreds of MB/s transfer rate (high speed ADC, DAC modules) we simply use 8 or 16 bit interface. To make all deterministic we can define time slots for every device.
SPI clock speed can also vary depending on currently selected module. MLVDS supports up to 100MHz.
Some simpler modules (slow ADC, slow DAC) can be designed as dual function with both backplane connectivity and IDC connector to enable stand-alone operation without the backplane.

So, the BP is intended to be used as an MLBDS bus + clocks, rather than as a straight copy of 4 extension headers.

AFAICT, the current VHDCI adapter/gateware will not support this backplane.

Any objections? Otherwise:

• to do: agree on pinout + detailed specification for the connectors

[gkasprow]

Are there any use cases that need both VHDCI and backplane-enabled modules like DDS and RF generators? Anyway, these modules will have SMA clock inputs/outputs and IDC connector to use without the backplane but with external clock. Backplane would be used when many DDS/RF channels are needed

[hartytp]

Are there any use cases that need both VHDCI and backplane-enabled modules like DDS and RF generators?

Not AFAICT. I just stated that this isn't supported for completeness, not to imply that it should be supported in the future.

[hartytp]

I've added a rough version of this to the Wiki. If no one objects to this as a plan, I'll close this issue...

[jordens]

The fundamental challenge with a shared backplane is that a shared resource will interfere deeply with RTIO: we'd need ways to arbitrate between the different users. In the end this will mean that there will be significant restrictions on how multiple modules can be used on the backplane and the interface and the gateware will be complicated. Imagine switching between different SPI protocol settings when toggling between modules or muxing between some parallel bus and SPI+nTTL. This obviously can't be transparent at all.

[hartytp]

@jordens Thanks for pointing this out.

Let's just scrap the backplane. The usefulness seems to be too marginal to justify the complexity. We can always retrofit one later if a pressing need for it emerges.

[gkasprow]

So maybe we can simply reserve backplane for SPI protocol for DDS and other stuff that needs clock distribution. In this way we would route LVTTL SPI from Kasli to all modules. Providing that SPI needs 4 lines + some interrupt/trigger/sync we would need just 8*5=40 lines per 8 slot backplane.

[hartytp]

In this way we would route LVTTL SPI from Kasli to all modules. Providing that SPI needs 4 lines + some interrupt/trigger/sync we would need just 8*5=40 lines per 8 slot backplane.

I think that most extension modules will want more than just SPI. e.g. the DDS might want some profile select pins, or a second independent SPI bus for a second DDS.

If the BP is really just for clocks, then why not just put a clock fanout buffer on Kasli + 8 MMCX/SMB/whatever. We can then internally route the clocks to the modules using coax that runs alongside the IDC.

[gkasprow]

Sure, this makes sense:) We can also go for UFL - in this way we could use low cost cables. But they don't like frequent insertions.

…

[hartytp]

That works for me.

[hartytp]

Backplane removed from Wiki. Closing this issue on the assumption that everyone is happy with us removing the BP from the Kasli specification. If not, please reopen.

[jordens]

IMHO the original idea of using the backplane to provide support for four (more or alternative) extension modules is just fine. I.e. all we need to commit to for now is to route power, 4x clock from the fanout, 4xI2C from a I2C switch, 4x8LVDS from the FPGA, to the 96 pin IDC on Kasli. The VHDCI breakout may be changed later to support the backplane when the need arrises. When the first extension module wants to use the backplane, they can bring it up and then we decide on the backplane connector pinout, the slot positions, and the backplane layout.

[hartytp]

I.e. all we need to commit to for now is to route power, 4x clock from the fanout, 4xI2C from a I2C switch, 4x8LVDS from the FPGA, to the 96 pin IDC on Kasli. The VHDCI breakout may be changed later to support the backplane when the need arrises. When the first extension module wants to use the backplane, they can bring it up and then we decide on the backplane connector pinout, the slot positions, and the backplane layout.

That sounds fine to me. I'll leave the BP off the Wiki for now, and let whoever wants it sort it out.

If there is room, I still think that having some clock outputs on Kasli for internal routing alongside the IDC might be a good idea...

[jordens]

Agreed. I suspect that eight clock coax connects will be tight, even with U.FL.

[hartytp]

I suspect that eight clock coax connects will be tight, even with U.FL.

Agreed, just put as many will conveniently fit without overcrowding. 4 should be plenty for most cases, and we can always put a clock buffer + output on the DDS boards to allow daisy chaining if necessary.

@gkasprow In light of this, let's not include a BP connector on the ADC/DAC boards. But, let's aim to do the layout so that a BP connector could easily be added in a later design revision if desired (we'd use jumpers to select between BP and IDC control).

[jbqubit]

Let's just scrap the backplane.

I concur.

[AnttiLukats]

LVDS is somewhat standard and can work 1.8, 2.5 and 3.3V VCCIO, but any single ended standard use on the LVDS would mean the singled ended standard VCCIO must be fixed, this is problematic. So it would be best to say LVDS is LVDS and never used as single ended. SPI can be serialized over LVDS