notes.md

Project notes

What's this about?

I want to be able to use linear CCD imagers in my further projects.

Be it for scanned linear cameras, spectrometers, positioning systems or whatever I feel like.

This project's main goal is to figure out how'd I do that, with as raw a CCD chip as possible, to open up the widest range of options for the future projects.

If you are replicating this

Do NOT

• Do NOT use the iCE5LP4K FPGA that I used. Even if you don't know what you're doing and want to just get something running with my exact files. DO. NOT.
  • At the time of writing, it and its series has NO support by the open source FPGA toolchains.
  • You'll be stuck with the awful Lattice iCECube2 "IDE".
  • You WILL regret this.
  • USE LITERALLY ANYTHING ELSE that you're actually familiar with using.
  • I have no idea why I went with this particular FPGA.
  • Could be in part to do with Lattice's confusing naming scheme, which calls these FPGAs iCE40 Ultra™ Family. It seems NOT to be part of the iCE40 family, no matter what marketing says.
  • If you aren't, start with some other FPGA that is supported by the
  • I'm only using this because I have a couple boards with these that fit into a breadboard, which it keeps the wiring tidier at the cost of pain elsewhere.

Do

• Be prepared to lose several good working CCDs to ESD, especially when just randomly breadboarding.
  • Buy more than 2, just in case.
  • CCDs seem to be exceptionally static-sensitive, behave accordingly.

Goals

The goals of this project are as follows:

• Get a linear CCD running, showing some image data on an oscilloscope
  • Create some prototype driver for this linear CCD
    • I wish to use a TCD1706 linear CCD.
      • Reasonably priced on AliExpress
      • Excellent resolution: 7400 elements (4.7µm × 4.7µm squares)
      • Other Toshiba CCDs seem to use very similar drive waveforms
    • I wish to be able to use my custom FPGA dev board; at least for the timing generation
      • I just so happen to have a couple on hand
      • Based on small Lattice iCE5LP4K FPGAs
      • Should™ be good enough for timing generation for early experiments
    • I will likely need to use some driver ICs to drive the large capacitance pins
      • I have some TC4426~TC4428 on hand.
        • Cheap and cheerful
        • Two channels per package
        • The specs seem to be reasonable
    • Actual goals:
      • Timing generation with FPGAs
        • Stay within timing margins for the CCD
      • Robust enough electrical design
        • Pretend EMI is not a concern, until it is
        • Ideally support all 5, 10, and 12V drive levels
        • Buffer CCD outputs
        • Be goddamn sure of ESD safety next time
        • Be sure that the drivers can sustain the load well
          • Current TC4426~TC4428 may only stay within thermal specs driving the main CCD clocks up to about 1.2MHz.
          • To go faster, one has to find:
            • Some way to parallel the drivers
            • Some drivers that are actually cool-able; the TC442x can easily drive 700p loads to 5MHz or so, but it sure gets toasty.
            • Some better drivers altogether meant to drive these loads at these speeds
      • Figure out what sampling rates/timings should one use based on exposure levels
        • Configurable timing generation would be a big plus
• Capture image data at as fast a framerate as possible
  • Some FPGA-based capture system
    • Fast ADCs to sample the CCD waveforms
      • I have obtained several AD80066 fast ADCs/CCD signal processors.
        • 16-bit, 24 MSPS, 4-channel beasts
        • CCD-ready front-end with weird correlated double sampler magic. No idea what that is, but it might help!
    • Buffer to on-board memory
      • Probably use some bigger FPGA, like the Artix7 FPGA board that I also have on hand
      • Or maybe the CYUSB3KIT-003?
    • Send/stream to PC
      • I have obtained a CYUSB3KIT-003 for USB3 streaming experiments
      • Has some funky state machines on-chip
      • Can use external memory for buffering more stuff
      • Maybe I don't even need an FPGA!

CCD notes

Some notes about CCDs I've either found out or read about so far:

• CCDs are supposedly very static-sensitive. I see nothing on the output of mine so far, meaning I, or someone where I've ordered the parts from, might have screwed up.
• CCD timing/waveform specs are non-negotiable. It just will not work unless you do what the spec says.
• CCD timing/waveform specs are still somewhat imprecise. The datasheet doesn't tell you what to do and what to watch out for in actual words. Always check your assumptions.
• Odds are you may need to keep the CCD clocks running all the time, else bad things happen.
• CCDs may easily over-expose. It may be a good idea to put alu foil over the whole sensitive area and all around, to prevent light leaks, until the actual timings are figured out and debugged enough.

Timing waveform notes

• The clocks run the entire time, unless the whole SH-high stuff happens
• Configurable values:
  • tINT
  • clock period length
  • RS pulse length (~t9)
  • CP pulse length (~t13)
  • distance between starts of RS/CP (~t16)
  • SH pulse width (t3)
  • distance between stop of RS/CP/ø and start of SH (t1)
  • distance between starts of SH and the whole RS/CP/ø release (t5)
• Intrinsic values:
  • Rise/fall times (t2, t4, t6, t7, t8, t10, t12, t14)
    • Depend mostly on drivers/pin capacitance
      • May be tweaked with RC networks or other analog sorcery
• Important things to watch out for other than timings:
  • ø1 vs ø2 cross point
    • Not heeding this recommendation will result in spilled electrons (or something) and loss of captured image.

Implementation notes

• The widths of RS (t9), CP (t13) and clock shall be derived directly from a master clock

  • Likely 48MHz (20.83ns) clock, based off the iCE5LP4K's internal clock

• tINT may be given in clock periods to keep the counters short

• How does one actually implement it then?

  • State machines!
    • Trigger "clock" state machine building the RS/CP/clock pulses every cycle
    • Trigger the "capture" state machine building the SH pulse and requisite "clock muting" periods
    • Probably the more sane thing to do
    • + Likely a better use of FPGA resources (fewer, reusable counters)
    • - Not quite as obvious, modification more difficult
  • "Timing blocks"
    • Building blocks with triggerable functions, such as:
      • Delay by N cycles
      • Pulse of N cycles
      • Repeat after N cycles
    • + Cute, easy to visualize/conceptualize and modify
    • - Likely not the best use of FPGA resources
    • + Easily testable small units
    • + May be used as a reference implementation to test the state machine-based implementation against!
    • ~ Try this first, see if it fits. If it doesn't, use SMs.
      • Nope, it's stupid. Use a state machine like a semi-normal person.

• RS/CP pulse widths are on the same order of time as the reference clock.

  • RS/CP pulse width: 10~200ns typ.; 20ns reference clock -> 0.5~10 clock cycles.

• List of signals to be driven:

  • SH (50 pF × 1 ⇒ 50 pF)
  • ø1 (300 pF (A) × 2 ⇒ 600 pF)
  • ø2 (300 pF (A) × 2 + 20 pF × 2 (B) ⇒ 640 pF) (complement of ø1)
  • RS (20 pF × 2 ⇒ 40 pF)
  • CP (20 pF × 2 ⇒ 40 pF)

• Driver layout:

  • IC 1: TC4428A
    • Comp A: ø1
    • True B: ø2 (not ø1)
  • IC 2: TC4427A
    • Comp A: SH
    • Comp B: — (not connected)
  • IC 3: TC4427A
    • Comp A: RS
    • Comp B: CP

Driver notes

• I have 3 variants of the driver IC on hand:
  • TC4426
    • Both channels are inverted
  • TC4427
    • Both channels are true (non-inverted)
    • Annoyingly, I've only got these in SOIC, not DIP.
  • TC4428
    • Channel A is inverted, channel B is true

Build schedule

• Verify that I can actually get the CCD running
  • See that the FPGA and the FPGA programmers work.
    • See WiProg
  • Work on the timings code. Testbench it before deploying, dummy.
  • Deploy, using capacitors as simulated loads for the drivers. CDon't touch the CCD yet, dummy.
    • Make sure that no constraints are violated, use an oscilloscope.
  • If all looks okay, hook up the CCD.
    • Make sure that no constraints are violated, use an oscilloscope.
  • If there's some output from the CCD, you're all good. This part of the project is done.

This part of the project should™ thus be finished, for now.

However, I've managed to damage the CCD by removing its protective film, and accidentally touching some of its pins.

In the meanwhile, I can:

• Verify that the AD80066 AFEs are working
  • Hook up the ADC to the Artix FPGA board
• Verify that I can actually capture some CCD-like waveforms with this
  • Use the signal generator! It's got arb capabilities.
    • Draw up the waveforms as per the o'scope screenshots

And also:

• Design some PCB for the final CCD driver/sensor assembly
  • Toss in generous amounts of ESD protection everywhere.