Cooperation between pyucis and pyEDAA.UCIS

[Paebbels]

Hello Matthew,

I would like to ask, if you would be interested in a cooperation between your pyucis project and pyEDAA.UCIS, which is maintained by me and @umarcor. pyEDAA.UCIS is part of a stack of Python-programmed code layers for EDA tools. It's all part of the Electronics Design Automation Abstraction = EDA² "brand".

In the last months, we released several layer of EDA² like a universal ProjectModel, a CLITool layer, a ToolSetup layer etc. As a latest release, I published a script originally contributed by Aldec to convert code coverage information from ACDB files (via intermediate UCIS XML files) to the Cobertura XML format. That script is now part of pyEDAA.UCIS. It allows e.g. cloud services or local on-premise GitLab instances to display code coverage information from VHDL and (System)Verilog in Merge Requests.

As your project contains a lot of details for a complete(?) UCIS data model, it would be interesting for us if we could join forces and maybe reuse or merge code bases.

What do you think about such a cooperation?
Should we schedule an online meeting e.g. via Zoom to discuss our ideas?

Kind regards
Patrick

---

/cc @umarcor

[mballance]

Hello Patrick,
Thanks for reaching out. I'd definitely be open to exploring how the two projects can better cooperate. Looking at what is in pyEDAA.UCIS at the moment, my impression is that the initial focus is on converting and formatting data (eg the ACDB to XML converter and the Coburtura output filter). Perhaps we can look at ways that pyUCIS can act as 'yet another data pipe' into the pyEDAA environment.
At the moment, pyUCIS is complete with respect to functional coverage (coverpoints, bins, crosses), but is incomplete with respect to representing code coverage. Based on the Coburtura integration, it seems enhancement in the code coverage space would be of interest to EDAA.
I'd certainly be open to setting up a Zoom call to better-understand the EDAA roadmap and discuss options for collaboration.

Best Regards,
Matthew

[Paebbels]

You're right, currently pyEDAA.UCIS is more or less a conversion tool. Moreover, the UCIS variant understood by our tool is limited to a pre-standard XML-based dialect as used by Aldec in Riviera-PRO and Active-HDL. I assume your pyucis project is either fully UCIS compliant (for the parts implemented) or focused on Mentor Graphics / Siemens EDA "dialect", right?

Anyhow, the goal of pyEDAA.UCIS is a general data model for UCIS and the conversion features becomes a usage example or by-product. We started with v0.1.0 as a conversion tool as this was the initial donation from Aldec. Which is also a good sign to have a first EDA tool vendor contributing to the EDA² idea :).

What timeslots would be good for a meeting?
Portland (PST) is -09:00 hr from here (CET). I would prefer a late evening or night timeslot, so 20:00 - 24:00 (CET) => 11am - 3pm (PST). Do you prefer weekdays or is the weekend also possible?

---

To give an idea how we tackle problems I would like to highlight pyVHDLModel and pyEDAA.ProjectModel.

pyVHDLModel

Over 5 years ago, I started to work on a Python-based VHDL parser called pyVHDLParser. Is was planned as a demonstrator for the language, (maybe) reference implementation and to play with new features for the IEEE P1076 working group. In addition, it was planned to understand VHDL source files so comments and code documentation could be extracted. You can imaging, the work on such a tool is quite complicate :). Almost 2 years ago, GHDL added Python bindings to the Ada code base (libghdl), so internals like the IIR data structure are since then accessible. In discussions with Unai, we figured out that pyVHDLParser has a generalized - but internal - VHDL language model, which would be great for GHDL too.

So I extracted the language model from pyVHDLParser into pyVHDLModel. Technically, it's a code document object model (CodeDOM) or syntax model. Since restructuring, both tools are now using the same abstract language model. Moreover 3rd party projects are using the language model and can choose what "frontend" to use (purely Python based or with binary library/better performance). We have made several demonstrators like simple documentation extraction with Sphinx or a browsable hierarchy view. Other possible users are tools like Symbolator to generate icons for entities.

The concrete implementation of the pyVHDLModel is called pyGHDL.DOM using pyGHDL.libghdl as a C/Ada-Python binding interface.

pyEDAA.ProjectModel

Before I started working on pyEDAA.* and the overall EDA² idea, I developed the "IP Core Management Infrastructure" - pyIPCMI, which was formerly part of The PoC-Library. This is/was a huge monolithic project with lots of EDA tool knowledge and internal abstraction layers, but not accessible by other frameworks. It's also hard to maintain and has almost no unit tests :).

Again in a discussion with Unai, we figured out, pyIPCMI should be sliced into multiple layers so other frameworks can reuse parts of it. This can be a single layer, a group of layers or the whole stack. When layers/parts of pyEDAA.* are used, the original framework can keep all it's specialties and CLIs. So there is no behavior change to the end user, while the framework is sharing and reusing the code base under the hood. In a second step, a framework gets access to improvements done to pyEDAA. As an example, many Python-based EDA tools support Aldec and Siemens EDA tools, but just a few support Cadence, Lattice or Synopsys. When a tool support gets added to pyEDAA, all frameworks can benefit.

One example out of pyIPCMI is the pyEDAA.ProjectModel. It offers Projects, Designs, Filesets, Files, Testbenches, Testharnesses, etc. The ProjectModel provides an abstract set of Python classes, but also 2 variant implementations:

1. Reading Xilinx Vivado *.xpr files
2. Reading OSVVM's *.pro files

Both project file formats are read and translated into the same data model. Again 3rd party Python-based tools can now e.g. create makefiles, launch vlib/vcom/vlog/vsim or compute compile orders or package a project as an IP core.

We're in discussion with VUnit and CoCoTB, if and how to use ProjectModel under the hood.

Quality

To avoid mistakes done in pyIPCMI, each layer comes with:

• documented code (doc-strings + manually written pages + installation instructions + examples or tutorials)
• automated documentation generation (BuildTheDocs + Sphinx)
• unit tests (pytest)
• code coverage analysis (Coverage.py + pytest-cov)
• static type checking (mypy)
• automated release generation
• excessive CI pipelines