Peggy Aycinena is a freelance journalist and Editor of EDA Confidential at www.aycinena.com. She can be reached at peggy at aycinena dot com.
June 25th, 2009 by Peggy Aycinena
One day I turned around and found Verification Methodology Manual for Low Power sitting on my desk. To be honest, I have no idea how I came to have this book, if it arrived in the mail or I somehow picked it up at a conference, but I noticed that Synopsys’ Janick Bergeron of Verification Guild fame was one of the authors, so I decided to look though it.
I’m not a verification expert, but as I had already decided to attend the Friday Functional Verification Tutorial on July 31st at DAC, organized by Andy Piziali (which includes Bergeron and IBM’s Avi Ziv), it seemed all the more appropriate to examine the book. Not surprisingly, it turned out to be a great read. At least the first several chapters.
Published in 2009, the authors include – in addition to Bergeron – Synopsys’ Srikanth Jadcherla, Renesas Technology’s Yoshio Inoue, and ARM’s David Flynn. The forward is written by Kelly Larson from Mediatech Wireless and includes this pearl of wisdom: Power always matters.
Previously, I’d been taught to believe: Verification always matters. But after perusing the book, I see the situation is far more complex. Now the reality is: Power and Verification always matter.
So, how do anxious designers go about meeting requisite verification and power goals, when their fundamental tasks are already daunting enough? I wish I could assure you that the authors of VMM for LP offer some comfort, but I cannot. Instead, the authors first give designers many reasons why power management is a problem (Density, Delivery, Leakage, and Lifetime), and then they propose a variety of solutions (including: multi-voltage control, clock gating, back bias, low Vdd standby, multi-rail retention, and state retention with power gating).
Unfortunately, the solutions are actually far more numerous than the previous parenthetical list would indicate, and the VMM for LP authors want designers to know that even when the many strategies are utilized, bugs sometimes creep in. More accurately, bugs always creep in.
Which is why when I got to Chapter 3: Power Management Bugs, my enthusiasm began to wane. There’s just so much to know, so many things to balance, isolate, optimize, minimize, maximize, and consider. It’s clear that “the path to low power design is paved with many errors that are not conventional logic failures [and] they are caused by a variety of reasons.”
Happily, just as I started to despair of mastering the content in VMM for LP, I discoverd Chapter 8: Rules & Guidelines. Exactly what the doctor ordered when it comes to helping designers know what’s what in VMM for LP. Here’s a summary of the concepts:
* Be safe. Don’t transition unless you can.
With a sigh of relief, I realized that VMM for LP is not unconquerable. It is instead a user-friendly handbook and tool for anyone who’s designing here in the 21st century. Better yet, having established that power management is tantamount to success in most designs today, and having established a cogent set of rules to achieve that success, the authors of VMM for LP admirably suggest designers re-think the problem in terms that mere mortals can more easily understand:
Think of a power management scheme in terms of a control system: a system that attempts to regulate the voltage of devices with power and energy as the end functions, and activity, thermal condition, and resource availability as inputs. A control system that has both hardware and software inputs and outputs. The control system view of the power management scheme greatly helps to understand the loop between voltage regulators (voltage sources), power management units (PMU), and functional blocks (controlees).
Clearly, VMM for LP is a companion book to the 2005 best-seller, Verification Methodology Manual for System Verilog (please tell me you already knew that), but the 2009 text is a winner all on its own:
The need for low power design is here to stay,
* Density – Amount of power consumed within an area, hence the heat dissipated in an area, which if left unchecked can lead to “fires and explosions.”
* Delivery – Relates to the amount of current that must be delivered at progressively lower supply voltages, and the ability to withstand current fluctuations; worsens as process technologies shrink.
* Leakage – Amount of current consumed by the chip when there’s no activity, which impacts battery life and regulatory issues related to Green design; also worsens with technology shrink.
* Lifetime – Decreasing reliability of chips due to higher current densities and subsequent material degradation.
June 18th, 2009 by Peggy Aycinena
When it comes to device physics, there’s a boatload of questions you could ask folks at DAC.
* Why didn’t we stop at 57 or 53.7, when we went from 65 to 45?
* If you stick a stack of die into a tiny plastic package, what does the heat sink look like that shuttles the heat out of the contraption?
* What are the specific electrical properties that distinguish high-k from low-k dielectrics?
* How hot can a laptop get before the devices at the heart of the thing are irreparably harmed, and why?
When it comes to the design flow, however, there’s only one question worth asking.
* Which tools are used, and in what order, to create a chip?
This single question makes any questions regarding device physics look like child’s play, which is why it’s exactly the question I’m setting out to answer when I go to DAC in July. Surely somebody there will have the answer. Surely somebody there will be able to tell me exactly which tools are strung together, end-to-end, to design a chip.
There will be designers at DAC; I’ll ask them. Surely they’ll know.
Better yet, I’ll ask the vendors. Surely they’ll know which tools are used upstream and downstream from their own tools. If I glue their answers together, end-to-end, I’ll get the solution.
Better still, I’ll ask the CAD tool managers. After all, they’re the ones responsible for supporting the flow, for making sure the tools actually work and can interoperate. Surely they’ll tell me. How hard can it be?
Wait – an even better idea. I’ll ask the VCs. They’re such experts, they’ll be able to tell me which tools are used, because they know which companies have market value. Surely they’ll know.
And, what about Senior Management? They love to answer questions. Surely they can answer this one.
So, there you go. I’m coming to DAC with a clipboard and a pen, determined to try to resolve the question although it may not be easy.
After all, it’s the job of the designers to get their chip designed. They’ll use whatever it takes, even if it includes a little tool here and there that they themselves have developed – or, heaven forbid, downloaded off of somebody’s HomeBrewTools.com website. The designers may want to keep that sort of thing a secret.
It’s the job of the vendors to provide the tools, and to make sure that John Q. Public thinks their tool is the only tool that can be used at a particular point in the flow: We actually have no competition in our technology niche.
Of course, it’s the job of the CAD guys to keep secrets, as well. If they reveal what string of tools they use, CAD guys from other design houses might copy them. In the world of CAD: String of Tools = Secret Sauce.
VCs and Senior Management? Look, those are the guys who invented NDA. VCs and Senior Management are nothing, if not all about secrets.
So, which tools are used, and in what order, to create a chip? Getting the answer, and the answer itself, is going to be complex.
I suspect I’ll find that the line of tools I’m attempting to unearth isn’t a line at all, but a multi-dimensional mesh of interconnected applications from a wildly interconnected set of vendors that’s devolved over time from a streamlined flow into a rat’s nest of confusion and overlap. I suspect I’ll discover that the answer to my question is not so much a String of Pearls, as a Web of Wonder. More accurately, not so much a String of Pearls as a Web of Bewilderment.
Device physics? Yep, that’s child’s play.
June 10th, 2009 by Peggy Aycinena
Raise your hand if you think Twitter’s really silly. Now raise your hand if you used to think Twitter was silly, but you’ve since changed your mind. That second group? That’s my group.
After registering for Twitter at John Blyer’s urging, way back in March, I didn’t think about it again until faced with the opportunity to Twitter about Chris Edward’s panel from the Exhibition Hall at DATE in April. What a hoot, and even better – what an easy way to make succinct notes that could be later recycled to produce content for EDA Weekly. After DATE, however, I didn’t think about Twitter again.
That was until the “XXX is now following you on Twitter!” messages started arriving in my email, which completely confused me. Why would anyone be following me on Twitter when I hadn’t posted anything of substance, hadn’t posted anything at all for weeks? It turns out that people on Twitter hunt for other people they know on Twitter and “follow” them in order to expand their own network. “Following” isn’t about me, it’s about them.
Meanwhile, I heard from Georgia Marzalek about somebody who posts whole recipes on Twitter, instructions in 140 characters or less sufficient to produce an entire dish. Meanwhile as well, I heard a comment from an EDA industry type that seemed distinctly dismissive of the EDA academic types, an unfortunate, ill-advised comment that rankled.
So, I added my lack of Tweets to the idea that lots of info could be packed into an itty bitty space, and combined that with the impression that the people connected to me on Twitter were mostly from EDA, plus my conviction that the academics and industry types together have created this industry, and voila!
The EDA Town & Gown Twitter Project
… was born. Why not commit 100 Days of Glory to profile 200 luminaries from EDA, half from industry and half of from academia? It took 140 seconds to decide to do it, and 140 minutes to prepare to launch it. Now 10 days and 2800 characters later, I’m completely enchanted by the effort. Like Twitter itself, The EDA T&G Twitter Project is a hoot and a holler.
Each day I pick two names from the treasure trove of people who have created, and continue to create, the stuff that makes this industry tick. I research their backgrounds, accomplishments, titles, and publications and create a 140-character bio. I try not to overlook any major data point on the luminary’s career trajectory and attempt to highlight, undoubtedly inaccurately at times, the most important of those points.
Here’s what I’ve learned so far:
* You’d be surprised how much info can be shoehorned into 140 characters. Yeah, a lot of stuff is left out, but if you compare my Bio Tweets to the full-blown bios, you’ll see my entries are pretty content heavy. You may need to already know something about the person being profiled, but the info is definitely there and decipherable.
* From the outset, I decided not to rank the contributors profiled in The EDA T&G Twitter Project. Someone profiled in June, for instance, is not more important than someone profiled in July. It’s a random selection process, period.
* It’s actually hard sometimes to find a full online profile of some of the people I’m researching. If they made the jump from academia to industry, or vice versa, well into their career, the arc of their professional history can be suprisingly difficult to track.
* I’m pretty sure most of the people profiled will be folks with PhD’s, people who have authentically added to the technology itself. That’s not to imply, of course, that Marketing, Sales, HR, Accounting, Finance, Reception, and PR aren’t also important, but in general the unique aspects of EDA have come from those who have done doctoral-level work. I may run out of PhD’s to profile before the 100 Days of Glory are up, and if that happens I’ll turn to other household names in EDA and happily profile them as well.
* The EDA T&G Twitter Project requires a daily commitment to production. Now that I’m fully into the project, I look forward each day to the task. I see it as an opportunity, not an obligation.
Meanwhile, I owe a debt to my kids in all of this. The oldest only responds to email or voice mail. The middle one responds only to posts on Facebook. The youngest, however, only responds to text messages. He’s the one who’s taught me to abandon grammar, spelling, and convention if I really want to cram information and nuance into 140 characters or less. Truly inspirational stuff for the author of The EDA T&G Twitter Project: