On Dec 10, 2007 1:33 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > Simple question (I hope). Why do we need auto-incrementing addresses > (mem_write_addr) in the oga1hq_io.v? 1) The HQ is better off > maintaining an internal register, 2) looking at your bright code, it > only expects the start address and as I recall than applies to PCI too, > and 3) there seems to be no internal use for an incrementing address it > in the I/O unit.
I haven't worked everything out yet, so there are plenty of redundancies. I just added a "start_write" signal from PCI so that we can pick up the start address before any data arrives. This gives us time to get the bridge to do an address cycle. So, that auto-incrementing counter does seem redundant. In fact, we'll probably want to require HQ to implement the bridge protocol directly. (Sorry about that.) We need to work out what that protocol will be exactly. 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. 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, 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. -- 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)
