Ideas and methods for increased collaboration in the EDA space at CERN (sorry, couldn’t come up with a catchy title)

whoami Work as an FPGA designer at Qamcom Research & Technology Involved with Open Source Silicon since 2010 Member of the OpenRISC core developer group Main developer of FuseSoC Organizer of orconf Director and co-founder of FOSSi Foundation

Why? We want to… ...increase interoperability with other projects ...reduce duplication of work ...avoid or automate tasks that are error-prone and time-consuming ...minimize the maintenance overhead

What? We will focus on three areas Block-level construction Register- and memory maps Core metadata

Block-level construction With traditional HDL Hard to overview Sensitive to simple typos Still requires drawing block diagrams for initial design and documentation

Register and memory maps With traditional HDL Possible, but not pretty (wbgen2 and similar tools exist for a reason)

Core metadata Traditional HDL are not suitable for capturing metadata such as File lists Include directories Required simulation/build options Relations to other cores Documentation (except for inline doc, e.g. Doxygen) These parts are usually handled by a custom build system which can be everything from a project-specific script/makefile/tclfile to more generalized systems such as hdlmake or FuseSoC. With some HDL, such as Migen, the lines between code and metadata are blurry

Ways forward Three ways to improve the situation are identified, each with their pros and cons Smarter HDLs DSLs Declarative source formats

Smarter HDL Block-level construction SV, MyHDL, Chisel, Migen... etc all have some kind of mechanism to group signals/wires into a bus/interface/bundle (There is ongoing work to add this to next version of VHDL as well) This eases the burden of having to manually route each wire between blocks We still need to draw blocks on paper for initial design and documentation

Smarter HDL Register maps OOP makes it easier to create register maps Still likely that the definitions are stored outside of the code Metadata Some HDL, such as Migen, blurs the line between code and (some) metadata In most other cases, metadata is stored separately

DSL Custom-made DSLs are likely the most efficient solution for each of the problems. at CERN wbgen2 for register maps hdlmake for (some) metadata (did I miss any?) BUT! Requires development Requires maintenance Limits interoperability with other projects

Descriptive source formats If the format is standardized and widely used There are likely already tools to solve some parts Higher chance of interoperability with other projects Likely to be battle-proven (best practices, known issues) Non-standardized formats have (almost) the same penalties as a custom DSL (development, maintenance, interoperability)

IP-XACT A descriptive source format: From Wikipedia IP-XACT is an XML format that defines and describes electronic components and their designs. IP-XACT was created by the SPIRIT Consortium as a standard to enable automated configuration and integration through tools. The goals of the standard are to ensure delivery of compatible component descriptions from multiple component vendors, to enable exchanging complex component libraries between electronic design automation (EDA) tools for SoC design (design environments), to describe configurable components using metadata, and to enable the provision of EDA vendor-neutral scripts for component creation and configuration (generators, configurators). IP-XACT has support for describing all three problem domains To be solved Many tools still need to be written

IP-XACT Good Covers the problem areas outlined in the outset (block-level design, register/memory maps, core metadata) Most accepted standard (IEEE 1685-2009 and 1685-2014) Bad unwieldy XML standard Requires some strict rules to be enforced (e.g. can’t mix structural and RTL code) Controlled by Accellera (WG membership is expensive!) Not good at dynamic components (e.g. n-port arbiter) Madness Big parts of the standard is completely crazy and should be avoided. See olofkindgren.blogspot.com/2016/11/ip-xact-good- bad-and-outright-madness.html

IP-XACT: The good parts Filesets Collection of files with metadata Can be swapped out for different tools (views) Design configurations Hierachical: The block diagram view Flat: The blackbox view Memory maps Each core define its registers At the interconnect level, ports are associated with address spaces Supports bridges and other more esoteric concepts

Kactus2 Open source GUI application. Good for: Entering core metadata (from scratch or by importing HDL) Doing block-level design Building register maps Bad for: Design automation. Can only export files from GUI. Not from CLI Interaction with EDA tools. Only basic Quartus/ModelSim support

FuseSoC A package manager and build system for HDL code Similar in scope to hdlmake Written in Python. Can be used as a stand-alone tool or integrated as a library in other tools (Optionally) uses IP-XACT VLNV tags for core names (e.g. ohwr.org:general-cores:wb_i2c_bridge:1.0) (Optionally) uses IP-XACT files to find file metadata (name, type, isIncludeFile, intended use)

ipyxact Python library to read and write IP-XACT files Supports only a subset (most of the sane parts) of the standard Contains basic examples for generating markdown + C headers from register maps and generating an IP- XACT file for a basic Wishbone component Used internally by FuseSoC to get file lists from IP- XACT files and by rgen to read register maps

What’s missing? CLI tool for creating top-level wrappers (Wishbone, AXI, etc) slave generators Documentation generators Kactus2 is still buggy/hard to use in some areas Lots of small useful utilitities Note: For some of these tasks, free (but not FOSS) tools already exist (e.g. Vivado, http://www.edautils.com/ip-xact.html

Ideas Extend wbgen2 to read/write IP-XACT register/memory maps (perhaps using ipyxact) Extend hdlmake to read IP-XACT filesets (or try FuseSoC) Extend documentation generator tools (wbgen2, any others?) to parse IP-XACT Extend sdb to parse IP-XACT metadata Define VLNV identifiers for all ohwr IP cores Create CLI library to generate VHDL/verilog top- levels (perhaps based on Kactus2 or ipyxact) File bugs for existing tools :)

That’s all folks! Let’s start talking! OlofKindgren https://www.linkedin.com/in/olofkindgren http://olofkindgren.blogspot.com qamcom librecores FossiFoundation http://www.qamcom.se https://librecores.org http://fossi-foundation.org OlofKindgren http://olofkindgren.blogspot.com https://www.linkedin.com/in/olofkindgren OlofKindgren http://olofkindgren.blogspot.com https://www.linkedin.com/in/olofkindgren OlofKindgren http://olofkindgren.blogspot.com https://www.linkedin.com/in/olofkindgren OlofKindgren http://olofkindgren.blogspot.com https://www.linkedin.com/in/olofkindgren OlofKindgren http://olofkindgren.blogspot.com https://www.linkedin.com/in/olofkindgren OlofKindgren OlofKindgren OlofKindgren OlofKindgren FossiFoundation http://fossi-foundation.org FossiFoundation http://fossi-foundation.org FossiFoundation http://fossi-foundation.org FossiFoundation http://fossi-foundation.org FossiFoundation http://fossi-foundation.org FossiFoundation FossiFoundation FossiFoundation FossiFoundation librecores http://librecores.org librecores http://librecores.org librecores http://librecores.org librecores http://librecores.org librecores http://librecores.org librecores librecores librecores librecores http://olofkindgren.blogspot.com http://olofkindgren.blogspot.com http://olofkindgren.blogspot.com http://olofkindgren.blogspot.com http://fossi-foundation.org http://fossi-foundation.org http://fossi-foundation.org http://fossi-foundation.org http://librecores.org http://librecores.org http://librecores.org http://librecores.org https://www.linkedin.com/in/olofkindgren https://www.linkedin.com/in/olofkindgren https://www.linkedin.com/in/olofkindgren https://www.linkedin.com/in/olofkindgren