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. > PCI allows per-word byte enables. The c/be signals are the command on > an address cycle but the byte enables on a data cycle. So, I recall wrongly. Then we'll have to read two PCI ports per write, but that's at most 3/2 more HQ cycles. > > 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. > > 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"). _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
