[Open-graphics] HQ stub in place

[Timothy Normand Miller]

On Wed, Jul 30, 2008 at 5:25 PM, Petter Urkedal <urkedal at nbi.dk> 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