[libre-riscv-dev] cache SRAM organisation

Staf Verhaegen 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 mailing list