| layout | title |
|---|---|
page |
Google Summer of Code 2016 - Ideas for Projects |
We are accepted as an organization in this years Google Summer of Code. Students can apply with proposals in the time frame from March 14 to March 25. We have collected some ideas in the following, but we encourage you to send your own ideas to [email protected] or post to our mailing list.
We also recommend you to have a look at the ideas of our close friends at lowRISC and MyHDL.
- Dependency Handling in the FuseSoC Package Manager (Python)
- Constrained randomised testing with coverage tracking in Cocotb (Python)
- Constrained randomised testing with coverage tracking in Cocotb (Python)
- Contributions to Yosys Ecosystem
- Visualization and Debugging Interface for jor1k (JavaScript, HTML)
- Extend LibreCores.org (PHP, Symfony, MySQL, HTML, Javascript)
- Create a Parallella acceleration framework for GNU radio (Python, C)
- Your LibreCore (Verilog, VHDL, Chisel)
- Port RISC-V core to Parallella (Verilog, C, Chisel)
- QEMU port of OpenRISC (C)
- OpenRISC: Improved OpenOCD support for transports and SMP (C, Tcl)
- OpenRISC Port of the ROMCC (ROM C Compiler) (C)
- OpenRISC GCC Port (C)
- Reference Implementation for a Leakage Aware Compiler Optimization (Verilog, C/C++)
- GNU Superoptimizer 2.0: Reference Implementation for the AAP (C/C++, AAP Assembler)
- An Altruistic Processor (AAP): Reference Implementation (Verilog, FPGA)
FuseSoC is a package manager for digital design blocks. It fetches IP blocks from different sources and as part of this project the handling of the cores and especially dependency handling are improved.
The dependency handling in FuseSoC is currently limited to specifying an exact version of a dependency. For this project we want to extend this so that cores can have a dependency on a range of versions. We also want to support alternative dependencies for cores with similar interfaces. The dependency handler also need to be able to resolve conflicts and produce a minimal set of dependencies.
Much of the inspiration for the dependency handling comes from Gentoo's ebuild format, and the format used for the DEPEND and RDEPEND lists could serve as a good starting point. If time permits it would also be very interesting to add support for Gentoo style useflags to the cores as well.
Hopefully this project will produce a general-purpose python dependency management library which can be used in other projects as well.
Skill Level: Intermediate
Language/Tools: Python
Mentor: Olof Kindgren
Goal: Extend the Cocotb co-simulation library to support constrained randomised testing (e.g. via Google or-tools) and to track achieved coverage of the tested HDL.
Details: Cocotb is a Python framework for testing VHDL and [System]Verilog hardware designs. Although various open source simulators are available, none of them provide the advanced verification features of expensive proprietary simulators. This project will implement constrained randomisation and functional coverage collection in Cocotb, giving open source projects these capabilities.
Constrained Randomisation is a similar concept to fuzz testing; generating random stimulus transactions according to certain constraints in order to exercise a hardware design. To understand how well the randomly generated inputs are testing design the we also need to instrument the code to track metrics on which scenarios have been exercised (known as functional coverage).
The goal of this project is to provide a convenient interface to an existing constraint solver from Cocotb and create and manage a database of functional coverage points. To facilitate processing of the coverage data we’ll need to export to various formats for consumption by other tools. We can also integrate coverage information with existing software development services such as coveralls.io.
By undertaking this project you will learn about latest ASIC/FPGA verification practices and the interaction between hardware and software development
Skill Level: Intermediate
Language/Tools: Python
Mentor: Chris Higgs
YoSys is a framework for Verilog RTL synthesis. The following list is incomplete and is meant to inspire student proposals. Do not simply pick one of the projects on this list! We are interested in genuinely original student proposals. Please contact FOSSi GSoC team early in the process to discuss your ideas.
Ideas regarding Project IceStorm (the FOSS iCE40 FPGA flow)
- Improvements in Arachne-pnr
place & route tool, such as
- Analytical (e.g. quadratic wirelength) placement
- Support for LUT cascade feature
- Support for BRAM cascade feature
- Improved inference of SB_IO cells
- Timing driven place and route
- Speedups (OpenCL?)
- Alternative iCE40 place and route flow (e.g. using VPR/VTR)
- Additional support for more iCE40 devices (e.g. UltraLite)
- In-hardware validation flow for chip databases
Ideas regarding Yosys
- Additional front- and back-ends
- New architectures (e.g. additional FPGA families)
- New non-synthesis flows (verification, etc.)
- New yosys commands and other features
Ideas regarding YosysJS
- Interactive schematic viewer running in the web browser
- Puzzle games and other web-based Verilog training tools
- Port of Icarus Verilog to JavaScript (using EMCC)
Skill Level: Intermediate/Advanced
Mentor: FOSSi GSoC team
jor1k is an emulator for the OpenRISC and RISC-V platform and is the fastest emulator which runs in the web browser and boots Linux. It comes with a working underlying framework and a comprehensive library for hardware devices such as a framebuffer and network support. It would be nice for teaching and for a broader audience to give the user a much more advanced user interface with debugging capabilities (disaassembler, breakpoints, ...) and further visualization features (status screens). Hence the student would have a lot of freedom for improving jor1k, issues #24, #107 and #110 are good starting points for a proposal.
Skill Level: Intermediate
Language/Tools: Javascript and HTML
Mentor: Sebastian Macke
LibreCores is a community web site with the goal of providing an overview of IP cores and the corresponding ecosystem, similar to the now abandoned OpenCores.org site. For further information on our goals, see the FOSDEM Presentation slides announcing LibreCores. The full site source code is available on GitHub. The issues also contain some plans and tasks to be taken on.
Please talk to Philpp for a full description of available tasks and a discussion what can/should be done, also based on your existing experience.
Skill Level: Intermediate
Language/Tools: PHP with the Symfony Framework, MySQL, HTML/JS
Mentor: Philipp Wagner
GNU radio is an immensly powerful framework for software defined radio, but it’s only as good as its built in hardware support. Currently, there is support for SIMD, GPUs, and FPGAs, but there is no support for manycore array accelerators like Epiphany. The project involves creating the equivalent of an accelerator (done in an FPGA) for the Epiphany manycore accelerator. All code should be written in "high level" C to maximize portability between manycore architecture.
Language: Python/C
License: GPL/MIT
Mentor: Andreas Olofsson
Our core ambition is to grow the community projects around open source components. LibreCores are IP cores, but they are free and open. If you have a great idea for such a LibreCore, we are happy to mentor you, but it is important that it is re-usable and contains everything needed for simple and flexible integration, like testbenches, the required software drivers etc. So, it is important that you discuss a proposal intensively.
More details will follow. Questions?
The RISC-V is an exciting new open source processor architecture founded at UC Berkeley. A test environment has been created for the Zynq based Zedboard development platform. Given that there are over 10,000 Parallellas in the field in 75 countries and 200 universities, it would be a great services to computer architecture researchers if there was a ready to run reference implementation of the RISC-V rocket core running in the Zynq FPGA on the open source Parallella board.
Language/Tools: Verilog, C, Chisel
Mentor: Andreas Olofsson
QEMU is a generic and open source machine emulator and virtualizer and contains a lot of features which would be very helpful for the OpenRISC community. There exists an old port but it is outdated and very slow. The goal of this project would be to rewrite and improve the current port and upstream the patches. Test cases, device support and a working image running Linux with proper device support should be provided as well.
Skill Level: Intermediate
Language/Tools: C
Mentor: Sebastian Macke
OpenOCD supports the OpenRISC processor, but the current backend is tailored to the needs of JTAG. Hence, we want to improve the backend to allow other physical transports, which is generally possible with OpenOCD. If time permits, the student may also add multi-thread (SMP) support to the OpenRISC backend.
Skill Level: Intermediate
Language/Tools: C, Tcl
Mentor: Stefan Wallentowitz
ROMCC, created by Eric Biederman, generates machine code from C that uses only CPU registers—meaning machine code that needs no stack and, therefore, no initialized RAM. This compiler is used in the Coreboot project.
More details will follow. Questions?
There is a GCC port for OpenRISC, but it lacks the potential to become a part of the official upstream GCC due to copyright assignments. We hence plan a clean room rewrite and have separated a summer assignment to start with the basic compiler, based on other clean room implementations.
More details will follow. Questions?
The Leakage Aware Design Automation Project (LADA) is led by Dr Elisabeth Oswald at Bristol University and funded over four years by the UK EPSRC.
Embecosm is industrial partner to this project, charged with applying the research to the next generations of free and open source compilers, such as GCC and LLVM. Many of these innovations involve hardware changes that the compiler can leverage (e.g. checksumming code on the fly).
In this project you will work to add appropriate hardware functionality to your favorite open hardware processor design (AAP, OpenRISC, RISC-V etc), and then extend either GCC or LLVM to support that hardware functionality. You will need both Verilog and Compiler skills, as well as some grasp of side-channel attacks in cryptography.
Skill Level: Advanced
Language/Tools: Verilog, C/C++
Mentors: Jeremy Bennett, Simon Cook
James Pallister presented the design and initial implementation for GSO 2.0 and GNU Tools Cauldron in 2015: Youtube
In this GSoC project you will implement GSO 2.0 for the AAP instruction set and demonstrate its effectiveness over code generate using LLVM for AAP. An advanced student would implement stochastic superoptimization to allow longer code sequences to be tackled.
Skill Level: Intermediate/Advanced
Language/Tools: C/C++. AAP assembler
Mentors: Jeremy Bennett, Ed Jones
AAP is the compiler writer's architecture from hell. It was created to advance compiler support for common deeply embedded architectures, and includes many features that cause great difficulty when compiling.
In order to be credible, we must show that AAP can be implemented on real silicon. A student implementation was created by Dan Gorringe in 2015 and presented at ORConf 2015 at CERN: Youtube
This GSOC project is to provide a full implementation, complete with debug interface to run on an appropriate small FPGA board such as a DE0-Nano.
Skill Level: Advanced
Language/Tools: Verilog, FPGA synthesis tool flow