The Instigater: Services with a Smile
Born in 1978, Yerevan, Armenia Holds a Master's degree in Construction Engineering. In 2004 started an engineering center with 7 students. Now there are over 150 engineers working at Instigate cjsc and affiliates across the country. Responsible for strategic planing and implementation, business … More »
EDA Application Porting Guide: Part 1
October 10th, 2014 by Arman Poghosyan
With this article we would like to start a series of tutorials covering the migration of EDA applications from Windows to Mac OS X and GNU/Linux. For that purpose we will review the technologies for building user-interface, data layer and business logic of typical EDA tools. For each of these technologies we will discuss porting concerns, issues, and solutions.
Nowadays, designers and developers have a variety of options when it comes to getting their development work done. There are choices in the areas, for example, of what application framework, programming language, and SW libraries to use, or what HW and OS platform to run on. Historically, EDA developers were using GNU/Linux and Windows operating systems. Current market trends, however, offer the opportunity for EDA developers to consider choosing a different OS for new developments. E. g. adding support of OS X and/or GNU/Linux to existing products, or permanently migrating to one of these operating systems, and vice versa. Today GNU/Linux and Apple OSX are more appealing for EDA and other applications, yet many EDA applications originated on Windows, and there are several technical difficulties in migrating from Windows to GNU/Linux or OSX. Let’s take a high-level look at one of these issues – the GUI. Also it is important to note that this applies not only to the existing, but also to new code-base. Even new products may initially start on GNU/Linux, and later, with growing adoption and revenue, company may consider porting to relatively less significant platforms.
Graphical User Interface
The Graphical User Interface of a typical EDA application consists of the following components:
(1) Menu bar, (2) Tool bar, (3) Search bar for locating items in design hierarchy, (4) Design Hierarchy browser, (5) Property editor for specific items in design hierarchy, (6) Command log, providing history of operations performed by the user in the current session,
Typically an application has main-window which provides
Design hierarchy contains information about design, that can be categorized into various levels of abstraction and formats as follows:
Automation (scripting) is an important feature of any CAD SW, and it is important to achieve the level of automation where any modifying operation that is possible to invoke from GUI, is also possible to invoke from the scripting engine.
There are also read-only commands used for navigation and iteration of objects in the database, and commands that manipulate the state of the user-interface and controller, including view-related commands such as zoom-in/zoom-out, and session-related commands such as undo/redo.
Ideally, in the case of clear design, any operation performed from the graphical user-interface, such as menu/toolbar-item invocation, or modification of object properties from property-editor dialogs, is not performed directly on the database item, but is mapped to the scripting command, and is executed by actually invoking that scripting command, thus ensuring that the journal-file recorded during the session is fully reproducible without any side-effects caused by modification of the data from the GUI code, bypassing the scripting engine.
Let’s also take a look at the internal structure of such application. The diagram below represents the architecture of a typical EDA tool:
The software architecture is typically decomposed into three main logical layers:
The graphic above shows the relationship between the layers.
The presentation layer is what a system user sees or interacts with. It can consist of visual objects, such as tree-views, dialogs, schematic drawings, and non-visual objects such as undo-stack, clipboard, current state of the UI, etc.
The business logic layer in EDA typically includes series of point-tools that operate on the database. Some of these tools operate in push-button mode, e.g. place & route or synthesis SW. Some other tools are very tightly integrated with GUI as they are semi-manual and typically very interactive, such as semi-manual place&route, LVS, DRC-aware router, and other tools in Analog-Mixed-Signal.
The data access layer is used to represent the design data in-memory and on-disk. It provides operations for storing, loading, importing, exporting the data from on-disk DB to memory-memory representation and back.
It is advised to strictly and cleanly encapsulate the in-memory structures into public API (e.g. C++ header files) that provide application business logic with a transactional (validated) access to the in-memory database, thus ensuring consistency of the data. This API is frequently referred to as CRUD logic, standing for Create, Read, Update and Delete operations over the DB objects. Some EDA tools rely on standard Database Management Systems (DBMS), including both general purpose SQL systems like MySQL, and EDA-specific non-SQL systems like OpenAccess.
At, this point, we wrap up the EDA software architecture design overview to focus on each layer in the other article. In our later topics we will concentrate on every logical layer in depth. In the upcoming series of articles we will discuss possible techniques which can be used for Windows to Linux/MacOS migration for each of the components described above.