search

lowRISC / lowrisc-chip

The root repo for lowRISC project and FPGA demos.
http://www.lowrisc.org/
Other
593 stars 149 forks source link

L1 Cache replacement policy #100

Open beatsnbytes opened 5 years ago

beatsnbytes commented 5 years ago

Hi all,

As far as I can see from the Chisel files the L1 D cache replacement policy is defined to be Random replacement. The Pseudo LRU policies are defined just for higher level caches and my attempt to port them to L1 was not fruitfull. I wanted to ask if there is any quick way implementing another policy than the random replacement for the L1 and why has only this policy been implemented? Is there a specific reason (performance-wise e.tc.) ? Thanks in advance!

jrrk commented 5 years ago

Dear Koba,

In previous lowRISC releases the Rocket behaviour was extensively customised, however it was soon found that

it was difficult to keep any patches in sync with newer Rocket releases to take advantage of new features (for example C extension, PLIC, run/halt debug).

Therefore in the latest release, only the minimum of necessary changes were made to suit our hardware requirements.

Moreover newer publicly released versions of Rocket lack an L2 cache, so it would not be possible to inspect how it works.

I would speculate that the random policy was implemented for performance reasons, and your attempts to change it were probably unsuccessful

because the code base requires changes to be made in multiple places to match the Chisel coding style. We do not have a Chisel specialist in

our team any more and consequently anticipate moving to a full SystemVerilog flow to give more traction to our next release.

Regards,

Jonathan

On 16/11/2018 16:02, Koba wrote:

Hi all,

As far as I can see from the Chisel files the L1 D cache replacement policy is defined to be Random replacement. The Pseudo LRU policies are defined just for higher level caches and my attempt to port them to L1 was not fruitfull. I wanted to ask if there is any quick way implementing another policy than the random replacement for the L1 and why has only this policy been implemented? Is there a specific reason (performance-wise e.tc.) ? Thanks in advance!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/100, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF1-iz6XU5rkkQzhXVtO-tYmcXTCdAks5uvuGsgaJpZM4YmhnH.

beatsnbytes commented 5 years ago

Well, I forgot to mention that I am working with the untethered v0.2 version. My main concern was implementing a software cache flush but with a random replacement it is not possible to deterministically know when the cache will be flushed. I guess I have to play my chances :)

jrrk commented 5 years ago

The Fence.rw instruction should do this but I don’t know if it was implemented on that old version.

Sent from my iPhone

On 16 Nov 2018, at 16:24, Koba notifications@github.com wrote:

Well, I forgot to mention that I am working with the untethered v0.2 version. My main concern was implementing a software cache flush but with a random replacement it is not possible to deterministically know when the cache will be flushed. I guess I have to play my chances :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

beatsnbytes commented 5 years ago

No, the fence.rw is not implemented in the version I am working at. Thanks for the clarifications!!

jrrk commented 5 years ago

Dear Koba,

May I ask, what is stopping you from upgrading to the latest version (v0.6) that has that instruction already?

Regards, Jonathan

On 18/11/2018 14:45, Koba wrote:

No, the fence.rw is not implemented in the version I am working at. Thanks for the clarifications!!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/100#issuecomment-439698171, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF18SXGb08RfLtSBlasmuoLZFbLzabks5uwXKXgaJpZM4YmhnH.

beatsnbytes commented 5 years ago

Dear Jonathan, The decision to work with the specific branch is mainly due to the fact that on the project that I work we want to support a multicore environment and afaik the specific older branch does not restrict you from this. The newer versions are targeted to Nexus platform which judging from its sixe wont fit a multicore netlist. Correct me if I am wrong, please.

jrrk commented 5 years ago

Dear Koba,

None of our releases support multicore correctly. The older releases use a version of TileLink which has bugs, the newer version lacks a coherent L2-cache.

The v0.2 release supported the use of ISA tests for multi-core scenarios and as such, may give the misleading impression that this behaviour is bug-free.

You can look into SiFive demonstration FPGA code releases to establish the latest status on the multicore issue. If you have an idea to develop your own

multicore support using a new coherent L2-cache, I would suggest starting from the kc705_mii branch as it uses TileLink-2 and and can support multiple cores.

However this would be a sizable new development.

Regards,

Jonathan

On 19/11/2018 13:51, Koba wrote:

Dear Jonathan, The decision to work with the specific branch is mainly due to the fact that on the project that I work we want to support a multicore environment and afaik the specific older branch does not restrict you from this. The newer versions are targeted to Nexus platform which judging from its sixe wont fit a multicore netlist. Correct me if I am wrong, please.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/100#issuecomment-439899073, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF1wnLlHJuYSizNJwOgBDQl4Tp-vAzks5uwrdNgaJpZM4YmhnH.