7/22/92
  Worked on the hang problem when CAM module not plugged in.  The problem
is the interface is requesting infinite bursts from the SPARCstation.  The
problem disappeared and would not come back after a few minutes.  The test
was done on im3.  Norm says the first interface fails consistently.  Will try
later.

  The second interface board (the one with the handshake fix) causes timeouts
when test16.exp is run.  The problem occurs whenever a register read is attempted.
All signals to CAM look good both with scope and logic analyzer (timing looks fine).
Guessing that the problem might be related to running CAM at 25 MHz, I tried the
first ("good") interface on im11, which has a 25 MHz clock.  It fails test16.exp
with a CAM interrupt rather than a timeout interrupt, but fails after a few (3-5)
tries at reading the multi register.

     select 1 reg! multi *step*
     multi read *step*


7/22/92
  Was able to reproduce the "Sparcstation hang when CAM not plugged in"  problem.
There is a problem in the sbus control which allows the sctlfsm to clear the
error status before an hstop can be sent back from the ctlsvchip.  This should be
fixable using the existing pal.

  Verilog pseudo-code for fix:

  dfctnb ux1 (ux1q, ux1qn, fsmchip-39(tmint), sb_clk);
  or02d1 ux2 (fsmchip-10(hstop'), hstop(from ctlsvchip0), ux1q);

7/23/92
  Couldn't duplicate the above problem in simulation on the first try--
hstop is already asserted when the timeout occurs.  Will have to check
it out further after vacation.

9/16/92
  Infinite loop in Forth is begin...again

10/22/92
  Working on 24 MHz bug (bug24.exp).  Had trouble reproducing
problem at first; then made a loop to execute the experiment
continuously--this made the problem happen immediately.
The logic analyzer kept failing its front panel test, then
finally started working.
  I put probes on the following signals:
    pb_clk (pin 1 of lspatch)
    iosel (lspatch-5)
    pb_data[0] (u4-44)
    eofout/lsin (lspatch-18)
    eofin/lsout (lspatch-2)
    pb_eosi (u1-4)

Now the test runs continuously without failing!

11/5/92
  Working on the diags25.exp problem.  The system fails to iniialize with
the logic analyzer probes on; the one probe found be responsible is the
one on IOSEL.  Initialization could be done by switching the clock jumper
over to the sbus clock (this was on im1--20 MHz).  The problem now is that
a cam interrupt and a timeout interrupt occur when a scan-io read is
attempted.  The opcode transmission looks OK and I can't view the previous
transfer, so I'm not sure what the problem is.

11/12/92
  Working on diags.exp problem.  With NO lspatch and 25 MHz (async) clock,
a timeout occurs when a read of register 23 is attempted.  This is probably
the first attempted read since triggering on eofin=1 produces no trigger
during the test.
  There is no problem when we use the 20 MHz Sbus clock (sync).

  With the lspatch fix in and using the 25 MHz clock (async), the problem
is the same as above; failure to read register 23.

  Experimenting with trigger count of iosels--problem takes n counts
to occur where:
   925 < n < 935

this count is inconsistent; sometimes it takes [much?] less time to fail.


11/19/92
  Worked on diags.exp problem.  Connected logic analyzer to cam module
(layer 13).  Now diags.exp will not initialize even synchronously unless
I disconnect the probe on iosel.  Looked at iosel on scope and found
3 volts of undershoot!  We need to fix this.