On Thu, Jul 24, 2008 at 2:15 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > >> Something I just realized: We need an enable/disable for the data >> cache in the address decoder. For memory accesses, it has a 16-word >> cache that we need to bypass when HQ is running. Sometimes we want to >> leave it on. For instance, in text mode, it doesn't hurt anything. > > As far as I can see from pci_address_decode.v, this is used for target > reads, right? So, as long as reads are pure, it doesn't hurt to leave > it on. Of course, HQ can always yield some side-effect on read, but is > that useful? If not, we could maybe reformulate the target read ports > of HQ to allow transmitting more than a single word, and thus benefit > from the cache.
That's the issue. If there were ever a side-effect on a read, we would need to put the address decode in single-word mode. I think there may be side effects for VGA graphics. >> Another way to do it is to encode the target into the port, like we >> did with byte enables. There are only two (maybe three, more on this >> later) targets that can be accessed via the bridge, memory and engine. >> So we just need two address ports: >> MEM_SEND_ADDR_MEM >> MEM_SEND_ADDR_ENG > > Done, and we just leave space for a third port. > >> Everything else stays the same. > > Well, I wasn't quite satisfied, but we can go back to the previous > version, if you like. I assumed the master command queue is the same as > the master write queue, so that the _FREE ports should be the same. > Thus, I did something similar to the memory port, including the names. > Now, all enqueuing ports are named _SEND and all dequeuing ports are > named _RECEIVE. What were you not satisfied? Previous version of what? Also, I'm not thinking much about PCI master right now, but I was thinking we should have three queues. Command, read data, and write data. The main reason to separate write data from commands is that we can now somewhat independently control write data generation and write address generation. We'll have a short counter for the address, and we need to track the address so the master can restart on terminate. There's also a lot of latency between issuing a write command (with count known in advance) and the data actually being consumed. The thing about the PCI master is that the writes aren't "reliable" in that we can just issue them and forget. The bus protocol allows the other target a lot of control. This is in contract to our bridge which is entirely a slave device, so there's no need for the extra flexibility. If this doesn't make sense, ask, and I'll try to explain better. -- 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)
