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
6 years, 3 months
Partial GSoC Proposal
by Yogesh Mahajan
Hello everyone,
My name is Yogesh. I'm a student at Indian Institute of Technology Bombay -
India, pursuing my bachelor's degree in Electrical Engineering.
I'm interested in developing open-source IPs for lowRISC on FPGA. I'm
planning to focus on SPI interface and memory controller.
I have worked on SPI as a part of one of my projects. I have tested some of
SPI cores on OpenCores on FPGA and have decided to add some extra features
based on my experience with SPI. Here are some highlights of my proposal
for SPI core
1. Support all 4 Modes (No need to mention)
2. Read and Write FIFOs (generic with default depth of 8)
3. Interrupt generation after a programmable number of messages.
4. Internal frequency divider
5. NASTI interface with the processor. (No openCores project has one)
6. At least two chip select pins controlled by core itself. This feature is
optional. I have added this option to support sending data to multiple
devices on same SPI bus. This option will reduce the processor's load to
manipulate CS pins externally. I came up with this idea while I was working
on my project where I had to manipulate three DACs. We can assign separate
bus addresses to handle multiple devices with the same core. This can be
very helpful for stacking up multiple external shields (like Arduino).
I have been also reading about RRDx memory controller, but I haven't gone
far in this as I'm new on this topic. I have looked into the last year's
project and realized that I need some help as this is a very vast topic. I
have also considered OpenCores project (
https://opencores.org/project,ddr3_synthesizable_bfm). Currently, I'm
trying to understand the JESD79-3F DDR3 standard. I'm still trying to
figure out acceptable deliverables for the memory controller and how much
time it will take as someone told me that designing a good memory
controller may take one man year. Can someone please help regarding memory
controller so that I can complete my proposal in time. I know that I should
have asked well before, but because of various reasons, I couldn't.
Some of my relevant work:
1. Superscalar processor (Currently Active): We are trying to make a small
superscalar MIPS processor for De0Nano (Altera's Cyclone IV) board.
2. Multicycle processor (Complete and Tested): It is a very small 16-Bit
SMIPS processor to support simple sequential tasks in FPGA projects. I have
implemented a UART bootloader to download the code on the processor.
3. Asynchronous RRAM controller
4. AES Encryption block for FPGAs and CPLDs: Supports counter mode chain
cipher and a 128-bit key.
I'm comfortable with VHDL and Verilog. I have some experience with DSPs
also.
Kindest regards,
Yogesh
<https://mailtrack.io/> Sent with Mailtrack
<https://mailtrack.io/install?source=signature&lang=en&referral=y.mahajan4...>
6 years, 5 months
CS undergraduate interested in dma engine for GSoC 2017
by Ilias Machairas
Hello, I am currently a CS undergraduate student at National and
Kapodistrian University of Athens in Greece. I really like hardware. I 've
had logic/digital design classes in which, amongst others, a mips clone was
extensively studied. In addition, I have had 2 computer architecture
classes. Currenlty, I am enrolled in an embedded systems course(hardware
approach) in the 8th semester which is project based and where we gradually
develop (each student) a SoC fire detector in VHDL(with a soft-coded
PicoBlaze processor and several processing elements talking via a central
switch). I am also currently trying to order a zybo-zynq SoC fpga. So,
firstly, I would like to ask, if lowRISC is something like the zynq series
fpgas but instead of a hard-coded ARM processor you use a RISC-V one? Or
more generally, I am comfused whether what you 're building is hardware
programmable or not?
Sorry if these are bad questions. Finally, I am really interested in the
DMA engine
that you propose in the list. I would appreciate it if you could give me
some quidelines and/or technical resources relevant to the dma component,
so that i can apply in a more specific manner.
Thank you,
Ilias Machairas
6 years, 5 months
FPGA for untethered Rocket Chip -- how much room is left?
by Sean Halle
Hi,
Thanks for all the work you're doing on RISC-V, it is greatly
appreciated.
I have a question about the FPGA and the untethered version. We're
about to buy an FPGA development board, but are bootstrapping so want to
keep the cost low. I found the two FPGA boards listed on the LowRISC site:
http://www.lowrisc.org/docs/untether-v0.2/ -- the page for Untethered,
which lists 2 FPGA boards:
http://store.digilentinc.com/nexys-4-ddr-artix-7-fpga-trainer-board-recom...
http://www.xilinx.com/products/boards-and-kits/ek-k7-kc705-g.html
My question is whether anyone knows how much room is free on the low cost
version. I would guess that it holds the core, including all the CSRs plus
both L1 caches, including virtual memory support (TLB), plus the DRAM
controller, the interrupt unit with timers, and ROM controller, as well as
an ethernet controller for communication.. but it only has 15K LUTs.. Do
you know how much room is left over? We are adding a bit to the base core,
so need maybe 4K additional LUTs..
Thanks, Sean
Intensivate
http://intensivate.com
*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.
On Sun, Feb 26, 2017 at 8:37 PM, Sean Halle <seanhalle(a)intensivate.com>
wrote:
>
> Thanks, Wei,
>
> That makes sense, we have the same issues with needing to keep our
> development isolated from the churn. We will probably do the same freeze
> approach ourselves -- take the current state of your code and freeze that
> while we do development, and then update after you do your own update.
>
> I really appreciate the work you're doing. Any of us trying to use
> Rocket in the real world need an untethered version, and it appears as
> though you've done a good job of making a stand alone version of Rocket.
>
> The last option we are checking out is SiFive, to see whether they
> release their chip code base under the same permissive license, and how the
> development complexity of their code compares to working with LowRISC.
>
> Thanks,
>
> Sean
>
>
>
> *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.
>
>
> On Tue, Feb 21, 2017 at 6:05 AM, Wei Song <wsong83(a)gmail.com> wrote:
>
>> Hello Sean,
>>
>> Currently lowRISC is still working on an old Rocket chip.
>> We plan to have the upstream Rocket merged to lowRISC in the upper half
>> of this year.
>> The reasons for this decision are two-folds:
>>
>> 1) The upstream changes include a total code reshuffle using a new
>> TileLink2 on-chip interconnect (which comes a new automatic chip generator)
>> and Chisel3.
>> Both of these are destructive and unstable for the time being. It is
>> hoped that the upstream code base might be more stable before the next
>> RISC-V workshop (May this year).
>> Then lowRISC can have the upstream merged with less human effort.
>>
>> 2) We are currently busy working on our own features including tagged
>> memory and programmed IO using minion cores.
>> Our next release is scheduled in March; therefore, there is literally no
>> chance to merge upstream before the release deadline.
>>
>> Sure, any feedback and bugfixes are extremely welcome.
>>
>> Best regards,
>> Wei
>>
>>
>> On 21/02/2017 13:55, Sean Halle wrote:
>>
>>
>> Nice, thanks, Wei. It sounds like a good option.
>>
>> One additional question, does the LowRISC code base pull in changes from
>> Berkeley on a regular basis? Is it up to date with the latest Chisel 3,
>> FIRRTL, Verilator version of Rocket, and all the latest Rocket code updates?
>>
>> If so, then it is looking like a very good option, indeed.
>>
>> If we go with it, then we will be able to contribute fixes and upgrades
>> back to the collection, and help move the project forward.
>>
>> Thanks, Wei,
>>
>> Sean
>> CEO Intensivate
>> http://intensivate.com
>>
>>
>>
>> *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.
>>
>>
>> On Tue, Feb 21, 2017 at 3:56 AM, Wei Song <wsong83(a)gmail.com> wrote:
>>
>>> Hello Sean,
>>>
>>> We are actively developing the lowRISC platform. All releases after the
>>> untethered-v0.2 are untethered SoCs by default.
>>> You should be able to see the development looking at the other branches
>>> https://github.com/lowRISC/lowrisc-chip/network
>>> We keep the master branch stable until a major release so there is
>>> little disturbance for users.
>>>
>>> For any questions or remarks, you can send email to our email-list:
>>> lowrisc-dev(a)lists.lowrisc.org
>>> For specific questions related to particular release or code, you can
>>> raise issues using GitHub's issue tracer
>>> https://github.com/lowRISC/lowrisc-chip/issues
>>> which we do actively monitor as well.
>>>
>>> Thanks,
>>> Wei
>>>
>>>
>>> On 21/02/2017 11:43, Sean Halle wrote:
>>>
>>>
>>> Hello,
>>>
>>> Thank you for all of your work on LowRISC, providing an untethered
>>> version of Rocket Chip.
>>>
>>> We are producing a high performance low power processor that targets
>>> Machine Learning, and are considering integrating it into the untethered
>>> LowRISC chip.
>>>
>>> This is a major decision for us. Whether we choose to integrate into
>>> Rocket Chip from Berkeley, or integrate into your untethered version has
>>> major implications, that involve a large amount of effort on our part. So
>>> we would like to investigate before making a final choice.
>>>
>>> One of the questions I have is about the level of current activity on
>>> the LowRISC untethered version. Is the code base still under active
>>> development? Is there a mailing list for people using the distribution to
>>> ask questions when things go wrong?
>>>
>>> Thanks, Wei,
>>>
>>> Sean
>>>
>>>
>>>
>>>
>>>
>>>
>>> *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.
>>>
>>>
>>>
>>>
>>> --
>>> Dr Wei Song ( 宋威 )
>>> The Computer Laboratory
>>> University of Cambridgehttp://wsong83.github.io/
>>>
>>>
>>
>>
>> --
>> Dr Wei Song ( 宋威 )
>> The Computer Laboratory
>> University of Cambridgehttp://wsong83.github.io/
>>
>>
>
6 years, 5 months
(no subject)
by Varun Bhat
Hello lowRISC Community,
I am a Graduate student at Colorado State University. I would like to
contribute to the lowRISC community through GSoC.
I am currently interested in working on the untethered branch of low risc
and possibly adding more IP cores onto that. I would love to contribute and
needed some feedback on where exactly the repository needs work. I cloned
the repository and tried to compile it for the nexys4 device, however I
don't see a good documentation on that. I would love to work on the
documentation as well so that it would be helpful for the others to use the
code as well. I would greatly appreciate it if you could provide some
inputs as to what details I will need to put in the proposal.
My major is in VLSI and embedded system and I have worked on a few FPGA
projects and Currently I am working on a project for my curriculum on
Software Defined Radio. I am fluent in Verilog, VHDL and lot more
programming and scripting languages. I love to learn more programming
languages. If there is any other way I could contribute, please let me know.
Varun Bhat
Graduate Student,
Dept. of Electrical and Computer Engineering
Colorado State University
Contact: +1 650 228 3691
6 years, 5 months
Google SoC 2017 candidate
by Paulo Nesello Künzel
Hello everybody,
my name is Paulo. I'd like to take part on this year GSoC and work with
you all.
I'm interested in the "Integrate more open-source IP for lowRISC on
FPGAs" project.
Best regards,
Paulo Nesello
6 years, 5 months
Gsoc 2017 - Integrate more open-source IP for lowRISC on FPGAs
by pradeep kathirgamaraja
Hi,
I am interested in integrating open source IP cores for lowRISC. I have
started to work with Opencore UART module. I am testing Opencore UART ip,
ip from FPGA fun website.
Here i have attached the simulation for uart transmitter in Vivado.
Thanks.
pradeep
6 years, 5 months
GSoC 2017 suggest my own topic
by kritik bhimani
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
6 years, 5 months
Student interessed in the "Integrate more open-source IP for lowRISC on FPGAs" project
by Paulo Nesello Künzel
Hello everybody,
My name is Paulo Nesello Künzel, I'm a Brazilian student at the Federal
University of Technology – Parana, studying Computer Engineering.
I'm interessed in the "Integrate more open-source IP for lowRISC on
FPGAs" project. I've lurked OpenCores for some time and worked on a
school project with their openRISC 1200 core. For a proposal, I'd like
to work on the Memory controller, then UART modules.
I'm currently reading Song's tutorial about Untethered lowRISC, but may
need some extra guidance.
Thank you for your attention,
Paulo Nesello
6 years, 6 months
(no subject)
by Shashank Joisa
Hi
I would like to contribute in Lowrisc.
I have already given my introduction in previous mail in which i have
mentioned that i know C++.
And the project I am interested is
1, Open SoC Debug: Trace Visualization and Configuration
I have gone through the description and i would like to work on these
projects.
It will be helpful if someone guide me how to start and continue with the
project.
Thank you
Shashank Joisa
6 years, 6 months
