[libre-riscv-dev] cache SRAM organisation
staf at fibraservi.eu
Fri Mar 27 09:08:48 GMT 2020
Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 21:28 [+0000]:
> On Thu, Mar 26, 2020 at 8:08 PM Staf Verhaegen <staf at fibraservi.eu> wrote:
> > Luke Kenneth Casson Leighton schreef op do 26-03-2020 om 15:15 [+0000]:
> > > On Thursday, March 26, 2020, Staf Verhaegen <staf at fibraservi.eu> wrote:
> > > > I can understand you do this to implement functional units withconfigurable pipeline length but I would strongly discourage to pipelineregister files after each other .
> > >
> > >
> > > "pipeline register files after each other"? apologies i am not clear whatyou mean, here. do you mean "don't do write-thru on the Regfile"?
> > No I meant for example connecting the output of one port of an asynchronous RAM to for example the address input of another port of an asynchronous RAM.
> ah right, no definitely not. the connections are:
> RegisterFile readport[0..R] ==> FunctionUnit[0..M] operand latches pipeline stage 0 pipeline stage 1 ... pipeline stage NRegisterFile writeport[0..W] <== FunctionUnit[0..M] result latches
> (and also: )register file bypass forwardingbus <== FunctionUnit result latchesregister file bypass forwardingbus ==> FunctionUnit operand latches
> so the asynchronous SRAMs will definitely *only* be connected to SFFlatches. *not* to other asynchronous SRAMs.
I still feel you intermix synchronous and write-through in this statement, the above seems to be possible with synchronous SRAMs.
More information about the libre-riscv-dev