>> The memory interface timing is controlled by a bunch of timing
>> registers that count cycles. If you have fast memory, reprogram
>> the timing registers and it will go faster. I doubt DEC would
>> intentially program them to be slower than what's required by the
>> DRAM. Unfortunately, those registers are write-only, so you
>> can't just read them back and find out what they're set to.
Jeff> That's fine for setting the system up to use 70ns, 60ns, or
Jeff> whatever DRAM. What we were talking about, though, was the
Jeff> *cache*. A huge secondary cache isn't going to be nearly as
Jeff> helpful if it's running at 33 MHz... And at this point we're
Jeff> both just speculating since we haven't provided any facts
Jeff> about how fast the memory bus (which the 2nd level cache is a
Jeff> part of) runs on the noname boards.
Incidentially, I was talking about *memory interface timing*, which
does include the bcache interface. If you'd look at the 21066 hw ref
manual, you'd find CAR (cache register). Among other things, it
contains a b-cache read-cycle count, write-cycle count, write-hold
time field. Read-cycle count is in the range 3..11, write-cycle count
in the range 1..9, write-hold time 0..1. So, this gives:
166MHz: 233MHz:
read-cycle time: 18-66ns 12.9-47ns
write-cycle time: 6-54ns 4.3-39ns
write-hold time: 0/12ns 0/8.6ns
I'm not sure which frequency you want, but the read frequency would be
55MHz @ 166MHz and 76MHz @ 233MHz. Of course, provided your cache is
fast enough.
On my Noname board (166MHz), the read cycle count is 5, write-cycle count
is 2, write-hold time is 2 cycles (that's with 15ns caches). This gives:
read-cycle time: 30ns
write-cycle time: 12ns
write-hold time: 12ns
You may say that's too high for 15ns cache RAMs, but I'm not sure what
exactly those 15ns refer to and reducing the times results in a
non-working system (actually, I think the write-hold time can be
reduced to 0ns on my system, but this may not be safe and the
performance gain is minimal).
--david