CDX SYSTEM AND HARDWARE DESIGN

Synopsis: concatenated cdxsys and related reports.

• [Stepper Motor Controller]
• [CD3200-Class Instrument I/O]
• [Excerpts From Ad46]
• [System Design Report 1]
• [System Design Report 2]
• [System Design Report 3]
• [System Design Report 4]
• [System Design Report 5]
• [System Design Report 6]
• [VPM Requirements]
• [System Design Report 7]
• [System Design Report 8: meeting minutes]
• [System Design Report 9: meeting minutes]
• [System Design Report 10: meeting minutes]
• [System Design Report 11]
• [System Design Report 12: meeting minutes]
• [System Design Report 13]
• [System Design Report 14: meeting minutes]
• [System Design Report 15: meeting minutes and email]
• [System Design Report 16: meeting minutes +]
• [System Design Report 17: meeting minutes]
• [Report 18]
• [Report 19]
• [Report 20]
• [Report 21]
• [Report 22]
• [Report 23]
• [Report 24]
• [Report 25]
• [Report 26]
• [Report 27]
• [Report 28]
• [Report 29]
• [Report 30]
• [Report 31]
• [Report 32]
• [Report 33]
• [Report 34]
• [Report 35]
• [Report 36]
• [Report 37]
• [Report 38]
• [Report 39]

CDNEXT-APU/FPM STEPPER MOTOR CONTROLLER

9/19/99

[CD3200-Class Instrument I/O]

Synopsis: design description of proposed stepper motor control system hardware and software.

MOTOR.DOC (Word 97 @ k:\cdx\doc\analyzer)

David McCracken

OVERVIEW

1. 14 two-phase stepper motors will be supported.
2. Step timing resolution for all motors will be at least 32 usec. No motor will experience more or less resolution than this and there will be no jitter; if appropriate, all 14 motors may step simultaneously.
3. The control system will comprise a relatively high level program executed by a general-purpose microprocessor (expected to be the MC68340 in the FPM unit) and microcode-like commands executed by a state machine implemented in programmable logic (expected to be the main FPGA in the FPM).
4. The high-level program will convert motor move commands into microcode commands that provide direct motor control patterns. These will be written at an indeterminate rate into memory shared with the FPGA, which will, in turn, transmit them at a fixed rate to the motor drivers via the motor (bit-serial) scan chain.

The scan chain is implemented as a buffered array of 56 bits embedded in the FPGA. Buffering allows the scan chain to be written at any time without disturbing the pattern currently being serially shifted out. The input registers of the scan chain are mapped into the microprocessor's memory space.

Each motor is controlled by four bits of the scan chain. Two bits select power and two select a motor winding phase pattern (a two-phase motor has four phase patterns). When the power selected for a motor changes, the microprocessor writes the power selection directly into the scan chain in the FPGA. The FPGA continually writes the phase pattern bits into the scan chain as it interprets the microcoded program prepared for it by the microprocessor. Under normal operation, the microprocessor never directly writes to the phase pattern bits in the scan chain.

The scan chain shift clock operates at 2MHz. Thus, all 56 bits are shifted out to the motor drivers in 28 usec. The scan chain requires an additional 4 usec. for housekeeping, resulting in 32 usec. for one complete scan image update to take place. After the image is serially scanned out, all bits are simultaneously broadside loaded into the actual outputs.

While one scan chain image is being shifted out, the FPGA creates the next image. Each image represents the scan chain state for one 32 usec. period. The microprocessor finishes preparing a microcode program comprising 256 periods (8.192 msec. total) before the FPGA is allowed to execute it. To enable the FPGA to continually update the scan chain, a pair of ping-pong memory buffers are used. While the FPGA executes the program in one buffer, the microprocessor writes the program for the next 8 msec. into the other.

The microcode program is very low level, comprising time-stamped motor control patterns which effect stepping. Thus, the microprocessor must be continually engaged in controlling the motors. The "motor control" portion of FPGA serves only as a time shifter and to synchronize to the scan chain. Only the power bits are of a "set and forget" nature.

DESIGN

MOTOR DRIVERS

Each motor driver comprises a relatively sophisticated circuit, such as two (one for each winding) Ericsson (or Rifa, SGS-Thompson, and others) PBL3717, which translates the two power bits into actual power levels and the two phase bits into the four phase patterns.

The power bits are called I0 and I1. They select the power level as follows:

• I1/I0 = 00 => High power.
• I1/I0 = 01 => Medium power.
• I1/I0 = 10 => Low power.
• I1/I0 = 11 => Off.

The phase control bits are called PH0 and PH1. Each controls the direction of current flow in one of the motor's windings. The output drivers are full bridges, whose motor terminals are arbitrarily called A and B. When the phase bit is 0, positive current flows from B to A; when 1, from A to B. Motors are connected to the drive terminals such that the controls operate as follows (for full-step, two phase on motor drive):

1. For clockwise (CW) rotation:

1. PH1/PH0 = 00 (0)
2. PH1/PH0 = 01 (1)
3. PH1/PH0 = 11 (3)
4. PH1/PH0 = 10 (2)

2. For counter-clockwise (CCW) rotation:

1. PH1/PH0 = 10 (2)
2. PH1/PH0 = 11 (3)
3. PH1/PH0 = 01 (1)
4. PH1/PH0 = 00 (0)

The drivers are connected to the scan chain in nibbles (groups of four) as follows:

• 0/4 = PH0
• 1/5 = PH1
• 2/6 = I0
• 3/7 = I1

Each motor's control nibble is located in the scan chain at the motor number times four. For example, the control bits for motor 9 are: 36 = PH0, 37 = PH1, 38 = I0, 39 = I1.

MICROPROCESSOR-FPGA INTERFACE

All 24 address bits and 16 data bits of the microprocessor are connected to the FPGA. The FPGA is selected by the microprocessor's CS3, which may be mapped to any address but which has been mapped to 0x00500000 through 0x005FFFFF (1 Mbyte).

Some of the flip-flops in the FPGA are assembled into control and data registers that the microprocessor can directly read and write. The motor scan chain input register is one of these. The FPGA's motor control logic also writes into the motor scan chain, suggesting that the input register would have to be dual-port. However, only the microprocessor writes to the motor power control bits and only the FPGA motor logic writes directly to the phase control bits in normal operation. The power control bits clearly do not have to be dual-port. However, under test situations, being able to directly write to the phase control bits without FPGA intervention could be useful.

The microcode program prepared by the microprocessor for the FPGA motor control logic to interpret requires at least 2 Kbytes of RAM (preferably 4 Kbytes). This is too much memory to be implemented by FPGA internal resources. External memory must be used. Two architectures are feasible, DMA access to main memory and a dedicated RAM that the microprocessor accesses through the FPGA. The DMA approach uses considerably fewer FPGA resources, as the DMA request/grant facility of the microprocessor provides more than half of the multiplexing circuitry. The dedicated RAM not only consumes at least 21 FPGA pins (8 data, 11 address, RD, WR, CS) but also the internal resources to support all of the multiplexed access means. The DMA approach steals time from the microprocessor, which the dedicated RAM approach does not do. However, the overall effect of this should be nearly inconsequential, due to the microprocessor's instruction pipelining and the fact that there are no other bus masters. From a software viewpoint, the two approaches are essentially identical, with only minor addressing differences.

As already explained, two microcode programs exist simultaneously, one being written by the microprocessor and one being executed by the FPGA. The program describes 256 32 usec. periods in one 8.192 msec. period. It is divided into two parts, a fixed 256-byte event count array and a variable event array. Each element of the event count array tells how many step events occur in the corresponding time slice. All of the events that occur in one time slice will occur simultaneously one (possibly two) scan chain cycle (32 usecs) after the event count is interpreted. After processing the 256 event count elements of one program, the interpreter immediately continues at the beginning of the other program.

An event count value of 0 indicates that there is no step activity in the 32 usec. time slice. The interpreter performs a read-modify-write on each event count byte, latching its current value and replacing it with 0. The purpose of this is to clear the program memory for reuse. The microprocessor could do this but it can be done more efficiently by the FPGA. Thus, the microprocessor only needs to write active event count elements, i.e. time slices in which one or more motors experience a step (phase change). The read-modify-write cycle should be reduced to just read when the current value is already 0 if this can reduce DMA hold time. However, it may actually be faster to always write the 0 without considering the current value.

When the event count is 0, it is not necessary to clock out the scan chain, unless the microprocessor has written to any of the power control bits. Not clocking the scan chain reduces power and electrical noise, but the logic to determine whether to do it may be excessive for the rather minor benefit. The motor drive system itself is unaffected by redundant updating.

When the event count is not 0, the microcode program interpreter (motor control state machine) reads the event or events from the event array. Each element (byte) of the event array tells the logic value of one of the phase control bits. Bits 0 through 5 select a scan chain bit address, which will always be one of the phase control bits, e.g. 0, 1, 4, 5, 8, 9, etc. Bit 6 is unused. Bit 7 tells the value for the selected bit. Phase control patterns require only single-bit changes to effect a step.

Like the event count array, the event array is ordered by time, but it does not exhibit the same strict association of time slice to array element. The interpreter maintains two pointers, one that iterates through the event count array at a constant 31.25 kHz (1/32usec.) rate and one that steps through the event array only as directed by the event counts. For example, assume that the beginning of the event count array is:

Call the event count pointer (implemented in the FPGA state machine) ecp and the event pointer ep. The event array is located immediately after the event count array so this means that ep equals ecp plus 256. Assume that the event count array begins at 0x100 and the event array at 0x200. Further assume that both ecp and ep point to the next element and are incremented after use (post-increment). At each 32 usec. period the motor control state machine operates as follows:

1. Initially, ecp = 0x100 and ep = 0x200.
2. In the first 32 usec. period, ecp increments to 0x101. The 0 at 0x100 is overwritten by another 0 if the read-modify-write is unconditional. Nothing else is done; ep doesn't change.
3. The second period is identical to the first except that ecp advances to 0x102. Although the event count at this address is not 0, nothing else occurs yet due to the post-increment assumption.
4. In the third period, the event byte at ep (0x200) is interpreted to write (0 or 1) to one scan chain bit. The event count byte at 0x102 is overwritten by 0. ecp advances to 0x103 and ep advances to 0x101.
5. In the fourth period, ecp advances to 0x104.
6. In the fifth period, the events at 0x101, 0x102, and 0x103 are interpreted to write to three bits of the scan chain. The event count byte at 104 is overwritten by 0. ecp advances to 0x105 and ep to 0x205. It is only a coincidence that ecp and ep have both advanced by the same amount at this point.
7. After interpreting the last event count in this example (i.e. after the nineteenth 32 usec. period) ecp = 0x114 and ep = 0x20B.

The main job of the state machine, done once in each 32 usec. period, is straight-forward:

1. Read the next event count at ecp and latch the value into a 4-bit down counter.
2. Write 0 to the byte at ecp.
3. Increment ecp.
4. While the (4-bit down counter) event counter is not 0 do:

1. Read the byte at ep.
2. Use D0 through D5 to select one of the motor scan chain bits and assign it the value of D7.
3. Increment ep.
4. Decrement event counter.

In many periods, the FPGA needs to access the microcode memory only one time, to read a 0 (although the read-modify-write could be considered a 1.5 access). If one motor steps in a period, two accesses are needed, one to the event count and one to the event. In the worst case, all 14 motors experience a step in the same period, for which the FPGA must access the memory 15 times. Even this worst case should be easily achieved, especially given the static RAM used in the FPM unit. If, for some reason, the FPGA is unable to interpret all of the indicated events before the next scan chain update, it should interrupt the microprocessor, presenting an error code in a status register that the microprocessor can read.

The two microcode programs will both be located on page boundaries. When ecp reaches 0xxxFF, the current program is exhausted and the next one should be started. If the next one is the later one in memory, ecp could simply keep incrementing. However, if it is the lower one, then one or more of ecp's bits higher than 7 must be changed. In all cases, ep must be changed to point to the other program's event array. At the program change, the FPGA should interrupt the microprocessor and present an appropriate (i.e. different from any error codes) value in the status register. This will alert the microprocessor to the availability of the memory occupied by the exhausted program. It could be helpful if the status code would indicate which memory buffer, lower or upper were being made available, but the microprocessor can also keep track of this itself.

Although it would be possible to map the two microcode program buffers into fixed memory locations in main memory, it would be better to map them to addresses defined by software. Since the event count array is a fixed 256 bytes and the event memory immediately follows this, selecting an event count array address automatically defines the event address. If the buffers were a fixed size, such as 2K (2048 total with 256 bytes of event count and 1792 bytes of event) then selecting the lower buffer's address automatically defines the upper buffer's location. Thus, it is possible for one 24-bit address to define all four addresses. However, it may not be desirable to do this. For one thing, it would be better to allow the size of the event buffer to be controlled by software. The easiest way to do this would be to have separate addresses. The motor control state machine does not have to guard against reading past the end of the event array, as the software will do this. Therefore, the FPGA doesn't need to be informed of the size of event memory. However, the size of the low buffer event array determines the address of the upper buffer. If the size varies, then software needs to tell the FPGA the address to use for the upper buffer. Another reason for possibly having the microprocessor write a full address for each of the four arrays into the FPGA is that this may simplify the logic of the state machine for buffer swapping. Basically, at this point the ecp and ep pointers are loaded with the event count and event array addresses for one or the other buffer. The reload values are taken either directly from "reload" registers written by the microprocessor at boot time or from the one base address (register written by the microprocessor) plus hard-wired offsets. The former not only affords greater flexibility but also may be simpler. To summarize, the FPGA must provide at least one 24-bit register into which the microprocessor writes the starting address of the lower microprogram buffer. Preferably, two such registers will be provided. The microprocessor will write the address of the lower buffer into one and the address of the upper buffer into the other. The FPGA motor controller state machine will toggle ecp between these two addresses and ep between these addresses plus 256. If it simplifies firmware, the FPGA may provide another two registers into which the microprocessor will write the two ep addresses. The microprocessor writes these registers only when it initializes the system. The buffer addresses do not change during operation.

Software is the program executed by the microprocessor. Its job is to translate motor move commands and ramp definitions into the step event microcode. As long as a motor is active, the program must continually perform this translation, writing a new microcode program (one program for all active motors) every 8 msec. As previously explained, the FPGA motor controller only serves to time-synchronize the microprogram.

At each interrupt from the FPGA, the program reads the FPGA status register to determine whether the interrupt has been issued in response to a motor state machine error (or unrelated event) or because the current microprogram has been exhausted and its memory buffer can now be reused. If the latter then the microprocessor performs the core motor control task.

CORE TASK

The core task of the program is to determine the position (in time and, therefore, in the event count array) of every step of each motor in the 8 msec. period encompassed by the microprogram under construction. The simplest way to do this would be to iterate through the 256 elements of the event count array, examining each motor's condition and requirements to determine whether it should step at that 32 usec. time slice. If so, then that event count would be incremented and the appropriate event written to the current event address. The program would handle the event count and event pointers similarly to the program interpreter, except that the data at the pointers would be written instead of being read. In one time slice, the event count and the event pointer are both incremented for each motor that steps at that time.

The simple approach is inefficient because it requires the next step time of each motor to be repeatedly computed as the algorithm visits each time slice and it requires that every time slice be visited. Alternatively, after computing the next step time of all motors, the program could immediately jump to the event count element of the earliest step, skipping all intervening do nothing time slices (these have already been reset by the FPGA's read-modify-write). This approach requires a more complicated program but can significantly improve the execution time for average cases. For the worst case of every motor stepping at every time slice, the greater complexity yields somewhat slower execution. It should be noted that this worst case would require an event array of 3,584 bytes (256 * 14) which is twice as much as the suggested 1792 bytes (allocating 2K to each complete microprogram).

STEPS

The fundamental measure of a step is its duration in terms of the number of 32 usec. periods. For example, for a motor to operate at 250 steps per second, each step would have a duration of 125 counts. The average 8.192 msec. microprogram would contain slightly more than two steps for this motor. The number of residual counts for the last step of one microprogram is carried over into the computation of the first step for that motor in the next microprogram, thereby providing continuous stepping for a virtually unlimited amount of time even though each microprogram encompasses only 8 msec.

Steppers are not normally operated at just a constant rate but with a ramp up to that rate (which is called the slew rate if it is the maximum speed that the motor can attain in the mechanical system) and a ramp down to the final position. An up ramp is simply a list of decreasing step durations while a down ramp is a list of increasing step durations. All motors are controlled by ramp tables that define at least the constant ramp duration and optionally up and down ramps. Each up/down ramp entry tells the duration of one step, while the single constant speed entry tells the duration of every step in the constant speed segment of the trajectory. At each step, the position record of the motor (after it makes that step) is incremented for CW rotation and decremented for CCW rotation.

RAMP TRUNCATION

If a motor move command specifies a number of steps that is less than the total number of steps in the up and down ramps in the ramp table selected for the motor, the command interpreter will create a temporary ramp table that symmetrically removes the top (shortest steps) of both the up and down ramps so that the total number of steps equals the requested move. This is assigned to the motor for the duration of its move and then discarded.

CDNEXT: CD3200-CLASS INSTRUMENT I/O

9/20/99

[Stepper Motor Controller]

[Excerpts From Ad46]

CDX32IO.DOC (Word 97 @ k:\cdx\doc\analyzer)

Synopsis: Proposed partitioning of CD3200 I/O into a CD3200-class instrument based on APU and FPM units.

CONCEPT

The APU replaces CPUDCM, SPM, and MAM boards. Generally, any I/O related to these boards or to flow scripts will be placed on the APU I/O scan chain. The FPM replaces MPM, TWR, LDR, and FCM boards. I/O related to these boards or to TWR and LDR macros will be placed either on the FPM I/O scan chain or will be controlled by specialized hardware/firmware on the FPM board. All motors controlled by the MPM, TWR, and LDR will be placed on the FPM's motor scan chain.

The APU will execute the old flow scripts, converted to the new script language, while the FPM will execute converted TWR and LDR macros. FPM script command interpreters will natively access I/O and steppers on behalf of local scripts and provide remote access to these resources on behalf of the APU.

The fluid checks script will be moved from the APU to the FPM to enable the strobed fluid sensors to be accessed by a local script. In the event of fluid error, the FPM fluid check script will send a fault message to the APU in the same way that the TWR and LDR units send fault messages to the CPUDCM.

Remote I/O will be apportioned to individual boards to first minimize local wiring and secondarily to try to avoid having to connect individual boards to both the APU and the FPM I/O scan chains.

SPECIFIC DEVICES

"PB" = Peripheral Bus

FPM SENSORS

The fluid strobe may be assigned to a scan chain bit or addressed uniquely.

APU SENSORS

FPM ACTUATORS

APU ACTUATORS

There are three multistate devices and all of these are instances of the same type of device. These are pressure/vacuum regulators, which can be Opened, Closed, or Servoed. Their names are SecPress2, SecPress3, and SecVac2. These will be implemented by dedicated hardware/firmware on the FPM board. Preferably, the control signals will be mapped into the FPM's I/O scan chain but unique addressing is acceptable.

Located directly on FPM:

Dac CHANNELS = 1-32 RANGE = 0-4095

Adc CHANNELS = 0-99 RANGE = 0-4095

AdcBipolar CHANNELS = 0-99 RANGE = 0-4095

IoBus CHANNELS = 0-255 RANGE = 0-255

Gain, prescale, and threshold are addressed as unique devices on the APU.

DATALATCH = PB 72-79 (byte 30)

PERI_VACACC_WET = PB 88-95 (byte 32)

PERI_VPMMUX = PB 104-111 (byte 34)

PERI_VPM_CNTRL = PB 112-119 (byte 35)

UNIQUE DEVICE REQUIREMENTS

The strobed fluid sensors are capacitively coupled and require both a precharge and charge time. They are derived from the CD3000 FCM circuit, in which a signal triggers a one-shot that generates the 10 usec. charge time, during which each sensor charges a hold capacitor through a coupling capacitor. The hold voltages are compared to fixed thresholds. The comparator outputs are latched on the falling edge of the one-shot output, which also starts the precharge to prepare for the next measurement.

To reduce electrolysis of the sensors, they should be strobe as little as possible. The best way to do this is to not automatically read them but only in response to a read request from software. In the CD3200, the analyzer program decides when to strobe and subsequently read the sensors. In the APU system, the checks script being continuously executed by the FPM CPU will do it.

Software would be simplified if the strobe control bit would reset itself after being written. Then the script would only have to write once to the bit and later read the latched data. If this is inconvenient for hardware then the script can set the control and clear it, but the the control will have to be edge-sensitive, because the time between executing the first and second writes is indeterminate.

It would be convenient for software if the strobe and readback data were mapped to the scan chain. However, it is important that the data presented to the scan chain be latched, because there may be a substantial delay between the time that the strobe is written and the data is read. The raw output of the comparators changes too quickly after the end of the capture strobe to have any validity when the data is finally read.

HARDWARE-ASSISTED BUBBLE/EDGE DETECTION

HARDWARE ASSISTANCE FOR OBSERVE

To eliminate the CPU stalling effect of OBSERVE, we would like to replace all or part of the function with hardware. If this hardware can be made general-purpose, then we might also want to use it to improve the resolution of WATCH. Jack stated that OBSERVE and WATCH do not occur simultaneously but a review of the flow sequences shows that this is not correct. If WATCH is to take advantage of the same hardware assist as OBSERVE, the hardware must either be duplicated or designed in such a way that both command functions can use the same raw data. It is not clear why the program doesn’t already allow the WATCH and OBSERVE processes to share a common raw data source.

Dave R suggested that some kind of filtering of the raw data be used in any function to avoid false interpretation. John mentioned that there have been reports of instruments not detecting bubbles that are large enough to seriously degrade results.

Both David McCracken and Jack proposed hardware assistance based on the fact that the scan chain updates the I/O status every 132 usec. Jack suggested a circuit (programmed into the FPGA) with an XOR gate fed by the current value of the sensor and its previous value in order to detect any change (output = 1). David suggested a capture function, which would be essentially a one bit logic analyzer. To capture a trace of the activity on one input bit, the scan chain address of that bit would be passed to the capture hardware, which would copy the bit from that address in the scan chain sequentially into a bit array at the end of each scan (or some multiple of scans). A software function could subsequently examine the trace to determine the condition of the sensor using DSP (Digital Signal Processing) techniques to provide general and/or application-specific filtering.

Dave R said that the FPGA could provide one or two 1K bit arrays for the trace. Jack had explained that the OBSERVE can operate for as long as seven seconds, which would cause the trace array to overflow if the sensor were sampled at 132 usec. Dave said that this could be avoided by allowing the sample rate to be set to a multiple of the scan rate. David suggested that the high sampling rate could be used if the OBSERVE function were to periodically copy the bit array and reset the trace counter (or allow it to wrap). Jack suggested that the OBSERVE function process each captured period, determine the sensor condition for that period and then discard the raw trace.

At the 132 usec sampling rate, 1K (1024) bits would be collected in 135 msec, which is considerably longer than the worst case flow sequence instruction dispatch delay. Therefore, the hardware doesn’t need to provide selectable sampling rates. It would be helpful for software to be able to reset (or write) and read the trace counter as the simplest means of determining the beginning and end of each trace record.

LOW LEVEL BLOOD SENSOR MONITORING

Two general means exist for the low level monitoring: hardware assisted and pure software. We have considered two specific methods within each of these. In the hardware assisted means, we can either trace a sensor's state by recording its condition in a bit array (David McCracken's suggestion) or we can set or clear a single flag to indicate that the sensor changed state within some time period (Jack's XOR suggestion). In the pure software means, the CPU can be almost completely dedicated to the task (as OBSERVE does now) or sampling can occur at the normal flow sequence dispatch rate (approximately what WATCH tries to do now).

We cannot detect many small bubbles (smaller than 20 uL) entrained in the sample. Since results have been reasonable, we have to assume that this is an acceptable deficiency. To get the most detailed information that the ultrasonic sensor can produce, we would want to sample it every .2 sec. We have no information on the optical sensor's bubble response and will assume that sampling it at this same rate is sufficient.

From Jack's observations, sampling at the dispatch rate will only show 33% of the bubble events detected by the sensor. This may actually be acceptable and the improved flow sequence task dispatcher should significantly improve the sample rate. However, the dedicated CPU would see nearly all of the events. The existing system seems to be able to tolerate dedicating the CPU during sampling, but it is unlikely that the new FPM will be able to do this.

Combining the WATCH and OBSERVE functions makes it possible to have an effective dedicated CPU monitor, but the dispatched monitor affords greater flexibility by allowing other flow scripts to execute more quickly (at the expense of the monitor rate). It is not necessary to design either a dedicated or a dispatched monitor, because, in fact, they are nearly identical, the only difference being the duration of sampling without returning to the dispatcher. This time period can be a command parameter, with 0 indicating just one sample. This time would not necessarily coincide with the blood edge detector filter (currently fixed 40 msec) which should also be a command parameter.

The FPM needs hardware assistance to do the WatchBlood function. The intent of the trace method is to allow a DSP-like filtering of the bubble events, assuming that a single event does not necessarily indicate a sampling failure. However, given that we already are undersampling the bubbles, we probably don't need to be so discriminating. Also, we now know that we need to sample two sensors, which would consume a considerable amount of FPGA resources. Therefore, we will use the change detector hardware. If any change occurs on a monitored sensor during the time that it is supposed to see only blood, the WatchBlood function will consider the sample suspect. Given that this may be too severe, we will have to change the fact that the data station now considers short sample and bubble to be identical problems.

CONCLUSIONS

WATCH CALLBACK

In the CDM, if a blocking watch is active, the bubble detector can piggyback onto the continuous sampling time to get very high resolution at practically no additional cost (which is good considering that stable state detection consumes nearly 100% of foreground bandwidth). This is not true in the APU. The hardware assist only needs to record any single transition to conclude that the signal is not stable. But for bubble detection it needs to record the number of 0 samples and the number of 1 samples. These are two different functions. In AD16 – Observe and Watch Commands – Hardware Assist for Observe, I suggested a hardware trace function to reveal the pattern of bubbles while Jack advocated a change detector (based on XOR between each sample and the next). The single change function serves the stable state filter but not the bubble detector. However, the trace consumes significant hardware and software (to analyze the trace) to generate a picture that is more detailed than necessary. It would be much better for the hardware to count 1s and 0s on the two monitored sensors. If this is possible then it is all that is needed for both bubble and stable state detection.

HARDWARE-BASED DECIMATION

GATHER IMPLEMENTATION REVIEW

SINGLE-PASS AND HIGH THROUGHPUT ANALYZERS

Dave R has proposed decimating in the ADC-DMA subsystem. Combined with the APU3’s collecting of only selected channels, this would entirely eliminate the software parsing function, leaving dmaParse only the job of transferring data from the DMA buffer to the communication system. This could also reduce coincidence if the hardware can convert the decimation determining channel first and not convert the others if the cell is to be discarded. Dave even suggested having hardware insert the raw data directly into communication buffers, but this would seem to be considerably more complicated than a data comparator. Never the less, it may be needed in order to achieve the desired performance level.

HARDWARE-BASED DECIMATION

OVERVIEW

The gather process collects list data by transferring ADC output data to a memory buffer, called the dma buffer, via DMA and subsequently parsing this data to create message packets that are sent to the data station. Parsing is done by a periodic software function. Parsing optionally includes decimation, a process by which the amount of list data of a predominant fraction of a sample is reduced without reducing other (usually one) fractions. For example, the amount of RBC list data might be reduced five-fold, without affecting the PLT list data count, by discarding the data associated with four of every five apparent RBC cells. Decimated cells are identified by the value of the data in one channel, which is normally a measure of the light refracted by the cell at a particular angle.

Decimating in the parse function is fairly expensive. First, it means that time is wasted converting (by ADC) and storing (by DMA) data that will ultimately be discarded, thereby increasing coincidence and potentially reducing the maximum gather rate. It also means that the dma buffer memory is used inefficiently to store data that will be discarded. Finally, it imposes a heavy processing burden on the parsing function, which may not be able to keep pace with raw data collection.

REQUIREMENTS

Decimation requires the following information:

1. The data channel used to determine whether to decimate. The maximum range of channels currently is 1 to 7, which could be identified by 3 bits. However, the script API uses a bit-mapped word to select channels 0 through 15 in order to be ready for more complex systems.
2. The upper and lower thresholds of a window that identifies the decimated fraction. These are 16-bit values. Any cell whose data in the determinant channel lies within this window (greater than or equal to the lower threshold and less than or equal to the upper threshold) is to be decimated.
3. The decimating factor. For example, 5 means to decimate by 5, i.e. to discard all channel data for 4 of every 5 cells identified for decimation. It is unlikely that any value greater than 63 would ever be used but the script API uses an 8-bit value for this, supporting a range from 1 to 255.
4. The maximum number of cells in the undecimated fraction to be collected. This is a 32-bit value in the script API, affording a limit of 4B, but a 16M range, i.e. 24-bits, would suffice.
5. The maximum number of cells in the decimated fraction to be evaluated or collected. The script source and message languages tell the number of cells to be evaluated, as decimation is largely transparent to the script writer. The parse function also uses the evaluated rather than collected count. Another implementation, including one in hardware, could count collected cells using the count to be evaluated divided by the decimation factor. This parameter requires the same range as the maximum undecimated count.

HARDWARE SOLUTION

It would be feasible to replace the decimation process with equivalent hardware located between the ADC output and the DMA controller. The control parameters listed in the preceding section could be implemented in registers programmed by the gather command interpreter, procGather. The two maximum count values can be loaded into registers that are counted down toward 0. However, the programmed decimation factor must be retained for reloading, so an additional 8-bit (possibly 6-bit) counter would be needed for decimation cycle counting.

The window comparator is trivial. Using its result, however, may entail some complexity. One potential source of complexity is the need to base the decimation decision on a channel that can be selected at run time. Converting this channel before any other affords the greatest efficiency but impinges on the channel selection mechanism. This approach also introduces the problem of where to store the data from this channel relative to the other channels. Typically, the channel used for the decimation decision is also selected for storage (although this should not be assumed). If, by coincidence, this is the first channel normally stored then the value could be stored in the dma buffer immediately after being used by the comparator. Then the remaining selected channels could be converted and stored. However, if it is not normally the first channel stored, it would be better to retain the value and store it in its normal position relative to the other channels. If this behavior is too difficult to implement efficiently in hardware, then the data station will have to be programmed to unscramble the channels, possibly by literally rearranging the list data but, more likely, by assuming a different channel ordering for some types of cells. If the out-of-order storage approach is taken, it should be used for the undecimated as well as the decimated fraction so that the two fractions can be manipulated together without having to normalize one of them.

With software-based decimation the data parsing function counts both fractions and terminates the gather if both reach their specified maximum count. When not decimating, the parse function relies on the DMA TC ISR to stop collecting and to mark the end of the raw data for the current gather (the ISR calls setDmaEnd to do this). Much of the benefit of hardware-based decimation would be lost if the parse function were required to count the two fractions. The program would be most consistent if the DMA TC ISR could take responsibility for ending the collection phase in all cases. The ISR executes only when the DMA reaches a predetermined count (BTC counts down to 0). Without decimation, this is simply the maximum specified count, possibly with intermediate steps to avoid collisions. With decimation in software, the DMA is programmed to count more than both fraction maxima combined in order to guarantee a sufficient supply of raw data for both fractions. Hardware-based decimation affords a means to stop collecting immediately when both fractions reach their maximum counts. Ideally, when hardware detects that both fractions have reached their maximum counts (actually counted down to 0) it would generate an interrupt that would provide an opportunity for an ISR to terminate the collection phase. For greatest program efficiency, this IRQ would not be the same as the DMA TC, whose handler must sort out the several possible causes for being invoked. However, it would also be feasible to share the DMA IRQ, with the decimation hardware providing an end count flag that the ISR could read to determine whether this was the source of the interrupt.

The ideal decimation behavior can be described as follows:

1. Gather begins with all of the control parameters loaded into registers and the decimation cycle counter initialized to the factor value. If there is an end count flag, it should be false. At each cell event do the following:
2. Convert the decimation decision channel first.
3. If the decimation channel reading is greater than or equal to the lower threshold and less than or equal to the upper threshold:

1. If the decimated cell count is 0 then abort collecting this cell.
2. Decrement the decimation cycle counter.
3. If the decimation cycle counter is 0 then:

1. Reload the counter from the decimation factor register.
2. Convert the remaining selected channels, storing the results at successive locations in the dma buffer with the decimation selection channel data that has already been converted stored in its normal position relative to the other channels.

4. Else the cycle counter is not 0. Abort collecting this cell.
5. Decrement the decimated cell counter. If it becomes 0 and the undecimated counter has also reached 0 then:

1. Set the end count flag (if there is one).
2. Generate the end count interrupt.

4. Else the data lies outside of the window.

1. If the undecimated cell count is 0 then abort collecting this cell.
2. Convert the remaining selected channels, storing them and the decimation selection channel data in their normal positions.
3. Decrement the undecimated cell counter. If it becomes 0 and the decimated counter has also reached 0 then:

1. Set the end count flag (if there is one).
2. Generate the end count interrupt.

EXCERPTS FROM AD46

Sept. 30, 1999

[CD3200-Class Instrument I/O]

[Report1]

k:\cdx\doc\analyzer\ad46.doc

SYSTEM DESIGN REVIEW MEETING 46

The interim system architecture erroneously assumed that the FPM would be responsible for nearly all control functions, but to allow CD3200 flow scripts to be reused, the APU should control everything that had been accessed through the Peripheral Bus. These items should be located on the APU's I/O scan chain.

The interim APU-FPM partitioned the systems into the following boards:

1. APU

1. 12" * 6" in the 4-channel version. 72 sq. in.
2. Located on the swing-out cardcage.
3. Provides functions related to gather, including main amplifier control and cell counting. Communication with Data Station.

2. FPM

1. 9" * 6". 54 sq. in.
2. Located on the slide-out Pneumatic Unit.
3. Vacuum/pressure subsystem related to Pneumatic Unit, including the five pressure/vacuum transducers.
4. Stepper motor control (motor scan chain controller).
5. I/O scan chain control of Left and Right Panel Boards.

3. Left Panel Board

1. 10" * 7". 70 sq. in. Sparsely populated in the middle. Periphery nearly consumed by connectors.
2. Located on the inside left panel plate, which separates the board from the solenoids on the left panel.
3. Provides 32 drivers for the 25 left panel solenoids plus spares.
4. Routing point for the FPM I/O and motor scan chain to the Tower Board.
5. Peristaltic Pump (stepper) driver interface.
6. Strobed fluid sensor circuits.
7. Simple sensors:

1. CS model door.
2. RBC Diluent Overpressure.
3. Vacuum Accumulator 1 Wet.
4. Vacuum Accumulator 2 Wet.

4. Tower Board

1. 2.5" * 6". 15 sq. in. total with 2.5 sq. in. consumed by scan chain interface (connector and single-differential translators).
2. Located outside of the main box on the side of the tower mechanical frame. Connected to the Left Panel Board through a hole near the top of the left front panel.
3. Tower mix motor (stepper) driver.
4. Tube spinner DC motor driver. This is not correct-- it will be replaced by a stepper.
5. Simple sensors:

1. Tower Height.
2. Tower Home 1.
3. Tower Home 2.
4. Door Open.

5. Loader Board

1. 5.2" * 5". 26 sq. in. total with 4 sq. in. consumed by scan chain interface.
2. Located in the loader unit. Daisy chained to the FPM I/O scan chain (two 16-pin ribbon cables).
3. One stepper driver interface.
4. Four solenoid drivers.
5. Five simple inputs.

6. Right Panel Board

1. 12" * 7". 84 sq. in. Sparsely populated. Periphery is not full (the motor driver board space is not used efficiently for periphery access).
2. Located in the main box behind the right front panel and perpendicular to it (parallel to the APU).
3. Five stepper drivers for the four syringe motors and the wash block motor.
4. High power full-bridge driver for the shear valve.
5. 24 solenoid drivers for the 15 solenoids plus spares.
6. Two sensor inputs for shear valve position.
7. One sensor input for paddle switch.
8. Two sensor inputs for pre-shearValve and post-shearValve fluid detectors.

Most of the boards do not fully consume the available spaces (in a CD3200 box). The available spaces are:

1. Cardcage (APU) 12" * 12".
2. Left Panel 12" (height) * 14".
3. Right Panel 12" (height) * 13".

VPM

When we examined the interim system, several changes were obvious. One is that the vacuum/pressure circuitry could and should be reduced to the minimum needed. It will be controlled through the APU scan chain and, therefore, doesn't belong on the FPM board. The transducers complicate board swapping, so, for maintenance concerns, the circuitry should be minimized. The vacuum/pressure circuit should be located on the Pneumatic Unit but no other circuitry should be there. Therefore, the new design will have a VPM board, which will only control the vacuum and pressure. It will be located on the Pneumatic Unit and will be controlled through the APU I/O scan chain.

Responsibility for the strobed fluid sensors as well as vacuum/pressure control was taken away from the FPM and given back to the APU (via the APU scan chain). Thus, the name FPM (Flow Process Module) no longer has any meaning. The unit now strictly replaces the MPM (Motor Process Module) and SHM (Sample Handler Modules-- Tower and Loader). Therefore, it has been renamed MSM.

MSM

The core of the MSM unit comprises the 68340, FPGA, APU interface (connector and drivers), motor scan chain interface (now augmented with an ADC), and I/O scan chain interface (if tower and loader remain separate boards). This consumes approximately 36 sq. in. In the interim system, the MSM (FPM) controls the tower and loader boards through scan chains. Therefore, it could be located nearly anywhere in the box. The new smaller MSM, however, could be located closer to the tower and loader that it controls. We physically examined the system to determine whether it would be feasible and desirable to move the MSM to the plate where the Left Panel Board is located and to connect directly to the tower and/or loader I/O devices, thereby eliminating the tower and loader boards. This could improve reliability by reducing components and connections, reduce exposure of circuitry to fluids, and improve our image with customers.

TOWER

The tower board clearly should be replaced. Locating the MSM at the bottom of the left panel (inside) plate with its tower connectors on the lower left and threading the tower wires through a hole near the bottom of the left front panel allows the wires to be only slightly longer than they are with a tower board. This MSM position is also the best location for the board to connect to the loader.

Disconnecting the tower I/O from the MSM located at the bottom of the inside left panel would not be physically difficult. There are several inches of clearance between this location and the Pneumatic Unit, which can slide out if this isn't enough. It would still be advisable to use connectors with ejector tabs to facilitate disconnect.

LOADER

Whether to replace the loader board with direct I/O from the MSM is not as clear as for the tower. The interim loader board has 30 input lines and 13 outputs. The 43 wires of a direct I/O approach compares favorable to the 40 wires used in the scan chain design (two 16-pin scan chains plus the 8-pin power cable). However, some of the inputs may be sensitive to EMI and the stepper driver is an EMI source. Another consideration is future flexibility. If direct I/O is used, every change, such as adding a sensor, potentially affects the wire count. If we choose direct I/O, thinking that it fits into a DB37 connector, for example, then the decision can be rendered obsolete by a relatively minor functional change.

The interim loader board's cabling is inadequate for maintenance. Three cables have to be disconnected to release the loader and none of them will be very accessible. The board will have little vertical clearance, yet its power plug must be pulled up with considerable force to disconnect. The single DB37 cable used in the CD4000 represents a much better approach even if it does increase the cabling cost. The interim board approach to cabling is not inherent in the scan chain interface. In fact, better cabling favors the scan chain approach, which isolates the wire count from future I/O count changes.

The two analog motor feedback wires increase the wire count of the scan chain interface but not of the direct I/O. But the interim design uses more wires in the scan chain connector than is actually necessary. It has two scan chain connectors that are nearly identical. Units can't be daisy-chained to a scan chain, because the data wires require unique input and output points. There are two logical data lines, downstreaming from the master (MSM) and upstreaming from the slaves. Each of these requires two wires for differential signaling. These four wires have to be different in the connectors, but all of the others are identical. Further, the loader board in the new architecture would be the only unit on the MSM's external I/O scan chain. The last unit in a scan chain doesn't need to provide a downstream connector. Therefore, the I/O scan chain doesn't even need the four data loop wires.

The situation for the loader's motor scan chain is different. The MSM master is located physically between the loader and the (new-- see stepper review) right panel motor driver board. One of the two slave boards must provide the data loop. While reducing the wire count in the MSM-Loader interface is desirable, it could only be done by physically looping through the right panel motor driver board and coming back through the MSM and down to the loader board. This would require either two normal scan chain cables or one special looping cable. The looping cable would reduce the total wire count but at the expense of system flexibility, as only standard cabling supports "mix and match" boards. Special cabling should only be used in a point-to-point link that we are sure is not going to change, such as between the MSM and loader.

If the loader board provided the motor loop, the logical interface signals would be:

1. I/O scan chain:

1. reset (shared with motor scan chain)
2. clock
3. parallel load
4. data in (from MSM)
5. data out (to MSM)

2. Motor control:

1. clock
2. parallel load
3. data in (from MSM)
4. data in loop (downstream through MSM to other units)
5. data out (to MSM)
6. data out loop (upstream from other units through MSM)
7. analog feedback.

The total wire count would be 24. A DB37 could support these while providing 13 power pins, which should be sufficient. A right-angle DB37 on the loader board would solve the disconnect problem, particularly if the connector itself can be bolted to the loader frame.

STEPPERS

The MSM will have three stepper interfaces for driving the two steppers located in the tower-- probe and spinner (this has been changed from a DC motor to a stepper)-- and the peristaltic pump, located on the left-hand side of the left panel. If direct loader I/O replaces the loader board then a fourth interface is needed. These are located on the motor scan chain but with the single-ended electrical interface that can be locally used instead of differential.

The four syringe motors and one wash block motor are all located on the right front panel. A stepper driver board will be located on the (inside) right panel under the wash block motor and, therefore, next to the right-most syringe. This board will contain five stepper driver interfaces. If the board is too large for this space, it may move to the right several inches, where there is a large open area that was occupied by an SDM in the CD3200. All stepper interfaces are removed from the Right Panel Module. The shear valve driver interface doesn't similarly migrate because it is not a stepper, but is controlled through the APU I/O scan chain.

The size of the syringe/wash block stepper driver board is determined by the following elements:

1. Five stepper drivers (including connectors) = 14 sq. in.
2. Motor scan chain interface = 2 sq. in.
3. Power and miscellaneous = 4 sq. in.
4. Total = 20 sq. in.

LEFT PANEL

The peristaltic pump driver will move from the interim Left Panel Board to the MSM. The interim Left Panel Board provides a scan chain connector to the Tower Board. This will move to a mechanically similar I/O connector on the MSM. The MSM area is determined by the following subsections:

1. CPU (68340, FPGA, 7-seg display, memory, PC-104, APU interface, BDM, support components) = 24 sq. in.
2. Barcode reader interface = 1.7 sq. in.
3. Motor and scan chain interfaces (including Loader) = 8.5 sq. in.
4. Tower section (including two stepper drivers) = 12 sq. in.
5. Peristaltic pump, driver = 1.7 sq. in.
6. Power connector and miscellaneous = 3 sq. in.
7. Border margin = 7 sq. in.
8. Total area = 58 sq. in.

The Left Panel Board continues is still needed to provide at least solenoid drivers. The interim design also includes fluid sensor circuitry (including for the strobed sensors). The board area is determined by the following subsections:

1. Solenoid drivers = 40 sq. in.
2. APU scan chain (ICs and two connectors) = 3 sq. in.
3. Sensor circuitry and connectors = 8 sq. in.
4. Power connector and miscellaneous = 3 sq. in.
5. Border margin = 7 sq. in.
6. Total area = 61 sq. in.

Since the Left Panel Board and MSM are located adjacent to each other, it would be possible to simply combine them into one. However, with such a large number of connectors, servicing would be easier if the two were separate. If separate, another 3 sq. in. should be allowed for separation. The total area consumed by the two boards would be 122 sq. in. The left panel plate provides 168 sq. in. The MSM will be located on the bottom of the plate and the Left Panel Board above it.

STROBED FLUID SENSORS

Two of the six strobed fluid sensors, are located on the front left panel. The remaining four are probes inserted into reagent and waster containers outside of the instrument. Their wires enter the instrument through the back panel (of a CD3200) but they could enter at any convenient point. Since only the two sensors on the front panel have a fixed location, it is reasonable to locate the sensor circuitry near to them and route the remainder to this point through the most convenient path. The Left Panel Board is the obvious choice for this. The sensor wires entering through the back panel can traverse to the front if necessary, but it would be better to provide an access point closer to the Left Panel Board if possible.

FLUID IN-LINE SENSORS

The pre-shearValve and post-shearValve fluid sensors attach to two small boards precariously dangling from a flagpole on the right front panel behind the Y-valve. The optical sensor board is our own and its circuitry should be merged into the Right Front Panel. The ultrasonic sensor board is mated to its sensor and is tuned by the manufacturer. This board consumes less than 2 sq. in. and the Right Front Panel board has virtually unlimited space, so it would be reasonable to provide an option to mount the sensor board on the panel board. Remote mounting should not be precluded, because the sensor cable has a fixed length that may not support every possible position of the sensor unless the board is mounted on the front panel.

STATUS BOARD

The interim Status Board has two combined motor and I/O scan chain connectors for attaching to the FPM. These must at least be replaced by connectors for the APU I/O scan chain, which doesn't include a motor interface. The wiring can be much more aggressively reduced by using a point-to-point loop-back cable to the Right Panel Board. This requires just one 14-pin cable.

RIGHT PANEL

The interim design has two combined motor and I/O scan chain connectors for attaching to the FPM. The new design has two similar connectors for attaching to the APU I/O scan chain. Neither the MSM's I/O or motor scan chain attaches to the new board. All of the stepper driver circuits are moved to the new right panel motor driver board.

A point-to-point loop-back cable connector will be added for connecting the Status Board to the APU I/O scan chain.

CABLING

The interim design uses consistent cabling, which would support mixing I/O boards, i.e. any board that attaches to a particular scan chain can be located anywhere on the chain. This essentially doubles the amount of cabling and connectors. The supposed flexibility that this should buy is really an illusion. Each I/O board is designed according to where it is located. Any movement would be within a narrow range that would not upset the bus topology. The bussing flexibility is inconsistent with the reality of these boards. Therefore, cabling should be reduced wherever feasible by using special point-to-point arrangements as specifically described above. The two cases that stand out are the Right Panel Board to Status Board and the MSM to Loader board.

The standard I/O control cables are as follows:

1. APU (I/O) scan chain. The APU has two of these but only one will be used for the near future. This contains 10 wires comprising differential pairs for:

1. Clock
2. Reset
3. Parallel Load
4. Data from master (APU) to slaves.
5. Data from slaves to master.

2. Point-to-point I/O loopback. This contains 14 wires, 10 of which are identical to a standard I/O scan chain. The remaining four wires comprise two differential pairs for loop data from master and loop data to master. This is functionally equivalent to two scan chain cables bridged by an I/O unit, but does not support physical daisy chaining of I/O units.
3. Motor control bus. There is only one of these and the master is the MSM. The standard version contains 10 wires as in the I/O scan chain plus two analog winding feedback wires. A 14-pin connector will be used with two wires not connected.
4. Point-to-point motor control with loopback. This contains 16 wires, 12 of which are identical to the standard motor control bus. The remaining four wires comprise two differential pairs for loop data from master and loop data to master.

I/O control cabling usage is as follows:

1. APU scan chain.

1. APU scan chain 1 to Right Panel Board is a standard 10-pin I/O scan chain.
2. APU scan chain 2 is reserved for future use.
3. Right Panel Board to Status Board is a 14-wire point-to-point I/O loopback.
4. Right Panel Board to Left Panel Board is a continuation of the APU scan chain after looping through the Status Board. It is a standard 10-pin I/O scan chain cable.
5. Left Panel Board to VPM (located on the Pneumatic Unit, so the cable needs a 3-foot service loop) is a standard 10-pin I/O scan chain. This is a continuation of the APU scan chain after looping through the Left Panel Board.

2. MSM I/O scan chain. This locally loops through the tower control section and then combines a standard I/O scan chain with a loopback motor control bus connected to the Loader Board. The Loader Board is the end of the I/O scan chain and does not provide any loopback.
3. MSM motor control.

1. This locally loops through the three on-board stepper drivers (for two tower motors and the peristaltic pump).
2. MSM to Loader. The motor loop continues after local drivers by joining, as a loop-back motor cable, the I/O scan chain in the Loader interface. The combination cable connects to a DB37 on the Loader Board. Loader power is provided on the 13 pins not used by the scan chains.
3. MSM to Right Panel Motor Driver Board. After looping back from the Loader, a standard 14-pin (12 active) motor scan chain continues the chain.
4. Right Panel Motor Driver Board to ? A second standard motor control connector may be included on this board to allow the motor chain to continue to future units. Currently, this is the end of the motor scan chain.

HARDWARE ROADMAP

APU

1. Modify interface to MSM (was to FPM in the interim design) to duplicate the APU to Data Station interface. This involves clock and data signal changes and pinout changes.
2. Add second I/O scan chain, remove motor scan chain, and replace connectors with two 10-pin standard I/O.
3. Implement decimation firmware.

FPM

No longer exists. Its vacuum/pressure control moves to the new VPM. The remainder moves to the new MSM.

MSM (replaces FPM)

1. Start with the existing FPM.
2. Remove VPM and all local sensor circuitry and firmware.
3. Retain barcode reader interface hardware and firmware.
4. Retain PC-104 interface.
5. Retain I/O and motor scan chain firmware but change cabling as explained above and add 56-bit motor scan chain input.
6. Add motor controller (on top of motor scan chain controller) firmware to FPGA.
7. Add ADC and control firmware for motor winding test (ADC circuit TBD).
8. Rewire interface to APU.
9. Merge Tower Board circuitry (minus scan chain connector and interface drivers). Place tower I/O connectors on the bottom left to be close to the new access point through the front left panel. Replace the spinner DC motor driver with a stepper driver.
10. Add a stepper driver for the peristaltic pump.
11. Add stepper winding feedback to each driver (one Mohm resistor for each leg of each winding).
12. Route the local I/O and motor scan chains and their off-board interfaces, including the combination cable to the Loader Board.
13. Add serial flash for programming FPGA and provide a means to disable programming by CPU without eliminating it entirely (e.g. by jumpering).
14. Add BDM DS/CLK select.
15. This board should be approximately 11" long by 5.5" high.

VPM (new)

1. Move FPM circuit to new board.
2. Move control firmware from the FPM's FPGA, retaining low-level control but replacing the higher-level interface with one compatible with the APU scan chain.
3. Add electrical interface to APU scan chain.

LOADER BOARD AND CABLE

1. Replace the power and two scan chain connectors with one right-angle DB37 to connect to the combined MSM I/O scan chain plus motor loop scan chain plus power.
2. Develop cable harness to get loader power directly from the Distribution Module instead of through the MSM.

LEFT PANEL BOARD

1. Eliminate peristaltic pump stepper driver.
2. Eliminate tower scan chain connector and wiring.
3. Replace the two I/O+motor scan chain connectors with two standard 10-pin I/O scan chain connectors (will attach to APU cable).
4. Modify the strobed fluid sensor firmware to read only once every 100 msec. and only if enabled by a control bit on the APU scan chain.
5. Add at least 4 scan chain inputs and 4 outputs for spares.
6. Reduce board height. New board should be approximately 5.5" high and 11" long. In any case, it and the MSM must share the 12" (high) by 14" inside front left panel plate.

RIGHT PANEL BOARD

1. Move all of the stepper drivers to the new Right Panel Motor Driver Board.
2. Replace the two SPI/MPI connectors with two standard 10-pin scan chain I/O connectors.
3. Add a point-to-point I/O loopback I/O scan chain connector for the Status Board. The data lines on this connect between the two standard connectors, i.e. the data in the APU cable connects to the standard data lines of the Status Board cable while the data in the other connector (which goes to the Left Panel Board) connects to the loopback data in the Status Board cable.
4. Merge the optical blood-in-line sensor circuitry.
5. Provide an interface to and optional piggyback mounting site for the ultrasonic blood-in-line sensor circuit.
6. Add at least 4 scan chain inputs and 4 outputs for spares.

STATUS BOARD

1. Replace the two SPI/MPI connectors with one 14-pin I/O scan chain loop back connector for connecting to the APU scan chain through the Right Panel Board.

RIGHT PANEL MOTOR DRIVER BOARD (new)

1. Copy (move) the five stepper motor driver circuits from the interim Right Panel Board.
2. Add the winding feedback connections (each winding leg to one of the analog bus lines through a 1 Mohm resistor).
3. Add one or two standard 14-pin motor control connectors. Note that the data lines of the second connector (furthest from MSM) are not directly connected to the first connector but to the last motor in the chain on this board.
4. Add power.

SYSTEM DESIGN REPORT 1

9/28/99

[Excerpts From Ad46]

[Report2]

Synopsis: some hardware changes needed on the APU and MSM (nee FPM) boards to better support software.

PROBLEM

The APU-MSM interface does not include a clock, limiting the maximum baud rate to the maximum that can be embedded in the data stream.

SOLUTION

Replace the SYNC signal from the APU with the 500KHz RXCLK, which is transmitted by the data station. Disconnect APU CPU PA3 from 75174 line driver input and replace it with RXCLK. The APU will be programmed to use SCLK for transmit and receive for both channels A and B.

PROBLEM

The APU-MSM interface is electrically and functionally nearly identical to the Data Station - APU interface but the two pinouts are different. This prevents the Data Station from communicating directly with the MSM, which would be useful during development.

SOLUTION

Arrange the pins of the APU-MSM connector to match the HSSL connector, with the APU playing the role of Data Station and MSM the role of the APU. Put ATN on the ACLOCK (TXCLK from APU to Data Station) pins 3 and 4. A special cable is needed for the Data Station to talk directly to the MSM. In this cable, pins 3 and 4 are disconnected and the wires connected to pins 9 and 10, i.e. the Data Station's own transmit clock is looped back as its receive clock in the cable itself. The MSM's ATN signal is not used.

PROBLEM

The MSM (FPM) CPU does not connect to an external baud rate clock so it can't use (hardware) synchronous clocking.

SOLUTION

Cut the CPU's SCLK (pin 88) connection to ground and connect it instead to the old SYNC input (after translation by 75175) which has been replaced by the global communication clock on the APU board.

PROBLEM

The MSM (old FPM) has no input handshaking, i.e. nothing to prevent the APU from overrunning the UART input buffer. The CPU output that could have been used for input flow control, RTSA (pin 80), was instead used for output impedance control for a multi-drop communication system, which we don't have.

SOLUTION

Disconnect RTSA from the output drivers' (75174) enable. Hard-wire the enable to always on. Disconnect TXRDY (CPU pin 83) from the interface CTSB driver, replacing it with RTSA. Configure RTSA for input flow control.

For any multi-drop system developed in the future using this same CPU, transmitter impedance can be controlled by simple I/O. At the final interrupt of a message, the ISR can turn off the transmitter.

CDNEXT: APU SYSTEM DESIGN REPORT 2

10/4/99

[Report1]

[Report3]

DISTRIBUTION OF FPM SUBSYSTEMS

The vacuum accumulators are located in the vacuum/pressure module. Consequently, their signal conditioning circuitry should move from the FPM to the new VPM board. These sensors are strobed but, unlike the strobed fluid sensors, they are operated continuously. The circuit shown in the FPM schematic is very similar to the circuit on the old VPM, but it is not identical, leading to some questions.

1. The old circuit uses a free-running oscillator (using a 74HC14) to continuously strobe the sensors. The new circuit apparently replaces this with a buffered signal from the FPGA.

1. Is the intent of the new circuit to drive this "SENSE" line as a replacement oscillator? Would this be a reasonable use of FPGA resources?
2. The old oscillator output drove to a full 5V and 0V, which was coupled into the sense circuits through 33KOhm resistors. The new circuit has much more complex impedance characteristics. The PNP drive transistor has a 10K emitter resistor to +5 and a 1K collector resistor to ground. Is the design intent to operate this transistor in linear mode? If not then what is the purpose of the emitter resistor? Why isn't it in the collector leg to produce a voltage-divider pullup and hard pulldown without allowing the transistor to drift into linear mode?

2. The new circuit shows 3.3KOhm resistors coupling the driver to the signal capture circuit. Is this intentional or a misreading of the 33KOhm resistors used in the old circuit?
3. Has the new circuit been tested electrically? in a live situation?

DAC

The vacuum/pressure control system will move from the FPM to the new VPM. Several improvements can be made to the circuit now on the FPM.

The circuit on the FPM simply provides buffered control signals to some remote actuator system, comprising solenoids and pumps. The solenoid control logic signals should be replaced by real solenoid drivers. There should be three of these, two for the pressure step downs and one for vacuum. Since the two pumps operate on 117VAC, we probably will want to continue outputting logic controls for them.

The DAC and comparator feedback control system is inefficient and inflexible. Each of the five servo control sections comprises an analog signal that is compared to one DAC channel output, generating a logic signal, which is sent to the FPGA. The same analog signal is fed to an ADC, whose output is sent to the FPGA. The FPGA writes the reference voltage to the DAC. The FPGA outputs the pump and solenoid control signals. The FPGA doesn't need the DAC to tell it when the measured signal is below the reference. It can do this itself by comparing the ADC output to the reference value.

Eliminating the DAC and comparator affords many advantages, such as:

1. Circuitry is reduced.
2. Greater and more flexible accuracy is possible. Reducing the DAC/comparator leg in itself reduces one source of inaccuracy. Additionally, accurate ADCs are much more common and cheaper than accurate DACs. The original MUXDAC had 12-bit accuracy; the new DAC has 8-bit; while the new ADC has 10-bit. 10-bit accuracy is likely to be sufficient, but upgrading to a 12-bit part would be painless.
3. It reduces the number of scan chain bits needed to control the system.
4. It affords the FPGA (or other intelligence) an opportunity to make smarter control decisions, such as hysteresis to avoid excessive motor and solenoid toggling, or PID for ideal control.

CONTROLLER

The vacuum/pressure controller combines relatively high level commands with the digitized sensor data to determine whether to turn the pumps and solenoids on. On and off commands are simple. For each of the three solenoids, the scan chain provides two bits that tell whether the solenoid is open, closed, or servoed. The scan chain provides one bit for each of the two pumps, which are either off or servoed.

Each of the five controlled sections (three solenoids and two pumps) needs at least one 10-bit reference level. For programmable hysteresis, two 10-bit references or one 10-bit level and one (e.g.) 4-bit hysteresis value would be needed. The total of 50, 64, or 100 bits would consume too much of the scan chain to be used without encoding. The most obvious encoding scheme is to demultiplex one set of 10 bits to registers selected by three or four address bits.

A simple controller could rotate continuously through the five channels, comparing each ADC output to the corresponding level (if servoing has been selected for that channel) and turning the output on if appropriate. This bang-bang control could excessively toggle the electromechanical devices. The simplest way to avoid this is by using upper and lower thresholds, turning on the device when the signal drops below the lower threshold and off when it climbs above the upper. By making these levels programmable through the scan chain, any system can be properly tuned by scripts. It would even be possible to adapt the hysteresis to changing conditions. For example, the vacuum may be maintained loosely (large hysteresis) most of the time to reduce solenoid wear but more tightly (smaller hysteresis) during the cell counting period to reduce vacuum oscillations during this critical period.

Bang-bang control, even with hysteresis, represents a primitive control means, in which overshoot can be controlled only by excessive cycling. A more sophisticated means, such as Proportional-Integral-Derivative, is more commonly used for servo mechanisms. A PID control system could not be feasibly implemented in an FPGA. A more reasonable approach would be to use a DSP. Any standard DSP can provide the computational power for this application. The other major concerns would be the time required to write the program and the circuit cost.

Analog Device's ADSP2105 itself costs only $3, but the full circuit comprises more than this one device. Like many DSP's, this device has on-chip data and program RAM and can boot itself from an 8-bit external EPROM (like our RAM-based FPGA) so its support circuit cost is quite low. It also has a built-in clocked serial port that can interface to the serial scan chain with little or no additional logic. Since the 2105's serial port isn't flow through (input looping back to output) as is normal for our scan chain, it would have to operate in snoop mode. That is, it could capture the scan chain signals as they pass by. The only reasonable way to map the device onto the scan chain would be to locate it at the logical end. Otherwise, it would inadvertently share addresses with some real device in the chain. It could actually be located physically anywhere at or before its logical address. As with the flow-through scan registers, it can't see bits physically located earlier in the chain (except on the next cycle, which could be confusing but may be usable anyway).

An ADSP2105 located at the physical beginning of the scan chain could capture the entire 256 bits by programming the serial interface for auto-buffering, using a DAG (on-chip Data Address Generator) to automatically transfer each group of 16 bits to a memory buffer. However, this isn't needed for the vacuum/pressure controller (it may prove useful for other situations where this chip might be valuable) which is located on the physical end of the APU's I/O scan chain and will only need 22 output bits. This is larger than the 2105's input holding register so auto-buffering might still be needed. The 2105's serial transmit can be used to send status information to the APU. There would be no reason to send raw ADC data, as the vacuum/pressure control system is entirely self-contained and, with a DSP, smart enough to identify and report errors.

The ADSP2105's serial port is designed for interfacing with serial peripherals, like CODECs and ADCs. However, it has only one serial port. Other devices in the ADSPxx series have two serial ports but also many other features that we don't need. It may be cheaper to use a parallel ADC (if we can find one-- the TI family that we have been using offers multiplexed ADCs only with serial interfaces) with the 2105 than to use one of the more expensive parts just to be able to use a serial ADC.

The DSP program can be relatively simple. A bang-bang controller with hysteresis wouldn't be more difficult to implement than the same functionality in VHDL for the FPGA. However, all of the tools and development methods would have to be procured and set up. Further, only one of us (as far as I know) has any experience programming the ADSP2105. The two solutions would have essentially identical system interfaces and would cost approximately the same. The basic tradeoff is, for an up-front cost (more in startup time than equipment, as the DSP tools are cheap) the DSP affords greater flexibility in control algorithms (and self-testing) which could result in more dramatic savings due to improved reliability.

Whether implemented by a DSP or FPGA, the bang-bang + hysteresis architectural and behavioral description is as follows:

1. Scan chain interface:

1. Two bits select the operating mode of P1 and V1 as follows:

1. 0 = pump off.
2. 1 = pump servoed. There is no pump always on mode.
3. These bits reset to 0.

2. Three pairs of bits select the operating mode of P2, P3, and V2 as follows:

1. 00 = solenoid off.
2. 01 = servoed.
3. 10 = solenoid on.
4. These bits reset to 0.

3. Ten bits provide a level word. It may be useful for these bits to reset to 1 but this is not essential.
4. Four bits select one of 12 10-bit registers. These bits reset to 1, i.e. no register selected.
5. On the rising edge of NPCS (parallel load) load the 10-bit level word into the selected register.

2. Pressure and vacuum feedback:

1. Feedback is through a multiplexed ADC, TLV1548, of which five of eight input channels are attached to P1, P2, P3, V1, and V2 transducers. The minimum ADC cycle period is 12 usec. when operating with a "fast" conversion, a 6MHz clock, and overlapping address and data, i.e. the address of the next channel is clocked into the ADC while the previous data is clocked out. The overlapping address/data cycle may be more difficult for the FPGA to provide than non-overlapping, in which two complete cycles are run, ignoring the data of the first cycle.
2. The controller iterates repeatedly through the five channels. For simplicity, every channel can be unconditionally read even though the data is actually needed only when a channel is servoed. Assuming that the overlapping address/data cycle is used, each channel is updated every 60 usec.
3. The ADC controller may transfer each channel's data to an internal register in order to present it continuously to the pressure/vacuum control means. Alternatively, the control may be synchronized to the ADC cycle and no data storage other than the raw 10-bits (perhaps with one level of buffer) is needed.

3. Pressure and Vacuum control:

1. Two output bits are buffered (single ended TTL/CMOS) and taken to a jack to control off-board power switches for the pressure and vacuum pumps.
2. Three pairs of output bits control on and high power of the P2, P3, and V2 solenoids. Three standard solenoid drivers are located on board.
3. For each of the five controlled devices:

1. If the mode bit(s) tell that the device is off then:

1. If the device is a pump, assign 0 to its control bit.
2. If the device is a solenoid, assign 0 to its ON bit.

2. If the mode bits of a solenoid tell that it is always on then assign 1 to its ON bit. If this is a change then assign 1 to the device's HI (power) bit and begin a 1/2 second timing process (for this one device) for power reduction.
3. If the mode bit(s) tell that the device is servoed then:

1. If feedback is lower than the low threshold (captured from the scan chain into one of two registers for each device) then:

1. If the device is a pump, assign 0 to its control bit.
2. If the device is a solenoid, assign 1 to both its ON and HI bits.

2. If feedback is higher than the high threshold then assign 0 to its control bit (pump) or ON bit (solenoid).

4. It is possible to create an almost (except for the solenoid OFF-ON change detector needed for power control) entirely combinatorial PV controller if the ADC controller copies each channel's value to a unique register. This may be desirable for a DSP-based design (with a second serial port for accessing the ADC) because the ADC interface can be put into continuous automatic mode, relieving the program of any need to synchronize the ADC and device controllers. However, for the FPGA-based design, it is probably better to tie the device controller to the ADC cycle in order to share one (or two) threshold comparator across all devices.

4. Solenoid power down: for each solenoid in power-down count mode (which means that continuous ON has been selected and that it has recently changed from OFF to ON) step its counter or compare its time end to a single global timer. If 1/2 second has elapsed then assign 0 to the solenoid's HI (power) bit. An FPGA-based design would probably be easier using a counter for each solenoid, while the comparator approach may be easier for a DSP-based design.

Other than pressure and vacuum control, the new VPM board will contain only the two vacuum accumulator wet sensors, which will be inputs to the APU scan chain.

APU-MSM COMMUNICATION CABLE PINOUT

The intelligence of the FPM, comprising the CPU and the bulk of the FPGA, was primarily responsible for motor control plus tower and loader script execution (tower and loader SHM units in the CD3200). This has been moved to the new MSM (essentially, FPM with other functions removed, has been renamed MSM).

The APU communicated with the FPM using the old SHM serial link, which is half-duplex, 19.2KBaud, asynchronous RS485. For APU-MSM this will be replaced by full-duplex, 500KBaud, separate data and clock lines, RS422, which is the same as the "HSSL" link between the data station and APU.

The APU and old FPM circuit (now MSM) both must be changed for the new link. In addition to circuit changes within each board, the connector pinout is changed to match the HSSL cable to allow the data station to link directly with the MSM for program development (software will also provide a link through the APU). The cable pinout is:

1. Pins 1 and 2 are data+/-, data transmitted by MSM to APU.

1. On the MSM this is connected through a 75174 driver to CPU TXDA pin 77.
2. On the APU this is connected through a 75175 receiver to CPU RXDB pin 84.

2. Pins 3 and 4 are clock+/- or atn+/-, txdata clock or ATN transmitted by MSM to APU.

1. On the MSM, this is connected through a 75174 driver to jumper-selected CPU SCLK pin 88 or PA2 pin 132. For direct communication with the data station, SCLK will be selected. For communication with the APU, PA2 may be connected (to be determined during software development).
2. On the APU this is connected through a 75175 receiver to CPU IRQ3 pin 105. If the MSM transmits SCLK, the APU is programmed to ignore this input. If ATN, the APU will treat it as either polled or interrupt signal.

3. Pins 5 and 6 are cts+/-, handshake transmitted by MSM to APU indicating whether the MSM can accept more data from the APU.

1. On the MSM this is connected through a 75174 driver to CPU RTSA pin 80.
2. On the APU this is connected through a 75175 receiver to CPU CTSB pin 87.

4. Pins 7 and 8 are data+/-, data transmitted by APU to MSM.

1. On the APU this is connected through a 75174 driver to CPU TXDB pin 85.
2. On the MSM this is connected through a 75175 receiver to CPU RXDA pin 76.

5. Pins 9 and 10 are clock+/-, txdata clock transmitted by APU to MSM.

1. On the APU this is connected directly to the data station's transmit data clock, i.e. HSSL connector pins 9 and 10.
2. On the MSM this is connected through a 75175 receiver to CPU SCLK pin 88.

6. Pins 11 and 12 are cts+/-, handshake transmitted by APU to MSM indicating whether the APU can accept more data from the MSM.

1. On the APU this is connected through a 75174 transmitter to CPU RTSB pin 86.
2. On the MSM this is connected through a 75175 receiver to CPU CTSA pin 81.

7. Pins 13 and 14 are reset+/-, system reset.

1. On the APU this is connected directly to the data station's (transmitted) reset, i.e. HSSL connector pins 13 and 14.
2. On the MSM this is connected through a 75175 receiver to reset device TL7705 RESIN pin 2.

The APU's selectable barcode interface should be removed. This can only be enabled at the expense of MSM communication and the APU cannot control an analyzer without the MSM.

COMMUNICATION CLOCKING

To support a fast Baud rate in the serial interfaces (data station to APU and APU to MSM) a separate clock is transmitted in addition to the data. The HSSL link was originally developed around the 68681 DUART (and the nearly identical 2681, which is still used on the data station's HSSL card). The DUART can associate a distinct clock for each data line. The HSSL interface contains separate clocks for the data in both directions.

The 68340 CPU supports clocked data but provides only one clock input, SCLK for transmit and receive data on both channels A and B. When we replaced the 68681 with the 68340, to provide the outgoing data clock (to the data station) we simply turned around the clock transmitted by the data station, i.e. the CPU SCLK. This clock and the CPU's transmit data experience equivalent delays through the buffers but the data still lags the clock by the delay time from SCLK to data out in the CPU. This delay does not exist when both the data and the clock are output by a 68681. The delay is calculated from the data sheet for a 17MHz 68340 operating at 15.97MHz (see MC68340 User's Manual, Electrical Specifications p. 11-22).

The worst case delay is: 1.5 tcyc + tcs + tvld, where tcyc = 63 ns, tcs = 5 ns, and tvld = .5*tcyc = 31 ns. The result is 130 ns.

The input data setup time relative to SCLK is: .5*tcyc + tcs + tchrx, where tchrx = 15ns. The result is 51 ns.

Since the data period at 500KBaud is 500 ns, the lagging data reduces the worst case data-clock margin from 449 ns. to 319 ns, which is unquestionable safe.

The situation is more complicated in the APU-MSM interface. Unlike the data station, with its multi-clock 2681, the APU won't accept a separate clock for the data transmitted by the MSM. Therefore, this data will lag the clock used to sample it significantly more than in the APU-Data Station case. To reduce the lag, the differential clock from the data station to the APU is routed directly from the HSSL connector to the MSM connector (see item 5 above). This still leaves the following (max) delays:

1. Clock through 75175 receiver on MSM: 35ns.
2. CPU SCLK to data out: 130 ns.
3. Data through 75174 transmitter on MSM: 65ns. delay + 120ns. output transition time.
4. Data through 75175 receiver on APU: 35ns. Wire delay from MSM to APU is negligible.
5. Total delay from APU SCLK to input data at APU CPU is 385 ns.

Given the 51 ns. data setup time, the worst case margin is 64 ns. It would be possible to improve this by delaying the data on the APU by one full clock period minus the data lag, thus moving the data into next clock period but forward in time for that period. This is possible because the link, although clocked, is still asynchronous, with the receiver extracting the start time from the data. If the data were moved too far forward in the next cycle, i.e. not delayed enough, an apparent clock lag would be created. Thus, we have to consider the minimum delays. Assuming that minima are 50% of maxima, the minimum data lag is 192 ns. The CPU-UART data hold time is the same as the 51 ns. setup time. Therefore, the ideal data time would split the min-max lag (192 ns.) in the middle of the bit time, producing a symmetrical pair (clock lag relative to minimum data delay and clock lead relative to maximum data delay) of worst case margins of 154 ns. This could be achieved by a 308 ns. (500 - 192) delay in the data at the APU. This is obviously much better than the 64 ns. margin, but since that also results from a worst case analysis, it is acceptible. Therefore, unless we encounter unreliable communication for unexpected reasons, the undelayed data design will be used. If it is convenient, we may want to include an unstuffed delay line on the APU data from the MSM as a contingency option.

MSM DMA

The MSM has no other uses for the CPU's two DMA controllers so they may as well be used for its communication with the APU. For consistency with the APU, DMA 2 will be used for transmit data (from MSM). CPU TxRdyA pin 83 will be connected to CPU DREQ2 pin 96. CPU RxRdyA pin 82 will be connected to CPU DREQ1 pin 93.

STEPPER MOTORS

DISTRIBUTION OF DRIVERS

System Design Review Meeting 46 Minutes (AD46.DOC) provides an overview of stepper driver requirements. Five drivers are required on the right panel motor driver board, three on the MSM, and one on the loader board. The motor controller can support as many as fourteen motors and providing spare drivers does not impact the existing motors. Each motor interface consumes four scan chain outputs and four inputs. Our standard scan chain shift registers (HC594 for output and HC597 for input) are octal parts. Coincidentally, each of the three boards is required to support an odd number of motors so adding one spare to each more effectively uses the scan chain address space while still using standard logic.

The right panel motor driver will provide six stepper interfaces and the MSM four. If the loader provides two, all three boards will have one spare, but there will still be two empty slots. We have considered replacing one or more pneumatic loader actuators with steppers. If the loader board can be expanded to support two more spare stepper drivers, it could save us a future board turn. Since two interfaces represent complete octal shift registers, they can be easily jumped over (serial in connected directly to serial out, bypassing the shift register) in order to recover the scan chain address space for a driver located elsewhere in the system.

MOTOR SCAN CHAIN INPUTS

As explained in AD46, the stepper interfaces will include four inputs for flags. One HC597 octal shift register will support two motors. For a circuit example, see Status Panel or Left Panel. The '597 is double-buffered. On the rising edge of NPCS0 (scan chain parallel load) the input capture register is loaded by asynchronous RCK. During the period in which NPCS0 is high, at each positive transition of SCK0, the captured input is loaded into the input scan chain because the active low synchronous load signal SRLOAD is driven by inverted NPCS0.

At least two of the scan chain inputs are taken to standard three-pin flag jacks. The other two pins provide +5 and digital ground to an opto-interrupter. The flag pin is connected to the '597 input and to a pullup resistor.

CDNEXT: APU SYSTEM DESIGN REPORT 3

10/8/99

[Report2]

[Report4]

1. MSM Motor Controller Bus Mastering.
2. Scan Chain.

1. Terminology
2. Scan Chain Stream Connections.
3. Shift Register Components.
4. Scan Chain Operation.
5. Scan Chain Controller.
6. Conclusions.

3. Stepper Motor I/O.

1. General.
2. Right Panel Motor Driver Board Requirements.

4. APU-MSM Communication.

MSM MOTOR CONTROLLER BUS MASTERING

Andy O has suggested the possibility of the motor controller reading step event data during the four microsecond dead time of the scan chain, thereby avoiding having to create a shadow motor scan chain. As Andy explained, in any 32 usec. scan period, the maximum number of events (bytes) to be read would be 14 because no motor can have more than one step in this period.

The memory bus is not available for the full 4 usec, because the FPGA has to arbitrate with the CPU for ownership. Motorola states that the 68340 has lower bus arbitration priority than external devices (User's Manual 3.6 Bus Arbitration p. 3-40). The User's Manual also states that DMA uses the bus arbitration protocol to request bus mastership (6.5 Bus Arbitration p. 6-18). This suggests that the FPGA would have higher priority than DMA, but it isn't always clear what is considered an external device. For example, although both the DMAC and UART are internal to the 68340, the UART RDY signals must be externally wired to the DMAREQ inputs.

In any case, the worst case bus lockout due to an instruction occurs when the CPU has just begun a long read/modify/write, such as ADD.L #12345678,someAddress. Assuming that the CPU uses a three cycle memory access, the lockout duration is 12 cycles for the CPU's instruction (from MC68340 User's Manual page 5-97, 98 Instruction Timing Tables) + 4 cycles for the extra cycle in each of two reads and writes (Motorola's example uses 2-cycle memory access). The total is 16 cycles, which, at 15.9744 MHz, is 1usec (16 * 62.6 nsec).

If DMA has equal or higher priority than the FPGA and if both RX and TX DMAREQs assert before the bus request then each of the two DMA transactions would add 7 cycles to the lockout period. DMA could require as much as 9 cycles for two-cycle DMAREQ recognition and a subsequent dual-address transaction (even though one of the addresses is that of the internal UART, the CPU will still keep the bus locked). However, both DMA requests' recognition times are hidden in the CPU instruction execution time, so the real worst case for one DMA is 7 cycles. This would increase the worst case bus lockout period to 1.88 usec.

If the motor controller can read 14 bytes from shared memory in less than 2.12 usec. then we don't need to further investigate DMA priority. If it can't meet this timing requirement, but it can perform the necessary reads in 1 usec. then we need to determine whether DMA has lower priority.

SCAN CHAIN

TERMINOLOGY

• Master. The scan chain controller is the Master. The system has three scan chains and, therefore, three Masters: the MSM I/O scan chain controller, the MSM motor scan chain controller, and the APU I/O scan chain controller.
• Slave. Scan chain I/O boards (and I/O scan chain subsystems on the MSM and APU) are Slaves.
• MOSI is scan chain output data from a Master, i.e. Master Out Slave In.
• MISO is scan chain input data to a Master, i.e. Master In Slave Out.
• Downstream. A board or scan chain shift register is downstream of another if it is located further from the Master in the electrical chain.
• Upstream. A board or shift register is upstream of another if it is located nearer to the Master in the electrical chain.
• MOSI data output from an upstream unit is input to the downstream unit.
• MISO data output from a downstream unit is input to the upstream unit.
• On a board, the furthest upstream output scan register is the head of the MOSI chain and the furthest downstream output register is the tail. The MOSI head register's serial input on a board is fed by the MOSI tail register's serial output on the upstream board.
• On a board, the furthest downstream input scan register is the head of the MISO chain and the furthest upstream input register is the tail. The MISO head register's serial input is fed by the MISO tail register's serial output on the downstream board.

SCAN CHAIN STREAM CONNECTIONS

The furthest downstream board in the chain is the end of the chain. The serial output of its MOSI tail register is connected to the serial input of its MISO head register. This connects the MOSI and MISO chains into one loop. The Master can verify the integrity of both MOSI and MISO chains by shifting twice the normal chain length without toggling NPCS.

A board in a scan chain may have one of three connector/bus configurations. These are:

1. End of chain. One normal bus connector.

1. MOSI is input and is connected to the serial input of the head MOSI register.
2. MISO is output and is connected to the serial output of the tail MISO register.
3. Requires four receivers (one 75175) and one transmitter (1/4 75174).

2. Daisy-chain. Two normal (size) bus connectors.

1. In the upstream connector:

1. MOSI is input and is connected to the serial input of the head MOSI register.
2. MISO is output and is connected to the serial output of the tail MISO register.

2. In the downstream connector:

1. MOSI is output and is connected to the serial output of the tail MOSI register.
2. MISO is input and is connected to the serial input of the head MISO register.
3. The SCK, NPCS, and Reset differential pairs in a downstream connector are attached directly to these same signals in the upstream connector.
4. For the two connections, requires five receivers (1-1/4 75175) and two transmitters (1/2 75174).

3. Loopback. One upstream loopback connector, which is a standard bus plus four extra wires for MOSI and MISO loopbacks.

1. The standard pins are connected as an upstream bus.
2. MOSI and MISO loopbacks are connected in the same way as the MOSI and MISO wires in a standard downstream connector.
3. Requires five receivers (1-1/4 75175) and two transmitters (1/2 75174).

A variant of the end-of-chain and daisy-chain boards contains a downstream loopback connector for attaching a loopback board. A downstream loopback connector contains the same pins as the upstream loopback but the signal directions are reversed. No board may contain only a downstream loopback connector. Normally, downstream loopback connectors are found only on daisy-chain boards. The downstream loopback should be located in the board's chain as if it were a downstream board. The loopback MOSI and MISO wires (two each) are routed directly to the downstream connector's MOSI and MISO pins. The normal MOSI and MISO wires from the downstream loopback connector are buffered (output to MOSI and input from MISO). Downstream communication requires the attachment of a loopback board or a flow through adapter in which the four normal MOSI and MISO wires are jumpered to the corresponding loopback wires. A daisy-chain board with a downstream loopback connector requires the same number of receivers (5) and transmitters (2) as a daisy-chain board without the loopback.

The scan chain registers are connected end-to-end as one long shift register. All of the registers must shift nearly simultaneously, so SCK has to be distributed in parallel to the boards. Thus, a daisy-chain board acts as an upstream-to-downstream bridge for SCK rather than as a repeater (where the translated signal would be rebuffered). NPCS should be treated the same way in order to minimize the skew between it and SCK. Reset should be treated similarly in order to avoid using an otherwise unnecessary output buffer.

Data signals are connected serially but they will not accumulate lag relative to SCK because, on each clock, data shifts only one position, i.e. there is no ripple effect. In fact, a small data output lag would be desirable to reduce the potential for a fast output being prematurely captured by a slow input device. Each differential data input (upstream MOSI and downstream MISO) is a transmission line endpoint with a characteristic impedance of 130 Ohm. In addition to the parallel terminating resistor, a parallel terminating capacitor can be used to improve the input data hold margin. A reasonable value would be 1000 pF-- the time constant of 65 Ohm and 1000 pF is 60 nsec (130 is divided by two because the capacitor sees the line and resistor in parallel). A MISO loopback should be similarly terminated.

The 75174 outputs can drive up to 30 receivers, but only the endpoints (at the driver and at the last receiver) should be terminated (only with 130 Ohm resistors-- the capacitor is for data lines). The other receivers should be unterminated but located very close to the differential signals to avoid reflections in the tap stubs. An end-chain board, i.e. one with only one normal connector, obviously should terminate SCK, NPCS, and Reset. However, while loopback and daisy-chain boards are designed to operate in the middle of the chain, they may also be used at the end of a chain, especially during system development. Consequently, they must support configurable termination. A terminating resistor is located near the receiver for each of these three signals. One leg (pad) of each resistor is connected directly to the wire. The other is connected via a removable jumper. If space is tight, the jumper may be a small wire between two vias.

SHIFT REGISTER COMPONENTS

The interim hardware uses 74HC594 for scan chain output and 74HC597 for input. The '594 is an extremely rare part that will probably soon be extinct. The parts we have now are made by National Semiconductor. I checked the web sites of National (back to Fairchild again), Intersil, Motorola (standard logic now "ON Semiconductor"), and Toshiba. None of them list a '594 in any technology. We cannot use this part.

The '597 appears to be more readily available, as I found it in TI, Toshiba, and Motorola data books. TI and Toshiba data books also list an HC595, which appears identical to the '594 shown in the schematics. Since I can't find any data on the '594, I can't say for sure that the two are identical, but the '595 looks like it would work in our scan chain (although, without an explicit timing definition of our own scan chain, the compatibility analysis must be considered incomplete).

For scan chain output, there are no standard alternatives to the '595, as it is the only part with double buffering. If the '595 is not commonly available then we will have to synthesize the equivalent functionality in FPGAs. Even if it is available, there are two reasons why, in some situations, we would want to use FPGA logic instead. One is that, unless all outputs are actually used, the octal parts waste scan chain bits (addresses). For inputs this is not important, as relatively few of the 256 bits are actually used. For outputs, this is more important, because most of the 256 outputs are used. The other situation in which synthesis may be preferable is where the scan register function can be folded into other functions. For example, the Status Panel contains a '594 and a '597, each only half-utilized. Additionally, it has an LM555 whose frequency is set by a digital potentiometer and an output amplifier whose volume is set by the other channel in the dual digital pot. The mixed signal buzzer circuit could be completely replaced by an FPGA, with frequency set by counting a clock and volume by PWM. The 4-bit output and input registers could be folded into this FPGA, replacing everything but buffers and drivers with one relatively small FPGA.

SCAN CHAIN OPERATION

Since nearly any behavior that we want can be implemented in an FPGA, scan chain operation should be compatible with '597 and '595 components, whose behavior can't be changed.

The '597 scan chain input register operates as follows:

1. Architecture

1. SI (serial input, pin 14) is connected to downstream scan chain master input data, i.e. to the serial output from a downstream register.
2. QH' (serial output, pin 9) is connected to upstream scan chain master input data, i.e. to the serial input of an upstream register.
3. SCK (serial shift clock, pin 11) is connected to scan chain clock.
4. SCLR (serial register clear, pin 10) is connected to scan chain reset.
5. SLOAD (serial register load, pin 13) is connected to inverted scan chain NPCS.
6. RCK (load input register, pin 12) is connected to scan chain NPCS.

2. IC Behavior

1. SCK shifts serial data on its positive edge when SCLR and SLOAD are high.
2. Asynchronous active low SCLR clears the serial register (i.e. the bits of this segment of the input scan chain become 0). SLOAD should be high when clearing.
3. Asynchronous active low SLOAD loads the input register data into the serial register. The serial register acts as a transparent latch. SCLR should be high at this time.
4. RCK, on its positive edge, stores external data into the input register regardless of any other inputs.

3. Circuit Behavior

1. Scan chain reset clears the scan chain bits. This behavior serves only a potential diagnostic function. It is not essential to circuit operation.
2. External data is captured into the input register when NPCS goes from low to high.
3. While NPCS is high, the serial register is transparent, i.e. the data captured by the input register appears on the scan chain. The input register does not change except during any period of metastability immediately after NPCS goes high. Any scan chain clock activity while NPCS is high is ignored.
4. When NPCS goes low, SLOAD goes high, enabling serial shifting is enabled. The input register is unaffected and the low-going edge of NPCS is itself of no particular significance. However, the relationship between the time of this transition and the scan chain clock is very significant. If one '597's SLOAD goes high just before a positive clock edge, while another's goes high just after, the two segments of the scan chain will be out of phase by one bit, making the data unpredictable and useless.
5. During the time that NPCS is low, the serial data is shifted by one bit toward the master on each positive clock edge.
6. When NPCS goes high, the cycle repeats. In this case, the relationship between the scan chain clock and NPCS is unimportant in all registers on the chain except the last. If NPCS at the last register prematurely goes high, i.e. before the last shift clock, the last bit shifted into the master could be incorrect.

The '595 scan chain output register operates as follows:

4. Architecture

1. SI (serial input, pin 14) is connected to upstream scan chain master output data, i.e. to the serial output from an upstream register.
2. QH' (serial output, pin 9) is connected to downstream scan chain master output data, i.e. to the serial input of a downstream register.
3. SCK (serial shift clock, pin 11) is connected to scan chain clock.
4. SCLR (serial register clear, pin 10) is connected to scan chain reset.
5. RCK (load output register, pin 12) is connected to scan chain NPCS.
6. G (output enable, pin 13) is connected to digital ground.

5. IC Behavior

1. SCK shifts serial data on its positive edge when SCLR is high. SCLR is the only signal that can prevent serial shift on SCK.
2. Asynchronous active low SCLR clears (all bits low) the serial register. The output register is not effected by SCLR. To clear the output, after clearing the shift register, a positive transition of RCK is required.
3. RCK, on its positive edge, transfers internal shift register data to the output register, regardless of any other inputs.

6. Circuit Behavior

1. Scan chain reset followed by at least one positive transition of SCK clears the output bits. This behavior is critical to outputs that must reset to a particular state. Outputs that must reset high for system safety must be inverted (e.g. by 74HC04)
2. Data is serially shifted on every positive edge of SCK. While NPCS is low, the outputs do not change.
3. On the positive transition of NPCS, serial shift register data is transferred to the outputs.
4. Data latched on the positive edge of NPCS does not change until another positive transition. Any scan chain clock activity while NPCS is high will continue to shift the data but will not affect the output as long as NPCS has settled.

The input and output registers have two important features in common.

1. Asynchronous, positive edge-triggered broadside load. On the positive edge of NPCS, external data is captured in input registers and internal shift register data is transferred to output registers.
2. Serial input data to the master and output from the master are both shifted on each positive edge of SCK.

SCAN CHAIN CONTROLLER

The document CD3200R FPM Hardware Design Description describes scan chain operation in general. The dimensionless state diagram in the document intimates that falling NPCS and rising SCK are coincident. Since data is serially shifted on the rising edge of SCK (the document doesn't state this, but it is what the circuits do) this could produce a race condition and should be avoided if possible. Considering the potential for skew between NPCS and SCK as they pass through multiple buffers through the chain, NPCS should not change near the positive edge of SCK. One way to avoid this would be to have NPCS change at negative transitions of SCK, thereby providing 250 nsec. for data settling time and skew margin. Another solution would be to stop SCK prior to any changes in NPCS, which could provide any margin deemed appropriate.

Settling time could be fairly important if an input register other than the '597 is used. The '597 nearly completely eliminates metastability, because the asynchronous external data captured on the rising edge of NPCS has 4 usec. in which to settle before being latched into the shift register by NPCS becoming low. Although a metastable state could theoretically persist forever, a standard rule-of-thumb is that it will not persist for longer than three times the normal propagation time. In this case, that would be 75 nsec. Longer delays than this only marginally improve an already acceptable failure rate. Simpler (and more common) parts like the 74HC165/166 could be reliable in this application if given at least 75 nsec. for captured data to settle before serial shifting. The '166's parallel load is synchronous to the shift clock, which is not perfect for this situation, because the scan chain clock would repeatedly load the asynchronous data while NPCS were high so that only one clock period would be provided for metastability resolution. The '165's load is asynchronous, but it actually provides less settling time because the parallel load is level sensitive, essentially wasting all of the NPCS high time that could have been used for settling had the data been captured on the rising edge of NPCS. The '165's settling time is further diminished by the worst case skew between NPCS and SCK, whereas the '166 would provide one full clock period of 500 nsec. for the parallel loaded data to settle before the first serial shift. Although the '597 would be theoretically better, this is sufficient margin for the '166 to perform as well as the '597.

If an FPGA is used for a scan chain input register, fewer resources would be consumed by emulating the single-buffered '166 instead of the double-buffered '597. Therefore, whether we continue to use actual '597s or switch to '166s for standard parts, accommodating the '166 is likely to increase the efficiency of our I/O implementations. This requires that SCK continue to operate while NPCS is high. As already mentioned, NPCS would change only on negative SCK edges and the maximum tolerable skew between SCK and NPCS would be 250 nsec.

As for the output side of the scan chain, the '595 is the only acceptable standard part and a synthesized replacement needs to act similarly. However, the synthesized part could improve on the '595 by making the reset output more reliable and by reducing external inverters by resetting to 1 or 0 as appropriate. If we know enough about a subsystem's final configuration to put inverters in the circuit then we know enough to program an output inversion in the PLD/FPGA.

CONCLUSIONS

1. Upstream MOSI and downstream MISO data input to a board will be parallel terminated near the receivers by 130 Ohm and 1000 pF.
2. SCK, NPCS, and Reset will connect directly from upstream to downstream (including downstream loopback) connectors, i.e. they will be bridged rather than repeated.
3. All end-chain boards will parallel terminate SCK, NPCS, and Reset with 130 Ohm resistors near the receivers.
4. Daisy-chain and loopback boards will provide a jumper-enabled 130 Ohm termination resistor for each of the three signals, SCK, NPCS, and Reset. One leg of the resistor is permanently attached and the other is connected into the circuit by a removable or soldered jumper.
5. The scan chain controller/master will change serial out data (MOSI) and parallel load (NPCS) at negative transitions of the scan chain clock (SCK).
6. Scan chain input registers may be:

1. 74HC597. Connected to the scan chain as described above ('597 Architecture).
2. 74HC166.

1. Shift/load (pin 15) connected to inverted NPCS.
2. CK INH (pin 6) connected to digital ground.
3. CLR (pin 9) connected to scan chain reset.
4. CK (pin 7) connected to SCK.

3. Synthesized emulation of 74HC166. Emulation of CLR is not required.

7. Scan chain output registers may be:

1. 74HC595. Connected to the scan chain as described above ('595 Architecture).
2. Synthesized 74HC595 improved as follows:

1. The shift register and output register power-up to the same data state as is imposed by the reset control.
2. Reset control applies to both the shift register and the output register asynchronously to the shift clock.
3. The reset data may be 1 or 0 depending on what is safe for circuitry controlled by the scan chain.

STEPPER MOTOR I/O

GENERAL

The interim boards contain a stepper driver circuit that will be changed for the new version. The changes will be:

1. The HCT164 plus HCT273 pairs shown in some schematics will not be used. All three boards that have stepper interfaces will have an even number, so octal registers would not produce scan chain holes and synthesized scan chain output registers can be any width.
2. Unless there is some compelling reason to use '595s, the scan chain output registers will be synthesized in order to improve power-up/reset reliability. In particular, the I1 and I0 inputs of the '3717 stepper drivers will reset to 1 instead of 0 (if '595s are used, the I0 and I1 controls must be inverted by external gates (e.g. 74x04, not the 74x240 shown in some of the interim system schematics). The reset state of Phase controls may be either 0 or 1.
3. The PLD/FPGA must be self-booting, preferably with internal flash or EPROM for configuration.
4. The A and B winding drivers of every '3717 will be connected to the A and B winding feedback motor control bus wires through 1 MOhm resistors. See the CD3200/3500 Chopper Driver circuit (drawing number 963042X rev B) for details.

At least two of the scan chain inputs will be taken to standard three-pin flag jacks. The other two pins of each jack provide +5 and digital ground to an opto-interrupter. The flag pin is connected to a scan chain input register bit and to a 3.3K pullup resistor. If the board has room, all four inputs will be similarly connected. A standard IC ('597 or '166) will be used for the scan chain input register unless a programmable device already used for other reasons has spare pins.

The following is an arbitrary assignment of wires to the standard (not loopback) motor control bus (scan chain input and output plus winding feedback wires):

• 1 and 2 are scan chain master data out (MOSI) + and -.
• 3 and 4 are scan chain shift clock (SCK) + and -.
• 5 and 6 are scan chain parallel load (NPCS) + and -. Input to the board.
• 7 and 8 are scan chain master data in (MISO) + and -.
• 9 and 10 are scan chain Reset + and -.
• 11 and 12 are A and B winding feedbacks.
• 13 and 14 are unused in the standard motor control bus.

The loop back motor control bus has 16 wires instead of the standard 14. Wires 1 through 12 are identical to the standard bus. The remaining wires are used as follows:

• 13 and 14 are scan chain master data out (MOSI) loopback + and -.
• 15 and 16 are scan chain master data in (MISO) loopback + and -.

RIGHT PANEL MOTOR DRIVER BOARD REQUIREMENTS

This board provides the interface to the four syringe motors, one wash block motor and one spare motor. It is connected to the motor scan chain as a loopback board in order to reserve the scan chain end position (with its reduced wire count) for the Loader Board.

1. The board is located on the inside front right panel directly under the wash block motor.
2. It is mounted with the component side facing the inside of the instrument.
3. It is no more than 6.5" horizontally by 4.5" vertically.
4. Looking at the component side, jacks for attaching to the four syringe motors are located on the right edge. The wash block motor jack is located as near as possible to the upper right corner of the board. The spare motor jack may be located anywhere on the board. Each motor jack is the standard 5-pin missing-center stepper connector (as used in CD3500/3200). Alternatively, a 4-pin jack may be used. In either case, the four wires attach to the two windings of the motor.
5. A 16-pin loopback motor control bus connector (.1"-centers box type with ejector levers) may be located anywhere on the board but, in the absence of other considerations, closer to the right side is preferable to avoid having the cable crossing over and interfering with access to the board. The cable will leave the board to the right. Because this is a loopback cable, the serial output from the output tail register connects (through a 75174 driver) to the MOSI loopback wire; and the input to the input head register connects (through a 75175 receiver) to the MISO loopback wire.
6. The 8-pin molex power connector used throughout the system will provide digital ground, +5V, and +24 volts to the board. Pins are assigned as follows:

1. 1 and 2 are +24V.
2. 3 and 4 are Ground.
3. 5 is +5V.
4. To recover board space, the power connector may be reduced to only the five pins actually used.

7. Three 74HC597 or 74x166 ICs will comprise the scan chain input registers. Alternatively, the input function may be incorporated into the PLD/FPGA used for scan chain output.
8. The 24 scan chain outputs, which control 12 '3717 motor drivers, will be provided by a PLD/FPGA that will self-boot and reset with I0 and I1 controls at 1 and Phase controls at 0 or 1. If there is room, this device should be socketed. If convenient, some means (such as an external control pin) will be provided for decoupling the spare motor from the scan chain in order to allow the motor address to be used elsewhere.
9. Two 75175 receivers and one 75174 transmitter are used for scan chain interfacing.

Each motor driver section, including connector, consumes 1.6 sq. in. using a non-optimal layout on the interim Right Panel board. If this same layout were used, the six driver sections would consume 9.6 sq. in. The power and motor scan chain connectors and input power capacitor consume 2.5 sq. in. Three 74x166, two 75175, one 75174, and related discretes consume 4 sq. in. Together, these groups consume 16 sq. in. of the 29 sq. in. board area, leaving a reasonable amount of space for a PLD/FPGA, printed wiring, mounting standoffs, and border.

In our meeting of 10/5/99, we concluded that this board would require very little design effort, because the interim stepper driver design could be cut and pasted into the circuit. This would be nearly true if we would accept the poor boot/reset output control afforded by the 74HC595. However, the superior PLD/FPGA approach would not be a difficult design-- it just wouldn't be the near-zero design effort that we predicted. The synthetic improved 74HC595 would be used in other places in the system, so this is a fairly efficient use of design resources.

APU-MSM COMMUNICATION

CDNEXT APU SYSTEM DESIGN REPORT 2 (CDXSYS2.DOC) APU-MSM Communication Cable Pinout describes how the data station's HSSL clock is routed directly to the clock sent down to the MSM. Not mentioned is what to do about terminating this new multi-drop line. In the real instrument, MSM will be the end of the HSSL line and should have the termination resistor. APU should be a non-terminating drop. The APU's printed wiring should locate the APU's clock receiver (75175) as close as possible to the clock lines traversing the APU board from the HSSL connector to the MSM connector (i.e. minimal "stub length").

Normally, the APU would not have a terminating resistor but, during development, it may connect to the data station without an MSM. For these occasions, it should have a terminating resistor with one leg jumpered. The jumper is removed when an MSM is connected.

SYSTEM DESIGN REPORT 4

10/11/99

[Report3]

[Report5]

1. SCAN CHAIN

1. Integrity Test, End-Chain Board.
2. Startup.
3. Stepper Driver Registers.
4. I/O Scan Chain Pinout.

2. MSM.

1. Subsystem Requirements.
2. Tower.
3. Steppers.
4. Communication Interfaces.
5. [Motor Winding Test].
6. FPGA.
7. Spare Scan Chain I/O.
8. Mechanical Requirements.

SCAN CHAIN (ADDITIONAL DETAILS)

As mentioned in cdxsys3, the end-chain (furthest downstream from the master) board connects the serial output of its MOSI tail register to the serial input of its MISO head register, creating one loop from the MOSI and MISO chains. Each chain is half the length of the loop. In normal operation, the loop is not seen, because the MISO chain is reloaded by NPCS after shifting only a chain length.

To test the integrity of both the MOSI and MISO chains, the controller shifts the full loop without toggling NPCS. The test requires shifting three times the length of one chain. The test operates as follows:

1. The CPU puts the chain controller into test mode.
2. The CPU loads a test pattern into the controller's output chain image.
3. One chain length is shifted, moving the test pattern into the output shift registers. NPCS is not toggled, so the current outputs are unchanged.
4. One chain length is again shifted, moving the test pattern through the end-chain loopback into the input registers. Again, NPCS is not toggled.
5. The CPU writes the normal output bit values into the controller's output chain image.
6. One final chain length shift moves the test pattern from the input chain into the controller's input chain image, while restoring the output shift registers to their normal values.
7. After reading the returned test pattern, the CPU can either restore the controller to normal chain operation or test another pattern, in which case it would have loaded this pattern instead of the normal control bits in step 5.

The forgoing test procedure assumes that the output and input scan chains are of equal length. In reality, the system has fewer actual inputs than outputs. The scan chain controllers should implement equal length input and output registers internally in order to support all possible external arrangements. If the external input chain is shorter than the output then, in step 4, the length of the input chain is shifted, thereby filling the input registers with data from the output shift registers but not all of it. The full output length shift at step 6 fills the controller's input registers with all of the output shift register data. The scan chain controller doesn't know the external chain lengths, but the CPU does. Therefore, in loopback test mode, the CPU will write into the controller the length of each shift. From the controller's point of view, test mode operation is as follows:

1. The CPU evokes test mode by writing to a control flag, e.g. 1 = test mode, 0 = normal.
2. When test mode is selected, NPCS stays low and SCK operates only on CPU command.
3. Whenever the CPU writes to a (one byte) shift length register, the scan chain is shifted that number of bit positions. This doesn't have to be predicated on test mode being selected, as the CPU will not write to this register without having selected test mode.
4. The CPU takes full responsibility for filling the controller's output register with test patterns and reading them back (after shifting) from the input register. It may repeat this procedure several times with different patterns during one test session.
5. When done testing, the CPU writes to the control flag to return the scan chain to normal operation.

Just as with the end-chain board requirement for terminating the scan chain's parallel control signals, SCK, NPCS, and Reset (see cdxsys3: SCAN CHAIN: SCAN CHAIN STREAM CONNECTIONS) only a true end-chain board (one with only one standard connector) should have a hard-wired MOSI-MISO loopback. Daisy-chain and loopback type boards require selectable end-chain looping, which is provided by a removable jumper that connects the serial output of the MOSI tail register to the serial input of the MISO head register.

As explained in cdxsys3: SCAN CHAIN: SHIFT REGISTER COMPONENTS, the 74HC595, which is the only acceptable standard IC for scan chain output, does not reset its parallel outputs unless the scan chain is operating. Some devices, such as solenoids (in most circumstances) can tolerate at least a few seconds in the incorrect startup state when the instrument is powered up. For others, such as stepper motors, the uncontrolled startup state period must be minimized.

One way to reduce the uncontrolled startup period is to synthesize an improved output register, cdxsys3 suggests for stepper drivers. However, the standard component is more cost-effective, both in terms of basic component cost and in cost of extra handling, support, and paperwork. Therefore, in less demanding situations, the 74HC595 is preferred.

The number of situations in which the 74HC595 can be used increases as the uncontrolled startup period is reduced. The current scan chain controller exacerbates the startup problem in two ways. One is that the FPGA that implements the controller is programmed by the CPU and, thus, may not begin functioning at all for at least several seconds after power is applied. The other is that the controller portion of the FPGA does not begin functioning until the CPU enables it. Both of these should be changed.

We can still keep open the option of programming the FPGA via the CPU, as it may prove helpful during development (currently, it is a hindrance in several ways) but the primary means should be self-programming via serial flash memory. This represents a change in our concept that programming by the CPU would be the production configuration.

To further reduce the uncontrolled period, at power up, the scan chain controller should automatically assert scan chain Reset and then toggle NPCS at least once. This could be the beginning of normal scan chain operation for all signals except Reset. It would be acceptable to require the CPU to turn off the Reset signal, saving the FPGA the need to time its activation period. Thus, the scan chain controller doesn't need a startup state machine. The scan chain Reset signal starts up activated and normal scan chain operation begins immediately.

In cdxsys3: Stepper Motor I/O: Right Panel Motor Driver Requirements, using synthesized output registers instead of '595s was strongly recommended mainly because of the uncontrolled startup period. If scan chain controller startup improvements reduce the uncontrolled period to under 1/2 second then '595s would be acceptable.

There are four scan chains in the system: two APU I/O chains (the spare may not be fully implemented in the FPGA); one MSM I/O chain; and one motor chain controlled from the MSM. The I/O and motor scan chains are essentially identical. The bus wire names and functions are described in cdxsys3: SCAN CHAIN. The motor control bus has two additional wires for stepper winding feedback. Its pinout is described in cdxsys3: STEPPER MOTOR I/O: GENERAL. The standard I/O scan chain bus pinout is as follows:

• 1 and 2 are scan chain master data out (MOSI) + and -.
• 3 and 4 are scan chain shift clock (SCK) + and -.
• 5 and 6 are scan chain parallel load (NPCS) + and -. Input to the board.
• 7 and 8 are scan chain master data in (MISO) + and -.
• 9 and 10 are scan chain Reset + and -.

The loop back I/O bus has 14 wires instead of the standard 10. Wires 1 through 10 are identical to the standard bus. The remaining wires are used as follows:

• 11 and 12 are scan chain master data out (MOSI) loopback + and -.
• 13 and 14 are scan chain master data in (MISO) loopback + and -.

MSM

As described in AD46: HARDWARE PARTITIONING: MSM, the MSM board will combine the following subsystems:

1. Tower I/O.
2. Stepper drivers for tower and peristaltic pump.
3. Right Panel Motor Driver board interface.
4. Loader board interface.
5. ADC for motor winding test.
6. FPGA for:

1. Stepper controller.
2. Motor (stepper) scan chain.
3. Support for motor winding test.
4. MSM I/O scan chain for tower and loader functions.

7. CPU for executing scripts related to mechanical operations (not fluid control) and for the higher level functions of the stepper controller.
8. Barcode reader interface (RS232 with CPU UART B).
9. APU interface (RS422 with CPU UART A).
10. PC104 interface for optional expansion (bailout) and logic analyzer access.

CONTROL INTERFACE

The tower subsystem derives from the interim design's tower board. The scan chain interfaces are replaced by direct I/O, eliminating the transmission line buffers (tower board U1, U2, and U3) but not necessarily the scan chain registers. The MSM's FPGA could provide direct I/O control lines, but using the I/O scan chain, which is needed for the loader anyway, would consume fewer FPGA pins.

SENSORS

The four flag sensors, GS2 Home, GS2 Height, GS1 Home, and Door Open, are buffered/inverted by HCT240 U8. Buffering serves no purpose and should be eliminated. All of these inputs except Door Open are motor flags and would, therefore, normally be input to the motor scan chain. However, since the MSM is responsible for both motor and tower control, both motor flags and tower I/O are in the MSM's immediate domain. Putting all tower sensors together may lead to more efficient script execution as well as better wiring locality on the MSM PCB. Therefore, all of these flag sensors will be read into the MSM's I/O scan chain through one register (HC597 or '166) along with the DC motor over- and under-current detectors, as shown in the tower schematic. This leaves two spare inputs, which should be connected to +5V through 10K resistors.

The schematic shows the serial output of the output register U7 connected to the serial input of the input register (U6). This hard-wired MOSI-MISO loopback is incorrect. The loader will be the end of the MSM I/O scan chain. This connection should either be deleted entirely or replaced by a removable jumper to allow the tower section to function as the end-of-chain during development.

ACTUATORS

The tower has three actuator devices, GS2 Release, Door Release, and bidirectional DC Spinner Motor. A stepper interface is also being provided for the spinner function, but the DC interface is needed as a backup in case the stepper is not as useful as we hope.

The interim tower design affords no power-down for either GS2 Release or Door Release. GS2 Release is activated to drop the tower and is never on for more than a moment. However, Door Release operates interactively with the user, whose behavior is unpredictable. Therefore, it must remain on for an unpredictable time and should have power-down capability. The ULN2003 (U10) driver has one spare output that can be used for this. The circuit should be identical to the solenoid drivers shown on the Left and Right Panel schematics except that the pulldown uses three instead of two sections of the ULN2003. To maintain a consistent (compared to other power-down actuators) software interface, the power and control bits need to be placed consistently on the output register ('595). One way to achieve this is to use the following pin assignments:

• Q0 (pin 15) = Door Release High Power.
• Q1 (pin 1) = Door Release On.
• Q2 (pin 2) = GS2 Release On.
• Q3 (pin 3) = Spinner On.
• Q4 (pin 4) = Spinner Direction.
• Q5-Q7 (pins 5-7) = spares.

The L293 used to drive the Spinner Motor requires true and complement of the direction signal. An HCT240 is used in the interim schematic. This should be replaced by an HC04. The bus driving capability of the '240 isn't needed and HCT is the wrong technology. The L293's logic input levels are standard CMOS, Vh = 2.3V min and Vl = 1.5V max, which is also compatible with the serial output register HC595. The rest of the Spinner driver circuit shown in the tower schematic can be used without change.

The MSM will provide the drivers for the tower lift motor and spinner (again, we won't know whether to use this or the DC motor until we have had a chance to experiment in a real system). It will also provide the drivers for the peristaltic pump and one spare motor.

If the fast scan chain startup reset described above is implemented and results in a sub-half-second (from power on) reset, then two '595s could be used to control the four motors, saving 16 FPGA pins (the 32+ internal registers that would be consumed probably are not as significant as the pins). If external registers were used then two inverters would be needed for each motor's I0/I1 (these pins of the pair of '3717s used for each motor are connected in parallel, so only two control lines are needed). As explained in cdxsys3: STEPPER MOTOR I/O: GENERAL, the '595 resets outputs to 0s, which would select high power in the '3717. Note that the negativity toward '595s for motor control expressed in that document did not take into account the possibility of a faster reset.

For the sake of control software, we should probably choose one motor control means, using either '595s or the synthesized improved '595, because the power controls are reversed between the two approaches. If the synthesized version is used, the main MSM FPGA would not have to be burdened with this I/O, as an efficient interface to an external PLD/FPGA already exists in the form of the scan chain. A common PLD/FPGA could be developed to support the six motors on the Right Panel Motor Driver, the four motors on the MSM, and the four on the Loader.

To reduce the wires in the Loader connector, the Loader will be the end of the motor scan chain. The Right Panel Motor Driver will provide an upstream motor loopback connector for which the MSM provides a matching downstream connector (the pinouts are identical-- upstream vs. downstream only defines signal direction). It makes little difference whether the MSM-local motors are upstream or downstream of the Right Panel Motor Driver unless the local motor interface is implemented in the motor controller FPGA. Although this will probably not be done, nothing is lost by allowing for it. Therefore, the motor chain will begin at the locals; traverse to the Right Panel Motor Driver Board, where it will loop back to the MSM; and finally traverse to the Loader.

Regardless of whether scan chain outputs for local motors are provided by the FPGA or external registers, line drivers and receivers are not used for on-board communication. Also, they are not used for tower functions, which are direct I/O in the new design. Thus, the only communication interfaces are the following:

1. Downstream motor loopback to the Right Panel Motor Driver (RPMD).
2. Standard motor and standard I/O scan chains to the Loader.
3. Clocked asynchronous link to the APU. For a description of this interface, including pinout, see cdxsys2: DISTRIBUTION OF FPM SUBSYSTEMS: MOTOR CONTROL, TOWER, AND LOADER.
4. RS232 to the barcode reader.

Unlike the I/O boards, MSM is the scan chain master and needs to buffer SCK, NPCS, and Reset in both the I/O and motor scan chains. These signals are buffered only once in the entire system. They are distributed in parallel and don't need to follow the link. For example, motor control data goes out to the RPMD and only the return data can go to the Loader interface, but SCK can branch after the buffer, with one branch going to the RPMD connector and the other to the Loader connector.

MOSI data being transmitted to the RPMD and MISO data coming in from it are both buffered. MOSI and MISO loopback data from the RPMD interface are taken directly to the Loader interface without additional buffering. Essentially, MSM is just a passive connector for the data to travel between RPMD and the Loader.

The MSM will consume eight transmitters (2 * 75174) for SCK, NPCS, Reset, and MOSI for the I/O and motor scan chains. It will consume two receivers (1/2 * 75175) for MISO in the two chains. The APU interface requires three transmitters (3/4 * 75174) and four receivers (1 * 75175). The 11 transmitters consume three 75174s with one spare section. The six receivers consume two 75175s with two spare channels.

The spare 75174 channel can be used to drive the "wink" LED. Previously, a spare LM339 from the vacuum accumulator wet circuitry was used, but this circuitry has moved to the new VPM. Either output of the 75174 may be used-- both can sink 60mA.

The only mixed signal requirement of the MSM is the motor winding test ADC. The TLV1549, an inexpensive ($1.90) single channel 10-bit ADC, could be used in this application, but its serial interface requires either an FPGA- or CPU-synthesized state machine for control. The raw motor feedback can't be input to it because the signal is differential and floating in the middle of 24V (when it isn't 0). If all of the motors were disconnected (and a driver turned on) the common mode input voltage would be 24V. Consequently, an amplifier is required to convert the signal to a 0-referenced single-ended input. Considering the software and hardware requirements to use the TLV1549, the original single-slope integrating converter from the CD3500 appears fairly equal. However, it too requires more than the MPM circuit indicates. Our system provides +/- 15V that could be used for the circuit except that it isn't clean enough. So, in addition to the many discrete components in the MPM circuit, we would have to add circuitry to clean up the power supplies. LDO regulators would be ideal for this except that negative LDOs are not available. A reasonable alternative would be 3-terminal adjustable regulators set to 11V.

Speed is irrelevant so there is no need to waste FPGA resources. A CPU program can access the serial ADC or control the integrating converter. The serial ADC has a three-wire interface (CS and CLK input and D out). The integrating converter requires two wires, the control bit and the comparator output. At least three pins of CPU Port A are available, which could take the FPGA entirely out of the design.

For the integrating converter, CPU TGATE1 or TGATE2 must be used for the input (from the comparator) in order to achieve accurate timing. This is required because the MSM CPU, unlike the MPM CPU, is always multitasking and can't be dedicated to conversion timing. The old integrating converter circuit uses two LF356 op amps, which would be replaced by one LF412C dual op amp. The 74HC00 used for the control line buffer, or some other HC component (e.g. HC04), would still be needed, because both the CPU and FPGA have Vout high of only 2.4V compared to the HC's 4.9V.

The only additional component needed with the serial ADC is the input amplifier. Given the possibility of 24V common-mode voltage, a current amplifier would be simpler than an op amp. However, the differential signal source comprises two taps off an equivalent 1M-154K-1M resistive divider. The Thevenin equivalents are Vth = 12.8V and 11.14V and Rth = 536K. Therefore, the signal inputs to a current amplifier, such as LM3900, would be 239 nA and 208 nA. But the input bias current (inverting input only) of the LM3900 varies from 30 nA to 200 nA. This much variation would reduce the initial accuracy to one bit. The alternative is to use a dual supply op amp with the signals dropped down below the supply with resistors. But this suffers the same component bloat that the old circuit experiences. Since the old circuit is cheaper and has already been tested (I am assuming this) we will use it, replacing the single op amp with a dual, the HC00 with an HC04 (because it may already be available), and the PIA interface with direct connections to the CPU.

The split analog power requirements are 6mA for LM311 and 7mA for LF412C. Any small 3-term regulator can supply 13mA. National's LH7001 positive/negative adjustable regulator provides both voltages in one package. Further, its low 1.2V VDO makes it close to an LDO. With this low VDO, it could probably provide +/- 12V from our system's +/- 15V supplies, especially considering our low current requirement (the LH7001 can deliver 100mA on both outputs).

The FPGA needs to provide an I/O scan chain for tower and loader functions. However, 256 bits is much larger than needed. As described above, the tower functions, including two spare inputs and three spare outputs, consumes eight input and eight output bits. The loader currently also consumes eight input and eight output bits. A 64-bit scan chain (64 outputs and 64 inputs) would afford ample room for expansion.

The flash and RAM are accessed through a GAL22V10 in the FPM. The FPGA should continue to be uninvolved in flash access as this could prevent BDM access in the event of FPGA problems. However, the FPGA will have to assume responsibility for RAM access, because the CPU holds its chip select outputs high (inactive) rather than tri-stating them when it grants the bus to the motor controller.

The FPGA provides access to the 7-segment LED but not to the "wink" LED. The wink allows the CPU to announce that it is alive even when the FPGA is not functioning. Therefore, it is controlled by one of the CPU's Port A pins.

As described above, the current tower I/O requirements leave two spare inputs and 3 spare outputs. It would cost little in components and board space to add another eight inputs and eight outputs to the MSM I/O scan chain. The spares could be used for additional tower functions or random functions in the body of the instrument but not for the loader. Since scan chain shift registers provide only logic inputs and outputs, in most uses they need additional circuitry. It's difficult to predict what might be needed, but solenoids are likely. Solenoids consume two bits, one for on/off and one for power. However, being connected to solenoid drivers doesn't prevent an output from being used for some other purpose. Therefore, it is reasonable to provide some solenoid drivers but to provide a means to tap into their control bits directly for a non-solenoid use.

We have two similar solenoid driver circuits, normal power, as on the Left Panel Module, and high power, as used for the tower's GS2 Release and Door Release. The high power circuit requires four sections of a ULN2003 and the normal three sections. Since each ULN3002 contains seven sections, one IC could support one high power and one normal solenoid.

The remaining outputs of the tower's output scan chain register should be used before the spare, as more compact register arrays can improve software efficiency. However, the power and on/off bits should be placed consistently with other drivers. Therefore, the Q5 output from the tower's output register should not be used as a solenoid control bit but left as uncommitted logic. The spare output bits of the tower scan chain output register would be used as follows:

• Q5 (pin 5) = logic.
• Q6 (pin 6) = high power solenoid power control bit. Drives one ULN3002 section that drives TIP125 as in the Left Panel.
• Q7 (pin 7) = high power solenoid on bit. Drives three ULN3002 sections.

The output bits of the spare shift register would be used as follows:

• Q0 (pin 15) = high power solenoid power control bit.
• Q1 (pin 1) = high power solenoid on bit.
• Q2 (pin 2) = normal solenoid power control bit.
• Q3 (pin 3) = normal solenoid on bit.
• Q4 (pin 4) = normal solenoid power control bit.
• Q5 (pin 5) = normal solenoid on bit.
• Q6-Q7 (pins 6-7) = logic.

All of the spare bits should be brought out to the area of the board reserved for tower connectors. Each solenoid driver should have a normal 2-pin solenoid jack. The three spares from the committed tower control output register can be brought to a 5-pin jack that includes one digital ground and one +5V pin. The eight outputs from the spare register can be brought out to a 10-pin connector that include one digital ground and one +5V pin. Note that all but three of the logic bits alternately serve solenoid control and, if used in this capacity, may not be used for logic.

Each of the 10 spare inputs should be pulled up to 5V through a 10K resistor. Two sets of five of these can be brought out to 7-pin jacks including one digital ground and one +5V pin.

The total component consumption proposed for spare I/O is:

1. The free two inputs and outputs.
2. One scan chain input register ('166 or '597).
3. One scan chain output register ('595).
4. Four TIP125, LED, catch diode, resistors for solenoid output.
5. Two ULN2003.
6. Four 2-pin solenoid jacks.
7. One 5-pin, two 7-pin, and one 10-pin jack.

1. The board is located on the bottom half of the left front panel solenoid separator plate. The Left Panel Module is located on the upper half of the plate.
2. It is mounted with the component side facing the inside of the instrument.
3. It will measure 14 inches horizontally by no more than 6 inches vertically (this is 1/2 of the plate; it may be able to steal some vertical dimension from the Left Panel Module if necessary).
4. Looking at the component side of the board:

1. One 16-pin loopback motor control bus connector (.1"-centers box type with ejector levers) is located on the left side anywhere between the middle and upper corner. A cable will connect this to the Right Panel Motor Driver (RPMD).
2. Tower I/O connections will be located along the bottom of the board starting at the left side and extending in a single row toward the right. They may be in any order convenient for the related MSM circuitry and will be located as close together as is convenient for service access. The connectors are:

1. Two stepper jacks. Each jack is the standard 5-pin missing-center stepper connector (as used in CD3500/3200). Alternatively, a 4-pin jack may be used.
2. One 2-pin DC motor (Spinner) jack.
3. One 4-pin jack for GS2 Release and Door Release.
4. One 6-pin jack for GS2Home/Height.
5. One 6-pin jack for GS1Home/Door.
6. One 6-pin jack for two spare scan chain inputs and three spare scan chain outputs.

3. Spare scan chain I/O jacks will be located above the tower I/O connections. These will comprise:

1. Four 2-pin solenoid jacks.
2. One 5-pin, two 7-pin, and one 10-pin logic jacks (mechanically similar to solenoid jacks).

4. On the bottom edge of the board, as near to the center as the tower jacks allow, will be located one 14-pin standard motor bus connector. Immediately above this will be located one 10-pin standard I/O scan chain bus connector. These two connectors may be swapped or, if there is sufficient room, both placed along the edge of the board. These jacks will have ejector levers, for which sufficient clearance between each other and the right-most tower jack must be provided. Ribbon cables from these connectors will join power wires in a harness that terminates in a DB37 shrouded male plug that will mate with a female receptacle on the Loader board.
5. On the upper right corner of the board will be located the standard 5-pin (or 4) stepper motor jack for the peristaltic pump.
6. On the right side below the peristaltic pump jack will be located a stepper motor jack for the MSM's spare motor interface.
7. A standard 8-pin (Molex) power jack will be located in the bottom right corner of the board if convenient or on the right edge as near to the bottom as is convenient.

CDNEXT: APU SYSTEM DESIGN REPORT 5

10/18/99

[Report4]

[Report6]

1. Scan Chain Topology.

1. Loop structure.
2. APU Change.
3. I/O Boards.
4. End Board.

2. Scan Chain Register pullup/down resistors.

SCAN CHAIN TOPOLOGY

Cdxsys3 and 4 describe the new scan chain design without addressing how current boards are affected by changes from the interim design. The following review describes the interim design, explains the rationale for the new design, and tells how existing boards are affected.

The interim system design mixes output and input registers in the scan chain. Each board in the chain has two connectors, an "input" from the upstream board (or master) and an "output" to the downstream board. The output connector on the last board in the chain loops back to the master. The distinction between MOSI and MISO data (in the bit stream) exists only at the master. On the slave boards, intermingled output and input bytes flow in one direction down to the last board, from where they return to the master.

The interim scan chain topology exhibits the following problems:

1. Each board must have two connectors with substantial wire redundancies.
2. An extra cable is needed to loop the chain back to the master.
3. Scanning bandwidth and/or scan space are wasted. MISO data is returned to the master by the return cable at the same rate that the MISO and MOSI data are shifted down toward the end board, but the return data is not used for any purpose. If the MISO data were returned through input shift registers instead of a passive cable, all of the addresses stolen from the output space could be recovered, essentially doubling the total address space without increasing the scan period. This deficiency is particularly acute in the motor scan chain, which cannot add input data to the chain using the interim topology, because all 56 bits are used for output and the chain length cannot be increased due to bandwidth requirements.

As described in detail in cdxsys3, the new design merges the downstream and upstream data paths into a single cable. The total amount of wiring is generally reduced because only the four data wires of the return path are replicated in the unified cable, compared to the full bus data return cable in the interim design. The unified cable affords additional opportunity for reducing the number of wires in certain cases, specifically loopback and end-of-chain. The end-of-chain wire reduction is especially valuable when strategically located. For example, making the Loader Board the end of both the MSM I/O and motor scan chains eliminates four wires compared to the loopback and 14 compared to the interim design.

The unified cable design is more flexible than the separate return cable, because it can support both separate and mixed input and output, whereas the separate cable topology requires mixed input and output. Wherever possible, separate input and output is preferred, because of its better address/bandwidth utilization, as already explained. However, in a few cases, separation is not feasible. For example, the new VSP controller is an Analog Devices ADSP-2104 with one of its two serial ports serving as a scan chain shift register. The port has no flow-through capability so this is emulated using the port's receive and transmit functions. Consequently, one full-duplex port is entirely consumed in emulating one-way data flow in the scan chain. In would be feasible to use one port for MOSI (output data) and the other for MISO (input data) but the other port will be used for reading a serial ADC. If the '2104 is placed at the end of the MOSI scan chain so that the MOSI-MISO loopback occurs exactly at the border between the input and output (simulated) scan chain registers, input and output data will be separate. Otherwise, they will be mixed in this case. The new topology has no problem with this-- it just allows devices to use the more efficient separated I/O if they choose to do so.

The interim design appears to afford a slight advantage in testing the integrity of the scan chain, because it feeds back all of the output data to the controller for verification. As described in cdxsys4, the new design requires putting the scan chain controller into a special loopback mode in which it doesn't assert the broadside load strobe NPCS or else none of the output data comes back to the controller for verification. This is actually true only if all 256 bits of the MISO data path are used for input. The sparser the MISO path, the more MOSI data is returned to the controller. For example, if 31 of the 32 MISO bytes are used for input, then the last input byte will be the last byte of output. That the output data begins being returned at the end of the chain and works toward the head as more inputs open up is particularly advantageous because only the last byte is really needed for verifying the entire chain (unless it contains all 0s or all 1s) because it has to traverse the entire chain. It might be reasonable to make the last byte of the MOSI scan chain a register connected to no outputs in order to be able to safely load arbitrary patterns for testing the chain.

Assuming that the MISO chain is filled with real inputs and, therefore, in the new design the special loopback mode must be invoked to test the output data, the fact that the interim design would afford continuous, automatic feedback in the same situation is no real benefit. Input data can be tested against output only in cases of actual output. Otherwise, the input data reflects the external signals captured on NPCS. Whatever has been written to the output image is ignored. But specific scan chain addressing is very fluid; adding, deleting, or changing one board affects all downstream addresses. It would be an unreasonable complication of the scan chain controller to either embed or download an I/O map in order to perform continuous integrity testing. The CPU knows the mapping, through the analyzer configuration file (analyz.ini) but it can't afford to perform continuous checking. Consequently, the interim design could only do the integrity test in a special mode, just like the new design.

The interim APU board contains a scan chain loopback jack, J9, which provides a return path for the data, i.e. MISO. It also contains the terminating resistors for SCK, NPCS, and Reset. As explained above, the new system merges the output and input paths into one cable. One board must provide the MOSI-MISO loopback and the terminating resistors, but it is not the APU. Therefore, J9 is eliminated. Its data return function (the two MISO wires) is moved to the unified scan chain connector J7.

In the interim system, APU scan chain data traverses the following path:

1. The CPU writes output data into the FPGA's MOSI image, which contains exactly 32 bytes even if the chain is not fully populated.
2. MOSI data leaves the APU via J7:1,2 and arrives at the first downstream board, Left Panel Module, on J1:1,2.
3. MOSI data from J1:1,2 is input to U6 74HC597 pin 14 input (i.e. the data capture by U6 on NPCS is consider MISO) shift register. Thus, the first byte in the MOSI image is actually not writable (it can be written, but the data is discarded).
4. Serial output from U6 pin 9 is input to a chain of eight output registers U18 through U11 74HC594 (these will be replaced by '595). Each register's serial output pin 9 feeds the next register's serial input pin 14. These eight bytes (64 bits) of the MOSI image are writable.
5. Serial output from U11 goes to LPM J3:1,2 and from there to Tower J1:1,2. This connection is a form of loopback, with the single connector providing both the input and return data. The data travels from J1:1,2 to the serial input pin 14 of U7 HC594. The corresponding byte in the MOSI image is writable.
6. U7 output pin 9 goes to input pin 14 of U6 HC597 input register. This is another byte in the MOSI image that can't be written.
7. U7 output pin 9 goes back to J1, this time to pins 15,16. The data coming back from Tower J1 is input to LPM via J3:15,16. It exits via J2:1,2 and arrives at Status Board J1:1,2. Thus, LPM passively bridges Tower J1:15,16 to Status J1:1,2.
8. Status Board J1:1,2 is input to U3 '594 pin 14. The image of this byte is writable.
9. Serial output from U3 pin 9 goes to U6 DS1267 input pin 11. This IC contains two 8-bit serial rheostats. The first is used to control speaker volume and the second the period (i.e. larger number yields lower tone). The MOSI images of these bytes are writable.
10. From U6 pin 13 the serial data goes to serial input pin 14 of U2 '597. The MOSI image of this byte is not writable.
11. From U2 serial output pin 9, the data goes to J2:1,2 and from there returns to the APU via J9:1,2.

In the new system, as already mentioned, the APU will have only the one unified bus connector. The data path will be APU to Right Panel Module to Status (loop back), to LPM, to VPM. There is no Tower Board. The APU will have one downstream connector. The RPM will have three scan chain connectors: upstream to the APU, loopback to the Status Board, and downstream to LPM. The LPM will have two connectors: upstream to RPM and downstream to VPM. The VPM will have one upstream connection to LPM.

None of the units, except optionally the VPM, will mix MOSI and MISO data. For example, MOSI data coming from upstream into the Status Board will go to U3 '595; from U3 to U6 DS1267; and from U6 back to the (loopback) cable, skipping U2. MISO data coming from downstream (from LPM via RPM) into the Status Board will go to U2 '597; and from U2 back to the (loopback) cable.

The RPM and LPM boards will contain many of the same components and sub-circuits as in the interim design but in different proportions. However, both of the new boards will contain input and output registers. As with the Status Board, the two will not mix. Upstream MOSI data flows down through only output registers while downstream MISO data flows up only through input registers.

On boards that may optionally serve as the end of a scan chain, CDXSYS4: SCAN CHAIN END BOARD: INTEGRITY TEST suggests including a removable jumper to connect the serial output of the MOSI tail register to the serial input of the MISO head register. CDXSYS3: SCAN CHAIN: SCAN CHAIN STREAM CONNECTIONS suggests the same treatment for the parallel control signals SCK, NPCS, and Reset. Loopback boards, such as Status, will not have the option, as they cannot serve as end boards, and end boards, such as Loader and VPM, will have these connections hard-wired. Only boards that can operate either in the middle or at the end of a scan chain, i.e. Left and Right Panel Modules, need the option. Further, the end board option will only be invoked during development, if at all.

A terminator/loopback plug affords a cleaner solution than jumpers on the board. The signals can be brought to jack into which a jumper adapter simultaneously terminated all three control signals and connects the MOSI tail to the MISO head. The adapter comprises three resistors and one loopback wire. This does not have to be a production assembly because it is only used during development. The most convenient arrangement would be an 8-pin (or 10-pin with one missing-pin key and one pin unused) female box type connector on the board and a hand-wired male terminator plug.

SCAN CHAIN REGISTER PULLUP/DOWN RESISTORS

In most of the interim circuits, single-ended data on the outputs of line receivers 75175 is pulled up to 5V through 10K resistors. For example, on the Status Board, R12 pulls up MOSI input from U4 pin 3 and R11 pulls up NPHRST (scan chain reset) input from U4 pin 13. The only purpose that these resistors serve now is to avoid floating inputs to CMOS parts in the event of catastrophic failure of the line receivers. This is not a very likely failure scenario in normal use but may occur during development and servicing.

Pulling up these signals is the opposite of the correct failure response. Reset presumably makes things as safe as possible. Forcing reset in case of failure of reset control is clearly better than forcing unreset. Regarding data, since reset clears output registers, presumably the circuits are designed to be safest in the 0 state if possible. Consequently, the safest replacement for valid data is 0. Therefore, all of the single-ended control signal pullups of NPHRST and MOSI or MISO data should be changed to pulldowns. The 10K value is still adequate, as none of these components are TTL.

CDNEXT: APU SYSTEM DESIGN REPORT 6

10/19/99

[Report5]

1. [Report7]

MSM Without Loader.

1. Scan Chain Termination.
2. Missing Motors.

MSM WITHOUT LOADER

SCAN CHAIN TERMINATION

The MSM controls two scan chains: the motor chain (MPI) for the entire instrument and an I/O chain for its own communication with the Loader board. The Loader has been chosen as the end board for both of these chains in order to reduce the wires in its connection to the main body of the instrument. As the end-of-chain, the Loader is expected to terminate both the motor scan chain and the I/O scan chain. To terminate a scan chain means to provide the MOSI-MISO loopback and terminating resistors for the parallel control signals SCK, NPCS, and Reset (See cdxsys4: Scan Chain Additional Details: End-Chain Board). Each of these scan chains has it own SCK, NPCS, and MOSI-MISO loopback, but they share a common Reset (this eliminates two wires from the Loader cable).

Andy O has reminded us that a CS model instrument or one in a tracked cluster won't have a Loader. Therefore, the MSM will require one or two optional termination plugs similar to the one described in cdxsys5: Scan Chain Topology: End Board. If one plug is used then it must contain five terminating resistors and two loopback wires. If two plugs are used, one to terminate the I/O scan chain and one the motor chain then a standard terminator adapter could be used for both of these and the optional APU daisy-chain board terminator. In this case, one of the MSM scan chains' terminator jack Reset pin pairs would not be connected in order to avoid double-terminating the shared Reset.

MISSING MOTORS

If the Loader is not present then the actual motor scan chain will be shorter than expected by the scan chain controller. This brings up the general question of what happens when any scan chain is not fully populated. First, it should be clear that the outputs (MOSI data) are not affected by any downstream events. Missing or damaged shift registers have an effect only at their own level and downstream.

What happens to the inputs (MISO data) is not obvious. If less than 14 motor driver registers were present, the MOSI-MISO loopback would occur upstream of where it would be expected, possibly causing some of the input data to be pushed off the head end of its image in the controller. However, regardless of where the loopback occurs, if the chain shifts 56 bits and the input image contains 56 bits, then the head of the input chain will always end up at the head of the image. The early loopback can't change this. What it does do is to fill some of the input image with output data from the previous scan cycle. Since each motor adds four output and four input bits to the full MOSI-MISO loop, each missing motor (registers) allows eight output bits, i.e. the control signals for two motors, to be passed into the input image.

The same effect occurs on I/O scan chains. Cdxsys5: Scan Chain Topology: Loop Structure suggests taking advantage of this effect by making the last byte of the APU I/O MOSI scan chain a register connected to no outputs in order to be able to safely load arbitrary patterns for testing the chain. This cost practically nothing for the APU scan chain, whose last MOSI element is in the VPM DSP's on-chip RAM. However, it is not feasible for the motor scan chain, which can't afford to give up a motor slot. It may also not be feasible (due to cost and complexity) for the MSM I/O scan chain, because it would have to be implemented in both the Loader and optionally in the MSM for Loader-less systems.

VPM REQUIREMENTS

VPM.DOC (Word 97 @ k:\cdx\doc\analyzer)

Last modified 10/28/99

DESIGN REQUIREMENTS

1. System communication:

1. Attached as the end board of the APU I/O scan chain.
2. An input (MOSI) register receives commands from the APU.
3. An output (MISO) register sends status to the APU. This register is contiguous with the input register and follows immediately after it; i.e. the MOSI-MISO loopback is a fixed design feature. If the MOSI scan chain is filled then the VPM's input register represents the end of the chain and all of the output register the beginning of the MISO chain. If the MOSI chain is not filled then some portion (or all) of the output register is actually part of the MOSI chain.
4. A software/firmware handshake method will be implemented to allow APU commands to serve multiple functions; i.e. unlike in simple I/O devices, the scan chain bits used in the VPM do not attach directly to specific I/O hardware.

2. Vacuum and pressure vent control. Two solenoid control circuits with power-down capability will be provided for the pressure and vacuum venting valves (#71 and #72 in the CD3200). Each driver circuit is controlled by two signals, on/off and high/low, but the APU control command will provide only an on/off signal. The VPM controller will effect power-down by setting high power when the command bit changes from 0 to 1 (activate solenoid) and then changing to low power after a 1/2 second delay. The power setting when the command bit is 0 is irrelevant.
3. Vacuum and pressure control:

1. Two pumps, vacuum and pressure, will be controlled. Each requires a single on/off logic signal. Two control modes will be supported, full off and servoed.
2. Three solenoid valves will be controlled. Each requires two control signals, on/off and high/low power, which control drivers located on the VPM board. Three control modes will be supported, full off, servoed, and full on. Power-down will only be provided on transition to full on. In servoed mode, power will remain high. If the mode changes to full on from full off or servoed, high power will be enabled for 1/2 second and then disabled.
3. Each of the five controlled sections will comprise an identical sensor (pressure transducer) and conditioning circuitry. Each conditioned analog signal will be input to one channel of a multiplexed 8-channel 10-bit ADC (TLV1548).
4. The VPM control means (FPGA or CPU) will periodically read the five pressure levels and determine whether to activate pumps and valves according to the following formula:

1. If the mode bit(s) tell that the device is off then assign 0 to its ON bit (this is the only control bit if the device is one of the two pumps).
2. If the mode bits of a solenoid tell that it is always on then assign 1 to its ON bit and assign 1 to the device's HI (power) bit. If this is a mode change then begin a 1/2-second timing process (for this one device) for power reduction. At the end of this period, assign 0 to the power bit.
3. If the mode bit(s) tell that the device is servoed then:

1. If feedback is lower than the low threshold (captured from the scan chain into one of two registers for each device) then:

1. If the device is a pump, assign 0 to its control bit.
2. If the device is a solenoid, assign 1 to both its ON and HI bits.

2. If feedback is higher than the high threshold then assign 0 to its control bit (pump) or ON bit (solenoid).

4. Status reporting and vacuum and pressure leak detection:

1. The status of each vacuum/pressure device will be reported on a pair of bits in the output (MISO) register. These are encoded as follows:

1. 00: the sensor output is lower than the low threshold.
2. 01: the sensor output is between the low and high thresholds.
3. 10: the sensor output is above the high threshold.
4. 11: not used.

2. The ability of each of the five vacuum/pressure channels to recovery will be reported on one bit in the output (MISO) register: 0 indicates acceptable recovery time and 1 indicates failure. The controller sets and clears each bit according to the following process:

1. When a device is turned ON (change from OFF, not ON to ON) a timer is started (for that device -- each device is independently timed).
2. The timer may operate at any convenient frequency but it must provide at least 100 msec. resolution and 10 seconds maximum timeout controlled by a value set from the APU scan chain. The counter may be initialized to this value and counted down to 0 or it may be initialized to 0 and counted up to the value. The APU command to set this count will contain a value adjusted to the specific timer period provided by the hardware. An independent recovery timeout is provided for each of the five devices.
3. When feedback indicates that the device has reach the high threshold, the recovery timer is stopped.
4. If the recovery timeout is reached, the channel has failed to reach the high threshold in the expected time. In this case, the device's recovery status bit is set to 1.
5. The status recovery bits are cleared by Master command. The VPM controller does not independently clear them. The clear command value comprises five bits which are AND'd with the flags, allowing the Master to clear any individual or set.

5. Vacuum accumulator wet detection:

1. Two vacuum accumulator wet detectors will be provided. Each comprises either a strobed or oscillator-driven capacitively-coupled input sensor circuit. In either case, the sensor presents an AC short to ground through the coupling capacitor when wet, which increases the time required to charge a storage capacitor. The output of each of these circuits attaches to one of the three ADC channels not used for VP control.
2. The controller will periodically read each sensor circuit's voltage and compare the value to a level set by APU command via the scan chain. If the sensor voltage is lower than the control level, the corresponding (one of two) flags is set in the output register (MISO), indicating that the sensor is wet. Otherwise, the flag is cleared.

6. Scan chain integrity test. One Master command will be interpreted to echo the command back to the Master. When it receives this, the controller will copy as much of the command as possible (right-justified, i.e. truncate from MSB if necessary) to the output register, leaving one bit for handshake. The controller will not change this output until it receives the next Master command, at which time it will revert to normal output.
7. Mechanical:

1. The board will measure no more than 8 inches wide by 6 inches high.
2. The five pressure transducers will be located at least 1.2 inches apart along the top edge of the board.
3. One standard 10-pin scan chain connector will be located on the right edge (component side view) of the board near the bottom.
4. SCK, NPCS, and Reset will have hard-wired termination resistors.
5. The power connector will be located on the bottom edge of the board near the right (component side view).
6. Solenoid, pump, and wet sensor connectors will be located along the left edge (component side view) and, optionally, along the top edge in space not needed for transducers.

IMPLEMENTATION REQUIREMENTS

1. Master (APU) control bits:

1. 1-bit next command flag. The master toggles this to indicate that it has written a new command to the controller's input register (on the APU scan chain).
2. 5-bit command ID.
3. 10-bit command value.

2. Master commands:

1. For each of five servo channels:

1. Write 10-bit low threshold.
2. Write 10-bit high threshold.
3. Write maximum recovery time counter (probably 10-bit).
4. Write control mode (one bit if pump, two if solenoid):

1. 0 = pump off.
2. 1 = pump servoed. There is no pump always on mode.
3. 00 = solenoid off.
4. 01 = servoed.
5. 10 = solenoid on.

2. Clear recovery time error flags.
3. Echo command. This is used both as a scan chain test and to enable other commands. After reset, the controller will accept only this command. After receiving it, the controller will accept all commands.
4. The 5-bit command word is encoded as follows:

1. 0 = no command.
2. 1, 2, 3, 4, 5 = write servo 1, 2, 3, 4, or 5 low threshold.
3. 6, 7, 8, 9, 10 = write servo 1, 2, 3, 4, or 5 high threshold.
4. 11, 12, 13, 14, 15 = write servo 1, 2, 3, 4, or 5 max recovery count.
5. 16, 17, 18, 19, 20 = write servo 1, 2, 3, 4, or 5 control mode.
6. 21 = clear recovery time error flags.
7. 22 = pressure vent on/off.
8. 23 = vacuum vent on/off.
9. 24 = echo.

3. Replies and status reports to Master:

1. Command received flag. Toggle this after processing a command to tell the master that the next command may be sent.
2. Vacuum accumulator wet. Two bits. 0 = not wet, 1 = wet. These flags are not sticky.
3. For each of the five servo channels.

1. 1-bit recovery time error. 0 = no error. 1 = timeout. This flag is sticky; only the Master can reset it.
2. 2-bit status:

1. 00: the sensor output is lower than the low threshold.
2. 01: the sensor output is between the low and high thresholds.
3. 10: the sensor output is above the high threshold.
4. 11: not used.

4. Scan chain (internal to controller):

1. Scan chain input (MOSI from APU). One bit is dedicated to handshake. There are 24 commands, which can be encoded in five bits. All of the threshold values comprise 10 bits. If 10 bits are sufficient for the recovery timeout value, then the input register must contain at least 16 bits. Bit 15 will be the handshake, 14-10 the command ID, and 9-0 the command value.
2. Scan chain output (MISO to APU). The output register bits can serve specific purposes except during the echo command reply. 18 bits are needed, but this odd number could complicate scan chain access in the APU. Therefore, 24 bits will be dedicated to the output register. Bit 23 will be the handshake. The controller will toggle it every time that any of the other bits are written. The shift register is loaded from an output image that may be either a unified register bank or distributed flags.
3. The controller will read and write to the serial shift registers only during the NPCS high period.

5. Controller I/O:

1. The scan chain interface requires four inputs, MOSI, SCK, NPCS, and Reset and one output, MISO.
2. Four output bits control the two vent solenoid driver circuits, each of which is a standard hi/lo driver.
3. Three pairs of vacuum/pressure solenoid control bits are output. Each pair attaches to a standard hi/lo solenoid driver circuit.
4. Two bits are output to jacks for (logic level) pump control. It may be desirable to buffer these, because they go off board.
5. A bidirectional synchronous serial interface controls the ADC. This requires three outputs, data in (to ADC), clock, and frame start, and one input, data out (from ADC).
6. The controller requires a power-on reset input. At reset, all scan chain shift registers and all outputs are cleared.
7. Total output bit count is 16. Total input bit count is 3.

STRUCTURE AND BEHAVIOR

While NPCS is low, the scan chain shifts and no other activity related to the raw shift registers takes place. When NPCS goes high, there is a four usec. period during which the input command (MOSI) is interpreted, possibly immediately changing the output image, which is subsequently copied to the output shift register (MISO). When NPCS goes low, the new output and the previous input begin serially shifting again. The output image register is needed for other processes to post status during the shift period. The input doesn't have one image. The command is fully interpreted during NPCS high and any value contained in the command is copied directly to the site where it is used.

1. After NPCS goes high, compare scan chain (MOSI) bit 15 to its previous value. If there is no change then do nothing; else if the all commands accepted flag is clear then do nothing; else interpret the command as follows:

1. Toggle the previous handshake value (for next new command detect).
2. If the command is Write Low Threshold, Write High Threshold, or Write Max Recovery Count (one of 15 commands) then copy the 10-bit command value to the selected servo channel (0 through 4) register.
3. If the command is Write Servo Control Mode (one of five commands) then copy command value bits 0 and 1 to the selected servo channel register. The two pumps require only one mode bit vs. the two required for solenoids, but it may be easier to process all five commands identically, copying a dummy bit 1 in the case of pumps.
4. If the command is Clear Recovery Timeout Flags then AND command value bits 0-4 with the recovery error flags in the output image.
5. If the command is Set Vent State (one of two commands) then for the selected vent (1 or 2) do:

1. If command value bit 0 is 0 then apply this to the on/off output.
2. If command value bit 0 is 1 then apply 1 to the on/off output and 1 to the power control bit. Start a 1/2-second timer for this device. At the timeout, change the power control bit to 0. The two vent solenoids are independent. Each needs a dedicated powerdown timing mechanism.

2. If the command is echo then set the "all commands accepted" flag and copy the entire 15-bit command ID and value from the input to the output shift register. Otherwise, copy all 17 output image bits to the output shift register bits 0-16. Toggle bit 23. Bits 17-22 are don't care. Note that these things are done on every cycle regardless of the command handshake and the image copy must be done after the command interpretation in order to show the new recovery error flags when the command clears the flags or to substitute the reflected command when it is echo.

The ADC interpreter continuously reads the ADC, cycling through seven of the eight channels. The ADC is shared by servo control and the unrelated wet sensor detector, suggesting that it might simplify the architecture to separate the continuous ADC reading from any interpreters. This would be done by having an ADC controller continuously read and post the seven 10-bit values for independent asynchronous processes to interpret. This uses more storage memory but possibly simpler state machines.

For each of the five servo channels do the following:

1. Record the channel pressure/vacuum state in the output image as follows:

1. 00: the sensor output is lower than the low threshold.
2. 01: the sensor output is between the low and high thresholds.
3. 10: the sensor output is above the high threshold.

2. If the mode bit(s) tell that the device is off then:

1. If the device is a pump, assign 0 to its control bit.
2. If the device is a solenoid, assign 0 to its ON bit.

3. If the mode bits of a solenoid tell that it is always on then assign 1 to its ON bit. If this is a change then assign 1 to the device's HI (power) bit and begin a 1/2-second timing process (for this one device) for power reduction.
4. If the mode bit(s) tell that the device is servoed then:

1. If feedback is lower than the low threshold then:

1. If the device is a pump, assign 0 to its control bit.
2. If the device is a solenoid, assign 1 to both its ON and HI bits.

2. If feedback is higher than the high threshold then assign 0 to its control bit (pump) or ON bit (solenoid).

5. For both pump and solenoid, if the state changes from OFF to ON then begin a timing (counting) process based on the max recovery count (count from this value down to 0 or from 0 up to the value).

The vacuum accumulator wet detection process can be based on a continuously driven or strobed sensor. Sensor circuits for the two approaches are very similar. The difference is mainly the use of a diode in the continuously driven circuit. The diode allows charge to accumulate continuously on the storage capacitor even while the sensor branch repeatedly charges and discharges. Except for the diode, the two approaches use the same number of components.

The continuously driven circuit can be excited at any convenient frequency and can be read at any time. The strobed circuit requires some coordination between the strobe assertion time and the subsequent ADC reading; and the strobe must also be deasserted to restore the sensor branch to a baseline state. For both circuits, the sensor is wet if the voltage on the storage capacitor falls below (or doesn't reach, in the strobed circuit) some circuit-dependent value. This value is relatively easy to predict for a continuously driven circuit, such as the one on the CD32/3500 VPM. The 5V. oscillator output charges the storage capacitor through 33K and a diode with a 1M bleeder to ground. If the oscillator's output were a square wave and the sensor were dry, the sense voltage would be 4.2 V. The reference circuit's oscillator does not produce a square wave. Excitation provided by an FPGA would be square but probably not as high as 5V. It is probably reasonable to use a fixed threshold for comparison, but the threshold could be set by command.

For each of the two wet sensor detectors, if the voltage is below the threshold, set the corresponding wet sensor flag in the output image; otherwise clear the flag.

There are two types of timed events, solenoid power down and vacuum/pressure recovery time. Although three of the solenoids are related to the recovery time at the application level and unrelated to the other two solenoids, it will be more convenient to ignore these relationships and treat all five solenoid power-downs as a single group unrelated to the recovery timers.

For implementation in a CPU, the ten timed processes (five solenoids and five VP recovery timers) would be implemented as posted times to compare to a global counter/timer. For implementation in an FPGA, it is more efficient to use one counter for each process. Ten counters are required. All counters are started and restarted by processes other than the timer. Therefore, timer processes only need to respond to actual timeouts.

Since each timer is dedicated to a particular device, the responding process does not need to be instructed on how to respond by the initiator of the timer. For each of the five solenoids, if the timer has reached the end time, assign 0 to the solenoid's power bit. It is not necessary to reset the timer. This can be a simple combinatorial-- e.g. if timer = 0 then output bit <= 0. For each of the five VP recovery timers, if the timer has reached the end time, assign 1 to the solenoid's power bit. It is also necessary to disable the recovery error timer process in order to allow the Master to clear the recovery error flag. When a recovery timer is disabled, the error flag will not be set, regardless of the timer value. Thus, the VP recovery timer process is as follows:

1. If the timer = 0 (assuming down-counting) and the process (for this one of five) is enabled then:

1. Disable this process.
2. Set the corresponding VP recovery time error flag in the output image.

SYSTEM DESIGN REPORT 7

11/9/99

[Report6]

[Report8]

1. Scan Chain Interrupt.
2. APU, RPM, Status Panel, and CD4000.

1. CD4000 Requirements.

1. Solenoid Controls.
2. Sensors.
3. Peristaltic Pump Motor Controller.

2. APU Connectors.
3. Scan Chain Register Bypass.

3. [Right Panel Module].

1. In-Line Fluid Sensors.
2. Shear Valve and Y-valve Controller.
3. Connectors.
4. Recap.

4. Left Panel Module.

1. Strobed Fluid Sensors.
2. Miscellaneous Changes.

SCAN CHAIN INTERRUPT

For simple I/O, software can generally treat a scan chain much like a random access parallel bus. However, for sequential encoded communication, as between the APU and VPM, software needs to know when something that it has written to scan chain registers has actually been received before it can write the next value. While it is possible to use time to control writing, this complicates software and reduces performance. A better solution is for scan chain controllers to indicate when they have completed a scan. This can be done by interrupting the CPU.

Both the APU and MSM CPUs appear to have external IRQ levels 5 and 6 free. IRQ level 7 could be used even though the level is non-maskable, because the program will use port configuration to disable individual interrupt sources instead of disabling the level. However, it may be better to reserve IRQ7 for a future use where its non-maskable level is needed.

The most reliable means of asserting the IRQ is to hold it active until the CPU accesses a particular address or writes to a particular bit in the scan chain controller, which it will do only in the ISR. Normally, the CPU will disable this interrupt, enabling it only for sequential writing to a single location. Therefore, the IRQ will usually be asserted. The interrupt request can't be cleared on a routine operation, such as writing to any scan chain address, because software may continue to access random locations even while simultaneously executing a series of sequential writes.

The FPGA's job is simple: assert (low) the interrupt when NPCS goes high; disassert it when the CPU accesses the clear mechanism (R/W specific address or write specific bit). This is required only for I/O scan chains, not for motor scan chains.

APU, RPM, STATUS PANEL, AND CD4000

The interim design attempts to meet the hardware control needs of a CD3200-class instrument with some spare capability for experimenting. Recently, John V, J. P. Y, and I have been reviewing the hardware control requirements of the CD4000 to try to anticipate its needs as well. As John has explained, the goal is to make an initial instrument that supports a wide variety of configurations, even though this will incur some cost penalty, and to remove portions to reduce the cost for any specific price-performance point. The major cost item is, of course, the laser. The next most costly items are hardware units, such as syringes and motors, followed by the number of channels on the APU, and finally by I/O control circuits. Given the relatively low cost impact of I/O control circuits, it is reasonable to provide extra capability where it we think it may prove useful. However, as much as possible, we want to modularize sub-circuits to facilitate depopulation, not only to reduce cost, but to avoid wasting scan chain resources that may be needed elsewhere.

The CD4000's basic control requirements are:

1. 17 steppers, comprising:

1. Three peristaltic pumps located at the top of the right (front) panel. These operate at constant, but selectable, rates.
2. One FMI pump, located near the middle of the left edge of the left (front) panel, approximately where the one CD3200 peristaltic pump is located. We have not yet discovered its operating characteristics.
3. Seven syringe drivers, located at the bottom left (front) panel.
4. Two y-axis (front-back) sample processor module (similar to the CD3200 tower) drivers, located at the middle bottom of the back panel.
5. One z-axis (up-down) sample processor module driver, located in the middle of the instrument and moved from back to front by one of the y-axis motors.
6. Three loader motors, tube spinner, mixer, and x-axis.

2. One DC motor, the "hop-hop" located in the middle of the bottom panel.
3. 97 solenoids, comprising:

1. 10 located along the left edge of the left panel.
2. 69 located throughout the left panel.
3. 15 located in the loader.
4. 3 located in the sample processor module.

4. 41 sensors, comprising:

1. 4 fluid sensors.
2. 1 Hop-hop motor sensor.
3. 1 door sensor.
4. 7 home sensors, one for each syringe.
5. 6 sensors on the sample processor module, 3 of which are motor home flags.
6. 8 sensors located in the loader.
7. 14 located throughout the instrument.

SOLENOID CONTROLS

The interim RPM contains 24 solenoid drivers, the LPM 32. The CD3200 has 15 solenoids on the right panel and 25 on the left. The CD4000 has 82 non-loader solenoids with all but three located on the left panel. To support the CD4000, 26 solenoid controls need to be added. As many of these as possible should be added to the LPM. The LPM is somewhat space constrained and may not be able to absorb all of these. Any remaining ones can be added to the RPM.

The solenoid driver circuits on both the interim RPM and LPM schematics contain an error that needs to be corrected. Some of the ULN2003 drivers mismatch inputs to outputs where one section is not used. Pin 4 input controls pin 13 output and pin 5 controls pin 12. In some cases pins 4 and 12 are connected instead of 4 and 13 or 5 and 12. In other cases, the mismatch is that pins 5 and 13 are connected.

SENSORS

The CD4000 has 33 non-loader sensors. Four of these are fluid sensors, which are treated separately. Ten are motor home flags, which are part of the motor control bus. There are 19 general-purpose sensors located throughout the body of the instrument. These can be provided by adding two HC597s to the RPM and one to the LPM. One half of one of these registers on the RPM will be used for the in-line fluid sensors (see discussion of RPM below). Each of the remaining 12 RPM and 8 LPM inputs should be connected to a 3-pin input device jack with the following pinout:

1. Pin 1 is +5V.
2. Pin 2 is input, pulled high by 10K to 5V.
3. Pin 3 is digital ground.

PERISTALTIC PUMP MOTOR CONTROLLER

The MSM's 14 motor limit is hard-wired into its timing and control mechanisms and cannot be increased. John and I considered the possibility of including on the RPM a fixed-rate controller for the three right panel peristaltic pumps, but J. P. pointed out that these pumps control flow cell fluid rates, which must be selectable from scripts. Even with selectable rates, these pumps demand less control than other steppers. J. P. says that the CD4000 may use ramps for these pumps, but this is not necessary. The pumps have no absolute position to maintain, so any position slip has no long term effect and doesn't change the slew rate. The worst possible effect of ramp-less driving is startup cogging, where a step fails to achieve more than 50% travel and the next step actually goes backward. However, a peristaltic pump presents a nearly constant load with little momentum, so any slew rate that allows cogging at startup risks cogging at other times as well and shouldn't be used. Therefore, a ramp-less controller should suffice for these motors.

The RPM is ideally located for accessing the delivery pump motors. However, the only communication means from either of our centers of intelligence (APU and MSM) to the RPM is the APU I/O scan chain, which is not designed for intelligent conversation. Never-the-less, we are putting a programmable VPM on the scan chain by encoding some scan chain (MOSI) bits to assign multiple uses to bits, and this could be done for a simple motor controller as well. The main problem would be scan chain address consumption. This couldn't be done with fewer than 16 bits (3 for on/off, 2 for register selection, and 11 for speed. To determine whether this approach could be supported, we need to consider how the scan chain would be used in a CD4000 box. The MOSI bit requirements are:

1. Status Panel: 24. It should be pointed out that much of this consumption is unnecessary. Four bits are unused. Eight are used for speaker frequency control, which is cute but certainly not required. Eight are used for speaker volume, when four or five would afford sufficient resolution. Thus, only 8 bits are really needed.
2. VPM: 16 bits (MOSI). See k:\cdx\doc\analyzer\vpm.doc or cdxsys.doc.
3. RPM: 8 bits for y-valves (see discussion of shear and y-valve control below). 1 bit for hop-hop on/off.
4. 164 bits for solenoids. Two bits (on/off and power) for each of 82 solenoids (97 - 15 on loader controlled on the MSM I/O scan chain). These may all be located on the LPM or distributed between RPM and LPM.

The total MOSI bit consumption is 212, leaving 44 available. Clearly, this leaves enough to implement the dumb stepper controller on the RPM. However, even a ramp-less controller would require a fairly substantial PLD. Assuming a 16-bit step counter and reload register for each of three motors, plus a 2-bit gray-code counter to generate step patterns, plus 24 bits for scan chain registers, 126 bits are needed. The smallest PLD that could be used would be an EPM7128.

An alternative approach would be a motor coprocessor that communicates with the APU's CPU through the PC104 interface. The coprocessor board would include on-board motor drivers plus power and motor cabling. This would be too big to implement as a mezzanine board. There is room on the APU's mounting plate for such a board, but the APU's PC104 connector must be properly positioned to minimize cable length (see next topic).

Considering the current uncertainty regarding fluid delivery precision and reliability when using a peristaltic pump, John and I have decided not to implement any means of driving the pumps at this time. The two alternatives will be reconsidered in the future. For now, the most important action is to be sure that the APU configuration will support a non-mezzanine PC104 coprocessor.

The current APU configuration doesn't allow the PC104 to serve as an effective coprocessor interface. The connector is located at the top of the board and the board is mounted at the top of the panel. PC104 is intended for stacking and is not properly terminated for any but the shortest bus lengths. Therefore, only a mezzanine board could be used now. But the most likely coprocessor function would be to extend I/O capabilities, which requires additional cabling and usually a fairly large board, for which a mezzanine is not suitable. Either the APU should move down on the mounting plate or its PC104 connector should be moved to the bottom edge of the board.

No matter what is done to the Status Panel or RPM, the cabling requirements of the Status Panel will not change. In contrast, there may be instrument configurations in which the RPM is completely removed, with the APU's I/O scan chain going directly to the LPM. Therefore, putting the downstream loopback connector to the Status Board on the APU would afford greater flexibility than putting it on the RPM.

If there is room on the left edge (circuit side) of the APU then the Status Panel loopback connector should be located here. The standard 10-pin scan chain connector to the RPM should be located at the bottom of the left edge; the 14-pin loopback connector can be located anywhere above this. Only one set of drivers and receivers should be located on the APU. These should be located upstream from the Status Panel connector. The return signals from the Status Panel are routed (on the APU) directly to the RPM connector without additional buffering. See AD46- Hardware Partitioning- Cabling or cdxsys.doc for scan chain cable definitions.

It is likely that some units on the APU I/O scan chain will, in some instrument configurations, not be used, possibly consuming chain addresses that are needed elsewhere. To simplify configuration, jumpers will be provided to connect units into or remove them from the scan chain. Only serial data needs to be bypassed, as all other signals are distributed in parallel. Thus, the common terminal of a 3-pin jack is the data input to the next unit downstream on the MOSI leg or upstream on the MISO leg. The two option terminals connect to the data input to the (de)selected unit and to the data output from the unit.

What constitutes a "unit" depends on function. Most units are 8-bit registers, such as the '595 and '597. Thus, each solenoid scan chain unit comprises a bank of four solenoids (4 bits on/off and 4 bits power). The VPM and Status Board both contain larger scan chain units, but all components of both of these modules are currently required. Therefore, neither of these modules will have any bypass jumpers.

RIGHT PANEL MODULE (RPM)

AD46: Hardware Partitioning: Fluid In-Line Sensors suggests that the CD3200's two in-line sensors, one optical and the other ultrasonic, be moved to the RPM. The ultrasonic sensor is circuit is an OEM module, and it was suggested that this be piggybacked onto the RPM. Further review of the target analyzer indicates that we are not clear about certain I/O requirements, including the in-line sensors. Given that the ultrasonic sensor is already a self-contained circuit that needs only power and a single scan chain input, it makes more sense to just provide a jack for it. The RPM should contain two of these, in case we decide to use ultrasonic for both sensors. This is the same as the CD3200's FCM (9631320) J11, a 3-pin jack with the following pin assignments:

1. Pin 1 is +5V.
2. Pin 2 is a scan chain input (MISO) with a 10K pullup to +5V.
3. Pin 3 is digital ground.

As mentioned in AD46, the optical sensor circuit is our own module 9631160 (drawing number). This is a very simple circuit, and it may still make sense to include this on the RPM. Two of these should be included, as we may decide to use optical for both sensors. Given the surplus of MISO bits and the uncertainty around the RPM I/O requirements, it would be best to make the optical and ultrasonic inputs independent. Thus, the RPM will simultaneously support two ultrasonic and two optical in-line sensors. These four MISO inputs can be attached to one nibble of the two HC597s provided on the RPM for general-purpose input (see Sensors topic above).

The original circuit contains a jumper-selectable option that we will not use and the alternate components can be deleted. This frees U1C, which, along with the spare U1D, can form the second circuit. Thus, only one LM339 is needed for two sensor circuits. The jumper, W1, is not needed for the old selection purpose but will be retained for another purpose. Although having the sensor circuit on the RPM is more efficient and affords a better mechanical arrangement than the separate PCB, we may find that the longer opto-interrupter leads pick up too much noise. Also, the manufacturing and service advantage of a common part may outweigh the advantages. Therefore, it would be good to provide the old interface as an option. W1 will provide the means to connect the MISO input to either the new signal (TP2, W1B-C) or to a 3-pin jack that is compatible with the old interface. The pinout of this jack is:

1. Pin 1 is +5V.
2. Pin 2 is signal output from the sensor circuit.
3. Pin 3 is digital ground.

In the old circuit, the opto-interrupter leads are soldered to the PCB. This will be replaced by a 4-pin jack. The PCB space provided for DS2 and Q1 is eliminated. The old circuit's output jack J1 is eliminated. The output (W1-C) is jumper-selected to the MISO input. To use the circuit on the RPM, the four opto-interrupter leads are connected to the 4-pin jack. The old adjustable sensor circuit (9631160) is used by connecting its J1 to the 3-pin jack on the RPM.

INTERIM DESIGN CHANGES

The interim RPM version includes a shear valve and Y-valve motor controller/driver interface. An Altera EPM7032 provides the logic for both motors and an L298 dual H bridge provides the drive. The circuitry is mostly correct but the logic in the 7032 is incorrect and will not work. Also, to support additional configuration options, we have decided to modify the requirements as follows:

1. Provide control for two shear valves and two Y-valves.
2. Provide an alternate interface to the existing shear valve assembly, which includes its own driver/controller circuit (Shear Valve Motor Controller - 0900, drawing number 74463).
3. Provide a simple means of configuring the scan chain for alternate uses.

These requirements can be met using the L298 for the two shear valves and an L293D for the two Y-valves. The L293D is similar to the L298 but delivers lower power in a smaller IC and with integral suppression diodes. An L293 may be substituted for the L293D but would require eight external suppression diodes. The EPM7032 can support the increased requirements after correcting some of the interim design's inefficiencies.

MOTOR ASSEMBLIES

The shear valve and y-valve are similar in that they both comprise a bidirectional DC motor with some form of CW and CCW End Of Travel indication. However, the shear valve cannot rotate continuously, while the y-valve can, and their position indicator mechanisms are quite different.

The shear valve position is indicated by three sensors, EOT (End Of Travel), CWL (CW overtorque), and CCWL (Counter Clockwise Overtorque). Shear valve movement is mechanically blocked at both CW and CCW extremes. The motor pulls the valve via a spring, which allows the motor to continue moving even after the valve stops. When the motor pulls a certain amount ahead of the valve, the appropriate overtorque signal becomes true. If this occurs during travel (i.e. when EOT is false) it is ignored. If it occurs when EOT is true, the motor is turned off (failure to do this is one of the errors in the interim design).

The shear valve sensor board circuit is arranged to produce the following outputs:

1. EOT is high (1) when the valve is at either CW or CCW end position.
2. CWL is low (0) when the motor has pulled ahead of the valve by a certain distance in the CW direction.
3. CCWL is low (0) when the motor has pulled ahead of the valve in the CCW direction.

EOT, CWL, and CCWL are all inverted on the RPM so that they are logically /EOT, CWL, and CCWL when input to the motor control PLD.

The shear valve motor drive is arranged so that normal polarity (positive current flow into the + terminal) drives the valve in the CW direction. Also, the Abbott standard cabling convention is followed, with the motor's + terminal attached to pin 1 of a 2-pin jack. Jack pin 1 is, by convention, the left-most viewed from above with the latching tongue facing down:

The y-valve assembly contains two position feedback sensors. These are simple opto-interrupters. A 1-K pullup to +5 is required on the RPM, but the inverters in the interim design serve no purpose and should be eliminated. The y-valve motor has a single-slot wheel that allows a phototransistor to pull the signal low when the slot is in the interruptor. Thus, CW and CCW are indicated by their respective signals low. Logically, they are /CW and /CCW. As with the shear valve, the y-valve controller must stop when the target position is reached. The interim design (equations for the 7032) fails to do this.

The y-valve assembly follows the same motor connection conventions as the shear valve. Motor + is connected to pin 1 of a 2-pin jack. Normal polarity drives the motor CW. The CW and CCW sensors are 90 degrees apart. Either one could be considered the CW or CCW but one way would require 270 degrees full travel and the other only 90 degrees. Obviously, we've chosen the latter. The position called sense 1 in the original DC Motor Driver (drawing 9631940) is CW, while sense 2 is CCW. These are called Y_CWL and Y_CCWL in the interim schematic.

DRIVERS

The L298 is a dual 2 Amp H bridge while the L293D is a dual 0.6 Amp H bridge. In both ICs, each bridge is controlled by three inputs, a general enable/disable and two half-bridge polarity selectors. A motor can be turned off either by the general disable or by assigning the same value (1 or 0) to both polarity selectors. These methods are not electrically identical but the differences are evident only when dynamic braking and/or PWM are used. We don't use either. Therefore, we only need to control the two half-bridges for each motor.

INTERIM DESIGN ERRORS

The interim design contains the following errors that will be corrected:

1. The shear valve position sense inputs are inverted, as in the original Shear Valve Motor Controller, but the original purpose is missed. In that circuit, the inputs are connected to 0.1uF capacitors, forming simple RC filters with the sensor board pullups. The HC14 inverters are used for their Schmitt trigger inputs to square up the slow signal, not for their inversion, which is an irrelevant side effect. The interim circuit should be replaced by the original, which terminates EOT, CWL, and CCWL with 100K and 0.1uF in parallel to digital ground.
2. The y-valve position sense inputs are inverted for no reason. The 1K pullups on the RPM and the pulldown transistors in the opto-interrupters are of sufficiently low impedance that the filtering used for the shear valve sense signals is not needed. Therefore, the y-valve position sense inverters should be eliminated.
3. The two full-bridge enables on the L298 are connected to the 7032, which drives them from the scan chain reset signal. This wastes a PLD pin. A motor can be turned off by assigning both of its half-bridges the same value. Therefore, the bridge enables will be tied to +5V. This applies to the L293D as well as to the L298.
4. The motor under-current detectors are used improperly and are not necessary anyway. The motor control equations (in MTRCNTLR.TDF) turn off the drive for under as well as over-current. The motors will never start, because the under-current will always be true until the drive is turned on. This error points out that under-current is a fundamentally different problem from over-current. Over-current occurs frequently while starting up a motor and does not represent a problem unless it persists. Under-current always represents a problem-- that the motor is disconnected or damaged. However, we don't even really need under-current to tell us this. If the motor doesn't reach its target position in a time period determined by software, the (analyzer system) program will report an error. It makes little difference whether this error is reported in 100 msec. or 2 seconds. In any case, correcting the problem requires human intervention. Therefore, the under-current detector circuits should be eliminated. Note that the interim schematic incorrectly swaps the "OVR" and "UDR" labels. For example, U13 pin 1 is labeled Y_UDR although it actually is the over-current detector.
5. The motor control equations ignore motor position sense signals, which are just output to the MISO shift register. Presumably, the intent is to require software to stop the motors in their home positions. This is impossible for the y-valve, which can rotate past its home positions, and dangerous for the shear valve, potentially leaving it in a powered stall. To avoid overheating the shear valve motor, we would have to reduce the over-current threshold, which would increase motor startup power cycling and decrease performance.
6. The shear valve position equations are wrong. SV_CCWP is assigned the value of SV_CCWL. This is both incorrect and wasteful. SV_CCWL is a simple input and SV_CCWP a simple output. The 7032 doesn't use either for anything. Routing this through the 7032 makes no sense. Anyway, the equation is wrong, because the input signal must be combined with EOT or else the output signal would indicate CCW home during every motor startup in the CCW direction. SV_CWP does combine SV_CWL input with EOT, but this too is wrong. For one thing, the home state indicator must be latched, because when the motor is turned off, the torque spring can pull back the overtorque detector, making SV_CWL false and incorrectly indicating that the device is not at the CW home position. Further, the interim design's equation will fail when the shear valve is in the CCW home position and starts in the CW direction. The SV_CWL signal will indicate CW overtorque before the shear valve leaves the EOT position. The SV_CWL will then indicate that the shear valve is in the CW home position when it is actually in the CCW home position. The correct equations are listed later in this document.
7. As with the SV_CCWL, routing Y_CWL and Y_CCWL through the PLD (7032) is pointless in the interim design. However, the new design will embed the MISO shift register in the PLD and use all of the position inputs internally as well, so, on two accounts, these signals still need to be connected to the PLD.

NEW CIRCUIT

The shear valves will be called SV0 and SV1, the y-valves YV0 and YV1. For consistency, the + of each motor will be connected to lower numbered half bridge, i.e:

1. SV0 + connects to L298 Out 1 pin 2.
2. SV0 - connects to L298 Out 2 pin 3.
3. SV1 + connects to L298 Out 3 pin 13.
4. SV1 - connects to L298 Out 4 pin 14.
5. YV0 + connects to L293D Out 1 pin 3.
6. YV0 - connects to L293D Out 2 pin 6.
7. YV1 + connects to L293D Out 3 pin 11.
8. YV1 - connects to L293D Out 4 pin 14.

The other driver pins are as follows:

9. L298 enable A pin 6 and enable B pin 11 connect to +5V.
10. L293D enable A pin 1 and enable B pin 9 connect to +5V.
11. L298 In 1 pin 5 is SV0_CW.
12. L298 In 2 pin 7 is SV0_CCW.
13. L298 In 3 pin 10 is SV1_CW.
14. L298 In 4 pin 12 is SV1_CCW.
15. L293D In 1 pin 2 is SV0_CW.
16. L293D In 2 pin 7 is SV0_CCW.
17. L293D In 3 pin 10 is SV1_CW.
18. L293D In 4 pin 15 is SV1_CCW.

When Sxx_CW is high and SxxCCW is low, the motor rotates CW. When Sxx_CW is low and SxxCCW is high, the motor rotates CCW. Both high or both low can be used for motor off. For consistency, only both low will be used. These eight pins are all connected to the motor control PLD and to an 8-pin SIP header. The header pins simplify rewiring for alternate scan chain use when a particular motor interface is deselected, in which case the corresponding two PLD outputs directly reflect MOSI bits; the MOSI direction control bit, which is called xCW (1 selects CW, 0 CCW) will be output as xCW and the on/off bit will be output as xCCW.

Each shear valve controller PLD section will have four inputs:

1. SVx_OC = overcurrent. High is true.
2. SVx_CWL = inverted CW overtorque. High is true.
3. SVx_CCWL = inverted CCWL overtorque. High is true.
4. SVx_EOT = inverted EOT sensor. Low is true.

Each y-valve controller PLD section will have three inputs:

1. SYx_OC = overcurrent. High is true.
2. SYx_CWH = CW home. Low is true.
3. SYx_CCWH = CCW home. Low is true.

The four SVx_CWL and SVx_CCWL sensor inputs (i.e. before inversion to avoid having to disable the inverters) are connected to an 8-pin SIP pin header, the other four pins of which connected to the four SYx_CWH and SYx_CCWH signals. This provides a convenient means of connecting alternate inputs when a motor controller is disabled, in which case, the corresponding two inputs are gated directly to the MISO register. Note that disabling one motor controller frees two scan chain outputs and two inputs.

To interface to an old shear valve with integral controller, the motor controller section is disabled. Direct scan chain outputs provide the two control signals, ON and CW/CCW; the two position state inputs, CWACK and CCWACK, are routed directly to the MISO scan chain. To simplify attaching the shear valve, the RPM will include two 7-pin SIP headers, one for each of the two shear valve interfaces. These headers afford only a mechanical convenience, bringing two alternate outputs and two inputs (from the same motor controller section) to a single connector that is compatible with the old Shear Valve Controller's J2 (which is also FCM J8). The pinout is:

1. Pin 1: +5V.
2. Pin 2: key.
3. Pin 3: digital ground.
4. Pin 4: motor ON (MOSI output).
5. Pin 5: motor CW/CCW (MOSI output).
6. Pin 6: CWACK feedback (MISO input).
7. Pin 7: CCWACK feedback (MISO input).

If a shear valve controller is disabled, whether the inputs are used for CWACK/CCWACK or some other purpose, they will be inverted. The only reason for going through the inverters is to avoid complicating the circuit with some means of multiplexing the alternate inputs with the inverter outputs. Software will not be affected by this inversion, because it will be hidden in the analyzer configuration file.

The interim circuit routes motor position signals through the 7032 to a separate HC597 for MISO input. The new design will capture them on the PLD's own internal 8-bit MISO shift register. The y-valve position sensors will be connected directly to the scan chain. For the shear valves, the internal signals, CWACK and CCWACK, generated from raw inputs (and state memory) will be connected to the MISO scan chain.

In the interim circuit, the 7032 has two scan chain data connections, reflecting the interim design's single leg chain architecture. For the new scan chain topology, the PLD requires four data connections, as follows:

1. MOSI input from the upstream unit.
2. MOSI output to the downstream unit.
3. MISO input from the downstream unit.
4. MISO output to the upstream board unit.

PLD RESOURCE REQUIREMENTS

1. Scan Chain: 5 inputs. 2 outputs.

1. MOSI input.
2. MOSI output.
3. MISO input.
4. MISO output.
5. SCK input.
6. NPCS input.
7. Reset input.

2. Shear Valve 0: 4 inputs, 2 outputs.

1. SV0_OC input. 1 = overcurrent.
2. SV0_EOT input. Inverted EOT. 0 = at full CW or CCW position.
3. SV0_CWL input. Inverted CWL.

1. If motor control enabled then 1 = CW over-torque.
2. else any input or old shear valve CWACK inverted.

4. SV0_CCWL input. Inverted CCWL.

1. If motor control enabled then 1 = CCW over-torque.
2. else any input or old shear valve CCWACK inverted.

5. SV0_CW output.

1. If motor control enabled then if 1 when SV0_CCW is 0 then the motor rotates CW.
2. else direct scan chain output for any use or old shear valve CW/CCW control.

6. SV0_CCW output.

1. If motor control enabled then if 1 when SV0_CW is 0 then the motor rotates CCW.
2. else direct scan chain output for any use or old shear valve ON control.

3. Shear Valve 1: 4 inputs, 2 outputs. Duplicates SV0 with all signals named SV1_xxx.
4. Y-valve 0: 3 inputs, 2 outputs.

1. YV0_OC input. 1 = overcurrent.
2. YV0_CWH input.

1. If motor control enabled then 0 = CW home.
2. else any input.

3. YV0_CCWH input.

1. If motor control enabled then 0 = CCW home.
2. else any input.

4. YV0_CW output.

1. If motor control enabled then if 1 when YV0_CCW is 0 then the motor rotates CW.
2. else direct scan chain output.

5. YV0_CCW output.

1. If motor control enabled then if 1 when YV0_CW is 0 then the motor rotates CCW.
2. else direct scan chain output.

5. Y-valve 1: 3 inputs, 2 outputs. Duplicates YV0 with all signals named YV1_xxx.

The PLD I/O pin totals are 23 inputs and 10 outputs, but the list doesn't include a convenient means of disabling motor control sections. It is possible to reprogram the PLD but it may be more convenient to provide an enable control pin for each one. This would require four more inputs. The EPM7032 has 32 macrocells and is, therefore, limited to 32 general I/O pins. It has four inputs that can be used as general or specific function inputs, but this still brings up the total to 36 vs. the 37 pins that would be needed for full selection capability. Being able to reconfigure via input pins is not necessarily easier than reprogramming the PLD. It isn't worth going to the next larger PLD, which is twice the size and complexity of the 7032, just to get one more configuration pin. Therefore, the YV0 controller will be permanently enabled (except by reprogramming the PLD). The other three motor controllers will have individual enable pins. The three inputs will be:

1. SV0_EN input. 1 = enable controller. 0 = direct scan chain I/O.
2. SV1_EN input. 1 = enable controller. 0 = direct scan chain I/O.
3. YV1_EN input. 1 = enable controller. 0 = direct scan chain I/O.

The scan chain will comprise one 8-bit MOSI input register and one 8-bit MISO output register embedded in the 7032, consuming 16 of the 32 available macrocells. Eight macrocells will be used for the four motor output controls (two per motor). Four macrocells will be used to generate the shear valves' latched CW and CCW states. Eight state flags will be driven onto the scan chain MISO register by NPCS, but none of these will need additional macrocells. Thus, only 28 macrocells will be consumed. The 7032's global clock pin 43 will be used for SCK. The other three special-purpose inputs, OE1 pin 44, GCLR pin 1, and EO2 pin 2, will be used as general-purpose inputs.

PLD PRODUCT TERMS

The controller logic contains two kinds of product terms, external and buried. External terms comprise motor controls and scan chain data (MOSI and MISO outputs). Buried terms comprise the scan chain shift registers and the four latched shear valve home position states, SV0_CWACK, SV0_CCWACK, SV0_CWACK, and SV1_CCWACK. These states and the four raw y-valve position inputs, YV0_CWL, YV0_CCWL, YV1_CWL, and YV1_CCWL, are latched into the 8-bit MISO register when NPCS is high. Latching may be asynchronous or synchronized on the global clock, which is driven by the scan chain's SCK. These eight signals are also used in motor control product terms. The shear valve state terms have the following equations:

The conceptual meaning of these equations is basically that if EOT and the related overtorque are both true then the shear valve has reached the CW or CCW home position. This is latched by allowing the signal to hold itself true. One caveat that applies to both the initial home event and the latched state is that they can't be true if the other home position is true. This prevents the startup EOT coming out of CW toward CCW from latching CCWACK and the EOT from CCW toward CW latching as the CWACK-- remember, EOT is not position-specific. Reset should clear both the MOSI and MISO shift registers if possible.

The 8-bit MOSI shift register outputs are internal motor control signals or simple outputs (for disabled motor controllers). As motor control signals, these are:

1. SV0_ON and SV0_CW.
2. SV1_ON and SV1_CW.
3. SY0_ON and SY0_CW.
4. SY1_ON and SY1_CW.

The remaining shear valve controller equations are:

The y-valve controller equations are:

The eight MISO scan chain registers are loaded during NPCS high. The load data are:

The interim RPM contains two SPI/MPI connectors. These are replaced in the new design by the following:

1. A standard 10-pin scan chain connector located on the right edge (component side view). This will connect to the APU and will be at a vertical position that matches the corresponding connector on the APU. The vertical position will depend on the final resolution of the PC104 coprocessor relationship discussed above.
2. A 14-pin downstream loopback for connecting to the Status Board will be included only if this can't be added to the APU due to space constraints. It would be located on the right edge (component side view) immediately above or below the scan chain connector to the APU.
3. A standard 10-pin scan chain connector located on the left edge near the bottom of the board. This will connect to the LPM.

All of the I/O connectors should be located on the top and left (component side view) edges of the board to facilitate harnessing. The in-line sensor jacks should be located at the extreme upper left. The others may be located for the convenience of the circuit. The power jack should be located on the right edge of the board below the APU or Status Panel scan chain connector.

1. Steppers. All five stepper motor interfaces in the interim design will be removed.
2. Solenoids:

1. The 24 solenoid controls of the interim RPM will be retained plus the overflow from attempting to add 26 to the LPM. If the LPM has space for all 26 then none will be added to the RPM.
2. The ULN2003 solenoid driver mismatch interim schematic error (e.g. U39 pin 4-13, 5-12) will be corrected.

3. Sensors. The RPM will contain two HC597 scan chain input (MISO) registers. 12 of the inputs will connect to general-purpose 3-pin input jacks. Four will connect to in-line fluid sensors.
4. In-line fluid sensors (4):

1. Two 3-pin jacks for connecting remote ultrasonic sensor boards.
2. Two optical circuits, each with a 4-pin jack for connecting a remote opto-interrupter. Two 3-pin jacks for alternate connection to the old remote optical sensor boards. Each of the two inputs can be independently configured for the on-board or remote circuit.

5. DC motors (shear valve and y-valve):

1. The L298 will be used for two shear valve controllers.
2. An L293D will be added for two y-valve controllers.
3. All of the L298 and L293D enables will be tied to +5V.
4. The eight 7032 outputs controlling the L298 and L293D will pass through an 8-pin SIP header for alternate output use.
5. The four 7032 outputs controlling the L298 are also routed to 7-pin jacks where they combine with the shear valve position inputs to provide an alternate connection to the old shear valve with integral controller.
6. The three (per motor) shear valve position signal inputs will pulled down to ground by 100K and 0.1uF in parallel, not up to +5V through 1K.
7. The inverters on y-valve position inputs will be deleted (1K pullups are still required).
8. The under-current detector circuits will be deleted. Four over-current circuits will be included.
9. The 7032 will have four scan chain data connections, MOSI up/downstream and MISO up/downstream, instead of two.
10. The 7032 will contain an 8-bit MOSI and an 8-bit MISO register. The motor controller will not use any external scan chain shift register resources.

6. Each HC595 and HC597 register will be provided with a 3-pin scan chain data bypass jack. The shear/y-valve PLD will be provided with two bypass jacks, one for MOSI and one for MISO.

LEFT PANEL MODULE

The interim LPM design strobes the fluid sensors on inverted NPCS, i.e. on every 132 usec. cycle of the scan chain. This is excessive and would substantially aggravate the existing sensor electrolysis problem. The strobe frequency needs to be reduced to the minimum, which is approximately four times per second. Also, the interim circuit incorrectly mimics the original circuit and may not function properly. The original 3500/3200 circuit (FCM drawing 9631320) uses a one-shot to generate a signal to charge the storage capacitors and then capture the comparators' outputs. The 20K and .001uF timing elements used with the LS123 produce a 10 usec. ramp period compared to the 4 usec. NPCS high period. Despite this substantial timing change, the sense (comparator) circuits in the interim version are identical to the original.

It would simplify software somewhat if the circuit were self-perpetuating and enabled by program control, but this would require some means of timing the 250 msec. sample period, which is too long for one-shots. A '555 timer is better suited to this interval but can't directly interface with the CMOS scan chain registers. A counter, such as HC4040 (12-stage ripple) could be used to divide down the NPCS. Alternatively, we could return to the old CD32/3500 approach, which is to let the analyzer program periodically strobe the circuit and then test the input. In either case, an all CMOS 10 usec. timer and latch mechanism is required. This will comprise an HC4528 one-shot and an HC273. The one-shot timing elements are .001 uF and 10K. The rest of the circuit is identical to the interim design, which is to say the original CD3500 FCM circuit.

1. The pump driver circuit in the interim design will be removed.
2. The tower interface circuitry and connectors will be removed. Tower I/O is now controlled directly by the MSM.
3. One standard 10-pin scan chain connector will be located at any convenient location on the left (circuit side view) edge. A cable will connect this to the RPM.
4. One standard 10-pin scan chain connector will be located on the right edge for connecting to the VPM.
5. As many as 26 solenoid controls, including drivers, will be added to support the CD4000. If there is not enough room for all of these, the remainder will be added to the RPM to make up a total of 26. These should be located in a horizontal line to facilitate cable bundling, but they can be located at any convenient vertical position on the board.

CDXSYS 8, 9, and 10 were originally published as AD45, 46, and 47, i.e. as part of the on-going software design meeting record. They have been moved into the system design record.

CDNEXT ANALYZER SYSTEM DESIGN REPORT 8

Sept. 22, 1999

[Report7]

[Report9]

MEETING MINUTES Originally published as AD45.DOC

David McCracken (chair), John V, Jack W, Lucy L, Dave R.

1. Dual Port Memory. Jack W.
2. APU-FPM System Organization.
3. System Design.
4. APU-FPM Coupling.

DISCUSSIONS

Jack presented the case for using dual port RAM for APU-FPM communication. The obvious advantage of dual port memory vs. serial communication is speed. Jack cited several examples, such as the possibility of a remote fork requiring as long as 70 msec. in the serial protocol. Jack's document (dpram.vsd) points out that this is the worst case, in which communication fails two times before finally succeeding. In another example, just to read a remote sensor could require as long as 14 msec. Both of these operations would execute in a few microseconds with dual port memory for communication.

The only disadvantage of the dual port RAM approach is that 24 wires are needed to connect the APU and FPM together. If the two boards were close together, this would not pose a significant problem. Dave R added that the simple wiring scheme could not be extended to boards that are far apart because of electrical noise, so the amount of wires needed to bridge some distance might be two or three times that cited for APU and FPM boards in close proximity. David suggested that the advantages mentioned by Jack could be realized without the disadvantages by using Quick Ring, which is a very high speed (e.g. 1 GHz) serial bus designed to appear as dual port memory to the CPUs. The disadvantage of this approach is the high component cost.

Jack suggested that, in addition to its raw speed advantage, dual port memory could simplify load balancing. If the FPM, for example, were to periodically copy its sensor status image into shared memory then either the APU or the FPM could act on sensor conditions, incurring no time or CPU bandwidth penalty.

When we started the CDNext-3200 design, we envisioned the following organization (this is copied directly from AD1.DOC)

NEW SYSTEM

During development, we have experimented with and considered alternative organizations, such as Jack's dual port memory proposal. In AD42, Dave R reported working around the fact that APU-FPM communication had not been implemented (or even fully defined). From AD42:

"Our system design has not yet solidified around the APU-FPM communication. Dave R developed a work-around this gap by wiring the APU to control the FPM's scan chains. He also reconfigured the FPM's CPU to provide some supporting intelligence. This system is basically ready to run flow scripts on the APU. The standard flow scripts will need to be modified so that the APU directly executes tower and loader macros."

The original plan was and remains appealing because it represents a natural evolution of the CD3200, with updated design and technology. We know that this basic architecture works and should work better with the improvements that we have made. A big plus is that the old flow scripts and macros need only translation and minor adjustments to be functional in a new APU-FPM system. Even if we were to devise a superior organization, we don't have a large enough team to implement one. By concentrating on technical improvements rather than sweeping architectural change, we can maximize our effectiveness.

The APU and FPM boards largely fulfill their requirements in their current hardware form. They contain the intelligence (CPUs that can execute scripts and communicate) and remote control (scan chain) capabilities to replace, respectively, the CPUDCM and TWR, LDR, and MPM (in addition to the other subsumed units).

The APU and FPM boards do not contain significant I/O resources and need to operate with remote I/O and motor driver boards. The natural remote I/O division from the point of view of scripts is for all local CPUDCM I/O to attach to the APU scan chain; all local TWR and LDR I/O to attach to the FPM I/O scan chain; and all motors to attach to the FPM's motor scan chain. This division should generally reflect physical locality as well, because the TWR and LDR units are physically distinct and the primary I/O responsibility of the APU is to manipulate valves to effect fluid flow related to sample measurement.

The left and right panel and tower boards of the most current APU-FPM prototype do not reflect the expected division. There are several reasons for this. One is that the locality of the tower and loader boards has been diminished by our desire to pull them into the body of the instrument to remove them from fluid zones (John says that our competitors have cited the exposure of these boards as evidence that the CD3200 is an unfinished prototype). Another reason is that we want to avoid having any board attach to both the APU and FPM scan chains, as this indicates a poor division of I/O. To avoid this, a temporary decision was made to simply dump all I/O responsibility onto either the APU or the FPM (or the FPM physical scan chain under direct APU control). This decision needs to be revisited. There are several competing requirements, including:

1. Minimize local I/O wiring, i.e. the remote I/O boards should be located as close as possible to the electromechanical devices.
2. Keep boards away from fluid areas and another other areas routinely exposed to the operator when manipulating samples or cleaning the instrument.
3. Minimize connections. Since I/O device connections can't be reduced, this primarily means reducing the number of boards in order to reduce the number of power and scan chain connections.
4. Avoid having both APU and FPM I/O scan chains on one board. Obviously, mixing the FPM motor scan chain with the APU I/O scan chain is not similarly discouraged, as there is no other motor control means.
5. Minimize script cross references, i.e. where a script executing on the APU needs to test or manipulate a resource in the FPM scan chain (the opposite direction is not supported at all).

All of these requirements have to balance against each other. For example, having both the APU and FPM scan chains on one large board would reduce the number of scan chain connections compared to several smaller boards, each connected only to one scan chain or the other. Also, a larger board reduces the number of power connections but tends to increase local I/O wiring, because it can't be located as close to the electromechanical devices as several smaller boards.

The relatively small tower board represents approximately half of the FPM's I/O responsibility. Loader I/O represents most of the remainder except for special hardware to control the servoed pressure/vacuums and strobed fluid sensors located directly on the FPM. Considering only size and ignoring location, the APU scan chain could be connected to the right panel and half of the left panel while half of the left panel and the tower could be connected to the FPM scan chain. This would yield one very large board for all APU I/O and one moderate-sized FPM I/O board, minimizing connections but probably significantly increasing local I/O wiring. While this might be a viable solution, it more likely represents an extreme position. A more reasonable possibility might be two moderate-size APU I/O boards, one located on the left panel and the other on the right.

At the next meeting, the group will examine a CD3200 and determine a division of remote I/O based on the principles described here. To assist in this, John will procure an instrument (preferably with the optics bench removed). Also, the document "CDNEXT: CD3200-CLASS INSTRUMENT I/O" (k:\cdx\doc\analyzer\cdx32io.doc) has been prepared (primarily from the CDM's analyz.ini) as a kind of worksheet listing all of the I/O to make sure that we don't neglect any known devices.

Considering that the CD3200 obviously can tolerate the current level of CPUDCM-SHM coupling and that the only potential additional coupling for the APU-FPM is in the strobed sensors and servoed pressure/vacuum controls, it would be reasonable to predict that, even with no effort to reduce the coupling, the proposed APU-FPM system can meet its I/O requirements. However, reducing the coupling is desirable both to "buy" CPU bandwidth for other functions and to improve domain cohesion (and, therefore, maintainability).

It isn't difficult to find instances of what could become APU-FPM coupling in the existing CD3200 flow scripts (or their translated versions in k:\cdx\fsq). There are some obvious specific cases, such as the new checks script, which replaces embedded code in the CD3200 analyzer. This periodically reads the strobed fluid sensors. Clearly, this can be moved to the FPM, which can send a fault message just as it will for the old SHM faults. More generally, we can search for the following telltale signs:

1. The flow sequence command SSTAT TOWER or SSTAT LOADER precedes all remote I/O operations.
2. Fork and Join to any macro name.
3. All barcode operations.

In most cases only a few of these exist in any one flow script. In some of these cases, it may be possible to move the entire script to the FPM. Alternatively, the script may be divided into some portions that execute on the APU and others on the FPM. When the latter approach is being considered, it is important to examine the intermixing of resources from both domains. For example, the shm.f file contains some scripts (and portions of scripts) that access tower/loader sensors and global VARs that are shared with other scripts that communicate with the data station and, therefore, belong in the APU domain. Thus, scripts that would otherwise clearly separate into APU or FPM are glued together by resources (VARs) that can't cross the domain boundary (this restriction is likely to change in order to address this problem).

CDNEXT ANALYZER SYSTEM DESIGN REPORT 9

Sept. 30, 1999, 10:24AM.

[Report8]

[Report10]

• APU-MSM Communication.
• Motor Scan Chain.
• Hardware Partitioning.
• Hardware Roadmap.

MEETING MINUTES Originally published as AD46.DOC

David McCracken (chair), John V, Jack W, Lucy L, Dave R.

DISCUSSIONS

Jack W questioned whether the APU-MSM communication, having evolved from the CPUDCM-SHM link, would be viable for the higher traffic volume. He pointed out that the SHM link not only has a low Baud rate but is also only half-duplex. Every message initiated by an SHM (such as macro done) requires the CPUDCM to respond to an ATN interrupt, send a request to the SHM, receive an ACK to the request, and then receive the reply as another independent message.

The APU-FPM physical interface, including Baud rate (19.2K) was similar to the SHM. The new APU-MSM physical interface is nearly identical to the HSSL, with a 500K Baud rate and hardware flow control. There still is an ATN line. In the meeting, David answered that the half-duplex requirement from the SHM was still in effect in the APU-MSM protocol. However, there is no need for this. The HSSL interface has provided reliable full-duplex operation and the only difference between this and the APU-MSM drivers is the restricted use of DMA simply due to the shortage of DMA channels.

To take advantage of the full-duplex capability, the MSM will automatically send the completion status of motor moves and scripts invoked by the APU. Sensor status must still be requested.

Currently, the APU-MSM protocol specifies the same CRC as in the APU-DataStation interface. This is a fairly time-consuming calculation and is unnecessary for the short distance and small messages (except during program download) that pass between the APU and MSM. This will be changed to a simple checksum.

The MSM interface Baud rate is 26 times faster than the SHM. Assuming that one-third of the traffic has been caused by the half-duplex restriction, the effective communication rate is 34 times faster than SHM communication. Tower and loader function communication does now have to share the link with motor communication but that is roughly balanced by the 50% reduction in tower and loader traffic due to converting interactive functions to full MSM scripts.

MOTOR SCAN CHAIN

John asked how the motors' winding test would be implemented in the new system, Dave R replied that it wasn't compatible with the scan chain. While it is true that the scan chain doesn't help with this function, it doesn't prevent the winding test from being implement essentially as it is on the current MPM. We just need to add two wires to the motor control cable that now comprises the scan chain.

The two new wires act essentially as an analog bus, with each of the 28 windings (two per motor) attached to the bus through 1 Mohm resistors. The drivers are connected across each winding. If a winding is not open, its driver is nearly shorted. If a driver is turned off, the circuit leg presents a 2 Mohm load across the analog bus. If all but one driver is turned off, the load is 154 Kohm. If there is an open winding across the one driver that is turned on, the voltage across the bus is 1.72V (154K * 24V / 2.154M). If that winding is good, it shorts the driver and the differential bus voltage is nearly 0.

The motor scan chain bus currently comprises both an I/O scan chain (SPI) and the motor scan chain (MPI). The SPI will not be needed in the new architecture. The new motor control bus will use two wires each for reset, clock, data out (from controller), data in (from motors) and parallel load. With the two analog wires, the total is 12 wires. Since this is not a common connector size, a 14-wire bus will be used. The motor scan chain runs continuously even if all motors are at rest. To avoid inducing noise into the analog lines, the analog lines should be placed on one side of the cable, interspersed with the two spare wires connected to the controller's (MSM) ground and not connected on any motor driver boards. Each motor interface circuit will connect the winding across the analog bus through 1 Mohm resistors. On the MSM board, the analog feedback bus will connect to an ADC. One of the functions of the MSM program will be to test the windings.

Dave R suggested using the otherwise unused potential motor scan chain inputs for optional home sensors. The scan chain has four outputs for each motor. After the scan chain serially shifts all 56 bits, the parallel load strobe transfers the bits to the outputs. A broadside load into the serial registers can occur at the same time (actually on the trailing edge of the strobe) just as is now done on the I/O scan chain. The next serial shift of the output bits, simultaneously reels in the inputs. Each motor interface circuit will provide one or more (up to four) home flag connectors, each comprising 5V, DGND, and a connection to one scan chain input.

ADDITIONAL ANALYSIS

The interim system architecture erroneously assumed that the FPM would be responsible for nearly all control functions, but to allow CD3200 flow scripts to be reused, the APU should control everything that had been accessed through the Peripheral Bus. These items should be located on the APU's I/O scan chain.

The interim APU-FPM partitioned the systems into the following boards:

1. APU

1. 12" * 6" in the 4-channel version. 72 sq. in.
2. Located on the swing-out cardcage.
3. Provides functions related to gather, including main amplifier control and cell counting. Communication with Data Station.

2. FPM

1. 9" * 6". 54 sq. in.
2. Located on the slide-out Pneumatic Unit.
3. Vacuum/pressure subsystem related to Pneumatic Unit, including the five pressure/vacuum transducers.
4. Stepper motor control (motor scan chain controller).
5. I/O scan chain control of Left and Right Panel Boards.

3. Left Panel Board

1. 10" * 7". 70 sq. in. Sparsely populated in the middle. Periphery nearly consumed by connectors.
2. Located on the inside left panel plate, which separates the board from the solenoids on the left panel.
3. Provides 32 drivers for the 25 left panel solenoids plus spares.
4. Routing point for the FPM I/O and motor scan chain to the Tower Board.
5. Peristaltic Pump (stepper) driver interface.
6. Strobed fluid sensor circuits.
7. Simple sensors:

1. CS model door.
2. RBC Diluent Overpressure.
3. Vacuum Accumulator 1 Wet.
4. Vacuum Accumulator 2 Wet.

4. Tower Board

1. 2.5" * 6". 15 sq. in. total with 2.5 sq. in. consumed by scan chain interface (connector and single-differential translators).
2. Located outside of the main box on the side of the tower mechanical frame. Connected to the Left Panel Board through a hole near the top of the left front panel.
3. Tower mix motor (stepper) driver.
4. Tube spinner DC motor driver. This is not correct-- it will be replaced by a stepper.
5. Simple sensors:

1. Tower Height.
2. Tower Home 1.
3. Tower Home 2.
4. Door Open.

5. Loader Board

1. 5.2" * 5". 26 sq. in. total with 4 sq. in. consumed by scan chain interface.
2. Located in the loader unit. Daisy chained to the FPM I/O scan chain (two 16-pin ribbon cables).
3. One stepper driver interface.
4. Four solenoid drivers.
5. Five simple inputs.

6. Right Panel Board

1. 12" * 7". 84 sq. in. Sparsely populated. Periphery is not full (the motor driver board space is not used efficiently for periphery access).
2. Located in the main box behind the right front panel and perpendicular to it (parallel to the APU).
3. Five stepper drivers for the four syringe motors and the wash block motor.
4. High power full-bridge driver for the shear valve.
5. 24 solenoid drivers for the 15 solenoids plus spares.
6. Two sensor inputs for shear valve position.
7. One sensor input for paddle switch.
8. Two sensor inputs for pre-shearValve and post-shearValve fluid detectors.

Most of the boards do not fully consume the available spaces (in a CD3200 box). The available spaces are:

1. Cardcage (APU) 12" * 12".
2. Left Panel 12" (height) * 14".
3. Right Panel 12" (height) * 13".

VPM

When we examined the interim system, several changes were obvious. One is that the vacuum/pressure circuitry could and should be reduced to the minimum needed. It will be controlled through the APU scan chain and, therefore, doesn't belong on the FPM board. The transducers complicate board swapping, so, for maintenance concerns, the circuitry should be minimized. The vacuum/pressure circuit should be located on the Pneumatic Unit but no other circuitry should be there. Therefore, the new design will have a VPM board, which will only control the vacuum and pressure. It will be located on the Pneumatic Unit and will be controlled through the APU I/O scan chain.

Responsibility for the strobed fluid sensors as well as vacuum/pressure control was taken away from the FPM and given back to the APU (via the APU scan chain). Thus, the name FPM (Flow Process Module) no longer has any meaning. The unit now strictly replaces the MPM (Motor Process Module) and SHM (Sample Handler Modules-- Tower and Loader). Therefore, it has been renamed MSM.

MSM

The core of the MSM unit comprises the 68340, FPGA, APU interface (connector and drivers), motor scan chain interface (now augmented with an ADC), and I/O scan chain interface (if tower and loader remain separate boards). This consumes approximately 36 sq. in. In the interim system, the MSM (FPM) controls the tower and loader boards through scan chains. Therefore, it could be located nearly anywhere in the box. The new smaller MSM, however, could be located closer to the tower and loader that it controls. We physically examined the system to determine whether it would be feasible and desirable to move the MSM to the plate where the Left Panel Board is located and to connect directly to the tower and/or loader I/O devices, thereby eliminating the tower and loader boards. This could improve reliability by reducing components and connections, reduce exposure of circuitry to fluids, and improve our image with customers.

TOWER

The tower board clearly should be replaced. Locating the MSM at the bottom of the left panel (inside) plate with its tower connectors on the lower left and threading the tower wires through a hole near the bottom of the left front panel allows the wires to be only slightly longer than they are with a tower board. This MSM position is also the best location for the board to connect to the loader.

Disconnecting the tower I/O from the MSM located at the bottom of the inside left panel would not be physically difficult. There are several inches of clearance between this location and the Pneumatic Unit, which can slide out if this isn't enough. It would still be advisable to use connectors with ejector tabs to facilitate disconnect.

LOADER

Whether to replace the loader board with direct I/O from the MSM is not as clear as for the tower. The interim loader board has 30 input lines and 13 outputs. The 43 wires of a direct I/O approach compares favorable to the 40 wires used in the scan chain design (two 16-pin scan chains plus the 8-pin power cable). However, some of the inputs may be sensitive to EMI and the stepper driver is an EMI source. Another consideration is future flexibility. If direct I/O is used, every change, such as adding a sensor, potentially affects the wire count. If we choose direct I/O, thinking that it fits into a DB37 connector, for example, then the decision can be rendered obsolete by a relatively minor functional change.

The interim loader board's cabling is inadequate for maintenance. Three cables have to be disconnected to release the loader and none of them will be very accessible. The board will have little vertical clearance, yet its power plug must be pulled up with considerable force to disconnect. The single DB37 cable used in the CD4000 represents a much better approach even if it does increase the cabling cost. The interim board approach to cabling is not inherent in the scan chain interface. In fact, better cabling favors the scan chain approach, which isolates the wire count from future I/O count changes.

The two analog motor feedback wires increase the wire count of the scan chain interface but not of the direct I/O. But the interim design uses more wires in the scan chain connector than is actually necessary. It has two scan chain connectors that are nearly identical. Units can't be daisy-chained to a scan chain, because the data wires require unique input and output points. There are two logical data lines, downstreaming from the master (MSM) and upstreaming from the slaves. Each of these requires two wires for differential signaling. These four wires have to be different in the connectors, but all of the others are identical. Further, the loader board in the new architecture would be the only unit on the MSM's external I/O scan chain. The last unit in a scan chain doesn't need to provide a downstream connector. Therefore, the I/O scan chain doesn't even need the four data loop wires.

The situation for the loader's motor scan chain is different. The MSM master is located physically between the loader and the (new-- see stepper review) right panel motor driver board. One of the two slave boards must provide the data loop. While reducing the wire count in the MSM-Loader interface is desirable, it could only be done by physically looping through the right panel motor driver board and coming back through the MSM and down to the loader board. This would require either two normal scan chain cables or one special looping cable. The looping cable would reduce the total wire count but at the expense of system flexibility, as only standard cabling supports "mix and match" boards. Special cabling should only be used in a point-to-point link that we are sure is not going to change, such as between the MSM and loader.

If the loader board provided the motor loop, the logical interface signals would be:

1. I/O scan chain:

1. reset (shared with motor scan chain)
2. clock
3. parallel load
4. data in (from MSM)
5. data out (to MSM)

2. Motor control:

1. clock
2. parallel load
3. data in (from MSM)
4. data in loop (downstream through MSM to other units)
5. data out (to MSM)
6. data out loop (upstream from other units through MSM)
7. analog feedback.

The total wire count would be 24. A DB37 could support these while providing 13 power pins, which should be sufficient. A right-angle DB37 on the loader board would solve the disconnect problem, particularly if the connector itself can be bolted to the loader frame.

STEPPERS

The MSM will have three stepper interfaces for driving the two steppers located in the tower-- probe and spinner (this has been changed from a DC motor to a stepper)-- and the peristaltic pump, located on the left-hand side of the left panel. If direct loader I/O replaces the loader board then a fourth interface is needed. These are located on the motor scan chain but with the single-ended electrical interface that can be locally used instead of differential.

The four syringe motors and one wash block motor are all located on the right front panel. A stepper driver board will be located on the (inside) right panel under the wash block motor and, therefore, next to the right-most syringe. This board will contain five stepper driver interfaces. If the board is too large for this space, it may move to the right several inches, where there is a large open area that was occupied by an SDM in the CD3200. All stepper interfaces are removed from the Right Panel Module. The shear valve driver interface doesn't similarly migrate because it is not a stepper, but is controlled through the APU I/O scan chain.

The size of the syringe/wash block stepper driver board is determined by the following elements:

1. Five stepper drivers (including connectors) = 14 sq. in.
2. Motor scan chain interface = 2 sq. in.
3. Power and miscellaneous = 4 sq. in.
4. Total = 20 sq. in.

LEFT PANEL

The peristaltic pump driver will move from the interim Left Panel Board to the MSM. The interim Left Panel Board provides a scan chain connector to the Tower Board. This will move to a mechanically similar I/O connector on the MSM. The MSM area is determined by the following subsections:

1. CPU (68340, FPGA, 7-seg display, memory, PC-104, APU interface, BDM, support components) = 24 sq. in.
2. Barcode reader interface = 1.7 sq. in.
3. Motor and scan chain interfaces (including Loader) = 8.5 sq. in.
4. Tower section (including two stepper drivers) = 12 sq. in.
5. Peristaltic pump, driver = 1.7 sq. in.
6. Power connector and miscellaneous = 3 sq. in.
7. Border margin = 7 sq. in.
8. Total area = 58 sq. in.

The Left Panel Board continues is still needed to provide at least solenoid drivers. The interim design also includes fluid sensor circuitry (including for the strobed sensors). The board area is determined by the following subsections:

1. Solenoid drivers = 40 sq. in.
2. APU scan chain (ICs and two connectors) = 3 sq. in.
3. Sensor circuitry and connectors = 8 sq. in.
4. Power connector and miscellaneous = 3 sq. in.
5. Border margin = 7 sq. in.
6. Total area = 61 sq. in.

Since the Left Panel Board and MSM are located adjacent to each other, it would be possible to simply combine them into one. However, with such a large number of connectors, servicing would be easier if the two were separate. If separate, another 3 sq. in. should be allowed for separation. The total area consumed by the two boards would be 122 sq. in. The left panel plate provides 168 sq. in. The MSM will be located on the bottom of the plate and the Left Panel Board above it.

STROBED FLUID SENSORS

Two of the six strobed fluid sensors, are located on the front left panel. The remaining four are probes inserted into reagent and waster containers outside of the instrument. Their wires enter the instrument through the back panel (of a CD3200) but they could enter at any convenient point. Since only the two sensors on the front panel have a fixed location, it is reasonable to locate the sensor circuitry near to them and route the remainder to this point through the most convenient path. The Left Panel Board is the obvious choice for this. The sensor wires entering through the back panel can traverse to the front if necessary, but it would be better to provide an access point closer to the Left Panel Board if possible.

FLUID IN-LINE SENSORS

The pre-shearValve and post-shearValve fluid sensors attach to two small boards precariously dangling from a flagpole on the right front panel behind the Y-valve. The optical sensor board is our own and its circuitry should be merged into the Right Front Panel. The ultrasonic sensor board is mated to its sensor and is tuned by the manufacturer. This board consumes less than 2 sq. in. and the Right Front Panel board has virtually unlimited space, so it would be reasonable to provide an option to mount the sensor board on the panel board. Remote mounting should not be precluded, because the sensor cable has a fixed length that may not support every possible position of the sensor unless the board is mounted on the front panel.

STATUS BOARD

The interim Status Board has two combined motor and I/O scan chain connectors for attaching to the FPM. These must at least be replaced by connectors for the APU I/O scan chain, which doesn't include a motor interface. The wiring can be much more aggressively reduced by using a point-to-point loop-back cable to the Right Panel Board. This requires just one 14-pin cable.

RIGHT PANEL

The interim design has two combined motor and I/O scan chain connectors for attaching to the FPM. The new design has two similar connectors for attaching to the APU I/O scan chain. Neither the MSM's I/O or motor scan chain attaches to the new board. All of the stepper driver circuits are moved to the new right panel motor driver board.

A point-to-point loop-back cable connector will be added for connecting the Status Board to the APU I/O scan chain.

CABLING

The interim design uses consistent cabling, which would support mixing I/O boards, i.e. any board that attaches to a particular scan chain can be located anywhere on the chain. This essentially doubles the amount of cabling and connectors. The supposed flexibility that this should buy is really an illusion. Each I/O board is designed according to where it is located. Any movement would be within a narrow range that would not upset the bus topology. The bussing flexibility is inconsistent with the reality of these boards. Therefore, cabling should be reduced wherever feasible by using special point-to-point arrangements as specifically described above. The two cases that stand out are the Right Panel Board to Status Board and the MSM to Loader board.

The standard I/O control cables are as follows:

1. APU (I/O) scan chain. The APU has two of these but only one will be used for the near future. This contains 10 wires comprising differential pairs for:

1. Clock
2. Reset
3. Parallel Load
4. Data from master (APU) to slaves.
5. Data from slaves to master.

2. Point-to-point I/O loopback. This contains 14 wires, 10 of which are identical to a standard I/O scan chain. The remaining four wires comprise two differential pairs for loop data from master and loop data to master. This is functionally equivalent to two scan chain cables bridged by an I/O unit, but does not support physical daisy chaining of I/O units.
3. Motor control bus. There is only one of these and the master is the MSM. The standard version contains 10 wires as in the I/O scan chain plus two analog winding feedback wires. A 14-pin connector will be used with two wires not connected.
4. Point-to-point motor control with loopback. This contains 16 wires, 12 of which are identical to the standard motor control bus. The remaining four wires comprise two differential pairs for loop data from master and loop data to master.

I/O control cabling usage is as follows:

1. APU scan chain.

1. APU scan chain 1 to Right Panel Board is a standard 10-pin I/O scan chain.
2. APU scan chain 2 is reserved for future use.
3. Right Panel Board to Status Board is a 14-wire point-to-point I/O loopback.
4. Right Panel Board to Left Panel Board is a continuation of the APU scan chain after looping through the Status Board. It is a standard 10-pin I/O scan chain cable.
5. Left Panel Board to VPM (located on the Pneumatic Unit, so the cable needs a 3-foot service loop) is a standard 10-pin I/O scan chain. This is a continuation of the APU scan chain after looping through the Left Panel Board.

2. MSM I/O scan chain. This locally loops through the tower control section and then combines a standard I/O scan chain with a loopback motor control bus connected to the Loader Board. The Loader Board is the end of the I/O scan chain and does not provide any loopback.
3. MSM motor control.

1. This locally loops through the three on-board stepper drivers (for two tower motors and the peristaltic pump).
2. MSM to Loader. The motor loop continues after local drivers by joining, as a loop-back motor cable, the I/O scan chain in the Loader interface. The combination cable connects to a DB37 on the Loader Board. Loader power is provided on the 13 pins not used by the scan chains.
3. MSM to Right Panel Motor Driver Board. After looping back from the Loader, a standard 14-pin (12 active) motor scan chain continues the chain.
4. Right Panel Motor Driver Board to ? A second standard motor control connector may be included on this board to allow the motor chain to continue to future units. Currently, this is the end of the motor scan chain.

APU

1. Modify interface to MSM (was to FPM in the interim design) to duplicate the APU to Data Station interface. This involves clock and data signal changes and pinout changes.
2. Add second I/O scan chain, remove motor scan chain, and replace connectors with two 10-pin standard I/O.
3. Implement decimation firmware.

FPM

No longer exists. Its vacuum/pressure control moves to the new VPM. The remainder moves to the new MSM.

MSM (replaces FPM)

1. Start with the existing FPM.
2. Remove VPM and all local sensor circuitry and firmware.
3. Retain barcode reader interface hardware and firmware.
4. Retain PC-104 interface.
5. Retain I/O and motor scan chain firmware but change cabling as explained above and add 56-bit motor scan chain input.
6. Add motor controller (on top of motor scan chain controller) firmware to FPGA.
7. Add ADC and control firmware for motor winding test (ADC circuit TBD).
8. Rewire interface to APU.
9. Merge Tower Board circuitry (minus scan chain connector and interface drivers). Place tower I/O connectors on the bottom left to be close to the new access point through the front left panel. Replace the spinner DC motor driver with a stepper driver.
10. Add a stepper driver for the peristaltic pump.
11. Add stepper winding feedback to each driver (one Mohm resistor for each leg of each winding).
12. Route the local I/O and motor scan chains and their off-board interfaces, including the combination cable to the Loader Board.
13. Add serial flash for programming FPGA and provide a means to disable programming by CPU without eliminating it entirely (e.g. by jumpering).
14. Add BDM DS/CLK select.
15. This board should be approximately 11" long by 5.5" high.

VPM (new)

1. Move FPM circuit to new board.
2. Move control firmware from the FPM's FPGA, retaining low-level control but replacing the higher-level interface with one compatible with the APU scan chain.
3. Add electrical interface to APU scan chain.

LOADER BOARD AND CABLE

1. Replace the power and two scan chain connectors with one right-angle DB37 to connect to the combined MSM I/O scan chain plus motor loop scan chain plus power.
2. Develop cable harness to get loader power directly from the Distribution Module instead of through the MSM.

LEFT PANEL BOARD

1. Eliminate peristaltic pump stepper driver.
2. Eliminate tower scan chain connector and wiring.
3. Replace the two I/O+motor scan chain connectors with two standard 10-pin I/O scan chain connectors (will attach to APU cable).
4. Modify the strobed fluid sensor firmware to read only once every 100 msec. and only if enabled by a control bit on the APU scan chain.
5. Add at least 4 scan chain inputs and 4 outputs for spares.
6. Reduce board height. New board should be approximately 5.5" high and 11" long. In any case, it and the MSM must share the 12" (high) by 14" inside front left panel plate.

RIGHT PANEL BOARD

1. Move all of the stepper drivers to the new Right Panel Motor Driver Board.
2. Replace the two SPI/MPI connectors with two standard 10-pin scan chain I/O connectors.
3. Add a point-to-point I/O loopback I/O scan chain connector for the Status Board. The data lines on this connect between the two standard connectors, i.e. the data in the APU cable connects to the standard data lines of the Status Board cable while the data in the other connector (which goes to the Left Panel Board) connects to the loopback data in the Status Board cable.
4. Merge the optical blood-in-line sensor circuitry.
5. Provide an interface to and optional piggyback mounting site for the ultrasonic blood-in-line sensor circuit.
6. Add at least 4 scan chain inputs and 4 outputs for spares.

STATUS BOARD

1. Replace the two SPI/MPI connectors with one 14-pin I/O scan chain loop back connector for connecting to the APU scan chain through the Right Panel Board.

RIGHT PANEL MOTOR DRIVER BOARD (new)

1. Copy (move) the five stepper motor driver circuits from the interim Right Panel Board.
2. Add the winding feedback connections (each winding leg to one of the analog bus lines through a 1 Mohm resistor).
3. Add one or two standard 14-pin motor control connectors. Note that the data lines of the second connector (furthest from MSM) are not directly connected to the first connector but to the last motor in the chain on this board.
4. Add power.

CDNEXT ANALYZER SYSTEM DESIGN REPORT 10

Nov. 11, 1999

[Report9]

[Report11]

1. Scan Chain and RPMD. Andy.
1. Replacement Drivers and Receivers.
2. Motor Flags.
3. Unused Scan Chain.
4. MOSI Shift Register.
5. Connectors.
2. MSM. Andy.
1. Scan Chain Skew.
2. Sense Register (for bubble detection).
3. Motor Page Flip and Scan Chain Interrupt.
3. Right Panel Module (RPM) and Left Panel Module (LPM). David McCracken.
1. Partitioning.
2. Solenoids.
4. Schedule. Andy.

MEETING MINUTES Originally published as AD47.DOC

John V, Robert D, Andy O, Jack W, JP Y, Dave R, David McCracken.

DISCUSSIONS

REPLACEMENT DRIVERS AND RECEIVERS

As the first item under the RPMD review, Andy pointed out some basic scan chain changes from the interim design.

The 75174 and 75175 differential drivers and receivers are obsolete. Andy and Coleman replaced them with MC26C32 (receiver) and MC26C31 (transmitter). These differ from the older parts in the following ways:

1. When not driven, they default to positive state (receiver out is logic high and transmitter out is + high and - low).
2. The differential signal transition time of the MC26C31 is 30 nsec. compared to 120 nsec. for the 75174 (TI's AM26C31C reduces this even further to 10 nsec.).

For scan chain usage, these differences only improve (reduce) the possible SCK-NPCS skew. It was not discussed in the meeting, but we will also need to replace the 75174 and 75175 used in the HSSL and IML (Inter-Module Link between APU and MSM). The IML timing analysis in cdxsys2- Distribution of FPM Subsystems- Communication Clocking will have to be revisited.

After the general meeting, Andy, Robert, and I discussed the possibility of a further upgrade to LVDS components. These are even faster and might support a significant speed increase. Our system, firmware, and hardware designs are based on the old, slow parts. Significant system design improvements could be made possible by a relatively small speed increase. For example, increasing SCK from 2 MHz to 2.5 MHz would enable the MSM (with FPGA and firmware changes) to support the 17 steppers required by the CD4000. It might be relatively easy for us to double the speed of all scan chains now in order to support future system enhancements. Andy is going to investigate LVDS.

MOTOR FLAGS

The version of the RPMD under review does not include motor flags, because the description of RPMD given in Cdxsys3.Doc- Stepper Motor I/O- Right Panel Motor Driver Board Requirements failed to mention them. The general motor scan chain description includes four flags per motor with at least two of them taken to 3-pin (+5, signal, DGND) pins. This description should apply to all stepper motors. It can be found in cdxsys2- Stepper Motors- Motor Scan Chain Inputs, reprinted here for reference:

As explained in AD46, the stepper interfaces will include four inputs for flags. One HC597 octal shift register will support two motors. For a circuit example, see Status Panel or Left Panel. The '597 is double-buffered. On the rising edge of NPCS0 (scan chain parallel load) the input capture register is loaded by asynchronous RCK. During the period in which NPCS0 is high, at each positive transition of SCK0, the captured input is loaded into the input scan chain because the active low synchronous load signal SRLOAD is driven by inverted NPCS0.

At least two of the scan chain inputs are taken to standard three-pin flag jacks. The other two pins provide +5 and digital ground to an opto-interrupter. The flag pin is connected to the '597 input and to a pullup resistor.

A value was not given for the pullup resistor. It should be 1K. This is the value used in the y-valve (DC motor driver) circuit, which uses our most common opto-interrupter. For additional background discussions, see AD46- Discussions- Motor Scan Chain.

UNUSED SCAN CHAIN

Andy opened the discussion of RPMD motor flags as an example of a situation in which either MOSI or MISO data is unused on a given board. Obviously, if both were unused, there would be no reason for the board to be on the scan chain. All of the current and planned boards use both MOSI and MISO, but a board using only one of these is conceivable.

In the case of the RPMD, had MISO been unused, there would be no need for its inclusion in the cable at all. The general loopback cable described in AD46- Hardware Partitioning- Cabling assumes that both MOSI and MISO are used in the loopback board. If there is no doubt about which boards will be on both ends of a loopback cable, the two boards can agree to simply leave out all four wires of an unused data signal. If more than one type of loopback board might be used or if the loopback board extended the loop by daisy-chain to another board (before returning via the loopback cable) and both MOSI and MISO were needed in some configuration, then the loopback launch point would have to be a full (16-pin in the case of motor scan chain) loopback connector. Then the situation presented by Andy could exist on one of the loopback boards. Andy's question was whether there was any need for a receiver-transmitter pair for the unused signal or if a wire loopback would be sufficient. The wire loopback is certainly adequate.

MOSI SHIFT REGISTER

The interim design used HC594 for MOSI output registers. This is very rare and we have substituted HC595, which is nearly identical but has an Output Enable instead of Output Reset. As explained in cdxsys3- Scan Chain- Scan Chain Operation- '595 Architecture, the only way to reset a '595 is to assert its MR (Master Reset pin 10) and then strobe its latch clock (pin 12).

Andy explained that the RPMD design doesn't try to reset the '595 but, instead, uses its OE to establish an initial output value. Disabling the output would allow pullup or pulldown resistors to establish a value sooner than the motor scan chain controller could load itself and effect the described reset. The motor driver current select signals could be pulled high, eliminating inverters. This approach conceptually answers the concern regarding motor safety at startup expressed in cdxsys3 and the general suggestion that a synthesized (in PLD or FPGA) replacement "could improve on the '595 by making the reset output more reliable and by reducing external inverters by resetting to 1 or 0 as appropriate." Dave R pointed out that the concept sketched by hand into the RPMD schematic ties the OE to +5 via 10K, affording the scan chain no means to control the output. We all agreed that OE should be tied to NPHRST, the scan chain reset signal, and that this signal would have to change to active high (PHRST instead of NPHRST). Andy mentioned that this would be a good change also because the replacement differential transmitters and receivers default to high. Also, scan chain reset is tied to '595 MR, which is not appropriate. The hand sketch appears to have accidentally swapped the connections. MR should be tied high and OE to scan chain reset.

We discussed the fact that this approach would require resistors on '595 outputs. For the motor scan chain, some of these would be replacing inverters. However, in all other situations, these would be additional components, so we might want to consider alternatives for I/O scan chains. There is another problem that we didn't notice during the discussion. Giving the scan chain reset control of OE appears to defeat the original purpose of providing a controlled reset condition without depending on the scan chain. However, if reset comes up high, for example because the FPGA's outputs are tri-stated until it configures itself and this results in the driver assuming a high output, then the dependency is very little compared to the active reset method.

Andy described how the scan chain controller would initially hold PHRST asserted (now high) and not disassert it except under software control. Software would load the scan chain with safe values and then write to a control bit in the FPGA to disassert the reset. Dave R added supporting detail to this scenario, explaining that he had expected software to initially test the scan chain by loopback before loading application values and then releasing reset.

The following analysis and proposal for I/O scan chains was not discussed in the meeting. Since there are many cases in which simply clearing the output register within perhaps 200 msec. affords adequate initialization, it is excessive to demand that all scan chain output registers reset in the manner proposed for the motor scan chain. However, there may be specific cases that require the essentially instantaneous controlled state made possible by that method. Two reset means can easily be provided in one system by the following design:

1. Scan chain reset is active high in order to take advantage of the differential receiver/transmitter default high. Scan chain output register configurations that need active low reset can invert the signal.
2. Scan chain reset will be active as soon as power is applied to the system. If necessary, the scan chain controller's output will be pulled high to force this state.
3. After the scan chain controller FPGA configures itself, it will continue to hold reset active until software deactivates it. If convenient, all scan chain output values may be initialized to 0, but this is not essential.
4. As soon as possible, the FPGA will begin operating the scan chain. It will not wait for a software command. For the proposed motor scan chain reset means (by OE), this activity will be irrelevant.
5. For MOSI outputs where the controlled circuitry can tolerate a lethargic reset, the '595 OE is tied high and PHRST inverted drives MR. The first NPCS strobe from the scan chain controller transfers all 0s from the serial shift register to the output register.

Item 4 in the above proposal deliberately contradicts the CD3200R Flow Panel Processor (FPM) Board Hardware Design Description (Dave R 9/4/98) description of the SPI control register. The EN (enable) bit described in that document serves no useful purpose and should be eliminated.

CONNECTORS

Andy relayed a question from Jill regarding the positioning of connectors, particularly motor jacks, on the RPMD. The RPMD requirements analysis in cdxsys3 says "looking at the component side, jacks for attaching to the four syringe motors are located on the right edge. The wash block motor jack is located as near as possible to the upper right corner of the board. The spare motor jack may be located anywhere on the board. Each motor jack is the standard 5-pin missing-center stepper connector (as used in CD3500/3200)." It also states that the board is 6.5" horizontally by 4.5" vertically and it calculates the total board space required as less than the allowable board size. However it doesn't take into account motor driver layout form factor.

The interim RPM replicates a motor driver template five times. Dave R explained that he allowed two square inches of copper for heat dissipation for each driver (one motor requires two drivers). Four drivers based on this pattern would require a board edge length of 7.5" compared to the 4.5" available. Locating the four connectors on the right edge is ideal but not required. Locating them along the top would be almost as good. All of the motors are located above the RPMD and the four in question are also located to the right of the board. We want to avoid any other locations for these connectors, which would require the cables to cross over the board. JP pointed out that service has always justifiably complained about such interference.

The interim LPM contains an example of an alternate form factor. The pump driver circuit aligns the two drivers length-wise, creating a 1.3" by 3" block with the connector located on the 1.3" side. Replicating this pattern four times would produce a block 5.2" by 3". While the 5.2" is still longer than the 4.5" right board edge, it fits well within the 7.5" horizontal limit. Replicating this pattern six times produces a 7.8" edge, which nearly fits all drivers on the top edge. Since much of the space is just a blank copper heat spreader, it would be a simple matter to slightly reduce the width and increase the length of the pattern. For example, 1.2" by 3.4" would give each driver 2 square inches while taking 7.2" of the top edge of the board and placing all of the connectors along the top.

SCAN CHAIN SKEW

Andy explained that he chose to avoid scan chain NPCS to SCK skew by stopping SCK before asserting (high) NPCS (and presumably not starting SCK until falling NPCS has had a reasonable time to settle). This is one of two solutions discussed in cdxsys3- Scan Chain- Scan Chain Controller. The other solution is for the scan chain controller to toggle NPCS only on the falling (inactive) edge of SCK.

The approach that Andy chose affords essentially infinite skew margin, because the controller can wait for an arbitrarily long time after stopping SCK before asserting NPCS and after disasserting NPCS before restarting SCK. However, any devices on the scan chain that have a synchronous parallel load will not function in this architecture, because they need at least one SCK to occur after NPCS has been asserted.

Both the '597 and '595 have asynchronous parallel load and, therefore, don't need an SCK after NPCS asserts. The analysis in cdxsys3 presents only the 'HC166 as an example of a synchronous parallel loading device. It has become clear that the '597 and '595 are readily available and we won't need other simple registers. However, asynchronous loading may not be feasible in all synthesized scan chain register situations. For example, the 7032 PLD proposed for the RPM's shear and y-valve controller (see cdxsys7) has a single global clock, which is driven by SCK. It also provides a global clear that is independent of the clock, i.e. it is asynchronous, but not a global load. It appears that the only way to effect a parallel load is to use NPCS to steer the data toward the latch, which is strobed by the global clock. Andy is going to review this entire PLD design and may be able to suggest alternatives.

Andy identified an error in the skew analysis presented in cdxsys3, which examines the possibility NPCS to SCK skew but explains that the situation with serial data is different, arguing that the data comes from an adjacent register rather than from the scan chain controller. This isn't true for the first output register in the scan chain. Dave R and I both expressed the opinion that the controller should change data on the falling edge of SCK. Dave said that he thought that this was the case in his original design. I explained that I had originally brought up the issue of skew because of Dave's Word document drawing that appeared to have NPCS changing on the rising edge of SCK. I did not consider data skew at that time.

SENSE REGISTER

Andy asked whether the "sense" register described in the CD3200R Flow Panel Processor (FPM) Board Hardware Design Description should be implemented on the MSM. It should not be. The sense facility assists bubble detection, part of the fluid control domain, which is the responsibility of the APU.

Although the sense facility is not part of the MSM, it is important to the APU and its requirements need to be clarified. Dave R mentioned that the reference document is fairly old and does not necessarily agree with more recent analysis. The two sense address registers are consistent with more recent requirements but the detection and control means are not. Instead of simply recording whether a change has occurred from one 132 usec. scan period to the next, the Boolean value of the monitored bit needs to be sampled and counted. The rationale for this requirement is described in implementation report 18 (report18.doc) as follows:

"[In the APU system, the] hardware assist only needs to record any single transition to conclude that the signal is not stable. But for bubble detection it needs to record the number of 0 samples and the number of 1 samples. These are two different functions. In AD16 – Observe and Watch Commands – Hardware Assist for Observe, I suggested a hardware trace function to reveal the pattern of bubbles while Jack advocated a change detector (based on XOR between each sample and the next). The single change function serves the stable state filter but not the bubble detector. However, the trace consumes significant hardware and software (to analyze the trace) to generate a picture that is more detailed than necessary. It would be much better for the hardware to count 1s and 0s on the two monitored sensors. If this is possible then it is all that is needed for both bubble and stable state detection."

The FPGA needs to provide two event counters for each of the two monitored sensors. Software needs to be able to both read and clear the counters.

MOTOR PAGE FLIP AND SCAN CHAIN INTERRUPT

Andy asked for suggestions on how the stepper controller should tell the CPU when it has finished executing one of the two step script pages. This is described in motor.doc- Design- Firmware as follows:

"The two microcode programs will both be located on page boundaries. When ecp reaches 0xxxFF, the current program is exhausted and the next one should be started. If the next one is the later one in memory, ecp could simply keep incrementing. However, if it is the lower one, then one or more of ecp's bits higher than 7 must be changed. In all cases, ep must be changed to point to the other program's event array. At the program change, the FPGA should interrupt the microprocessor and present an appropriate (i.e. different from any error codes) value in the status register. This will alert the microprocessor to the availability of the memory occupied by the exhausted program. It could be helpful if the status code would indicate which memory buffer, lower or upper were being made available, but the microprocessor can also keep track of this itself."

This brings up the related topic of scan chain interrupt, discussed in cdxsys7. This interrupt is not related to the motor scan chain and may only be relevant to the APU in practice. However, it should be included in the MSM's I/O scan chain definition for possible future application. As explained in cdxsys7- Scan Chain Interrupt, sequential access to one location on the scan chain may be necessary for communicating with intelligent agents, such as the VPM. To avoid overwrite, the CPU is synchronized to the scan period via an interrupt from the scan chain controller.

The page flip reference cited above implies that the FPGA has one interrupt connection to the CPU and that the CPU has to read a status register in the FPGA in order to determine the cause(s). However, cdxsys7- Scan Chain Interrupt implies that the scan chain interrupt must be unique because it is nearly always active but rarely of any interest to the CPU. These are not necessarily mutually exclusive definitions. The APU and MSM CPU's each have at least two unused external IRQs. It would be possible to dedicate one of these to the scan chain interrupt and the other to all other sources, which at this point seems to be only the motor page flip. It also would be feasible to combine the scan chain interrupt with other sources, but then the FPGA would have to provide an enable bit for this to allow software to turn it off. Dave R mentioned that he had planned to provide such a bit for all interrupt sources. It probably is a good idea to follow Dave's thinking on this, as it increases system configuration options. ISR performance is only slightly degraded by having just one IRQ, so the decision to use one or two seems to hinge more on FPGA complexity considerations.

PARTITIONING

I (David McCracken) introduced my latest design report, cdxsys7, which attempts to define the Right Panel Module (RPM-- not RPMD) and Left Panel Module. Except for the Loader, these are the last of the modules that have not yet been defined sufficiently to begin implementation. John and I had decided to review CD4000 I/O requirements to try to prepare the first system to support the 4000's current mechanical requirements. These are outlined in cdxsys7- Apu, Rpm, Status Panel, and CD4000.

Cdxsys7 suggests that 26 solenoid controls be added to the 32 on the interim LPM. This was rejected by all participants. Dave R mentioned that he had received complaints about having as many as 26 on one board. JP said that solenoid failure was such a common problem on the CD4000 that each bank of eight reserves one for a spare. The new solenoids that we will be using will have detachable leads, which should go a long way toward reducing the difficulty of replacing solenoids, but Dave pointed out that driver failure would require replacing the entire board.

Andy suggested dividing the LPM into two identical modules, each with 32 solenoid controls. This simultaneously reduces the "big board" criticism while increasing instrument configuration flexibility. He also suggested that further division, e.g. into four identical boards more like the CD35/3200's CDMs, would yield diminishing returns, as each board requires two scan chain connectors, a power connector, and physical margins.

The only down side to Andy's suggestion is that we had planned to keep the strobed fluid sensor circuitry on the LPM for close proximity to two of the five sensors. The MSM is also well placed for accessing the two sensors on the left front panel, but fluid sense lies in the APU's control domain and should be on the APU's scan chain to minimize communication traffic. The fluid sensors as a group are not localized; the other three are located under the instrument, which is more accessible to the RPM. Therefore, we will move the strobed fluid sense circuitry to the RPM. The four wires from the two left front panel sensors will be routed to the RPM. This reduces the LPM to a simple block of 32 solenoid controls and 16 general inputs. It also puts all specialized I/O, except for vacuum/pressure control, on the RPM. Concentrating specialized I/O onto one board improves system flexibility by allowing the design of simpler boards to stabilize.

SOLENOIDS

During the discussion of solenoid distribution, it was revealed that there isn't one definition of solenoid driver that applies to all instruments. The CD35/3200 instruments use an all electric valve with two-stage driver. JP and Dave R described a much different situation in the CD4000, in which banks of small solenoids open pneumatic valves to actuate larger air-driven valves. This system is well known as a source of problems. The pressure/vacuum requirements are very high (JP added that the vacuum/pressure unit is a frequent source of problems), the air-driven valves often don't have enough mechanical force to pinch tubing fully closed, and the small solenoids have reliability problems. JP and Dave also described the CD1200 as having a different all-electric control means in which software apparently implements some sort of PWM-based power down, thereby eliminating power transistors, but at the expense of CPU bandwidth (according to Dave).

JP volunteered to investigate the CD1200 solenoid control means to determine its general utility. However, if Dave's estimation that it requires intensive CPU involvement is correct then it is not generally applicable. Likewise, the low-power single-stage drivers needed for the CD4000's solenoids are not applicable to all-electric valves. Only the two-stage drivers used in the CD35/3200 and interim CDNext systems afford solenoid control in all systems, albeit at some hardware expense. In the case of a CD4000-class instrument, replacing the pneumatic valves may be highly desirable. In any case, at this stage of development, flexibility is more important than relatively minor cost reductions. Therefore, for now we will continue to use the two-stage driver.

Dave R mentioned that the power transistors are vulnerable to shorting due to bending of their leads. Andy asked whether equivalent surface mount components were available. These should have no such problem. If we continue to use through-hole parts, they should be mounted on spacers designed to prevent this problem.

Andy outlined the anticipated schedule as:

1. RPMD (Right Panel Motor Driver) finished by Dec. 1.
2. MSM (Motor and Sample handler Module) finished by end of Dec.
3. VPM (Vacuum Pressure Module -- see vpm.doc) start Nov. 15; expected completion in mid-January.

John V asked the Dallas group to not do any work on the APU until the Santa Clara group has reviewed its current design status. However, since the MSM and APU share the basic scan chain design, any improvements (such as timing and component upgrading) or clarifications developed for the MSM should be folded into the APU design. The Santa Clara team will review the APU in the following areas:

1. Incorporation of improvements developed for the MSM.
2. Placement of connectors.
3. Communication interfaces.
4. FPGA configuration.
5. Bubble detection support.
6. Decimation support.
7. General design: requirements, functionality, and efficiency.
8. Range of gain control (with Mike Y).

CONCLUSIONS

1. The 75174 and 75175 differential line drivers and receivers will not be used anywhere in the system. They will be replaced by 26C31 and 26C32 in the HSSL and IML interfaces and by either these or LVDS components in the scan chains.
2. The scan chain clock rate may be doubled to 4 MHz (to be determined by Andy).
3. Motor flag inputs to the scan chain will be added to the RPMD. Two 3-pin jacks will be provided for each motor. Pin 1 is +5V. Pin 2 is the flag signal pulled up to +5V by 1K. Pin 3 is digital ground.
4. Any board that is on a scan chain and does not use one of the serial data signals, MOSI or MISO, does not need to buffer that signal. If the board contains a scan chain loopback connector that includes the unused signal then a wire loop (two wires for one signal) is sufficient. The unused signal may also be removed from a dedicated loopback interface.
5. Scan chain reset will be active high. This value will be established as soon as power is applied to the system and will not be removed except under software control.
6. As soon as possible after power-up, the FPGA will begin operating the scan chain. There will be no means to stop scan chain operation except by turning off the system.
7. Scan chain output registers will be HC595 or synthesized by PLD/FPGA. No other components will be supported. Where the most immediate power-up control signals are required, e.g. stepper motor registers, they will be established by pullup/down resistors and the registers will be tri-stated by scan chain reset. This will also be the initial value control means used when one or more outputs must be high. Otherwise, initial outputs of 0 are established by scan chain reset (inverted on the I/O board) clearing the shift register and the first NPCS loading this into the output register.
8. Scan chain input registers will only be HC597 or synthesized by PLD/FPGA.
9. The MSM's scan chain controller will not include the input monitor "sense" capability, used for bubble and fluid edge detection. This will exist only for the APU.
10. Both the APU and MSM FPGAs will provide a means to interrupt their respective CPUs at the end of each scan (chain) period. The MSM FPGA will also generate an interrupt when the motor controller finishes executing one event page. Whether one or two IRQs are used and the exact configuration control means within the FPGAs have not yet been determined.
11. The strobed fluid sensor circuitry will be implemented on the RPM.
12. The LPM will contain 32 solenoid drivers and 16 inputs. A CD3200-class instrument will use one LPM; a CD4000 will use two. Each solenoid driver will comprise the two-stage design, which consumes two MOSI output bits, one for on/off and the other for high-power control. Each input will comprise a standard 3-pin jack (+5V, 10K pullup, digital ground) and will consume on MISO input bit.

CDNEXT ANALYZER SYSTEM DESIGN REPORT 11

Nov. 24, 1999

[Report10]

[Report12]

• Design History File Change.
• Comments On Cdxsys10 (11/9/99 design meeting minutes originally published as ad47).
• I/O Scan Counter.

DESIGN HISTORY FILE CHANGE

Our project plan specifies that reports cannot be edited once they have been published unless clearly identified as unfinished. I have had to bend this rule for the system/hardware design meeting reports. I had published them as documents AD45, AD46, and AD47 because all of our previous meetings were reported under this series; but all of the other meetings were for software design. I had been publishing system/hardware design and implementation reports under the CDXSYS series of documents and none of those were meeting minutes.

Organizing reports by whether they involve a meeting is inappropriate, especially since, although some of us are involved in both software and hardware, others work on strictly hardware or software. Therefore, I have moved the system/hardware meeting minutes into the cdxsys series, renaming AD45, AD46, and AD47 to cdxsys8, cdxsys9, and cdxsys10. I modified the original reports only to tell their new file name and their origin. All substantive text is unchanged.

To recap the file organization: all design files are stored under the project server directory K:\cdx\doc where K is mapped to \\eisscd32\cd3200. The system-hardware-software design files are located in k:\cdx\doc\analyzer. The files are:

1. ADxx are software design meeting minutes. These are concatenated into aswmin.doc, which contains only the minutes and conclusions; and aswdes.doc, which includes only conclusions and tasks.
2. REPORTxx are software implementation reports. These are concatenated into reports.doc.
3. CDXSYSxx are system/hardware design and implementation reports. These are concatenated into cdxsys.doc without venue and task text.
4. Some specific design topic documents are not included in the regular file series. They have been included in the concatenated report files. Those related to system/hardware design are:

1. motor.doc describes the design for the new stepper motor control system that we are implementing on the MSM.
2. cdx32io lists CD3200 I/O organized by subsystems that would be appropriate for CDNext, i.e. to create a CD3200-class instrument using CDNext hardware and software.

COMMENTS ON CDXSYS10

Cdxsys10, originally published as ad47, reports on the system/hardware design meeting of 11/9/99 at ADD. After reviewing this and cdxsys7, a supporting document introduced at the meeting, we have had some follow-up discussions.

1. J.P. Y wanted to clarify the solenoid and driver reliability issues involving the CD4000 discussed in topic 3.2: RPM- Solenoids.

1. The solenoid drivers have been reliable and fail only when splashed due to broken fluid connections. While not directly affecting hardware or software design, this possibility should be pointed out for mechanical design improvement in the form of splashguards.
2. The small air control solenoids have a reliability problem. This is in addition to the problem, reported by J.P. and Dave R, that the air actuators are not always strong enough to fully pinch the tubing.

2. Regarding the problem of solenoid high-voltage driver transistors shorting to each other due to bending of their legs, Andy reports that he is searching for surface mount replacements.
3. Andy reports that red LEDs are usually not used, particularly in products destined for Japan, because red indicates something bad. He wants to know if we really need the solenoid driver indicators, and, if so, whether another color can be used. The indicators are very helpful for software development and probably for field service, so I think that we should continue using them. They can be any color, but it would be helpful if the intensity difference between high and low power were more pronounced. Perhaps a different color could improve this as well as assuage concerns about the negative connotation of red. However, since these are only seen by field service and not the customer, I don't think that the generally negative perception of red is a problem. John V may be able to suggest someone either in marketing or field service to help us to determine how best to proceed.
4. Andy made the following comments regarding the shear/y-valve proposal presented in cdxsys7:

1. The proposal tallied the PLD input pin count requirement as 23, while the actual total is 19. As Andy points out, this means that the 7032 could accommodate configuration pins for all control sections, whereas the proposed design had to leave the YV0 controller permanently enabled. Left over pins might be used to restore enable controls to the 293 and 298, which the design proposal had removed from the interim design.
2. Regarding the restoration of 293 and 298 enables, I (David) don't think that these are needed, because the controller can achieve the same result by assigning both polarity controls the same value. It would seem that enable control could be useful only if it were to operate directly from a power-on reset, providing more reliable motor disabling. However, if the PLD outputs power up in known states then this is equally reliable, as the polarity controls would automatically assume the same value.
3. Andy suggested changing the 7032 to a 7064 to provide the resources for implementing the strobed fluid sensor circuitry that we had decided to move from the LPM to the RPM. This change would simultaneously yield a cleaner (fewer components and less board space) implementation while according the shear/y-valve controller some margin for design changes (even with the pin count correction, the controller proposal left the 7032 very nearly 100% utilized). I agree with this suggestion.

5. Andy has researched the LVDS vs. 26c32/31 drivers and receivers and found that the LVDS components are not only considerably more expensive (e.g. $1.90 vs. $.50) but also require 3V, which the system design does not provide. Clearly, the 26c components with RS422 signal levels represent the better approach.
6. Andy suggested (and I agree) that the 26c components can support doubling the scan chain rate as I suggested in cdxsys10. It is my opinion that we do this now before any new boards are made. Not only would this improve overall performance now but also lay the foundation for a future increase in the MSM motor controller count to support the CD4000 hardware without having to provide another sub-system to control the three right panel peristaltic pumps.
7. Andy has investigated the possibility of a replacement for the L298 and or 3717 that would, like the L293D and 3717, contain integral recirculation diodes, but would contain two full bridges, like the L298 and L293. He reports that STMicro is working on an improved 3717 but is not yet sampling. We will continue to watch for this part but not design for it at this time.

I/O SCAN COUNTER

In cdxsys10- Motor Page Flip And Scan Chain Interrupt, I suggested that software needs an interrupt (that it can dynamically enable and disable) from the I/O scan chain controllers that asserts (if enabled) after each scan. This will be used to support sequential writing to one location for communicating with an intelligent unit on the scan chain. It might also be used to support randomly related devices, where one device should be written at any time prior to another, for example to set a voltage level before turning a device on. However, this situation is difficult for the Interrupt Service Routine, because there may be several of these relationships pending at any given time and it is difficult to tell generally which ones can be consolidated into a single scan.

For software, it would be simpler to be able to track the scan controller at a higher level than the interrupt. The most straightforward means of achieving this is for the scan chain controller to count scans in a register that the program can read. To be sure that a write is completed before another is effected, the program can perform the first write, read the scan count, and perform the second write only when the count changes.

If the scan chain rate were approximately doubled (the NPCS high period would not necessarily be reduced by doubling the scan rate) the 64-bit MSM I/O scan chain period would be 18 to 20 usecs and the 256-bit APU scan period 66 to 68 usecs. Currently, the APU worst-case main loop period is 45 msec, but the MSM is unlikely to experience any period longer than 2 msec. It is important that the scan counter not roll over during the APU's main loop period. This would dictate that the maximum count be at least 680. Ten bits would provide 1024.

The I/O scan chain interrupt is required. The scan chain counter is only a convenience, which may simplify software and flow scripts, and should, therefore, be included (in both the MSM and APU I/O scan chain controllers) only if it doesn't impinge on essential FPGA functions.

CDNEXT ANALYZER SYSTEM DESIGN REPORT 12

Nov. 30, 1999

[Report11]

[Report13]

Mike Y (edited by David McCracken)

Synopsis: CDNEXT-APU analyzer APU3 board design review. MEETING MINUTES.

John V, Mike Y, Dave R, David McCracken.

DISCUSSIONS

Introduction

Due to the APU3 board being an experimental platform, there are no formal design specifications to date. Many of the circuits were not well characterized before the board was designed, so formal performance specifications would not be benificial. Initial testing of the APU3 shows the performance to be very good and the next step is to gather data through the board.

There have been many concepts for using a single general purpose "APU" like board for a number of machine platforms. The APU3 board was designed with 7 parameters of high speed linear data acquisition with 4 decade accuracy suitable for any of our optical data. An 8th. parameter is intended for bandwidth limited data acquisition such as an impedance channel. The APU board is intended to functionally replace the CPU/DCM, MAM and SPM boards in a CD3200. Relative to a CD4000, the APU board functionally replaces the CPU, DACM, OSPM1, OSPM2, ITSPM and ADCM boards. The APU3 is designed to have 3 Photodiode signals come in on 1 connector, 4 PMT signals on another connector and 1 impedance signal on a 3rd connector.

Both the CD3200 and CD4000 are desired platforms to gather data on for the APU. However, the preamps for the CD3200 and CD4000 have very different architectures, the CD3200 has fixed gain preamps and the CD4000 preamps have wide adjustable gain range. The CD3200 implements its adjustable gain of x1, x2, x4, and x8 on the MAM board. The purpose of this meeting is to determine the best configuration of the preamps, adjustable gain, and connectors on the APU board.

The initial discussions were where to place the adjustable gain. It was agreed that the APU board would only be implemented in new factory built machines, therefore no field compatibility should be considered. At this point it is decided that adjustable gain will be implemented at the preamp board level.

Separate Photodiode preamps or schemes to consolidate them are discussed. The CD4000 uses a bullseye detector has both forward scatter detectors very close to each other whereas the CD3200 uses a beamsplitter and 2 separate detectors several inches apart. It is decided that due to the fact that the gains are all different in all the detectors that there is no advantage to having a universal preamp to be used in each channel. It was decided that a Photodiode preamp consolidated with 3 channels will be designed. The second CD3200 forward scatter photodiode will wired to the 3-channel preamp. The extra channel will be de-populated if it is not used.

Regarding the PMT preamps, David McCracken and John V were initially in favor of keeping all the preamps as universal and separate due to the added flexibility and ease of stocking spare parts for field service. Mike Y pointed out that there would be changes to the existing CD4000 PMT preamps such as interface voltages and readback voltages. The CD3200 preamp could not be used because it is a fixed gain design. It was decided that 3 PMT preamps circuits would be consolidated onto one board.

With the previous decisions, there is no need to revise the APU3 at this time.

David McCracken’s group will be ready to acquire data in 6 weeks, it will take Dave R 2-3 weeks to get the data acquisition state machines running. Due to Robert D’ groups tight schedule, it was decided to initially use adapter boards to connect the APU3 to existing CD3200 and CD4000 preamps for initial data acquisition.

CONCLUSIONS

1. There is no need to revise the APU3 PCB at this time. Some rework will need to be done.
2. New PMT preamps will be designed consolidating 3 channels on 1 board implementing wide gain range.
3. New Photodiode preamps will be designed consolidating 3 channels on 1 board, also with adjustable gain.
4. Adapter boards will be used to connect the APU3 to the CD3200 and CD4000 benches for initial testing.

CDNEXT ANALYZER SYSTEM DESIGN REPORT 13

Dec. 9, 1999

[Report12]

[Report14]

Synopsis: APU system hardware analysis. VPM ADC Control.

VPM ADC CONTROL

DISCUSSION (via Email)

James C (Coleman) R; 12/08/99 10:41 AM:

Since the APU scan chain description does not include any interface

between the APU and ADC on the VPM Board, I have some questions.

(1) The ADC needs to be programmed at power up for the conversion

rate (fast or slow). Should the APU do this, or should the FPGA

on the VPM do this. If the FPGA does it, what should it program

it for - fast or slow?

(2) The ADC can return data for self-test voltages (Vref). Should the

FPGA read this data, and if so what should it do with it?

(3) The ADC has a command for Software power down. Is this mode

planned to be used, and if so how is this to be controlled?

(4) The ADC can be operated in two distinct modes: normal sampling

mode (fixed sampling time) and extended sampling mode

(flexible sampling time). Is the extended sampling mode

planned to be used, and if so how is this to be controlled?

David McCracken; 12/9/99 10AM-PST.

Reviewing the data sheet for the TLV1548 and our VPM requirements, I have the following observations and suggestions:

1. There is no accuracy penalty for fast vs. slow conversion; only an insignificant power penalty (1.5mA vs. 1mA). At this point it doesn't seem that we would need the faster (7 usec. vs. 15 usec.) conversion time, but our requirements in this regard might change. In any case, we certainly don't care about a .5 mA difference, so I think that we should program for the fast conversion. If one or the other were a default then I would say use that to avoid complications, but the data sheet seems quite adamant about the need to set the rate. The APU doesn't need to control this and I think that the interface for it do so would be more complicated than just having the FPGA do it.
2. Regarding the three self-test voltages, I think that these could be useful but at a much higher level than the FPGA. I think that we could extend the design suggested in VPM.DOC by using a scan chain command similar to echo. Three commands could be defined to cause a selected reference to be output onto the MISO serial register. The ADC control machine would continuously read all 11 channels and, if one of these commands is active, assign the value of the selected channel to the output register. In reviewing this, I noticed that the Scan Chain Interface diagram in VPM.DOC neglects to show the echo command as one possible source feeding the output register, as described in item 2 of Structure and Behavior. This was just an oversight. If we can add the ability to read the reference channels then each of these channels would also serve as another possible source.
3. We don't need power down.
4. Regarding normal vs. extended sampling modes, normal is simpler, allowing CSTART to be permanently held high while the clock and CS do all of the work. The TLV1548 data sheet suggests that extended sampling mode be used for "a wide range of input source impedances," by which I think they mean relatively high impedance sources that can't meet the input capacitance charging time requirements. The analog input capacitance is a rather high 55 pF (max). At the end of the data sheet is a detailed analysis of input charge time requirements, which I think is important unless the op amp outputs are less than 100 Ohm (maximum input channel resistance is 1K, so a 100 Ohm source would provide 90% of the theoretically fastest charging time). If there is any problem in our circuit, I would favor reducing the ADC clock rate to increase the sampling time, as this would achieve the same result without adding any complexity to the interface.

THE DOCUMENTS AFTER THIS POINT ARE NOT YET INCLUDED IN THE INDEX

SYSTEM DESIGN REPORT 14

2/17/2000

[Report13]

[Report15]

• [Documentation And Hyperlinks].
• [MSM]
• [Scan Chain Rate]
• [Number Of Supported Motors]
• [NPCS High]
• [Event Memory]
• [Bus Mastering]
• [Msm Tower I/O]
• [Led Driver]
• [Door Release]
• [Spinner Motor]
• [Loader Connector]
• [Motor Winding Test]
• [Msm Dma]
• [Master And Slave Communication Interfaces]
• [Msm Conclusions]
• [Right Panel Module]
• [Coordinated Efforts]
• [Scan Chain]
• [Pld]
• [Shear Valve And Y-Valve Controller]
• [Strobed Fluid Sensors]
• [Left Panel Module]
• [RPMD]

DISCUSSIONS

Coleman and Maha reported wading through the 80 plus pages of cdxsys to get up to speed on their new assignments. I (David) committed to adding an index to the document and hyperlinks for new reports. As the first step in hyperlinking, I created links at the beginning of cdxsys to each of the reports. Clicking on one of these takes you to the named report. This is not particularly useful for users but helps a lot when adding hyperlinks to topics, because these links afford faster navigation to and from the general reference areas.

Robert described hyperlinks as specially formatted text that, when clicked on, move the viewer to the selected topic. He mentioned underlining and font change as one kind of formatting. I'm using a slightly different format, underlining plus square brackets with no font change, because MS Word seems to like to change the font when the text is cut and pasted. If the font is the same as surrounding text, Word does this less often.

Especially valuable is being able to retrace the links back to your starting point by clicking the web link arrows. You can't do this unless Word's web toolbar is exposed. To do this, open Tools-Customize-Toolbars and put a checkmark in the Web checkbox.

SCAN CHAIN RATE

System design report 11 topic Comments on cdxsys10 item 6 reports Andy's conclusion that David's request to double all scan chain rates (I/O and motor) from 2MHz to 4 MHz [Cdxsys.doc-ScanChain4MHz] can be easily achieved with the 26C series line drivers and receivers. This change will be implemented immediately because it potentially affects nearly every subsystem.

NUMBER OF SUPPORTED MOTORS

Stepper Motor Controller Proposal (motor.doc) requirements specify that 14 motors will be supported by the MSM [Cdxsys.doc-MotorRequirements]. David's request to double the motor scan chain rate did not include immediately increasing the number of supported motors, but only to avoid delaying the design schedule.

Coleman suggested that, as the schedule has already slipped due to personnel changes, the time required to increase the motor count would not be significant. System design report 7 topic Apu, Rpm, Status Panel, And Cd4000 enumerates the 17 motors used in the CD4000 [Cdxsys.doc-CD4000Motors]. It is not clear that all 17 would be used in an alternate version of a CD4000-class instrument, but it is possible that more advanced instruments will require even more motors.

With the 32 usec. step resolution and keeping at least 4 usec. for the NPCS high time (see report 3 topic Scan Chain Operation [Cdxsys.doc-NPCS]), the maximum number of motors that can be supported is 28. This is much more than we anticipate using in the near future. David arbitrarily suggested supporting 20.

In addition to the faster scan chain shift rate, increasing the motor count requires increasing the FPGA's scan chain register length. If the number of simultaneously-driven motors were to increase, the size of event memory (not event count memory-- see motor.doc [Cdxsys.doc-MotorEvent]) would have to increase, as would the size of the event counter. In the original 14-count design, only 14 events could occur in any single 32 usec period, requiring only a 4-bit event counter [Cdxsys.doc-MotorEventCounter]. If all motors were to step at their fastest rate one (of two) event arrays would consume 3,584 bytes. Increasing the number of simultaneously-driven motors to 20 would require a 5-bit event counter and 5,120 bytes in each of the two event arrays. The event array pointer would require 13 active bits (plus a static base address). Even at 14 motors, the event arrays are too large for implementing in the FPGA and are, instead, implemented by a portion of main memory. Thus, supporting 20 simultaneous motors only increases the event counter by one bit and the event array pointers by 1 or 2 bits. If all 20 motors stepped in one period, the FPGA would have to read 20 events. Andy's design specified reading the events (as many as 14) during the 4 usec NPCS high period. Increasing this to 20 could create problems, but a very simple solution is to increase the NPCS high time for motors.

In the current systems, no more than seven motors are simultaneously active. However, given the modest FPGA resources needed to support 20, it seems unreasonable to enforce such a limit in the basic design. The CPU may have difficulty meeting the requirements of 20 motors, but, if so, this may be resolved by specifying a combinational limit, like a transistor's SOA, i.e. a maximum amount of step activity that may be apportioned as more motors at slower rates or fewer motors at faster rates.

NPCS HIGH

The original scan chain design specifies 4 usec. NPCS high period with a 2 MHz. clock. Changing the clock to 4 MHz. brings up the question of what to do about the NPCS high period. The VPM proposal (vpm.doc) specifies several tasks that have to occur during VPM high [Cdxsys.doc-VPMNPCS]. System design report 2 explains how a DSP could be used as the VPM controller [Cdxsys.doc-DspVpm]. In this approach, the DSP, interrupted by NPCS going high, performs these tasks in software. The suggested design requires at least 3 usec. Whether this VPM approach is implemented or not (Coleman was working on an FPGA version but has been rotated into the more important MSM job) it is reasonable to continue to provide sufficient NPCS high time for this sort of scan chain intelligence. Therefore, the 4 usec. NPCS high time will be retained even though the serial shift period changes from 128 usec. to 64 usec.

For the motor scan chain, a longer NPCS high time may be even more important than for the I/O scan chain in order to support reading as many as 20 events during one period. Therefore, the motor scan chain NPCS high time will be as long as possible, depending on the number of bits in the chain. An 80-bit chain supports 20 motors. This shifts in 20 usec, leaving 12 usec. for NPCS high. If a feedback register is implemented (see System Design Report 4 topic Missing Motors [Cdxsys.doc-MotorScanChainFeedback]), the resulting 88-bit chain shifts in 22 usec, leaving 10 usec. for NPCS high.

EVENT MEMORY

As explained in System Design Report 3 topic Msm Motor Controller Bus Mastering [Cdxsys.doc-BusMasterLockout], the worst case delay for the FPGA to gain control of the bus is 1.88 usec. Assuming that it reads the shared memory in a burst and that the cycle time is 80 nsec, 20 event bytes could be read in 1.6 usec. Even with the old 4 usec. NPCS high, the FPGA could read the events with all motors changing in one 32 usec. step period. Andy's plan to read the events during NPCS high is still valid. Andy's design includes implementing the two 256-byte event count arrays in the FPGA. If this was proposed out of concern for timing in the NPCS high period, it should be revisited. With a 12 usec. NPCS high period, the FPGA has more than enough time to read the event count and 20 events. Moving the 512 bytes from the FPGA to main RAM would steal a small amount of bus time from the CPU but this would not be significant and might significantly reduce the size and cost of the FPGA.

BUS MASTERING

Coleman reported that Andy had not yet designed the means by which the FPGA reads the event memory, which requires that it assume the role of bus master.

A major issue is how the FPGA gains control of the memory interface, which is normally controlled by the CPU. In particular, we were concerned about which CPU signals become high-impedance when the CPU grants the bus. The only ones that don't are the chip selects, CS0 through CS3. All address, data, RW, and AS go to high impedance. See MC68340 User's Manual section 3-6 Bus Arbitration (p. 3-40), Fig. 3-24 Bus Arbitration Timing (p. 3-42), and Table 2-5 Signal Summary (p. 2-14). Motorola documentation doesn't say what levels (high or low) the CS signals assume when the CPU grants the bus, but Motorola tech support told us (Service Request Number 1-98LP answered by Cindy.Barham@motorola.com 9/27/99) that they would be high (inactive). Consequently, the FPGA only needs to control the one that selects RAM.

The new MSM schematic includes no FPGA but the FPM and APU schematics indicate that all CPU data and nearly all address signals are connected to the FPGA. The standard chip select usage that we have followed is CS0 selects flash, CS1 RAM, and CS2 or CS3 selects I/O. It is useful during development to be able to access RAM and flash even if the FPGA is not programmed. This has been provided through a GAL in the previous designs; continuing to support is desirable. However, with the addition of the serial EPROM configurator, this is not essential, as it was when the CPU had to program the FPGA itself.

The original motor controller proposal doesn't specify whether the FPGA should read shared memory as bytes or as words. Clearly, the latter would use the bus more efficiently, which would benefit the CPU, but it would be more difficult for the FPGA. If the additional complexity is not too severe, reading words would be preferable.

MSM TOWER I/O

System Design Report 4 topic MSM - Tower suggests that the I/O from the interim tower board is to be merged with into MSM as direct I/O from the MSM board [Cdxsys.doc-MsmTower]. Coleman asked for clarification regarding the means of providing this. There are three possibilities. The I/O could be provided directly by FPGA pins; it could be provided by discrete parallel registers mapped into the CPU's I/O space; or it could be provided by local (on the MSM board) serial registers mapped into the MSM's I/O scan chain. An I/O scan chain must be implemented in order to support the loader, which remains a separate board, so this solution would entail only increasing the chain length.

The scan chain solution uses the fewest FPGA pins but the most internal resources (for the additional chain register length). The FPGA direct pin solution uses the most FPGA pins but relatively few internal resources. The parallel registers solution uses relatively few FPGA resources but consumes the most board space.

LED DRIVER

Coleman questioned the complexity of the LED driver inherited from the old FPM. Apparently the LM339 comparator was used instead of a simple transistor because a spare was available from the DC motor current fault detectors. This is still the case. However, the voltage divider used to provide the reference level is not needed. Any level between 1 and 3 volts would work and this is already available in the divider used for either of the motor current detectors. The reference should be shared.

Coleman also asked about the source of the "wink" signal. This is basically a visible watchdog, which the CPU toggles periodically to announce that it is alive. It can be mapped onto the I/O scan chain or any other I/O that the CPU can write to. An appropriate control would be one of the Port A pins, as the CPU can control this even if the FPGA is not functioning.

DOOR RELEASE

The MSM schematic sheet 3 shows a 12K base resistor connected to the TIP125. As pointed out by Maha for the LPM, this should be replaced by 2.7K. Also, as David pointed out for the LPM's solenoid drivers, the ULN2003 inputs should initialize to low values to avoid turning on (at high power) the solenoids.

SPINNER MOTOR

Report 4 explains that both a DC motor driver and a stepper are to be provided for the tube spinner [Cdxsys.doc-SpinnerMotor]. The new MSM circuit incorporates a DC spinner motor driver circuit from the interim design. This design was examined in report 7 topic Right Panel Module - Interim Design Errors, which concludes that the under-current detector is unusable in concept and should be discarded [Cdxsys.doc-MotorUnderCurrent].

The over-current detector is not implemented correctly. The reference voltage at pin 7 of U9 LM339 should be set to match the 2 volts developed at the 1 Ohm sense resistor (note that U11 L293E pins 4 and 7 are supposed to be tied together-- this isn't clear in the schematic) at the maximum 2A output. The circuit shown develops a 3.3V reference, i.e. 3.3A over-current threshold. The 2A maximum output current is specified for the L293E as non-repetitive t = 5msec, so the 3.3A threshold is clearly useless. SGS application notes suggest approximately 0.7% positive feedback around the comparator. This is probably not necessary, but we might want to consider it. Without a feedback resistor, the reference divider should be 6.8K to +5 and 4.7K to digital ground (this 2V reference can also provide the LED driver threshold). Note that MTR_OVR is active low, i.e. logic 0 signifies over-current.

The motor control signaling is inefficient, using three lines when two would suffice. The MTR_CW and NMTR_CW, which should be renamed MTR_CCW, can both be taken high or low to stop. These should be translated to ON and CW signals in the MOSI scan chain (or other direct output control means) by the following equations:

MTR_CW = ON & CW

MTR_CCW = ON & /CW

With positive logic, these equations make both signal low/0 if ON is false. MTR_CW and MTR_CCW should initialize to both low or both high to avoid running the motor at system startup.

LOADER CONNECTOR

System Design Report 4 topic MSM - Mechanical Requirements suggests that two connectors be provided on the MSM for the motor and I/O scan chains to connect to the DB37 loader connector [Cdxsys.doc-MsmLoaderConnector]. Coleman question the rationale for using two instead of one larger connector. Robert added that manufacturing would normally prefer a single connector. No rationale was offered in report 4 but it may be preferable to use two connectors, a 14-pin and a 10-pin, that are used throughout the system, than one unique part. It would be appropriate for Robert to decide this.

MOTOR WINDING TEST

System Design Report 4 topic MSM - Motor Winding Test [Cdxsys.doc-MotorWindingTest] reviews the various options and suggests essentially duplicating the old MPM circuit. David asked that this analysis be reviewed by an analog engineer. Robert offered Ed Sewell's assistance.

MSM DMA

As suggested in System Design Report 2 topic Motor Control, Tower, and Loader [Cdxsys.doc-MsmDma], DMA2 will be used for transmit data to the master (APU) and DMA1 for receive data from the master. CPU TxRdyA pin 83 will be connected to CPU DREQ2 pin 96. CPU RxRdyA pin 82 will be connected to CPU DREQ1 pin 93.

MASTER AND SLAVE COMMUNICATION INTERFACES

The MSM's slave communication connects to the RS232 barcode reader. It does not change from the interim design.

The MSM's master (to APU) communication connector will be identical to the APU's master (to Data Station) connector. The interface circuitry shown on sheet 3 must be changed to match the signals of the APU (see APU rev. 21 sheet 4). However, 26C drivers and receivers should be used (and, therefore, only terminator resistors are required). The interim APU's slave (to MSM) communication connector will be rewired to mimic the Data Station (as well as changes in the treatment of PRST and Clock).

System Design Report 5 topic Scan Chain Topology - End Board [Cdxsys.doc-EndBoard] describes optional SCK, PRST, and NPCS termination on scan chain boards that may optionally serve as end boards. Similar treatment will be accorded the high-speed serial link (HSSL or Inter-Module Link). The APU will require optional (instead of permanent) terminators for the master's clock and PRST signals. However, the MSM will use permanent terminators, because it must be the end of the IML, as its slave is not IML-compatible.

Sheet 3 of the MSM schematic also shows 10K pullups at the data inputs to the line driver. These should not be necessary.

MSM CONCLUSIONS

• All scan chains (I/O and motor) will shift at 4 MHz.
• 20 motors will be supported, with sufficient FPGA and memory resources for all to simultaneously step at the maximum rate, including the following:
• The event counter (count in each event count array element and counter used to iterate through the event list for one 32 usec. period) will comprise 5 bits.
• Each event page (of two) will comprise 5120 (20 * 256) bytes.
• The motor MOSI output and MISO input registers will each comprise 80 bits.
• The scan chain cycle will be composed of a 20 usec. shift period, during which NPCS is low, followed by a 12 usec. NPCS high period.
• During NPCS high, the event count for the next 32 usec. step time and as many as 20 events will be read and the MOSI register directly programmed (from the event data).
• The 10,240 bytes of event memory will be implemented in main RAM, which the FPGA accesses by becoming a bus master.
• The 512 bytes of event count memory may be implemented in main RAM or in the FPGA.
• To become the bus master, the FPGA arbitrates with the CPU. After becoming bus master, the FPGA performs all reads necessary for one step time in a burst. The FPGA must control the RAM chip select, CS1. When relinquishing the bus, the CPU drives all of its CS outputs to logic highs, deselecting the devices. Therefore, the FPGA does not have to control the other CS signals.
• The FPGA may read shared main memory as bytes or words, but words are preferred if they can reduce bus time. Since the FPGA retains bus mastership until it has completed all reads for one step time, if reading words can't reduce the overall execution time of scan chain programming then it is no better than reading bytes.
• Tower I/O signal means is at Coleman's discretion to choose any of three possible mechanisms: local scan chain, parallel registers, or dedicated FPGA pins.
• The LED driver will continue to be an unused LM339 section, but the reference voltage will be shared with the spinner motor over-current detector, which also uses a section of the LM339.
• The spinner motor under-current detector is eliminated and the over-current reference corrected as specified.
• The spinner motor control signals will be reduced from three to two as specified.
• The Door Release high voltage transistor base resistor will be changed to 2.7K.
• All output drivers will initialize to off states.
• Robert D will determine whether to use one 10-pin and one 14-pin or one larger connector for the Loader connector (on the MSM board).
• Ed Sewell will review the motor winding test circuit.
• DMA2 will be used for transmit data to the master and DMA1 for receive.
• The master (to APU) communication connector will be configured the same as the APU's master (to data station) communication connector. The differential clock (TXClk from master) and PRST signals will have permanent terminator resistors (the APU will have removable terminators).
• Resistors on data inputs to line drivers will be deleted.
• The second UART channel will be as designed for the FPM, an RS232 interface to the barcode reader.

RIGHT PANEL MODULE

COORDINATED EFFORTS

Maha and Jack have been independently preparing updated versions of the RPM, particularly focussing on the Shear Valve and Y Valve controls. For Jack this has primarily been an exercise to gain familiarity with the Altera tools. He has also been able to show that design proposed in System Design Report 7 topic Right Panel Module - Shear Valve And Y-Valve Controller [Cdxsys.doc-ShearValveController] consumes more internal resources than a 7032 has to offer. For her part, Maha has reviewed the same design, improved signal naming, and corrected errors in the design description. Simultaneously, she has been correcting the LPM, which shares a number of circuit elements with the RPM. Going forward with this, we want to be sure that Jack and Maha coordinate their efforts.

Maha is using Verilog for logic design, Jack AHDL, and Coleman VHDL. Jack says he would be happy using Verilog, but we may not have the tools for this in Santa Clara. Robert D may have some suggestions about how to coordinate, as he has experience managing eclectic environments. One that we can all agree on immediately is to use the improved signal naming (and corrections) suggest by Maha.

SCAN CHAIN

Jack presented his RPM block diagram, which emphasizes the scan chain. This format is particularly useful for interfacing to software, which needs to know the bit address of all I/O.

Jack's diagram shows the interim RPM, which doesn't separate the input and output legs of the scan chain. As explained in report 5 topic Scan Chain Topology [Cdxsys.doc-InterimScanChain], this inefficient topology will be replaced by one in which all output registers occur in the MOSI leg and all input registers in the MISO. The two legs connect at the end of the MOSI leg, which loops back through the MISO. U33, the one input register on the RPM, will be folded into the PLD. It is important not to duplicate the interim topology in the new design.

Jack's diagram suggests that the PLD is the end of the APU scan chain, with the internal output (MOSI) register feeding into the input (MISO) register, whose output goes to the APU. As shown in the Intermodule Communication Diagram [Modules.doc] the RPM will have a standard connection to the APU, followed by a loopback connection to the status board, followed by a standard connection to the LPM. This is also described in report 5 topic Scan Chain Topology - I/O Boards [Cdxsys.doc-IntermoduleCommunication]. See report 3 topic Scan Chain Stream Connections [Cdxsys.doc-ScanChainStream] for a description of the different kinds of connections. System Design Report 7 topic APU Connectors [Cdxsys.doc-ApuStatusConnector] discusses improving cabling flexibility by including the Status Board loopback connector on the APU instead of the RPM. However, changing the APU is not currently in our schedule and we have to provide some means of connecting the Status Board.

PLD

Jack's study indicates that a 44-pin 7064 would be able to implement the proposed Shear and Y-valve controller. However, Maha reminded us that we had decided (see report 10 topic Rpm And Lpm [Cdxsys.doc-RpmLpm]) to move the strobed fluid sensor controls (see report 7 topic Left Panel Module [Cdxsys.doc-StrobedFluidSensors]) from the LPM to the RPM, for which the 44-pin 7064 would not provide enough I/O.

After briefly reviewing the strobed fluid sensor requirements, Coleman and David suggested that a 68-pin 7064 would probably provide sufficient internal as well as external resources, based on the fact that the 7032 was only one macro cell short (if logic equations are used instead of state machines) for the Shear and Y Valve controllers. Maha and Jack did not necessarily agree with this assessment. Robert mentioned that the 5 volt 7064 is considerably more expensive than the 3.3 volt version. According to Maha, Andy was considered using an Actel equivalent of the 7064 that might be cheaper. David objected to using Actel because the anti-fuse technology renders devices untestable by the manufacturer (not to mention the fact that we are continually changing our designs). David proposed looking at Cypress components. This proposal was not taken seriously, but Cypress affords several advantages at least during development. Its VHDL and Verilog tools are practically free and most of its parts can be programmed in or out of circuit. We should also consider the possibility of using the 3.3 volt Altera parts in our 5 volt system. If signal levels are acceptable, the cheapest solution may be to use an LDO linear regulator to power just the PLD.

SHEAR VALVE AND Y-VALVE CONTROLLER

Maha presented her review of the design proposed in report 7 [Cdxsys.doc-ShearValvePld]. She found and corrected the following deficiencies:

1. YVx_CCWL and YVx_CWL were renamed YVx_CCWH and YVx_CWH in the list of resource requirements and in the logic equations but not in all of the text. The correct names have H suffix to reflect the elimination of inverters.
2. The equations all include a non-existent "PRST" input. This should be replaced by the real signal PRST.
3. The names of the control signals SVx_CW (scan chain outputs) are identical to the output signals. Maha changed the control signal names to SVx_CW_REQ, i.e. SV0_CW_REQ and SV1_CW_REQ.
4. The proposed Y-Valve equations contain a number of SYxxx names. These are a typographical error. Maha replaced them with YVxxx names.

One more error, apparently overlooked by the review, is that both the Shear Valve and Y-Valve equations contain an under-current term, SVx_UC and YVx_UC. The under-current detectors have been eliminated and so should these terms.

In the original proposal, Y-valve 0 was not selectable as simple I/O, unlike the other valve sections. This was only due to a PLD pin shortage. Since the next size up affords an additional 24 pins, this limit no longer exists. Y-valve 0 should have an SV0_EN mode select input. It and Y-valve 1 will now be identical and can be described by YVx equations similar to the Shear Valve equations.

The following is a revised version of the PLD Product Terms section of report 7.

The controller logic contains two kinds of product terms, external and buried. External terms comprise motor controls and scan chain data (MOSI and MISO outputs). Buried terms comprise the scan chain shift registers and the four latched shear valve home position states, SV0_CWACK, SV0_CCWACK, SV1_CWACK, and SV1_CCWACK. These states and the four raw y-valve position inputs, YV0_CWH, YV0_CCWH, YV1_CWH, and YV1_CCWH, are latched into the 8-bit MISO register when NPCS is high. Latching may be asynchronous or synchronized on the global clock, which is driven by the scan chain's SCK. These eight signals are also used in motor control product terms. The shear valve state terms have the following equations:

The conceptual meaning of these equations is basically that if EOT and the related overtorque are both true then the shear valve has reached the CW or CCW home position. This is latched by allowing the signal to hold itself true. One caveat that applies to both the initial home event and the latched state is that they can't be true if the other home position is true. This prevents the startup EOT coming out of CW toward CCW from latching CCWACK and the EOT from CCW toward CW latching as the CWACK-- remember, EOT is not position-specific. PRST should clear both the MOSI and MISO shift registers if possible.

The 8-bit MOSI shift register outputs are internal motor control signals or simple outputs (for disabled motor controllers). As motor control signals, these are:

1. SV0_ON and SV0_CW_REQ.
2. SV1_ON and SV1_CW_REQ.
3. YV0_ON and YV0_CW.
4. YV1_ON and YV1_CW.

The remaining shear valve controller equations are:

The y-valve controller equations are:

The eight MISO scan chain registers are loaded during NPCS high. The load data are:

Maha and Jack will review this again for residual errors.

STROBED FLUID SENSORS

As described in System Design report 9 topic Hardware Partitioning, there are six strobed fluid sensors [Cdxsys.doc-FluidSensors]. The new design will provide 8. Report 7 topic Left Panel Module [Cdxsys.doc-StrobedFluidSensors] discusses two means, hardware or software, of providing the longer of the two periods. Jack and David agreed in the current meeting that software will provide the period. Hardware only needs to respond to a trigger from software (via the scan chain) and, otherwise, do nothing with the fluid sense circuits.

Jack and David described the theory of the sensing mechanism. To reiterate, the fluid sensors are capacitively coupled to the circuit. The coupling capacitor presents an open circuit when the sensor is not contacting fluid and a ground-referenced capacitance otherwise. The other end of the coupling capacitor is attached to one end of a charging capacitor, the other end of which is grounded. The common node is normally discharged to ground through a resistor. When the mechanism is triggered by a signal from the CPU a transistor is turned on to charge the common node. The charge rate depends on total capacitance, which depends on whether the coupling capacitor is floating or grounded. The node voltage is (continuously) compared to a reference. After 10 usec (with the components used in the original FCM circuit) if the capacitor is floating, the threshold will be crossed; but if the capacitor is grounded, the node voltage will not have reached the threshold. At this time, the circuit latches the output of the comparator.

To render this circuit in the PLD requires the following elements:

1. A means of responding to the CPU's control signal, which is a scan chain output. This must be edge-sensitive because the CPU needs at least 68 usec. (potentially much longer) to change it. The logic for this is relatively simple:

1. The control signal is recorded at every NPCS high period.
2. Assuming positive edge trigger, when the recorded control signal is 0 and the current signal is 1, the control state machine begins. It should be possible to implement this in such a way that the trigger is recognized even as the new signal value (1) is recorded, thus automatically preventing retriggering until the CPU changes the signal to 0 and subsequently to 1 again. In any case, the mechanism must be non-retriggerable.

2. A 10 usec. period counter. This can be a 6-bit counter clocked by the 4 MHz scan chain shift clock.
3. 8 flip-flops to capture the 8 comparators' outputs at the end of the 10 usec. charging period. The outputs of these are inputs to the scan chain (MISO). The comparators' outputs cannot be directly captured into the scan chain register because they have to be captured at a particular time unrelated to the scan chain cycle and they must be held until the next trigger, also without regard to the scan chain cycle.

LEFT PANEL MODULE

As discussed in the meeting documented by report 10 [Cdxsys.doc-RpmLpm], the LPM will comprise a relatively small, simple I/O facility that can be duplicated for larger systems. Maha presented her review and corrections of the constituents of the new LPM.

As mentioned for the MSM Door Release, the transistor's base resistor needs to change from 10K (12K in some instances) to 2.7K.

David pointed out that the ULN2003 logic inputs float when scan chain reset is active. If they float high, high power will be applied to all solenoids. To avoid this, the control input to each ON (pulldown) driver pair should be pulled low by a 10K resistor to digital ground. With the pulldowns turned off, it doesn't matter what value the high-voltage drivers assume. However, floating the ULN2003 inputs may not be good for the IC.

David questioned the choice of Schottky diodes for the high/low voltage blocking diodes. These originally were 1N4002 (even a 1N4000 would suffice). If the cheaper diodes are available in surface mount, we will use them instead of the Schottky diodes.

As with all of the other modules, David questioned the use of resistors on the line driver inputs and receiver outputs. These are actively driven, so passive pullups seem to serve no purpose. They may be an unreviewed vestige of the interim design. All interim design circuits are suspect. Unless someone comes up with a rationale for these resistors, they should be eliminated.

RPMD

The RPMD schematic was briefly discussed. David had expressed concern that the motor drivers' I0 and I1 inputs might be floating at scan chain reset. Both I0 and I1 should be pulled high by 10K resistors (to +5 volt). David reviewed the schematic and concluded that the proper pullups were in place. However, upon closer inspection of Rev. 11, it appears that this is not the case. This should be clarified before fabrication.

The line driver input and receiver output resistors should be removed unless we conclude that they serve a purpose.

CDNEXT ANALYZER SYSTEM DESIGN REPORT 15

4/21/2000

[Report14]

[Report16]

John V, Robert D, James C (Coleman) R, Jack W, Maha N, David McCracken.

VENUE

1. Email discussions subsequent to design meeting 2/17/2000 documented by Design Report 14.
2. Design meeting 4/11/2000.
3. Email discussions subsequent to design meeting 4/11/2000.

DISCUSSIONS

2/21/2000 EMAIL BY MAHA

This is a follow up on the changes discussed during our last meeting:

LPM:

RPM:

I will check into the cypress option, as well as the cost effectiveness of using a 3.3 volt part in a 5 volt system.

2. I noticed that Jack is using 594's for the rpm boards, but we are using 595's because we needed the extra gate for NPCS control.

REPLY FROM DAVID MCCRACKEN

1. I agree with your conclusion regarding the ULN2003 input.

2. Regarding the RPM FPGA. I'm sorry that I didn't represent your comments correctly in my report. I remember that you had suggested Atmel, which I think is a good choice. Atmel is generally inexpensive and high quality.

3. Regarding Jack's RPM schematic; he is just using the interim design for getting up to speed on the Altera tools and to develop a bubble detector, which he will soon present for review. He isn't proposing that any portion of the interim circuitry be retained. As far as the 594 is concerned, we don't want it used anywhere because it is unavailable.

MSM SHARED MEMORY ACCESS

Coleman reported increasing the shared (between CPU and FPGA) memory pointers in the MSM in order to accommodate the increase from 14 to 20 motors. See Report 14 topic MSM-- Event Memory [Cdxsys.doc-EventMemory]. Report 14 suggests that having the FPGA read the shared memory as words instead of bytes would benefit the CPU by using the bus more efficiently [Cdxsys.doc-EventMemoryAccess]. Coleman asked why this would be the case. David explained that this would free more bus time for the CPU, but this would only be true if the FPGA were using cycle-stealing. Coleman explained that burst mode is being used. This is actually much more efficient than cycle-stealing because it is not only inherently faster to skip all but one arbitration cycle but, additionally, the FPGA and SRAM can cycle significantly faster than a normal CPU bus cycle. David asked whether the burst duration could become long enough to create a problem for the CPU. Coleman pointed out that the maximum number of readings would be 21 (one event count reading plus 20 event readings) which, at a 40 nsec. cycle rate, leads to a maximum CPU bus lockout of only .84 usec. This is certainly not a problem for the CPU and reveals clearly that the decision to use burst-mode instead of cycle-steal is correct.

SCAN CHAIN TIMING

Coleman reported that the 4 MHz motor scan chain rate presents no problem for the FPGA. It should be pointed out that although this rate (or at least faster than 2 MHz) is required to support more than 14 motors, it is also desirable in the I/O as well. Increasing the scan rate reduces I/O control latency, which obviously can improve performance. More subtly, it can simplify script and/or analyzer programming by making events in two different cycles of the scan chain appear more nearly simultaneous to the relatively slow electro-mechanical system. Ideally, the scan chain would provide instantaneous response, like a parallel bus. We can't achieve this, but replacing all of the 75174/175 chips with 26C31/32 devices allows us to easily double the rate. We want to do this to all I/O scan chains (APU and MSM) as well as to the motor chain.

Coleman asked for confirmation that the 32 usec. period of the motor scan chain remains in effect for 20 motors and that it applies only to the motor scan chain-- I/O scan chains cycle is as fast as possible. This is correct. Also, reiterating previous decisions:

1. The 4 usec. NPCS high period is retained for all I/O scan chains, regardless of the clock doubling, in order to give any intelligent unit on an I/O scan chain (such as a DSP VPM) time to read and write its MOSI and MISO registers.
2. The motor scan chain NPCS high period will be whatever is left over from the 32 usec. period. The 88 bits (see later discussion of feedback register) of the 20-motor scan chain shift in 22 usec at 4 MHz, leaving a 10 usec. NPCS high period.

FPGA PORT AND REGISTER ADDRESSES

Maha asked whether there were any rules or requirements for addressing FPGA internal resoures that are visible to the CPU (APU or MSM). None are imposed for the benefit of software, which can easily adopt any assignment that suits the FPGA.

FLASH MEMORY ACCESS

Coleman asked whether it was still necessary, given the addition of FPGA self-programming from a configurator (serial memory), for the MSM CPU to be able to access flash memory independently of the FPGA. This requires a separate PLD (22V10), which he would like to eliminate. David answered that independent CPU access to RAM can be convenient when using the BDM to debug hardware, because it may afford the only means for the CPU to execute a program. However, this is not feasible for the MSM, because the FPGA also accesses main RAM as a bus master and must arbitrate access.

There is only one reason for independent CPU access to flash memory-- to support the CPU in programming the FPGA. We discussed whether to continue to support this method in addition to the other two methods of programming, through the Bit Blaster and through the configurator, and decided not to burden the hardware design with supporting this third method. I (David) would like to reconsider this decision. I originally asked for the configurator to alleviate problems in the interim design's handling of the FPGA. The virgin system programming method was extremely complicated and could not be automated; our standard BDM debugger could not be used at all; the FPGA configuration image in flash could easily be corrupted; and the FPGA could easily be programmed in a way that caused it to be destroyed. We have corrected these problems by modifying the analyzer program, tools, and methods. The only remaining problem with CPU-based FPGA programming is that it wastes time during analyzer program development, because it requires an extra step every time we reboot under the debugger. This may sound petty, but the accumulated time waste is significant. On the other hand, this method affords greater convenience than the configurator when distributing an FPGA update because it can be done entirely through the communication system, without even opening the analyzer. The CPU-based method also saves the cost of the configurator, but, as implied by Coleman's question regarding flash access, at the expense of a PLD (22V10) which also requires programming.

The Bit Blaster method is required, because it is far preferable to the other two methods for testing an FPGA program under development (in fact CPU-based programming can't begin to function in a virgin APU until the Bit Blaster has established an initial configuration). Given that we now have a reliable and reasonably convenient means of programming the FPGA via the CPU, this might be the preferred method for production and maintenance, but we would still like to have the configurator during analyzer program development.

The PLD in the FPM circuit, from which the MSM is derived, provides both RAM and flash access. Only flash is actually needed. The FPGA doesn't have to be involved in any way with flash access, so the CPU can more-or-less directly access it. CS0 can be connected directly to flash CS. The CPU's R/W can probably connect directly to flash WR, with CS used for write cycle timing. However, flash OE and the DSACK0 feedback to the CPU must be generated by circuitry, which precludes eliminating the PLD entirely. Therefore, the question that we must answer is whether it is better to have the configurator or the PLD in production. Both need to be programmed and the PLD costs less (especially if the 22V10 is replaced by a 16V8) . We want the configurator as an option in any case for the convenience of program developers but it doesn't have to be stuffed. As an option, it may not even require a socket, as it may be possible to put the device on a small adapter that plugs into the Bit Blaster connector.

If we decide to use CPU-based programming for production, the BIOS program would not change. It now checks FPGA Done signal for high, indicating that programming has already been done, to avoid overwriting a new configuration set up through the Bit Blaster. As far as the program is concerned, there is no difference between the Bit Blaster and the configurator. However reset is affect by this decision. This was the next topic that we discussed.

SYSTEM RESET

We discussed reset, assuming that CPU-based FPGA programming was no long an option. Coleman suggested that the CPU be held reset until the configurator is done programming the FPGA. Clearly, this is correct if the CPU depends on the FPGA for access to flash memory. I requested a reset button, adding yet another reset source. The reset sources are:

• Push button.
• System master.
• BDM.
• Power on.
• FPGA programming.

We decided the following:

1. The FPGA is reset only by power-on, which causes it to program itself from the configurator.

• The reset switch, system master, and BDM reset sources are logically OR'd to produce one composite reset signal. This signal serves as an input to the FPGA but does not reset it.
• The FPGA asserts a CPU reset signal at power-on, during self-programming, and when the composite reset signal is asserted.
• The CPU reset input is jumper-selected to either the FPGA's CPU reset output or to the composite reset. By bypassing the FPGA, the latter enables BDM-based debugging even when the FPGA is dysfunctional.

Although we didn't consider it at the time, item 4 nearly solves the problem of how to handle reset for CPU-based vs. configurator-based programming of the FPGA. When the CPU programs the FPGA, its reset should be connected to the composite reset. Power-on should be added to the list of composite reset sources, so that the CPU will be reset by all sources except FPGA self-programming phase. This doesn't interfere with configurator-based programming, because the FPGA was itself going to combine power-on with the composite reset. Doing this externally can only simplify the FPGA. A separate power-on FPGA input is still needed to trigger the self-programming sequence.

The apparent conflict between the CPU's port A pins and the configurator would not materialize, because the port pins reset to input and the CPU would not change them to output unless the FPGA Done signal indicated that programming was needed. A conflict would arise only if the configurator were plugged in (or stuffed) and CPU reset were jumped to the composite signal instead of to the FPGA's reset out. This would happen only due to user (engineer) error (when using the BDM to debug a bad board, configuration can be skipped).

Whether or not we decide to support CPU-based FPGA programming, the power-on signal should be added to the composite reset; omitting it was just an oversight. With this change, the reset circuit has no bearing on the CPU-based programming decision.

TOWER CONTROL

Coleman asked for clarification of the plans for tower control. The plan is to eliminate the interim design's tower board, moving its functionality to the MSM. The reasons for this are:

1. The scan chain interface comprised half of the board.
2. Users, understandably, don't like having a board on the front panel.
3. The MSM's location, immediately behind the tower area on the left panel, affords easy direct access to the electro-mechanical components.

Coleman was unclear about the three different means of providing I/O mentioned in report 14 topic MSM Conclusions [Cdxsys.doc-TowerIo]. The different means are as follows:

1. Local scan chain. This approach most closely resembles the interim design. Serial shift registers in the scan chain provide all I/O. They are located on the MSM board and are connected directly to single-ended logic signals. The scan chain drivers, receivers, and cabling are eliminated (except where the chain goes off-board to the loader).
2. Parallel registers. The MSM CPU accesses tower I/O via memory-mapped parallel registers, e.g. HC274.
3. Dedicated FPGA pins. The CPU accesses tower I/O via memory-mapped registers in the FPGA. FPGA pins connect to tower interface circuits.

Report 14 doesn't suggest a preference. I (David) prefer the first choice, because it preserves FPGA pins compared to option 3 and is uses less wiring and smaller ICs than option 2.

SCAN CHAIN FEEDBACK REGISTER

Report 14 topic MSM- NPCS High states that the 20-motor scan chain length would be 88 bits if a feedback register is included [Cdxsys.doc-MotorScanChainLength]. That reference includes a link to Report 4 topic Missing Motors [Cdxsys.doc-MotorScanChainFeedback]. Coleman asked for additional explanation.

Another reference to this is in Report 5 topic Scan Chain Topology [Cdxsys.doc-ScanChainFeedbackRegister]. The feedback register would comprise some number of output bits, either in a dedicated shift register or a portion of a register used for application purposes. The scan chain controller or the CPU could write test patterns to the feedback register and read them back at some MISO position if the MISO chain is not completely full, which is likely to be the case. This would enable continuous testing of the scan chain's integrity under normal operating conditions. The MISO position in the FPGA at which the feedback register's image appears depends on the number of external MISO registers (which must be at least one less than the FPGA's MISO length.

One aspect of the feedback register that Jack has discovered is that its serial shift register cannot continue shifting during NPCS high, as does the 74HC595, if it occupies the end of the output leg, because this would cause the pattern to be lost. However, if it does not occupy the end of MOSI leg and the next downstream register shifts during NPCS high then it too may do this. The only effect that this would have would be to shift the pattern in the FPGA's MISO memory. Since this position depends on factors outside of the FPGA's control anyway, the shift would be immaterial. In any case, the CPU would either have to directly set up and test the pattern or tell the FPGA where to expect the feedback image in the MISO array.

Coleman suggested that, for now, he simply add an 8-bit register to the FPGA's motor MOSI array, i.e. to make it 88 bits instead of 80. The MISO array should also contain 88 bits.

We did not discuss how to handle the feedback register. It has several unusual constraints. One, as already mentioned, is that the FPGA can't embed knowledge of its MISO image address. The FPGA also can't know the register's MOSI source address, because the MOSI chain length is not fixed. Depending on the number of motors in the external chain, the MISO reflection of any particular MOSI byte may appear in the same shift cycle (in which case an external register would not be needed), delayed by one cycle, or never (if the output byte ends up in an input register, it will be overwritten by input data). This would suggest that the CPU be responsible for managing the feedback test. However, this would not support continuous testing. Moreover, the CPU has a problem writing the pattern. It does not have or need direct access to the motor scan chain MOSI registers in the FPGA. The only means that it currently has for writing into the register would be to treat it as a motor, incrementing the event count and providing an event descriptor byte that sets or clears just one bit of the register at a time. This arduous process would complicate normal motor control.

Having the FPGA perform the integrity test automatically and continuously would be more reliable and much easier on software. This would not be terribly difficult but it would consume FPGA resources. The FPGA would contain two 4-bit registers, into which the CPU would write the MOSI and MISO byte indices corresponding to the feedback register. The FPGA would write a fixed pattern, such as 10111000, to the MOSI address. This would have to be done on every scan cycle after the FPGA clears the MOSI registers. At the end of each scan cycle, the FPGA would compare the byte located by the MISO index to the fixed pattern. If they are not identical, a status flag would be set for the CPU to read and the CPU would be interrupted. It doesn't matter whether the feedback image is delayed by one cycle or not since the pattern is constant. The CPU can discard the first interrupt caused by the integrity test in case it results from the first such delay. To avoid interrupting the CPU in a system that does not implement the feedback register, the FPGA should not perform the test (or at least not generate the interrupt) until the CPU has written to one of the 4-bit index registers. The CPU would write to the controlling register after writing to the other.

Considering that this affords a continuous and nearly infallible test of the scan chain's integrity, it seems worth implementing if the FPGA can support it. It should also be extended to the I/O scan chains, changing only the size of the index registers according to the length of the MOSI and MISO arrays. Except for the FPGA resources, this only has the shortcoming that it steals a byte of useful I/O space. We can design around this and if the byte becomes desperately needed, the CPU only has to not write to the index registers to regain control of the lost byte.

MSM-LOADER CONNECTOR

Report 14 topic MSM Conclusions assigns Robert D the task of determining whether to use one 10-pin and one 14-pin or one larger connector for the Loader connector (on the MSM board). We decided to use the two connectors, because the system uses them in other places.

CPU BUS CONNECTOR (PC104)

David asked to change the PC104 connector, explaining that half of the pins are unused, that we have no intention of connecting any real PC104 board to it, that synthesizing Intel CPU signals from the 68340 bus wastes FPGA resources, and that not having 68340 bus signals prevents efficient use of the connector for real potential uses, such as:

• Connecting a logic analyzer to the CPU bus.
• Providing a temporary platform for developing alternative system master communication means, for example to develop USB and parallel port interfaces for the APU.
• Providing a temporary master interface for units that otherwise support only Inter-Module Bus communication. For example, the MSM affords an ideal platform for developing independent modules, such as a tube spinner, because it provides both stepper motor and I/O control. However, because we have no intention of having it talk directly to the system master, its hardware supports only IMB master communication. This would prevent it from talking to most desktop and all portable computers, into which we are reluctant (or unable) to insert a HSSL card. Yet it costs us nothing to include in the software the ability to communicate through some device, such as USB or parallel port interface plugged into the bus extension connector.
• Providing an alternate master interface for production units, such as direct RAM access (where the system master can access the unit's RAM as a bus master) for extremely high-speed communication or Ethernet for communicating with a remote system master.

Robert suggested an alternative to the bus extension connector for logic analyzer access. All of the CPU signals are routed to a standard pattern on the circuit side of the board. A matching empty device carrier or socket can be soldered to this pattern for attaching a logic analyzer probe specific to the target (68340). It seems that the cost of providing at least the pad pattern is practically nil, as we would want some arrangement of pads for the bed-of-nails tester anyway. Jack and David should find out what kind of probe is available for the HP logic analyzer that Jack uses. Absent an alternative, we should match this.

We decided to connect the following signals to the 64-pin ex-PC104 connector in any convenient arrangement (if it's no trouble we might want to arrange in logical groups, such as data, address, and control):

1. 16 CPU Data
2. 24 CPU Address
3. CPU R/W
4. CPU DS
5. CPU AS
6. CPU CLKOUT
7. CPU DSACK0 and DSACK1
8. CPU CS2
9. CPU reset
10. CPU IRQ3, IRQ5, and IRQ6 (we only discussed IRQ3 but the others may be useful)
11. CPU DREQ2 and DONE2
12. CPU BUSERR
13. CPU BR and BGACK
14. BG from the FPGA
15. 4 grounds and 3 +5 pins.

The usage of all of the signals except those involved in bus mastering is obvious. If the circuit attached to the connector is a bus master, it will have to coordinate with the MSM, which is also a bus master. The circuit can attach directly to the CPU's BR (Bus Request) which is open-drain, but the MSM (which also has its own direct BR connection) must arbitrate the CPU's BG (Bus Grant) signal. If the motor controller has asserted its BR then the FPGA should not assert BG to the expansion connector. The connector circuit can attach directly to the CPU's BGACK, because this is open drain and because this circuit's BGACK would not have reason to assert unless the FPGA had already given it the BG.

THROUGH-HOLE VS SURFACE CONNECTORS

Maha reported an objection from manufacturing to the surface-mount 3-pin connectors on the RPMD (Right Panel Motor Driver). These components require a secondary operation. The main reason for using surface-mount is to avoid secondary operations. The surface-mount parts are difficult to get and much less reliable for connectors than through-hole. They are especially unjustified for the RPMD, whose motor drivers must be through-hole.

We agreed to use through-hole parts in the future for all connectors.

STROBED FLUID SENSORS

The original strobed fluid sensor circuit from the CD3000 series (see Cdxsys14 topic Strobed Fluid Sensors [Cdxsys.doc-RpmFluidSensors]) is replicated with several different charging RC combinations, all with the same tau. Maha wanted to make all of these identical.

We can be sure that the variations were not accidental, but their purpose is undocumented. Likely possibilities are:

1. The variations were provided in case a need arose for them. There are two situations relative to this: 1) the need never arose; 2) the existing instruments depend on the variations.
2. The variations were added as practice revealed that they were needed.
3. A careful engineering analysis developed these variations to match particular sensor/fluid combinations. This is, unfortunately, the least likely motivation.

Although the most obvious characteristic of the charging circuit is its tau, which determines the sense voltage rise time, different charging RC combinations with equal taus are not equal circuits without including the coupling capacitor and the resistance of the fluid. Looking at the net circuit, C1 (charging capacitor) is charged through R1 (charging resistor) while C2 (coupling capacitor) is charged through R1 plus R2 (fluid resistance). When R2 is high (no fluid) the rise time to the threshold is less than when R2 is low. Ideally, the shortest and longest rise times (to the threshold) are centered around the capture time (Jack says this is 10 msec, but Maha and I think that it is 10 usec), because this provides the greatest error margin.

When R2 is infinite (no fluid) the tau that Maha has considered really is all that matters. When R2 is less (fluid present) the network tau determines the rise time. The goal of the circuit is for each instance to have the same charging RC tau and the same network tau as all of the others. The actual charging RC values can be varied to compensate for the coupling RC values. We can't just choose R2 (fluid resistance). It varies according to the electrical properties of the fluid and by the emersion level of the electrodes at the point that we want to identify as "fluid present". If this can be determined, component values can be chosen by solving the simultaneous equations for fluid present and fluid absent rise time. The "fluid present" tau can be simplified by lumping C2 and C1. C2's equivalent capacitance is determined by the relationship of R1 to R2 (because Q = CV). The network tau is approximately R1 * ( C1 + C2 * R1 / (R1 + R2)).

We can design the circuits to produce nearly any arbitrary margin but component values may become unreliable at extremes. 7.5 vs. 12.5 usec. would provide a 50% margin and should be reasonably attainable. However, we currently have no idea about R2, the fluid resistance (at the transition point). I (David) volunteered to find someone to take some measurements. It should be pointed out that this discussion has used tau for convenience but it can't be directly used for time calculations, because the threshold is 50% (2.5V out of 5V) not 63%. Actual times are calculated by .693 * RC, which is the 50% case of Vout = Vin * (1 - e^(-t/rc)).

David mentioned that Maha's FPGA output driving the base of the PNP discharge transistor should be Open Drain to be sure that the transistor cuts off. Coleman clarified this by noting that the FPGA uses tri-state to simulate this effect. The low output is active while the high output is tri-state. David suggested removing the pullup resistor, but Coleman made the very good point that it is difficult to debug a circuit with floating nodes. We should make this a general rule: where it doesn't interfere with circuit operation, any node that can float (assuming this is itself safe, as in this example) will be weakly pulled up or down to facilitate debugging.

Maha asked how to connect the fluid sense inputs. CD3000 series instruments use several multi-signal connectors. Jack mentioned that some of the signals go through two connectors before going out to sensors. We decided that this arrangement is too specific to a particular instrument for our needs. Each sense input will connect to a separate 2-pin jack. The other pin is connected to analog ground.

SHEAR AND Y VALVE CONTROL

System design report 7 topic Shear Valve and Y Valve Controller contains a diagram of a new shear valve control circuit [Cdxsys.doc-ShearValveCircuit]. Maha asked about the meaning of "10+2" in the new shear valve jack. This "jack" is a conceptual representation (i.e. gobbledygook) of the 2 motor drive wires and the 10-wire ribbon cable that comes off the existing shear valve position sense board (this is J1 in the CD3000 series Shear Valve Motor Control circuit 0900). Considering that the motor drive wires must be heavier than the ribbon cable wires and that they will produce a lot of EMI, they should not share the ribbon cable connector.

Maha also wondered where the EOT was in the new shear valve connector. It is supposed to be there. The connector carries +5, CCWL, EOT, CWL, and Gnd. The remaining 5 pins are not connected.

Maha pointed out an error in the PLD Product Terms for shear and y valve control. The PLD Requirements correctly identify only overcurrent signals, SV0_OC, SV1_OC, YV0_OC, and YV1_OC, but the equations continue to include the undercurrent signals, SV0_UC, et. al. The analysis in report 7 explains that undercurrent should be eliminated, because it is illogical for undercurrent to prevent turning on a motor.

I reviewed the schematic for the interim Tower board and found the following:

There are two separate scan chains <0> and <1>. Scan chain <1> drives 1 stepper motor.

Scan chain <0> drives 2 solenoids (GS2 Release and Door Release), and 1 dc motor (spinner), and has inputs from GS2 Home, GS2 Height, GS1 Home, Door Open, MTR_OVR, and MTR_UNDER.

I know that the stepper motor on scan chain <1> is already included in the allocation of motors for the MSM motor scan chain (mpi), along with a second motor designated as an alternate for the dc spinner motor.

My question is: Are the 2 solenoids and dc spinner motor already included in the allocation of 64 bits for the MSM i/o scan chain (spi)? or, Do we need to add 8 more bits to the MSM i/o scan chain (spi)? I know that you suggested making the MSM i/o scan chain 128 bits instead of 64 bits, but do you really think that is necessary? Or could we get by with just adding 8 bits?

Another question I have is: Is there a new allocation for bits for the MSM motor scan chain (mpi) now that we have increased it for 20 motors instead of 14? I understood the old allocation of:

MSM - 2 for tower (probe & spinner)

1 for peristaltic pump

1 spare

RPMD - 4 syringe motors

1 wash block motor

1 spare

LOADER - 2 motors

SPARES - 2 motors

I guess my main question is, Where is the location of the shift registers for the spare motors?

Another question I have concerns the flags from the stepper motors to the input scan chain. Documents Cdxsys2.Doc and Cdxsys10.Doc both imply that each stepper motor interface has 4 flag inputs to the scan chain, but in actual implementation, each stepper motor interface has only 2 flag inputs to the scan chain. Both documents reference the Status Panel and Left Panel, which I have not seen yet.

[Not in reply : From cdxsys2.doc Motor Scan Chain Inputs:

At least two of the scan chain inputs are taken to standard three-pin flag jacks. The other two pins provide +5 and digital ground to an opto-interrupter. The flag pin is connected to the '597 input and to a pullup resistor.]

1. I chose the 64 bit figure for the MSM's I/O scan chain out of thin air. Reviewing the interim Loader board, I see that it has only 4 outputs and 8 inputs. Even with the additional tower requirements, 64 bits is more than sufficient.

2. Regarding spares in the motor scan chain, we don't need to fully populate the external chain. For both the I/O and motor scan chains, holes in the chain mean nothing to the CPU, which just reads and writes the FPGA locations that are defined in our configuration file. The unused positions only waste FPGA registers. It doesn't hurt anything for the FPGA's motor controller to write nonsense to unused slots, so it is not affected by how any many motors any particular system actually uses.

3. Regarding the motor feedback inputs, I think we should associate four inputs with each motor, even though only two are actually required, because having two spares doesn't cost much and could be very handy during development. Cdxsys2 topic Motor Scan Chain Inputs suggests the treatment of the two required inputs. I think that it would be reasonable, as long as the board has space to treat the two spares in the same way, i.e. each one connects to a pullup (e.g. 10K to +5) and one pin of a 3-pin jack, the other two pins of which connect to digital ground and +5.

4. A topic that we have not addressed related to unused scan chain resources is parameterization in the FPGA design. While a system will function perfectly well without utilizing all of the scan chain potential provided by the FPGA, the FPGA resources are precious. Since we are planning to support a variety of system configurations, being able to easily reduce the resources could allow selecting a smaller FPGA or combining functions into one. For example, the current architecture has the APU FPGA providing gather functions and the MSM FPGA providing motor functions. Both provide I/O. A smaller, single-board analyzer may be feasible, combining fewer motors, less I/O, and/or fewer gather channels, all handled by one CPU and FPGA. The analyzer CPU program already parameterizes I/O-related resources (the motor control program will also do this). To take advantage of a reduction in requirements, we only need to change one number and recompile the program.

CDNEXT ANALYZER SYSTEM DESIGN REPORT 16

5/18/2000

[Report15]

[Report17]

• [Ecp Hardware And Software Design]
• [Solenoid Test Circuit]
• [Pwm-Based Solenoid Power-Down]

John V, Jack W, David McCracken, and J. P. Y.

References:

• IEEE Std 1284-1994: IEEE Standard Signaling Method for a Bidirectional Parallel Peripheral Interface for Personal Computers. (ISBN 1-55937-427-6). See pages 38 through 44.
• Parallel Port Complete by Jan Axelson (ISBN 096508191-5). See pages 17-30 for general I/O and specific parallel port accessing. See pages 285-303 for ECP-specific information.
• Intel 82091AA integrated PC chipset data sheet chapter 6: Parallel Port. This is not available in printed form but can be retrieved from Intel Developer's Insight CD-ROM in design\periphrl\datashts\index. This is also duplicated on Intel's web site.

DISCUSSIONS AND POST-MEETING ANALYSES

IEEE 1284 COMPATIBLE STATE MACHINE

Jack described the ECP state machine that he has been designing according to the IEEE 1284 specifications. The basic operation of the interface is as follows:

1. Negotiation. As explained on p. 40 of the IEEE Std, the negotiation phase enables the PC's port driver to determine whether the peripheral supports ECP communication. We did not previously discuss whether Jack's chip needed to support all ECP features. Negotiation according to the IEEE specification is not needed. We can accomplish the same goal in software on top of the normal ECP state machine, reducing the FPGA's complexity. We control both the PC port driver and the peripheral (the analyzer's 68340 CPU). Our negotiation requirements are that the PC port driver and the analyzer BIOS determine whether they have an ECP connection. The following sequence can achieve this:

1. The (analyzer) BIOS probes Jack's chip to determine that it exists. His chip will need to provide some means of indicating its own existence. It will be mapped to a unique 68340 address, so this is simple. One way would be to provide readable (by the 68340) bit whose permanent value is not the same as a floating data bus. Another way is to provide any bit or bits that are read/write, in which case, the 68340 would write a value and try to read it back.
2. When the BIOS determines that Jack's chip does exist, it will begin negotiating by asserting the Talk Request (nPeriphRequest in the 1284 Std) and then begin polling for the PC's request grant (nReverseRequest assertion).
3. When the PC driver enters into negotiation, it repeatedly polls nPeriphRequest. When this signal is asserted, the driver grants the request by asserting nReverseRequest (note that this is the normal response).
4. When the BIOS sees that its Talk Request has been granted, it sends a signature message comprising one or more bytes. For our very controlled environments, this message just has to occur-- its contents are not important. However, there is no reason not to provide specific information, including a unique signature that no other devices will coincidentally transmit and configuration data, such as BIOS version number.

2. Default condition. Originally, Jack had the PC's port default direction as input. This is common practice for safety in many situations. However, it is not the most useful way to handle the ECP. For reverse transfer, the peripheral asserts nPeriphRequest, to which the PC responds by asserting nReverseRequest (at the discretion of the PC). There is no corresponding signalling means to return to forward transfer. Therefore, forward transfer must be treated as the default condition, to which the link reverts automatically or under higher-level software control. Jack agreed with this argument.
3. Forward transfer. When the link is in the forward transfer (default) state, the PC can send data whenever PeriphAck is low (deasserted Busy). According to the 1284 standard, the PC can send data (forward transfer) for as long as it wants, ignoring any assertion of nPeriphRequest. However, our packet protocol imposes other requirements. Only one packet (no more than 250 bytes) is sent. Then the PC's port driver automatically reverses the direction of the port and asserts nReverseRequest to allow the peripheral (Analyzer) to send an ACK/NAK reply. Even if the analyzer had asserted nPeriphRequest before the PC began a forward transfer, it must still reply with ACK/NAK rather than the data that it originally wanted to transmit.
4. Reverse transfer request phase. When the analyzer wants to send data, it asserts the nPeriphRequest signal (through Jack's chip). If and when the PC asserts nReverseRequest, Jack's chip asserts nAckReverse (to acknowledge the direction reversal). Then, unless this is preceded by a forward transfer from the PC, the analyzer sends its packet to the PC. We decided to provide an option to assert an interrupt (to the 68340) when nReverseRequest goes active to relieve the CPU of having to poll for the Talk request grant. At the end of the reverse transfer, the PC deasserts nReverseRequest, waits for the peripheral to deassert nAckReverse, reverses the direction of the port, and sends ACK/NAK.

INTERFACE OPERATION

The basic operation of the interface described above leaves many unanswered questions, particularly regarding interface state transitions. These are difficult to answer effectively without taking into account the operation of software. First, we need to examine the basic packet transfer mechanisms. The analyzer and the PC's ECP driver are nearly identical functionally. In both systems, one DMA channel and one interrupt are associated with the ECP interface. To transmit, the DMA channel is programmed with the memory source address, the ECP port data destination address, and the message byte count. The DMA and interrupt controllers are programmed to cause an interrupt at the DMA TC (terminal count). Receiving a packet is more complicated. Hardware is configured to interrupt on the first input byte, at which time the ISR programs DMA to transfer the remainder of the packet (the first byte tells the length) from the ECP data port to memory. Again, an interrupt asserts at DMA TC.

The 68340 responds rapidly and efficiently to interrupts. The PC currently is running Windows 95, for which the interrupt response is slow (latency as high as 15 to 20 usec) and consumes considerable CPU time. Thus, reducing the number of interrupts is more important on the PC side than on the analyzer.

Another fact to consider is that the volume of data in the reverse direction (analyzer to PC) is at least 100 times greater than in the forward direction. This suggests that Jack's original decision to make input to the PC the default would be more appropriate. However, this is feasible only if we are willing and able to modify the ECP interface standard. We certainly shouldn't be afraid to change the protocol because we control everything except the PC's hardware. To make the analyzer the default talker, the PC would need to ask the analyzer for permission to talk and it would be the analyzer's prerogative whether to grant the request.

LISTENER-TALKER ROLE REVERSAL ANALYSIS

Although it would be possible to use any of the interface signals in any way that we like, we will encounter the least resistance by staying close to the actual 1284 standard, which uses only the three signals, nInit/nReverseRequest, nFault/nPeriphRequest, and PError/nAckReverse, for direction control. The PC drives nInit while the peripheral (analyzer) drives nFault and PError. This can't be changed, but the signals may be interpreted differently if they are independent of port configuration in the PC's port chip. Most important, they are not tied to port direction control. Section 6.1.3.9 of the Intel 82091AA data sheet tells that clearing ECP's ECR bit 4 enables interrupt on the low-going nFault signal. Axelson's table 15-2 also indicates this but uses the ambiguous name nError for the signal. According to the Intel data sheet (Fig. 31, page 76) the PC can read the status of nFault and PError from bits 3 and 5 of the ECP PSTAT register at I/O address Base + 1. Axelson's table 15-1 (page 289) ambiguously refers to this as DSR without explanation, but presumably this status register is present in all ECP devices. Section 6.1.1.1 of the Intel data sheet also shows these signals in bits 3 and 5 of the PS2-compatible PSTAT located at Base + 1. There is no indication that these two inputs are tied to any function other than the possible interrupt associated with nFault.

Port direction is changed by selecting PS2 mode (in the ECR) and then changing PCON (register at Base + 2) bit 5 (0 for forward and 1 for reverse). See Intel data sheet page 67, figure 27. While in PS2 mode, output signal nInit is controlled via PCON bit 2. Figure 32 on page 78 of the Intel data sheet shows a nearly identical PCON register in ECP mode. This figure erroneously states that bit 5 controls direction in PS2-Compatible and ECP Modes, which Axelson's sample programs and Intel's own data sheet (ECR register description on page 86) state is not the case. The direction can only be changed in PS2-Compatible mode. Intel's register description states that the direction can also be changed in mode 000. Since this is the unidirectional ISA-Compatible mode, the data sheet makes no sense. Despite Intel's confusion regarding direction control, it is likely that the nInit signal is derived from PCON bit 2, which can be controlled in both PS2-Compatible and ECP modes. There is no indication that it is associated automatically with any particular hardware function.

One apparent roadblock to reversing the direction control means is that the standard affords the default listener (peripheral) two output semaphores, nPeriphRequest/nFault to request the right to talk and nAckReverse/PError to indicate its direction reversal. The nPeriphRequest function is desirable to avoid polling but the function of nAckRequest, to avoid having the PC and peripheral attempt to simultaneously drive the data bus, is essential. The standard takes advantage of the fact that there are two signals available to separate the two functions, affording additional flexibility, but they could be merged into one signal. Consider that nAckReverse is actually need only at its desassertion, which is when it tells the PC that it can safely revert back to talker and that nPeriphRequest is actually only needed for its assertion and can remain asserted throughout the reverse transfer, serving in the role of nAckReverse when it deasserts. The following is a neutral description of the two-semaphore direction change means:

1. The default talker never initiates a direction reversal.
2. When the default listener wants to talk, it asserts reversalRequest. This should be a signal that can interrupt the default talker.
3. The default talker may immediately honor the reversalRequest or it may transmit another packet. The purpose of this is not to grant the default talker unlimited talking rights but to allow for the possibility that it has started to talk just as the reversalRequest asserts.
4. The default talker honors the reversalRequest by first determining that the default listener has ACKd the last byte that it has received. The default talker can determine this by verifying that the default listener's data ack is deasserted.
5. The default talker changes its port direction to input and then asserted the reversalAck signal.
6. The default listener can, upon the reversalAck assertion, immediately, change its port direction to output and begin transmitting.
7. The default listener holds the reversalRequest asserted throughout its entire packet transmission period. When it finishes transmitting, it waits for the last data ack from the default talker (now in listen mode), reverses the direction of its port back to input, and deasserts reversalRequest.
8. The default listener must wait for the default talker's reversalAck to deassert before re-asserting reversalRequest.

For the PC as default listener, nFault would serve as reversalAck because it can cause an interrupt. Thus, the PC can request to talk and do other work without having to poll to determine when to begin talking. It should be noted that the interrupt could be triggered by the first byte of a message from the analyzer even if the PC has asserted its talk request. nInit has to serve as the reversalRequest, as it is the only output available from the PC for this purpose.

SOFTWARE FOR TESTING HARDWARE

Jack asked for some sort of program to run on the PC to enable him to physically test his chip. The Nohau 68340 BDM debugger affords sufficient control of the analyzer side.

It is relatively easy to control a PC's parallel port in a DOS VM (Virtual Machine). Old real-mode programs run in DOS boxes under Win95 and have no trouble controlling legacy devices like the parallel port. The downside is that every access is trapped by the operating system, resulting in poor performance, which is obviously not a problem in Jack's test situation.

The simplest way to control the port is by using DOS debug in a DOS box. Only two commands are really needed, IN and OUT. The syntax for these commands is:

i<ioaddr>

o<ioaddr> <data>

To find the I/O address of a PC's parallel port, open Start- Settings- Control Panel- System- Device Manager- Ports- Printer Port- Resources. We are using the port in ECP mode and depending on it to have already been configured by either the BIOS or Windows. The device manager should call it an ECP port and its resource list should include two I/O base addresses, typically 0x378 and 0x778; an IRQ, typically 7; and a DMA channel, typically 3 or 1.

For example, using debug commands we can set the port's direction to output (must be done in PS2 mode-- EPP is supposed to also work but it didn't when I tried it); switch back to ECP mode; and then send a form feed character to the printer. The commands are:

DEBUG

>o77A 35 ;Write 0x35 to the port's ECR register to select PS2 mode.

>o37A 6 ;Write 6 to the PS2 mode control register to signal direction change.

>o37A C ;Write 0xC to the control register to change the data drivers to output.

>o77A 75 ;Write 0x75 to the ECR register to return to ECP mode.

>o778 C ;Send form feed character (0xC) to the printer.

At this point any number of characters can be sent to the printer, by writing to 778.

This example assumes that the port's base addresses are 0x378 and 0x778. It uses the automatic strobe feature of ECP mode to simplify sending multiple characters to a printer. To provide test signals to Jack's circuit, it may also be useful to put the port into the original SPP mode (ECR bits 7,6,5 <= 000) which doesn't generate any signals automatically.

Testing can also be relatively easily automated by writing a simple real-mode program for compiling by the Watcom C compiler (Microsoft's compiler doesn't support real-mode program development). The Watcom debugger (also unlike Microsoft tools) supports reading and writing I/O ports.

J. P. mentioned that he had been helping Ed Sewall find information on how the stepper motor winding test was used. We discussed the possibility of implementing a similar test for the solenoids. The basic concept is to provide electrical feedback from each driven device (one motor winding or one solenoid coil). To avoid having one feedback wire for each device, each one is connected to a common wire through a large value resistor (1M in the existing motor winding test circuit) that doesn't pass enough current to interfere with normal operation of either the associated device or any of the others that are also connected to the common feedback wire. To test a device, all others are electrically floated by disconnecting both their pull up and pull down drivers. In this state, the voltage across the device under test can be tested through its high value feedback resistor. The device driver is turned on. If the device is bad (open circuit) the voltage across it will remain high. If it is good, its low resistance will significantly reduce the voltage.

For the test to be effective the feedback resistors must not interfere with normal operation, i.e. the trickle current must not activate devices, and the voltage across the device under test when it is driven must be appreciably different from when it is not driven. The 1M feedback resistors limit trickle current to .024 mA from 24V even if all but one device are turned on. This is not enough to activate a motor or a solenoid. The existing motor chopper driver circuit also meets the second requirement. For the off state, all transistors in the FWB (Full Wave Bridge) can be turned off, allowing no current to flow. When one winding is turned on, the current flows from 24V through a pull up transistor (in the bridge), the motor winding, a pull down transistor (in the bridge), and a current sense resistor to ground. The winding's DC resistance is several ohms while the sense resistor is .5 ohm (typically-- there are several possible configurations). Even if the transistors' resistances were 0, the winding and sense resistor would present a fairly predictable voltage divider. If the winding is open, the tester will see 24V across it when the driver is turned on. If the winding is good, the voltage will be less by the inverse ratio of the winding resistance to the combined resistance of the two bridge transistors and the current sense resistor. For example if each transistor exhibits a saturation voltage of 1.2V (from the PBL3717 data sheet), the winding resistance is 3 ohm, and the current sense resistor is 1 ohm, then the differential voltage will drop to 16.2V. Even if the transistors' saturation voltage were 0, the differential voltage would be 18V.

The solenoid driver circuit presents a much trickier situation for measuring the unit under test. For one thing, the device cannot be fully floated because the pullup comprises two drivers, one of which is an uncontrollable diode to 12V. With the high power pullup transistor and the pulldown driver turned off, the top end of the coil will go to 12V, because trickle and leakage current will forward bias the low power pullup diode. More significantly, the voltage across the energized coil depends on the ratio between the drivers' effective resistance (due to saturation voltage) and the coil resistance; there is no current sense resistor. Further exacerbating the difficulty of distinguishing between an open and a good coil, the typical solenoid DC resistance is 24 ohm, making even a good solenoid look much more like an open circuit than, for example, a 3 ohm motor winding.

Our solenoid pulldown device is composed of two sections of ULN2003. The pullup is either a TIP125 to 24V or a 1N4002 to 12V. If the high power circuit is used for testing, the excitation current will be 1A, if low power, .5A. The TIP125's Vce is 1.2V at 1A (from Motorola's data sheet). The diode's Vf is 1V at .5A (estimate based on 1.6V at 1A specification). The ULN2003 Vce at 350mA is 1.2V (typical). The TI data sheet doesn't list Vce for higher currents. Assuming that the two sections are nearly identical, they should split the .5 or 1A current evenly and each exhibits approximately 1.2V Vce.

Given the relatively high Vce of the TIP (due to its being a darlington) there is no penalty for using the high power for testing. The greater current would both create larger (more easily distinguished) voltage drops and increase the pulldown's Vce. Therefore, high power is better for testing than low power. When the pulldowns are turned off, the only current flow will be a small reverse voltage leakage through the 1N4002 from the 24V and nearly the entire 24V will be seen across the coil (this must be measured as part of the test). When the pulldowns are turned on, the voltage across the coil will drop by approximately 2.4V. Detecting this 10% drop should be feasible.

Adding the solenoid coil test to the system would entail adding the two feedback wires to the standard scan chain cable. Since there are no 12-pin connectors, we would have to move up from 10-pin to 14-pin. This cable would be identical to the motor scan chain, as described in AD46 topic Cabling [Cdxsys.doc-MotorControlBus]. For the MSM, tower I/O drivers are located on the MSM board itself, so no cabling would be involved. We may not want to increase the wire count in the loader interface, so we might want to leave the loader's solenoids without feedback. However, we need to discuss this, because the loader contains some of the most difficult solenoids to test by inspection. The loader interface DB37 connector now contains 13 pins for loader power, as described in AD46 topic Cabling [Cdxsys.doc-LoaderInterface]. We could take two of these for solenoid feedback.

The decision whether to add solenoid coil testing should consider that adding wires to the scan chain increases connector pin count, which decreases reliability. We know that the small solenoids used in the CD4000 have reliability problems but we don't intend to use these in the future. For the large solenoids that we do intend to use, we need to consider failure history, not only in terms of raw number of failures but also the percentage due to open coils and bad connections, which are the only failures that the circuit can test.

J. P. mentioned that the CD1200 uses an efficient power-down mechanism that we might want to migrate to CDNext. He and Dave R introduced this at an earlier meeting as well but no one explained exactly how it operates. After the meeting J. P. and I (David) examined the circuit and determined how it operates.

The circuit, despite rumors, is not "software-driven" any more than the 3000 series instruments' solenoid drivers are. It is also not more power-efficient. It operates by providing two pulldown drivers to each solenoid. These operate in anti-phase, each at a 50% duty cycle. The high end of the solenoid is tied to 24V. If neither pulldown is enabled, the solenoid is off. If only one is enabled, the solenoid sees 50% (average) of 24V, i.e. 12V. If both are enabled, the solenoid sees the full 24V. This circuit may be more cost-efficient than the driver in the 3000 series because it doesn't require a separate 12V supply. The circuit itself may be cheaper as well. Both circuits (3000 series and CD1200) require two logic signals per device. The CD1200 circuit also requires the anti-phase generator, which is a simple square wave generator. But the 3000 series driver requires the TIP125 high power pullup plus one section of ULN2003 to drive its base. It also needs the low power diode pullup. The CD1200 pulldown is implemented as two ULN2003 sections in parallel. The CD1200's phase generator is inefficiently implemented in small GALs, but it is still probably cheaper than the 3000 series pullup devices. The phasing frequency can be very low, e.g. 60 Hz, to minimize EMI and transistor switching loss.

The CD1200 circuit turns off 8 control signals at a time by deasserting the LS374's Output Enable. It can't operate on a bank of fewer than 8 solenoids without wasting control signals, which for CDNext would mean scan chain bits. If this circuit were implemented on the scan chain, the HC595's OE bit could be controlled in the same manner as the LS374. Our intention to disable outputs at reset would have to be merged with the phasing signals. One disadvantage of the CD1200 circuit is that the circuit itself would dictate that the scan chain outputs be used only for solenoids. It would not be feasible to use them for other purposes since they would be floating half the time. Some of the disadvantages of the CD1200 circuit could be eliminated by using a PLD for the driver circuit. A pair of HC595's could be replaced by a single bank of 8 PLD outputs driven by two buried 8-bit registers driven in anti-phase. Except for the possibility of a very small glitch, a 100% duty cycle output would present an adequate control signal. Two bits would still be required for each output but at least the output could be used for something besides a solenoid. Also, it would not be necessary to control only banks of 8 solenoids because the PLD can be programmed to make any single output controlled by either one scan chain bit or by two alternately selected (anti-phase) bits. The PLD would be more expensive than two HC595's, especially when the cost of programming is considered.

In considering whether to design a scan chain version of the CD1200 solenoid driver circuit, we should also consider where to develop the anti-phase control signals. A square wave generator with gating and logic to combine the phase signals with scan chain reset is fairly cheap to implement locally on each board that contains solenoid drivers. However, if we were to implement the solenoid feedback test described above, it would leave two unused wires in the new standard I/O scan chain cable. These could be used to distribute phasing signals generated at a central point, reducing circuit redundancy while providing a convenient means to stop phasing at will, which would be helpful (maybe essential) in the feedback test.

CDNEXT ANALYZER SYSTEM DESIGN REPORT 17

5/25/2000

[Report16]

[Report18]

• [IRQ Usage]
• [DMA Usage]
• [CPU Timer/Counters]
• [CPU Port A]
• [Scan Chain Integrity Testing]
• [Motor And Solenoid Winding Test]
• [Improved Solenoid Driver Circuit]
• [Miscellaneous]

Robert D, James (Coleman) R, Jack W, David McCracken, and J. P. Y.

References:

• SCHEMATIC MSM - 2500. Drawing No. 74773-101; rev. 11. J.V. Smith. 04-20-00.
• RPM (Right Panel Module) PLD equations from Maha N: /tmp_mnt/index/noujeim/rpm_fpga/worklib/rpm_pld/altera/rpm_pld_cnt.srs, et. al.
• Stepper Motor Drive Circuit. Ericsson data sheet for PBL 3717. Second source SGS Motion Control Application Manual.

DISCUSSIONS

Referring to the suggestion in report 15 that MC68340 IRQs 3, 5, and 6 be routed to the auxiliary connector [Cdxsys.doc-AuxIrqs] Coleman explained that IRQ 5 and 6 are already being used for the I/O scan chain and motor controller interrupts. As the inclusion of IRQ 5 and 6 was only suggested as potentially useful, we agreed to neither implement the suggestion nor try to devise a substitute.

Coleman pointed out that the MSM schematic inherits from the APU and FPM schematic bubbles indicating that MC68340 IRQs 5, 6, and 7 are active high while IRQ3 is active low. He asked whether this was, in fact, the case, and whether they should be passively pulled appropriately high or low. Jack reviewed the CPU manual and concluded that all of the interrupts are active low but, because our software configures them as edge-triggered, they could be tied either high or low to avoid false triggering when not being actively driven. We concluded that they should be pulled up to reflect their true passive state. We could find no reason for some of the interrupts being shown without bubbles. Coleman will correct the component library.

Coleman asked whether IRQ7 should be used. David explained that IRQ7 is a level 7 interrupt, which is non-maskable. Jack added that the program uses a level 7 interrupt internally for the watchdog timer, but that can in effect be masked by not turning on the watchdog timer. They both agreed that there is no external mechanism that represents a sufficiently severe condition as to warrant being non-maskable. Coleman had found a reference to some kind of IRQ7 usage that might be related to memory. Memory parity or CRC error would be appropriate for NMI but we are not using memory error detection.

Coleman questioned the request in report 15 topic CPU Bus Connector [Cdxsys.doc-Done2] for DMA DONE2 on the auxiliary connector. This request was an error. We have no use for either DONE1 or DONE2.

Report 15 requests DACK2 as well as DREQ2 on the auxiliary connector. Coleman asked whether omitting DACK2 in the CPU's UART A interface to DMA channel 2 was an oversight. Jack explained that only DACK needs to be connected externally. The CPU executes the entire bus transaction internally for on-chip peripherals.

Coleman pointed out that he had connected DREQ1 to RxRdyA per David's request in report 14 topic Msm Dma [Cdxsys.doc-RxRdyA]. As with the TxRdy link to DMA2, DACK1 is not connected.

No usage had been specified for the CPU's timer counter pins, GATE1, TIN1, TOUT1, GATE2, TIN2, and TOUT2. David requested that one of counters (we arbitrarily chose T1) be used to generate an alternate source for the IMB (Inter-Module Bus between APU and MSM) serial clock. When the APU or MSM (which can communicate directly with the data station as well as through the APU) communicates with the data station using the HSSL interface, the data station HSSL card's transmit data clock (differential signal) is routed across the APU to the MSM, providing the IMB data clock. Unlike HSSL, the IMB uses just one clock for data travelling in either direction.

We are planning to replace the HSSL data station link with USB and/or parallel port, eliminating the IMB's clock source. Either the APU or the MSM needs to provide a replacement. This could be provided by any 500 KHz free-running clock, but using one of the CPU's timers would reduce component count. The APU already uses both of its timers. Neither of the MSM's timers was previously committed.

The timer can be programmed to operate as a nominal (Jack pointed out that we can't get exactly 500 kHz, but this is not a problem) 500 kHz 50% duty cycle oscillator. TOUT1 can drive the input of a 26C31 (conveniently, there is one spare). The differential output can drive the IMB clock, but this reverses the normal direction and can't be permanent. The 26C31 output can be tri-stated but only in pairs and the other section needs to be always enabled. Coleman also pointed out that the MSM contains a permanent terminating resistor for the master interface clock and the transmitter is not supposed to be terminated.

Coleman suggested that we not even attempt to hardwire the TOUT1-driven 26C31 transmit pair onto the IMB bus, but instead connect the IMB clock wires to either the 26C32 receiver or to the transmitter using two 3-pin jacks with the IMB signal pair on the center pins. We all agreed. A third 3-pin jack is needed to connect the CPU's SCLK to the receiver output when the master provides the clock or directly to TOUT1 when MSM provides the clock.

In our discussion regarding the motor and solenoid winding tests, we decided to use timer 2 for the ADC timer. TGATE1 is the only pin used for this.

David suggested that unused timer/counter pins be pulled up by resistors but also connected to holes, making them more readily accessible for prototyping experiments. Jack argued that the time/counter pins can only be used for simple I/O when the associated timer facility is disabled. Therefore, the unused pins are not useful. TGATE1, TIN1, and TIN2 should simply be pulled up while TOUT2 is no connect (see winding test discussion).

Coleman showed how the CPU's port A pin usage was returned to the original design (from APU and FPM) in which bits 7, 6, 5, 1, and 0 are used in programming the FPGA. This was in response to David's request in report 15 [Cdxsys.doc-CpuProgFpga] that we retain the ability to program the FPGA from the CPU.

SYNC

Coleman asked about the purpose of the "sync" attached to PA2. This is a vestige of the interim APU-FPM communication interface and is no longer relevant. PA2 is, therefore, available. We decided to use it and PA3 for motor and solenoid winding test.

WINK

Coleman asked about the actual operation of "wink", attached to PA4. David explained that wink is toggled in the main program loop to visually indicate that the program is functioning. This is like a visual watchdog and is almost redundant because the main loop also toggles the 7-segment LED between two patterns to indicate the same thing. There is a small difference in that the CPU can access the wink LED even when the FPGA is not functional. In practice, this difference is almost inconsequential. If the unit (MSM) is not fully functional in the field, it is simply replaced. If it is not functional during development, we have to use instrumentation (chiefly the BDM debugger) to determine where it is failing, and the crude distinction provided by the wink vs. the 7-segment display is not particularly helpful.

We agreed to retain the wink but later realized that port A pins could be useful for the motor and solenoid winding tests. We only needed two pins and they were available without discarding wink, but if any other uses for port A present themselves, we should sacrifice wink.

The wink LED driver was not efficient, consuming an entire comparator package and several resistors. Two comparator sections were already unused and we freed a third when we eliminated the spinner motor's under-current detector. Any one of these can be used for the wink LED. Also, the resistors used in voltage divider to generate the wink comparator's reference voltage were redundant, as the motor's over-current comparator's reference can be shared and is adequate for the wink.

To reiterate, we will keep the wink only as long it consumes available resources that are not needed for other purposes. It should be sacrificed if we need a port A pin or another comparator.

DOUBLE-LENGTH SHIFT

Coleman requested a further explanation of scan chain test mechanisms. His FPGA design includes a double-length shift mode for testing in both the motor and I/O scan chain, as suggested in report 3 topic SCAN CHAIN STREAM CONNECTIONS [Cdxsys.doc-ScanChainDoubleShift]. He questioned how this could work correctly, given the variability of the external MOSI and MISO chain lengths. He also wanted a more detailed explanation of the "feedback register" first suggested in report 5 topic Scan Chain- Loop Structure [Cdxsys.doc-ScanChainFeedbackRegister].

CONTINUOUS FEEDBACK CONCEPT

David explained that the double-length shift mode for testing is not necessary if the register feedback test mechanism (see report 15 topic Scan Chain Feedback Register [Cdxsys.doc-ScanChainFeedbackRegisterTopic]) which is much better, is implemented. The register feedback mechanism affords continuous 100% testing of the scan chain in normal operation. Jack added that continuous testing is almost imperative because of the fact that the scan chain requires I/O to be updated constantly. This means that I/O errors can occur even when the CPU is not writing I/O. We will present the cheap continuous testing as an advantage of the scan chain I/O mechanism over less-dynamic bus-based architectures that may not appear to need continuous testing but which also afford no cheap means to do it.

The scan chain feedback register test is conceptually simple but the implementation is somewhat difficult to understand. Jack and my (David) understanding of the mechanism is helped by having seen with the BDM debugger the phenomenon that provides the basis for the test.

The scan chain comprises four legs: the internal (to FPGA) MOSI registers, the external MOSI registers, the external MISO registers, and the internal MISO registers. The end (output) of the external MOSI leg connects to the end (input) of the external MISO leg. If the external MISO leg is not as long as the internal MISO leg (which is normally the case) some number of bits in the internal MOSI leg will appear in the internal MISO leg. The relative lengths of the four legs determines the number of bits, their MOSI source address, their MISO destination address, and when they appear. If the combined length of the two external legs is less than the length of one internal leg (internal MOSI and MISO legs have the same length) then some of the first MOSI bits to shift out will shift through both external legs and end up in the internal MISO length in a single scan cycle (delimited by NPCS). If the combined length of the external legs is greater than this, no internal MOSI bits will traverse the entire external chain in one cycle, but some of these bits stored in external MOSI shift registers will continue their traversal and end up in the internal MISO leg on the next cycle.

The longer the external MISO leg, the fewer MOSI bits that show up in the internal MISO leg. However, if even a relatively small number, comprising a distinct pattern (i.e. some mix of 0s and 1s) shows up in one or two cycles at the expected internal MISO location, it almost certainly guarantees that the entire external chain is functioning properly. Further, there is a good chance that this tests the external interfaces of the external registers as well as their internal shift registers, because most chip failures are not isolated even when they are caused by an external event at just one pin.

We would like the FPGA to perform the feedback test in every scan chain cycle in order to detect transient errors as well as permanent failures, but it can't know any of the characteristics of the phenomenon that depend on external chain leg lengths. We can simplify the information that is needed in two ways. One is that the test bit pattern doesn't need to change, as it would for a memory test for example, because each 1 and 0 in the pattern has to traverse the same path, which guarantees that "stuck at" and "stuck to" faults will be detected by a single pattern. Using a fixed pattern not only simplifies the test in itself but also provides the means to ignore the cycle uncertainty. After the first two scan cycles, whether the test pattern requires one or two cycles to reach its internal MISO destination is irrelevant. The FPGA only needs to delay before performing the test and this can easily be built into the CPU-FPGA API, relieving the FPGA of responsibility.

No trick can eliminate the need to vary the source (internal MOSI) and destination (internal MISO) locations of the test pattern according to the length of the external chain legs. Some MOSI bits will never appear in the MISO registers and the ones that do will not appear in fixed MISO locations. The CPU will know this information because it can be derived from the analyzer configuration file (analyz.ini) which the script compiler uses to translate source scripts to system-specific commands. Because the pattern is constant and occupies a static MOSI location, the CPU can write the source directly transparently to the FPGA in the case of the I/O scan chain. However, this won't work for the motor scan chain, because the FPGA clears the internal MOSI chain at the end of every scan and the CPU couldn't rewrite the pattern every 32 microseconds even if it did have direct access (which it doesn't now have). The CPU could write the pattern into event memory but this would be inefficient for both the CPU and FPGA, which would have to read one byte for each bit in the pattern every 32 microseconds. Therefore, the FPGA should automatically write the pattern into the motor internal MOSI chain itself after clearing all of the bits. The CPU tells the FPGA where to write by writing the address into a register. Similarly, the CPU tells the FPGA where to read the MISO image by writing the address to another register. The MISO pointer is needed for both the I/O and motor scan chains, while the MOSI pointer is needed only for the motor.

The CPU should first prepare the outgoing test pattern by writing it to the MOSI leg of the I/O scan chain and by writing the MOSI address of the pattern to the source pointer register of the motor scan chain controller. Then the CPU will write the MISO address of the reflected pattern to the destination (where the test pattern will show up) pointer register of both the motor and I/O scan chain controllers. The act of writing to this register can turn on the FPGA's MISO pattern test, which registers a fault if the MISO pattern is incorrect. The CPU will delay long enough between preparing the MOSI pattern and writing the MISO address to ensure that two scan cycles have passed. Thus, the FPGA will be able to perform the test without regard to timing or sequencing. However, the error flag should stick until cleared by the CPU to be sure that temporary faults are detected.

Given the significantly greater complexity of the motor feedback test (due to the MOSI pattern generation) and the fact that most motor failures can be detected by other means, we may choose to implement the integrity test only for the I/O scan chain.

If the combined length of the external MOSI and MISO legs is greater than the internal leg length, the integrity test requires a dedicated external register to hold the test pattern between scan cycles. Depending on the chain leg lengths, this would not necessarily have to appear at the end of the MOSI leg, but this location would support the longest external legs and should be used. The test register can't be used for real output because it will always be written with the test pattern. Also, it should not shift during NPCS high as does the HC595, our typical output register.

The register isn't needed if the combined external leg length is shorter than the internal leg length. If the external length is too long and an external register is not provided, the test can't be performed. This situation would not require changing the FPGA. Instead, the CPU would simply not write to the MISO pointer register and the FPGA would not perform the test.

CONTINUOUS FEEDBACK REALIZATION

Coleman suggested that it would be easier to understand the continuous feedback test if we would pin down specific cases. Although the test pattern could comprise as few as four bits, we agreed to use a full byte, arbitrarily chosen to be 10010011 (0x93). We also decided to reduce the length of the usable I/O scan chain to 48. The tower I/O consumes only 8 bits, leaving 40 for the loader, which is more than twice as much I/O as provided by the CD3200 loader controller (SHM).

For the MSM, we decided on the following:

• For the motor scan chain (if we decide to implement the feedback test):
• The internal MOSI and MISO each contain 11 bytes.
• The external MISO and usable MOSI each contain a maximum of 10 bytes.
• A one-byte feedback register will be located at the end of the external MOSI chain, which will be in the loader.
• For the I/O scan chain:
• The internal MOSI and MISO each contain 7 bytes.
• The external MISO and usable MOSI each contain a maximum of 6 bytes.
• A one-byte feedback register will be located at the end of the external MOSI chain, which will be in the loader.

If a loader is not used, the MSM I/O scan chain will not need an external feedback register for integrity testing because the combined external length will be less than the internal MOSI length. If a loader is used, its own I/O usage will determine whether it needs to provide a feedback register. The situation with the motor scan chain is more complicated. As with the I/O scan chain, the loader is the end of the chain but only if it is installed. Otherwise, like the I/O scan chain, the motor scan chain is terminated and looped back (external MOSI to MISO) on the MSM board. If we decide to implement the motor scan chain integrity test then the loader will include a feedback register. If the loader is used then all of the requirements for the motor scan chain test will be in place. However, if the loader is not used and more than nine motors are in the chain then the test can be performed only if some other unit in the motor scan chain provides the feedback register. Since our current system defines only 8 steppers other than whatever motors are in the loader, it is probably unreasonable to expect the MSM to provide an optional feedback register. It is more reasonable to expect this of some additional (as yet unspecified) motor driver board.

MOTOR WINDING TEST

Coleman reported that he and Ed Sewall have been studying the stepper motor winding test described in report 4 topic Motor Winding Test [Cdxsys.doc-MotorWindingTest] and report 9 topic Motor Scan Chain [Cdxsys.doc-WindingTestBus]. Ed was particularly concerned about the statement "If a driver is turned off, the circuit leg presents a 2 Mohm load across the analog bus." in report 9, because he thinks that the PBL3717 motor driver chip affords no means to turn off all of the transistors in the bridge. We reviewed the internal schematic of the 3717 and confirmed that one of the upper transistors will always be on. Consequently, each "off" driver circuit leg appears as 24V connected to each wire of the feedback bus through a 1M resistor. Coleman volunteered himself and Ed to re-analyze the circuit based on this information.

Ed and Coleman were unclear about how the test is supposed to be conducted. David repeated his general interpretation, which is that all drivers except one are turned off (which we now know to mean connected to 24 V). The differential voltage across the bus is measured. Then one driver is turned on. If the winding is open (or the motor disconnected) current will flow through the resistor network, causing a measurable differential voltage. If the winding is intact, it will nearly short the driver, causing the differential voltage to be significantly less. In David's original erroneous analysis, the differential would have been 1.7V in the case of an open winding and nearly 0 otherwise. This difference is easily measured. Ed will determine how much of a difference we can expect given the real functionality of the 3717.

SOLENOID WINDING TEST

David presented excerpts from report 16, in which a solenoid winding test, similar to the motor test, is described [Cdxsys.doc-SolenoidTestCircuit]. The circuit analysis in that report is based on accurate (hopefully) data regarding the components and indicates that a 10% difference voltage difference could be expected between a good and a bad winding. However, it was based on the old solenoid driver circuit, which uses a pullup transistor to 24V for high power, a diode to 12V for low power and a pulldown driver. David also presented another excerpt from report 16, describing the solenoid power down circuit used in the CD1200. We all agreed that this is a better circuit and Coleman decided to use it for the MSM's on-board tower solenoid drivers.

The solenoid winding test described in report 16 calls for a two-wire bus as used for the motor winding test. Coleman pointed out that the high end voltage is not relevant with the elimination of the pullup devices. We agreed that only the low end wire is useful. This is particularly advantageous for the loader, because it means that the solenoid test would steal only one of its DB37 pins. For the I/O scan chains, adding even one wire requires increasing the 10-pin to a 14-pin connector because 12-pin connectors are not available. This is not a significant issue for the MSM, because its tower I/O circuitry is on-board. As reported in report 15 topic MSM-Loader Connector [Cdxsys.doc-MsmLoaderConnectors] we had decided to use two standard connectors, 10-pin and 14-pin, on the MSM for the loader interface. Adding a solenoid winding feedback wire would require the 10-pin connector to change to a 14-pin. The MSM-loader wiring harness is unique and this change is not significant.

David requested that Ed and Coleman review the solenoid winding test proposal, particularly in light of the driver circuit change.

WINDING TEST ADC

David had originally asked Ed to review just the single-slope ADC analog circuit from the old MPM board to determine whether it could function as suggested and to consider whether it could be replaced by a cheaper circuit (especially one that would not need a split power supply). There was some uncertainty about how the circuit was expected to function. David reiterated his understanding that the MPM CPU provides logic and timing control, while the circuit provides a means to discharge a capacitor and then charge it up to a set threshold at a rate determined by the voltage across the winding feedback bus. This appears to be a single-slope ADC, which is not very accurate compared to a dual-slope converter, but which should still be adequate if we take a reference reading.

Coleman suggested that we use some of the CPU's native I/O pins to control the two circuits, one for the motor winding test and one for the solenoid test. David suggested that the unused timer/counter T2 be used. If TGATE2 were attached to the comparator output, the CPU would be able to either count the charge time programmatically with TGATE2 configured as a simple input or use the timer to measure the duration of the TGATE2 period. Coleman suggested using one port A pin (PA2 and PA3 are available) to discharge one shared or two individual slope capacitors and one pin to select between the two sources.

We did not define how much analog circuitry the motor and winding tests would share, i.e. whether the signals are multiplexed at the analog input, in the middle of the analog circuit, at the output, or not at all. Given the addition of the solenoid test, we may want to reconsider whether the homemade single slope ADC is really the best solution. An off-the-shelf multi-channel input ADC may be easier for us than trying to multiplex the two signals in the homemade ADC and cheaper than simply duplicating the entire motor winding analog circuit. On the other hand, if we were to simply duplicate the analog circuit, it would not be difficult to provide the necessary control pins from the CPU. One approach would be to use TGATE2 for one comparator input and one port A pin for the other. The wink could be sacrificed so that two port A pins would be freed to provide separate discharge capacitor control signals. With this arrangement, TGATE2 could be configured as simple input so that both measurements are timed programmatically or it can be configured as the timer gate, in which case one measurement would be timed by program and the other by timer. Neither approach presents any software difficulties.

David's original analysis of alternatives to the old analog circuit rejects using a Norton current amplifier (like the LM3900) at the front end to reduce the high common-mode signal down to a more easily managed 0 to 5 or 15V. The reason was that the high input offset current variation would swamp out the measurement. We may want to reconsider this. If we take a reference reading of all drivers in the off state immediately before turning on the one under test, the component variation may be irrelevant, as it would affect both readings identically. The only problem would be if the good/bad measurement variation were so small that the required signal amplification times the input offset current could pin the amplifier's output regardless of the signal. Another consideration is that there are better current amplifiers than the LM3900, but some of these need a split supply. A high common-mode voltage tolerant diff-amp, like the INA117 or AD629, might also be used although they may be too expensive. The reason for bringing up this issue again is that it may be possible to redesign the analog circuit to make it more adaptable to multiplexing or cheaper to simply duplicate. Now that Ed and Coleman understand the basic premise of the winding test, they may be able to devise more efficient alternatives to the original proposal.

David compared the CD1200 solenoid driver circuit to the one that the interim design took from the CD3000 series (see report 16 topic Pwm-Based Solenoid Power-Down [Cdxsys.doc-PwmSolenoidPower]).

The analysis in report 16 raises several questions regarding the scan chain connections, such as whether to transmit the phase signals on spare wires made available if the solenoid winding test is implemented or to generate them locally on scan chain I/O boards. For the MSM, these questions are easily resolved. In the case of tower I/O, all control wiring is local anyway. For the loader, the primacy of DB37 pins dictates that, if the loader does implement the new driver circuit, it must generate the phases locally. Also, the problem of the CD1200 circuit decreasing flexibility by dedicating outputs in groups of 16 bits to motors is not an issue for the MSM's tower solenoid controls, because they are implemented in the FPGA rather than by indivisible 8-bit registers.

Report 16 suggests a pwm frequency of 60Hz to minimize EMI but we all agreed that this would likely cause the solenoids to chatter in the low power condition. We decided to use 240Hz. This may also be too low, but it can easily be changed.

GAL FOR BYTE-WIDE FLASH

Coleman reported having to reinstate the PLD used for memory selection. It is needed only to tell the CPU (through NDSACK0) that the flash is byte-wide and only to support CPU programming of the FPGA (otherwise, this function would be implemented in the FPGA instead of the separate PLD). Coleman restored the original 22V10. He will review this and possibly use a smaller and cheaper device like a 16V8. In any case, we will use the pins not needed for the flash interface for other purposes.

Jack questioned why the reset needed any logical combination. Coleman explained that the circuit implements the requirements that we determined in report 15 topic System Reset [Cdxsys.doc-SystemReset] with changes to accommodate David's request to retain the ability of the CPU to program the FPGA.

HALT INDICATOR

Coleman asked about the purpose having the CPU's HALT signal control the 7-segment LED's decimal point, which he copied from the interim FPM circuit. This serves only as a crude diagnostic indicator of the CPU's condition. David reported seeing the DP turn on during early FPM development and not knowing its significance. Knowing that it indicates that the CPU has halted, which can be caused by a bad instruction or double bus fault, might be useful. However, we now do nearly all development under a BDM debugger, which provides specific information about such faults. Nevertheless, we may as well keep the circuit, because it costs nothing.

TDI AND TDO

Coleman asked what to do with TDI and TDO. These, in addition to TCK and TMS, support IEEE 1149.1 JTAG testing of the CPU. Since the board has no other JTAG-compliant components, boundary scan testing would not be cost-effective. TDI and TMS are inputs but the CPU has internal pullup resistors for them. TCK should be pulled up to 5V.

UNUSED INPUTS AND OUTPUTS

David requested that, generally, any CPU (or any other component) I/O pin that is not used be connected to a hole to facilitate connecting a wire in case we find a use for it during development. Unused inputs should also be pulled to 5V by resistors.

CONCLUSIONS

1. IRQ 5 and 6 will be used by the FPGA to interrupt the CPU for I/O scan chain and motor controller events. Only IRQ3 is routed to the auxiliary (CPU bus expansion) connector.
2. All of the 68340's external interrupts are active high and will be pulled high through resistors if unused. IRQ7 and IRQ3 will be pulled high. IRQ7 is unused and IRQ3 is not driven unless a mezzanine board is not installed.
3. The CPU's DONE1 and DONE2 pins are no connects.
4. DACK2 is routed to the auxiliary connector but is not connected to anything relative to TxRdyA's usage of DMA2. DACK1 is no connect.
5. The CPU's TOUT1 will drive the input of a 26C31 differential line driver. It will also be connected to an outer pin of a 3-pin jack (.1" spacing). The other outer pin will connect to the Inter-Module Bus (APU-MSM serial interface) clock receiver output. The center pin will connect to the CPU's SCLK pin.
6. The Inter-Module Bus differential clock signal pair will connect to the center posts of two 3-pin jacks. The other pins will connect to the inputs of one 26C32 receiver and the outputs of the TOUT1 driver. Setting the two jumpers one way will cause the clock from the APU to drive the MSM's clock receiver. The other way will cause the MSM's buffered TOUT1 to drive toward the APU. The former connection will be used when the APU connects to the data station through the HSSL interface, the latter when any other interface is used. The 3-pin SCLK jack will be set to match; i.e. all three jacks are changed in concert.
7. The "sync" signal attached to PA2 in the interim design is eliminated.
8. The "wink" signal controlled by PA4 will be retained only if we don't need PA4 for any other use, such as for the motor and solenoid winding tests. If the wink is retained, its driver will be an unused LM339 comparator section and it will share the motor over-current voltage reference.
9. The scan chain double period shift mode originally proposed for integrity testing will not be provided for any scan chain that provides the continuous integrity test.
10. The FPGA will support the continuous scan chain integrity test for the I/O scan chain and may also support it for the motor scan chain (TBD Coleman).
11. The loader will provide an I/O scan chain feedback register if one is necessary (whether one is will be determined by the number of active output bits in the loader itself).
12. If the continuous integrity test is provided for the motor scan chain, the loader will contain a feedback register for the motor scan chain.
13. Scan chain feedback registers will be simple 8-bit shift registers that will not shift during the NPCS high period.
14. The scan chain test pattern will be binary 10010011.
15. The MSM I/O scan chain will comprise:

1. Internal MOSI and MISO each seven bytes.
2. External MISO and usable MOSI each a maximum of six bytes.
3. One byte feedback register at the end of the external MOSI chain.

16. If the integrity check is implemented, the motor scan chain will comprise:

1. Internal MOSI and MISO each 11 bytes.
2. External MISO and usable MOSI each a maximum of 10 bytes.
3. One byte feedback register at the end of the external MOSI chain.

17. If the integrity check is not implemented, the motor scan chain will comprise:

1. Internal MOSI and MISO each 10 bytes.
2. External MISO and usable MOSI each a maximum of 10 bytes.

18. The tower solenoid drivers (located directly on the MSM) will be implemented similarly to the CD1200 design with the FPGA providing the control signals. The phase frequency will be 240 Hz (subject to review and testing).
19. It is yet to be determined whether the loader will implement the 1200-style or 3000-style solenoid driver but, in any case, no wires will be taken from the DB37 to provide the phase signals. If the 1200-style is implemented, the loader will generate its own phase signals locally.
20. Subject to review by Ed and Coleman, the MSM will include a solenoid winding test facility using a one-wire feedback bus. The tower solenoid feedback is direct on the MSM board. The 10-pin loader I/O scan chain connector will be replaced by a 14-pin connector to accommodate the additional wire. The other three new pins will be unused.
21. The MSM will provide a motor winding and a solenoid winding test ADC. Ed and Coleman will investigate whether two circuits similar to the MPM's single-slope converter or some alternative should be used. In any case, the CPU will interface to the circuit will be through TGATE2 and two or three (sacrificing "wink") port A pins.
22. TIN1, TGATE1, and TIN2 will be pulled high. TOUT2 will be no connect.
23. The 22V10 used for generating the flash memory's NDSACK0 and the reset combination may be replaced by a smaller and cheaper PLD.
24. The CPU's HALT signal will continue to control the 7-segment's decimal point.
25. The CPU's TCK will be pulled high. TDI, TMS, and TDO are no connect.

CDNEXT ANALYZER SYSTEM DESIGN REPORT 18

6/4/2000

[Report17]

[Report19]

• [Parallel Port Link Design]
• [Right Panel Module]

PARALLEL PORT LINK DESIGN

Report 16 topic Ecp Hardware and Software Design - Listener-Talker Role Reversal Analysis [Cdxsys.doc-ReverseEcp] describes a protocol derived from the standard ECP. The derived protocol reverses the roles of the PC and the peripheral to make the peripheral the default talker. Per report 16 task 4, Jack has reviewed the protocol and made the following observations:

1. In general, any automatic interface control (signaling and buffer reversing) by the analyzer's interface device (the one that Jack is designing) reduces CPU requirements. The most significant benefit accrues from compressing events in time to allow either CPU (analyzer or PC) to perform more than one interface transition function in a short period, reducing interrupts and/or waiting. For example, if Jack's device can respond automatically to the PC's reverse direction request, the PC can assert the request and test the response in a single interrupt period. If the decision requires the analyzer CPU's involvement, the PC will have to assert the request and set itself to be interrupted by the response.
2. The device can respond immediately (combinatorially) to the PC's reverse direction request if the PC asserts the request before receiving the first byte of a message from the analyzer and deasserts it if the analyzer simultaneously begins talking. In this case, the device would latch the first (length indicator) byte of the analyzer's message but not drive the output (toward the PC) until the PC deasserts the reverse direction request.
3. The device is not aware of our packet protocol and, therefore, cannot automatically generate interface signals or change direction at the end of a packet transfer.

There are two basic approaches to direction reversal. The programmatic approach has the analyzer and PC programs negotiate using Jack's interface device as a simple conduit. The automatic approach has the PC program negotiate directly with the interface device. The latter is clearly preferable if it can be reliable. This means that there cannot be any point, however brief, at which the device and the PC's parallel port both try to drive the interface. They may be simultaneously set for input, but this must be a temporary condition that is resolved by control signals (and CPU involvement when necessary).

Jack's suggestion (listed above as observation 2) seems to afford a reliable means of reversing direction. However, the simple protocol fails in one scenario. Imagine that Jack's device starts transmitting a packet by driving the first byte onto the interface and asserting the transmit strobe. The PC may assert the reverse request just as the device asserts the transmit strobe. The device can't stop the transaction in progress, but if its output is automatically tri-stated by the PC's reverse request there is a risk of the PC capturing an indeterminate data value because the ECP's data exchange is automatically done in hardware independently of the program-based direction reversal request. This problem can be prevented by Jack's device transitioning to a data transmit state prior to commencing a transaction. In this state, the device can simply ignore the reverse request. As Jack has observed, his device cannot know by itself when it has transmitted the last byte of a packet, suggesting that such a data transmit state could not persist for the duration of a packet without assistance from the analyzer CPU. The CPU might be involved anyway at the end of the packet, but there is a simple way to establish the transmit state per byte. The transition to transmit state can occur when Jack's device latches its transmit byte. The transition out of transmit state can occur after the PC's receive handshake. Thus, the reverse request can combinatorially tri-state the device's output at any time that the device is not in the transmit state, and the only possible glitch would occur in the data just as the device drives it onto the cable when it would be in transition anyway.

The above analysis shows that it would be relatively simple to provide safe direction reversal with a low-level protocol. However, this approach leaves the analyzer vulnerable to a higher-level conflict. Imagine that the analyzer has left itself in a ready to receive or neutral state, i.e. not blocking the PC's request to talk. A direction reverse request from the PC will be granted at this time even if the analyzer CPU is simultaneously preparing to transmit. If the analyzer's DMA then tries to write the first message byte to the interface device there can be a conflict with the input byte from the PC. It may be possible to resolve this conflict at a low level, but a simpler solution is to require the analyzer CPU to negotiate for the right to transmit, not with the PC but with Jack's device. The device can respond immediately, so this represents a simple control flow situation for the CPU. Once the device grants the right, it can ignore the PC's reversal request. The device cannot rescind this right because, as Jack says, it doesn't know which byte is the end of the message. The analyzer CPU has to explicitly give up its right just as it must explicitly request it. This approach prevents low level direction conflicts by wrapping them in a protocol that prevents higher level conflicts. The PC can (and should) hold its reversal request throughout the transmission from the analyzer. At the end of the message, the analyzer can examine the reversal request signal (through Jack's device) and decide whether to give up its right to transmit. Conflict can exist only if the analyzer and the PC simultaneously request to transmit. Preferably the right would be accorded the analyzer but this is a minor issue. What is important is that the device resolve the conflict without generating glitches in the interface signals. Using the analyzer's and the PC's unsynchronized talk request signals combinatorially would create an opportunity for a metastable state to produce a prolonged glitch. The analyzer's talk request is inherently synchronized to the interface device's state machine clock by virtue of the fact that it is created by latching the CPU's data bus (when the CPU writes to the control register). To synchronize the PC's talk request, the device only needs to also latch it. The latched signals will be synchronized to the same clock and can be used combinatorially.

The PC's ECP signal directions can't be changed, but their usage changes for our inverted protocol. Without making major (and unnecessary) changes to the standard ECP definition, the only signal available for the PC's talk request is nReverseReq (Centronics nInit). We could use either nAckReverse/pError or nFault/nPeriphReq for the talk grant signal. The former is more consistent with the ECP standard but the latter would allow the PC to be interrupted when the grant is asserted. The interrupt could prove useful when Jack's device doesn't immediately grant the request. Consistency with the ECP standard is tenuous and of no particular value. The standard meaning of nAckReverse is to grant the opposite direction from our reversed protocol. Any automatic use of the signal according to the standard interpretation would provide exactly the wrong functionality. Therefore, it makes the most sense to use nFault/nPeriphReq. The PC can treat this as a simple input without interrupt if it chooses.