Open side-bar Menu
 The Instigater: Services with a Smile
Arman Poghosyan
Arman Poghosyan
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

Introduction

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:

EDA - GUI

EDA – GUI

(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,
(7) Command line prompt, that lets user enter scripting commands, (8) Status bar, indicating the status of the window/controller, as well as any currently running command (9) Schematic/Layout views and editors, displaying the design logical designs (schematics) and physical designs (layouts) of the developed system.

Typically an application has main-window which provides

  1. Project/file management functionality: open/close/save project, import/export files into the project from various industry standards.
  2. Database browser: typically a combination of tree-views, table-views, and property-editor dialogs, that let users navigate the project hierarchy, and inspect each individual object.
  3. The embedded scripting interface, which enables application automation, allowing the user to perform any operation on the database using scripting languages such as TCL, Python, JavaScript, Skill, Scheme, Lisp, etc.

Design representations

Design hierarchy contains information about design, that can be categorized into various levels of abstraction and formats as follows:

  1. Design specifications – text documents and drawings (UML, Vector Drawings, etc)
  2. Algorithmic/Functional models of design – e.g. Matlab/Simulink or C/C++/SystemC reference implementations and executable specifications
  3. Algorithmic/Functional test-cases – SystemC or SystemVerilog tests, or tests in Matlab/Simulink, or just test-vectors to be used by QA team
  4. Bit-accurate and clock-accurate RTL interfaces and implementations, including multiple implementations for the same module (e.g. functional and synthesizable models)
  5. For analog-mixed-signal design the role of logical design is taken by Schematic views and spice simulation specification and configuration files
  6. The physical design data: P&R data for digital design and layout data for analog-mixed-signal.
  7. Configuration files and scripts for compiling the design, running various design flows, as well as running verification tool-chains and flows, and finally – the log and data files storing the results of executing those flows.

Scripting Interface

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.

Architecture

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 architecture of a typical EDA tool.

The architecture of a typical EDA tool.

The software architecture is typically decomposed into three main logical layers:

  1. presentation layer
  2. business logic layer
  3. data access layer

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.

With the help of scripting layer the journalization and command line support is provided for the business logic layer and for the other functionality (CRUD logic, save/load, import/export, etc). This requires developers to integrate one or several most commonly used scripting engines into the SW architecture: TCL, Python, Javascript, Lisp, Scheme, etc.

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.

Related posts:

Leave a Reply

Your email address will not be published. Required fields are marked *


*

TrueCircuits: IoTPLL



Internet Business Systems © 2017 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise