raz@kilowatt.uucp (Raz- Berry) (05/04/89)
In article <170004@hplsla.HP.COM> tomb@hplsla.HP.COM (Tom Bruhns) writes: >> Refresh has always seemed so silly to me... nobody does the smart >> thing, which is to *monitor* the address bus and only supply refresh for >> the rows not accessed by the computer. So, the more loaded your computer >> gets the fewer refresh cycles need to come in and steal time. For todays rams (1Mx1's) typical refresh is 512 refreshes every 8ms. This means a refresh operation every 15 us or so. Let us assume that it takes two cycles to do a typical refresh operation (Ras before cas) and the cycle of this fictional computer is 150ns. This means that you take 2 cycles out of every 100 cpu cycles. That's 2% of all of the cycles going on the bus. It is debateable to spend a lot of time, and VLSI chip real estate just to get a 2% improvement in bus speed. You can play other games with arbritration logic to help this number without getting very complex. Such as giving higher priority to 'normal bus' requests and putting off refresh requests until the bus is free, when a simultaneous refresh and 'normal bus' request occurs. You can also keep in mind that you can miss one refresh time out (15 us), but if you hit a second one, and the first has not yet been serviced you'll need to grab the bus and do two refreshes back to back. Something else maybe your not aware of, to perform a refresh operation you don't have to send an address to the rams. All you have to do is ras before cas, and the rams take care of refreshing the correct row and collum and updating internal pointers to access the next row on the next refresh. I'm sure that you could remember the addresses that have gone by, and not bother refreshing them when the time came, I just wonder if it's worth it. >> That isn't too difficult a function to add in a VLSI refresh >> controller. > >Agreed! Hmm, If anybody would care to share their thoughts on how this could be accomplished, I'd be real interested in hearing them. I've been thinking about it and I can't come up with an _easy_ way of implementing this scheme. >Yet another very simple refresh technique: if your processor will be >dead while awaiting the refresh completion anyway, and you can tolerate >doing the once-per-whatever-millisecond refresh all at once, simply let >the processor do it for you. I worked this out on a 6502 some years >ago, letting a simple timer interrupt the processor (NMI, of course!) >to enter the refresh routine. By very careful design you can get the >time down to the number of RAS cycles required for refresh, plus perhaps >a little overhead for the NMI/RTI. Of course this would never do in a multi-tasking environment. Imagine locking out the blitter, copper, and all tasks for 512 cycles! What if you were in the middle of drawing a screen? >> -Matt >> ---------- >Tom Bruhns >tomb%hplsla@hplabs.hp.com -- Steve -Raz- Berry Disclaimer: I didn't do nutin! UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com "Fate, it protects little children, old women, and ships named Enterprize"