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).