On 2007-12-10, Timothy Normand Miller wrote: > Here are some things we need to figure out. PCI and the SPI > controller (iirc) both run in the PCI clock domain, so I am making the > address decoder do the same.
By address decoder I assume you mean a 32 bit register which keeps track of the current address being processed by PCI, and which can self-increment within the size of a burst, but otherwise is updated either from PCI or HQ? > However, HQ and the bridge will be in > another (100MHz or whatever we can manage). Without HQ, we would put > fifos between the decode (I called this 'glue' elsewhere) and the > bridge. With HQ, those same fifos would be read by HQ, and HQ would > therefore read and write the bridge protocol. So, the idea is to do this in oga1hq_io? As discussed before, we don't want to pass data words though HQ, so what I'm imagining is that HQ can put oga1hq_io in a state where data words are passed though in either direction. It will need to know when to leave the pass-through mode, and since PCI transactions can be aborted, I guess that information must come from the PCI controller. > So, this is helping me with the bridge. I'll do some clean up on that > and write a module with a fifo interface. We'll have the decode talk > to the fifos and then fit HQ in there next. Okay. Now that the PCI fifo is tightly coupled with the HQ I/O, it should probably be worked out before HQ I/O. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
