You down with OPC?
Ownership is a big thing for an engineer. When you’re done with a project, you can stand back and state proudly, “I made that!”
Well, it used to be that simple. Perhaps now it’s more like, “See your TV? Well, it needs backlights to work and those backlights are divided into zones and something has to decide how to light the zones to keep power usage down and there’s a big chip that controls a lot of this stuff and a portion of the chip handles the zones and that portion has to talk to the rest of the chip over a complex interface, and that interface is really really important for the picture to look good. So, that interface? I made that! OK, I didn’t actually make it, but I designed it!”
Ownership is good. If you’re going to put your name on it, you want to make sure it’s going to be good. Stated conversely, if you want it done right, do it yourself.
Synthesis and Place and Route Hold Keys to the Kingdom
I got a note a few weeks ago from an engineering student: “Why does it take so long to compile my FPGA design?” This twitter-esque brevity led me to semi-consciously fire off some half-helpful standard response, to which the student replied: “My other projects... seem to compile almost immediately, but the FPGA takes forever.” A layer of the onion had peeled back. This was a student who was approaching HDL as just another programming language. To him, the step of synthesis-and-place-and-route was just another “compiler,” and he couldn’t understand why this compiler took so much longer to do its work than, say, gcc.
“Freedom!” — Mel Gibson, Braveheart
Freedom is a good thing, right? Whether it’s political, design, or economic freedom, we generally believe that more freedom—more flexibility to make choices—is unequivocally a good thing to have. You can never have too much freedom.
But is that really true, even for design engineers? At the far end of the political spectrum, extreme freedom is called anarchy: the complete absence of control. And most people use the word anarchy in a bad sense, so maybe there is such a thing as too much freedom. Total economic freedom, such as the type Ayn Rand espoused, also tends to divide opinions. Some see it as the triumph of personal will and responsibility, while others view it as economic oppression. Entire governments have been formed (and toppled) on such questions.
“So why do you think you’re right for this job?
“Well, it’s pretty much exactly what I’ve done for the last 10 years. We were almost done with something just like what you’re about to develop when the economy tanked and the project got canceled.”
“Hmmm… OK, which defrumpitation algorithm did you use?”
“Well, we started with the FTL-25 open-source algorithm…”
“OK, good, that’s what we’re using…”
“… yeah, but we found that performance was horrible – it’s really inefficiently put together. We pretty much had to develop a new one from scratch. It took a lot of tries to get it just right – it’s not obvious – but we managed it. We were going to publish the results, but it all got packed up before we had a chance to.”
What Is the Key?
[Editor’s note: Atrenta’s Ron Craig and Magma’s Bob Smith got together to provide two viewpoints on what is going to be most important for timing closure in 2011. What follow are their thoughts.]
What is timing closure in the 2011 SoC design environment? Ron Craig, Senior Marketing Manager, Atrenta Inc.
Backend timing closure is an incredibly inefficient process, fraught with uncertainty. In an ideal world, an engineer would need to run a single pass through the synthesis to GDSII flow and he'd be done. But the reality isn't that simple. I've heard stories from well-known companies of up to 20 backend iterations to close timing, with each iteration taking up to a week. Evidence such as this would suggest that timing closure in the backend is no longer working – that this “tortoise” will indeed eventually get there, but at what cost? Is there a way to add certainty to the process?
Engineers of a certain age will remember when Mentor Graphics made engineering workstations. Remember those? They were overpriced computers with big monitors that every self-respecting hardware or software designer had on his/her desk, as opposed to a Windows or Macintosh machine that marked you as a receptionist, or worse, a marketing dweeb.
Mentor was just one of many companies making engineering workstations, including Apollo, Daisy, Intergraph, and Sun Microsystems. Remember them? Unlike most of its competitors, however, Mentor Graphics survived. Flourished, even. Mentor is now a big embedded-development company with all kinds of spiffy technology to help hardware and software designers.
Altium Leads Another Design Tool Revolution
Nick Martin, the founder of EDA’s most unconventional company, Altium, Ltd., is not afraid of being different. Since 1985 when the company (formerly known as Protel) released its first EDA tool, Nick and his growing band of nerdy rebels have been challenging the status quo in electronic design automation. The company has always had the philosophy of giving the individual engineer the tools he or she needs to get their job done, without the barriers of cost and access posed by traditional EDA.
Nick’s vision has always extended beyond the here and now. The self-appointed vanguard of the constantly moving target of innovation has capitalized on the company’s unique circumstances and culture to produce products and services that track dangerously close to that bleeding-edge of engineering design - where the concepts embodied by the design tool flow are just a little ahead of the mainstream engineering crowd, but well within view of forward-thinking designers.
Listening to Alexander Pope (and even Seneca and Cicero long before), you would think that erring is a particularly human trait. Taken out of the original context (which places human fallibility in contrast to the divinity of forgiveness or the diabolicalness of persisting in erring), you might feel singled out by nature as a particularly unreliable entity.
In fact, we are surrounded by errors. They happen all the time. We are but a wee part of a huge, interconnected, error-prone system. Our very existence is a testament to the ability of living forms to survive any number of errors that might occur. The more we study genetics and the geological history of our planet, the more we learn about the range of redundant systems and adaptations that have evolved to bring us this far. (Or, looked at from an anthropic perspective, that had to evolve to get us this far.)
With a few exceptions, however, the machines we humans create have no such adaptability. Whereas the natural world abides variation and randomness, we create deterministic systems that assume a relatively narrow range of operating conditions such that a given input will guarantee a correct output.
Fish Fry - December 10, 2010
In Fish Fry this week, Amelia examines where our chips come from, the new Xilinx (TI enhanced) DSP kit, statistical variations in semiconductor processes, and some seriously bad movie tech. Also this week, the nerdy giveaway is a Texas Instruments Wireless Watch Development Tool.
Your burger bun has seeds on it, and they look as though they are randomly placed, (I am sure that in the bun factory there is a standard procedure that says how many seeds should go on each bun, and this is accurate when averaged out across the buns.). If you put a large coin on the surface of your bun, how many seeds does it cover? Try somewhere else, and then somewhere else again. Each time you will get a slightly different number. Now try a small coin. The numbers will, it is likely, vary even more.
Now, instead of two dimensions, think three. And instead of a burger bun, think of the silicon in a 22nm technology, with sesame seeds as your dopant atoms. At this level we are looking at a very small number of atoms of dopant, and while the manufacturing procedure will have an average doping level across the entire device, two otherwise identical transistors will have different numbers of dopant atoms. In fact, one transistor in 22nm technology may have ten or even fewer dopant atoms, while another may have twenty, or even more. This is going to produce correspondingly different characteristics.
You’ve heard it a hundred times: “Lower the costs, complete the project on time and don’t make any mistakes.” This is the mantra of just about every product development organization in the world. Within the semiconductor industry this translates into lowering product lifecycle costs, getting designs taped out on time and avoiding bugs that require respins, according to a recent International Business Strategies (IBS) survey . Achieving these formidable objectives requires design teams to continue to improve design productivity and eliminate errors in their work product. An important component of improving productivity and reducing errors is having easy and real-time access to key project data that design teams can leverage into smarter decision making. At the same time, there’s increasing recognition that not only the technical leaders need consistent project visibility, but business and management leaders do as well. An unpredictable, poorly timed product release can have the same dire consequences as a very late one. Tools and/or processes that can automate and present a common, unbiased view of key project metrics to the entire team of project stakeholders are especially valuable. That’s where visualization can help.
Fish Fry - December 3, 2010
In Fish Fry this week, Amelia investigates the curious case of QuickLogic, Lattice Semiconductor’s new HiGig MAC IP Core, and Mercedes Benz’ new Biome concept car. Also this week, she announces the winner of the very first Fish Fry nerdy giveaway.
Why FPGAs Will Win
You probably remember the TV commercials. Two strangers randomly collide - co-mingling their confections in a fictitious fortuitous coincidence - giving the world the magic that is Reese’s Peanut Butter Cups. It’s a lie, but fact emerges from farce - chocolate and peanut butter make a very nice combination.
FPGA fabric and optimized circuit blocks make a very nice combination, too. Why settle for lower performance, lower density, and higher power consumption for the parts of your circuit that do not require the flexibility of FPGA fabric? Why pour concrete and lock down chunks of your design in hard-core cells that are likely to change or require multiple variants?
Several months ago, Cadence announced a strategy called EDA360. It was accompanied by a whitepaper that was eventually made public. It was, and is, billed as the brainchild of Cadence CMO John Bruggeman and was issued as a call to arms – a manifesto, even – to the EDA industry.And it caused a bit of a stir, some of it the kind Cadence would like, some less so.
Well, now that some time has passed to let everyone calm down some, seems like it might be good to come back to this topic in the hope that rational heads can prevail. What does this mean for Cadence and for the industry?
OK, that sounds way too generic. Here’s the real question people ask: is this just marketing hype or is there some substance behind it? The specific reason that question applies is that most examples given by Cadence about how EDA360 gets put into play involve pointing to products that have existed long before EDA360. Which almost makes it look like the strategy is really a repositioning of existing products.
Fish Fry - November 12, 2010
In this week's Fish Fry, Amelia takes on ARM Devcon, the Ultimate EDA tool, Lattice Semiconductor's new MachXO2, 50 caliber flash drives, and more...