On Dec 9, 2007 6:06 PM, Michael Meeuwisse <[EMAIL PROTECTED]> wrote: > Anyway, if we can define how many entries we want from a certain > address (I mean the FETCH instruction) we can do less fetches in the > video program. Although I'm not sure if that even matters.
Perhaps the best thing to do would be to have a small queue (16 entries) that takes an address and count from the video clock domain to the memory clock domain (fifos are the most common way to cross between clock domains, for us anyhow). This way, we can queue up more than one FETCH back to back. The arbiter pops a request out, counts down, pops another, etc. Right now, it can't manage more than one pending FETCH. > So all the video fifo has to do is be an 256-bit-wide queue? The > video controller will know when 1/xth is used up and can be re- > filled; it'll send a fetch at that point. The arbiter will work away > the addresses received in order. Exactly. > Why four address counters btw? Four memory controllers. Most things will deal with 32 or 64 bits at a time. The video controller works with 256 bits at a time. Since each memory controller may have different outstanding requests, the video requests to each have to be managed separately. For the return data, they're synchronized by the fact that the request is so far in advance. (So in reality, it's four 64-bit-wide queues.) > > Tell me if the "tags" thing above doesn't answer your question. > > I really meant a tag to let the arbiter know that we want x bytes > from an associated address. 256 bytes, 512, a few KB, etc. I'm just calling that the "count". It's always in words. > > I'm not quite following. Explain to me why you think we need more > > than one queue for video data. Maybe that'll help. > > Really because it's how I'd do it if I'd have to write it in C. Which > makes no sense in hardware. Even after all this time, I still have to actively fight against the software mindset in order to design good hardware. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
