[Libre-soc-dev] litex ecp5 progress, regfile-compunit arbiter needed.

[Luke Kenneth Casson Leighton]

started this as an update, realised it needs discussion.

fighting with litex and libresoc to get over a critical 50mhz threshold
needed to initialise the DDR3 IC.

efforts to compile other litex designs with 64 bit wide buses led to
further problems.

it might be necessary to add a nmigen-based 64-to-32 "thunker" that then
allows a well-tested litex codepath to be used.



thinking through a design of a new component which arbitrates a synchronous
connection between regfiles and CompUnit Managers.

the problem is this:

* CompUnits "fire" combinatorially into a pipeline / FSM, the moment that
GO_READ goes hi.
* all Regfiles are currently designed to be *combinatorial*

this causes an extremely large combinatorial critical path chain that
extends right the way from the instruction issue phase all the way through
the POWER9 decoder, the regfile, *and* the CompUnit, right the way into the
first stage of every pipeline.

oops.

i fixed the decoder part, and created a dog's dinner mess of the CompUnits
that needs to be reverted.

before that happens, the regfiles need to be made non-combinatorial.

unnnfortunately, this will have the side-effect of getting the regfile
"read enable" exactly one clock cycle out of phase with the regfile "data".

and guess what?

the CompUnits are *specifically* designed to have the "ok" flag (GO_READ)
arrive at the *same* time as the data.

* request is raised by CompUnit to indicate "desire to read"
* PriorityPicker selects one and only one of those to "fire"
* "picked" unit's register address is asserted on regfile bus
* "picked" CompUnit is told "GO_READ"
* "picked" CompUnit knows that the data present on the regfile data bus is
for it and it alone.

what is needed, if the regfile output is to be delayed by one clock, is
that the "REQUEST" has to be switched off on one clock cycle, but in that
same cycle the regfile "enable" is still sent, and a FSM keeps track of the
fact that the "GO_READ" must be sent on the *next* cycle.

urgh.

interestingly this should allow FPGA BRAM to be used.  also interestingly,
this is a half-way-house towards the "cyclic buffer" regfile bus idea.

l.






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