On Monday 21 January 2008 23:55:24 Timothy Normand Miller wrote: > On 1/21/08, Lourens Veen <[EMAIL PROTECTED]> wrote: > > On Monday 21 January 2008 20:51:02 Kenneth Ostby wrote: > > > Lourens Veen: > > > >The S3 part, I think I have everything in the XP10 covered. > > > > > > > >Looking at it again, I guess I mainly don't understand the > > > > connection between the bridge and the arbiter. There is only > > > > one command queue, but the read end seems to consist of four > > > > separate parallel FIFOs, and I don't understand why. > > > > > > Is it the the four different memory banks you wonder about? > > > "arb2br_rdata_outA" and so forth? > > > > Yes. I understand that there are our memory banks, so it makes > > sense to have four FIFOs with return data, one for each of them. > > But then how come we only have one command queue? I can see sending > > the same command to each bank, but you'd have to send different > > data upon writing... > > There's one set of reads to request, but they get divvied up between > each memory controller. Not much point in more than one queue, > because we can't enqueue them fast enough to make any meaningful > difference. We use the lower two address bits in the command to > select the memory controller, when we pop a command out.
Right, that makes sense. > For the return, each controller is running independently, so they > can't put their return data into the same queue. When returning the > data over the bridge, we just pop words from the queues in the right > order (when they arrive). What about write commands though? Or don't we write to memory through the bridge? We'll have to upload textures somehow I guess. Lourens
pgpZdzdInVqnY.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
