umarcor hwstudio f2f1ef hwstudio?include prereleases&longCache=true&style=flat square&label=Releases&logo=github&color=informational

Hardware Studio (hwstudio) is a graphical design environment for hardware modelling, focused on (V)HDL. It allows describing systems by arranging and connecting blocks in a diagramming tool. Unlike other similar tools, the main target of hwstudio is not HDL generation. Instead, it is expected to be used by hardware designers for gaining insight into their models and for easing cumbersome tasks, such as connections in large structural architectures or co-simulation with non-trivial software models.

This is a work in progress proof of concept and not actively funded/developed. A diagraming tool which is kept in sync with HDL sources needs to integrate multiple complex features. It is challenging to bring together the expertise in hardware design with knowledge about software architecture, and spare time for devoting to open source tooling. Hence, this repository contains several iterations to try putting together existing pieces: Godot, OSVB (GHDL, VUnit, GtkWave, OSVVM…​), pyVHDLModel, hdl/constraints, hdl/containers, SymbiFlow, etc..

User Guide

Installation and setup

Since this repository is early work in progress, no regular/tagged releases are available yet. Nevertheless, after each commit is pushed, CI workflows produce artifacts. Latest artifacts are published as assets of pre-release nightly: github.com/umarcor/hwstudio/releases/tag/nightly.

Hardware Studio is composed of two main components: the frontend and the backend. Features that require interacting with files or tools on the host are not implemented in the frontend, but handled by a backend. Therefore, although the frontend can be used standalone, it is recommended to run both of them.

Frontend

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!

Native builds of Hardware Studio are available for x64 only. However, the backend can be executed on any platform, as long as EDA tools are available.

HTML5

Godot has built-in support for docs.godotengine.org: Exporting for the Web. That generates an HTML5 build to be used on browsers with support for WebAssembly (WASM) and WebGL. The HTML5 build of Hardware Studio is available at umarcor.github.io/hwstudio.

Since WASM is a very recent technology, there are still compatibility and performance issues on some platforms/browsers. For instance, fonts are not properly scaled on 4K monitors. It is therefore recommended to use the native artifacts.

The HTML5 artifacts are available for download, so users can run the HTML5 build locally for experimentation. Note that a web server is required for serving the files. For testing purposes, a shell script is included in the tarball (serve.sh), which will start a Docker container and serve the content.

Backend

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:

# pip3 install -r py/requirements.txt

Then, execute the main script for starting the server:

# ./py/api/main.py
Serving on port 8000...

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.

When using the HTML5 frontend, open the Console in the developer tools to see the output printed to the terminal by the frontend.

Usage

Hardware Studio’s frontend has three main editing modes, each of them based on one node type in Godot: Graph, Tiles and Spatial. Modes are just different approaches to drawing the designs and allowing the user to navigate and modify them. Having different modes is a result of exploring the capabilities and limitations of Godot as a hardware diagram editing tool.

Apart from the editing modes, the menu of Hardware Studio includes explorer features for gaining insight into the designs, boards, devices, etc. Currently, development is focused on those features rather than on the diagraming aspect.

Usage of Hardware Studio should be intuitive and self-learning should be easy. If you don’t understand how some feature works, or if nothing happens when you do some action, chances are that it is not ready yet. Feel free to open an issue for discussing it!

  • Right-click anywhere on the Tiles or Spatial modes to open the context menu.

  • Use Ctrl + Space and Ctrl + Shift + Space to switch between editing modes.

Graph

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.

Tiles

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.

Spatial

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.

  • Use WASD or arroy keys for moving the "player".

  • Use + to enable instantiation mode.

    • Page Up and Page Down iterate over the available "blocks". Currently, there are 7 blocks only, representing and, or, xor, not, nand, nor and xnor.

    • + places an instance of the block.

    • Esc disables instantiation mode.

Menu

There are two main menus in Hardware Studio:

  • Context menu: a popup menu triggered with the right-click of the mouse. It allows opening the main menu, changing the editing mode, opening the documentation, the About page and quitting. It contains additional options specific to the active editing mode.

  • Main menu: a full size panel with tabs, opened from the context menu and closed with Esc. Tabs Repositories and Boards allow exploring the designs and data about the devices, while Preferences contains configuration options.

Repositories

TBW

pyVHDLModel uses Design as the root of multiple documents and libraries. Therefore, it does not match the naming/classes in Hardware Studio. A Model Design corresponds to a Design in Hardware Studio, plus the tree of sources. In order to retrieve the tree of sources, the Sources field of the corresponding Project needs to be inquired.

However, currently libghdl and therefore pyGHDL.dom don’t allow handling multiple Designs in a single instance. Therefore, Hardware Studio analyses all the sources in a Project as a single Model Design.

Boards

TBW

Preferences

TBW

Development

Tools

For previous iterations based on Vue.js, Vuetify, and JointJS or Three.js, see other branches.

The current iteration of this project is based on Godot (github.com/godotengine/godot), a "multi-platform 2D and 3D game engine" . Despite Godot being presented as a game engine, it is a powerful framework that provides common tools for writing fancy and interactive interfaces. It has built-in support for exporting to multiple platforms: Linux, Windows, Mac OS, Android, iOS, HTML5 and consoles. Moreover, it is free, open source, community driven and lightweight.

A very interesting feature of Godot is that a very complete set of pre-built control nodes is provided. "Node" is the term used in Godot for reusable objects/items, and "control" is the category with nodes for User Interfaces (UIs). The category includes not only labels, buttons, checkboxes, etc. but also container/layout components that set anchors, margins and sizes automatically. As a matter of fact, Godot Editor (the development environment/application) is written/designed using the engine itself; so are most of plugins/assets available in the (Asset Library). How cool is that!

Therefore, designing interfaces with Godot feels gratefully similar to using CSS frameworks such as Bootstrap, Bulma, Tachyons, etc. Yet, Godot provides two significant advantages. On the one hand, Godot exports to HTML5 by converting the game/tool to WebAssembly and exports to other platforms are native statically compiled executable binaries. Hence, desktop releases are significantly more lightweight than putting a website into Electron or NW.js. On the other hand, for providing so-called single page applications (SPA), CSS frameworks need to be complemented with a JavaScript/TypeScript framework, such as Vue.js, React or AngularJS. In the context of a diagraming tool, those general purpose JS frameworks fall short. There are more specialized libraries (JointJS, Three.js…​), but none of them provides powerful enough pre-built UI features. Coordinating a backend, a framework for UI and a different framework for diagramming is certainly a difficult task. The most complete JS framework in this regard is JGraph/mxgraph, which is a self-contained solution including frontend libraries and backend. Unfortunately, mxgraph was a commercial project for a decade, before being open sourced a few years ago. Subsequently, there are some constraints that feel dated. For instance, backends (and documentation) are only available in .NET and Java. However, the main drawback is that lots of features are related to allowing users to customize the look and feel of their diagrams through graphical interfaces, and to allowing developers to build complex custom interactive diagrams. That’s a whole set of features that we don’t need, and thus add excessive complexity. In the context of this project, we need a tool good enough for drawing structural diagrams with square boxes and a single predefined style/theme. However, it needs to provide easy bindings to languages such as Python or C.

If you are new to Godot, read the docs.godotengine.org: Step by step guide. There, you will learn that multiple languages can be used. Apart from C/C++ or C#, Godot offers its own programming languages: docs.godotengine.org: VisualScript and docs.godotengine.org: GDScript. Furthermore, with GDNative, high-performance code can be written using compiled languages like C, C++, Rust, or Python (using the Cython compiler). In the frontend of this project, GDScript is used only (for now), which is similar to Python with optional static typing. Nonetheless, VisualScript is very relevant too. It is a node-based (graphical/visual) programming language. Users/designers/developers can drag and drop nodes and set connections to compose a dataflow diagram. Since Godot Editor is built with the engine, this means that there are built-in classes for handling those diagrams. Hence, it is possible to design custom tools by reusing those. For example, littleMouseGames/whiskers.

Overall, the only drawback of Godot is that windows and dialogs are fully managed by the engine. In consequence, when opening or saving some file, the explorer is not the native one from the host. Moreover, the tool and the modal windows are constrained in a single main window (for now); i.e. floating dialogs cannot be moved to other monitors. Nonetheless, for this same reason, the experience is more consistent across platforms, which might be desirable.

Design goals

The layout and routing of schematic/dataflow diagrams that minimize crossings is a non-trivial optimization/algorithmic problem (godotengine/godot-proposals#1401). However, that is neither the most complex nor the most important feature to implement. This project can get along with a just good enough connection routing solution. Layout and routing has been thoroughly studied and is known to work well enough. Instead, this project is focused on some more interesting ideas. In this context, "interesting" means "not attempted before" (thus, undocumented) or "no public/open implementation available, although the feature is known in some vendor/commercial product".

(V)HDL centric design

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.

  • rust_hdl was developed by Olof Kraigher (co-author of VUnit), starting in 2018. It is written in Rust and it is meant to provide "a collection of HDL related tools". Parsing of the VHDL language is almost complete, but semantic analysis stages were not implemented yet. In fact, plugging rust_hdl as a frontend into GHDL (or using GHDL as a backend from rust_hdl) has been discussed. However, rust_hdl is not actively developed at the moment, since the main author is currently not using HDL.

  • pyVHDLParser is a token-stream based parser developed by Patrick 'Paebbels' Lehmann. Patrick is the Vice-Chair of the IEEE P1076 Working Group, so the main focus of pyVHDLParser is correctness and fast (real-time) processing without requiring a compiled tool. Development started in 2017, however, due to the focus on covering and properly handling all the features in the language, it is a long going project which is not complete yet.

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:

  • Parsing the entities to get the list and types of generics and ports. This is possible with pyGHDL.dom already, and it might be possible with rust_hdl too. Hence, it’s possible to identify entities as blocks to be instantiaded in diagrams.

  • Getting an schematic/RTL diagram from an architecture. This is more complex, as it requires not only parsing, but also semantic analysis and (at least partial) elaboration of the design. The output of ghdl --synth might work well (either before or after passing it to yosys). Nonetheless, this is the main goal of this project, as it would really provide insight into existing designs.

(V)HDL generation/synchronization

As a complement to generating diagrams by analysing (V)HDL sources, it should be possible to generate structural (V)HDL sources from diagrams in Hardware Studio. This is supported by many tools already, so it is not a novelty, but a need for usability.

In this regard, it is unfortunate that neither a standard style guide nor open source automatic code formatter exists for VHDL. As a result, keeping style consistency between handwritten and generated sources is not possible yet. Nevertheless, that is one of the expected use cases of pyVHDLModel. See also VHDL Style Guide (VSG).

2.5D|3D visualization

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.

Gamification of hardware design and Industry 4.0

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, albeit not being a relevant mechanic in the game.

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.

Integration with other tools

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.

Structure

Hardware Studio is implemented in two main components (a frontend and a backend) which talk to each other through a web API (see wikipedia.org: OpenAPI Specification). As shown in Figure 1, the frontend is written in Godot’s GDScript. On the other hand, the backend is written in Python and it handles most of the complexity. Since the goal of Hardware Studio is to wrap existing projects, rather than reimplementing them, the backend is based on bridging to and reusing over a dozen purpose specific open source tools.

Internal structure of Hardware Studio
Figure 1. Internal structure of Hardware Studio.

Projects and *.hwf

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.

The binary/text format for saving ArchGraphs is undefined yet. That’s why this tool is still barely usable.

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.

Signal/port types

TBW

  • How to handle compatible/incompatible types

  • Getting resolved types needs elaboration, so we use string representations for now

Editing modes

Tiles

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

Spatial

TBC

Types

These classes are to be (re)designed in terms of pyVHDLModel.

The workflow and internal structure of Hardware Studio are based on Entities, Architectures and Blocks:

  • Entities are black boxes with name, ports, generics/constants and a context. It defines the external interface of a component.

  • Architectures are the description of the logic/behaviour of a component. Architectures have a name, an Entity they belong to, and the content. That content can be defined using different languages, hence multiple types exist: ArchScript, ArchGraph, ArchVHDL, etc.

  • Blocks are each of the components in a diagram/design; the instantiation of Entities. Blocks have a name, the Entity/Architecture that are to be used, and maps for generics/constants and ports.

Hence, the main difference compared to other circuit/model diagraming tools is the ability to select the behaviour (thus implementation) of a block through a dropdown list. In traditional GUI tools, changing the behaviour requires the deletion of the previous block, and even redoing all the connections to/from it. Fast swapping of implementations in different languages allows for iterative comparison during development. That is, it allows switching between e.g. an in-development (V)HDL design and a reference software function. This concept is, naturally, borrowed from the VHDL language.[1], but extended to other languages.

For now, extracting diagrams from (V)HDL sources is not supported. Hence, only architectures of type ArchGraph can be viewed and edited in the explorer. Therefore, the top-level instance is expected to be of type ArchGraph. Users can then instantiate any kind of Block in there.

Data

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.

Project

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

  • Name : String: name of the project. Does not need to be unique.

  • Sources : Array: a list of objects of type Source.

  • Designs : Array: a list of objects of type Design.

Source

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

  • Location : String: URL or path of the repository/directory.

  • Type : int: type of sources, where the integer is a constant from the enumeration {glob, pyCAPI, FuseSoC}.

  • Library : Dictionary: name of the logical libraries where sources are to be analysed, and the corresponding patterns (applies to type glob only).

Design

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

  • Name : String: name of the design. Does not need to match any entity name, and it does not need to be unique.

  • DesignTop : String: the top-level unit of the logical design and (optionally) secondary unit, using the following syntax LibraryName.PrimaryName(SecondaryName).

  • Targets : Array: a list of objects of type Target.

Target

  • Board : String: identifier of the target board.

  • BoardTop : String: the top-level unit of the implementation and (optionally) secondary unit, using the following syntax: LibraryName.PrimaryName(SecondaryName).

  • IO : Array: mapping of the top-level ports to the device pins.

  • Constraints: (optional) constraints to be passed to simulation, synthesis or implementation tools.

Entity

  • name

  • context

  • generics

  • ports

Generic

  • name

  • type

Port

  • name

  • direction

  • type

Architecture

  • name

  • entity

  • type

    • ArchScript

    • ArchGraph

    • ArchVHDL

    • ArchICE

    • …​

ArchScript

Logic defined in GDScript. Mostly used for defining built-in basic blocks.

ArchGraph (GraphEdit)
  • children:

    • GBlock (entity instances)

    • GLabel

    • GSlice

  • types

A dataflow diagram designed using Godot’s GraphEdit and GraphNode.

ArchVHDL
  • entity_file

  • entity_name

  • arch_file

  • arch_name

VHDL sources.

ArchVerilog

TBW

ArchICE

TBW

Graph Nodes

Graphical scene/class hierarchy:

  • GraphNode

    • GNode

      • GBlock

        • name

        • entity

        • architecture

        • generic_map

      • GLabel

      • GSlice

Internationalisation and localisation

Godot supports translating games/tols by importing CSV files, or using gettext's *.po format. See docs.godotengine.org: Internationalization.

Hardware Studio is in a very early design state and no internationalisation was done yet. Should you be interested in helping, let us know!

Continuous Integration (CI)

GitHub Actions is used for automatically building Hardware Studio and for publishing artifacts/assets. See CI runs at github.com/umarcor/hwstudio/actions. Two main workflows are defined in .github/workflows:

Since the output of asciidoctor is a single HTML file, no artifact is uploaded.

Action .github/actions/godot

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:

Roadmap

  • Complete the definion of the Types classes.

  • · Extract entities and architectures by parsing HDL sources:

    • VHDL

      • Define the OpenAPI between the frontend and the backend (container swaggerapi/swagger-editor).

    • Verilog

      • Verilator?

  • Implement the functionality of OSVDE in tab Repositories of the main menu.

  • Define/update the content of Block details in Repositories, depending on the selected unit (in the tree or in the diagram).

  • Redefine the routing of the connections in the Graph mode (currently, splines/bezier curves).

  • · Generate HDL sources from ArchGraph:

    • VHDL

    • Verilog

  • · Generate ArchGraph from:

    • VHDL

    • Verilog

    • ICE

  • · Synch Entities and HDL sources:

    • VHDL

    • Verilog

  • · 2.5D

    • Minimap

    • Layers/groups

  • · Co-simulation

  • · Waveforms

References


1. See the concept of Configurations in the VHDL LRM.