Article View: comp.arch
Article #12097Re: HP PA-RISC Cache Question
From: Mark Forsyth
Date: Fri, 14 Jun 1991 15:41
Date: Fri, 14 Jun 1991 15:41
48 lines
2727 bytes
2727 bytes
>From: lupin@jetsun.weitek.COM (Edward Lupin)
>
>I am having a hard time understanding how the HP PA "Snakes" cache can
>operate at 66 MHz using only asynchronous SRAMs external to the CPU.
>Referring to the timing diagram below, phi1 and phi2 are the two-phase
>66 MHz clocks. Latch clock is 90 degrees out of phase with phi1,
^^^^^^^^^^^^^^^^^^^^^^^
Not correct.
>easily achievable with the 132 MHz input clock.
>
>Assuming that latch clock to address delay is no less than 5 ns, and
^^^^^^^^^^^^^^^^^^
Not correct.
>data set up is no less than 2 ns, only 8 ns remains for the SRAM access
^^^^^^^^^^^^^^^^^^ ^^^^
Not correct. Not Correct.
>time, less, if there is any attempt to provide some margin. Eight ns
>access is much faster than any CMOS "off-the-shelf" SRAMs with which I
>am familiar.
The design uses 12ns standard asynchronous SRAMs for 66 MHz, as described
in published technical papers. Lower frequency operation can use slower
SRAM devices. And yes, the caches are accessed once every clock cycle.
BTW, there are announced 8ns devices in 64kbit density and 10ns devices
in 256kbit density.
>I suppose the address could be output on the positive edge of phi1,
>yielding an extra 7 ns for SRAM access time, but then the address would
>change for the next cycle before the data is latched into the CPU. How
>could HP guarantee the SRAM's minimum address to data invalid delay?
>
>Have I made a mistake somewhere? How does HP do it?
>
I don't think that anyone at HP is willing to describe any unpublished
technical details, especially in an area considered to be a competitive
advantage. Unfortunately in this respect, the RISC processor market is
still a competitive business. The only thing that can be said is that no
laws of physics are being violated, that there is plenty of timing margin
to insure reliability and manufacturability, and that the viability of
large primary caches (off-chip) for high-performance RISC was generally
written off prematurely by some of the industry (or at least according to
technical articles published in the last couple of years).
- Mark Forsyth (maf@hpesmaf.fc.hp.com)
disclaimer: my opinions, not HP's
Technical Details
Message-ID:
<8840036@hpfcso.FC.HP.COM>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!mafReferences:
<1991Jun13.221247.6855@jetsun.weitek.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!maf From: maf@hpfcso.FC.HP.COM (Mark Forsyth) Newsgroups: comp.arch Subject: Re: HP PA-RISC Cache Question Message-ID: <8840036@hpfcso.FC.HP.COM> Date: 14 Jun 91 15:41:52 GMT References: <1991Jun13.221247.6855@jetsun.weitek.COM> Organization: Hewlett-Packard, Fort Collins, CO, USA Lines: 48