Few pundits have addressed the system engineering development implications of the recent EDA and semiconductor company’s move toward platforms that include both chip hardware with associated firmware software.
Niche industries are notoriously myopic. They have to be, since excelling in a highly specific market segment usually requires a sharp focus on low-level details. A good example of a niche market is the semiconductor Electronic Design Automation (EDA) tools industry, that fine group of highly educated professionals who create the tools that allow today’s atom-sized transistors to be designed and manufactured.
The EDA industry has long talked about the importance of software (mostly firmware) as a critical complement to the design of processor-intensive hardware ASICs. While the acknowledgement of the importance of software is nothing new, it has only been in the last few years that actual hardware-software platforms have been forthcoming by the industry.
What does this trend really mean, i.e., the move to include firmware (devices drivers) in the System-in-Chip integrated circuits (ICs)? To date, the result is that companies offer a platform that contains both the SOC hardware and accompanying software firmware. In some cases, like Mentor, the platform also includes a Real-Time Operating System (RTOS) and embedded code optimization and analysis capabilities.
One could argue that this move to include software with the chips is an inevitable step in upward abstraction, driven by the commoditization of processor chips. Others argue that end users are demanding it, as time-to-market windows shrink in the consumer market.
But rather than follow the EDA viewpoint, let’s approach this trend from the standpoint of the end-user. I define the end-user as the Systems Engineer who is responsible for the integration of all the hardware and software into a workable end-system or final product (see figure). Note the big “S” in SE, meaning the system beyond the hardware or software subsystems.
The integration phase of the typical Systems Engineering V diagram is just as critical as the design phase for hardware-software systems.
What is the end-system or final product? It might be a digital camera or tablet; or perhaps a heads-up display for commercial or military aircraft; or even a radiation detector for a homeland security devicen. Regardless of the end system or product, the role of the Systems Engineer is changing as he/she receives software supported ICs from the chip supplier, courtesy of the EDA industry. In essence, the “black box” that traditionally consisted of a black package chip just got a bit blacker.
Some might say that the systems engineer now has less to worry about. No longer will the SE have to manage the hardware and software co-design and co-verification of the chip. Traditionally, that would mean long meetings and significant time spent in “discussions” with the chip designers and the firmware developers over interface issues. Today, that job has effectively been done by the EDA company and the chip supplier as the latest generation of chips come with the needed firmware, e.g., the first offering from Cadence’s multi-staged EDA360 strategy.
On the embedded side, the chip-firmware package might also include an RTOS and tools for software developers to optimize and analyze their code. Mentor is leading this area among EDA tool suppliers.
But how does this happy union of chip hardware and firmware affect the work of a module or product level SE? Does it make his/her job easier? That is certainly the goal, e.g., to greatly reduce co-design and co-verification issues between the silicon development and associated software while including hooks into upper level application development. Now, companies claim that many of these issues have been taken care of for a variety of processor systems.
One should note that these chip hardware-software platforms don’t yet really extend to the analog side of the business. This is hardly surprising since the software requirement is far less than on the digital processor side. Still, software is needed for such things as communication protocol stacks (thing PHY and MAC layers).
Yet, even on the digital side of the platform space, important considerations remain. How does hardware and software intellectual property (IP) fit into all of this? Has the new, higher abstracted blacker box that SEs receive been fully verified? The answer to this question might be partially addressed by the emergence of IP subsystems (“IP Subsystem – Milestone or Flashback“).
Other questions remain. How will open system code and tools benefit or hinder the hardware chip and firmware platforms? From an open systems angle, the black box may be less black but is still opaque to the System Engineer.
What will be the new roles and responsibilities for systems engineers during design and – perhaps more importantly – during the hardware and software integration phase? Will he/she have to re-verify the work of the chip hardware-software vendors, just to be sure that everything is working as required? Will the lower-level SE, formerly tasked with integrating chip hardware and firmware, now be out of a job?
If history is any indication, then we might look back to the early days of RTL synthesis for clues. With the move to include chip hardware and firmware, the industry might expect a shifting of job responsibilities. Also, look for a slew of new interface and process standards to deal with issues of integration and verification. New tool suites will probably emerge.
How will the new chip hardware and firmware platforms affect the integration System Engineer is not yet certain. But SE’s are very adaptable. A black box – even a blacker one – still has inputs and outputs that must be managed between variant teams throughout the product life cycle. At least that activity won’t change.
