Friday, October 23, 2009

ARM Osprey @ 2 GHz

I am sure this is old news for a lot of you folks. This Cortex-A9 processor release is a direct competetor to Intel ATOM and is geared for the netbook segment. This is the first time ARM seems to deviate away from their core business model of focussing primarily on Low Power processors for Mobile handheld to processors targeting bleeding edge performance.

This time around ARM has released a physical IP Implementation called Osprey running @ 2 GHz. They claim that this processor is 1/3 the size of ATOM in the TSMC 40G process and consumes less then half as much power. Not sure if anyone will license and use the physical IP as such in an SOC. Most ARM licensees (TI, Samsung, Nvidia, broadcom, qualcomm) currently license the soft IP and implement the core physically (in silicon) using EDA tools from Synopsys, Cadence, Mentor and Magma.

These are interesting times in the design community using ARM IP. They dont have much work left than pack a few boxes after paying a few million quid to ARM :).

Only time will tell if the strategy for ARM of taking on Intel headon (well not really!, throw in a few qualcomm's, TI's, broadcoms and samsung's in there!) will materialize as this core cannot run a full fledged desktop operating system like windows XP. It runs windows Mobile and Linux OS.

Kudos to their processor architecture, hardware design and software teams for taking Intel Head on in the new application processor space....

Friday, October 16, 2009

Does global mode hold fixing make sense?

Yes :
-----
1. It's supported in most CAD tools.
2. Optimizations are still ongoing in the physical design flow.
3. A lot of hold buffers can be inserted in the data base quite easily before it is routed.
4. This would reduce subsequent eco size post route and would enable quicker and easier converge on remaining hold violations and DRC.

No:
---
1. A Huge number of Hold Buffers are added. This will contribute to a lot more power and area.
2. Elmore metric has some serious limitations in terms of accuracy.
Emperically it has been observed that elmore delay is way off for nodes close to the driving point.

If a CAD flow can support fast and efficient ECO routing and DRC cleanup, would just do it post route to avoid over designing.

Since we dont live in a ideal world, most people end up fixing hold in global mode which is far from optimal especially in the smaller technology nodes. (we end up overbuffering by atleast 40-60% using elmore delay model in 45nm).

Friday, April 24, 2009

High performance ARM cores and CAD Reference methodology

It is quite funny the kind of deliverables (reference methodology) a few CAD vendors (in the top four) provide to customers as a reference methodology (RM) for Implementing a high performance ARM core.

1. Sometimes the RM is incomplete
2. The vendor never managed to get even within 50-100 MHz of the performance quoted by ARM in their data sheet(including OCV and SI).
3. The vendor used unreasonable OCV and SI targets to get to the desired frequency.
4. The methodology has formal verification Issues
5. There is no mention of a Hold Margin during hold fix. In this day and age people sign off with a hold margin in PT with quite pessimistic OCV and SI settings.

I am referring to a quick TAT ASIC EDA flow using standard TSMC libraries to achieve frequencies quoted by ARM in the data sheets.

Extra effort and customization might be required to push it over and above the frequency quoted by ARM for an ASIC methodology, which is understandable and reasonable.

Otherwise it fails to satisy the objective of the core (it being an IP) and the amount of money and time which a company has to invest in trying to implement the IP.

Do tell us what your positive/negative experiences have been if u have worked on an ARM core and if a CAD methodology/vendor has really helped boost performance of your core in the past.

It is time that ARM started promoting 1-2 vendors over others if in fact they feel that TAT can be reduced as a result of changing the vendor in order to achieve the desired performance on the core.

Although this does not satisfy the criteria of an ideal IP, who cares as long as people get what they want!

Friday, February 29, 2008

It's Raining Buffers!!

Shrinking feature sizes->increasing die sizes->faster clocks->interconnect density->reducing supply voltages->Overbuffering? (courtesy: Henny Penny).

well..I will trust henny penny and be his humble devotee. Will I end up with higher area and more power consuming silicon? The CAD guys will tell me that my buffer counts are realistic. Buffering under elmore delay model can be off by as much as 200% in comparison to SPICE. Buffer/inverter counts can no longer be evaluated as a percentage of total gate count.

what are metrics for buffer estimation which we can rely on in the 45 and 65nm realm?

while there's more to follow in this article..Industry veterans out there, let us know your thoughts/metrics you have used and are currently using to prove the CAD guys wrong.