GSoC’21 Week 1: The Beginning
Well well well it's almost Sunday again.
About the project
Before going on to the weekly report, I shall slightly elaborate on my project since the last post only gave an overview.
As explained in the previous post, BaseJump STL is a comprehensive hardware library for SystemVerilog that contains all the commonly used hardware primitives. It consists of a pretty wide variety of hardware primitives which have been used across various projects.
FuseSoC is a package manager and set of build tools for reusable hardware building blocks facilitating the sharing of designs between projects and reusing open IP cores. One of the major challenges of working on fairly large and complicated hardware projects is tracking dependencies and versioning these dependencies. FuseSoC is a simple and effective solution to this problem.
Why FuseSoC?
- FuseSoC is non-intrusive: Most existing designs require no changes to work with FuseSoC
- FuseSoC is modular: FuseSoC can be used to create an end-to-end flow
- FuseSoC is extendable: Supports a wide variety of simulating and EDA tools and new EDA tools can also be added pretty easily
- FuseSoC is standard-compliant: Much effort has gone into leveraging existing standards such as IP-XACT and vendor-specific core formats where applicable
- FuseSoC is resourceful: FuseSoC already has a standard core library currently consisting of over 100 cores. Other core libraries exist, and more can be added to complement the standard library.
- FuseSoC is free software: It puts no restrictions on the cores and can be used to manage your company’s internal proprietary core collections as well as public open-source projects
- FuseSoC is battle-proven: It has been used to successfully build or simulate projects such as Nyuzi, Pulpino, VScale, various OpenRISC SoCs, picorv32, osvvm and more.
Why is it important?
BaseJump STL contains a lot of hardware blocks that come in handy when working on projects. Still, it may not be easy to use for many as one would have to manually handle the parameters and modify them to fit their existing project structure, which may already be using FuseSoC. On the other hand, having FuseSoC cores for the BaseJump STL blocks would make it a matter of just adding a few lines (if not a single line) to your current project core to use that block across your project. Yes, it's as simple as that.
How is this done?
FuseSoC makes use of cores. The FuseSoC package manager can discover cores stored locally or remotely and combine them into full hardware designs.
A FuseSoC core can be defined as a reasonably self-contained, reusable piece of IP. It is analogous to packages in npm. All the details of a core, such as the source files as well as the targets, dependencies and parameters, are contained in a description file known as the core file. These files have a .core filename extension.
So you might have guessed by this point that a big part of my job is to make these core files for the different cores in BaseJump. The other objectives of the project include creating test benches for different target simulators and EDA tools as required.
Want to know more about FuseSoC and BaseJump? You will have to wait for the next blog ;) (or read the documentation)
Week-1 updates
- Got a clear idea of the process by creating two core files with Verilator lint and testbench targets (bsg_dff and bsg_adder_one_hot)
- Created core files for 93 modules in bsg_misc that have been tested with a Verilator lint target.
- Working on testbenches for these modules.
Next week
- Create/Port Verilator testbenches for the linted cores.
- Take a closer look at and fix bugs in cores that return errors while linting.
- Create core files for bsg_mem modules with lint targets.
