Retrofitting cache--any issues?

[Logistics]

While researching some ancient DIP20 cache for a 486 board, I started thinking about adapters, specifically some to convert SOIC and SOJ to DIP, which I had come across on the net. I ended up finding, iirc, an SOIC chip which was pin-compatible with the original DIP. However, rather than being around 100ns, it was more around 40 or 50 nanoseconds.

It may have also required 3V rather than 5V, but that aside will the much faster cache cause timing issues or is it simply bottle-necked by the chipset feeding it? (Assuming the cache is now much faster than the system can even utilize.)

[Compgeke]

Re: Retrofitting cache--any issues?

The faster cache won't make much difference. I have some 20ns cache on my '93 486 board (Shuttle HOT-409) so I don't see why 40 or 50 would make much of a difference over 100. I believe my HOT-433 has 10ns cache but that's also a later board with PCI and entire onboard I/O and such.

[mockingbird]

Re: Retrofitting cache--any issues?

Better ask over at Vogons. The depth of knowledge of retro computer gear there is astounding.

[Logistics]

Re: Retrofitting cache--any issues?

The faster cache won't make much difference. I have some 20ns cache on my '93 486 board (Shuttle HOT-409) so I don't see why 40 or 50 would make much of a difference over 100. I believe my HOT-433 has 10ns cache but that's also a later board with PCI and entire onboard I/O and such.

Are you sure they were 10ns? Because usually chips that were 100ns were etched -10, 90's were -9 and so on.

[eccerr0r]

Re: Retrofitting cache--any issues?

the 3.3V/5V issue may be a bigger problem if the chips are not tolerant of both voltages.
I'm not sure there really were 100ns SRAM cache chips because DRAMs were readily available faster than that, even in the 486 era (and 386 era as well, I do recall using 70 or 80ns chips then)... 100ns SRAMs typically ended up being used for embedded applications...

If the cache controller could be made to take advantage of the faster chips then possibly it could be made faster, but a lot of the times the capability of doing so is not available to the user. Ideally the SRAMs are fast enough to make one bus transaction every cycle (at least then), if it can already do it, then it doesn't help to go faster. Based on the bus frequency of typical 486's it sounds like you have to be in the 10-20ns range for SRAM to keep up with bus frequency at 33MHz (also keep in mind of the cache controller latency) so it's reasonable to be down that low.

[Logistics]

Re: Retrofitting cache--any issues?

Yeah, I was confusing the chips on 30-pin simms with cache ic's.

But the formula for nanoseconds to megahertz is 1 / ns * 1000. So for example, you needed 30ns cache to run at 33MHz.

[eccerr0r]

Re: Retrofitting cache--any issues?

Yes if calculating cycle time, at 33MHz bus frequency, the cycle time is about 30ns. However as stated before, cache controller latency - it needs to at least add in a mux plus control logic - 30ns is not fast enough and you will need 10-20ns chips. The request comes out of the CPU, goes to the chipset, leaves the chipset, goes to the cache ram, back to the chipset and then back to the CPU.

Even worse is if the tag needs to be accessed every cycle and you have to do two memory lookups every cycle. However I don't think many caches are done this way because the chip requirements would be ridiculous - and they tag a line at a time and you only pay a tag latency lookup once every few cycles and suffer misses a bit more often. Newer CPUs cheat by pipelining the tag lookups but you can't exactly do this with old CPUs (486 and older).

Lots of things happen behind the scene...