On Tue, Aug 19, 2008 at 11:30 AM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > On 2008-08-15, Timothy Normand Miller wrote: >> I looked. It's worse than that. It assumes that you're going to read >> at least 8 words starting on an 8-word boundary. I designed it under >> the assumption that memory reads would always come in 16-word blocks. >> But I THINK that the real enforced granularity is 8. Also, the count >> is 7 bits, and the address auto-inc only considers the lower 7 bits. >> (Actually, since it's doing even numbers, only bits [6:1] are >> inc'd/dec'd.) So I think you could safely read up to 15 blocks of 8 >> (120 words), as long as you don't cross a 128-word boundary. > > This is going to consume a fair amount of program memory. IIRC, we may > terminate the read at any point and let the host re-issue a read for the > missing part? I'm thinking that a practical simplification is to > terminate the read at the next 128-word boundary. Moreover do we gain > anything by reading more than will fit in the cache, which as far as I > can see is 32 words? If not, maybe we should cut on a 32-word boundary.
I wouldn't read more than 8 or 16 words at a time anyway. That's how big the hardware cache (in pci_address_decode) is anyhow. Although HQ doesn't have an explicit way to terminate reads, the PCI controller will automatically time out, and the host will re-issue the request. A full cache line is fetched for every cache miss. So for random access, lots of time is wasted. But sequential is more common. It's best to pick a cache size that's a good compromise. > >> > Another goofy thing: It seems tricky at best to unroll the >> > transfer-loop for target write. The reason is that we only know the >> > number of queued commands, but what we need is the number of queued >> > write-data commands. Any idea? >> >> That is tricky, and we may have no good answer for that. >> >> I suggest we do nothing about it right now. We should get a working >> revision out, then we can go back later and see if we can do anything >> clever with the CPU design. > > Okay, we don't unroll, but we can still avoid sending an address for > each write request. You can, although the check to decide whether or not to send an address would probably take longer than just sending an address. It depends on what you're doing. For instance, if you get an address and some writes, then you don't get anything, so you go on about some VGA business, then you get another write without an address, you'll have to reissue the correct address (where PCI left off), because you may have changed it to access some memory for what VGA needs to do. >> One thing I've thought of is going to wide instruction word. Two >> instructions are side-by-side, and you have two register files and two >> ALUs. On a fetch, you can fetch any two regs from file A and any two >> from file B and then cross them over in any way you like to the ALUs, >> then on writeback, you can do one write to each file. It's like two >> processors in parallel but with the ability to cross registers over >> between them with restrictions. Now we can deal with some of the >> inefficiencies, if we can schedule instructions properly. Obviously >> only one instruction could hold a branch (but it could be either, and >> we could allow it to be both if only one could compute to true). > > That would probably help. We could probably just widen the data path > inside HQ. We could probably drop the adder from the second ALU, or > replace it with a 16-bit decrementer if needed. Comparisons for > equality can be done with xor instead of rsub. However, this implies a > fair deal of rewrite both to RTL and the assembler, and make the HQ more > difficult to program with 3 delay slots and register dependencies, so we > should be sure we really need it and that it will solve the problem. By no means would this arch be easy to program. -- 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)
