[libre-riscv-dev] Possible memory related paper and rust
programmerjake at gmail.com
Wed Feb 26 02:20:00 GMT 2020
CCing the mailing list since this seems relevant to everyone else.
The referred paper can be found by Googling "a single-stage risc-v
processor to mitigate the von-neumann bottleneck".
On Sun, Feb 23, 2020, 22:29 Cole Poirier <colepoirier at gmail.com> wrote:
> Hi Jacob,
> Apologies if this paper is not actually relevant, but I figure it is
still worth sharing on the off chance that this novel (to me at least)
memory/architecture concept is possibly useful to the SOC and its memory
It seems interesting but probably not useful for our design, since it seems
to be about microcontroller-type designs where they are using two sram
ports instead of one and switching the design to be completely single-cycle
instead of using the traditional 5-stage RISC pipeline. Those modifications
don't really work that well on high clock frequency designs or designs that
have more than just single-cycle sram for memory -- both of which we are
> I’m also not sure if the 6600 design already solves such problems.
yes, it does by having separate instruction and data caches as well as a
wider (128-bit, not sure) memory interface. Those reduce the memory
bottleneck by allowing accessing instructions and data simultaneously
(assuming the required data is in the caches).
> I haven’t studied it in detail yet nor read the book chapters yet. Can
you share them with me?
Luke would be a better person to ask.
> I’ve been working on trying to install the coriolis2 hdl workflow, but
unfortunately up until today I had been trying to do so in a parallels vm
on a mac. I have always struggled with the devops and configuration/systems
aspect of software engineering, primarily in trying to work with c++,
C++ and C are known to be a giant mess of build systems that are mutually
incompatible in subtle (as well as obvious) ways. That's one of the reasons
I really like Rust -- because everything uses or is compatible with the
same standard build-system/dependency-manager -- cargo.
language called Elm (no runtime errors is a dream).
One of the reasons why statically-typed languages (like Rust) are really
> So I feel lucky to have found and learned rust over the past year and a
bit. One of the most wonderful things for me about rust is I get to spend
more time coding than fighting my tools and cryptic or unhelpful errors. I
have attempted 3 reasonably big projects, and about half a dozen smaller
ones to try and improve my competency, but I often get stuck due to my lack
of knowledge and experience. Still being a relative novice I often struggle
to be able to complete really complex projects. I think a good way to
improve my abilities in rust and software engineering would be to assist on
a rust project with a much more experienced and talented developer.
Sounds like a good idea!
> Pardon me if this is not a feasible idea. Is there any way I could help
you with the Kazan compiler? I understand that compilers are very advanced
code based, however, I figure there is perhaps some way I could help. Even
just doing tasks for you like migrating the CI pipeline.
Sure, however I'd have to come up with some tasks first, since nearly the
rest of Kazan depends on the part I'm currently working on (the shader
compiler IR), which I would like to finish before building the parts which
are built on top of it, in order to avoid needing to rewrite large parts of
the code if some of the base structures fundamentally change.
Sorry for taking so long to respond.
More information about the libre-riscv-dev