On 7/11/06, Daniel Rozsnyó <[EMAIL PROTECTED]> wrote:
Timothy Miller wrote:
For me, it would be very interesting to see some memory design, how to share the memory read/write. Once I was trying to create a framebuffer out of TTL, but the design was memory->lcd only, I never understood how are the writes made. Since my RAM ran on the same freq as the output, I thought that doubling the data bus width makes some space to insert writes, but it was just too complicated to share r/w and I think, that's not the way how it has to be done. Is there any theory about designing such a things (web, books)?
What I've had to do in the past is something like this: You have multiple agents trying to access memory at the same time. Give them each a priority. Combine that with some logic to determine when accesses should be allowed and some heuristics about when each should be (de)selected. Start with a state-machine. Say you have one writer and two readers. Then have a 3-bit state called 'active', where each bit corresponds to an agent. On any given cycle, check to see if a higher priority agent wants the memory (so you get one cycle latency on switch-over), and change the state. If an agent has no request, then a cycle later, switch to another agent with lower priority. Let's say agent 0 is video, so it must always have priority. Then it should always get control when it has requests, no mater what. But let's say agents 1 and 2 often read and write the same areas of memory (like bitblt). We could make them have the same priority, so we only switch between them if the other has no request. Add to that a heuristic to deal with memory row misses. Figure out how many bits correspond to a column address and take the next higher few as a row address, but not all of them, because it's a heuristic. If the key changes, we assume we would cause a row miss, so rather than necessarily allowing that to happen, switch to the other agent if it has the same key. If you want concrete examples, I'll need some more time. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
