Design Article

IMG1

Predictable RTL, An Oxymoron?

Ramprasad Satagopan

8/25/2004 12:00 AM EDT

One of the many things that register transfer level (RTL) design engineers grapple with is predictability. But, what exactly is predictability?

Is it:   What I expect to work at 500 MHz ACTUALLY works at 500 MHz?
Or:     What I expect won't work at 500 MHz does NOT work at 500 MHz?
Or:     The design works at 500 MHz only for a PORTION of the design cycle?

Then, who takes responsibility for the unpredictable? Is it the designer who wrote RTL that cannot close timing? Is it the computer aided design (CAD) engineer who runs synthesis and place and route? Is it the CAD vendor whose tool gives different results in every version of RTL?

Philosophical as it may seem, the fact remains that in a design cycle many things change simultaneously. Predictably. RTL is in a constant state of flux—as features are added, bugs are resolved, and bugs then become features. What everyone considered reusable intellectual property (IP) ended up being redesigned IP. The wafer fab, in order to improve yields, made some subtle changes to the design rules, which resulted in some not-so subtle changes to the overall timing. And of course, the electronic design automation (EDA) vendor released a new revision of their software, which had a varying degree of impact on the chip implementation.

Where does all this leave the timing closure team? In tears, maybe. Working weekends, certainly. Predictably. This happens in every design cycle.

Is there a method to navigate through this madness? History tells us that "divide and conquer" is a strategy that wins quite often. Predictably. Logic designers appreciate this when they traverse a karnaugh map—just one variable changes in each hop.

Can we divide and conquer our way to timing closure? During a design cycle, if at any point in time the RTL designer is solving only one set of problems relating to timing closure, and slowly eliminating one variable at a time, can this be deemed a predictable design cycle? What factors need elimination in a systematic manner?

Library issues. Does the designer have a poorly designed library? (Believe me, these do exist. Even today!) And most people do not realize that their library was designed with Halloween in mind—scary is the word for it.

With IP blocks, the IP vendor has a give and take policy: the RTL designer gives and the IP vendor takes—on parameters such as the access time to important macros in the design. How much are IP-related timing paths limiting the design?

What about the floorplan—is the chip on low carbs? Or, are most of the blocks tall, skinny, and shapely as opposed to big-fat-square structures? Shape is important, you see.

What about misbehaving tools? Application engineers at EDA companies do need a time-out once in a while.

And finally, there's the RTL itself. Is the design adequately pipelined? Is this part of the solution, or part of the problem? If the design system has a warning alert for many of these issues in a step-wise manner, is that a predictable design flow?

What must a predictable design system contain? It should have an elaborate library analysis engine that provides insight into issues with the library. It should also have an early silicon feasibility reporting mechanism that alerts the RTL designer if his design is not achievable, so he can add pipeline stages to the design. And it should have an ability to ease the impact of a real floorplan by allowing quick creation of preliminary floorplans to study the impact of placement, loading, and buffering on logic structures in the design. Plus, it should allow designers to sidestep issues relating to incomplete design data, such as third-party IP and/or constraints.

A system that can do this should be intensely aware of physical design issues right from the word "go". It has to be an integrated solution that spans from the entire RTL to GDSII design flow. It should allow the designer to traverse the design space one step at a time. And importantly, it should provide adequate debug hints to where the real problem lies throughout the flow. And, it should do this Predictably for a wide range of design styles.


About the Author
Ramprasad Satagopan manages an applications engineering team which is responsible for Magma's front-end products. His technical interests are primarily in the areas of Physical Synthesis and Low Power design. Prior to Magma, he held various design and design management positions at leading semiconductor and systems companies. And, quite predictably, he has suffered from the pain of timing closure imposed by archaic design methodologies! His email address is ramp@magma-da.com.


print

email

rss

Bookmark and Share

Joinpost comment




Please sign in to post comment

Navigate to related information

Most Popular

Product Parts Search

Enter part number or keyword
PartsSearch


FeedbackForm