[lowrisc-dev] GSoC 2017 suggest my own topic

Sean Halle seanhalle at intensivate.com
Sun Apr 2 04:11:18 BST 2017


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.


More information about the lowrisc-dev mailing list