Grabber CameraLink interface

[jbqubit]

This Issue pulls together Camera Link related discussion into one place.

---

@jordens created an (ARTIQ Issue)[https://github.com/m-labs/artiq/issues/595] on this. Contents reproduced below.

Electron multiplying CCD cameras can perform as well as PMTs for many applications. They have the advantage of many more pixels, lower price per pixel, and all the obvious offerings of being able to spatially localize (i.e. image) photons.
By implementing a Camera Link receiver, an ARTIQ DRTIO satellite could within a few 100 µs receive the frame and perform cropping, binning, and photon counting on multiple ROIs in a scalable way.
Configuration of the camera would be out-of-band over the "usual" channel, i.e. the vendor's libraries and an ARTIQ controller.
An array of "ROI engines" listening to the pixel stream would be configured to gate on pixels within their respective ROI, perform configurable binning, and then post the result as an RTIO input event.
http://www.andor.com/pdfs/specifications/iXon_Ultra_888_EMCCD_Specifications.pdf
http://www.xilinx.com/support/documentation/application_notes/xapp585-lvds-source-synch-serdes-clock-multiplication.pdf

---

@gkasprow comments from orthogonal Issue #148 reproduced below.

What camera link standard do you want to use?
Base or Medium/Full one?
There are 2 ways to do that – using IOSERDES or external deserializer (http://www.ti.com/product/DS90CR287)
The deserializer gives just 28 signals + clock which would fit to 2 IDC cables (we treat them as 2x16 LVTTL).
But it is just Base configuration + serial link + 2 control signals. The advantage is simple implementation in the FPGA.
Medium configuration would need 4 IDC cables and second deserializer.

Another way is of course IOSERDES where for Base configuration we could use just one IDC cable (4 LVDS @595Mbit + 1x LVDS clock @85MHz)
This also means that Kasli banks have to be routed to the IDCs in standardized way. We can define first LVDS pair as the clock/io.
3 remaining LVDS signals will be used for serial communication and synchronization.
Second IDC would add another video channel + remaining 3 LVDS control channels
Third IDC would be just supplement for 64 bit video required by Full standard

The CameraLink standard defines 4 synchronisation LVDS channels and 2 serial channels. How do you plan to use them? I assume you used frame grabber that took care of communication. Is Andor control protocol described?

So do you want to have just Base configuration that consumes 2 IDCs or implement Full configuration that would need one more IDC?
Of course we can make IO board wired for Full configuration and give an option to use 1, 2 or 3 IDC channels (Limited Base, Medium or Full)

---

@jbqubit argues against use planning to use Sayma/Metlino for CameraLink. For v1.0 Sinara board support anyway. Pasted below from #148.

Metlino VHDCI anticipates applications that a) require very-low latency, high bandwidth link to ARTIQ Core Device (Metlino) or b) convenient re-use of 3U peripherals via VHDCI Carrier. CameraLink does not fit this profile for the following reasons.

• Maximum possible pixel clock rate for CameraLink is 85 MHz, 255 MB/s (single-link) ref
• CameraLink is pin-hungry >=16 pins
• Fanciest camera on the market (I know about) is Andor Ultra 888
  • readout rate is still slow relative to DRTIO: 697 frame-per-second for 128x128 sub-array
  • at best 10 ns timing accuracy
• Gateware-based image processing is likely required for feedback within the qubit coherence time. As this gateware is likely to be application specific it shouldn't be part of the standard Metlino or Sayma .bit files.
  Better to design a CameraLink 3U peripheral for Kasli, do the image processing on Kasli and transmit results back to ARTIQ Core Device using DRTIO.

---

@gkasprow said 'You can even hook up camera link to SFP using adapter.' Do you have more info on this adapter?

[gkasprow]

Example CameraLink to SFP adapter is here
There are a few other producers. Never used them and don't know anything about protocol.

Some time ago I designed simple FMC with Medium camera link interface. I have 2 pieces in my lab. It supports both IOSERDES mode and DS90CR288AMTD/DS90CR287MTD and can be assembled either as transmitter or as receiver. If someone is interested I can publish the project.
It can be modified to support Full CameraLink configuration.
.

[jbqubit]

Now referenced in wiki. This remains unfunded and without a champion. Re-open Issue if further discussion is needed.

[gkasprow]

@jordens @jbqubit I sketched initial schematic for Camera Link 3U board. CameraLink specifiction is here.
It seems Andor ignores all 4 CC lines as well as serial port and triggering happens using another DSUB connector and USB port. I don't know about utilisation of these line by other vendors.
So the question is: shall we implement full Camera Link support as specified by standard or it would be better to add yet another connector for trigger signals and ignore IOs defined in the standard?
The basic configuration requires 5 LVDS signals and 1 MDR/SDR connector, basic/full requires another 5/10 LVDS lines and second MDR/SDR connector.
With schematics I published we fully support basic/medium configuration and it takes 1 EEM for basic and 2 EEMs for medium version.
We can still maintain such connectivity utilising free LVDS lines (without single ended to LVDS conversion) in second EEM but in such way there won't be full support for base mode with 1 EEM.
We can also use remaining LVDS channels in second EEM and route them to optional trigger connector. Pinout is here, page 20.

[jordens]

Thanks @gkasprow That was quick as usual!

The following are really low priority. IMHO even the small amount of additional layout or stuffing work is not worth it:

• Having access to CC or SerTx/SerRx or Full Camera Link.

• Let's also drop the single ended use of the EEM lines.

• Medium Full Camera Link. I am not aware of any camera that would be useful to us that can do that.

• Overall let's just go with the layout as listed in the wiki entry. That gets rid of IC1,2,3,4,5,6,7.

[jordens]

My reasoning against the use of single ended EEM lines for the CC LVDS lines is that they could be fast. Also using them single ended makes supporting different EEM modes on the FPGA with a single bitstream impossible AFAIK because we can't switch IO standards at runtime.
Let's just support either CC0/1/2 or CC0/SerTx/SerRx on the three remaining pairs of the first EEM connector.

• Label EEM connectors according to the specification (A and B)
• RX_EN can be fixed IMHO since the FPGA pins need to either be tristated until the board is identified or need to be fixed inputs when there is no autodetection.

[hartytp]

Thanks for doing that @gkasprow!

AFAICS, from the hardware perspective this looks finished; the rest is gateware from here. Can we close this and handle the rest with ARTIQ issues?

[jordens]

@gkasprow great!
Is length matching (among the X and among the Y) required here? I guess there are some 100 ps of margin or so.

Other than that this looks good to me and can be closed as per @hartytp 's suggestion.

[gkasprow]

Once you are ready, we can produce 4 pieces and ship to you.

[kkumarumeshsharma278]

If I want to connect this grabber to an FPGA via LVDS, do I need only a receiver, or just a transmitter and a receiver?

Is this grabber cameralink supported for Ultrascale plus FPGA ?

[gkasprow]

This board is a camera link receiver only. It has some transmitters but only for UART control lines.
The only support that I'm aware of is for 7-series FPGAs

[SaeedHassan243]

Example CameraLink to SFP adapter is here There are a few other producers. Never used them and don't know anything about protocol.

Some time ago I designed simple FMC with Medium camera link interface. I have 2 pieces in my lab. It supports both IOSERDES mode and DS90CR288AMTD/DS90CR287MTD and can be assembled either as transmitter or as receiver. If someone is interested I can publish the project. It can be modified to support Full CameraLink configuration. .

Hi, is there any update on this? I was looking for something like this. Where can find this repo?

Thanks

[gkasprow]

@SaeedHassan243 the design is here
FMC_CamLink_PCB_v1.5.zip

[SaeedHassan243]

Hi, Thanks for sharing the files. I will check them in detail

Do you have any firmware with which you verified this hardware? maybe some RTL files. It would be helpful if you can share those as well. And sorry for commenting on the closed Issue

Thanks

[gkasprow]

No, It was long time ago and the firmware was written by another institute