[Open-graphics] Designing a CPU

[Daniel Rozsnyó]

>> 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.