Towards the Ariane Desktop: Display Output for Ariane on FPGA under Linux (S/B/G)
Ariane (recently renamed to CVA6, ) is an open-source, general-purpose RISC-V CPU architecture which implements the RV64GC instruction set and is capable of running Linux. Intended as a research and demonstration platform, it has been taped out in several incarnations and can be mapped to an FPGA device for low-cost evaluation and testing. The supported target for FPGA emulation is the Genesys II board, and the mapping flow and auxiliary hardware environment provided by the Ariane maintainers offers a rich feature set, making it possible to run RISC-V programs on custom hardware in real time.
On Ariane, user interaction with the programs running on the CPU was until recently limited to an UART link, which only allows for text input and output and requires a computer to be connected. In a previous project, a display peripheral (called PAPER) was integrated into the FPGA platform and tested.
PAPER is an AXI-compliant peripheral module which supports the streaming of image (framebuffer) data from memory, as well as possessing the capability of streaming a text buffer in VGA text format – such as the Linux Virtual Terminal’s internal text representation – from memory and graphically rendering the text it contains. While PAPER has been successfully integrated into the FPGA platform and tested using simple bare-metal examples, driver support under Linux has not yet been implemented, and the current hardware implementation still has a prototype character.
The overall goal of this project is to take a step towards a fully-featured autonomous Linux system based on Ariane with extensive user interaction support. To this end, you will work to provide usable display output, directly from the FPGA’s HDMI port, on the FPGA port of Ariane. This will involve both hardware design tasks to improve maturity and extend the current feature set, as well as software development in the form of Linux driver development.
In this project, you will learn to work with and extend an advanced processing system all the way from the RTL/hardware level to the Linux kernel and userspace levels. This will provide you with unique insights into the workings of such a platform, and these insights will apply readily to the Linux systems you will encounter in your academic, professional and private lives. You will learn how to hardware peripherals are designed and integrated into processing systems, as well as how to establish software support for them both in bare-metal applications and under Linux.
- Support for higher resolutions: Due to the current structure of the AXI infrastructure, output resolutions are limited to a maximum of SVGA (800x600) at a 60 hertz refresh rate. By refactoring the AXI infrastructure, you will eliminate this restriction and allow resolutions of Full HD and beyond.
- Resource reclamation: Currently, FIFOs are implemented in HDL, which results in relatively high flip-flop utilization. By replacing them with Xilinx primitives, the FF utilization of the peripheral can be reduced by ~66%.
- Support for Runtime-Configurable Resolution: Currently, the frequency of the output pixel clock is fixed at compile time. In order to make the resolution runtime-configurable, you will replace the fixed-frequency clock generator with a configurable one. This will make it possible to change the output resolution while the system is running and without requiring time-intensive re-implementation.
- Verification: The assembled platform must be thoroughly tested to ensure complete and correct functionality. Furthermore, it must be ensured that the modifications don’t impact the system’s critical path.
- Bare-Metal Driver Adaptation: The existing bare-metal software framework is kept as platform-agnostic as possible, but certain specifics must be adapted to correspond to the specific platform. The goal is to achieve an easy-to-use library which provides user-friendly support for both image and text display in bare-metal applications.
- Linux Device Driver: In order to interact with the PAPER peripheral under Linux, it must be abstracted by a simple device driver kernel module. This driver will allow higher-level drivers (e.g. a console driver) to interact with the peripheral through a unified interface.
- Linux Console Driver: A prototype console driver for Linux exists, which allows the output of the linux console to be displayed from the first line on PAPER’s original target platform, the ZEDBoard. The objective is to develop this driver to provide a more streamlined integration into the Linux kernel and to port the resulting software to source tree for the Linux distribution targeting Ariane.
Depending on your progress and interests, several further steps can be considered, such as:
- Feature Extensions (HW): As an example for an optional goal, the PAPER module’s functionality could be extended to allow for runtime-customizable fonts in text mode.
- Linux display driver (SW): In order to provide graphical output under Linux, a framebuffer driver or a KMS/DRM display driver can be implemented.
- Input Peripheral Support (HW): In order to completely remove dependence on serial UART input, support for keyboard input over PS/2 or USB could be implemented. This may be realized with a dedicated hardware peripheral (re-using an existing open-source core is the most time-effective option), or by using GPIO pins to “bit-bang” the PS/2 protocol. The Genesys II board has both a dedicated USB HID host which converts USB to PS/2 and a general-purpose USB 2.0 controller which is attached to the FPGA with an ULPI interface.
- Input Peripheral Support (SW): If support for PS/2 keyboard input is implemented, this will require software support under Linux.
We can also discuss targeting a subset of the tasks above depending on your time frame and interests. Possible follow-up work could involve a tape-out of the system.
- Strong interest system design and hardware/software interaction
- Experience with HDLs (preferably SystemVerliog) such as taught in VLSI I
- Basic knowledge of operating systems
Composition: 40% RTL Implementation, 20% Verification, 40% Software Design