Conceptual Model

EDA² is a conceptual model for characterising the abstraction layers in Electronic Design Automation projects based on Hardware Description Languages (HDLs). Its goal is the interoperability of diverse tools and languages with documented APIs.

Important

This conceptual model is not meant to be an isolated full-stack, but each of the layers is to be useful and (re)usable. In fact, it is still being enhanced and reworked, so the naming and specific scope of the layers should be taken with a grain of salt.

Layers of the EDA² conceptual model.

-1 | Tools

Development of (open source) EDA tools. Organisation gh:hdl contains an awesome list of tools: hdl.github.io/awesome. Most EDA tools are developed and managed independently of EDA². However, since the main purpose of EDA² is easing the usage of tools, this layer represents them.

0 | Installation

Packaging and distribution of EDA tools. Organisation gh:hdl contains an index of packaging solutions (gh:hdl/packages), along with gh:hdl/smoke-tests for packagers to test the artifacts. This layer includes the abstraction(s) for dealing with multiple versions of the tools installed in different locations.

1 | CLI

Abstraction of Command-Line Interface programs (independent of EDA tools). May include the abstraction for running isolated tools on containers (e.g. from gh:hdl/containers).

2 | EDA

Interaction with EDA tools (both open source and vendors), including multiple version support, output filtering, etc. See The pyEDAA.Reports Documentation, The pyEDAA.OutputFilter Documentation and OSVB: Logging.

3 | Workflows

Middle layer to translate projects into execution steps (EDA and/or CLI). See Workflows and integration, OSVB: Tool and OSVB: Runner.

4 | Language Model

Syntax and Document Object Model (DOM) of the imperative and parallel language(s) such as VHDL and System Verilog. See:

• The pyVHDLModel Documentation

• The pySVModel Documentation

• OSVB: pyVHDLModelUtils.

5 | Data Model

IP-XACT, UCIS, XUnit, Cobertura,… imported from or exported into structured files such as JSON, XML, TOML/INI, YAML,… See Languages and Data and OSVB: Logging.

6 | Project Model

Tool independent information (files/filesets, primary design units, testbenches, gh:hdl/constraints, etc.) and tool specific parameters. See Projects and Configuration and The pyEDAA.ProjectModel Documentation.

7 | Configuration

INI/JSON/YAML format for providing the sources and constraints data used in Workflow and/or Project through files, instead of using the APIs. See OSVB: Core.

8 | Web

Web API wrapping the previous layers.

9 | GUI

Visual frontend to the web API or to the previous layers. See OSVB: Open Source VHDL Design Explorer (OSVDE).