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

2. 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

3. 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

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

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

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

7. 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

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

9. 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

10. 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

11. 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

12. 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)

13. 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

14. IP-XACT
Good
Covers the problem areas outlined in the outset (block-level design, register/memory maps, core metadata)
Most accepted standard (IEEE and )
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

15. 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

16. 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

17. 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)

18. 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

19. 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,

20. 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 :)

21. That’s all folks! Let’s start talking!
OlofKindgren
qamcom
librecores
FossiFoundation
OlofKindgren
OlofKindgren
OlofKindgren
OlofKindgren
OlofKindgren
OlofKindgren
OlofKindgren
OlofKindgren
OlofKindgren
FossiFoundation
FossiFoundation
FossiFoundation
FossiFoundation
FossiFoundation
FossiFoundation
FossiFoundation
FossiFoundation
FossiFoundation
librecores
librecores
librecores
librecores
librecores
librecores
librecores
librecores
librecores