TSFPGA + VUnit

This is the third and final post reviewing the presentations featured in the VUnit track at FPGAworld. In this review, I will cover the session that was hosted by Ludvig Vidlid, co-founder of Truestream, a consultancy firm providing FPGA design services and the maintainer of the open source TSFPGA project. TSFPGA is an FPGA project manager consisting of three main components: a source code manager organizing all project files, VUnit as the test framework, and a Python-based Vivado build system.

Truestream also offers a range of FPGA IPs, placing particular emphasis on achieving a more compact footprint compared to their competitors. With size being a unique selling-point, ensuring both functionality and resource utilization of the design becomes important. VUnit is used for verifying functionality but how can size be effectively verified? Truestream recognized that the recipe used by the Python test runner within VUnit can be repurposed to address this challenge:

1. Schedule one or multiple concurrent simulation threads.
2. Collect the results of these simulations.
3. Present the simulation results in a report

Verifying the size of a design is simply a matter of replacing the word "simulation" with "build" and keep the rest of the recipe. The VUnit Python test runner, being a software tool, builds on the principles of object-oriented programming (OOP) and the three steps above are associated with objects/classes such as TestRunner, TestScheduler, TestResult, and TestReport. From these classes, Truestream created a number of derived classes that inherit the core functionality of the VUnit baseclasses while selectively overriding methods that deviate between the realms of building and simulating. For example, BuildResult inherits functionality from TestResult and the method displaying the pass/fail status of a test is extended to also include the resource utilization of the build. Consequently, the resulting output has the look and feel of VUnit while delivering supplementary information:

Truestream's work on TSFPGA is yet another example of VUnit's philosophy of being open to integration with other tools, a principle I also discussed in my prior review of Sebastian's presentation. The fact that we both use Python obviously helped the integration and today this hardly raises an eyebrow. However, when VUnit first came into existence, Python was a rarity in the realm of EDA while TCL, with its roots in EDA, was found everywhere. The reason for choosing Python over TCL was partly due to programming capabilities. For most VUnit users, the primary focus lies in crafting test code in VHDL or SystemVerilog, while the Python layer is perceived as a small script managing the full automation. However, providing that level of experience means hiding the complexities behind the scenes and a language capable of much more than scripting is needed to manage that. Both TCL and Python can provide such features but we felt that TCL was lagging behind. An example of that is support for OOP which is native to Python. TCL has a number of different extension packages for OOP but it wasn't included into the language until 2012.

Being open to integration also means that we want a language with a large ecosystem where we can find almost anything we ask for. This extends well beyond the bounds of EDA. For example, we want to integrate with IDEs, tools for requirement management, continuous integration tools etc. We also want reference models for the functionality we implement, whether that is a simple CRC generator or a complex image processing algorithm. Using Python brings many such opportunities.

When we started, Perl was also quite popular and a potential contender. However, Python was on a more positive trend and that has continued ever since.

Finally, I would recommend exploring Truestream's HDL modules project, a collection of open-source VHDL building blocks that serve as good illustrations of something Ludvig emphasized during the presentation:

"What to test? Functionality and anything else that is important."

What's more important is the full transparency, as all tests are openly available and continuously executed by the GitLab CI. I wish more open-source and closed-source IPs would adopt this practice. "Proven is use" is a weak argument for future success, given the varying contexts in which an IP may be reused. When tests are available, we can identify the true reuse potential right from the beginning and avoid costly setbacks much later in the project. In fact, the proven in use fallacy led to one of the most expensive software bugs in history: the "rapid unscheduled disassembly" of the first Ariane 5 rocket.

That concludes the reviews of this year's presentations and I encourage everyone to check out the recording. I'm already looking forward to next year's event and if you have ideas for presentations and want to be part of the lineup, feel free to reach out to me. Whether it's an individual presentation or a collaborative effort, I'm here to support you at every stage of the creation process, providing assistance as needed.