Posted on Leave a comment

Hardware generation and simulation in Python

There are various approaches to Python HDLs, some more suited to Python developers than to HDL developers. They all have one thing in common: The very refined test bench capabilities of the Python ecosystem which allow you to just connect almost everything to all. From all these Python dialects, myHDL turns out to be the most readable and sustainable language for hardware development. Let me outline a few more properties:

  • Has a built-in simulator (limited to defined values)
  • Converts a design into flattened Verilog or VHDL
  • Uses a sophisticated ‘wire’ concept for integer arithmetics

In a previous post, I mentioned experiments with yosys and its Python API. Not much has changed on that front, as the myHDL ‘kernel’ based approach turned out to be unmaintainable for various reasons. Plus, the myHDL kernel has a basic limitation due to its AST-Translation into target HDLs that impedes code reusability and easy extendability with custom signal types.

For experiments with higher level synthesis, such as automated pipeline unrolling or matrix multiplications, a different approach was taken. This ‘kernel’, if you will, can handle the legacy myHDL data types plus derived extensions. This works as follows:

  • Front end language (myHDL) is slightly AST-translated into a different internal representation language (‘myIRL’)
  • The myIRL representation is executed within a target context to generate logic as:
    • VHDL (synthesizeable)
    • RTL (via pyosys target)
    • mangled Verilog (via yosys)

Now the big omnipresent question is: Does that logic perform right? How to verify?

  • The VHDL output (hierarchical modules) is imported into the GHDL simulator and can be driven by a test bench. The test bench is also generated as a VHDL module. Co-Simulation support is currently not provided.
  • The Verilog output can be simulated with iverilog, however, Co-Simulation is not enabled for the time being for this target
  • The RTL representation is translated to C++ via the CXXRTL back end and is co-simulated against the Python test bench. Note that support for signal events are rudimentary. CXXRTL is targeting at speedy execution with defined values (no ‘X’ and ‘U’)

Instead using classic documentation frameworks, the strategy was chosen again to use Jupyter Notebooks running in a Jupyter Lab environment. Again, the Binder technology enables us to run this in the cloud without requirement to install a specific Linux environment. The advantages:

  • Auto-Testing functionality for notebooks in a reference Docker environment
  • Reduced overhead for creating minimum working examples or error cases

This Binder is launched via the button below.

Launch button for cyhdl demos

Overview of functionality:

  • Generation of hardware as RTL or VHDL
  • Simulation (GHDL, rudimentary CXXRTL)
  • RTL display, output of waveforms
  • Application examples:
    • Generators (CRC, Gray-Counter, …)
    • Pipeline and vector operations
    • Extension types (SoC register map generation, etc.)

Yosys synthesis and target architectures

The OpenSource yosys tool finally allows to drop a reference tool chain flow into the cloud without licensing issues. This is in particular interesting for new, sustainable FPGA architectures. A few architectures have been under scrutiny for ‘dry dock’ synthesis without actually having hardware.

In particular, a reference SoC environment (MaSoCist) was dropped into the make flow for various target architectures to see:

  • How much logic is used
  • If synthesis translates into the correct primitives
  • If the entire mapped output simulates correctly with different simulators

The latter is a huge task that could only be somewhat automated using Python. Therefore, the entire MaSoCist SoC builder will slowly migrate towards a Python based architecture.

It is expected to document some more in particular about several architectures.

As an example, a synthesis and mapping step for a multiplier:


As always with educational software, some scenarios don’t play. The restrictions in place for this release:

  • Variable usage in HDL not supported
  • Custom generators, such as Partial assignments (p(1 downto 0) <= s) or vector operations not supported in RTLIL
  • Limited support for @block interfaces
  • Thus: No HLS alike library support through direct synthesis (yet)

Exploring CXXRTL

CXXRTL by @whitequark is a relatively fresh simulator backend for yosys, creating heavily template-decorated C++ code compiling into a binary executable simulation model. It was found to perform quite well as a cythonized (compiled Python) back end driven from a thin simulator API integrated into the MyIRL library.

Since it requires its own driver from the top, a thin simulator API built on top of the myIRL library takes care of the event scheduling, unlike GHDL or icarus verilog which handle delays and delta cycling for complex combinatorial units. It is therefore still regarded as a ‘know thy innards’ tool. A few more benefits:

  • Allows to distribute functional simulation models as executables, without requirements to publish the source
  • Permits model-in-the-loop scenarios to integrate external simulators as black boxes
  • Eventually aids in mixed language (VHDL, Verilog, RTL) and many-level model simulations

There are also drawbacks: Like the MyHDL simulator, CXXRTL is not aware of ‘U’ (uninitialized) and ‘X’ (undefined) values, it knows 0 and 1 signals only. It is therefore not suitable for a full trace of your ASIC’s reset circuitry without workarounds. Plus, CXXRTL only processes synthesizeable code and would not provide the necessary delay handling for post place and route simulation.

Co-Simulation: How does this play with MyHDL syntax?

This is where it gets complicated. MyHDL allows a a subset of Python code to be translated to Verilog of VHDL such that you can write simple test benches for verification that run entirely in the target language.

Then there’s the co-simulation option, where native Python code (featured by the myHDL ‘simulator kernel’, if you will) runs alongside a compiled simulation model of your hardware. The simplest setup is basically a circuit or entire virtual board with only a virtual reset and clock stimulus. Any other simulation model, like as UART, a SPI flash, etc. can be connected to such a simulation with more or less effort. The big issue: Who is producing the event, who is consuming it? This leads us back to the infamous master and slave topic (I am aware it’s got a connotation).

The de-facto standards aiding us so far in the simulator interfacing ecosystem:

  • VHDL: VHPI, VHDLDIRECT, specific GHDL implementations
  • Verilog/mixed: VPI, FLI
  • QEMU as CPU emulation coupled to hardware models

The easiest to handle may be the VPI transaction layer, that is already present for myHDL. In this implementation, it is using a pipe to send signal events to the simulation and reading back results through another reverse path. Here, the myHDL plays a clear master role. For GHDL, a asynchronous concept was explored via my ghdlex library, allowing distributed co-simulation across networks where master and slave relationships are becoming fuzzy.

Finally, the CXXRTL method provides most flexibility, as we can add blackbox hardware that does just something. We have the full control here over a simple C++-layer without any overhead induced through pipes. The binding for Python can easily be created using Cython code. However it requires to clearly separate testbench code from hardware implementation.

This implies:

  • Test bench must be written in myHDL syntax style and needs to use specific simulation signal classes
  • Extended bulk signal/container classes re-usage is restricted
  • Hardware description can be in any syntax or intermediate representation, as well as blackbox Verilog or VHDL modules

Links and further documentation

As usual in the quickly moving opensource world, documentation is sparse and solutions on top of it are prone to become orphanware, once the one man bands retire or lose interest. However, I tend to rate the risk very low in this case. Useful links so far (hopefully, there’ll be found more soon):


  • Recommended for academical or private/experimental use only
  • The pyosys API (Python wrapper for libyosys) may at this moment crash without warning or yield misleading feedback. There’s not much being done about this now as updates from the yosys development are expected.
  • Therefore, jupyter notebooks may crash and you may lose your input/data
  • No liability taken!
Posted on 2 Comments

RISC-V in the loop

Continuous integration (‘CI’) for hardware is a logical step to take: Why not do for hardware, what works fine for software?

To keep things short: I’ve decided to stick my proprietary RISC-V approach ‘pyrv32’ into the opensourced MaSoCist testing loop to always have an online reference that can run anywhere without massive software installation dances.

Because there’s still quite a part of the toolchain missing from the OpenSource repo (work in progress), only a stripped down VHDL edition of the pyrv32 is available for testing and playing around.

This is what it currently does, when running ‘make all test’ in the provided Docker environment:

  • Build some tools necessary to build the virtual hardware
  • Compile source code, create a ROM file from it as VHDL
  • Build a virtual System on Chip based on the pyrv32 core
  • Downloads the ‘official’ riscv-tests suite onto the virtual target and runs the tests
  • Optionally, you can also talk to the system via a virtual (UART) console


This is the quickest ‘online’ way without installing software. You might need to register yourself a docker account beforehand.

  1. Log in at the docker playground:
  2. Add a new instance of a virtual machine via the left panel
  3. Run the docker container:
    docker run -it hackfin/masocist
  4. Run the test suite:
    wget && sh && make all test
  5. Likewise, you can run the virtual console demo:
    make clean run-pyrv32
  6. Wait for Boot message and # prompt to appear, then type h for help.
  7. Dump virtual SPI flash:
    s 0 1
  8. Exit minicom terminal by Ctrl-A, then q.

What’s in the box?

  • ghdl, ghdlex: Turns a set of VHDL sources into a simulation executable that exposes signals to the network (The engine for the virtual chip).
  • masocist: A build system for a System on Chip:
    • GNU Make, Linux kconfig
    • Plenty of XML hardware definitions based on netpp.
    • IP core library and plenty of ugly preprocessor hacks
    • Cross compiler packages for ZPU, riscv32 and msp430 architectures
  • gensoc: SoC generator alias IP-XACT’s mean little brother (from another mother…)
  • In-House CPU cores with In Circuit Emulation features (Debug TAPs over JTAG, etc.):
    • ZPUng: pipelined ZPU architecture with optimum code density
    • pyrv32: a rv32ui compatible RISC-V core
  • Third party opensource cores, not fully verified (but running a simple I/O test):
    • neo430: a msp430 compatible architecture in VHDL
    • potato: a RISC-V compatible CPU design

Posted on Leave a comment

Hardwaredesign und CI/Cloud computing — Open source

Automatisches Testen und Verifizieren von Software ist spätestens mit dem Schlagwort “CI” – Continuous Integration zum Standard für grössere Softwareprojekte geworden. Bei aller möglichen Überflutung mit derartigen Reizwörtern darf man hier kurz innehalten und nachfragen: Was ist das genau? Bringt mir das was?

Ein paar Aspekte für den klassischen innovativen Entwickler zusammengefasst:

  1. Man wird älter und kann/will sich nicht mehr alles merken
  2. Man hat beim allgemeinen Preiskampf weniger Zeit für ausführliche Dokumentation
  3. Die Bibliothek oder das Sammelsurium an möglichst (!) wiederverwartbarem Sourcecode ist angewachsen und der kontiuierliche Unterhalt wird immer aufwendiger
  4. Implementiere ich etwas Neues, mache ich vielleicht etwas Altes kaputt

Diverse Technologien zur Virtualisierung von Komponenten (Docker, Virtuelle Maschinen, Linux Container, …) lösen das Problem insofern, dass sich Bausteine aus Projekt A nicht Baustellen aus Projekt (oder gar Problem) B in die Quere kommen (und umgekehrt). Trotzdem möchte man möglichst viele Gemeinsamkeiten abdecken. Also ergibt sich eine klassische NxM-Komplexität: N Bausteine müssen gegen M Konfigurationen/Varianten getestet werden.

Nichts leichter als das: Systeme aus der Opensource-Szene wie Tinderbox oder der Nachfolger buildbot, oder auch teilkommerzielle Dienste wie Travis CI sind beim Testen von Software soweit behilflich, dass für alle Beteiligten, sei es OpenSource oder proprietär/Closed Source, ein Produkt aus der automatisierten Pipeline ploppt, welches – zumindest im Idealfall – gegen eine Menge Fehlerszenarien und Konfigurationen automatisch getestet worden ist.


Gegen was muss denn jetzt typischerweise getestet werden? Nehmen wir an, unsere Software bietet eine Funktionalität einer Bibliothek, d.h. ein Nutzer soll Funktionen aufrufen können. Generell bietet sich der Ansatz einer Bibliothek aus Erfahrung immer an, mit dem Fokus auf:

  • Wiederverwertbarkeit von Code und Algorithmen
  • Optimale Interoperabilität
  • Optimale Abdeckung vieler Anwendungsfälle und Szenarien

Der Aufruf einer Funktion bedingt immer: Eingabe-Daten haben eine mehr oder minder sinnvolle Ausgabe zur Folge, oder gar einen Absturz oder eine Endlos-Schleife. Standard-Strategie ist bei uns, diese Funktionen mit einem virtuellen ‘Adapter’ so zum umwickeln (‘wrappen’), dass sie aus der mächtigen Scriptsprache Python aufgerufen und gegen Szenarien oder Messdaten getestet werden können.

So weit ist das alles mit erträglichem Aufwand für Software implementierbar.

Testen von Hardware

Das Testen von Hardware ist eindeutig kniffliger. Hier lässt sich a priori nicht einfach ein Script schreiben, typischerweise geht es um sogenannte parallel auftretende ‘Test-Vektoren’. Vereinfacht: Angenommen, wir haben einen (virtuellen) Chip, der 16 Eingänge und 16 Ausgänge besitzt. Rhetorische Frage: Kann der Chip mit allen möglichen Eingangssignalen sinnvolle Ausgangssignale erzeugen, so dass alle Zustände definiert sind?

Da die Eingänge unterschiedliche Funktion haben, wie z.B. Takteingänge, reicht eine statische Analyse niemals aus, und die Testszenarien müssen im Grunde genommen immer auf die Funktion der Ein/Ausgänge zurechtgeschnitten werden. Geht auch alles, allerdings mit erheblich höherem Aufwand als für die Software. Wenn alle möglichen Zustände und Sequenzen irgendwie abgefangen werden müssen, um entweder in einem OK oder ERROR-Status zu enden, wird das Problem je nach Komplexität nicht mehr handhabbar, bzw. reicht ein einziger PC nicht dazu aus.

Dazu kommt, dass die Simulationstools, die solche Fehlerszenarien durchspielen können, noch nicht allzulange auf mehreren Rechnern ohne Kostenexplosion verteilbar sind. D.h. für die “Cloud” ist das für den einfachen Anwender oder die Kleinfirma keine legale Option. Es muss also auf OpenSource zurückgegriffen werden, was aber weitere Risiken mit sich bringt: Opensource ist, spätestens nach dem Download, nicht mehr kostenfrei und es gibt – ohne einen vorliegenden Supportvertrag – keine Garantie für gewünschte Funktionalität.

Der Paradigmenwechsel

Wie schon vor vielen Jahren die Gnu Compiler Collection (GCC) teure, proprietäre Compilerlösungen abgelöst hat, und bei allen Unkenrufen zum Trotz die Nummer Eins beim Übersetzen von Sourcecode für andere Architekturen geworden ist, zeichnet sich auch in der Hardware-Welt ein Paradigmenwechsel ab. Wird sind eigentlich an dem Punkt, wo jeder mit entsprechend Know-How in der Lage ist, sich sein eigenes Computerdesign zu entwerfen und es auch zu testen, ohne dass es an Geld für entsprechende Werkzeuge mangelt. Die Übergänge zwischen Software- und Hardware (in der akademischen Welt oft noch klar getrennt) werden fliessender, gefragt sind robuste Lösungen, Gesetzgeber pochen mehr auf Garantie und Haftung — auch bei kleinen innovativ-agilen Entwicklern.

Wie löst sich diese gordische Knoten?

Dazu liesse sich ein Buch schreiben. Aber warum nicht gleiches mit Gleichem vergelten: In der Opensource-Welt hört man schon mal den Spruch: Read the source, Luke.

Also möchte ich schliesslich auf das OpenSource-Konzept ‘MaSoCist’ verweisen, was wiederum auf einem Sammelsurium an existierenden OpenSource-Tools aufbaut, seien genannt:

  • Der gcc GNU compiler
  • GHDL – ein OpenSource VHDL Simulator
  • Linux, GNU Make
  • … und eine Handvoll Software-Tools aus dem eigenen Hause

Als Sourcecode-Hoster wurde github ausgewählt, so findet sich entsprechend das Code-Repository unter

Kurzumriss MaSoCist

Der MaSoCist ist im Grunde genommen eine komplexe Anleitung und Regelsammung um Hardware zu bauen. Dazu gehört a priori die Simulation derselbigen. Bei dieser Art der Entwicklung muss man sich dabei auf sehr viele Dinge verlassen, insbesondere darauf, dass:

  • Die OpenSource-Werkzeuge (die teilweise gebaut werden) korrekt funktionieren
  • Die Abhängigkeiten von externen Werkzeugen und Bibliotheken stimmen

Das heisst, wir müssen unsere Tools auch laufend gegentesten, denn irgend jemand könnte im Laufe der Entwicklung etwas beschädigen.

So ist der MaSoCist nicht nur ein Baukasten für Hardware, er testet sich zudem selbst, dank einiger Dienste, die die OpenSource-Welt für uns bereitstellt.

Was baue ich jetzt genau mit dem MaSoCist?

Grob lässt sich das wie folgt auflisten:

  • Es wird ein virtueller (oder auch für FPGA synthetisierbarer) Mikroprozessor gebaut
  • Es wird die zugehörige Peripherie (UART, I2C, …) gebaut
  • Es wird die Test-Firmware für eine gewisse Plattform übersetzt und als ROM-Datei in die Simulation integriert
  • Das Ganze lässt sich wie ein Linux-Kernel konfigurieren, d.h. CPU core, Anzahl und Art der Interfaces lassen sich entsprechend der Möglichkeiten, die die mitgelieferten Style-Sheets bieten, auswählen.
  • Schliesslich: Die virtuelle Architektur wird mit externen Stimuli per sog. Co-Simulation auf korrekte Funktion getestet

Optional erstellt der MaSoCist auch die komplette Systemdokumentation aller Register, usw. Natürlich muss manuell die passende Dokumentation zum ‘Chip’ erstellt werden.


Mehrere Ansätze sind hier gängig:

  • Simulation eines Hardware-Designs ohne CPU gegen externe Software, Daten, oder Stimuli (UART-Eingaben, ..)
  • Simulation des Gesamtsystems mit der innewohnenden Firmware und CPU, allenfalls ohne externe Stimuli

Der MaSoCist nutzt hierbei die Möglichkeiten, die GHDL bietet, um entweder eine Simulation mit statischen/fixen Testmustern zu stimulieren (wie aus einer VHDL-Testbench heraus) oder die dynamischen Ansätze der Co-Simulation über unsere ghdlex Bibliothek. Hierbei können einfache Kommandozeilenaufrufe oder ein Python-Script die Simulation ansteuern und auf Herz und Nieren (in der Cloud) testen.

Wie beginne ich?

Am besten mit einem Docker Container. Das hat den Vorteil, dass keine Software  – ausser allenfalls dem Docker-Dienst oder einer virtuellen Linux-Maschine – installiert werden muss.

Das ganze kann auch komplett im Browser ablaufen.

Die Details dazu finden Sie hier. Viel Spass!