On Wed, Jul 23, 2008 at 2:42 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > On 2008-07-23, Timothy Normand Miller wrote: >> When the address decode logic gets a write from PCI, first it gets the >> address and pushes that into the queue, with some flags indicating >> that this is an address, and along side are flags that indicate the >> target (engine, memory). The address is a byte address; only for I/O >> space will the lower two bits be non-zero. The next thing it does is >> push the data word onto the same queue, with some flags indicating >> that this is write data, along with the byte enables. >> >> Since 38 bits are required to make sense of the queue entry (for data: >> 32-bit data, 4-bit byte enable, 2-bit type), and HQ is 32-bit, either >> we need to expand HQ to more than 32-bit, or we throw more ports at >> it, with one port triggering a dequeue when accesses (probably the >> data/address portion). > > Thanks for the explanation. Then, I suggest we use one data port and > one byte-enables port.
I was thinking that we should have one port that indicates type (address, read count, write data) and byte enables or target. The other port would be the data/address port and also dequeue. 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. >> > Assuming e.g. byte enable are encoded in the top of the address, the >> > code may look something like (omitting count logic) >> >> For the command queue, an address entry contains the following data: >> >> Address -- 30 bits >> Type -- 2 bits (indicating that it's an address) >> Target -- which memory space >> >> The following memory spaces are valid >> >> parameter TARGET_CFG=0; >> parameter TARGET_ENG=1; >> parameter TARGET_MEM=2; >> parameter TARGET_PROM=3; >> parameter TARGET_IO=4; >> >> HQ can't get CFG or PROM, but it can get any of the other three. >> (Actually, I think IO isn't connected right, but we can fix that >> easily.) > > When writing these out on the bridge, I assume the target must be > encoded in the address. This is what you mentioned we could do before > HQ, right? I can see there is one target (maybe PROM) which must be > filtered out before we have 2 bits that can fit in the address. Either > way works. 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 Everything else stays the same. >> > where MEM_WRITE_DATA_xxxx are really commands. Yet another naming >> > scheme: >> > >> > MEM_CMDQ_FREE >> > MEM_SEND_ADDR >> > MEM_SEND_READ_COUNT >> > MEM_SEND_DATA_0000 >> > MEM_SEND_DATA_1111 >> > MEM_READQ_AVAIL >> > MEM_READQ_DATA >> >> I kinda like the second one better. > > Yeah, it was growing on me too after sending the mail, maybe because it > clearly distinguishes the active command ports (by the verb "SEND") from > the passive ones (by the nouns "CMDQ" and "READQ"). Yes. -- 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)
