Google Summer of Code (GSoC) 2020 - Report

Abstract

Making WARP-V compatible with OpenPiton (BYOC - Bring Your Own Core) framework.

WARP-V is an open-source and highly flexible and configurable CPU core with customizable ISA and pipelines written in the emerging “Transaction-Level” modeling. OpenPiton is an open-source, general-purpose, multi-threaded manycore framework for heterogeneous architecture research. This project aims to evolve WARP-V further by adding necessary support for memory, microarchitecture extensions etc., and make it RISC-V Linux compatible and then integrate it with the OpenPiton-derived Bring Your Own Core (BYOC) Framework. This would open the doors for the first Linux-capable processor based on TL-Verilog and easy scaling to multicore heterogeneous implementation with OpenPiton.

Mentors

• **Steve Hoover,** Founder, Redwood EDA (WARP-V Lead Developer)
• **Jonathan Balkind,** Princeton University (OpenPiton Lead Developer)
• **Ákos Hadnagy,** Delft University of Technolgy (WARP-V Developer)

Student

Shivam Mahesh Potdar

Senior Year EE Undergraduate

National Institute of Technology Karnataka, India

Repositories Involved

stevehoover/warp-v

bring-your-own-core/byoc

Overview of Work Done

WARP-V Related

Upgrade WARP-V from RV32I to RV32IM[A]

• Support for RISC-V ISA M Extension (Multiplication and Division instructions)
• Adding support for these meant supporting long latency operations in the microarchitecture. The division module usedtakes about 37 cycles for results, while multiplication takes 5.
• Currently, this is handled by making the core stall till the operation completion and then the result is flown into the result mux in the last stalling cycle.
• With this the core currently supports two kinds of mechanisms for late-arriving results, other one being "second-issue" for loads
• PR (s) (this part is distributed over more than one PRs, including but not limited to) - https://github.com/stevehoover/warp-v/pull/26 https://github.com/stevehoover/warp-v/pull/32

Formal Verification with M Extension

• Akos did a great job with the formal verification of WARP-V last year with riscv-formal framework by Symbiotic EDA.
• The interface with riscv-formal had to be upgraded to work with the M extension (and supporting the long latency instructions).
• The same two mechanisms described above were factored in for formal checks as well.
• PR - https://github.com/stevehoover/warp-v/pull/36

Upgrade the CI mechanism to support parallel runs

• Before the summer, we had Travis CI integrated with WARP-V to run formal checks based on Sandpiper SaaS and riscv-formal.
• This was upgraded to support parallel runs (both 1 stage and 3 stage pipelines running simultaneously).
• So for every line committed to WARP-V repositories, you know whether it is still compliant with RISC-V for multiple pipelined implementations. That's the beauty of TL-Verilog! 😁
• PR - https://github.com/stevehoover/warp-v/pull/38

OpenPiton Integration

• Other cores which are supported in BYOC have a separate transducer module which instantiated alongside the core. With WARP-V and the flexibility that is possible, we can generate one top-level module (warpv_openpiton) to directly contain all the interface signals with the BYOC Transaction-Response Interface (TRI).
• Both decoding the encoding logic for the TRI signals is internal to the core
• To support memory requests with variable latency, a generic external memory interface is in progress, which would eliminate the internal instruction and data memory conditionally.
• PR - https://github.com/stevehoover/warp-v/pull/50