[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] freeze signal



Yann Guidon a écrit :
<...>
> > Yep, you must insert a delay so you must at least stop the current flow
> the "current flow" can't be stopped once it is "issued" (sent to the EUs
> and inserted in the writeback queue). The "slot" is detected at decode
> stage and delayed at issue stage and before (decode and stage).
> Otherwise, we would need to insert heavier and slower pipe registers
> all over the chip and reduce the frequency :-/
> 
> > or you could try to predict the cas e (but i wait an algorythme for
> > that).
> it's a simple lookup table.
> IE :
> - when you see opcode = OP_ADD with 64-bit data and no carry (2r1w)
> - when you see that all the required registers are available (either
> in R7 or on the Xbar)
> - when you see that there is at least one free slot available in 3 cycles
> in the future
> 

That's the last point the problem, how do you do that ? For me it's an
allocation (schedule) algorythme, a typical np hard problem.

> => then you can issue the instruction (ask another instruction from the
> fetcher + validate the ASU + mark the destination register as "dirty"
> + allocate the slot in the scheduling queue).
>

So you continue or stop the flow :D
 
> IF opcode=OP_ADD AND ( source or destination register is not ready
>  OR no free slot in 3 cycles) then : delay 1 cycle and try again.
> 
> I don't know if you accept this as an "algorithm" but it's what
> it does and you can see that we need 1 LUT and 1 scheduling queue.
> For the first FC0s, i am merging the "register scoreboard" with
> the queue, but i will use another technique for superscalar cores.
>

Yes it's an algorythme but not enough precise !
 
> > In the first case, i need a signal to stop the pipeline (or stop
> > to produice output) to insert an empty slot.
> The "slot" is inserted at decode/issue stage. the rest of the
> units can do their work without caring, as long as their latency
> is deterministic (and can be encoded in the opcode LUT which
> also tells the issue stage which flags are meaningful for the decision
> whether to issue or not).
>

So you'r enter all the information in the lookup table (wich register
are in use at what level, the different latency of the unit, the
different thoughtput, the type of unit,... ). I think it's a bit to much
!
 
> > nicO
> WHYGEE, going to sleep, now :-)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/