On Dec 7, 2007 4:16 PM, Lourens Veen <[EMAIL PROTECTED]> wrote: > On Friday 30 November 2007 20:32:50 Timothy Normand Miller wrote: > [tasks] > > > > Did I miss anything? > > Task 1.3 is gluing the PCI module to the bridge and the SPI PROM > controller. The SPI PROM controller is not listed as a task, nor in > the "things we have" list. What's up?
Petter wrote this. It's long since tested and verified. I have restructured the to-do slightly and have defined a "PCI address decode" block that is designed to route accesses to/from the SPI controllers (there are two of them). There may need to be a manual merge of the working version with the one in the repository. This is also the case with mem and video. I can do memory. I'm hoping I can work with Patrick on video. That reminds me that we need a "special" kind of fifo for video. Since the data better be there in time (or else!), we don't have to qualify the dequeue into the fifo. That saves some logic and makes it faster. Another thing I haven't resolved is how to manage the separate memory controllers. For the demo, we had them working in lock-step, so we had all these 256 bit words flying around. For most things (except video!) we don't want that. One problem here is that we can quickly run out of block rams for these really big fifos. One place where I want to eliminate some fifos is for video requests. I want some address counters that LOOK like fifos. So instead of pushing addresses into a request fifo (or four), we have a small fifo that accepts an address and count to transport the request from the video clock domain into the memory clock domain. Then these counters appear as read request agents. Each memory controller spills its return data into the correct return fifo, and the video controller dequeues them at the right time. (This also implies that the arbiter has four schedulers. Oh, and we can't forget the "memory refresh" agent that is the timer for DRAM refresh.) Man, I'm so scatter-brained right now. Too many things to remember about one thing while I'm working on something else. You have no idea how glad I am to have all of you on the mailing list helping me to keep track! > > Bridge, arbiter, video and memory controller need to be wired up in the > big FPGA, right? Should that become a separate task? Something I've been calling the "bridge address decoder" routes config reads/writes to registers in the mem and video controllers and routes graphics memory reads/writes to the arbiter. The arbiter arbitrates between PCI graphics memory reads/writes and video controller reads (it's a scheduler). So we have two tasks here: Bridge decoder and arbiter. > About your picture: can the drawing engine bypass the arbiter, and if so > doesn't that cause problems when drawing engine and PCI or drawing > engine and video controller try to access memory at the same time? The memory controller can only be given one command at a time. There are four memory controllers, and each can get an independent command. The arbiter's job is to act as a scheduler for the memory controllers, arbitrating between PCI, video, and engine accesses. The engine talks to memory through the arbiter. Each module wanting access to memory is an "agent", and they have priorities. Note that OGA therefore constitutes something on the order of 9 agents (2 writers and 7 readers), maybe more. I forget exactly. PCI _could_ be modeled as two agents (read vs. write), but it's probably better to just completely serialize it. > Your email about HQ is marked to-do; I'm working on an extended version > of your picture as well. Bruce Adcock has done a detailed drawing in Onmigraffle. I'll post a PDF of that soon. You can use that for reference. > I need to read up on HQ, which will require a > fairly round tuit. I'm unlikely to have one available until December > 17th or so unfortunately (day job is still killing me, and I have an > OGP/OHF presentation on the 15th that I still have to start preparing > for). I think Petter has HQ under control. > Lourens > -- 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)
