search

bluespec / Toooba

RISC-V Core; superscalar, out-of-order, multi-core capable; based on RISCY-OOO from MIT
Other
161 stars 36 forks source link

Ifetch cleanup master #17

Closed jonwoodruff closed 3 years ago

jonwoodruff commented 3 years ago

This is a refactor of instruction fetch to be cleaner and simpler. This has been tested running FreeBSD and does not regress performance.

  1. Instruction fetch memory (both ICache and MMIO) now support instruction fragment aligned accesses directly to remove complexity around fixing this up in the Fetch pipeline.
  2. The instruction fetch pipeline now uses a SupFifo to support instruction picking with a much simpler algorithm. That is, at the end of Fetch3, instruction fragments are enqueud to a SupFifo, up to 2xSupWidth per cycle. The beginning of decode picks up to SupWidth instructions from these fragments, and any unpicked fragments simply fall to the head for the next cycle to pick.
  3. To reduce the overhead of the SupFifo, which contains both a PC and PredPC for each fragment, a table is used to hold upper bits of PCs in flight in the instruction fetch pipeline, with indices and offsets handled in the pipeline itself.
jrtc27 commented 3 years ago

The dual-core commit and revert should be removed from the history

jonwoodruff commented 3 years ago

The dual-core commit and revert should be removed from the history

Having acquired some education from Alexandre, I am wondering if I'm expected to rewrite history in the ifetch-cleanup-master and force push (doing what to this pull request and comments?), or if there is some better way to do this. ... Ok, at this point I'm not aware of any other way to do this, so I'll go ahead and force-push this branch with the two commits removed from history.

jrtc27 commented 3 years ago

The dual-core commit and revert should be removed from the history

Having acquired some education from Alexandre, I am wondering if I'm expected to rewrite history in the ifetch-cleanup-master and force push (doing what to this pull request and comments?), or if there is some better way to do this. ... Ok, at this point I'm not aware of any other way to do this, so I'll go ahead and force-push this branch with the two commits removed from history.

Yes, that's what I meant. Some of the commits could stand to be squashed into earlier ones ("Do A" then "Fix bugs introduced by doing A" is not useful history, better to just have a "Do A" commit that's correct) but it's not the end of the world.