You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • Metastability Starts With Standard Cells

    Metastability is a critical SoC failure mode that occurs at the interface between clocked and clockless systems. It's a risk that must be carefully managed as the industry moves to increasingly dense designs at 28nm and below. Blendics is an emerging technology company that I have been working with recently, their MetaACE product can be used throughout the design flow starting with foundation IP.

    For standard cells, there are at least three groups that benefit from MetaACE:

    • The designer of the standard-cell synchronizer
    • The individual responsible for characterizing the synchronizer cell
    • The integrator of the synchronizer cell into a SoC product

    MetaACE is used to refine cell design by minimizing the settling time-constant (tau) while maintaining other cell specifications. MetaACE is then used to obtain the parameters that characterize the synchronizer. The results can then be used to determine the MTBF of the synchronizer, as it will be used in the SoC product.

    Let’s look in detail, as it was explained to me during customer meetings, at how a standard-cell characterization team might use MetaACE as part of their flow. Assume that the design is sent to characterization; this includes the extracted cell netlist as well as device models for the process in question.


    The typical characterization flow would be run to find things like setup/hold times, propagation delay, input loads, etc. Using MetaACE one could also determine the four parameters needed for metastability analysis: Tw(1), Tw(2), tau-m and tau-s. This uses the same extracted cell netlist and device models for the characterization but with a few twists:

    1. A small netlist should be created that instantiates the design.
    2. Also, a few parameters would be defined that MetaACE will use for its analysis:

    *include process models (SS corner, for example)
    .include '$models/processModSS.sp'
    *include cell to test
    .include '$CellLib/DFF.sp'
    *include the file MetaACE creates to drive simulation
    .include '$MetaACE/ic.sp'

    *define SUPPLY and wire it to Vdd
    Vdd vdd 0 DC 'SUPPLY'

    *Wire up the flip-flop/Synchronizer cell(s) to be simulated
    xdff1 Vdd 0 D C QN Sync DFF_X1

    * bring out any internal nodes you may want to plot/analyze
    Vm3 xdff1.z9 n11 0
    Vm4 xdff1.z10 n21 0


    In the above netlist example, the model file and the file that MetaACE modifies are included as well as the flip-flip/synchronizer to be simulated. “SUPPLY” is wired up as are “C” and “D” which are used by MetaACE to specify the supply voltage and clock/data inputs. Finally, any internal nodes in the circuit needed for analysis should be brought to this top level.

    1. MetaACE is now run, specifying the netlist created, above, as the input as well as a few other parameters. The main items needed are the location for the simulator (HSPICE) as well as:
      1. The temperature of the run,
      2. Vdd for the run,
      3. The name of the clock and its rise/fall time and width,
      4. The name of the data input and its rise/fall times,
      5. The device’s setup/hold times (if known), and
      6. What node(s) should be plotted and analyzed.

    2. For a master-slave type device, the first simulation run may specify the node that is the input to the slave as the node to analyze, first; this will give tau-m.
    3. Once tau-m is found, the same circuit is run, again, but this time looking at the output of the first slave stage (if more than one stage). This will give the results for tau-s and TW(1).
    4. After this second run, the simulation can be rerun a third time looking at the output of the second flip-flop (for a multi-stage device) which will give TW(2).
    5. At each run, the configuration used can be saved for future use (in GUI or command-line mode). Steps 4-6 could be run from the command line as part of a script automatically extracting all parameters for each submission of the circuit for characterization.

    These general procedures can be run over various process corners by copying the configuration files (which are XML) and the top-level netlist, modifying the netlist to call different corner models and changing the configuration file to point to the appropriate netlist to simulate. In this way, one could simulate the SS corner and the FF corner, for example. Even more complex cases can be run, such as an N-stage synchronizer cell, where each flip-flop could be assumed to be at a different process corner. Whatever you can specify in your netlist, MetaACE can simulate.

    After the characterization process concludes, the results for the taus and TWs are tabulated along with the other parameters of the cell and passed back to the library folks for design updates, datasheets, etc. The data are all that is needed to calculate MTBF for this cell once the input clock frequency, duty cycle and data arrival rate is determined. This data could also be used to see if any recent changes made to the cell influenced tau; for example, the drive strength of the cell increased but this may have caused tau-s to get a bit larger. This may be acceptable based on some specification about what the maximum allowable tau. But for the first time, one may actually gain some insight into how their cell changes affect not only things like propagation delay and loading, but also how those changes may make performance of the cell, when used as a synchronizer, better or worse.

    Bottom line: MetaACE is a powerful tool that allows any engineer, who has the extracted cell netlists and device models, the ability to obtain the metastability parameters well before fabrication and even during the cell design process. It also allows any product engineer, who integrates synchronizer cells into his design, to calculate the overall MTBF of all the synchronizers in the system.