applications of Sinara and Kasli

[jbqubit]

What projects currently plan to make use of Sinara and Kasli?

• Yb+, Ba+ at ARL
• Yb+ at JQI
• Yb+ at Duke
• Be+, Ca+, Al+, Mg+ at NIST Boulder
• Ca+ at Oxford

What other projects might make use of Sinara and Kasli?

• Yb+ clock at Qutega
• Be+ Penning at NIST, photon detection using multi-channel plate readout; perhaps using CERN NA62 Readout Chip (TDCpix)
• color center qubits (eg diamond SiV) at ARL; need fast time to digital converter (TDC) perhaps based on this demo; compare with PicoHarp
• ultrafast laser... @jordens

Added by gkasprow: What extensions are planned for Kasli?

• isolated BNC TTL DIO
• isolated SMA TTL DIO
• slow 40 channel DAC
• LVDS over RJ45 (compatible with CAT6 cables? If we use 4 pairs then what about ground connection?)
• Camera link (what specification, color space, FPS, buffer length)

[hartytp]

Slow multi-channel ADC board?

[dtcallcock]

Slow multi-channel ADC board?

At some point we plan to add one of these ADAS3022 data acquisition chips Daniel S found to the NIST ARTIQ hardware via SPI.

I can think of a lot of other extensions like this that are just a single SPI chip and don't require new gateware to be written, just a driver. For these should we think about creating a template that includes the IDC/backplane/power/EEPROM/mounting etc and just leaves an open area for placement of the chip and suitable connectors? Then physicists could design and build their own boards very quickly.

There could even be a breadboard space and/or Arduino header on there to allow for really simple one-offs or prototyping.

[hartytp]

At some point we plan to add one of these ADAS3022 data acquisition chips Daniel S found to the NIST ARTIQ hardware via SPI.

Looks nice.

For these should we think about creating a template that includes the IDC/backplane/power/EEPROM/mounting etc and just leaves an open area for placement of the chip and suitable connectors? Then physicists could design and build their own boards very quickly.

I hope we can get the DAC board funded fairly soon. We could use this as the basis of a template -- just rip the DACs etc off...

[jordens]

I'm all for such a template. And a slow ADC that roughly matches the slow DAC would be fitting. Feel free to mess with the wiki. With a chip like the one you suggest. Or similarly there are some really nice and flexible multichannel "any kind of temperature sensor" chips out there.

[hartytp]

@dtcallcock

• I haven't looked at the data sheet carefully, but do you want any signal conditioning before the amps? e.g. it would probably make sense to have a very basic common-mode + differential-mode filter to reduce RFI rectification and cable cross-talk (if using a high-density cable).
• What about ESD diodes. Is the chip okay with its inputs being driven by +-10V from a photodiode amp when the board is unpowered? Otherwise, protection diodes are probably a must...
• Do you want 8 channels per board? Or, add a few ADCs multiplexed using CS lines? If 8 channels per board, shall we use insulated BNCs like the 3U_BNC?

[dtcallcock]

Probably yes to all those things. It might make more sense for people with a concrete use case and who are willing to fund the board to weigh in on the specifics though.

[dtcallcock]

As an exercise, I took a look at what else we have connected to the experiment that we might want to replace with Kasli extensions.

A lot of these are problematic because:

• A perfectly good commercial product exists.
• Tight Artiq integration wouldn't really add anything. Easier to just connect it to the PC than the FPGA.
• Everyone’s specific requirements will be different enough we’re unlikely to be able settle on a specification.
• They’re either too trivial or too hard to implement. This obviously depends a lot on the size of the eventual user base.

Still, I put the whole list up for completeness because people may have different ideas.

Temperature reader

• Based on the LTC2983 SPI temp measurement chip or similar?
• Front panel connections that match Omega’s standard connectors?
• Compatibility with transducers used in cryostats?

Piezo driver

• DAC and HV amplifiers
• 4ch?
• Based on existing plug-in amplifier module like this?

Line Trigger

• So Artiq knows what the line phase is
• IEC connector on the front?

RF Switches

• The lab is dotted with many mini circuits rf switches. They are a pain to wire up. They are SPDT but almost always used as SPST with an external termination.
• 4 SMA in, 4 high isolation SPST, 4 SMA out?
• Note that the proposed DDS/Synth extensions with integrated switches will reduce a lot of the need for these.

RF Attenuators

• We use a lot of these LabBricks. They are a lot of money for what is basically a few-$ SPI digital attenuator and a bad USB/software interface.
• 4 SMA in, 4 attenuators, 4 SMA out?
• Note that the proposed DDS/Synth extensions with integrated attenuators will reduce a lot of the need for these.

Solid State Relays

• For switching an external PSU
• For controlling atomic ovens/dispensers, field coils, heaters, etc…

Magnetic field coil driver

• Few amp, high stability and low noise.
• DAC to generate line frequency (+harmonics) for feedforward cancellation of lab fields

Feedback controller for high current coils

• Connects to external current transducer
• DAC to generate line frequency (+harmonics) for feedforward cancellation of lab fields?
• Oxford have already developed something that does this.

Digital Servo

• Could be a carrier for a Red Pitaya that adds analog front-end etc? See Robert's RED PID.

PDH Error signal generator

• Similar to Toptica product
• Would work with proposed DDS/synth card?

RS232/GPIB

• Currently relying on a lot of flakey USB adaptors.
• Would allow use of the SRS SIM rack as part of Kasli

Peltier controller

• Current requirements and power dissipation may well make this undesirable.

Clock generation

• Carrier with monitoring and distribution for a Luff PLO.

[gkasprow]

For the purpose of slow control we could use Kasli + extensions with IPbus, which becomes standard in High Energy Physics. IPbus is simple and fast implementation of control protocol which bridges Ethernet with Wishbone. In this way we can hook several UARTs to wishbone on one side and run virtual serial ports on PC on the other side to get rid of USB to RS232 converters With this approach one can think of a system that detects all modules plugged to Kasli (EEPROM ID) and loads appropriate Linux drivers. We could use existing tools like Wishbone Bus. It would do the same with FPGA IPs that reflects connected hardware. I can imagine such situation:

• connect all estensions to Kasli
• run auto discovery script
• run wishbone builder or similar tool that collects all IP for detected resources and generates FPGA code and then compiles to a single bitstream. Another option is set of standardised cores (like SPI, I2C,IO) followed by a fabric switch that match connected hardware with IP cores.
• run driver discovery script that load apropriate Linux drivers that reflect connected hardware and IPcores. Here (SDB) could be used for IP core identification

Theoretically all required open software/open gateware components exist. I know that it is very complex task, but we can ask for founding i.e. from EU QuantERA

[sbourdeauducq]

@dtcallcock I'm quite interested in building laser controllers. Sayma doesn't seem to be the right platform for that (the DACs are overkill wrt the sample rate, and JESD204 especially with the crappy Xilinx transceivers introduces hundreds of nanoseconds of latency). Kasli doesn't have nice (high-ish speed) I/O connectors for the ADC/DACs and I'm not sure if it should have it. Those connectors tend to be pricy, but wouldn't the TTLs also benefit from them, especially if we want nanosecond resolution?

[hartytp]

@dtcallcock

Piezo driver

• One option might be to just make a 3U fixed/switchable gain HV amplifier output stage that connects to the IDC on the slow DAC board. This minimises the amount of extra hardware/software needed
• Might also work for blade traps voltages?

Feedback controller for high current coils

Paper + designs hopefully being published soon...

RS232/GPIB

For GPIB, I find the prologix GPIB-ethernet adapters really reliable (USB is always a pain). Not sure that making this a Kasli extension is worth the effort though.

Peltier controller

MAX1968 are potentially a good option for this, depending on how much power you want.

[hartytp]

@sbourdeauducq > I'm quite interested in building laser controllers.

Out of curiosity: the lasers themselves? or, just the electronics (current, PZT, temp controllers, etc)? What do you want to do differently to, say, DL PROs?

Those connectors tend to be pricy, but wouldn't the TTLs also benefit from them, especially if we want nanosecond resolution?

Are you talking about replacing the pin-header/IDCs on Kasli with something higher-speed?

JESD204 especially with the crappy Xilinx transceivers introduces hundreds of nanoseconds of latency

Off-topic, but: why is this so slow? (IIRC, this is what limits the bandwidth for Sayma ADC-DAC control loops, right?)

[sbourdeauducq]

Out of curiosity: the lasers themselves? or, just the electronics (current, PZT, temp controllers, etc)?

Considering the status of my current attempts to build a scanning Fabry-Perot interferometer, it would be prudent to stick to the electronics for anything professional.

What do you want to do differently to, say, DL PROs?

Existing commercial offerings are black-boxes that are impossible to reproduce, expensive, and difficult to tweak to adapt to a particular setup. I'm envisioning some open-hardware and open-firmware device that (if not Kasli-based) is also optimized for reproducibility - simple PCB, hopefully just 2 layers, without BGA. I have the same frustration with controllers for Bayard-Alpert gauges and quadrupole mass analyzers - especially as the vacuum parts can be had for pretty little money, but then cannot be connected to anything. The latter is perhaps not very interesting to you, but I believe it matters for smaller (or even hobbyist) labs.

Are you talking about replacing the pin-header/IDCs on Kasli with something higher-speed?

Yes.

Off-topic, but: why is this so slow? (IIRC, this is what limits the bandwidth for Sayma ADC-DAC control loops, right?)

The transceiver silicon itself already has a lot of latency, especially the one in the FPGA - see https://www.xilinx.com/support/answers/42662.html.

[hartytp]

interesting. Thanks for the info...

[hartytp]

Speaking of speculative uses for Kasli: one day, it would be nice to port our laser diagnostic system to Kasli. That would remove the last piece of NI hardware from my lab...

[hartytp]

This seems largely redundant now. Closing.