| |
|
|
 |
| |
 | |  | | | | | Interview: Logic designers expand horizons
Nimish Modi
Cadence Design Systems | |
| |  | |  |
Interview with Nimish Modi, Cadence: Logic designers expand horizons
Cdnusers spoke with Nimish Modi, Manager of the Cadence Front-End Design Group. Nimish is also the executive sponsor of the Cadence Logic Design Team Solution—a cross-divisional effort that covers all of the technologies from the Encounter and Incisive platforms relevant to logic design. He has more than 20 years of experience in logic design, verification, and management and, thus, has a good understanding of EDA design challenges and needs
cdnusers: Nimish, what did you do before you joined Cadence?
Nimish: I was involved in various aspects of microprocessor design at Intel for 18 years in both technical and management roles. I started off as a logic and verification engineer on the i486 and Pentium processors; when I left Intel I was responsible for the development of all of Intel’s server processors
cdnusers: You have been in logic design a long time. What is happening in the market today that is different?
Nimish: I believe that we’ve reached an inflection point in the way chips are designed. Traditional design methods are no longer adequate to address the challenges created by the increasing integration of heterogeneous complexity and the migration to advanced process geometries. Because of this, traditional methods almost invariably result in the compromise of one or more of the chip’s performance, predictability, power, or productivity goals.
Going forward, I believe that these issues need to be addressed much earlier in the design cycle, namely at the design creation or logic design stage. This will require a change in mindset by logic designers as well as changes in the toolkit that they use to address their design problems.
At Cadence, we are developing a methodology that takes a holistic view of logic design and provides flow-based solutions. Our customers need this capability as they migrate more heavily to 45 nanometers and beyond.
cdnusers: Let’s back up a minute. What is your definition of logic design?
Nimish: Strictly speaking, logic design consists of transforming an architectural or micro-architecture specification into an executable format that represents the logic function of the device. However, in today’s world, that definition is too narrow. Due to the challenges I talked about earlier, logic designers not only have to consider the design creation piece but also a component of the verification piece and a component of the design implementation piece. This is because the RTL (register transfer language) or the HDL (hardware description language) representation needs to be verified by a logic designer as meeting certain targets for functional correctness and coverage before it is handed over to the verification experts. Similarly, the synthesized netlist needs to meet certain implementation checks—be it timing, power, test, etc.—before it’s handed over to the physical designer. So in a sense, today’s logic designer has to be part verification engineer and part physical designer as well.
cdnusers: Can you tell us more about the implementation piece in this context?
Nimish: Twenty years ago, as a logic designer, my primary concern and responsibility was to generate a functional RTL. Then I handed it over to the implementation team who was responsible for iterating through the design at the back end, achieving convergence, and taping it out. Today, in contrast, it is virtually impossible for an implementation engineer to be held solely responsible for convergence. If we followed the paradigm we did 20 years ago and just handed over the functional RTL to the implementation engineer, he or she could spin around for an inordinate amount of time before converging. And, in some cases, the delta may be so high that the design may never converge.
As a result, the onus of convergence has moved up the design chain so, now, the logic designer needs to be responsible for both the functionality and for ensuring that their design is created and structured so that it will meet other critical design goals such as power, timing, and test.
cdnusers: So it seems the logic designer has to take a holistic approach—toward both the logic design and in anticipating the problems the implementation engineer will face.
Nimish: Exactly. There are two dimensions here. As mentioned, the logic designer needs to have an appreciation for the flow from beginning to end, so not only is the functionality right, but the stage is set so the chip can actually converge on all its other critical goals.
Secondly, it’s not enough to “design for test” or “design for power” in isolation. If you do, you may end up achieving a specific goal—say test—and then realize you have totally blown your power budget. It’s a bit like that kids’ game where gophers pop up in a field—you whack one on the head with a hammer and he disappears while at the same time another one pops up from some place else. In the case of logic design, we want to ensure that every gopher—be it timing, area, power, etc. —disappears and never pops up again. To make this happen, we have to move from a “design for” paradigm to a “design with” paradigm, in which there is a concurrent analysis and design capability that takes an overarching view of the various goals that need to be met.
cdnusers: Can you tell us more about the implementation piece in this context?
Nimish: Basically, it includes front-end tools woven in an inter-optimized flow that allows logic designers to step away from a silo tool-flow and take a holistic approach toward their design goals. The goal of the solution and the “design with” paradigm is to do concurrent, automated design via a solution that is targeted up the design stack and aimed at the logic designer.
The Cadence Logic Design Team Solution is made up of six vectors:
Design with Verification
Design with Power
Design with Test
Design with Physical
Design Logic Signoff
Design Management
Design with Verification is built on the principle that the earliest bug is the cheapest bug. The flow provides the designer with targeted capabilities to do early verification, getting a jumpstart on complex bugs early in the cycle.
Design with Power provides the ability to do early analysis, design, and verification of low-power features—and, as we know, power is a big, big problem today.
Design with Test facilitates the integration of test into the design creation phase. This is important as there is growing evidence that “post processing” test into the design can lead to non-trivial timing and power issues.
Design with Physical allows the logic designer to comprehend physical data into the synthesis flow, thereby reducing the number of back-end iterations and enabling faster timing convergence.
Design Logic Signoff formalizes handoff to the back-end or implementation designers. Currently, this handoff is done in an ad hoc manner with no standard set of “checks” followed. This capability enables a formalized and consistent handoff that improves quality and facilitates closure.
Design Management provides an automated plan- and metrics-driven mechanism to enhance design predictability. Existing Cadence vManager technology focuses on the verification piece. Design Management enhances that capability to comprehend all other components of a design—it enables not only logic designers, but also their managers and executives to get a concrete metrics-driven indicator as to where a design is in the cycle. It also enables designers to make adjustments as necessary to get back on track if they are derailed.
cdnusers: Thank you, Nimish. Can you tell us what do you do to relieve stress after a day’s work?
Nimish: I do a variety of things. I have two young kids, and I like spending a lot of time horsing around with them. I am a big-dog guy and have a large German Shepherd that I spend a lot of time with as well. Also, I am a voracious reader, primarily fiction.
cdnusers: Where do you do your best thinking about logic design?
Nimish: You know, I don’t really have a favorite spot or time for doing my best thinking. Good ideas come up anywhere and anytime. I guess I am subconsciously thinking about work because I could be watching a TV show, or taking a shower, or taking the dog for a walk and boom—all of a sudden a gem of an idea pops up. I just wish they would pop up more often.
| 
About the author
Nimish, who joined Cadence in 2006, is a Corporate Vice President leading the front-end design R&D group. In this role, he is responsible for the Encounter Synthesis, Test, and Conformal product lines and the Cadence Logic Design Team Solution. Prior to joining Cadence, Nimish was at Intel for 18 years, engaged in microprocessor development in various technical and managerial roles. He was a member of the logic and validation teams on the i486, Pentium, and Pentium II processors; then he managed the Celeron project. When he left Intel, he was responsible for server CPU development, which included the Xeon and Itanium product lines. Nimish obtained a Bachelor of Engineering degree in Electrical Engineering from the University of Bombay and a Masters degree in Electrical Engineering from Virginia Tech. |
| |
This content has not yet been rated by other users |
|
|
|
|
|
|
|
|
|
|
| |
|
|
|