We are happy to announce we have six students in this years' Google Summer of Code. We are very grateful to Google to support the students financially to bring the Free and Open Source Silicon community forward.
Below you can find a list of the great projects we have this year. There will be regular updates and we will soon publish how you can follow the projects individually.
We are looking forward to a great summer!
Code quality metrics for projects listed on LibreCores.org
Student: Amitosh Swain Mahapatra
Mentors: Oleg Nenashev, Philipp Wagner
LibreCores.org lists free and open source "IP Cores" on the website for the community to view and use. All listed projects are backed by a git repository. Currently, LibreCores.org websites, extracts the project readme and license and renders them on the project page, along with links to the project homepage and git repository.
A user browsing for cores on LibreCores will be interested to know the quality of the project's code so as to determine how useful the project will be to them. Such information can be obtained from feedback from users using the project, and also from the project’s code.
This projects aims to collect code quality data that can be extracted, from a project's git repository. Such metrics may be from repository metadata as well as from the structure and content of source files. Collected metrics will also be enhanced when additional sources for metrics are available. Individual metrics would be combined to calculate the overall repository code quality which may be further used for purposes such as search ranking.
EDSAC Museum on FPGA
Student: Hatim Kanchwala
Mentor: Jeremy Bennett
Electronic Delay Storage Automatic Calculator (EDSAC) is a first generation British computer commissioned in 1949. It was built by Maurice Wilkes and his team at the University of Cambridge Mathematical Laboratory. EDSAC is the world's first stored-program computer.
The project's goal is to reimagine the EDSAC on modern hardware, with the ultimate objective to make the historic computer accessible to and reproducible by a new generation of computer architects and engineers. Investigating the evolution of computing techniques gives architects and engineers context to modern concepts of computer architecture, organisation and design.
The historic computer, complete with all its subsystems, will be replicated on an FPGA, using Verilog HDL, capable of accepting and executing all EDSAC Orders. To emulate the ancient I/O, various "I/O flavours" will be designed to interface with the FPGA board, via a standardised communication protocol. Users can choose, extend and even add new I/O flavours. An assembler utility will be built in Python, which users can utilise to debug and build their code for EDSAC, which can be then loaded onto the FPGA for execution.
High-level bitstream format for Lattice iCE40 FPGAs
Student: Roland Lutz
Mentors: Martin d'Anjou, Stefan Wallentowitz
This project will create a format which represents the bitstream for a Lattice iCE40 FPGA in a way which is friendly for humans to read and write, comparable to what an Assembler language is for machine text. In contrast to the existing bitstream "explanation" format, it isn't designed conforming to the way the information is organized in the bitstream but what functionality the data represents, and it can be converted back into a bitstream. It allows to better understand the output generated by the toolchain, to create small designs "by hand" or to optimize critical parts of a larger design.
This format is targeted at three audiences:
Beginners: have a tool for understanding the bitstream which the toolchain generates for a given design, and are able to observe directly on the FPGA which effect a change in the bitstream has.
Intermediate learners: are able to express a design in a way which is very close to how the FPGA actually works.
Users: who for some reason needs to exert full control over the implementation of some part of a design are able to express it in the new format, comparable to an Assembler block in a C program.
Integration of a RISC V CPU on LimeSDR project
Student: Cairo Caplan
Mentors: Andrew Back, Zack, Olof Kindgren
LimeSDR is a flexible software-defined platform, that integrates an FPGA and a Lime Microsystems LMS7002M field-programmable RF transceiver, that is 2x2 MIMO and can be tuned anywhere from 100KHz to 3.8GHz. The FPGA is presently used to take care of things such as interfacing, digital down-conversion and tuning, and sample time-stamping.
This proposal address the need for the LimeSDR project to have an full open-source FPGA firmware, which includes replacing it's proprietary NIOS II softcore CPU to a RISC V implementation and adapting the system to a FuseSoC-based development flow.
Integration of OpenRISC Linux Port into OpTiMSoC
Student: Pedro Henrique Penna
Mentors: Stefan Wallentowitz, Philipp Wagner
Open Tiled Manycore System-on-Chip (OpTiMSoC) is an open-source framework that allows one to design and prototype manycore-based platforms on FPGA devices. In its current status, OpTiMSoC offers wide support for experimenting different architectural- level configurations. However, when comes to benchmarking the prototyped platform at software-level, current runtime libraries and operating systems still have to be im- proved. To address this problem, the goal of this project is integrate OpenRISC Linux Port into OpTiMSoC. To do so, a new manycore configuration with a Host Tile will be designed and implemented. The Host Tile will run OpenRISC Linux and will be able to communicate with Gzll kernels running on Computing Tiles via message-passing through the Network-on-Chip (NoC). Overall, the communication infrastructure will be exported to user-level through standard UNIX file system operations.
Updating Sodor
Student: Kritik Bhimani
Mentors: Christopher Celio, Stefan Wallentowitz
Currently sodor is written in out-dated Chisel2, complies to out-dated Priv ISA spec v1.7, not ported to FPGA
The following are the benefits that I am speculating by "updating sodor":
- I have seen 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 undergraduate computer architecture courses with the port of 3 stage on FPGA providing an even more complete overview of comp arch