Multiple Rockets and Minions memory hierarchy
by Tobias Strauch
Hi Rob et al.,
thank you for sharing an update on your wonderful project at the RISC-V WS in Munich.
I’ve been following the lowRISC project closely and I was wondering, if I may ask you two questions.
1) Support for (many) MultiCores (except the Minions):
Are you still planning to go for a solution, that supports multiple cores of the same kind (except the Minion Cores Network), so let’s say, multiple rockets, multiple BOOMs etc. I’m particular interested in how you solve the cache coherence\software\OS software problems that come with it.
2) Minions and local memory
Will you attach local memory to the individual minions, and if so, how will your global memory hierarchy look like?
Thank you so much in advance for your answers.
Cheers, Tobias
PS: Can’t wait to work with your next release.
PPS: I think the survey on the RISC-V cores you mentioned is highly appreciated.
5 years, 9 months
Re: Weekly Report of Porting musl to RISC-V Project #5
by Alan Pillay
What is the current status of musl on RISC-V?
This was the last time I heard about it, but it has been many months since.
Regards.
> Hello,
>
> Thanks to the folks, I passed the mid-term evaluation. Now it is about
> time to publish the fifth progress report on porting musl on RISC-V.
>
> Last week, the toolchain itself has been built for RISC-V and running
> on Spike, and libc-test [1] can be executed with it now. I posted the
> result of tests on [2]. The REPORT.txt file contains all error
> messages of failed tests, both run-time ones and compile-time ones.
>
> Some failures are expected since musl on x86_64 also does the same
> ones (e.g. errors in src/api/fcntl.c), but there are some unexpected
> errors too. I guess that the "warning: <the name of a header> is
> shorter than expected" warning indicates bugs in arch-dependent part
> of I/O functions or system calls (or kernel?) and it causes syntax
> errors in the same compilation unit.
>
> Moreover, some tests triggers a "signal 11" error (segmentation fault)
> in libc. I added some logs to [2]. They are bugs in the port,
> obviously. I am working on them.
>
> The good news is, anyway, some results are *better than x86_64*,
> especially in math functions :-)
> (probably the cause is the difference in the floating-point precision,
> though. it is usual in float tests...)
>
> It takes long, long time to get but finally I have a (seems-to-be)
> working test suite for the port. I will continue to debug and fix the
> port using the result. Stay tuned!
>
>
> [1]: http://nsz.repo.hu/git/?p=libc-test
> [2]: https://gist.github.com/omasanori/ee828369aea844ac7fdfdc8362953299
>
> --
> Masanori Ogino
5 years, 9 months
Unofficial repository of Debian packages for RISC-V 64-bit (riscv64)
by Manuel A. Fernandez Montecelo
Hello,
After some requests by different people in the last few days, I just
published the work that I've been doing for a while creating a
repository of Debian packages for riscv64, which I hope that will become
some day (in a not very distant future) a full and official Debian port.
First, let me thank specially Kurt Keville from MIT for all the help.
Also thanks to people who helped in some way or another (too many to
list, but most are reading the lists along with the rest of you and are
familiar names ;-) ).
So, to cut to the chase, you can find the repository here:
http://riscv.mit.edu/
And explanations and the story here (it's long, but the good part is
that you can skip it altogether :) ):
https://people.debian.org/~mafm/posts/2017/20170422_debian-gnulinux-port-...
IMPORTANT #1:
Sadly, due to recent changes in the toolchain, it seems that these
binaries will not work if your system has recent-ish versions of the
toolchain (or maybe very old ones). I am not sure if there is a way
to make them work, probably not, in which case all that work will have
to be re-done somehow.
You can try to use for example static binaries, like the one in the
package "bash-static" [1], which are more likely to work on your
system.
[1] http://riscv.mit.edu/debian/pool/main/b/bash/bash-static_4.4-4_riscv64.deb
I hope to keep it updated so the binaries will target newer versions
of the toolchain soon.
IMPORTANT #2:
YOU SHOULD NOT RUN BINARIES FROM RANDOM PEOPLE DOWNLOADED FROM THE
INTERNET!!!!
Still, if you marginally trust me and the Debian project, make sure
that you include the bits to verify the authenticity of the repo, as
per the instructions in the URLs above, and apt will do it for you.
If not in a Debian system (or derivative), you can also check the
signed Release file in [2] (which contains the checksum of files which
in turn contain the checksums of sources and binaries), it is signed
with my key, which is in turn signed by other people's (some of whom
you may know and trust) and published in the keyserver pgp.mit.edu [3]
for example, and I also sign this message with this key.
[2] http://riscv.mit.edu/debian/dists/unstable/
[3] http://pgp.mit.edu/pks/lookup?op=vindex&search=0x7F7606A445DCA80E
So if you trust my signature, verify that Release file is correctly
signed by it and the checksums of the files that you download match,
you are good to go.
Hope that it's useful at least for some of you.
Any feedback welcome.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo(a)gmail.com>
5 years, 11 months
Interested gsoc 2017
by Daniel Gonzalez
Hello I'm Daniel González an Electronic Engineering student which is interested on the "Integrate more open-source IP for lowRISC on FPGAs" project but there is no mentor to contact directly, sorry I'm new in this so... What's the next step?
Thanks for your time
Cheers,
5 years, 11 months
Re: [lowrisc-dev] GSoC 2017 suggest my own topic
by Sean Halle
Hi Kritik,
Thanks for suggestion the Sodor project. We, ourselves, used Sodor as a
starting point for developing our high performance low power core. The
reason was that Sodor was an easy way to learn Chisel, because it doesn't
use the complex coding techniques that are in the Rocket code base, and
Sodor has very little content, so it compiles and simulates quickly. This
speed is important because it is inside the code-test-debug cycle. We
typically do a few minutes to an hour of development then do a compile and
run. Sodor compiles and simulates the full conformance suite plus
Dhrystone benchmark in under a minute. In comparison, Rocket takes on the
order of 5 minutes, or more. This turned out to be a key advantage to
Sodor development. The other was the fact that it only has the core logic,
without memory implementation. The memory is just a dummy model, that is
loaded as a RAM image. That was important during development because it
kept things very simple, allowing us to focus on the pipeline. We played
tricks to adapt the memory, and didn't have to stop to update and debug an
actual memory implementation.
I would be happy to act as an informal source of advice on this project.
It sounds like a very needed and valuable contribution. Most especially
simplifying the exception code, updating to 1.9, simplifying the CSR code,
and improving the documentation. All huge.
Feel free to get in touch seanhalle at intensivate dot com
Sean
================
Hey kritik bhimani here,
I am interested in working on the topic of "Updating Sodor" though the
topic is not mentioned there but possible in "your project here". I intend
on completing all the tasks given in to-do list(on repo) during the period
along with that provide an in-depth documentation for sodor.
To-do list:
-Updating to Chisel3/FIRRTL which requires making the Sodor testharness
speak to Verilator (since Chisel3/FIRRTL can only generate Verilog, no more
C++).
-Updating to Privileged Spec v1.9
-Use the External Debug to load programs into Sodor, like how Rocket works.
-Provide a Verilog test harness, and put the 3-stage on an FPGA
which would require an AXI port so that binaries can be loaded into Sodor's
scratchpad also allowing others to use Sodor's cores in their project
-Add support for the ma_addr, ma_fetch ISA tests. This requires detecting
misaligned address exceptions
-Make common/csr.scala file clearer and more understandable.
-Refactor the stall, kill, fencei, and exception logic of the 5-stage to be
more understandable
I have also contributed to this repo
https://github.com/ucb-bar/riscv-sodor/pull/20
The following are the benefits that I am speculating by "updating sodor":
- I have seen in that some individuals(from the mailing list and other
sources) start off with sodor and then move to rocket possible reasons for
this could be since they are quite new to chisel/RISC-V and starting
directly with the large codebase of rocket(which includes a lot more than
the instruction pipeline) could be difficult. Keeping sodor updated to
latest standards of RISC-V ISA / Chisel would help ease their transition
from sodor to rocket(which is continuously being updated to latest
standards)
- It is already used for educational purpose so having it updated would
help teach the latest content and also a better documentation would
definitely help in having an even wider deployment in terms of number of
schools using sodor in undergrad computer architecture courses with the
port of 3 stage on FPGA providing an even more complete overview of comp
arch
My previous projects:
communication between zc706 and host motherboard with intel i7-5960x via
PCIe - it involved making an appropriate block diagram in
vivado[cdma(support for both scatter-gather and normal transfers was
achieved),axi2pcie and many other IP's were required] device driver for
host running Linux kernel 4.6 and a userspace application. Was able to
achieve a read speed of 500MiB/s(wrt host). Another project that I am
currently working on is to modify already existing support for OoO
processor simulating RISC-V ISA to a one with desired specifications which
are currently not met just by changing the parameters in exported python
file.
Thank you
CONFIDENTIALITY NOTICE: This e-mail and its attachments contain information
which is confidential. It's use is strictly limited to the stated intent of
the provider and is only for the intended recipient(s). If the reader of
this e-mail is not the intended recipient, or the employee, agent or
representative responsible for delivering the e-mail to the intended
recipient, you are hereby notified that any dissemination, distribution,
copying or other use of this e-mail is strictly prohibited. If you have
received this e-mail in error, please reply immediately to the sender.
Thank you.
5 years, 11 months
