[Gb-ccb] Notes from GB meeting 15-Jan-2004

[Tim Pearson]

Some notes from the Green Bank meeting on 15 January 2004.  Please
review these notes and let me know if I have gotten anything wrong or
if subsequent developments have changed any of this.

We also discussed the schedule: I'll summarize that in a separate
note.

- Tim


Noise calculation

  Martin and Randy still differ, and this needs to be resolved (action
  item for Martin). Not urgent.  Even if we substitute an ideal
  op-amp into the circuit we get a similar result, the result is
  dominated by Johnson noise in the resistors.  A good question was
  raised which is, do the detectors add noise?

Detector amplifier circuit

  We agreed that Rev H is acceptable, and the noise performance is
  adequate.

Single-channel prototype

  NRAO will proceed immediately with the construction of a prototype
  of the analog circuitry from detector to A/D.  This may be ready for
  testing in 4 weeks from today, but not with the correct Bessel
  filter (lead time: 5-6 weeks). Tests can be conducted with the real
  receiver detectors. Tests should include noise level and step
  response.  At the backend side of this circuit we'll use the AD4290
  evaluation board. Aside from the Bessel filters and perhaps the
  matched resistors, lead times shouldn't be a problem. We'll use a
  simple single pole filter or equivalent in initial lab tests. NRAO
  will purchase parts for the prototype and the Caltech equipment
  budget will be reduced accordingly.

Testing prototype

  It would be good to have some involvement from Caltech (mcs, tjp,
  student) in conducting and interpreting the tests - to help in
  planning the tests of the final system.

CCB circuit board (16 inputs)

  NRAO will start work on the layout of this board.  Critical input is
  the number and packaging of the FPGAs. We have tentatively agreed to
  use 2 FPGA's, each handling 8 channels. One can also handle the USB
  communications, and the other can also handle the control
  signals. Other parts are fully defined in Martin's document.

RFI filters

  Should be evaluated as part of prototype test? It was suggested that
  screw-in filters be used to allow selection and matching of filters
  in the final device.

Control lines

  Specification in Martin's document is acceptable.

Power management

  Investigate regulating the analog 5V supply on the board; this would
  require an external 7.5 V supply instead of 5V.

FPGA issues

  If we use a single FPGA, we will need to use a ballgrid array
  package requiring outside board assembly. We need at least ~ 260 I/O
  pins if we take all 15 bits from the A/D. If we drop the 3 lowest
  bits the count is reduced by 48. A preference was expressed for
  recording all 15 bits in the "fast-dump diagnostic" mode, but using
  only the 11 MSB in the accumulation - TBD.  The 15th overflow bit
  should be used to set a flag (or counter) in every 1ms integration
  output by the FPGA if one or more of the 100 ns samples had an
  overflow.

  An alternate design would use 2 or 4 FPGA's each handling 8 or 4
  channels. This would probably require an extra FPGA with a
  different program to handle readout to USB and the control signals.
  Using multiple FPGAs will ease the board layout (maybe) but
  complicate the FPGA programming.

  RFI shielding of the analog electronics from the FPGA is a concern.

  USB interface: Martin will acquire a USB interface chip kit and test
  whether it has adequate speed.

  Uploading the FPGA program. Not decided. We need to see if it is
  possible to program the FPGA(s) through the USB chip at a reasonable
  speed.  A < 20s load time is our goal. Loading from a PROM is
  acceptable (perhaps even desirable) for the production system, but
  tedious during development.

  We discussed providing a fast dump diagnostic mode.  This could be
  an alternate FPGA program, but more convenient as an option in the
  standard program.  A buffer of 20K samples (2 ms) in a selected
  channel has modest memory requirements. Options to select shorter
  dumps of 2 channels or 64 channels would be nice. Requirements for
  control software interface TBD.

  Development tools. Caltech will try to acquire Mentor under an
  educational license.  Otherwise we will use XiLinx's free (crippled)
  system, which should suffice.