Archive for February, 2010

ASIC Verification for Low-Power Problem

February 11, 2010

With ever-increasing smaller and denser geometries and increased lifestyles of portability and website immersions, the latest portable systems such as PDAs, cellphones, laptops, netbooks, iPaq, iTouch, iPod,… need large power capacity and in conjunction the smallest power consumption.

For the ASIC design specialist, he or she must manage the smallest power consumption issue.  He/she must ensure with proper check-offs of the design tape-out checklist that the items have been properly verified.  One such example is the low-power mode for SRAM (static RAM).  Most designers are careless about the default states of READ ENABLE (REN), CHIP ENABLE (CEN), and WRITE ENABLE (WEN) during the RESETN time.  For a good design, these signals should be in the disabled state of  “0” which means there are no read or writes occuring.  However, sometimes he/she makes minor mistakes and one or a few of the signals become active “1” .  Unfortunately, this can mean an extra 100 to 200 uA current being consistently drained by these active signals.  It’s a cleaner design to always prevent this from happening.  One method is to use assertions to monitor the default states during dynamic simulations or the verification engineer can use formal verification (to formally prove the property will never occur).



For this example, you can code the assertion quite easily and add it to the verification assertion library of components aka vlib.

I added coding to ensure assertion only monitors when RESETN goes active high (inactive) using the $rose construct.

Additionally, we want to wait up to 10 cycles when RESETN goes active high to ensure no weird state machine glitching causes the assertion to trigger “falsely”.

property CRW_zero_clk;

@(posedge CLK) ($rose(RESETN)) |-> (!REN && !WEN && !CEN) [*10]

else assert “SRAM HAS ILLEGAL WEN,REN or CEN state” after RESETN is inactive”;



ASIC Debugging for High-speed SERDES

February 11, 2010

For those who wish to debug problems with the high-speed SERDES (serial – deserializers), one needs to follow some simple steps:

1) Obtain and read the technical specifications of the IP provider.

2) Obtain the proprietary serial control register information which usually consists of internal resets, register shifting and loading, and other specialized control of the PHY, which is the physical analog portion of the high-speed IO.

3) Obtain a high-speed digitizing scope such as the Agilent Infinum with a 13 GHz sampling rate.

4) Obtain a device to interface to the serial control register of the PHY.

a) One can obtain it from the IP provider


b) Build your own using USB to serial control register protocol.

5) Next, determine the special BIST modes to isolate the indeterminate areas of the PHY.

a) IO loopback – to take the receive and output back onto the transmit IO.

b) Receive clock loopback – to take the CDR (clock data recovery) and output the clock back onto the transmit IO to observe the capability of the CDR.

c) Parallel loopback to verify the serializer-deserializer path to the digital interface is working properly.

d) Serial loopback to verify the internal BIST modes of transmitting data streams and checking the received data streams.

See sample diagram below for the special loopback structures:



Once the various BIST modes are run, one can tabulate the data and determine the appropriate area of failure.



Then based upon the tabular information one can draw conclusions about failures in the PHY.

ASIC Backend Design Tip : Primetime OCV

February 10, 2010

The purpose of the Synopsys Primetime tool is to analyze timing delays due to the inherent physical delay of the CMOS gate and due to the timing delays that interconnect the CMOS gates together.

Additionally, Primetime is used to analyze “derating” factors which can affect the localized area of the semiconductor chip due to number of gate delays and wiring. Traditionally, the old method was to “derate” the entire cell set which means all the cell delays would be delayed by say a factor of 0.9. This was overly pessimistic and did not accurately reflect the true delays. Over design will result in longer design cycles by trying to overcome an obstacle which cannot be overcome.

Instead, the current methodology is to use “context-specific” derating values which result in more accurate timing and shorter design cycle.

This applies only to 90nm and 65nm. It does not substitute for statistical static timing analysis.

See table below:

Primetime OCV Modeling

The methodology to apply for OCV is to perform graph-based OCV and then collect violating paths to perform path-based OCV.

See table comparing graph-based OCV to path-based OCV:

Graph versus Path AOCVM

Graph versus Path AOCVM Table