FROM: Phil Green, Sandia National Labs, (505) 844-5087
REF: WFD Progress Report
The report of October 6, 1993 was quite encouraging. It appears
that you are going through the normal process required for the
development of a system as sophisticated as the MACRO WFD. I have
a few general comments and also some comments in reference to
specific points in the report.
First, I would like to get a copy of the latest circuit drawings for
the WFD for review. The last time I got a set, I reviewed the circuits
and provided some feedback on design questions and found that the
drawings I had were already obsolete. I never received new ones.
Secondly, I would like to suggest that, although high priority
must be given to producing a working system, I would strongly
encourage a lower priority on getting into volume production. There
are always many things to learn which can delay production for three
months or more but can provide big payoffs. For example, I cannot
judge from the information I have whether or not any plans have been
made for diagnostics and testing of over 1000 channels. At Sandia we
have designed into our 200 Mhz digitizers command- driven or power-
up driven state machines which will initiate the module to the same
configuration it had at last power down or will re-initialize the module
with a command. We also provide non-volatile RAM for setup storage.
This greatly simplifies initialization after a power-down and also gives
quick-recovery operation after power failures. We have also arranged
for all important settings to have a read-back feature so that the setting
could be sent to the module and subsequently verified.
I also suggested a few months ago that all adjustments be
arranged to be software controlled to minimize bench adjusting. You
can easily incorporate either voltage or current DACs so it makes nearly
any setting programmable. This can be accommodated for the daughter
board but some analog control lines have to be incorporated into
interface connection. The DACs will surely be on the motherboard but
"knee" control lines would need to take voltages or currents up to the
daughterboard.
I would like to comment on the VME interface testing.
32 bit add + 32 R/W + 16 R/W tested good
24 bit add + 32 readout + 16 R/W tested good
8-bit readout notest OK. Mode
unnecessary!!
Unaligned readout notest OK. Mode
unnecessary!!
Block transfers notest PLEASE TEST
Block transfer mode can increase data transfer rate
by as much as 50% since the address-strobe is not
repeated and you can generate a data strobe as fast
as you can get back a DTACK. I realize that this
mode can be problematic. For example, all VME
controllers do not support block transfers. Some
controllers handle it poorly so that the transfers
could be corrupted but its a great mode to use.
Base address selection tested good
Zero suppression control tested good
Interrupt enable notest PLEASE TEST
Again, there is no more efficient way to transfer
asynchronously collected data from a crate full of
units than through interrupt driven accesses. I
don't know exactly what the plan is for data
readout but if we get in a crunch for time,
interrupts will help.
All others tested - GOOD!!
Concerning the ASIC rollover problem. It appears that some
very good sleuthing has gone on to determine what is going on there. I
have a feeling I don't have the latest version of the ASIC schematic but
I have looked at what I have. Teh drawing is dated Dec. 23, 1991.
Apparently the PAR signal is needed in the REG8E for the register to
update. Since the clock is constantly hitting the register, you must be
getting the appropriate Write-Enables and Strobes out but no PAR.
Consequently you write the old data out. I don't know if I read your
note right but you indicated that you got correct rollover words out (i. e.
no defective timewords) at frequencies of 199, 201, 206, 207, 208, 209,
and 210 Mhz. This would suggest that you got bad words at 200, 202,
203, 204, 205 Mhz. If the problem is purely delay, why does it not
update at 202 Mhz but does update at 208 Mhz.? Maybe I read things
wrong.
I would like to know more of your possible "fix" which requires
one severed connection and one jumper. Maybe I could get the latest
ASIC schematic with the surgery marked in red? I agree that there are
workarounds. In fact, if the data rate is not too high, it could give one
a more secure feeling to have readout of externally introduced timing
"fiducials." If we end up with only 2-fold fan-in use and put a timing
fiducial into a 3rd channel, we could end up with a solidly timed data
stream. Furthermore, this channel, or the 4th could be used to inject a
timed pattern of pulses which could code the absolute time for data
synchronization.
In summary it appears that great progress is being made.
I again urge restraint in the desire to forge on at rapid speed.
Retrofixes are not impossible but thorough testing can avoid this.