Porting tagged memory support to current version of RISC-V Rocket Chip
by Zhe Cheng Lee
Hi, all,
Has anyone successfully port lowRISC changes to support tagged memory to a
more updated version of the rocket chip repository (e.g. develop lowRISC
from a more updated version of the rocket chip repository)?
I want to develop a design module that rely on those tagged memory bits and
are to be integrated with the most recent version of the rocket chip. At
this stage of my development process, I just want at least the L1 caches to
support tagged memory. In other words, I'm not concerned about including
the tag cache or supporting tagged memory in main memory right now. I'm
having trouble successfully pushing the tags into the L1 caches. I have
already added the load/store tag instruction decoding and encoding (I'm
aware that the order of the control signals in the decode table has been
changed a bit since the rocket-chip version lowRISC is based off of), the
new memory access type constant MT_T, and the necessary config parameters.
At first, I thought I just need to include the highlighted modifications in
lowRISC's nbdcache.scala from
https://github.com/lowRISC/rocket/commit/51f65e2dce1bc60ef37c6da956bd8f9c...
and in its tilelink.scala from
https://github.com/lowRISC/uncore/commit/cebfde6d42b7465cab79518fad91e323...
to the corresponding places in rocket-chip's nbdcache.scala, cache.scala,
and tilelink.scala. Even without the tag utilities and tag cache, this
should be fine just for testing existing instructions, since those tag bits
would just be ignored in those cases, correct? But with that, the
simulations do not pass the prebuilt tests and benchmarks that don't test
the load/store tag instructions.
Can anyone help with this?
Thanks.
8 years, 1 month
Peripheral pitfalls
by Reinoud Zandijk
Hi folks,
Just a quick note this time and I hope a discussion starter:
I just read about the SHAKTI Processor project
(http://rise.cse.iitm.ac.in/shakti.html) and this passage at the beginning
caught my eye:
"While the cores and most of the SoC components (including bus and
interconnect fabrics) will be in open source, some standard components like
PCIe controller, DDR controller and PHY IP will be proprietary 3rd part IP."
If it is using undisclosed proprietary 3rd party IP, then what is the point of
taking a free ISA for a SoC? Only the royalties avoided? It is nice that they
want to share the CPUs and busconnect as open source but without `standard
components' its as like giving a full description of how to build an engine
but leave out the rest of car.
I hope lowRISC is not going this way. If only for safeguarding alone I'd
strongly advise against easy coupling of `standard' proprietary 3rd part IP
over say some memory mapped bus connection. I'd like lowRISC to keep being
open to the core, but all the way trough to the outside world.
And no, I am not a GNU'ist ;) Most of that standard stuff isn't exactly rocket
science so to say and open source examples can be found already online or in
academia. We can also take this opportunity to really clean up legacy
interfaces(*). We can use some of these existing systems and bolt them on in a
more sane way for a start and refine them later on, say for a PhD or Masters
degree project or even a GSoC project. Not that we should ever expose the
interfaces to other than firmware...
Ideas?
With regards,
Reinoud
(*) not quite fair a comparison but analog to using the SCSI command set over
an ATAPI layer that maps to a bypass to give commands to a virtual disk that
is addressed in LBAs that are mapped on real sectors on the disc using an
interface that was designed 25+ years ago that wasn't able to address discs
over 2gb.
8 years, 2 months