[libre-riscv-dev] [hw-dev] Re: 6600-style out-of-order scoreboard designs (ariane)

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Wed, May 22, 2019 at 12:05 AM Mitchalsup <mitchalsup at aol.com> wrote:

> > i found that if only the "CU Busy" signal is used to switch off an
> > individual unit going into the priority picker, that just (spuriously)
> > results in re-assertion on the next clock cycle, which then re-asserts
> > GO_Read on the next, which causes it to be de-asserted again: flip
> > (bounce) flop (bounce), flip (bounce)
>
> There should be SR-flops in the FU and another set of FU flags in the CU

 yes, i'm going to have to add those, because looking at how
Branch-speculation "schroedinger" wires are added
(shadow/success/fail) to the Function Unit, they depend on having
those Go_Read-related and Go_Write-related flip-flops.

> The CU SR-flops should be 1 (or more) clocks "down" the pipe from the
> FU flops. The only part of the SB that the CU interacts with is the Release_
> Request_FU signal.

 this handles *write* only.  what i'm trying to communicate
(unsuccessfully so far) is that a similar problem exists on *read*,
and that there is a real need for having a Release_Read_Request_FU.

 i'll try again, below, using similar style timing diagrams, i'll do
so in a separate message.

> We need this signal to be delayed at CU for the CU
> dependent timing of the instruction.

 yes.  found that one out :)

> > this *reasserts* the "readable" flag... *even though the row of
> > dependency cells has done its job*.  result: flip-flopping of the
> > Go_Read flag.
>
> Once an FU gets a Go_Read_FU the Read reservations are removed
> making that FU unable to assert Readable or get another Go_Read_FU.
> {That only works if there are no holes in the logic.......}

 there's a hole in the logic :)  the clue was the diagrams from
Thornton Figure 79 (and 80 i think).  without a
Read_Request_Release_FU signal (separate and distinct from
Release_Request_FU aka Write_Release_Request_FU) the case where there
are *no* Read Reservations cannot be distinguished from an idle state.


> > This is what the 4-input to the 8 decoder NAND gates is supposed to do.
>
> sorry, am slightly confused: i'm not using NAND gates anywhere, only
> AND, OR, NOT AND NOR, i haven't seen NAND anywhere in the diagrams.
>
> did you mean the priority picker?
>
> In the logic diagrams there are 8+4=12 gates that decode the 5-bit register
> number into 1:32 assertions, This decoder is enabled/disabled by the second
> SR-flop in the FU. not being seen after the Issue_FU cycle. IT is clear in the
> logic diagrams. A disabled 1:2^k decoder asserts 2^k zeros.
>
> So after Issue_FU and before Go_Read_FU read reservations can be asserted.
> After Go_Read_FU there are no read reservations to be asserted anymore.
>
> Also note: The FU remains Busy until it gets the Go_Write_FU signal. There are
> 3 periods of time captured by the 2 SR_flops; a) the time when the FU is NOT
> Busy (nB), b) the time the FU is Busy and waiting to Read (wR), c) the time
> between Go_Read and Go_write.
>                   ___________
> Issue____/              \ ___\_____
>                         _______________________
> Busy   ______/                                              \________
>                        ___________
> READ  _____/                      \_____________________
>                                         ___________
> GRead _____________/              \ ___\_____
>                                                  ___________
> RRel_FU________________/               \ ___\_____
>                                                                  ___________
> GWriteFU________________________/              \ ___\_____
>
> Issue_FU        causes both read and write reservation to be asserted
> Go_Read_FU causes the read reservations to be deasserted.
> Go_Write_FU causes the write reservations to be deasserted and clears FU_Busy

 ok.  i'll write a separate message with similar diagrams
demonstrating the (two) problems.

 l.