Counter Specification

Scientific Objectives

This counter is intended to be a replacement for the existing ICC-based Adjustable Gate Counter. It will support two input channels and a trigger input. Each input channel is routed to three independent counters. The first is "ungated" and count all input pulses. The other two are "gated" and only count pulses which fall within a programmed gate interval.

On the ICC-based counter, the two gates were known as the "Fixed Gate" and the "Adjustable Gate" since the former was set with dip-switches and the latter could be dynamically modified via software. In this design, both gates will be set via software even though in actual use one will probably be kept at a constant value.

The gates are defined by three parameters: the trigger pulse, a programmed delay and a programmed width. These counters have limited bandwidth, but it turns out their useful dynamic range can be extended by further limiting their bandwidth in a predictable fashion. By accepting at most one pulse per trigger, we can accurately extrapolate the correct number of events. If there are M triggers within a particular period of time and G pulses are counted (allowing no more than one per trigger), then the extrapolated true event rate is

        N = -M * log(1 - G/M)

There are two gates on the board. The first gated counter on each channel is gated by the first gate and the second gated counter on each channel is gated by the second gate. Since the number of trigger pulses is required in the expression above, the trigger input will also be directed to a counter. Hence, the total number of counters on the board will be seven; three counters for each of two channels plus the trigger counter.

At a minimum, these will be 16-bit counters. However experience has shown that more than 16 bits would be very useful on the ungated counter of each channel. Since the gated counters get fewer counts, they won't require more than 16-bits, and the trigger rate is the laser repetition rate which is not expected to exceed the 16-bit limit. As such, we will plan on providing 20-bits for the two ungated counters.

Programming the Gates

Each gate is programmed by writing a 16-bit value to the gate's configuration register. The most-significant 8-bits determine the delay and the least-significant 8-bits determine the width of the gate. These values are latched in the configuration register and routed to AD9501 programmable delay chips, which can produce delays proportional to the digital input. The resolution can be adjusted on a per-board basis. However, care should be taken to make sure the required ranges are achievable in a particular implementation.

Software Interface Motivation

A counter design faces competing requirements from hardware, software and science. The simplest design for hardware and software is one in which the counters are latched and read under software control. Unfortunately that approach has very poor scientific performance, since the integration period can vary widely due to interrupt latencies and competing demands on the processor's time. In an earlier experiment, we measured the standard deviation of the integration time of such a counter to be approximately 10% with maximum deviations approaching 100%.

So it is clear that the integration period must be controlled by hardware. To make the counters useful in more than one application, this integration period should be programmable at least within the range of 1 Hz - 16 Hz.

A hardware integration period leads to the next question; how to reliably read these counters into a telemetry stream. The simplest hardware solution is to produce an interrupt whenever the counters are latched. The software can then use the counter collection rate to drive the entire telemetry frame. This approach meets the basic scientific requirement and provides a simple hardware solution, but it presents many problems to the software. The counter may not be highest-rate channel to be collected, and if there are two or more counter boards (a likely scenario) there are competing definitions of the true collection rate. The usual implementation under this configuration is to define the telemetry stream based on some independent time base, possible the CPU system clock, read the counters based on their interrupt and report the last value read. This works, but still has problems; if the telemetry rate and the counter rate get badly synched and the report time and the latching time are nearly simultaneous, variations in the software report time will result in the same value being reported twice and other values being ignored completely. In addition, the interrupt service presents addtional load on the system, resulting in more variation in the collection times of other channels.

We have come up with a solution which appears to be a good compromise all around. We leave the software to read the counters from the hardware at its independently-determined rate, we latch the counters based on a hardware integration period, and we provide a hardware mechanism to synchronize the two rates.

Ideally, we would latch the counters just prior to reading the first counter and we would finish reading all the counters before the counters are latched again. This synchronization scheme attempts to do just that. If any read occurs outside that window, a resynchronization is triggered, moving the latching time to a "safe" region.

Counter Status

Counter status can be obtained by reading from the base address of the board. This status word includes synchronization information as well as a sticky overflow bit for each counter.

[Wennberg, et. al.] P.O. Wennberg, R.C. Cohen N.L. Hazen, L.B. Lapson, N.T. Allen, T.F. Hanisco, J.F. Oliver, N.W. Lanham, J.N. Demusz, and J.G. Anderson, Rev. Sci. Instrum. 65, 6 (1994)