FTL Systems' high-end engineering software systems have evolved from point tool products bundled with other third party components from firms such as Analogy, Avanti, Synopsys, Siemens, Infineon and OneSpin. Over 6,000 of these point tools were resold over the last 20 years.
FTL Systems' engineering software suite grew out of FTL's internal engineering software requirements. These requirements and tool technology evolved over more than 20 years of FTL Systems designing high end processors, complete computer systems, telecommunications, energy systems and autonomous robotic systems. In 2016, 2017 and 2018 we are partially re-writing and re-packaging portions of the Engineering Suite to meet the needs of mainstream industry customers. Modules are available to the market in phased releases.
Developed by a single team virtually all competing engineering tool systems are developed as point tools by those who focus on tools rather than advanced product design using the tools. Usually such point tools are purchased and integrated into a tool suite by a third party. The resulting tools often have a variety of user interfaces and limited design communication between point tools. FTL Systems' engineering software suite was developed by a single, long-term, user team to meet their needs based on real, high-end designs.
We are now offering the modules as an integrated, end-to-end design flow from conceptual design through manufacturing. Direct sale as an integrated design suite provides greater end customer value and ease of use. As a suite intended for mainstream users, some capacity and functionality limitations apply. Modules are available to the market in phased releases.
End-to-end design flow Previous versions of the engineering software suite were resold as point tools, bundled with other third party components from firms such as Analogy, Avanti, Synopsys, Siemens, Infineon and OneSpin. Over 6,000 of these point tools were resold over the last 20 years. With the 2016 and 2017 releases we offer the modules as an integrated, end-to-end design flow from conceptual design through manufacturing. Direct sales as an integrated design suite provides greater end customer value and ease of use. As a suite intended for mainstream users, some capacity and functionality limitations apply.
Intrinsically Multilingual FTL Systems uses a patented, language neutral database technology to represent design data. This enables separating the language-specific design modules and the back-end tools such as synthesis and routers. This both reduces the development effort and provides an intrinsically multilingual, collaborative design experience including restricted design language translation capability.
Industry-Standard Interfaces Where feasible, the engineering software suite reads and writes industry standard textual interfaces. To facilitate migration, the suites also read a limited set of proprietary, legacy interfaces however these are not intended to be complete or supported for ongoing usage.
Integration of Real-World Devices FTL's many patented features include ways to accurately integrate existing digital and even analog devices into a system-level simulation. For example, FTL Systems' SpiceMillertm technology creates new analog models from actual analog devices running on conventional device characterization tools. Embedded ARM processors and FPGA devices can be integrated, enhancing both verification accuracy and performance.
Economically Modular Mainstream industry customers vary widely in their engineering software needs over time. Therefore in the rewrite, FTL Systems adopted a highly modular structure and financial model. Modules can be readily and economically licensed for a time period, perpetually with the option of ongoing software updates or as a secure, cloud-based service (SaS). Users can get exactly what they need, when they need it.
Linux-Centric FTL Systems focuses on making the best uses of Unix, specifically Ubuntu Linux. Although we have supported other Unix, Linux, AIX, Solaris, HPUX, OSX and Windows versions over the last 20 years, we believe that focusing on Ubuntu Linux provides users with the highest productivity and most cost-effective design environment possible.
Strong and Timely Platform Support FTL Systems recognizes the need for strong and thus focused platform support. With Ubuntu Linux, X86-64 processors and AMD GPU hardware there are many potential hardware platforms. However in order to improve quality, FTL's focus is on hardware platforms built and sold by FTL Systems using X86-64 processors, AMD GPU hardware and FTL's own processor systems. Intel and AMD processors must implement X86-64 (64 bit only), optionally with one of several instruction set extensions. AMD GPU architectures are supported (Nvidia GPU are not supported).
Designed to Effectively Use Distributed and Cloud Computing for Collaboration FTL Systems has a long history developing parallel, high performance computer systems. During the recent re-write of the mainstream tool suite we adopted a distributed and cloud computing methodology. Many designers work on a system providing a high-end user experience, often with multiple screens and multimedia capability. Other designers in the test laboratory and field access the common design environment from tablet or other mobile devices. Back-room servers provide the required engines for computationally complex modules.
Many of the following illustrations are drawn from FTL Systems' own designs. We develop the engineering tool suites based on in-house experience.
The VHDL (digital) and VHDL-AMS (analog and mixed signal) Design Module enables reading, writing and designing using a standardized, textual hardware description language (IEEE Standard 1076 and 1076.1). VHDL and VHDL-AMS meets the needs of those designing systems with electronic, electro-mechanical, fluidic, optical and even parallel software / firmware components. Following the Pascal and Ada philosophy, VHDL and VHDL-AMS are strongly typed and generally insensitive to case.
Tools within the VHDL/VHDL-AMS design module focus on correct-by-design methodology, extending the underlying methodology under which VHDL and VHDL-AMS were developed.
VHDL-PLI (programming language interface) also requires the C design module.
The Verlog, Verilog-A, Verilog-AMS and System Verilog Design Module enables reading, writing and designing using a standardized, textual hardware description language (IEEE Standard 1364, Accelera 3.1a for Verilog-A / Verilog-AMS and IEEE Standard 1800).
Tools within the Verilog Design Module focus on loosely typed compatibility with the C design style. Verilog types are primarily defined inside the standard rather than as external packages.
Verilog's VPI also requires the C design module. The older Verilog PLI is not supported.
The SPICE Design Module supports design of lumped parameter analog circuits using Berkeley SPICE and a variety of industrial spice versions. To facilitate multi-lingual design and integration of other SPICE dialects, this module translates SPICE models into VHDL-AMS. It uses VHDL-AMS device models (supplied as binary) to define device functionality. Only a subset of device models are supported however users can employ VHDL-AMS to add their own devices.
The C, C++ and System C Design Module enables reading, writing and designing widely available programming languages. This design module can be used to create software, firmware and even behavioral descriptions of hardware. Logically some C and C++ constructs are dynamic in ways that do not directly map to hardware constructs alone such as run time recursion and dynamic memory allocation. These require support unique to FTL's Behavioral Synthesis Module.
The Electronic Design Interface Format (EDIF) was originally intended to provide a means for exchanging net-list or schematic information between tools developed by distinct vendors. Although standard develop has been discontinued, EDIF 2 and 4 standards are widely used by industry for the intended purpose.
The Test Case Language Module supports a commonly used, interpreted language (TCL) and graphical display language (Tk). FTL Systems' implementation of TCL includes many additional commands needed to control the functionality of other, engineering suite modules. Only those modules that are accessible have their additional commands brought into visibility. TCL and Tk are only used during simulation; they cannot be synthesized into hardware or firmware.
Versions supported include 8.5 & 8.6.
Integrated optical design includes devices such as transmitter optical sub assemblies (TOSA), receiver optical sub assemblies (ROSA), optical fiber as transmission lines, optical splitters, optical combiners, frequency domain optical processors and propagation within atmospheric media or lens. Such models are almost always dependent on the optical frequency spectra of the transmitted signal.
This module is intended to work in conjunction with an electronic, lumped element mixed signal hardware description language such as VHDL-AMS or Verilog-AMS. The integrated optical design module addresses the non-lumped characteristics of integrated optical devices wherein the frequencies involved are such that few devices are truly described by lumped parameters.
The Digital Simulation Module includes numerous innovations in multi-core simulation. These techniques are covered by numerous FTL Systems patents and patent applications worldwide.
The Mixed-Signal Simulation Module includes numerous innovations in time-domain and frequency domain simulation. These techniques are covered by numerous FTL Systems patents and patent applications worldwide.
The Programming Language Compiler / Linker Module translates VHDL, Verilog, C or C++ source code into linked, executable binaries suitable for external execution on suitable processors. ARM executable can be verified within the suite using the Embedded ARM Co-Design Module.
applicable to supported compiler targets (above).
By compiling and linking for independent execution, fully contained device modules realize stand-alone digital simulation models. These models do not include devices built into the Design Modules nor mixed-signal models.
Standard platform debuggers, such as GDB, and profiling tools, such as gprof, can be used for external execution (compatible with GNU binary formats). Alternatively tools within the Digital Simulation module can be used.
The Embedded ARM Co-Design Module supports design in which one or more ARM cores are combined with dedicated hardware. For example, FTL Systems uses ARM processors to provide its TeraFLOP to PetaFLOP processors with boot and diagnostic capability.
The Embedded ARM Co-Design Module includes a compiler, debugger and profiling tool. Development may be migrated from an ARM simulation model into ARM-compatible silicon and then non-volatile memory as the development cycle evolves.
FTL Systems' Merlintm Behavioral Synthesis Module translates behavioral hardware description language constructs into a behaviorally equivalent embodiment using a well defined set of logical primitives. Examples of logical primitives include adders, latches and NAND gates. The primitives may be user-defined so as to map onto primitives defined by an FPGA, gate array or standard cell.
Using behavioral hardware description language inputs can greatly reduce the design time, cost and reliability of significant designs.
Outputs include both EDIF net-lists and a database format accessible through the OpenAccess API.
FTL Systems' Merlintm Physical Synthesis Module translates net-lists defined in terms of logical primitives into net-lists consisting of devices defined with parameters. Examples include transistors, passive devices and transmission line. Optimization within the physical synthesis tool transforms device net-lists to reduce circuit size (scheduling), reduce latency, reduce power or comparable transformations.
The Mechanical Design Module results in high level directives for manufacturing custom parts, creating assemblies / sub-assemblies and insuring that all parts fit together as intended. Substrata / printed circuit boards result in a DXF file defining the physical size. Assembly information, metal and plastic components get translated into inputs to the Computer Aided Manufacturing Module. The overall mechanical design becomes input to the 4D Rendering Module.
to yield either a 3D (projected image plane), a 4D model of a design (3D with time history) or a unique, immersive rendering.
Typical outputs are standard formats such as JPEG, JPEG2000 or an FTL-specific immersive 3D representation.
Place and Route Module for printed circuit board and other substrata translates net-lists, package definitions and timing constraints into files used for fabricating a specific substrata or printed circuit board file. Placement geometrically locates package terminals from the net-list. Routing provides a path to connect net-lists to packages along a single layer and between layers.
Routing employs a semi-automatic strategy. An experienced PCB designer is intended to guide the routing strategy with the help of tool assistants that automated steps where possible (such as a bus or differential pair route).
The PCB route uses ODB+ as its output file format.
extracting actual load, timing and other parameters in order to drive post place and route simulation.
If simulation of the post place and route timing does not satisfy all timing and yield requirements, the place and route phase may need to be repeated. In practice, timing and yield checks are implemented incrementally.
in addition to the internal net-list, timing and yield constraints.
Outputs include a database format accessible through the OpenAccess API and the older GDSII file format.
Semiconductor manufacturing software translates the OpenAccess and other outputs from the integrated circuit router to optimally control the equipment actually used to produce an integrated circuit die within a fab.
Preparation for lithography translates the engine-independent files into a form that corrects for specifics of the mask maker (if employed), the lithography engine, the resist employed and other manufacturing specific provisions. For example, before making a set of optical masks one typically corrects for diffraction within the mask and resist layer (OPC). Direct write engines require engine-specific commands to steer the required beam.
Scheduling software organizes the specific machines assigned to a fabrication and the travel of wafer carriers (300mm FOUP) among machines for optimal fab throughput. At each step in the wafer processing, machines must often have wafer-specific parameters.
Wafer test prepares the test patterns used for testing wafers between process steps, after completion of all wafer-level steps and after dicing a wafer into die.
Once the die is tested, control files may be needed for a laser tool that configures fuses to achieve specific functionality or maximize yield.
Once a wafer is divided into die and has its fuses configured packaging tools must be guided to provide the applicable input / output connections and thermal transmission provisions. Fuse configuration may determine the actual part number of each resulting die.
Manufacturing control software must account for the final disposition of each die in JEDEC trays, as multi-die modules or as manufacturing scrap.
The Computer Aided Manufacturing Module translates the description of machined components and component assemblies into formats that can be directly used in manufacture.
transformation of sub-assemblies and assemblies into a form suitable for semi-automated, robotic assembly analysis of sub-assemblies and assemblies to determine material requirements (ERP interface), and scheduling of materials for manufacture against inventory and pending materials orders.
As Engineering Suite users, FTL Systems recognizes that libraries of behavioral models, physical packages, logic technologies and mechanical components are critical to rapid and reliable design. Therefore we put high priority on such libraries as well as importing customer-created libraries from other sources.
We provide dedicated tools to define and check symbols, packages and mechanical components in a Librarian Module.
The same component may have various representations. IEEE and ANSI has a standard for some kinds of symbols, Std 91-1984 and Standard 617 of the IEC. Symbols can vary based on the factors such as the aggregation of bits into higher level data types (buses), handling of power signals and other representation styles.
Where suitable models are available, we recommend the Free Model Foundry (www.freemodelfoundry.com), a repository of VHDL and Verilog models commissioned by the device manufacturer.
For further details and to order module licenses please contact your FTL Systems sales representative.
Copyright © 2018 FTL Systems BV. FTL Systems Inc. (US) is a distinct business in the US.