VHDCI_carrier as a SCSI breakout

[hartytp]

Context:

• There are a situations where it's useful to have EEMs physically separated from the Kasli that controls them by some meters.
• e.g. for the laser servo, we will probably have Kasli in the rack with our lasers and AOMs, but the photodiodes that connect to Sampler are near our ion trap in a different part of the room. To avoid large bundles of BNCs carrying analog signals, it would be nice to have Sampler(s) near the photodiodes and to connect it to Kasli with a single SCSI cable.
• Plan is to use a VHDCI_carrier as a EEM<-> SCSI adapter
• Need to check that this works from a SI point of view
• Proposal:
  • Loopback with Kasli->VHDCI_carrier->SCSI cable->VHDCI_carrier->BNC_DIO (and return)
  • Send a 125MHz clock and some data lines down the cable, loop back to Kasli and latch again at the other end. Send a PRBS down and look for errors over a couple of hours.

[jordens]

Could you delineate this from the alternatives: DRTIO, multiple core devices?

A backplane to vhdci adapter would be fitting and simple. The other parts are already there.

[hartytp]

DRTIO, multiple core devices?

Those alternatives can work in some cases, but this is more targeting cases where one wants to keep the devices directly connected to a single FPGA. e.g. for NU-servo, it's convenient to only have both the ADCs and DDSs connecting to the FPGA that runs the servo loop gateware.

A backplane to vhdci adapter would be fitting and simple. The other parts are already there.

How does that help? The aim here is to allow the Sampler and Urukul to be located up to 10m from Kasli, while still running the servo gateware on a single PC. An EEM<->SCSI adapter seems like a nice solution for this.

[jordens]

DIN 41612 to VHDCI, mounted into the rear panel, VHDCI cable, VHDCI carrier, and connect the two Samplers to it. The only thing missing is the power supply.

[jordens]

Maybe you can even use the vhdci carrier the other way round at the kasli end of the vhdci cable as well.

[hartytp]

Yes that's exactly the plan: vhdci carrier at each end. No new hw needed.

Everything should work apart from i2c but that's already on the to fix list for the vhdci carrier next revision.

[jordens]

Ack. Then I misunderstood. And for the loopback test you can even use the same carrier twice.

[hartytp]

Again that's the plan. Sorry the above was hastily written as a note to self and not clear.

Plan is to use a pair of DIO to check the lvds receivers are okay with the signal at one end And the fpga is okay with the signal at the other.

[gkasprow]

I tested DIO -> VHDCI carrier -> SCSI cable -> vhdci carrier -> DIO. Did not notice any issues above 100MHz. The cable was 2m.

[gkasprow]

The MLVDS drivers are much stronger than FPGA ones. So it works well with DIO but does not have to work with FPGA which has only 4mA LVDS current

[hartytp]

Thanks for the reminder Greg. I want to go kasli->VHDCI carrier->10m scsi->vhdci carrier->bnc DIO->bnc->bnc->bnc dio->vhdci carrier (all from here are the same components that we're used before) -> scsi->vhdci carrier -> Kasli.

That tests both eem to Kasli transmission and Kasli to eem. Can test with two fast busses at different frequencies in each direction to give an aggressive crosstalk test.

Just needs components I have in the lab and a handful of lines of migen.