PULP is ready to take-off: Our 64-bit core Ariane

358 views
Skip to first unread message

Florian Zaruba

unread,
Feb 16, 2018, 10:30:46 AM2/16/18
to hw-...@groups.riscv.org
The PULP project team (http://pulp-platform.org) at ETH Zurich and University of Bologna are proud to present the newest member of the PULP family. Ariane is a Linux-ready, application-class, 64-bit RISC-V core supporting (RV64-IMC) written completely in System Verilog, and is available to download from our GitHub page (https://github.com/pulp-platform/ariane) immediately.

Ariane is a 6-stage, single issue, in-order CPU which fully implements I, M and C extensions as specified in Volume I: User-Level ISA V 2.1 as well as the draft privilege extension 1.10. It implements three privilege levels M, S, U to fully support a Unix-like (Linux, BSD, etc.) operating system. It has configurable size, separate TLBs, a hardware PTW and branch-prediction (branch target buffer, branch history table and a return address stack). The primary design goal was on reducing critical path length to about 20 gate delays.

Following the feedback we will get from our users, we will continue the development of Ariane on the public repositories, and we have many features that we are working on for this core such as:
* IPC improvements
* Double precision floating point unit
* Full support for Atomics
and many more to come.

...and we are still not done yet!

We still have a couple of exciting new releases in the upcoming weeks in the multi-core space: as promised we will eventually share all our PULP development. Stay tuned!!! and follow us on twitter @pulp_platform.

Your PULP team
signature.asc

Alex Bradbury

unread,
Feb 23, 2018, 5:25:35 AM2/23/18
to Florian Zaruba, RISC-V HW Dev
On 16 February 2018 at 15:30, Florian Zaruba <zar...@iis.ee.ethz.ch> wrote:
> The PULP project team (http://pulp-platform.org) at ETH Zurich and University of Bologna are proud to present the newest member of the PULP family. Ariane is a Linux-ready, application-class, 64-bit RISC-V core supporting (RV64-IMC) written completely in System Verilog, and is available to download from our GitHub page (https://github.com/pulp-platform/ariane) immediately.
>
> Ariane is a 6-stage, single issue, in-order CPU which fully implements I, M and C extensions as specified in Volume I: User-Level ISA V 2.1 as well as the draft privilege extension 1.10. It implements three privilege levels M, S, U to fully support a Unix-like (Linux, BSD, etc.) operating system. It has configurable size, separate TLBs, a hardware PTW and branch-prediction (branch target buffer, branch history table and a return address stack). The primary design goal was on reducing critical path length to about 20 gate delays.

[My messages don't seem to be making it to the hw-dev archives, so let
me try again for a third time. Apologies if you've received this
message multiple times].

Congratulations on the release! Someone can correct me if I'm wrong,
but I'm pretty sure this is the first open source (System)Verilog
RISC-V core capable of booting unmodified RISC-V Linux. Many thanks
for the clear docs and diagrams for the pipeline design. [For anyone
who missed them - see here
https://pulp-platform.github.io/ariane/docs/home/]

Best,

Alex

Max Hayden Chiz

unread,
Feb 23, 2018, 10:03:45 AM2/23/18
to RISC-V HW Dev, zar...@iis.ee.ethz.ch
Congratulations on yet another release.

You've probably answered this somewhere that I can't find, so I'm sorry if these are repetitive questions. (I'm sending them off-list, but feel free to copy the list with your response if you think others would benefit from the answers.)

It seems like Ariane doesn't support the extensions you added for RI5CY. Is that just temporary (and adding them would be part of "IPC improvements") or is the plan to leave them out permanently?

I was trying to see how much overhead the extra register ports and other hardware for your extensions added, but I couldn't find that information on your site, and comparing RI5CY with Zero-Riscy isn't a fair comparison because they don't have the same pipeline design. Do you have a paper somewhere that estimates how much area and power these extensions cost and how much performance they get, preferably with a per extension breakdown?

Also, since you already use a scoreboard, do you plan on making a super-scalar version in the near future? I'm especially curious in the comparative cost and performance of a single-issue chip with your ISA extensions vs a dual issue chip without them. Is this something your work will eventually address?

Finally, some of the instructions you add, like hardware loops, are extensions of RISC-V, but others could be handled with macro-op fusion (e,g. post increment loads and stores, some of the ALU extensions) is there a reason you didn't go with the fusion route for those operations? With regard to things that RISC-V will eventually have a spec for, like the bit manipulation instructions, is the plan to make the two compatible once RISC-V has an official extension?

FWIW, I'm generally impressed with your design and looking forward to seeing what else you guys make. Keep up the good work.

Thank you for any information you can provide.

Best wishes,

Max H. Chiz
New Orleans, LA USA

P.S. As you may already know, I'm currently trying to implement data cache prefetching for Rocket and Boom. Once we get it working, if you decide to copy pieces of it for use in your designs, I'll be happy to answer any questions you might have.

We'll be implementing a generator library to support many different prefetchers. I assume you'll want to just pick a single design and implement it directly. Hopefully our testing will give you some guidance on what to use. But if you end up needing me to look at something specific, I'll be happy to work with you to get whatever you need evaluated. (And if you already have suggestions or ideas in this area, please let me know so that I can incorporate them into our plans. I'm trying to be very comprehensive, but it's always possible that I've overlooked something important. OTOH, if you don't plan on waiting for our testing to wrap up, I can probably make some suggestions based on an educated guess about what should work at various design points.)
Reply all
Reply to author
Forward
0 new messages