On 3/17/07, Daniel Rozsnyó <[EMAIL PROTECTED]> wrote:
>> Also, we need ways to handle writing to full fifos and reading from
>> empty ones. One way would be to have the instruction block, but being
>> able to pause the pipeline adds extra logic and complexity that we
>> might like to avoid.
>
> OK so do you want an error return or do you want to query for size, or
> do you want interrupts? I think being able to query the size of a fifo
> would be best.
>
I have an idea for empty fifos: forwarded ignore flag. Each data word
(register, alu in/out) will have one more signal - a bit indicating if
the data is valid or not. Then on the end, you might get an ignored
write to memory/mmio. If you want to branch depending on such an
optional value, then a default choice must be given by the instruction
(to which direction jump, if the value is invalid). The flag will
propagate as the null value does in sql expressions in databases (if
either operand is null, the result is null).
Pro: pipeline is not stopped, no polling in nanocode
Cons: power consumption, logic complexity?
For the full fifos we'll have to propagate the impossibility of write
back to the source, so maybe a near-full signal on the destination fifo
could issue a "full" state on the source fifo's input side. The
back-routing would be set ad-hoc by the nanocode, as the functional
units will be linked. If it's too abstract, I can draw an image if it.
I like your ideas. I'm also thinking we might want to consider making
it possible for MMIO to stall the pipeline. I have a way to do it
where the busy signal is registered, so it's not terrible. Having a
read or write block has certain advantages that MAY be worth the extra
logic. It's also especially not so bad if only one stage is able to
cause a stall.
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Favorite book: The Design of Everyday Things, Donald A. Norman, ISBN
0-465-06710-7
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
