The frontend is developed using Godot and it is exported for GNU/Linux, Windows and Mac OS. The artifacts are standalone executables, so just downloading the nightly tarball/zipfile for your platform and extracting it should work. Otherwise, let us know!

The backend is mostly written in pure Python, so it can be used through PYTHONPATH, after getting a tarball or through git clone.

Install the dependencies through pip:

Then, execute the main script for starting the server:

In the frontend, go to Menu / Preferences and check that the Backend address and port are correct. There is a button for testing that frontend and backend can talk to each other.

Apart from "traditional" text-based programming languages (such as docs.godotengine.org: GDScript, C#, or any foreign language through docs.godotengine.org: GDNative), Godot has built-in support for visual programming through docs.godotengine.org: VisualScript, similar to the docs.blender.org: Shader Editor in Blender. The class which VisualScript is built on is available as a Control node named docs.godotengine.org: GraphEdit, so that developers can build custom interfaces with them.

The Graph editing mode in Hardware Studio is based on GraphEdit.

The main node type in Godot for managing 2D scenes is TileMap. It provides a two-dimensional grid with optional snapping. Although mostly meant to be used when designing game levels (see docs.godotengine.org: Using TileMaps), the content of the tiles can be changed programmatically.

The Tiles editing mode in Hardware Studio is based on TileMap.

The Godot 3D engine uses the Spatial node for everything 3D. As explained in 2D in 3D (see also 3D), using a 3D environment with a constrained camera is a common tradeoff for getting richer lighting/shadow effects. Moreover, it’s a better fit than tilemaps for exploring editing designs through a 2.5D|3D visualization.

The Spatial editing mode in Hardware Studio is based on Spatial. Currently, three ortogonal and fixed cameras are used.

There are two main menus in Hardware Studio:

The workflow needs to be (V)HDL centric. That is, hardware designers working with VHDL 2008 sources and using VUnit for managing regression tests should NOT need to modify their sources in order to use Hardware Studio.

Parsing HDLs is a challenging task. Both VHDL and System Verilog are known to be difficult to parse because of the number of use cases they cover, as well as due to the notable differences compared to software languages. In fact, as far as we are aware, there is no tool (open source or not open) which can support either VHDL or System Verilog completely. All of them specify which versions and/or features are (un)supported. However, a robust and as-comple-as-possible parser is the foundation for any kind of tooling to be built around a language. As a result, hardware design environments have been severely lagging behind in comparison to the IDEs, GUIs and debuggers available for almost any software language.

Dozens of developers tried implementing their own VHDL parsers. Some notable examples are VUnit, Symbolator, TerosHDL, vhdl-style-guide or VHDLTool. All of those have complex parsers, based on regular expressions and ad-hoc tweaks, or on general purpose parser generators. They suffice for their use cases, but the implementation of new and more complex features is hindered by the maintenance burden of the parsers.

There are two projects with a wider scope, which are expected to be used by any tool around the language, rather than by some specific tool. See detailed discussions in jeremiah-c-leary/vhdl-style-guide#312 and jeremiah-c-leary/vhdl-style-guide#328.

Overall, almost a dozen projects are known in the community, which are trying to reimplement features already available in GHDL, but not easy to reuse. Although GHDL’s main purpose was never being a parser per se, advanced VHDL parsing was required in order to allow simulation and synthesis features. As a result, GHDL includes the most complete VHDL parser and semantic analysis capabilities available in open source tooling, and maybe compared to vendor tooling too. Throughout the last decade, there were numerous requests for having GHDL’s parsing/analysis capabilities exposed through an API for developers to build tools on top of it. However, GHDL is written in Ada. That might be appealing to VHDL developers, due to the similarities; but it seems to be an stopper for developers with a background in C/C++, Rust, Python, etc.

pyVHDLModel is a Document Object Model (DOM) for the VHDL language written in Python. That is, a set of classes that represent the objects found in VHDL sources, and utils for manipulating and interacting with those classes. The generation of an specific tree for an specific codebase is done by a backend. Currently supported backends are pyGHDL.dom/pyGHDL.libghdl and pyVHDLParser. Therefore, pyGHDL.dom is used in the backend of Hardware Studio.

Yet, there are two distinct required features with different complexity:

Regarding the interface and how users interact with the design, the purpose of this project is to explore visualizatons that go beyond collapsible/expandable 2D diagrams. Our belief is that the multiple abstraction layers in hardware designs can be better understood and debugged by using the third dimension.

The main blocker to achieve a true 3D visualization allowing users to locate blocks at arbitrary locations is the routing. The complexity is increased if the layout needs to be automatic. That is, in fact, a very challenging task from an algorithmic point of view (SymbiFlow/ideas#/issues/#41). Nevertheless, so much freedom in the visualization might be counterproductive. Hence, a semi-constrained 2.5D approach might be preferred.

Depending on implementation details, off-the-shelf Godot classes might not work. That is, the connection and port type management logic that is provided in GraphEdit and GraphNode might need to be reimplemented. On the other hand, 2.5D Demo Project with GDScript exists. Nevertheless, this is far below other features in the priority list.

Moreover, 2.5D or 3D visualizations are a good fit for virtual reality (VR) devices. The usability of VR for real-time navigation of (V)HDL designs is to be tested. We are not convinced about it, because text editing is expected to be an important task of the development process. Anyway, Godot supports VR and AR (see Godot 3’s VR and AR support), so it would be relatively straightforward to try it once other features are ready.

Since most hardware designs are indeed logic puzzles, there are lots of synergies between describing systems in (V)HDL and several game types. This is specially so because VHDL is a parallel/concurrent language; thus, co-execution of multiple cooperative modules/components is natural. The most obvious games are the ones where electrical circuits are used, or which are based on playing with logic gates and Boole’s algebra:

Similarly, synthesizer rack simulators can be repurposed:

However, many strategy and survival games focused on building, automation and resource management can also be easily related. The following list is a very small subset of circuits designed in games with basic hardware logic features.

On a different category, (advanced) simulation environments mimicking real world industrial machinery/vehicles are gaining popularity. Those are sometimes developed together with custom input devices, frequently reusing the actual controls from the target plant.

Since FPGAs are a good fit for advanced industrial control applications, it is appealing to test control designs against the CAD models of the plant (if available). In this regard, several CAD and 3D modelling suites (such as FreeCAD or Blender) are gaining scripting/animation support too, which allows simulation of mechanisms and collision detection:

Consequently, due to Godot providing easy to use engines for both 2D and 3D, adding HDL simulation features to Hardware Studio would allow building interactive learning environments. See Virtual development board for HDL design and VHDL DPI/FFI based on GHDL’s implementation of VHPIDIRECT.

As explained, we aim to reuse existing tools when possible. For editing VHDL, projects such as VSCode, Emacs, Vim…​ all are good solutions. GHDL provides a language server to be used with any of them. Moreover, TerosTechnology provides a VSCode extension with multiple advanced features for working with VHDL and VUnit: vscode-terosHDL.

For waveform visualization, either GtkWave (github.com/gtkwave/gtkwave), Wavedrom (github.com/wavedrom/wavedrom) or d3-wave might be used. Nonetheless, replaying waveforms in Hardware Studio’s frontend dataflow diagram (e.g., by colouring connections) would be interesting for allowing animated simulations. Related reference: Reading waveforms from HDL simulators with PulseView. See also Data type exploration and visualization in arithmetic algorithms/circuits and Virtual development board for HDL design.

A Project in Hardware Studio is a top-level instance which has implementation details, such as external pin mapping and board constants. Hence, in order to save projects to disk, the text or binary format of entities and architectures needs to be defined. For (V)HDL architecture types, that is standardized already. However, ArchGraph, the description of architectures through the graphical editor, is per se a visual programming language (VPL). Hence, the definition of the format to be used for saving diagrams to disk is, implicitly, a textual or binary programming (description) language. That is, users can potentially choose to write the diagrams manually or programmatically, instead of using the visual editor. In fact, drawing structural circuits with TikZ is conceptually similar to describing them in VHDL, even though the syntax is very different.

docs.godotengine.org: ConfigFile, while intended for configuration files, can be used for saving games, as it can serialize any Godot datatype (not custom objects). Unlike JSON, (de)serializing types such as Vector2 or Vector3 manually is not required. However, due to portability and potential compatibility with other tools, it might be desirable to use JSON or YAML, either as complements or replacements of ConfigFile. See docs.godotengine.org: I/O > Saving games and docs.godotengine.org: Step by step > Creating your own resources.

TBW

TBC

TileMaps in Godot can be square, isometric or custom shaped. The isometric view is used by many projects for faking 3D, while using 2D nodes. Actually, it’s possible to render 3D assets as 2D sprites. However, the isometric view falls short when handling the depth and/or the height. Moreover in TileMaps assets are measured in pixels. That is desirable for games based on pixel-art, but cumbersome for a diagram editing tool. As a result, Tiles in Hardware Studio are square, while Spatial is used for isometric or other visualizations.

TBC

TBC

Data is a unique instance of a helper class, which is loaded automatically (see docs.godotengine.org: Singletons (AutoLoad)). It contains the data and the interface for other components in the frontend to interact with design, components, etc.

A Project is a class that represents the content that users need when working on a hardware description project.

A Source is a class that represents a repository or directory containing HDL sources.

A Design is a class that represents the top-level of a hardware design, which might be targeting one or multiple boards.

Graphical scene/class hierarchy:

Currently, there are neither official Docker images nor GitHub Actions for Godot (see godotengine/godot-proposals#1411 and godotengine/godot-proposals#1413). Hence, Hardware Studio uses it’s own: