[libre-riscv-dev] Introduction and Questions

[Jeremy Singher]

> Unfortunately, not yet - would you like to help with this?
> We’re a bit starved on labor - about 4ish full-time in man-hours?

Sure, if you point me to documentation on the core design, I can draw
up a diagram of it.
Is there enough information on the core to make a WikiChip-like diagram?
I find that displaying the pipeline depth, width, and important
components is a good way of
displaying key characteristics of a core, and it makes it easier for
people like me to draw comparisons
against other cores (commercial and open-source).

> We’re using a modification on the scoreboard architecture from the Cray CDC 6600.
> Our scoreboard is somewhat similar to that of Tomasulo’s algorithm.

So you have OOO execution with multiple functional units executing in parallel,
and a scoreboard tracking completion status of writes to registers, right?
Is this a unified-register-file, or register-in-issue-queue design?

> No. So since we’re implementing a POWER chip, we decided to start by writing a POWER
> Simulator first. There are were a few options for this, QEMU, PearPC, and Gem5.

Ah I see, that's ok. You have to start somewhere :).

> From initial discussion, our first tapeout would be looking at Raspberry Pi rev B 2012 performance wise.
> It would be good to get some drystone number down.

Are you targeting IPC as the performance metric? Or IPC x Freq?
The Pi 1 Rev B seems to be a 1-wide in-order design, so it should be a
pretty conservative target to hit.
Any basic OOO core should beat the PI B in IPC, it only needs to run
at an equivalent frequency.

Do you know what the final performance target is? (Or minimal target
for a commercially viable product?)
The Cortex A72 is a 3-w OOO that might be a good point to target (it's
also used the latest Pi 4s).

>From running a couple experiments on other open-OOO cores, it seems
like 3-ish DMIPs/MHz is a good
target for a OOO core.

> Are you familiar with Python nMigen - its basically Chisel for Python. You mentioned michroarchitecture… Perhaps you could help Luke on the scoreboard.

Ya, I've been trying to run the script on the website, running into
problems with Yosys, debugging now.

Lastly, have you guys talked to the university efforts to build
open-source cores? I see links to the
Shakti project on the site. Is this a collaboration with them? I
thought they were doing RISC-V?
There's also groups at ETH, Berkeley, and MIT pushing out their own
application-class cores. How does
this design compare to those?

Part of the reason I'm asking so many questions (beyond my own
curiosity) is that I will likely be
a TA for a computer-architecture course in the near future, and I
would like to revamp the course by
having students interact with real RTL for a complex SoC, instead of
just simulators.


Thanks,
-Jeremy
On Fri, May 15, 2020 at 11:45 AM Yehowshua <yimmanuel3 at gatech.edu> wrote:
>
>
>
> > On May 15, 2020, at 2:24 PM, Jeremy Singher <thejsingher at gmail.com> wrote:
> >
> > Hi all,
> >
> > My name is Jeremy Singher.
>
> Hello and welcome!
>
> > I'm a graduate student studying computer
> > architecture, interested in open-source hardware and high performance
> > microarchitectures. I am looking for an open-source hardware project I can
> > contribute to through the course of my graduate studies, and I have some
> > questions about the Libre-SOC project.
> >
> > 1. It seems like you guys are building various components of an
> > out-of-order microarchitecture, such as the scoreboard, and load-store
> > ordering units. Do you have a complete microarchitecture diagram of the
> > core (or a text description)?
>
> Unfortunately, not yet - would you like to help with this?
> We’re a bit starved on labor - about 4ish full-time in man-hours?
>
> > I could find bits and pieces on specific
> > components, but I'm interested in details like pipeline width, depth,
> > branch-to-branch latency, load-use delay, etc.
>
> We’re using a modification on the scoreboard architecture from the Cray CDC 6600.
> Our scoreboard is somewhat similar to that of Tomasulo’s algorithm.
>
> > 2. Is the SoC at a state at which I can evaluate performance on simple
> > benchmarks in simulation? Other similar open-source hardware projects have
> > make targets to launch verilator simulations, but I could not find an
> > equivalent in your repos (although I probably am just bad at looking).
>
> No. So since we’re implementing a POWER chip, we decided to start by writing a POWER
> Simulator first. There are were a few options for this, QEMU, PearPC, and Gem5.
>
> We’re making tweaks to PearPC and we also writing a simulator in Python that parses the official POWER3.0B spec.
>
> I can’t remember why we decided to fiddle around with PearPC and not use QEMU or Gem5.
>
> > 3. What is your target performance in terms of an established benchmark
> > like Coremark, Dhrystone, Embench, or SPEC? I'm trying to compare the
> > merits and progress of various hardware projects out-there.
>
> From initial discussion, our first tapeout would be looking at Raspberry Pi rev B 2012 performance wise.
> It would be good to get some drystone number down.
>
> > 4. What is the right way to get started contributing? My experience is with
> > Verilog, and I've looked at other languages too, including BSV and Chisel.
> > I'm primarily interested in developing microarchitecture for
> > performance-critical components, like branch predictors, prefetchers,
> > instruction schedulers, and load-store units. Ideally, I could contribute
> > my work as part of graduate studies to this project.
> >
>
> Are you familiar with Python nMigen - its basically Chisel for Python. You mentioned michroarchitecture… Perhaps you could help Luke on the scoreboard.
>
> Our codebase is a bit of a mess at the moment - there was so much to do for such a large project.
> By August, with significant extra funding and labor in the pipeline, there should be more ability to clean things up.
>
> > Sorry for the barrage of questions.
> >
>
> No offense here :)
>
> > Best,
> > -Jeremy
>
> Yehowshua
>
> > _______________________________________________
> > libre-riscv-dev mailing list
> > libre-riscv-dev at lists.libre-riscv.org
> > http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev