GSoC'22 Project Ideas List

Welcome to the project ideas list for GSoC'22. You are allowed to choose any given project to work on with us or you can suggest your own idea as well.

We encourage you to join our Gitter Chat Room (general) to discuss ideas. Please use the recommended Proposal Format for all projects and you can see the detailed timeline here.

Project 1 - Integration of Compressed (C) extension in NucleusRV Core [selected]

Difficulty: Medium

Designation: 175 hours (medium)

Required Skills: CHISEL, Scala, RISC-V ISA, Compressed ISA of RISC-V.

Mentors: Sajjad Ahmed, Usman Zain

Chat channel: Join gitter channel

Overview:

NucleusRV Core:

NucleusRV is the RISC-V based Core that currently supports I and M extensions. It is used along with the SoC-Now SoC Generator that accepts parameters and generates an entire SoC comprising of a Core with selective extensions, devices that are selected via parameters, and a Bus Interconnect that is used as the communication medium between the Core and the Devices, which is also selected by means of parameters.

Adding the support of Compressed (C) extension in NucleusRV Core would enable RISC-V to reach even more use cases on the deeply embedded side. This way the SoC-Now generator’s scope will also expand so that now the parameter to include the C extension in the Core will become available. Henceforth increasing the value of the Generator and the Core standalone itself. The SoC-Now generator furthermore uses two Frameworks Caravan and Jigsaw, for connecting Buses and Devices respectively in any CHISEL Design/IP

Compressed (C) Extension:

RISC-V ISA contains an extension for compressed instructions, which means instructions that can be executed using only half of the resources. The basic 32-bit instruction is compressed to support only 16-bit space. Henceforth reducing the resource consumption to half and increasing the throughput of the core to double (means instead of 1 32-bit instruction, the core can now execute two 16-bit instructions at one time because only the instruction is being compressed, the core stays put to support the 32-bits). Not all instructions can be allowed to be compressed, but most instructions do get compressed but on certain conditions. The hardware of the core shall be designed in such a way that it can read if an instruction coming into the core from the instruction memory is either a full 32-bit instruction or two 16-bit compressed instructions and then perform their operations according to their desired specs defined and standardized by the RISC-V.

Expected Outcomes:

• Implement 23 instructions of RISC-V Compressed ISA in CHISEL.
• Integrate implemented design with NucleusRV Core.
• Pass all compliance tests for verification.
• Document the project.

Project 2 - Integrate CAN bus controller with Azadi-SoC

Difficulty: Medium

Designation: 175 hours (medium)

Required Skills: SystemVerilog / Verilog, Verilator, Understanding of basic Bus protocol.

Mentors: Zeeshan Rafique, Dr. Roomi Naqvi

Chat channel: Join gitter channel

Overview:

CAN

CAN stands for "Controller Area Network". It is a serial bus protocol used in a network where data has to travel long distances. eg. cars, planes, drones, bikes, etc. It has a special ability to avoid collision between the data packets. It is a carrier-sense, multiple-access protocol with collision detection and arbitration on message priority (CSMA/CD+AMP). CSMA means that each node on a bus must wait for a prescribed period of inactivity before attempting to send a message. It works on the broadcast transmission protocol.
For further info, check this doc.

Azadi-SoC

Azadi-SoC is a low-end embedded class System on Chip. It integrates an extended version of the RISC-V based core. i.e. lowrisc/ibex and few peripherals using tilelink bus protocol. We want the support of the CAN bus controller in our SoC as a Memory Map I/O (MMIO).

Mentee can use the available open-source IP of the CAN bus controller.

Expected Outcomes:

• Integrate CAN bus controller with SoC.
• Complete the testing of the interface and IP after integration.

Project 3 - Add FuseSoC support at SoC level for Azadi-SoC and Rebase ibex core with the latest commit [selected]

Difficulty: Easy

Designation: 175 hours (medium)

Required Skills: SystemVerilog / Verilog, Verilator, YAML, Python, Git.

Mentors: Zain Rizwan Khan, Zeeshan Rafique

Chat channel: Join gitter channel

Overview:

The Azadi-SoC is an open-source System on Chip that uses Ibex as a CPU. We have integrated a Floating Point Unit (FPU) with the older version of ibex which needs to be rebased with the latest commit. Also, the Azadi-SoC uses FuseSoC to manage files. The SoC supports FuseSoC on the core/CPU level but needs to be added at the SoC level.

This project is intended to:

1. Rebase ibex core with the latest commit hash, this will be a little hard because we have made many changes in an older version of ibex core.
2. Add support for FuseSoC at the SoC level.

Azadi-SoC

Azadi-SoC is a low-end embedded class System on Chip. It integrates an extended version of RISC-V based core. i.e. lowrisc/ibex and few peripherals using tilelink bus protocol.

Expected Outcomes:

• Able to build a simulation model for Azadi-SoC using FuseSoC.
• Able to generate and upload bitstream for Azadi-SoC using FuseSoC
• Rebase ibex core with the latest comment.

Project 4 - OpenTCAM(SRAM-based TCAM Compiler) [selected]

Difficulty: Hard

Designation: 350 hours (large)

Required Skills & Tools: Python, Verilog, OpenRam Compiler, Verilator.

Mentors: Ali Ahmed, Sajjad Ahmed

Chat Channel: Join Gitter Channel

Overview:

TCAM(ternary content addressable memory) is specialized memory used for high-speed IP lookup in routers. The term T(ternary) refers to the memory's ability to store data in 3 states 0, 1, and X, which makes it to be used in various applications. But the classical TCAM is really expensive, acquires a large area(16T cell) and has high power consumption, and is not openly available. Unlike SRAM which is cheap, power efficient requires less area(6T cell), and has a mass production ratio. There is sufficient work done on mimicking the TCAM behavior on SRAM using block rams of FPGAs but it's never been done on ASIC. Because manufacturable SRAMs and PDKs were not openly available before Google’s Open MPW shuttle in 2020.

The project is the first of its kind and is aimed to design an SRAM-based TCAM compiler that uses the SRAM model generated with OpenRam compiler to generate configurable TCAM blocks. It has two parts.

1. Mapping of a TCAM table(data that needs to be written in TCAM) to an SRAM table(mapped data that needs to be written in SRAM).
2. Writing a logic around SRAM to mimic the behavior of the TCAM.

Table Mapping:

Block Diagram:

Expected Outcomes:

• Python-based TCAM compiler which can generate Verilog RTL with different configurations of TCAM blocks + Synthesis scripts.
• A table mapping utility that accepts the TCAM table and outputs the SRAM data table.

Reference: Ali Ahmed, Kyungbae Park. “Resource-Efficient SRAM-Based Ternary Content Addressable Memory”, IEEE Transactions on Very Large Scale Integration (VLSI) Systems ( Volume: 25, Issue: 4, April 2017)

Project 5 - Verification of SRAM-based TCAM IP

Difficulty: Hard

Designation: 175 hours (medium)

Required Skills: Python, EDA tools, Verilog.

Mentors: Auringzaib Sabir, Ali Ahmed

Chat Channel: Join Gitter Channel

Overview:

Build a verification environment for SRAM-based TCAM IP to test the behavior of the design. The project includes

1. Building a reference environment of a TCAM.
2. Comparator logic to compare the results from the reference model and the TCAM IP after a specific search query is stimulated to both the reference model and design under test.

TCAM

TCAM (ternary content-addressable memory) is a specialized type of high-speed memory that searches its entire contents in a single clock cycle. The term “ternary” refers to the memory's ability to store and query data using three different inputs: 0, 1, and X.

Expected Outcome:

• Build a python based verification environment for TCAM IP.