Subscribe

Follow Synopsys

Follow the Author

Categories

About

I'll write about the crafting of optimization software for integrated circuit design. There is a unique joy and struggle in building something that must aim at perfection yet never achieve it. My secret goal is to share the excitement so other programmers decide to join me.

The Author

Brent Gregory

I've been writing software for fun since 1975, and at Synopsys since 1987. When I'm not coding, I manage an amazing team of software engineers who invent algorithms to solve the hardest problems in computer science. I mainly work on the tools that read a user's description of an integrated circuit, and compile it into the billions of polygons that implement the function in silicon.

Determine the critical properties of the software that drive purchase decisions.

Understand the link between your software and revenue.

3

Get a job in a department where you can affect those critical properties.

Go where you can have the most impact.

4

Find or build a system that measures the critical properties.

Measuring is the first step toward improving.

5

Write code that improves the measurements of critical properties.

This is how you add value.

6

Deliver your improvements to customers, and ensure they see the benefits.

This is how your value is realized.

7

Review your progress, and adjust.

Feedback loops drive improvement.

I use these steps every day. I work at a company that sells the software that creates integrated circuits. Some critical properties are the run time of the software, and the clock frequency and power dissipation of the integrated circuits. I use a suite of realistic test cases to guide improvements to the critical properties. When a project looks like a winner on the internal tests, I take it to customers to see how it works in the real world. At every step, feedback loops keep things on track, and revenue is the ultimate feedback.

I developed these steps based on my experience working at Synopsys. They might also work in other industries. I think they work especially well at Synopsys because integrated circuit success is exquisitely tied to a set of crisply measurable critical properties, and those properties are driven by the quality of the algorithms we create.

43% of assumptions are incorrect.
87% of perceptions are distorted by cognitive bias.
52% of statistics are made up.

With so much wrong-headed confusion, how do we tell which way to go?

Experiments. I love experiments.

Pinewood Derby is a competition where kids build 7-inch (18 cm) cars and race them down an inclined track. Theories abound: Weight concentrated in the front will pull the car faster. Balance the weight at the center for better stability. Put the weight in the rear for more potential energy. After endless arguments, I built a car with moveable weight and let everyone see for themselves which placement gives the fastest car. (The experiment showed that the center of gravity should be about 1-inch (2 cm) ahead of the rear axle.)

Good experiments cut through the intellectual fog created by wrong assumptions and biased perceptions to show what really works. Nowhere is this process more clear than Electronic Design Automation (EDA), the Grand Central Station of NP-Complete problems. The problems are NP-Complete and very large, so optimality is often out of reach. But, some algorithms get closer to optimum than others. Picking the best triggers heated debate.

All key EDA decisions are settled by experiment. Which vendor has the best tool? Run a benchmark. Which settings should we give to the EDA tool? Try them all, and pick the best. Which algorithm should we use inside the tool? Run many experiments to see what works best.

If you’re a programmer like me, then all this focus on experiments is a win. I have to write good software. But, I don’t have to spend much energy convincing other people that it is good. The experiments do that for me.

What is your seniority? How well-known are you? How convincing is your rhetoric? It doesn’t matter if you work in area where success is governed by experiments. The only thing that matters is: How good is your software? I love working in that kind of environment. Interested?

You do this every day: You have three errands: Bakery, Library and Store. You pick the order with the shortest travel distance (Store -> Bakery -> Library) or (Library -> Store -> Bakery), etc. Congratulations: You just solved the NP-Complete problem called “Traveling Salesman”.

Any NP-Complete problem can be solved by comparing all possible answers, and picking the best. With three destinations, there are six answers to compare (abc, acb, bac, bca, cab, cba). A human could compare all the answers for up to seven destinations. A computer: About 15 destinations. With 60 destinations, there are more answers than there are atoms in the universe. This kind of analysis leads many to classify NP-Complete problems as intractable.

Yet, a team in 2004 found the optimal tour of the 24,978 cities in Sweden with (only) 8 years of computation time. In 2006, they cracked a 85,900 destination problem using 136 computer-years. A plot of the history of these breakthroughs hints at a 10x improvement in solvable destinations every decade. This is surprisingly good progress for an “intractable” problem.

Some of this improvement can be credited to faster and more abundant computers. But, most comes from clever algorithms that eliminate sub-optimal answers without exhaustively checking them.

Can we declare victory? In many fields, we can solve the NP-Complete problems that are important to everyday life. That is why people make up fanciful problems like visiting all the cities in Sweden. But, Integrated Circuit (IC) design presents real problems that remain past the reach of optimal algorithms.

For example, ICs have millions of registers each placed at a different location on a rectangle of silicon. IC designers must find an order to connect these registers in a chain using as little wire as possible. (Oh, and they want an answer in a few minutes, not years.) This is the same problem as finding the best order to visit cities, so IC optimality is beyond our reach for now. In another decade or two, we’ll probably solve million destination problems, but then ICs will have 100s of millions of registers. NP-Complete is not quite solved yet.

Traveling Salesman is one of many NP-Complete problems faced by IC design software every day. At Synopsys, we solve some optimally, and others with close-to-optimum algorithms. There’s fascinating work to increase the pool of problems we solve optimally and narrow the gap for problems we’ve not yet licked. The work is both interesting and a good business because IC designers want the best possible ICs, and so will buy the software that delivers the best results. Interested?

I have the best job in all of computer science: I solve NP-Complete problems. “But”, I hear you say, “NP-Complete means ‘can’t be solved’”. Yes. That’s what makes it so fun.

I build the software used to create integrated circuits. This is a field thick with NP-Complete problems. Determine where to place the components on a slab of silicon to minimize interconnect delay: NP-Complete. Determine which of the millions of components use high-power logic (fast but battery draining) versus more battery-friendly low-power logic. Pick a route for all the wires that hook up the components: NP-Complete. And, the granddaddy of all NP-complete problems: Does there exist an input where the Boolean logic network gets the wrong answer (satisfiability). I could go on.

I work in a multi-billion dollar industry (called Electronic Design Automation, or EDA), charged with solving the world’s toughest software problems. The success of every electronic device from cell phones to network switches to computers, hinges on EDA.

How do I do it? A bear charges a pair of campers. The first camper starts to put on his running shoes. “You can’t outrun a bear,” observes the second camper. The first camper replies, “I don’t have to outrun the bear. I have to outrun you.”

I don’t have to solve these NP-Complete problems. I have to outrun everyone else trying to solve to these problems. That means compared to anyone else’s software, mine must generate integrated circuits that are faster, have longer battery life, have fewer bugs, and are easier to manufacture. Because we can’t reach the optimum, the race never ends.

My company, Synopsys, is racing ahead. For example, most of the electronics that brings you this message were created with Synopsys software. But, the competition is fierce and integrated circuits evolve quickly. There is always a drive to do better. That brings me to why I’m writing this. I need help. I need smart and creative engineers to make the next generation of EDA software. This kind of software is not for the casual programmer. Getting to the optimum is impossible, but getting closer than anyone else is matter of superior intelligence, creativity and raw software skill. Interested?