| Summary: | reservation station "feedback" for further processing (FP64) | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Luke Kenneth Casson Leighton <lkcl> |
| Component: | ALU (including IEEE754 16/32/64-bit FPU) | Assignee: | Luke Kenneth Casson Leighton <lkcl> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | CC: | libre-soc-bugs |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| NLnet milestone: | --- | total budget (EUR) for completion of task and all subtasks: | 0 |
| budget (EUR) for this task, excluding subtasks' budget: | 0 | parent task for budget allocation: | |
| child tasks for budget allocation: | The table of payments (in EUR) for this task; TOML format: | ||
| Bug Depends on: | 106 | ||
| Bug Blocks: | 116, 48 | ||
|
Description
Luke Kenneth Casson Leighton
2019-07-25 15:35:14 BST
Investigating for several days, the combinatorial MultiIn/Out code was being used, and is not working. The reason it turns out is because when used for ReservationStations, the multi in/out code only needs to send a single value. Unfortunately, for pipelines, the "valid" signal travels with the data, but the "ready" signal is sent on the PREVIOUS cycle. Therefore if the ready is sent to one multi-in sender but on the next cycle the "in" is flipped to a higher priority input, the data from the sender to which the "ready" was sent is irretrievably lost. The solution therefore is to have latches on every input, and to have the multiplexer read first from those then go back to combinatorial routing. It *might* be possible to buffer just the one data set, because only one input will have been told that it was ok to send data. |