On Wed, Jul 30, 2008 at 5:25 PM, Petter Urkedal <[EMAIL PROTECTED]> wrote: > On 2008-07-30, Timothy Normand Miller wrote: >> > * Do we keep the val_or_addr[0] indicator for inport vs outport? I >> > see no reason not to, we'll just revise hqio.asm at the end. >> >> You're using bit zero of the I/O space address to select direction? I >> see no problem with that. I think we have plenty of "space", and if >> having this extra indicator (besides the fact that the CPU knows >> whether it's reading or writing) yields a way to save logic or make it >> faster, then go for it. > > I though you had put that in. On second though I don't think a > direction bit in the address has any purpose. We could just consider > input and output ports to be distinct address spaces, so that reading > and writing to -0x20 are two different functions.
Works for me. > >> What happens if you do a reads on a write address or a write on a read >> address? (Not that we really have to worry about the consequences.) > > Right, I think we'd just have to throw away the lower bit if we went > with this scheme, since the authoritative source must be the > instruction. Let's just wire out the 9 bits we're going to have now. Actually, we can do more than 9. Even the scratch RAM could be enlarged if we needed. > >> > * We route out the port address and data i/o from HQ, something like >> > >> > module oga1hq( >> > ... >> > output [8:0] io_addr, >> >> IIUC, this can be [7:0], since the high bit is for scratch space and >> the low bit is direction. > > Yes, I picked 8 out of the air. I would also suggest changing the bit 9 > test on val_or_addr to bit 31, cf bottom of > http://readlist.com/lists/duskglow.com/open-graphics/1/5851.html unless > you've changed your mind. Then we don't have a predefined limit on the > range, and we can adjust the io_addr width as needed. I agree with you. Using the high bit allows us to keep scratch and I/O away from each other so they can enlarge as necessary without one having to relocate. > >> > One thing which is not clear to me is what to register at what needs to >> > be combinatorial. I think the critical part is reads. The input ports >> > needs to be decoded from the port address (val_or_addr) and fed back to >> > HQ and multiplexed into wb_val_o in one cycle, or is there another way? >> >> Well, can we get the address any earlier? If we could get a cycle >> early, we could pipeline the read MUX. > > I don't think we can. val_or_addr comes directly from res_o of the ALU, > which by the way already is MUXed after registration. Ok, then we'll just have to see how it goes. We'll wire it up and try it. -- 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)
