Numetrics » 2010

Throughput, Not Productivity, is What Matters

Ron Collett — Thu, 16 Dec 2010 22:25:32 +0000

Discussions about R&D return-on-investment (RoI) among semiconductor industry executives often turn to engineering productivity. They’re often surprised when I assert that productivity isn’t that important—at least as far as R&D performance metrics are concerned. A far more important metric is engineering throughput.

Throughput measures rate of output and therefore quantifies how fast you develop products. Productivity measures how efficiently you develop them. Throughput is about cycle time. Productivity is about cost. The more productive your teams, the fewer engineers needed to develop products—hence the lower the development cost. But what’s more important, cost or time-to-market?

Throughput’s dimensions are “output per week.” For example, output quantified in “Design Units” yields Design Units per Week. Unlike productivity, throughput ignores the amount of manpower the team expends to create that output. It simply quantifies the output and divides it by the project’s duration (concept to release-to-production), measuring output per unit of time.

The distinction between throughput and productivity is important because time-to-market usually trumps all else. I’m not suggesting efficient development isn’t important, but throughput, and therefore time-to-market, is what usually generates the most revenue and profits.

R&D organizations can increase throughput on their projects in four ways: (1) by raising the average productivity among team members, which means executing tasks more efficiently and therefore expending less effort; (2) by increasing the number of hours in the standard work-week—not particularly popular among engineers, but one that often finds favor with management; (3) by eliminating low value-add activities that consume project resources, thereby increasing engineering resource utilization; and (4) by increasing the project’s staffing level.

The first two—increasing productivity and encouraging longer hours—rarely yield competitive advantage. That’s because nearly all R&D organizations pursue them (to survive), enabling them only to keep pace with the industry norm.

The latter two – increasing utilization and staffing—are the opportunities for differentiation and competitive advantage. Most companies are reluctant to pursue these insidious root causes of low throughput. That’s because eliminating non value-added tasks can be contentious and politically unpopular—nobody likes to hear their job has little value add. Likewise, increasing staffing level means taking on fewer projects, which can also be quite contentious and riddled with politics.

Originally published at: http://www.eetimes.com/electronics-blogs/other/4211451/Throughput–not-productivity–is-what-matters#

Comments

Me2

12/13/2010 5:16 PM EST

One of the buzz words I’ve heard in this realum is “Factory Physics” which is the scheduling of factory equipment such that WIP does not site waiting for a piece of equipment to be available. In other words, if a tool is working efficently, but the scheduling department is not scheduling correctly, throughput is affected. Nice article.

RCollett

12/13/2010 9:26 PM EST

@Me2,

Seems that Factory Physics is now an official discipline — quoting from the Kellogg School of Management website: “Factory Physics is a set of ‘laws’ representing the core science of lean manufacturing, which describe the underlying operations behavior of manufacturing systems, including the fundamental relationships between performance measures such as throughput, work-in-progress, manufacturing cycle time, and process variability. Taken together, these tools provide a firm scientific foundation for the practice of lean manufacturing.

Thanks for the comment.

Ron

daleste

12/13/2010 7:01 PM EST

I enjoyed your article. It brought to mind a couple of quotes from my past. A great leader once told me, “A good engineer will keep working on a new product until it is perfect. A great engineer knows when it is good enough to release to production.” When asked if adding more designers to the project would speed up the schedule, the design leader told me, “If it takes one woman 9 months to make a baby, how long does it take 5 women to do it?”

RCollett

12/13/2010 9:43 PM EST

@daleste,

I think you are alluding to the Mythical Man-Month, a book written by Frederick Brooks in 1975. Mr. Brooks’ book is best known for its formulation of Brooks’s Law: “Adding manpower to a late software project makes it later.”

However, allocating the correct number of engineers to a project from its outset is what I was referring to. In other words, staffing it correctly by ensuring that the staffing level is commensurate with the design’s complexity, which includes both the deterministic and stochastic aspects of design complexity.

Thanks for the comment.

Rgds,

Ron

Frank Eory

12/22/2010 3:38 PM EST

Ron, we have probably all experienced examples of Brooks’ Law — which applies just as well to hardware projects as to software projects.

The difficulty is how to accurately estimate the correct number of engineers and specific engineering skillsets to allocate to the project and when to add them.

Increasingly, project managers today either do not come up through engineering, or else their hands-on engineering development days were so long ago they are no longer relevant to today’s NPI processes and methodologies.

It seems to be an extraordinarily difficult task to make the correct assessment. The consequences of underestimating the resourcing needs is a missed schedule, which might mean a complete waste of an investment, and the consequence of overestimating the resources is excessive R&D cost.

These days, almost any manager will take the cost-conservative approach and assume that engineering will find a way to meet the schedule and make up for any project management/staffing shortcomings. Translation: They will also fall back to your Option 2 — expect engineering to work longer, harder and smarter.

RCollett

12/22/2010 6:06 PM EST

Frank,

Generating consistently reliable estimates of resources and schedule requires an empirically calibrated model whose inputs include (1) a description of the technical attributes of the design, (2) the likely performance range of the development team (best case to worst case), and any constraints on the project (i.e. schedule, staffing). The key to creating a good model is to have a wealth of project data. In the IC space, our models leverage an industry database of 1,600 production IC projects comprising 30,000 circuit blocks. Its predictive power is strong. The coefficient of determination is 0.93 (i.e. R-squared value) when we plot Estimated Project Effort vs. Actual Project Effort. Top semiconductor companies across the industry can vouch for its accuracy and efficacy.

Thanks for the comment.

Rgds,

Ron

no.name_#4

12/14/2010 5:22 AM EST

I think this article ties into EE Times 11/22/2010 “Semiconductor success is no longer about the chips, it’s about end customers”, with its emphasis on successful companies being product-centric.

In my 20+ yrs experience in various Semiconductor Fabs, the successful companies where successful in their time because they had a unique product/chip that was in demand. That demand in part was driven by economic realities but more so by an end-user purchasing decision for a product that was enabled by their unique product/chip.

Daring to have product R/D is daring to have a unique and market untested products (taking investment risks and investing back into the company). This takes vision and Steve Jobs best exemplifies this quality.

Now days, many companies prefer to follow behind a product acceptance cycle rather then lead it, with the idea they can predictably and with low risk do a same/similar product cheaper & faster. These companies don’t grow or create new markets they just go for shares of existing markets. As markets shifts, so do the fortunes of these companies shift.

There aren’t many Silicon Semi-Companies with significant new product R/D anymore (Intel, Apple, IBM, Toshiba) are the only ones that come to my limited mind. The others just seem to follow or just refine existing product lines (TI, Qualcom, National, Lucent…).

daleste

12/14/2010 12:37 PM EST

I agree that most companies spend most of their R&D making incremental improvements on existing products. This is the safest way to getting good return on investment. The “home run” product takes much more investment and is usually an unknown in the market place. It may be accepted and be wildly successful or it may be a dud and a waste of R&D resources. Very few companies want to take that kind of risk.

RCollett

12/14/2010 3:27 PM EST

@no.name_#4,

Not sure that the TI, Qualcomm, National and Lucent would agree with you that they merely follow or just refine existing product lines — I’ll let them weigh in on that if they care too. Notwithstanding that debate, your overall point is well taken — that pioneering new technologies, products and applications takes vision. It also takes money. The two go hand in hand.

On the money front, I believe that one of the core problems is that a lot resources are wasted on projects that should never have been started in the first place. This is money down the drain. Resources get spread too thin when companies take on too many projects. One of the primary reasons they take on too many is because they think they can finish them with fewer engineers than is possible. In sum, there is a misalignment between the design’s complexity and staffing level. I observe this first-hand every day of the week.

Thanks for your comment.

Rgds,

Ron

RCollett

12/18/2010 1:43 PM EST

@daleste,
With SoC development costs routinely ranging from $50M to $100M, it’s no surprise that few companies want to take on additional risk. Moreover, the consequence of such skyrocketing costs is that SoC product revenue must be much higher than in the past — to justify the investment. Sales must reach $250M to $500M, because the R&D RoI must be at least 5X. Achieving such revenue targets means the total market size must be at least $750M to $1.5B, because one must assume a maximum of only thirty to forty percent market share. There aren’t that many markets of that size. Bottom-line: participating in the SoC business means there is little if any margin for error. It requires picking the right market opportunities and hitting development schedule targets.
Rgds, Ron

jadesbox

1/11/2011 10:25 AM EST

“a lot resources are wasted on projects that should never have been started in the first place”

Indeed, but shall a project manager refuse a project he thinks would be a waste of the company’s money, or shall he accept such a challenge?

The choice is easy the first attitude would be detrimental to his career while the second would be beneficial unless it brings the company to bankrupcy.

RCollett

1/13/2011 8:03 PM EST

@jadesbox,

You have hit on what I believe is one of the most insidious problems in the semiconductor industry — the conflict of interest facing engineers and project managers. They accept projects that they know will not finish anywhere close to the target schedule. That’s because the staffing-level allocated to the project is inadequate, given the design’s complexity. What goes a long way toward solving the problem are fact-based estimates of resource requirements. When the organization has reliable estimates, far better decisions are made.

Thanks for the comment.

Ron

prabhakar_deosthali

12/21/2010 4:39 AM EST

Just when the new Millennium started, I was party to an innovative R & D project where my company after discovering that the product being developed had potentially a very revolutionary effect on the market, spent all its efforts in getting worldwide patents for the technology being developed but failed to provide enough R & D resources to bring the product to a level where it could be shown to have commercial viability. The company got the patents but could not get advantage of them. Millions of dollars were just wasted in the whole process. All the industrial giants who had shown interest in our technology could not get the sample prototypes in time and hence turned their back to us. Eventually the company went bankrupt with the patent power and the technology remaining only on the paper!

RCollett

12/22/2010 3:10 PM EST

Prabhaker,

Once the technology was patented, was an effort made to attract investors (i.e. VC’s, Angel investors, etc.). If not, why not? If so, then why did they choose not to invest.

Rgds,

Ron

RWatkins

12/22/2010 10:06 AM EST

As a member of a small design house that specializes in doing what others couldn’t… (just so my bias is clear) In 30+ years of engineering experience, sometimes as observer and sometimes as participant, I have come to believe that the incremental improvements are merely necessary for survival and maintenance of the status quo, while “pioneering new technologies” are what keeps jobs and income where the best engineers are. If all I do as an engineer is fine-tune a product BOM for cost, you might as well find a lower cost engineer in China to do the same job (as long as you don’t mind the learning curve as he substitutes parts that are too “cheap”). On the other hand, if you need a solution that has evaded in some cases generations of engineers that might be enabled by new technology and/or a lifetime of experience of a carefully observing practicing engineer, sending the product to a “high productivity” house will fail every time.

RCollett

12/22/2010 3:36 PM EST

@RWatkins,

I agree. What I think we’re talking about determining the primary opportunity for engineers and scientists based in the U.S. — to create products or offer services that are heavily differentiated from those that can be easily replicated in low-cost, off-shore regions of the world. How can it be otherwise? These are the “new technologies” to which you’re referring. They are the ones comprising higher value-add, and therefore they command a price premimum, which justfies the higher labor cost. In short, the U.S. engineering community must be able to differentiate itself from the engineering community in low-cost regions.

Also, small clarification to your point about a “high productivity house” — I’m sure you’ll agree that offshoring does not necessarily equate to high productivity. In fact, it’s probably the opposite. Instead, teh promise of offshoring is higher development-throughput, which is the the amount of output created in a given time period. The availability of low cost (off-shore) labor means more bodies can be thrown at the project, which usually (but not always) results in higher throughput.

Thanks for the comment.

Ron

In Search of Best-In-Class R&D Organizations Competition among semiconductor companies has become super-heated, and R&D...
Death of the SoC Rumors of the SoC’s impending death have been popping...
The Realities of IP Reuse Long touted as a silver bullet, IP reuse often...

Related posts brought to you by Yet Another Related Posts Plugin.

Falling IC development productivity means lost engineering jobs

Ron Collett — Wed, 01 Dec 2010 21:40:12 +0000

Bad news: Steadily declining IC development productivity means more job losses for engineers employed in first-world economies—e.g. U.S. and Europe. Those lost jobs are going to second-world economies because labor costs are much lower. Moreover, the trend is accelerating as chip design complexity outpaces gains in productivity. Don’t shoot the messenger for the message.

IC development productivity isn’t keeping pace with rising design complexity. The solution has been to increase team size—throw more resources at projects. Once that decision is made, the question quickly turns to choosing the geographical location to hire the new resources? Second-world economies that have a good base of technical professionals seem to be the logical choice, at least from the perspective of executive management.

It’s not that engineers in those countries are more productive than their counterparts in North America or Europe. Rather, it’s that they are significantly less expensive—four to eight times less expensive.

I expect the pace of job migration will quicken during the next few years because IC design complexity is non-linearly outpacing increases in productivity. There’s a triple effect happening here—team sizes are growing, off-shore development sites are maturing, and the financial cost of off-shore labor remains low. That’s all bad news for engineers in first-world economies.

If productivity kept pace with rising complexity, team size would be remaining constant. Off-shoring would nonetheless occur, because of the cost advantage. But it would happen at a slower rate—that was the situation 10 to 20 years ago. However, as off-shore development sites matured, and the cost and effectiveness of inter-site communications technology steadily improved, off-shoring became increasingly viable—and effective

Off-shoring of development was a competitive advantage for first movers. But today, it is rapidly losing that edge, because nearly all companies do it. So in most cases, it’s now a necessity in order to compete. If you’re paying four to eight times more for your resources, your cost structure is uncompetitive—even if your productivity is, say, twice as high.
Originally published at: http://www.eetimes.com/electronics-blogs/other/4211146/Falling-IC-development-productivity-means-lost-engineering-jobs

Comments

iniewski

12/1/2010 10:56 AM EST

Ron, agree, this has been unfortunate trend for a while (unfortunate for those in North America, others might think the opposite …interesting question that follows is: should we stop educating and producing IC designers? Kris

RCollett

12/2/2010 8:59 PM EST

Kris,

I hope not, but it begs the question: can a strong case be made for recommending to someone entering university to pursue a career in electrical engineering?

Rgds,

Ron

asicman78

12/2/2010 11:39 AM EST

I also agree, and as a 30-year old FPGA/ASIC engineer I wrestle everyday whether there is a future for me in this industry. In the 10-years I have been a professional engineer the whole time the sword of outsourcing has been hanging over my head.

It is illogical to blame the companies who are just trying to compete and grow. It would be malicious to blame the engineers in India, China or wherever as they are just trying to better their lives.

But as us young Engineers here in the U.S and Europe look toward the next 20 years, is the consensus now that we should start looking to transition into another industry?

If IC development leaves the U.S for good, doesn’t all the jobs that support those efforts leave as well. Semi Apps Engineers, EDA Apps Engineers, EDA developers, Test and Measurement, Verification, etc. At one point even moving project and product management closer to the developing teams makes sense.

I’ve always wanted to an engineer but I am slowly coming to the realization that I may not have the opportunity to stay one

RCollett

12/2/2010 8:59 PM EST

@asicman78,

From my perspective, it is unimaginable that all of the IC/ASIC engineering work will be off-shored. It’s axiomatic that skills that cannot be found off-shore will remain on-shore, and this includes both technical and management, including remote management of the off-shore team. I think that gaining skills in managing off-shore teams will find increasing demand in the coming years.

Thanks for your comment.

Ron

asicman

12/3/2010 3:33 PM EST

@Ron,

I agree that not all IC engineering work will be offshored. Of course companies could always address this by using H1-B engineers here in the US, increasing competition for jobs for native engineers and driving down salaries.

The sad thing is that no one will want to study engineering, I sure as heck would not recommend it to a high school student. What would you say? Go work your butt off in school, if you find a job you will make some good money but be prepared to work for 10-15 companies before you retire, and all the while the industry is consolidating R&D and Manufacturing overseas so you may end out in the cold. No, you may make less money doing something else but the peace of mind a different career will bring would more than make up for it.

As far as your recommendation, I am afraid to say that there will probably not be a management job for every displaced US engineer.

I love being an engineer, and I will try to stay one as long as I can, but I am not kidding myself about future.

RCollett

12/6/2010 3:51 PM EST

asicman,

Naturally there won’t be a management job for each engineer. Agreed.

However, I strongly believe that there will continue to be very substantial engineering opportunities in the U.S. The key I think is to offer significantly greater value-add than counterparts in the low-cost regions. This includes technical skills and management skills. In other words, I think that the focus for today’s U.S-based engineer is to achieve differentiation by climbing further up the value chain.

Ron

Joel.Amzallag_#2

12/4/2010 7:06 PM EST

As a EE and father of high-school kids I am definitely trying as hard as I can to dissuade my kids to be engineers. The know-how is already there, the jobs to support IC development is already there and the marketing is starting to move as well.

RCollett

12/6/2010 4:01 PM EST

Joel,

I can fully understand your point.

On the other hand, I firmly believe that getting a technical degree will put your kids in a far better career position in the long term — e.g. math, science or engineering. I believe the problem-solving skills and intellectual acumuen gained through a technical degree are universally recognized by employers.

Rgds,

Ron

VincePG

12/5/2010 3:28 AM EST

20 years ago, EEs commanded the top salaries coming out of University. Now look what Yahoo recommends to the University bound: Actuary, Accountant, Medical Technical and Dental Hygienist. Software Engineer is still on the list, but it’s way down there. The 21st century is about technology and the US is training accountants and insurance agents. The middleclass is collapsing and the wealth is concentrated at the very top, while our public universities are starving. Something is terribly broken in this country.

iniewski

12/6/2010 4:08 PM EST

Ron: I disagree. Law or medical degree would be obviously much better. But today biz management pr marketing would beat technical degree by far. You need to like doing engineering to pursue this career. Following your passion is probably the best bet anyways, regardless of material compensation to be achieved in future years…Kris

RCollett

12/6/2010 8:05 PM EST

Kris,

I strongly agree that one must pursue their passion. But there is also the need to pick a career that ensures longterm employment and a decent salary. Naturaly, there has to be a balance. However, IMO, attention to “ensuring” longterm employment and good salary has never been more important than it is today. That’s because of the inexorable trend toward globalization. IMO a technical undergraduate degree followed by whatever graduate degree one chooses is the best possible combination, and one that increases the likelihood of long term employment and good compensation. No guarantees of course, just higher probability.

You mention that law/medical degrees would be better than engineering, but those are graduate degrees. Why not an undergraduate in engineering followed by either law or medicine? (BTW, that’s what I did — undergraduate EE and then law.)

As for business management, PR or marketing, which are all fine professions, I likewise believe an undergraduate technical degree followed by an MBA in one of these disciplines is the right way to go.

In sum, my hypothesis is this: (1) For new engineers entering the U.S. workforce, they should enter with a master degree. Why would I hire a EE new grad (undergraduate) when I could get one overseas for a fraction of the cost? (2)In order for the U.S. workforce to climb up the value chain, we need a lot more college graduates that have technical degrees, who then pursue Masters Degrees in whatever disclipline their passion leads them.

Ron

Code Monkey

12/6/2010 4:10 PM EST

If my kids want to be EEs, I’d advise them to learn Mandarin or Vietnamese because that’s what they’ll be speaking on the job.

Or, I can wait and see of the government stops selling us up the river.

RCollett

12/6/2010 8:17 PM EST

Code Monkey,

IMO, an EE (Masters) with fluency in Vietnamese or Mandarin (and English of course) would be quite valuable – throw in an MBA degree and I think you’ve got a very marketable combination.

In other words, for the U.S. to remain competitive, it must increase the skills and knowledge of the its workforce. The U.S. has the best and and largest number of graduate programs in the world. We must leverage this. We need to be graduating students from these programs that upon graduation will reside and remain in the U.S. A government policy that encourages this would be quite worthwhile. Thanks for your comment.

Rgds,

Ron

RCollett

12/6/2010 4:12 PM EST

Vince,

I certainly wouldn’t argue that things are broken in the U.S., but I think that the problem is that the U.S. needs to adapt to the new global playing field — e.g. that there is a tremendous amount of low-cost, competent engineering talent available at low-cost throughout the world. In order for the U.S. to compete and keep its population employed, the U.S. workforce must climb higher up the value-add chain. That entails a number of actions, one of which is far more technical training of our workforce, both in numbers of people and skill level.

Thanks for your comment.

Ron

mixed-signal

12/7/2010 9:57 AM EST

As frustrating as the performance of US companies and management has been over the last 10 or 15 years, electrical engineering is as engaging and fascinating field as ever. I understand the motivation to dissuade others from the field, but I can’t embrace it. Technology is too important and too rewarding to work with to give up on it.

The US still has huge advantages in education and skills in many areas, and there are many startups and smaller companies each year demonstrating this.

Things have changed, though, in terms of what matters most:
- IC design skills, digital or analog at least, are widely available. If you’re going to be only a circuit designer you’ll have a tough time competing. The competition is global, so you have to be on top of your game and do high quality work.
- RF design skills are still in relatively short supply.
- Robotics, connected systems (e.g. sensor networks), and biomedical devices are all seeing more investment and growth now than just “IC design.”
- The end product and system are more important than IC design, which is just one means to the ends. – Having a combination of skills that cover system or product design and IC / circuit design seems to be a better bet.

I for one would like to see the tone change away from “IC design design in the US is going away” to one more entrepreneurial, focused on the opportunities we have for exciting product development in mixed systems of RF, communications, embedded controllers, sensors, software, etc. Anyone capable of doing detailed IC design is probably capable of excelling in these related areas, as well, and positioned to make good design choices and trade-offs.

Things don’t remain the same forever, and the larger, older companies keep trying to do the same old thing with management that doesn’t care about the technology anymore (just numbers).

So, let’s get on with it and focus on where the opportunities are so we can keep doing exciting and innovative work.

RCollett

12/7/2010 3:57 PM EST

@mixed-signal,

Great points.

In addition, I think that the EE curriculum at the undergraduate level should include a mandatory overview course on “Business Practices” — it would provide a brief introduction to key topics, including finance, market strategy (e.g. segmentation), corporate structures (C, S, etc.), venture capital financiing, etc. I have no doubt that it would pay significant dividends to the individual, the industry, and the U.S. economy.

Thanks for your comments.

Rgds,

Ron

asicman

12/8/2010 2:41 PM EST

My plan and what I would advice to any 20-30 year old engineer and/or students looking into getting an engineer degree don’t and if you are in the industry then do your best to get out.

Just like the name of this blog ROI, the return on investment is just not worth. I urge them to be like the businesses that are sending the work overseas, try to get a much out of your money as you can. Killing yourself getting an engineering degree, taking on those loans, just to know that you have to do the same for grad school on another field just doesn’t seem right. Your 50-100K in the hole by the time you are done and the prospects and not everything they are cracked up to be.

You think all these other fields have it better? You think companies are not out there thinking how to ship these jobs overseas as well? Why have a manager here when the workers are over there? Why base the company here when 90% of the employees are in Asia? You think we will end up a country of CEOs, CTOs, corporate lawyers, etc.

The best advise I would give is to minimize your exposure to debt, in the end you will probably be happier with a 40K/yr job that will allow you to get some sleep at night. Do your engineering as hobby. The idea of a nation of MBAs is a joke.

RCollett

12/8/2010 8:03 PM EST

@asicman,

I believe dissuading someone who has the aptitude to earn an engineering or science degree from pursuing that path does that person a disservice. Not that many people have the intellectual capacity and stamina needed for it, and therefore, those that do have the ability will have an edge in the job market. Granted, they may need to pursue a graduate degree of some kind, as an undergraduate degree may not be enough, but those are the stakes that will be needed to compete in the world that’s emerging.

I certainly respect and understand your points, such as the high cost of getting a college education, which is a big problem that needs to be solved. However, your point about a $40K/year job doesn’t resonate with me. I don’t see too many people that can sleep well at night when they can’t make financial ends meet.

Lastly, not sure who is suggesting that the U.S. will or should be a nation of MBA’s. My point was that giving engineers a little bit of business training would be very helpful on numerous fronts.

Rgds,

Ron

asicman78

12/12/2010 1:36 AM EST

@Ron

So what do you tell engineers that are in their 30’s, 40’s, and 50’s with only a B.S.?

“Sorry about getting laid off? Don’t worry about the mortgage, rent, and finding a new job because even though you may have 10+ years of experience you don’t have a M.S or M.B.A”

How are we supposed to live, support our families, and accomplish this?

I have an exercise to anyone reading this.

1. Log on to linkedin.com and check out the profiles of engineers. I will guarantee you that you will find that less than half of them have had a job that’s lasted longer than 5 years at anyone given company within the last 10-15 years.

My point: Engineers are now commodities and like commodities we are used up and discarded when no longer needed. On top of the fact that foreign prices on these commodities are cheaper.

2. Log on the career website for any mid to large size company (Xilinx, Intel, Qualcomm, Broadcom, etc) count the number of engineering positions open in the continental U.S. Now run the same search but instead of the U.S. punch in their sites in China, India, etc. Finally, compare the numbers.

My point: I don’t have to dissuade people from becoming engineers, this will.

In the end Engineer is a tough and challenging career and one that I love, sadly it is no longer rewarding. Unless your niche is RF or Biomedical there is not going to be much work out there.

I have been lucky and haven’t had any long periods of unemployment in my short career, but I know this won’t last. There is nothing fueling engineering in the U.S. Defense money is going away, consumer has been on its way for the last 10 years. Biomedical won’t sustain on its own and neither will energy.

I wish I had the resources to go back to school get an M.S or an M.B.A. Maybe others will get lucky and survive, but as for me, you can chuck me up as one of the casualties of this brave new world.

And please if you see me at your local intersection with my cardboard sign, please drop me a dollar.

RCollett

12/22/2010 3:50 PM EST

@asicman78:

What I would tell engineers in their 30’s: gain experience by working in several different countries who’s engineering labor costs are likely to remain low.

Engineers in their 30’s or 40’s: go back to school for either additional training or in a field of science/engineering requiring skills not likely to be easily off-shored.

Engineers in their 50’s: Stay in the field as long as possible, save as much money as possible, and develop your post-engineering career plan.

Thanks for your comment.

Ron

In Search of Best-In-Class R&D Organizations Competition among semiconductor companies has become super-heated, and R&D...
The Elephant in the Corner Why do so many IC design teams commit to development...
Death of the SoC Rumors of the SoC’s impending death have been popping...

Related posts brought to you by Yet Another Related Posts Plugin.

Facts and Data vs Heuristics and Hope

Numetrics — Sat, 20 Nov 2010 13:01:20 +0000

During the next five years, a great many semiconductor companies will be faced with an increasing number of underperforming business units. Chances are they’ll be selling or spinning them off. Some chip companies, large and small, will disappear altogether. Why?

Persistently missed product development schedules—poor schedule predictability—is the culprit and bane of semiconductor companies. It is a pervasive problem in an industry whose R&D stakes are now excruciatingly high. Typical SoC development costs, for example, range from $50 million to $100 million (from design concept to release-to-production). With a target return of 5X to 10X and a narrow market window, a mere three-month slip can dramatically reduce revenue and profitability. No surprise.

Projects miss schedule when management underestimates or fails to acknowledge the time and resources the R&D organization needs to develop complex ICs. Absence of a reliable estimation process is the crux of the problem. Curiously, many semiconductor executives have been blind to the issue, and yet it is the key failure mechanism of their businesses because it goes to the heart of their product development engine. Go figure.

Accurately calculating design difficulty—the prerequisite to reliably estimating resources and schedules—demands quantitative methods that measure the intrinsic difficulty of designing an ICs logic, circuitry, packaging, etc. However, it must also take into account the sizable stochastic footprint of chip development.

Some executives fail to recognize the stochastic aspect of IC development has a far greater impact than ever before—a consequence of soaring development costs, inexorable competition and the limited size of each market opportunity. Resource and schedule planning therefore demands a stochastic model, which contemplates events that projects routinely encounter. Examples include spec changes, EDA tool issues, IP quality, project management, organizational issues, etc. It’s not exceptionally hard to model the development process, but it does require a good deal of industry data.

Project and program managers typically rely on experience and intuition to create project plans. Not a bad start, but the approach is light on facts and data and heavy on heuristics and hope. IC development has both a deterministic and stochastic component, and they are inextricably intertwined. Most project plans contemplate only the deterministic aspect of complexity, which is why they are flawed from the start. Not addressing the “stochastic problem” will almost certainly translate into reduced shareholder value and lost jobs.

Originally published at: http://www.eetimes.com/electronics-blogs/other/4210716/Facts-and-data-versus-heuristics-and-hope-

Comments

iniewski

11/19/2010 6:45 PM EST

Ronald, you write “Projects miss schedule when management underestimates or fails to acknowledge the time and resources the R&D organization needs to develop complex ICs” but my experience on many IC projects has been that all projects miss schedule because they are designed to do so! As one executive explained to me, “if I make a realistic schedule we will be late to market by one year, but if I shorten it unrealistically we might be only 6 months late”…has anyone worked on an IC design project that met teh deadline and was on budget??? Kris

RCollett

11/29/2010 6:54 PM EST

Kris,

My observation is that giving a team an unrealistic schedule is usually counter-productive b/c it is a demotivator. Far better is to give a team a very aggressive — but achievable — schedule. When I say “very aggressive,” I mean a schedule that assumes the development team’s prodcutivity will be best-in-class. In other words, in order to achieve the target schedule, the team must perform at or near best-in-class. The result (based on tracking this phenomenon on hundreds of projects across the industry) is that the productivity of those teams are far above norm — and the projects are are on schedule (slip is less than 10%) and come in within tolerable budget margins.

Thanks for your comment.

Rgds,

Ron

Robotics Developer

11/20/2010 9:35 PM EST

I could only dream to be on ANY project that was on time, on budget, and up to full performance. I (when I was young and naive) would give realistic schedule estimates to my boss; he would double or triple it and give it the the VP; the VP would talk with marketing and come back with a schedule that was 75 to 80% of my original one. There is always pressure to shorten the proposed schedules either by the boss or higher ups. What usually happens is the engineering staff gets hammered and is blamed for the slipping schedules. NO-ONE remembers the original schedule, its just a fact. Until companies realize that the designs will take just so much time / resources and make the appropriate trade-offs UPFRONT they are bound to lose market share or fail. I might suggest a sliding schedule analysis that provides the cost verses time to market trade-offs balancing shorter/more costly development with earlier/more profitable releases. Anyone know a company doing this?

RCollett

11/29/2010 6:44 PM EST

@Robotics Developer,

There are definitely companies making appropriate up-front tradeoffs — Intel for example. Here is an abstract of a paper presented by Intel at an industry conference held earlier this year devoted to project planning strategies:

“Effective planning for complex design projects requires understanding the tradeoffs between resources, complexity, schedule, and risk. Resource decisions are based on a particular project’s priorities, which may impact team productivity [because team size might need to be increased to hit target schedules, and increased team size will reduce productivity -- but increase throughput], and hence are important to comprehend in any systematic approach to benchmarking or planning. An empierial model for silicon design is built from available data: both from internal and external sources. This mdoel can be used to understand reslationships between team size and productivity, complexity and duration, risk and performance to schedule. Use of the model to predict organizational limits for complexity is discussed along with how key trends like reuse and modularity are unavoidable responses to current trends. This model is used throughout Intel to help make silicon design resourcing decisions . . . .”

In light of the above, perhaps it’s not surprising that Intel’s financial performance continues to be exceptionally strong.

Rgds,

Ron

iniewski

11/29/2010 7:40 PM EST

thank you Ron, agreed…pls pass the info on to executives

Death of the SoC Rumors of the SoC’s impending death have been popping...
The Elephant in the Corner Why do so many IC design teams commit to development...
In Search of Best-In-Class R&D Organizations Competition among semiconductor companies has become super-heated, and R&D...

Related posts brought to you by Yet Another Related Posts Plugin.

How Complex is Your Chip Design?

Numetrics — Thu, 11 Nov 2010 11:10:12 +0000

When planning new IC design projects, such as SoCs or complex analog or RF chips, R&D organizations that have a firm grasp on the complexity of implementing the design wield a powerful competitive advantage. Complexity is a measure of engineering difficulty and provides the foundation for reliably estimating engineering resource requirements and development cycle time for projects, which is the essence of good project planning. Can anyone disagree that consistently reliable project plans, which means projects finish on-time and within budget, translate to higher revenue and profits? But how does one get an accurate, quantitative calculation of design complexity?

One approach (that I know works) uses “industry standard effort” as the proxy for complexity. Industry standard effort is a calculation of the amount of effort the average design team in the semiconductor industry would expend on the particular design project and is based on the design’s technical specifications and characteristics. An empirically calibrated model must perform the calculation—not a theoretical model. Technical characteristics include parameters such as process technology and geometry, number of metal layers, power, circuit types such as AMS, RF, logic and memory, transistor counts, processor cores and block functions, clocking schemes and frequencies, amount of reuse, and many others. A number of top semiconductor companies use this methodology. Intel, for example, recently presented a paper entitled “Empirical Model for Organizational Dynamics” that references this approach.

Developing a reliable complexity estimation model demands extensive project data mining of the relationships between chip design parameters and the amount of engineering effort associated with implementing them. I know this firsthand, having spent over ten years working in the field. The lynchpin is having a rich database of industry projects and a mathematical model that can be readily calibrated with the industry data.

With a reliable calculation of standard effort, R&D organizations can compare the relative complexities of different designs, a very useful project planning capability. Taking it one step further, R&D managers can use the calculated complexity to determine the productivity of a finished project. It’s the ratio of Industry Standard Effort to Actual Effort Expended. Measuring the productivity on a handful of finished projects provides a baseline and starting point for reliably estimating the productivity on future projects.

Why is all this useful? In short, combining complexity and productivity modeling yields a fact-based approach to generating accurate and precise staffing requirements for IC projects, and this translates to on-time delivery and business success.

Originally published at: http://www.eetimes.com/electronics-blogs/other/4210492/How-complex-is-your-chip-design-

Optimal Team Sizes for Chip Projects What’s the optimal team size for a given IC...

Related posts brought to you by Yet Another Related Posts Plugin.

Productivity and Pornography

Numetrics — Thu, 04 Nov 2010 06:17:10 +0000

By Ron Collett

“We must increase our IC development productivity!” is the persistent invocation from semiconductor industry executives, and it’s getting louder by the day. It’s not surprising. Yet when I ask the question, “What do you mean by productivity?,” executives and R&D managers often give vague answers. Few seem to have a firm grasp of the definition, other than saying “we need to finish projects on schedule, reduce development cycle times and use fewer engineers.” As a characterization of the benefits of boosting productivity, it’s not a bad start.

It reminds me of U.S. Supreme Court Justice Potter Stewart’s comment in a landmark First Amendment case in which he described the challenge of defining pornography: “Pornography is hard to define, but I know it when I see it.” Maybe semiconductor executives are saying the same thing: “Increased productivity is hard to define, but I know it when I see it.” Justice Stewart subsequently recanted, concluding that pornography can be indeed defined. So too can productivity.

As a starting point, consider the U.S. Department of Commerce (DoC)’s definition of manufacturing productivity: “Output divided by Labor-input.” Output is the difference between the widget’s selling price and the cost of materials comprising it. Labor-input is the effort expended on manufacturing it (in person-hours). The dimensions of manufacturing productivity are therefore: Dollars per person-hour.

We can use a similar approach to quantify IC development productivity: Output/Labor-input. However, Output must be a calculation of the design’s complexity as opposed to value-add. That’s because complexity is a measure of the development team’s output. For the moment, let’s assume we can calculate it—a challenge, but one that’s definitely achievable.

Labor-input, the denominator, is the total effort the IC development team spends on the project from start to finish. The start milestone is “begin concept definition.” The finish milestone is release-to-volume production. Consistent accounting from one project to the next is a must. Also, it’s more reliable to use full-time equivalents (FTE’s) instead of counting person-hours, where one person working full-time for a week is a an FTE, or a “person-week.”

Adapting the DoC’s mfg. productivity definition to IC development productivity yields a productivity metric whose dimensions are: Total IC development effort expended divided into the chip’s design complexity (i.e. “Complexity/Effort”). The key question of course is how to accurately calculate design complexity?

Comments

Mark Wehrmeister

10/29/2010 5:38 PM EDT

Design complexity is less important than the value to the customer. Presumably, a more complex design will have greater value to the customer and fetch a higher initial price. Instead of trying to measure design complexity, use the market price for the result of that design as a proxy in the calculation of productivity.

RCollett

10/30/2010 6:05 PM EDT

Mark,

No doubt that value to the customer is the most important metric in business. And using a product’s revenue (or profit) as a measure of Output is very useful. However, in most cases it yields an incomplete picture because revenue is the result of the Output of the entire enterprise, not just the R&D organization. For example, high revenue could be the result of powerful marketing and sales, as opposed to superior engineering. This actually is very common — a strong sales/mktg. organization masks a weak R&D organization. Likewise, the revenue for a particular product line might be very low because of poor mktg/sales, but the productivity of the R&D organization could be very high. Thanks for your comment. Ron

Luis Sanchez

10/29/2010 10:25 PM EDT

On schedule, within budget and less engineers.
That’s simple isn’t it?
But… we engineers like numbers so an equation is required for IC productivity.
To measure complexity… I bet there ought to be some efforts being done already trying to measure that. In some top rated university in the US.

RCollett

10/30/2010 6:13 PM EDT

Luis,

One approach is to use a model that calculates the amount of effort the average development team in the particular industry segment would expend on that project. Then compare that effort value with the amount that your team actually spent. If you spent less, then you were more productive. If you spent more, then you were less productive. Since this isn’t a forum for commercials, I’ll direct you to www.numetrics.com where there is further info on this. Thanks for your comment. Ron

Frank Eory

10/29/2010 10:34 PM EDT

This reminds me of stupid management metrics like “lines of code per hour” for software engineers and “gates per hour” for hardware engineers. It also reminds me of an old Dilbert cartoon in which managment was paying bonuses for verification engineers to discover bugs — which quickly lead to collaboration between design & verificaton and a cartoon panel in which one of Dilbert’s colleagues was coding a minivan worth of bugs!

RCollett

10/30/2010 6:16 PM EDT

Frank,

I completely agree with you — “lines of code” and “gates” or transistors, etc. are wholly inaccurate measures of output, and to use them invites misleading results and misguided behaviors. Thanks for your comment. Ron

zeeglen

4/25/2011 8:38 PM EDT

Tell your managers to tally “capacitors per hour”. Use 0.001uf instead of 0.01 and 0.1…

zeeglen

4/25/2011 8:41 PM EDT

Yeah, I know, meaningless when applied to silicon design. But the managers don’t know that.

Himanshu_Gupta

10/30/2010 7:32 AM EDT

attention grabbing title Ron! productivity is easier to define in manufacturing units as one need to simply check the end results but during research and development, i do not think the productivity is as simple. One way to check productivity can be through the return on investment as everything is about money in the end.

RCollett

10/30/2010 6:30 PM EDT

Himansuhu,

Definitely want to use revenue (and profit) generated from the product — to calculate the return on R&D. However, what if you have a really poor sales & mktg. and very productive R&D organization? If revenue is low, it appears that the return on R&D is low. Although financial measures that use revenue and profit can be very valuable, they can give a distorted picture. Metrics that, to the greatest extent possible, directly reflect the output of a particular organization provide the most insight when analyzing a business. Thanks for your comment. Ron

yalanand

10/31/2010 2:11 PM EDT

True RCollett, I agree with you that financial measures are very deceptive while measuring productivity.

I have specifict question for you.Since I belong to service based company I want to know how do you measure the productivity for service based companies ?

RCollett

11/1/2010 2:56 AM EDT

Yalanand,

For a particular service engagement:

(Total dollars billed for the Service – Total fully-burdened cost of delivery of that Service)/(Total person-hours expended on that engagement)

The numerator is the your firm’s value-add. The denominator of course is the effort expended to deliver that value-add to the client.

Thanks for the comment.

Ron

phoenixdave

10/31/2010 3:58 PM EDT

@yalanand:If your are based on a hourly service rate, your billable hours (within the established budget) would be a start.

iniewski

11/1/2010 12:36 PM EDT

Rob,I think we agree that the final value of IC (or any other product) is determined by a customer (market). We also agree that this is has to do with Sales & Marketing effort to the same extent as R&D. Trying to separate R&D from that total is tough, if not impossible. What if my team designs very complicated, sophisticated product in half the time, a product that nobody wants! Is that R&D productivity? Kris

RCollett

11/2/2010 11:25 AM EDT

Kris,

If your R&D organization uses half the effort that another organization would expend to design an equivalent product, then your organization’s productivity is twice as high. If as you say, nobody wants to purchase the product, that’s the fault of marketing and perhaps other parts of the enterprise, and it is wholly unrelated to the development productivity of the R&D organization (unless the R&D organization had exceptionally heavy influence on the product definition or other marketing-related tasks).

Rgds,

Ron

prabhakar_deosthali

3/7/2011 5:39 AM EST

Like someone has commented, to be able to measure productivity of a person or a team we must be able to measure or estimate correctly the amount of work done. We must also be able to measure the complexity of the work done and then add appropriate weight-age to the amount based upon the complexity. The same number of lines of code written for an offline application is less complex than those written for a time critial real time application with a tight memory budget. If such metrics are evolved then only we can truly measure the productivity for a given development project team.

RCollett

4/25/2011 7:42 PM EDT

Prabhaker,

You are correct. Our customers use an empirical model we developed. It calcuates the amount of effort the average team in the industry would spend on that project. It’s quite accurate — coefficient of determination (R-squared) is over 0.9 (i.e. Predicted Effort vs. Actual Effort). For more information, you can go to the blog entitled “How Complex is Your Design,” which ran on 11/5/10, or alternatively, you can find a lot more information on our website (www.numetrics.com).

Rgds,

Ron

ATUL SRIVASTAVA

3/7/2011 7:53 AM EST

Instead of a ratio it can be defined more as a percentile . The formula will be roductivity=
(Current project data/ What is the last best data you have for similar project ) X 100
Data can be internal or from the industry sources and you generally factor for any differences due to complexity , geography etc .
This has been practically used by some companies .In one company certain groups are star performers and others are expected to reach upto start groups productivity level .In that case the productivity of star performer team is 100 percentile. This approach is quite practical.

Originally Published at: http://www.eetimes.com/electronics-blogs/other/4210257/Productivity-and-pornography#

In Search of Best-In-Class R&D Organizations Competition among semiconductor companies has become super-heated, and R&D...
The Elephant in the Corner Why do so many IC design teams commit to development...
Death of the SoC Rumors of the SoC’s impending death have been popping...

Related posts brought to you by Yet Another Related Posts Plugin.

The Rise and Fall of Productivity

Numetrics — Sat, 23 Oct 2010 05:18:04 +0000

Is IC design productivity rising or falling? It’s a question on the minds of semiconductor executives and R&D managers throughout the industry. The answer depends on whether we view it in absolute versus relative terms. Both have merit. In absolute terms it’s rising, but in relative terms it’s falling.

A “relative” measurement compares changes in productivity to changes in design complexity: How much is productivity increasing compared to the increase in design complexity? Through that lens, productivity is falling, and recently the decline has become steeper. How do I know? Aside from rigorously measuring it for more than 10 years, I know that design team sizes have been steadily increasing – the facts and data irrefutably confirm it. That means productivity isn’t keeping pace with rising design complexity. The “escape hatch” solution has been to increase design team size – throw more engineers at the problem. Alternatively, if productivity was keeping pace or increasing, average team size would be flat or declining, respectively. Of course, in absolute terms, productivity is increasing: Productivity this year is higher than last year, and last year it was higher than the previous year, and so on. That’s also irrefutable – again, based on the facts and data. Consider the effort required to design a million-transistor SoC ten years ago versus what it takes today. No comparison – teams expend much less effort today than they did then.

Absolute year-over-year productivity improvement (or decline) is critically important to an R&D organization’s productivity improvement initiative, but it is not important from an industry-level standpoint. Rather, the relevant concern there is whether productivity is keeping pace with combination of three inextricably intertwined forces: increasing design complexity, time-to-market pressure and global competition.
Declining “relative-productivity” is occurring even in the face of more design reuse, better EDA tools, new methodologies, etc. No doubt these things are boosting “absolute productivity,” but they aren’t enough to keep engineering managers and executives from continuously boosting team size. What will be the impact on the semiconductor industry?

Originally published at: http://eetimes.com/electronics-blogs/other/4209967/The-rise-and-fall-of-productivity

Comments

iniewski

10/23/2010 1:37 PM EDT

Ron, the key is the metric here…sure it takes more people to design an IC today, 100+ designers is not unheard of…but each designs lots of transistors or gates, much more than in the past…so in terms of the first metric productivity drops, in terms of the second it increases…Kris

RCollett

10/25/2010 12:09 PM EDT

Kris,

Yes, exactly — relative productivity continues to decline, whereas absolute productivity continues to rise. It’s an inconvenient truth that executive management needs to face. Thanks for your comment. Ron

eewiz

10/24/2010 11:28 AM EDT

I would argue the main reason for low productivity is the lack if innovation in EDA industry. IC designers have to deal with many point tools by different vendors and some of them dont even work well with others. If you design an analog circuit in once process node, you have completely redesign the circuit & layout to make it work in another process node. Basically I feel the EDA tool should be able to mask all the physical design challenges that come up in lower process nodes from the circuit/logic designers to improve the productivity.

daleste

10/25/2010 12:16 PM EDT

I agree that there needs to be better tools for mixed signal design. The EDA vendors have done a good job on the tools for pure digital design since that is the easier case. The design community has to work with the EDA companies to get tools for analog and mixed signal. The problem is that the standards need to be put in place first so that the tools can benefit everyone. Most companies see their design flow as a strategic advantage so they don’t have the desire for standardization.

RCollett

10/25/2010 2:36 PM EDT

Daleste,

I agree completely about the difficulty of getting standards in place. Tough to make happen when consensus is needed — kind of like trying to get agreement a the United Nations. Lots of posturing, spin and lip service, which of course is not at all surprising. Much easier when a de facto standard arises, typically driven by a company with significant market power that has introduced a technology that demonstrates clear value-add. Thanks for your comment. Ron

RCollett

10/25/2010 12:14 PM EDT

eewiz,

You may very well be right, but I don’t see more innovation than we’ve already seen coming out of the EDA industry. The market isn’t growing much and the competition in the EDA industry is stiff, which means that the risk-return equation for venture capital funding is out of balance. The consequence is less investment in start-ups. So the innovation must come from larger EDA companies, which is always spotty. Thanks for your comment. Ron

Frank Eory

10/26/2010 7:18 PM EDT

Ron, do your data distinguish design productivity from verification productivity? The verification bottleneck seems to be getting worse faster than the design bottleneck.

RCollett

10/27/2010 1:48 AM EDT

Frank,

When I refer to design productivity, the term “design” includes verification, as well as design (digital, analog, RF, etc.), layout, test, validation, qualification, etc. So my use of the term “design productivity” is a misnomer. (My bad.) It’s really IC Development Productivity, which is the term our tools use to report the productivity metric. Development Productivity measures the aggregrate productivity of an entire IC development project, from start-of-concept milestone to release-to-production milestone, and includes every activity occuring during that interval (except SW development, which has its own productivity metric — SW Development Productivity).

But to your point, it is indeed true that verification productivity is not keeping pace with verification complexity. The evidence is in the size of verification teams — they continues to grow, which means that verif. productivity is not keeping pace with verification complexity. In addition, verif. team size is growing non-linearly with other design activities on the project, which reflects that indeed it is becoming a more significant “bottleneck.” Thanks for your comment. Ron

antiquus

10/28/2010 12:20 PM EDT

Much of the stagnation can be attributed to the toolsets. Yes, there have been major strides in tool development, but mostly in the area of broad integration and backend support, and not at the level of helping to understand the code itself. (Don’t get me wrong — some of the backend pieces are absolutely amazing!) At the front end, where the coder sits, there has been little effort at improving code entry. At both places where I worked with VHDL/Verilog, the code was edited by standard text editors. In my position as reviewer, I find myself sorting through mulitple vi windows tracking this or that variable. I don’t see why syntax-aware and otherwise helpful editors (like from www.scitools.com), or even compile-on-the-fly (like Visual Studio), are not more welcome in the hardware domain.

Coming from a software background (mostly C and C#), my impression of VHDL/Verilog is a bunch of ill-organized and poorly factored modules, and coding style/methods based as much on tradition and superstition as the worst software I’ve ever seen. Modules with 50 inputs are routinely accepted, and no one thinks this is hindering productivity? We won’t even get to ideas like information hiding and other advanced concepts.

The languages require a schizophrenic combination of brute force and “oh, the compiler will optimize that away” thinking. Those coders that use the advanced features of the languages are clearly in the minority. Does it strike anyone else as odd that the simulator and synthesizer use different compiler _front_ ends? Syntax that works in one throws warnings and errors in the other! Duh!

Perhaps my impressions are wrong: my sample set is exactly ‘2′ employers. But I see much the same on the comment boards.

Silicon_Smith

10/28/2010 1:19 PM EDT

I tend to disagree. Verilog/VHDL though modelled on the traditional software languages like C, were meant for Hardware description and there is only a level of abstraction in any language before it stops serving its actual purpose. I think, even software engineers would agree with this!

antiquus

10/28/2010 6:20 PM EDT

VHDL was modeled from Ada, and Verilog seems to be some combination of C and Cobol. I did not say that these languages are at the end of their usefulness (although some tweaks would be helpful), but proper tools would enhance the productivity of using them.

Why are there no compilers that work in real-time, as the code is entered? For modern C, C#, Java and other systems, all syntax is checked and errors displayed directly in the editor. Cross references can be checked, so that an “input” to a module is instantly tracked to its source in the calling module. This greatly reduces the number of fundamental errors, and can ensure consistent naming.

Another example would be that the editor should recognize that a (Verilog) “wire” declaration is needed that corresponds to an “assign”, and simply insert it, or a proper “reg” declaration when the assignment happens inside an “always”. ….and delete them when necessary as well.

Multiple files in a design should be displayed in a tree or network format. “dir” or “ls” just don’t lend themselves to identifying dominant and subordinate files in a hierarchical design, and especially won’t help in culling out just the call strings and linkage information. This is currently a form of tribal knowledge in the design team.

The fundamental problem here is that software developers make their own tools. Hardware developers are stuck with vi or gvim or (Heaven help us) edit, and don’t know what they are missing. You have a billion-instruction per second machine there (thanks to the hardware guys that came before us), and it spends its day waiting for keystrokes (sort of reminiscent of Marvin the robot). Incremental simulation and synthesis should be a research topic at all the major vendors.

Frank Eory

10/28/2010 8:32 PM EDT

@antiquus — There are more tools available to help out at the RTL level than just text editors feeding into simulators & logic synthesis tools. There are decent linting tools, for example, that will warn you of all sorts of bad coding practices, and will also let you graphically view your hierarchy and track objects from one level to another.

I like your idea of an editor that would automatically add the mandatory (and mundane) stuff like wire & reg declarations. But you should be aware that even for old standby editors like vim, there are add-ons for Verilog syntax awareness — nothing too fancy, but at least they display keywords in one color, numbers in another color, operators in yet another and so on.

Not nearly up to the level of software development tools, but not entirely stuck in the Stone Age either.

And for real productivity gains in hardware design, certain types of designs lend themselves nicely to ESL tools — even some tools in which the design entry method is drawing block diagrams rather than typing code in a text editor.

antiquus

10/30/2010 10:53 AM EDT

A parable:

A certain woman is a diabetic. She is now skilled at working with syringes, and finding new places to give herself those shots. She is very grateful for the science that keeps her alive, and is diligent to follow the rules.

Then science (an art) became technology (an engineering discipline), and she received an implanted insulin pump.

Now, at restaurants, she pulls out her wireless (yes, that’s W I R E L E S S) remote pump controller, and uses it to prick her finger. She taps in chicken, potatoes, and ice cream, and the calculations are done. No more charts, no more disposing of needles, no more remembering to just do it.

And you have colored syntax and lint!!?!!

@RonCollett : we found your lost productivity!! Its spinning counterclockwise in the northern hemisphere!

daleste

10/28/2010 12:51 PM EDT

Don’t forget that VHDL and Verilog are languages that are used to describe physical logic. Many of the techniques used by logic designers help prevent problems in the physical logic. Good software coding can cause problems when it is synthesized into logic. You may need a block in your chip that has 50 inputs, so that is okay.

It does not strike me as odd that the synthesizer and the simulator have different compilers since they are used for two different objectives. Many things work fine is simulation that can not be easily implemented in the silicon. That is the designers job.

antiquus

10/28/2010 2:42 PM EDT

So you are saying that your early design efforts can run down a rabbit hole, leaving the synthesis step to materially start over? Reliance on the designer’s wisdom in this matter does not allow for scalable productivity. How many iterations do young designers require before they learn these quirks? Getting the bugs out during synthesis and validation when they should have been gone during simulation and verification is certainly a hindrance to better productivity.

jjdraw

10/28/2010 4:06 PM EDT

ahh, you can’t even buy ICs any more.
We almost ALWAYS have to make changes because even ’standard’ components are not available.
What a joke.
all these new fantastic ‘press releases’ for some pie-in-the-sky chip, but you can’t hardly find ANY inventory any more.
WHAT A JOKE.

Time to redesign using basic discrete components.
take your ‘fancy’ chip sets and go fly a kite !!!

In Search of Best-In-Class R&D Organizations Competition among semiconductor companies has become super-heated, and R&D...
Death of the SoC Rumors of the SoC’s impending death have been popping...
The Elephant in the Corner Why do so many IC design teams commit to development...

Related posts brought to you by Yet Another Related Posts Plugin.

The Ripple Effect

Ron Collett — Thu, 12 Aug 2010 15:00:23 +0000

As a senior product-development manager, you’ve no doubt seen the ripple effect: Your project is humming along and it’s time to add engineers on a crucial part of the design. But wait! The engineers you need are tied up on another project whose schedule has slipped, and they can’t be moved over to yours. What’s worse is when the manager on that project is not sure when they’ll be free.

You’re frustrated and suddenly stalled on the freeway and what happens in larger organizations is chillingly clear: a chain-reaction crash that creates incredible chaos across the R&D group.

Missing Schedule

Part of the reason so many semiconductor projects miss schedule is that staffing levels are not aligned with the level of complexity that the design team needs to undertake. This is solvable problem.

Fact-based planning provides the team with data for decision-making—ensuring that projects are staffed properly to meet the demands of the design’s complexity. Estimates of design complexity, project-staffing requirements and development cycle time are generated using empirically calibrated models. This is the heart of Fact-based planning, which is used by top semiconductor companies across the industry.

Fact-based planning

• Eases the traditional tension between groups within the enterprise that struggle to communicate in different languages by guiding discussions and strategy with facts and data.
• Enables predictable revenue streams because it yields accurate schedule estimates, therefore there are no surprise shortfalls in revenue or margins.
• Leads to predictable schedules, which is crucial in an era when time to market is more important than ever, and companies can’t afford to miss the market upturn.
• Doesn’t replace bottom-up, detailed planning but complements it.

Boosting Productivity

Fact-based planning is essential to an important productivity boosting best practice: seeing the project execution pipeline clearly and managing it centrally. This best practice—and the tooling behind it—rolls up all project plans to generate a picture that shows the total resources consumed by all project plans. With this bird’s-eye view of all project plans, engineering managers can observe where there are shortfalls and over-subscriptions role by role, month by month. This becomes an essential tool for managing the pipeline.

This isn’t an airbag that protects you in a chain reaction crash. This is a radar system that prevents the crash in the first place and gets everyone to their destinations safely.

Originally published in EETimes http://www.eetimes.com/discussion/other/4205031/The-ripple-effect

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

How productive is your R&D organization?

Numetrics — Tue, 22 Jun 2010 01:19:09 +0000

By Ron Collett

From the business perspective of a semiconductor company, Numetrics’ solutions are about making substantial improvements in chip development productivity and schedule predictability. But just what is productivity, and how do you first characterize it and then improve it? What’s the outcome?

Productivity drives development throughput in your R&D organization – the higher the productivity, the greater the throughput. And throughput is a measure of how much product the engineering organization churns out during a given period of time.

There are three ways to boost R&D throughput:

Add headcount
Increase work-hours per week
Raise utilization and productivity

The first two have downside: Raising R&D headcount increases cost, and more hours lead to workforce burnout and high turnover.

The only viable long-term strategies for sustaining high throughput are to increase engineering utilization and productivity.

Utilization

Increasing R&D utilization—the percentage of the engineering workforce’s effort spent on revenue-generating activities—is among the quickest and most effective ways to boost throughput. That’s because it essentially increases R&D resources without incurring additional cost.

Organizations struggling with low utilization find their engineers spend more than half their time on non-revenue-generating activities, such as sales, customer support, and product support – all of which should be handled by different groups. In large companies, that means millions of dollars a year are being squandered.

Engineering organizations in best-in-class companies, however, spend 73 percent of their engineering time on activities that generate revenue and create persistent value. By shrinking the amount of time engineers spend on projects that get cancelled, non-core research, myriad internal initiatives, and so forth, companies can significantly raise their utilization rates and, in the process, reduce R&D spending and/or develop new revenue-generating products.

Productivity

Productivity – the second factor driving throughput – is the amount of engineering output per unit of labor expended to create that output. Productivity is a function of efficiency. Only by improving efficiency will productivity rise. Analysis of R&D efficiency compares the effort a particular set of engineering tasks should consume to what they actually consume. Reducing the effort needed to complete a set of tasks raises efficiency, which increases productivity, and this gives rise to higher throughput.

Boosting productivity requires a reliable measurement system–one yielding accurate baselines and fair comparisons. Additionally, a robust measurement system paves the way for managers to determine the absolute minimum staffing projects need to finish on time. At that point, the projects are “optimally understaffed,” which means the projects can be staffed to levels that assume the teams will meet an improved productivity level.

And there’s where best-in-class companies are pushing the productivity envelope.

Originally published in EE Times http://www.eetimes.com/discussion/other/4201131/How-productive-is-your-R-D-organization-

Optimal Team Sizes for Chip Projects What’s the optimal team size for a given IC...

Related posts brought to you by Yet Another Related Posts Plugin.

The Brewing Innovation Storm

Numetrics — Fri, 21 May 2010 22:56:26 +0000

By Jeffrey Eversmann
After two years of doom and gloom, it’s refreshing to attend an industry event and hear talk of innovation—at all levels. That was the atmosphere at a recent GSA Silicon Series luncheon I attended in Austin, Texas, that featured a panel discussion on blurring technology lines.

At the application-segment level, Patrick Moorhead, marketing vice president with AMD, joked:

“I’ve been hearing that the desktop market is dying for the past 15 years.”

He made that quip after holding up the “4th screen” examples he had brought with him: an iPad and a Sony eBook reader. “Only 5-10% of consumers back up their data, so a fixed device will always be in the home,” Moorhead said.

I agree. While I like the professional security that a proliferation of leading-edge microprocessors brings, I am burdened by the yearly upgrade rotation I am now on to keep current the six-plus PCs in my home. All of us in the semiconductor industry have been through multiple iterations of the tablet device, some of them from Apple. As was often said by the panel, “it’s not an either-or these days.”

Fellow panelist Naveed Sherwani, CEO of Open-Silicon, Inc., added “the new form factor will succeed if it is useful.” So, panelists agreed that the iPad is not a desktop (or even laptop) killer. The question is: Will the average consumer add yet another device to the list of electronic gadgets we carry around each day?

The panel shifted to the technology level and wrestled with an intriguing question: Will ARM replace x86 in the desktop or will x86 replace ARM in the SoC market? While some in the audience checked email on their smartphones, Sandeep Shah, director of marketing and applications at Marvell Semiconductor, Inc., and Sherwani tackled the question.

Shah argued that an “ARM architecture licensee can bring together the best of both worlds.” (This is a very interesting perspective in light of Apple’s recent purchase of Intrinsity, which worked with Samsung to develop the ARM Cortex-based A4 processor.)

Shifting processor sands

Sherwani was quick to add that while there really hasn’t been an attempt by x86 to take over SoC design, that doesn’t mean an attempt isn’t brewing:

“In the next three years or so, things will get more competitive and more intense, when x86 is available for SoC development.”

Then it was time to move on to another much-discussed technology challenge, low power design. The panel members pulled out their different battery-powered devices and rattled off the actual vs. published battery life. “What we really need is more disclosure, a ‘truth-in-battery-life’ from silicon providers,” Moorhead said.

Shah, who probably lives power issues on a daily basis, talked about how the different Blackberry models used different chips from Marvell to get different power performance in the system. Marvell focuses on both system-level and gate-level approaches to power management. Sherwani wrapped things up from a design perspective saying “we have just scratched the surface on lower power design.” Maybe what we need is a Moore’s Law for low power design – something that will challenge engineers to do things that today are viewed as impossible.

All in all, the GSA luncheon was a great opportunity to re-connect with fellow semiconductor engineers. We exchanged cards with the same cell phone numbers, but with new company names, new titles, and new addresses. We talked about how tough things have been but how happy we are to be traveling less and spending more time with our families.

It felt like the calm before the innovation storm. I don’t know about you, but I’m here and getting ready for it.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Doing Moore with Less

Numetrics — Wed, 21 Apr 2010 20:54:55 +0000

By Ron Collett

It’s a common refrain, and I heard it this week at the IEEE VLSI Test Symposium in Santa Cruz: Moore’s Law is increasingly difficult to obey. We see evidence of this perception everywhere:

Manufacturing costs are soaring: A fab that cost $2.5 billion to construction at 90 nm now costs $6 billion at the 22 nm node. So companies are selling off their fabs and losing what was once a huge competitive differentiation for them. Their primary differentiation is increasing their product-development capability.
System-on-Chip (SOC) development costs run anywhere from $50 million to $100 million per project. A dwindling number of markets can support the ROI that type of investment demands.

This increasing risk has significantly cooled VC investment in our industry. In 2000, venture capitalists invested nearly $4 billion in semiconductor companies; last year, it was $771 million.

This means that to be successful in 2010 and beyond, semiconductor companies must “do Moore” with less. That requires a focus on product-development capability. How do you transform your product-development organization into a world-class team?

Here are some best practices:

Start with an integrated framework of product-development capabilities. We, with our partners, the global operational-strategy consulting firm PRTM, counsel such a framework to improve product and cycle-time excellence. It’s remarkable how few companies have this kind of framework, but, implemented correctly, it translates into a capability to improve your overall maturity. And the more mature your product-development maturity, the faster you’ll see revenue growth.
Optimize your R&D footprint. No one builds an SoC at a single site any more. An integrated approach to R&D management is key to taking advantage of synergies and scaling opportunities.
Extend your enterprise: The cost of development is so high, it’s no longer possible to develop everything in house. Establishing relationships with other companies and with universities is becoming essential.

In an era of doing more with less, these best practices can help semiconductor companies “do Moore” with less, widen their competitive differentiation and increase revenues and profits.

End of the Free Ride According to Pagemill Partners, a well-known Silicon Valley venture capital...

Related posts brought to you by Yet Another Related Posts Plugin.