From eddie_weaver%10@hpg200 Tue Nov 22 06:45 MST 1988
Received: from hpfcfa.HP.COM by hpfclr.HP.COM; Tue, 22 Nov 88 06:45:23 mst
Received: by hpfcfa.HP.COM; Tue, 22 Nov 88 06:29:37 mst
Full-Name: 
Date:        21 Nov 88 18:22 -0600
Subject:     MINUTES FOR CACHE DR ON 11/17/88 EGW
Message-Id:  <15930628.0.0.0....@.HPDESK>
X-Hpdesk-Priority: 3
X-Hpdesk-System:  259
To: dick_carter%ux@hp1900, ruby_fidler%40@hpd500, jim_finnell%ux@hpunix,
        rob_horning@hpfcfa, doug_hunt%ux@hpunix, bill_kern%10@hpg200,
        vahid_lajevardi%10@hpg200, danny_h_lu%10@hpg200, dean_mulla%ux@hpunix,
        ron_nicholson%ux@hpunix, ken_takemoto%10@hpg200,
        chi-lie_wang%10@hpg200
Cc: dave_burns%10@hpg200, felix_guerra%10@hpg200
From: eddie_weaver%10@hpg200
Sender: eddie_weaver%10@hpg200
Received: from hp4000 by hpfcfa; 22 Nov 88 6:24:11-MST (Tue)
Status: R



Minutes for Lego Cache Design Review  11/17/88                egw

Attendees: Dick Carter         Ken Takemoto        Dean Mulla
           Doug Hunt           Vahid Lajevardi     Jim Finnell
           Rob Horning         Danny Lu            Bill Kern
           Ruby Fidler         Chi-Lie Wang        Eddie Weaver
                               Ron Nicholson

    Format of minutes - This is a running log of the notes I took at
                        the meeting. I will use "*" to designate
                        follow up items or major issues.

** ACTION ITEM for all attendees: Return comments on documentation (HDD, ERS,
         schematics, etc.) to Ken so these can be improved in next pass.


Morning session: Circuit design and PAL design

* 1. General concern: PALs are maxed out. No room for late changes. This
     was a problem in Tioga design. Should design be changed to free up some
     terms?

2.  Q: Any tristated control lines? If so are they driven high before they
    are tristated? A: RDY is tristated and is driven high before tristate.

3.  Q: How are 32MHz state machines (SMs) synched with 16 MHz SMs since there
    are two possible alignments? A: ALE signal syncs machines.

* 4. STATE SM is not grey coded. Could be grey coded if R1 and A1 states
     switched.  Follow up: Need to check product terms and reset. Also are
     any control signals combinatorial outputs based on STATE outputs? If
     not then this becomes a don't care.

* 5. Notes from discussion in break: Lots of concern about battery backup
     on cache. Need to verify timing of power supplies on power up and power
     down. Reset is NOT powered by +5S. etc.

6. Q: Is coprocessor fast enough to match Stirling timing? A: Yes, although
    Rocket is being rolled to match Stirling exactly on which edges data is
    sourced on.

* 7. CLN and VLD are not parity protected. Usually not hard to do and would
     be recommended. Tag parity is recalculated when VLD and CLN are written.

8. Q: What happens on double word store to I/O space? A: This is an illegal
    transaction and is converted to a legal transaction in the RCMD PAL.

* 9. Verify that a Flush Entry with an I/O space address, still results in
     a flush of the cache line!

10. Confusion on LDWC to I/O space. Verify this is not allowed.

11. Q: Does Stirling always start with a quad word aligned address on a QWIF?
    A: yes, but if it didn't the cache controller would force 00 word address.
    Similarly, double word alignments are also forced.

12. RCMD: How does 16MHz RCMD stay in synch with 8MHz Rabbit? Done in
    Rabbit. Actually, two possible cases exist and result shows up in
    performance studies as a 1/2 cycle penalty.

13. Aside from main discussion: HPMC can get set from one of 3 sources.
    It isn't reset unless all three sources are cleared. Is there a race
    between clearing and setting such that the circuit can lock out future
    HPMCs?

14. Q: Can we simulate bad parity? A: Yes with test bits.

* 15: General comments on how to improve readability of schematics:
         a. All inputs from left. All outputs to right.
         b. Some type of page references to find signals
         c. Flag primary inputs (sourced external to the block)
         d. Companion guide with all signal names and their functions
         e. Differentiate PAL inputs and outputs clearly (left, right) or
              (I,O,Q).
         f. Disgruntment about IEEE format but will live with it.

16. Incomplete schematics on 3s6p2. Breaks in wires - 2 places. (NABUSD)

* 17. Data Parity Rams

         a. Dangerous to tie three unused outputs together since they may
            drive against each other assuming random startup state. Separate.

         b. Why 4 SRAMs? Why 4kx4 vs. 4kx1? Could use Read/Modify/Write.

* 18. Transceivers

         a. How long are buses tristated? (esp. without pullups) Historical
            problems with looking at a tristated bus with a transparent latch!
            Parts can oscillate = high power drain and excess system noise.

         focus: * 573's driving tristate to A bus
                * 646's driving tristate to SAD bus (esp. byte access)

         recommend: 1st  disable outputs when inputs tristated
                    2nd  someone always drives bus
                    3rd  pullups on bus

* 19. Can 573's drive the load on the address bus?

20. SRAM timing specs need derating for loading.  This derating should be
    added to the critical path timing analysis. Manufacturers won't
    guarantee specs.

21. Q: Does anyone have experience whether TTL leakage on bus will effectively
    pullup the bus? Do pullups add excessive load? (characterization to
    follow up)

* 22. Timing problem: NTWE falls and NTCS rises off of the same clock edge
      in the middle of the data cycle. If there is skew between them then
      problems!

23. Future additions:

    a. Would be nice to have a "cache off" feature to bypass cache.
    b. Would be nice to log more detail on a cache parity error to
       be able to pin point RAM. (not just tag vs. data)

24. Historical problems with other designs:

    a. Resets not synchronized
    b. Transceivers oscillate
    c. PAL startup states cause glitch
    d. 646s switched to transparent mode with same signal that clocks part
         caused glitches in data
    e. Clock problems when layout did not match geometry modeled on Spice.
    f. With FCT parts, under and overshoot required bus terminations
    g. Note: Firefox and Silverfox have schottky clamps on their address
         bus. Lego may be OK since TTL has its own clamping.
    h. Design error did not impact correct function but did impact performance.
         Was not caught in simulation. Incorrrect bypassing of I fetch on miss.

25. Q: Concern about thrashing of caches because of unified I/D cache.
    A: Stirling's internal cache allows forward progress.



AFTERNOON SESSION:  Transactions and corner cases

1.  Note: error in I/O store diagram. Data should be valid for two
    CPU cycles. Follow up.

2. Q: In the sequence of an I/O Write followed by an I/O Read, where do the
         machines halt? A: There is no queueing in Rabbit except for R16, W16
         and CLR 16 transactions. (may be this is a request to look at this
         corner case to show sequence  more clearly)

3. Clean Miss:

    a. Q: On back-to-back transactions, what starts the next transaction?
       A: ALE starts but uses a trick to hold off STATE sequencer.

         (aside: what if next transaction in cache command?)

    b. Note: logic equations on STATE SM diagram are not complete. (e.g.RDY)

    c. Q: Why doesn't NTWE come back high on Clean Miss timing diagram?
       A: Shortage of terms? Also "OFF" signal (3s6p2) used.

4.  LDWC: There are other ways to leave cache state after LDWC. Indigo left
    cache line flushed.

5. Problem (?) noted: Flush buffer stall situation. NFLUSH not asserted for
         I/O transactions. ( ed. I don't understand this point)

6.  NBUSD Description:

    a. Additional handouts of schematic update: Page 1) is  patch to latch
         START signal. Page 2) is circuit to separate the two sources of
         NFBWE ( single word I/O and quad word flush). Page 3) changes the
         address selection to still be valid when CCOD is delayed.

    b. What is the performance impact of holding off Rabbit?

    c. Other ideas: Rabbit arbitrates for the bus

    d. Testing has the burden of considering the two types of NBUSD
         for all cases.

7. Simulation:

    a. Will all fixes be simulated? Yes and also preferrably prototyped.

    b. For autochecking back to back sequences, can a pattern of register
         and memory contents be used as a fingerprint to verify correct
         completion of simulation?

8. Note: correction to design: Rabbit will only assert Reset on shorter
    duration on special case of Cache abort - only.

9. HPMC: Will Stirling do one more instruction before HPMC on cache abort?
    There is probably no way to prevent this since ERROR can come late from
    NIO.

GENERAL COMMENTS - closing statements

1. Note: 3s6p4: tag parity is disabled - clock is disabled ( fix in PP)

2. Data parity implementation is scary. A lot of clock qualification going
    on. Tough to prove no glitches.

3. Stores: Is there a potential conflict between tag source and output?
    Where does the mux get turned on? (i.e. turn on drivers to Tag Rams)

4. Things to check in characterization:

    a. "Walk" through most signals on the board with o'scope to look for
         problems.
    b. Verify setup margins on signals to clocked pals
    c. Focus on critical paths
    d. Focus on potential for race conditions
    e. Contention between signals should show up on signal waveforms

5. Philosophical discussion of when do you know you are done. Schedule
    driven, prototypes pass tests, simulation suite passes. Recent products
    where SW was the critical path left lots of time for HW testing. This may
    not be the case in the future.


Conclusion: Thanks again for your time and effort. Hopefully, the next pass
    of the Lego board will be bug free and ship in '89. If so, thanks in
    part to each of you.


