- FPGA chips database visualizer improvements
- DSP hard block integration in F4PGA
- Improve the visual representation of the placement done by VTR
- Spartan6 bitstream documentation
- Document XADC and
DNA_PORTblocks for Xilinx Series 7 - SystemVerilog preprocessor for Verible
- F4PGA toolchain integration in mainline Edalize
- FPGA Tool Performance Results Visualization
- Generalization of wrapper scripts for installed F4PGA toolchain and making them OS agnostic
- Symmetrical placement and routing APIs in OpenFASOC
- Smart and cloud based infrastructure to test analog blocks functionality and performance in OpenFASOC
The F4PGA database visualizer is an open source tool for visualizing the structure of FPGA chips covered by the F4PGA project. This is very useful in understanding the internal structure of specific FPGAs and reasoning about ways to best support them in the open source tools. Currently the tool supports visualizing the top level structure (tiles) of an FPGA chip as it is documented and modeled in open source toolchains.
The main goal of the project is to extend the tool with the possibility of visualizing internal structures of the tile cells of an FPGA chip. This will require the following changes:
- Extending the frontend with functionality of rendering sub tiles within a tile, or with a functionality of “entering” a tile to see its details
- Extending the intermediate format used by the tool with functionalities required to handle multiple levels of the device
- (Nice to have) Adding a more detailed visualization of the tiles internals (Basic Logic Elements [like LUTs, DFFs], and their interconnections
The work will result in improvements in the existing FPGA devices visualization software allowing it to show details of logic tiles of the visualized chip. As part of the work, the existing visualization demo will have to be extended to present the tile details.
Python, NodeJS, basics of HTML/CSS
Medium: the project touches different aspects of the tool:
- Intermediate representation of the chip data
- Frontend and grid rendering
During the project it will be necessary to collaborate with the F4PGA development team to determine the best way of presenting the tiles details so that it is understandable to FPGA users.
Duration: 175 hours or 350 hours
Mentor: @kgugala
Modern FPGAs are equipped with multiple dedicated hard-blocks which can perform operations that would be slow and resource consuming if implemented as a part of a design in the fabric. An example of such a hard-block is a DSP (Digital Signal Processing) unit. DSP blocks can perform basic math operations like addition, multiplicaion and multiply-accumulate which are very common in signal processing pipelines.
The DSP hard block of the Xilinx 7-series FPGA devices (DSP48E) is currently documented in Project X-Ray, but it currently lacks support within the F4PGA architecture definitions. The aim of this project is to add support for DSP48E to the architecture definition so that it can be supported by the toolchain. This will enable designs using DSPs to be synthesized, placed and routed correctly.
This project will also aim at enabling the entire testing flow for designs using Xilinx 7-series DSP hard blocks to complete successfully. The testing flow includes:
- Verilog-to-Bitstream using the F4PGA toolchain
- Fasm2bels to re-generate the original netlist from the bitstream output of F4PGA
- Proof-test through Vivado to verify the correctness of the netlist.
This project will enable full support of DSP hard blocks within the F4PGA toolchain, which will translate to improving coverage for real world designs and more widespread adoption.
- Familiar with the following tools: Vivado, Yosys
- Programming/Scripting languages: Python, C++
- HDL: Verilog
Hard: This project takes into consideration many different aspects of the toolchain, including the architecture generation infrastructure, synthesis and place and route. Moreover, the skill-set required to achieve the goal is very diverse.
Duration: 350 hours
Mentor: @mkurc-ant
During the fasm2bels stage in f4pga-arch-defs, the fasm information is transformed into a post-P&R design in form of a Verilog netlist and few TCL scripts that can be later on read by Vivado. One of the scripts contains the information about which BELs (Basic Logic Elements) should be instantiated and how they should be connected. Currently, however there is no information about which BEL corresponds to which instance in the original netlist which makes the placement graph hard to read. The idea is to implement a mechanism that will allow for better visual representation of the placement done by VTR (Verilog to Routing) by highlighting the instances on various hierarchy levels with a set of colors. Having a clear visualization of the post-placement instances and their mapping to the physical blocks of the FPGA would be a great benefit for the toolchain users, who can leverage this information to better understand which parts of the design may need optimization.
The result of this work should be a Vivado compatible script produced during the fasm2bels stage in the F4PGA flow that will perform the highlighting which can be later on viewed in the Vivado design viewer.
- Familiar with the following tools: Yosys, Vivado
- Programming/scripting languages: TCL, C++
Medium: This project requires some hands-on experience with the Yosys and Vivado tools as well some basic knowledge of the TCL scripting language. C++ is vital to enhance the existing tools in the F4PGA toolchain.
Duration: 175 hour or 350 hours
Mentor: @acomodi
Spartan6 is a popular FPGA from AMD (formerly Xilinx) which is still used in many boards on the market today. For exactly this reason there is continuous interest in creating an open source toolchain for this architecture. There has already been some work in F4PGA with regard to this architecture. Namely, it’s possible to read the original bitstream and convert to a textual representation of its content in the form of what bits in which frame are active. F4PGA tools can also generate a bitstream from a textual representation. The missing part falls into the scope of project X-Ray where the meaning of those bits found in the bitstream has to be determined. The idea is to extend the existing set of project X-Ray infrastructure/tools/fuzzers to document the information which bits correspond to what features of the Spartan6 architecture
As a result of this work some basic fuzzers required in X-Ray for a small Spartan6 FPGA (e.g. XC6SLX9) will be created. One of them is the part fuzzer which produces the information about how many configuration columns and rows there are. Another is the tilegrid fuzzer which lists what tiles the FPGA is built on.
- Familiar with the following tools: Vivado, ISE
- Programming/scripting languages: TCL, Python, C++
- HDL languages: Verilog
Hard: This project requires some deeper understanding of FPGA architectures. Experience with the ISE tool and TCL scripting language is useful for this task. Python and C++ are vital to create or enhance existing tools used in X-Ray.
Duration: 350 hours
Mentor: @tmichalak
Among other dedicated hard-blocks performing functionality that cannot be implemented directly using FPGA fabric Xilinx 7-series devices provide the XADC block and DNA_PORT block. The former is a generic dual 12-bit A/C converter capable not only of sampling external voltages but also reading the device's internal sensors like the temperature sensor. The latter block allows accessing unique device identification data a.k.a. "DNA".
F4PGA’s FPGA flow depends on so-called architecture definitions, which are hardware descriptions of specific FPGAs that enable using specific configurable and hard blocks. Documentation of Xilinx 7-series hard blocks is covered by project X-Ray. The task is to extend the existing fuzzer to document all XADC related configuration bits as well as create a new fuzzer for the DNA block so that they become available in the open source flow.
As a result of this task 2 complete fuzzers shall be created:
XADCfuzzer which will be the extended version of the existing fuzzer for XADC that will generate the list of XADC related features and the bits corresponding to themDNA_PORTfuzzer that will generate the list of DNA_PORT related features and corresponding bits
- Scripting languages: TCL
- HDL languages: Verilog
Easy: The task mostly requires getting familiar with the methodology used in other X-Ray fuzzers and reusing existing or coming up with your own approach to get the expected outcome.
Duration: 175 hours
Mentor: @mkurc-ant
SystemVerilog is the most popular HDL in ASIC design. The open source ecosystem around SystemVerilog tooling is constantly growing. One of the parts of the ecosystem is Verible. It’s a multi-purpose SystemVerilog parser that comes with various tools which can be used for linting, formatting or indexing SystemVerilog code. It also comes with useful integrations like github actions (CI scripts) or LSP support.
Currently, verible mostly focuses on handling un-preprocessed files, which is fine for most of its use cases. However there are cases when the knowledge about the preprocessed code is absolutely necessary. One example would be macros that contain parts of code that is needed for the code outside of macros to make sense (e.g. the begin keyword when used inside a macro).
The goal of this project is to write a generic SystemVerilog parser library that can be used by Verible to preprocess SystemVerilog sources.
A standalone library with a well defined API that can be used to preprocess SystemVerilog sources
- Programming languages: C++, Bash, Python
- HDL languages: Verilog or SystemVerilog
- Operating system knowledge: Linux
Hard: This project requires a good understanding of the language parsing process (lexing, parsing, preprocessing) but also a good understanding of linting and formatting concepts
Duration: 350 hours
Mentor: @tgrochowik
Edalize is a Python library to easily interface with many different EDA tools. It is heavily used in FPGA-tool-perf to generate the setup for many different design builds. Moreover, tools such as Edalize lower the barrier to approach the vast landscape of EDA tools, thus making it a great fit to enable the F4PGA toolchain support, greatly improving its usability. Currently, FPGA-tool-perf uses a forked version of Edalize, as it required some changes for the adoption of the F4PGA toolchain. The idea is to move all the changes in upstream Edalize, to lessen the burden of maintaining the internal fork, with the advantage of integrating the most recent features of the upstream repository, such as the metrics extraction, which is currently handled externally in FPGA-tool-perf.
FPGA-tool-perf uses the upstream Edalize library, with all the additional features to extract the relevant data, as well as a full integration of the F4PGA toolchain within the library.
- Python
- FPGA tools usage
Easy: This project is mostly aimed at improving and upstreaming an already existing development code.
Duration: 175 hours
Mentor: @acomodi
FPGA-tool-perf is a tool to run and profile different FPGA designs, supporting many toolchains, both open and closed source. Its main focus is to gather information about different interesting metrics, such as run-time, frequency, area-utilization and more. One of the great advantages of using such a tool is being able to verify and monitor the performance over time of all the different desings and toolchains, understand the overall status of the EDA ecosystem and identify what can be improved and optimized to achieve better results. While the core of the tool has most of the functionalities supported, and performance data is correctly generated by CI, a proper visualization tool of said data is still lagging behind. At the moment, the data is visualized on this page which is generated by the CI, but it requires some changes (both backend and visualization) to improve the performance of the code and improve the presentation layer of the collected results.
The final product should be a user-friendly interface, preferably web-based, that is updated regularly and automatically with every CI run, which can display all the relevant metrics of the gathered data.
- Web technologies (JavaScript, Web Frameworks)
- Python
- UX
Medium: the project touches different aspects of the tool, from data generation (which might need to be adjusted accordingly during the project’s development) to data visualization.
Duration: 175 hours or 350 hours
Mentor: @acomodi
F4PGA aims to become a "GCC for FPGA" where a user can choose the target FPGA device merely by specifying different command line switches in the toolchain invocation command. Currently in F4PGA there are wrapper scripts written in Bash that invoke the actual tools like Yosys, VPR and other helper Python scripts. This takes away the need for the user to know the exact stages of the flow - which tools and in what order have to be executed to generate a bitstream given some specific HDL source code.
Unfortunately those scripts are currently specific to Xilinx 7-series devices. Moreover adding support for a new architecture(s) and device(s) to F4PGA requires the modification of some hard-coded parameters that are part of the scripts. It is also not possible currently to add another intermediate stage to the whole Verilog to bitstream flow. Being written in Bash also prevents from using the toolchain on OSs other than Linux (eg. on Windows).
- As a result of this task the toolchain wrapper scripts will be re-written to Python and become common to all F4PGA architectures. The flow definition for each device will be read by them from a config file.
- The F4PGA toolchain runs on Linux, Windows and MacOS with the newly created Python wrappers. The flow on all three OSes is identical so that the end user is not influenced by the choice of OS.
- Scripting languages: Bash, Python
- Operating system knowledge: Linux, Windows, MacOS
Medium: The task does require more than just Bash to Python script conversion. It requires developing a unified way of describing the toolchain flow, as well as writing scripts which will use the description to broaden the scope to more platforms while making the flow more user friendly.
Duration: 175 hours or 350 hours
Mentor: @mkurc-ant
OpenFASOC is a framework used for automated IC design generation. It sits on top of tools such as OpenROAD primararly but recently is using tools such as gdsfactory and ALIGN. Currently, we have enabled a few Python based functions that allow us to help with our analog layout requirements, and we are planning to create more general APIs that could be generalized to new analog designs.
- As a result of this, it is expected to add new APIs that guides OpenROAD's placement/routing tools to enhance specific parts of the placement/routing steps (symmetry, guard banding, non default rules, symmetry, etc..)
- Call tools such as gdsfactory or ALIGN, to improve specific cells (aux cells) to improve the overall layout performance of the smaller circuits, routing or placement.
- Programming languages: Python, C++
- Operating system knowledge: Linux, Windows
- Nice to have: Circuit level and Physical Design basic understanding
Medium: The task does require physical design understanding, python and C++ coding skills are needed
Duration: 350 hours
Mentor: @msaligane
Smart and cloud based infrastructure to test analog blocks functionality and performance in OpenFASOC
OpenFASOC is solely using open source EDA tools to build automated analog and IC blocks. Since we are following a software style approach to hardware, it is important to make sure every new commit or pull request do not impact our generator's final result. This can be either done by checking functionality (DRC, LVS, Simulation), or performance (IE: inaccuraccy of a temp. sensor, or figure of merit (FOM) of an ADC etc..). Moreover, to be able to leverage the high computing power provided by Google Cloud Platform, design space exploration by generating a large number of blocks could be used to enable data driven optimizations at circuit/layout level by testing all the possible design input configurations.
- Analog generators can be tested continuosly as we update its source code to check for functionality and performance
- Smart and granular tests are used to detect small design improvements or issues
- Create Importable Python modules for each of the generators as explained here
- Programming languages: Python, C++
- Operating system knowledge: Linux, Windows
- Nice to have: Circuit level and Physical Design basic understanding
Medium: The task does require python and C++ coding skills are needed, circuit IC design knowledge would be useful.
Duration: 350 hours
Mentor: @msaligane