Some of you may have read a article last year that TSMC was premature in acquiring Cadence and had many good reasons to do so (reasons I don't personally feel qualified to debate—this is not my point today). This idea jumped to my mind while I was shaking my crystal ball a few days ago, trying to figure out what 2006 would bring to the electronic engineering community. And suddenly, the crystal ball flashed, showing the role of the electronic engineer is radically changing.

Looking at it carefully (and being a little extreme), what exactly does this mean to the engineer?

• First, that with increasing system complexities together with problems at mastering the 65-nm (and beyond?) process (some of the sources of the recent ESL debates), it is required that SoC design teams are 'manufacturer-specialists'.
  
  
• Second, all a SoC system "design engineer" will do in the future is fit specs in some language defined by a foundry and then let the foundry engineering teams process this input and release a fully packaged product.
  
  
• And finally, that in the end, ASIC and SoC design engineers will have two choices left: find work at a foundry or switch to software design in his (or her) current company.

While these outrageously simplistic consequences (hardware engineering and EDA for the foundries and software engineering for the others) may reveal some actual trends, is this really all that 2006 has in store?

It is true that EDA companies and the EE community are facing important challenges to really benefit from the most advanced manufacturing processes. Maybe this will lead to reshaping some parts of the industry and maybe this will lead to a shift in the design flow.

But when you think about electronic engineering, please bear in mind:

• Not everybody designs multi-million series chips in 65-nm: SoC and ASIC design engineers only represent a minority (10-15%?)—even if influential and significant—of all the design engineers at work today. Many people design electronic systems with a set of standard and custom processors (embedded microcontrollers, FPGAs, and other DSPs), peripherals, mixed analog/digital pieces, and IPs. Everything is put on a PCB without a real straightforward EDA flow.
  
  
• At the very start of 2006, between soft, firm or hard microprocessors; between standard cell, structured ASICs, ASSPs or FPGAs; volatile or non-volatile FPGAs; there have never been as many technology options for the development of electronic systems—at virtually any size or price.

For 2006, I predict electronic engineer's roles will be more exciting than ever... and this is not just about making a choice between advanced electronic system-level languages.

• First, the engineer's role will be to dive into the target system application (the software) before defining the hardware architecture. With 2006, it is time to quit the bad habit to throw architecture at the application engineer and just ask him to put software on top of it. So, he'll have to be an application or a software engineer before showing his hardware skills.
  
  
• Second of all, the hardware engineer will have to take his informational role seriously. As a specialist, he'll have to shake the design teams habits, forget about his 'all P' / 'all FPGA' / 'all SoC' approaches and investigate new technology alternatives. These alternatives may require quite a bit of experimenting (there are so many prototyping platforms). In 2006, the hardware engineer has to believe the ideal technology for his project really exists... and remember: 'ideal' first means 'of value for your company'.
  
  
• Finally the engineer must forget about 'one size fits all' design and verification approaches to really manage system complexity. While reinventing the wheel is a bad engineering practice, worrying about what really works with your people is pragmatic engineering.

Well... will 2006 be the year of pragmatic engineering?