Monthly Archives: August 2014

ASIC Design Flow – an Overview

Today, ASIC design flow is a very solid and mature process. The overall ASIC design flow and the various steps within the ASIC design flow have proven to be both practical and robust in multi-millions ASIC designs until now.

Each and every step of the ASIC design flow has a dedicated EDA tool that covers all the aspects related to the specific task perfectly. And most importantly, all the EDA tools can import and export the different file types to help making a flexible ASIC design flow that uses multiple tools from different vendors.

ASIC design flow is not exactly a push button process. To succeed in the ASIC design flow process, one must have: a robust and silicon-proven flow, a good understanding of the chip specifications and constraints, and an absolute domination over the required EDA tools (and their reports!).


This article covers the ASIC design flow in very high level. We will provide a more detailed articles in the future explaining more about the activities within each phase. Let’s start with the first step.



ASIC System Design


Assuming your ASIC specifications are completed and approved by the different parties, it’s time to start thinking about the architectural design. In ASIC system design phase, the entire chip functionality is broken down to small pieces with clear understanding about the block implementation. For example: for an encryption block, do you use a CPU or a state machine. Some other large blocks need to be divided into subsystems and the relationship between the various blocks has to be defined.  In this phase the working environment is documentation.


Register Transfer Level (RTL)


For digital ASICs or for digital blocks within a mixed-signal chip, this phase is basically the detailed logic implementation of the entire ASIC. This is where the detailed system specifications is converted into VHDL or Verilog language. In addition to the digital implementation, a functional verification is performed to ensure the RTL design is done according to the specifications.

When all the blocks are implemented and verified the RTL is then converted into a gate level netlist.




In this phase the hardware description (RTL) is converted to a gate level netlist. This process is performed by a synthesis tool that takes a standard cell library, constraints and the RTL code and produces an gate-level netlist.


Synthesis tools are running different implementations to provide best gate level netlist that meets the constraints. It takes into account power, speed, size and therefore the results can vary much from each other. To verify whether the synthesis tool has correctly generated the gate-level netlist a verification should be done.




In this stage, the gate level netlist is converted to a complete physical geometric representation. The first step is floorplanning which is a process of placing the various blocks and the I/O pads across the chip area based on the design constraints. Then placement of physical elements within each block and integration of analog blocks or external IP cores is performed. When all the elements are placed, a global and detailed routing is running to connect all the elements together.

Also after this phase a complete simulation is required to ensure the layout phase is properly done.

The file produced at the output of the layout is the GDSII (GDS2) file which is the file used by the foundry to fabricate the silicon. The layout should be done according the silicon foundry design rules.


Get 3 quotes from ASIC design companies for your ASIC project.

How to make THE difference in SoC power management architecture

This is a guest post by Dolphin Integration which provides IP core, EDA tool and ASIC/SoC design services


To reduce the Bill-of-Material (BoM) and to simplify their usage, System-on-Chips (SoC) become more and more complex due to the integration of a large number of features previously located on board. This increase of complexity, combined with economic and green stakes leads to draw new optimizations, such as partitioning the SoC in different subsets with power and voltage islets supporting several states of activity. Theses states allow minimizing power consumption for islets that are not used or are operating with reduced speed performances.
Embedding the Power Management Network (PMNet) enables a second pass of optimization towards reduction of BoM and power consumption. One of the main challenges for SoC Integrators is then to properly select the PMNet – including power regulators, external and internal capacitors – to sustain the voltage drops caused by SoC activity changes (transition when islets are waken up …), but also to take critical decisions on the integration and the package assembly.
A new generation of power kit library is required, to ease the PMNet deployment and its reuse in successive circuits, to improve the Time-To-Market and to secure the PMNet integration into SoC.


The RPKL Approach


Along the lines of RISC architecture (Reduced Instruction Set Computer) is an alternative approach compared to CISC (Complex Instruction Set Computer), RPKL (Reusable Power Kit Library) architecture is driven by a different approach from usual
CPKL (Custom Power Kit Library), having all its regulators designed, sized, and assembled for a specific usage.
For those SoC integrators using custom power-regulation kit library to build PMNet, the challenge is that such an offering leads to:

  • Either optimize the PMNet architecture with a bottom-up approach for each load in a SoC (modifications of regulators are required to match the needed output current, voltage ranges…) – partaking in a hardly reusable library, an increase of time-to-market, and the risks associated with taping-out a new or modified design.
  • Or to create an “all-in-one” regulator that can do it all but is under-optimized for integration on SoC.


To prevent this pitfall, the guiding idea is to define a limited number of power regulators enabling a large spread of usage. To fit this need, an RPKL is based on 30 structural components (or main functions) that can be derived to produce a total of about 350 functional components (or specific functions or combinations).

  • Structural components correspond to the main functionality achieved by the component (regulator type, principle of operation, specific performances). They represent a common part which remains constant for all the functional components based on the same structure.
  • Functional components are “real” components that deliver up to a pre-defined output current and output voltage range. One of the main characteristics is a resizable pass transistor in linear regulators or switches in switching regulators (aka power stage unit).

The figure below illustrates this principle for a linear regulator. The structure remains the same and the power stage unit is interchangeable. This organization enables to select the appropriate structure for the earlier stages of the SoC architecture, with
the flexibility to select the exact functional component in later SoC integration stages.

linear regulators

A Reusable Power Kit Library based on only 30 structural components enables to address different challenges among which:

  • Low-cost, by providing for example regulators that do not require external tank capacitor to reduce the BoM.
  • Low power, by providing regulators that are specifically designed to supply low-voltage and ultra low power mode applications.
  • Low noise, for SoCs embedding analog features sensitive to noise on their power supply voltage, such as RF stages, clock oscillator and PLL when a lowjitter is required, or high performance analog and mixed-signal functions.
  • High efficiency, by providing different variants of power-efficient Switching Regulators (eSR).

The flexibility of the RPKL comes with the use of several pre-defined Interfaces of Distribution of Power (IDP). The IDP represents the connection in a cascade of regulators, or between a regulator and its loads. It enables to split the constraints between upstream and downstream regulators, for example by keeping high voltage constraints only on upstream regulators (area saving). It also enables trade-offs between higher conversion efficiency, area, BoM and the need for noise immunity in SoCs embedding many islets. The figure below gives a representation of IDPs.

IDP representation


Based on the analysis of tens of block diagrams for diverse applications – such as power metering, smartcard, smartphone, Bluetooth, wireless connectivity, tablet, industrial MCU, smartwatch, RF, or DTV -, from 180 nm to 28 nm, it is possible to affirm that only 4 different IDPs voltages are required for an RPKL.
The IDPs thereby set the standard for regulators input and output voltages; and these voltages are also common in systems so they can also be used to supply I/Os and peripherals.
Nevertheless, building a PMNet implies to verify it, and also to perform the verification from the earlier stages of the PMNet definition and optimization, up to the completion of the physical implementation. To address this need, specific views (simulation models) are provided to verify the adequacy of the PMNet with its loads in different operations scenarios to make sure that:

  • The power supply voltage of each IDP will remain in the operating range of each load during the transition from one operating mode to another (MTC: Mode Transition Check).
  • The noise generated on the power supplies by the different loads across the PMNet will not degrade the performances of noise-sensitive loads (NPC: Noise Propagation Check).
  • The integration is properly structured and sized (assembly, routing, decoupling, etc.)

These views must be provided as a standard deliverable for each functional component of an RPKL, together with some guidelines for facilitating their usage.



Benchmarking methods

There are multiple alternative solutions to build the PMNet for a given SoC. The obvious one is to optimize component-by-component, for example by getting the best efficiency for some regulators without taking into account the impact at the global network level or of induced BoM and area cost. Other parameters such as the load activity over time and the other regulators involved in the PMNet have to be considered, A more reliable solution to identify the most suitable PMNet is to define different constructions of the PMNet and to compare them using a common Figure of Merit (FoM).

A FoM is an arbitrary function that weights various parameters together in order to optimize a set of performances (power, cost, battery life, etc) and deduce the best compromise. It follows that a FoM is application-specific and its form will be selected based on those performances factors.
As a starting point, the FoM can be chosen to get the best area and power consumption trade-off by minimizing both the SoC power consumption and the SoC or PMNet area.
It leads to find the minimum figure for the formula FoM = area x power (mm2 x mW).
As an illustration, the following example represents the different loads for a SoC. The SoC is powered thanks to a battery and spends most of the time in wait mode. The optimization at application level can be either cost (BoM, SoC area) or lifetime operation (Low power).

loads to be supplied



4 different synoptics have been drawn with different approaches:
– 1- Power optimization (higher efficiency for each regulator)
– 2- BoM optimization (reduction of the number of external devices)
– 3- Optimization of the power consumption during SoC activity
– 4- Optimization of the power consumption during SoC wait mode

In the synoptics, the following regulator types are used:

  •  eSR: efficient inductor-based Switching Regulator
  •  iLR: islet Linear Regulator
  •  nLR: low-Noise Linear Regulator




The figure-of-merit below represents independently the power and area “performances” for the different synoptics. Synoptics 1 and 3 have similar power performances, whereas synoptic 2 has the lowest area but the highest power consumption. To enable to select among these 3 synoptics, the used FoM enables to weight each criterion.


FoM for 4 different PMNet synoptics


In a situation where both area and power consumption of the PMNet must be optimized, synoptic 2 turns to be the optimal solution.


The RPKL arrangement into structural and functional components allows a high flexibility and opens the door to its reuse into other SoCs. The RPKL enables fast time-to-market and right-on-first-pass integration into SoCs. Since there are many possible optimizations of PMNet for a given SoC, selecting the appropriate one can be eased by using the appropriate FoM that can be enriched to match with the targeted application.
Before launching a complete library of products based on the RPKL principle, proof of concept has to be checked thanks to Silicon Qualifiers in different process nodes. Associated verifications have also to be demonstrated in order to enable to anticipate
by simulation the behavior and performances of the PMNet and its associated loads.
Indeed, it is not only necessary to prove that power-regulators individually meet their specifications, but also that all interactions are properly mastered, simulated and measured: IR-drop, Pop-Up Noise, transitions between modes of power domains, high-frequency disturbances on high-resolution converters.


Click here to learn more about Dolphin Integration products and services