Multi-Core, Self-Test, Robots, World Domination

Fish Fry - January 21, 2011

by Amelia Dalton

In Fish Fry this week, Amelia introduces the fabulousness of the new EE Journal, checks out the new microcontroller-multi-core combo pack from NXP, and tries to sort out the future of chip manufacturing. Also this week, She interviews Kozio co-founder Joe Skazinski, announces a brand new super cool nerdy giveaway and referees a Robot Haiku Smackdown....and here’s a tip, keep listening until the very end...


Who is Going to Make Your Chip?

by Dick Selwood

It used to be that real men had fabs. The small number of companies designing chips also developed their own processes and built fabs for only a few tens of millions of dollars. If they had spare capacity they might also run other peoples’ designs through the fab. The fab price tag got bigger as processes chased Moore’s Law, the industry went through cycles of growth and contraction, and lots more people wanted to make chips. So companies were set up just to make chips. These are the foundries.


Between an ARM and a Hard Place

Fish Fry - January 14, 2011

by Amelia Dalton

In Fish Fry this week, Amelia examines the new ARM/Microsoft announcement, the squishy ownership of IP in today's electronic design and how the Verizon iPhone plan will affect smartphone users in the U.S.


Other People's Code

You down with OPC?

by Bryon Moyer

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.


Elephant in the Room

Synthesis and Place and Route Hold Keys to the Kingdom

by Kevin Morris

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.


The Donkey and the Engineer

by Jim Turley

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


From Conductor to Semi

by Bryon Moyer

“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.”


Timing Closure in 2011

What Is the Key?

by Ron Craig, Atrenta Inc. and Bob Smith, Magma Design Automation

[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?


Mentor Graphics

Graphics Mentor

by Jim Turley

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.


Head in the Clouds

Altium Leads Another Design Tool Revolution

by Kevin Morris

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.


To Err Is Universal

by Bryon Moyer

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.


Chips - Not Just For Kids

Fish Fry - December 10, 2010

by Amelia Dalton

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.


Statistical Variation

by Dick Selwood

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.


Visualization for Chip Design

by Aditya Ramachandran, Synopsys

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 [1]. 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.


Calling All Plant Cars

Fish Fry - December 3, 2010

by Amelia Dalton

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.

subscribe to our eda newsletter

Login Required

In order to view this resource, you must log in to our site. Please sign in now.

If you don't already have an acount with us, registering is free and quick. Register now.

Sign In    Register