English
Software - The X factor
Chris Turner, Cambridge Consultants
Cambridge UK
Abstract
This paper discusses the challenges faced by IP providers and/or SoC designers in providing appropriate software enabling customers to program their chips in the applications. Provision of such software is a critical success factor for many semiconductor businesses and this paper raises some of the issues together with some best practice example solutions.
Introduction
New markets and applications in today’s semiconductor business are driven by the generation of new Intellectual Property that is created either by the IC developer or licensed from an IP provider. However the definition of new IP for a new application it is often led by the software tasks that the application has to perform, which in turn dictates the IP hardware specification. In today’s markets, the IP can be realised in an ASIC, an FPGA or some other device platform but, whatever the target, and before the IP is developed, its system architecture requirements must be defined, and this almost invariably leads to software architecture.
Defining the combined system and software architecture, its algorithms, its model of computation, its security or encryption techniques, code size, critical response times and programming environment is every bit as important as defining the hardware architecture, in fact it often completely dictates how the hardware should be constructed.
So before an IP product can be specified there needs to be a comprehensive understanding of the software it will run, what information any sensors or wireless systems will provide, what processing power is required and what outputs have to deliver or control. This understanding is often gained through performing an architecture study and perhaps doing some experimental modelling in MatLab or exploring the design space of digital signal processing techniques.
A further set of requirements often arises from power management in that the architecture may dictate a low-power mode for when the product is quiescent and then need to turn itself on quickly to process information on demand. Issues like reliability, self test and fault tolerance are also considered as well as applicable software standards compliance for communications and interoperability. All of this dictates the division of processing tasks across the computational elements in a system, leading to an architecture definition. Then the IP can be specified and its development can begin.
This trend towards software and architecture engineering to meet the needs of demanding and novel applications is emerging throughout the semiconductor industry where there are long-established companies going fabless or fab-light and reducing their investment in manufacturing, focussing instead on market leadership that comes when IP serves the complete application requirement in a complex system on a chip.
Figure 1: Software through the IP value chain
This is a very positive change for semiconductor companies and their IP providers, as they increase their added value by taking control of the system engineering agenda, putting them closer to applications and the consumer. The relentless advance of the industry, thanks to Moore’s Law, allows companies to play higher up the value chain. However, this advance has brought new challenges and risks, as many companies are no longer broad-line semiconductor component suppliers, but focused and dependent upon particular markets and applications without the manufacturing and cost differentiation they once enjoyed.
Enter the fabless companies and also the chipless companies, which are IP providers who almost define the entire chip and licence its design to a semiconductor company instead of making it themselves. Fleet of foot and comprising engineering talent and innovative thinking, these companies embrace system-level design in valuable market sectors, such as smart phones, media players, broadcast receivers, set-top boxes, broadband routers, PC peripherals etc. And of course, in the early stages, these new markets and technologies set the industry’s agenda and enjoy higher profit margins and return on investment.
So, what are the differentiating factors, success factors or X factors that could help these IP and semiconductor companies transition and grow?
Software can be the success factor
Any five-year-old fabless semiconductor or IP company can tell you the differentiating success factor is often software. Almost all new SoC opportunities for application-specific semiconductor products (ASSPs) start out by defining software models or standards, often conceived by academic researchers, for new forms of communication or processing, such as new wireless transmission techniques, cell phone applications, PC or laptop peripherals, or other Internet-related technologies. For example, consider UWB, which starts with the mathematical theory of orthogonal frequency division multiplexing (OFDM), or graphics chips, again starting with definitions of graphics primitive requirements operations in their software drivers. Again, the definition of communications modulation, handshaking and protocol stacks defines what the chips must do.
This reveals why so much innovation in the semiconductor industry takes place in start-ups; be they chipless or fabless. These are the companies where management is attuned to software and technology, as opposed to being focused on hardware and fabrication. The smaller innovative companies are more likely to be staffed with progressive software architects. They are often spinouts from universities or research institutions founded by programmers and engineers who can see where new technology is emerging and probably did their Ph.D. on it. And these companies have determined how to develop, deploy and support the software that is critical to their success in chip sales.
As a result, the challenge for larger, established semiconductor companies (i.e., the so-called integrated device manufacturers (IDMs)) is how to participate in this process of emerging technology and markets, where new applications and products are being defined and where market leadership is often won by being first to market with the right product and supporting software. It is in these new markets where early adopters can be seen, leading to early majorities that support profitable pricing, ROI and market leadership. Coming into a market late is costly and companies doing so are often doomed to failure. IDMs do participate later on, usually by acquiring the matured fabless start-up (i.e., either pre- or post-initial public offering (IPO)). However, this can be expensive and does not always succeed if executives and engineers opt out along the way.
In some cases, this transition from manufacturing- to market- and application-led thinking will be a challenge for established semiconductor companies, especially those who view software as a cost to be minimised, as opposed to a leadership technology to be optimised and invested in.
Software best practice
There are some good examples of best practice where getting the software right has clearly led to success. First, the different communities of software users must be considered and addressed from the outset of an ASSP’s development. These communities are typically:
Figure 2: Software Communities
It is all too easy for a chip company to neglect this community of programmers and focus only on its internal needs and those of the end users. But in markets for ASSPs (e.g., Bluetooth or ZigBee wireless chips or wireline chips, such as broadband modem processors) the needs of the application programming community are key. In these scenarios, the ASSP chip company needs to deliver an out-of-box development environment that empowers and enables the product developers to get their applications up and running as easily as possible. Any lack of quality or support in the application developers’ environments will delay design wins and put downstream volume chip orders at risk. Clearly, it is not enough to just point these developers at a set of third-party software resources and tools and wish them luck. An ill-conceived approach to these issues can also have a huge negative impact on the ASSP chip supplier because their support costs can escalate if application developers are not properly equipped to do their job and require constant hand-holding.
The ideal solution is for ASSP chip suppliers to provide an out-of-box integrated development environment (IDE) tool, typically accompanied by a reference design board carrying the ASSP. This IDE fulfils a number of purposes:
Integrated development solutions
An excellent example of an IDE shipping to ASSP application developers is the Bluelab product from CSR (Cambridge Silicon Radio). Bluelab is a CSR-specific version of xIDE supplied by Cambridge Consultants and it enables application development for CSR’s Bluecore ASSPs which run Bluetooth applications in cell phones, headsets, in-car audio and so on. Bluelab carries all of CSR’s code and connects to their reference design platform. Even low-skilled software developers can get up and running using Bluelab in thirty minutes or so and their access to the Bluecore chip is restricted to application development whilst they are unable to inadvertently re-program any radio code. Supporting many hundreds of developers worldwide, the availability and ease of use of Bluelab has been a crucial factor in CSR’s considerable market success.
Figure 3: Cambridge Consultants' xIDE
When considering how to deliver software and tools to application developers, the ASSP semiconductor company can choose from a number of options. xIDE is one of many solutions, another is Eclipse.
Eclipse is an open source project focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle. It runs on Java and is very portable. ASSP chip companies can pick up and use Eclipse to offer development environments, and many tool vendors have also adopted it as a ‘wrapper’ for their various compilers, debuggers, etc. However, IP and chip companies should exercise caution before jumping on the Eclipse bandwagon; it can be an overly complex environment for a small applications development team halfway around the world to install and use. Its openness could lead to increased technical support as developers reconfigure and extend it. And in the long term, it may prove difficult to manage, incur more cost than initially expected and may be perceived as not offering much value by product companies purchasing ASSPs.
Using a controlled and bespoke environment like xIDE has been more beneficial to Cambridge Consultants’ clients. The ASSP team knows exactly what software their customer is using and they have deterministic control over what the customer can and cannot program. Lower skilled applications development customers of the sort that may encountered in application fields like ZigBee can be addressed with a simply installed IDE running on a Windows PC. In addition the development software is seen to be strongly branded and supplied by the ASSP provider, thus capturing its value proposition within the sales process.
Stacks and libraries
Another example of successful software deployment was seen at Virata, a Cambridge-based fabless DSL modem ASSP provider that held its IPO in ‘99 prior to merging with Globespan and later being acquired by Conexant. Virata had to deliver huge amounts of code to its broadband router manufacturing customers.
Figure 4: Virata software stacks 1
Figure 5: Virata software stacks 2
Virata’s engineering team had more than twice as many resources devoted to software than to the engineering of the ASSP hardware. And there is no doubt that it was the availability of good software supporting all standards required by telecommunications companies, along with excellent support and training, that persuaded customers to design in Virata’s chips.
Conclusion
In conclusion, as more semiconductor companies seek to deliver the complete system solution, they must address software engineering more actively and, in particular, the needs of the application developers programming their chips, the needs of their own engineers and the end users’ needs. Many of the newer fabless semiconductor companies formed in the last 10 years have seen and addressed these needs. It remains to be seen if larger semiconductor companies going fabless or fab-light and focusing on complete SOC applications will be able to do so as well.
About the Author
Chris Turner manages Cambridge Consultants’ business development activities in the semiconductor industry, where the company offers wireless and analogue IC design together with silicon IP and software tools, including 16-bit XAP processor cores and xIDE. Chris’s previous roles include VP of operations at Virata Corporation, operations manager at the Olivetti Research Laboratory and chief engineer at Acorn, where the first ARM-powered computers were made. Chris is also a founder and director of two start-up companies; Yogitech SpA, which is an ARM technology partner in Italy specialising in fault-robust IC design, and Zentian Ltd., a Cambridge-based company developing speech recognition IP. Chris is a registered European Engineer, a fellow of the IET and vice chairman of the IET Microelectronics and Embedded Systems Network.
Cambridge UK
Abstract
This paper discusses the challenges faced by IP providers and/or SoC designers in providing appropriate software enabling customers to program their chips in the applications. Provision of such software is a critical success factor for many semiconductor businesses and this paper raises some of the issues together with some best practice example solutions.
Introduction
New markets and applications in today’s semiconductor business are driven by the generation of new Intellectual Property that is created either by the IC developer or licensed from an IP provider. However the definition of new IP for a new application it is often led by the software tasks that the application has to perform, which in turn dictates the IP hardware specification. In today’s markets, the IP can be realised in an ASIC, an FPGA or some other device platform but, whatever the target, and before the IP is developed, its system architecture requirements must be defined, and this almost invariably leads to software architecture.
Defining the combined system and software architecture, its algorithms, its model of computation, its security or encryption techniques, code size, critical response times and programming environment is every bit as important as defining the hardware architecture, in fact it often completely dictates how the hardware should be constructed.
So before an IP product can be specified there needs to be a comprehensive understanding of the software it will run, what information any sensors or wireless systems will provide, what processing power is required and what outputs have to deliver or control. This understanding is often gained through performing an architecture study and perhaps doing some experimental modelling in MatLab or exploring the design space of digital signal processing techniques.
A further set of requirements often arises from power management in that the architecture may dictate a low-power mode for when the product is quiescent and then need to turn itself on quickly to process information on demand. Issues like reliability, self test and fault tolerance are also considered as well as applicable software standards compliance for communications and interoperability. All of this dictates the division of processing tasks across the computational elements in a system, leading to an architecture definition. Then the IP can be specified and its development can begin.
This trend towards software and architecture engineering to meet the needs of demanding and novel applications is emerging throughout the semiconductor industry where there are long-established companies going fabless or fab-light and reducing their investment in manufacturing, focussing instead on market leadership that comes when IP serves the complete application requirement in a complex system on a chip.
Figure 1: Software through the IP value chain
This is a very positive change for semiconductor companies and their IP providers, as they increase their added value by taking control of the system engineering agenda, putting them closer to applications and the consumer. The relentless advance of the industry, thanks to Moore’s Law, allows companies to play higher up the value chain. However, this advance has brought new challenges and risks, as many companies are no longer broad-line semiconductor component suppliers, but focused and dependent upon particular markets and applications without the manufacturing and cost differentiation they once enjoyed.
Enter the fabless companies and also the chipless companies, which are IP providers who almost define the entire chip and licence its design to a semiconductor company instead of making it themselves. Fleet of foot and comprising engineering talent and innovative thinking, these companies embrace system-level design in valuable market sectors, such as smart phones, media players, broadcast receivers, set-top boxes, broadband routers, PC peripherals etc. And of course, in the early stages, these new markets and technologies set the industry’s agenda and enjoy higher profit margins and return on investment.
So, what are the differentiating factors, success factors or X factors that could help these IP and semiconductor companies transition and grow?
Software can be the success factor
Any five-year-old fabless semiconductor or IP company can tell you the differentiating success factor is often software. Almost all new SoC opportunities for application-specific semiconductor products (ASSPs) start out by defining software models or standards, often conceived by academic researchers, for new forms of communication or processing, such as new wireless transmission techniques, cell phone applications, PC or laptop peripherals, or other Internet-related technologies. For example, consider UWB, which starts with the mathematical theory of orthogonal frequency division multiplexing (OFDM), or graphics chips, again starting with definitions of graphics primitive requirements operations in their software drivers. Again, the definition of communications modulation, handshaking and protocol stacks defines what the chips must do.
This reveals why so much innovation in the semiconductor industry takes place in start-ups; be they chipless or fabless. These are the companies where management is attuned to software and technology, as opposed to being focused on hardware and fabrication. The smaller innovative companies are more likely to be staffed with progressive software architects. They are often spinouts from universities or research institutions founded by programmers and engineers who can see where new technology is emerging and probably did their Ph.D. on it. And these companies have determined how to develop, deploy and support the software that is critical to their success in chip sales.
As a result, the challenge for larger, established semiconductor companies (i.e., the so-called integrated device manufacturers (IDMs)) is how to participate in this process of emerging technology and markets, where new applications and products are being defined and where market leadership is often won by being first to market with the right product and supporting software. It is in these new markets where early adopters can be seen, leading to early majorities that support profitable pricing, ROI and market leadership. Coming into a market late is costly and companies doing so are often doomed to failure. IDMs do participate later on, usually by acquiring the matured fabless start-up (i.e., either pre- or post-initial public offering (IPO)). However, this can be expensive and does not always succeed if executives and engineers opt out along the way.
In some cases, this transition from manufacturing- to market- and application-led thinking will be a challenge for established semiconductor companies, especially those who view software as a cost to be minimised, as opposed to a leadership technology to be optimised and invested in.
Software best practice
There are some good examples of best practice where getting the software right has clearly led to success. First, the different communities of software users must be considered and addressed from the outset of an ASSP’s development. These communities are typically:
- In-house programmers and engineers at the semiconductor or IP provider
- ASSP application developers in the company that design the SoC into its product and deliver products to customers
- End-user customers (who may also use the device for programming, e.g. as a computer)
Figure 2: Software Communities
It is all too easy for a chip company to neglect this community of programmers and focus only on its internal needs and those of the end users. But in markets for ASSPs (e.g., Bluetooth or ZigBee wireless chips or wireline chips, such as broadband modem processors) the needs of the application programming community are key. In these scenarios, the ASSP chip company needs to deliver an out-of-box development environment that empowers and enables the product developers to get their applications up and running as easily as possible. Any lack of quality or support in the application developers’ environments will delay design wins and put downstream volume chip orders at risk. Clearly, it is not enough to just point these developers at a set of third-party software resources and tools and wish them luck. An ill-conceived approach to these issues can also have a huge negative impact on the ASSP chip supplier because their support costs can escalate if application developers are not properly equipped to do their job and require constant hand-holding.
The ideal solution is for ASSP chip suppliers to provide an out-of-box integrated development environment (IDE) tool, typically accompanied by a reference design board carrying the ASSP. This IDE fulfils a number of purposes:
- It can provide a tailored and branded application development environment consisting of documentation, project management tools, programming editors, etc.
- It can be a delivery vehicle for real-time operating system (RTOS) drivers and libraries that run on the ASSP.
- It can include the chosen compilers, assemblers and debuggers necessary to build and run applications.
- It can include interfaces to configure and monitor the ASSP and its software while in operation (e.g., radio data packet monitoring and on-chip register configuration).
- It can facilitate the control and debug of multiple processors in the ASSP, and can help designers by abstracting complexity into manageable programming and debug interfaces.
- It constrains application programmers to work within the preferred environment and flow, preventing them from disrupting other parts of the hardware and software and reducing support activities.
- It gets applications developed faster and at a lower cost.
- It reduces time-to-design and time-to-volume.
Integrated development solutions
An excellent example of an IDE shipping to ASSP application developers is the Bluelab product from CSR (Cambridge Silicon Radio). Bluelab is a CSR-specific version of xIDE supplied by Cambridge Consultants and it enables application development for CSR’s Bluecore ASSPs which run Bluetooth applications in cell phones, headsets, in-car audio and so on. Bluelab carries all of CSR’s code and connects to their reference design platform. Even low-skilled software developers can get up and running using Bluelab in thirty minutes or so and their access to the Bluecore chip is restricted to application development whilst they are unable to inadvertently re-program any radio code. Supporting many hundreds of developers worldwide, the availability and ease of use of Bluelab has been a crucial factor in CSR’s considerable market success.
Figure 3: Cambridge Consultants' xIDE
When considering how to deliver software and tools to application developers, the ASSP semiconductor company can choose from a number of options. xIDE is one of many solutions, another is Eclipse.
Eclipse is an open source project focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle. It runs on Java and is very portable. ASSP chip companies can pick up and use Eclipse to offer development environments, and many tool vendors have also adopted it as a ‘wrapper’ for their various compilers, debuggers, etc. However, IP and chip companies should exercise caution before jumping on the Eclipse bandwagon; it can be an overly complex environment for a small applications development team halfway around the world to install and use. Its openness could lead to increased technical support as developers reconfigure and extend it. And in the long term, it may prove difficult to manage, incur more cost than initially expected and may be perceived as not offering much value by product companies purchasing ASSPs.
Using a controlled and bespoke environment like xIDE has been more beneficial to Cambridge Consultants’ clients. The ASSP team knows exactly what software their customer is using and they have deterministic control over what the customer can and cannot program. Lower skilled applications development customers of the sort that may encountered in application fields like ZigBee can be addressed with a simply installed IDE running on a Windows PC. In addition the development software is seen to be strongly branded and supplied by the ASSP provider, thus capturing its value proposition within the sales process.
Stacks and libraries
Another example of successful software deployment was seen at Virata, a Cambridge-based fabless DSL modem ASSP provider that held its IPO in ‘99 prior to merging with Globespan and later being acquired by Conexant. Virata had to deliver huge amounts of code to its broadband router manufacturing customers.
Figure 4: Virata software stacks 1
Figure 5: Virata software stacks 2
Virata’s engineering team had more than twice as many resources devoted to software than to the engineering of the ASSP hardware. And there is no doubt that it was the availability of good software supporting all standards required by telecommunications companies, along with excellent support and training, that persuaded customers to design in Virata’s chips.
Conclusion
In conclusion, as more semiconductor companies seek to deliver the complete system solution, they must address software engineering more actively and, in particular, the needs of the application developers programming their chips, the needs of their own engineers and the end users’ needs. Many of the newer fabless semiconductor companies formed in the last 10 years have seen and addressed these needs. It remains to be seen if larger semiconductor companies going fabless or fab-light and focusing on complete SOC applications will be able to do so as well.
About the Author
Chris Turner manages Cambridge Consultants’ business development activities in the semiconductor industry, where the company offers wireless and analogue IC design together with silicon IP and software tools, including 16-bit XAP processor cores and xIDE. Chris’s previous roles include VP of operations at Virata Corporation, operations manager at the Olivetti Research Laboratory and chief engineer at Acorn, where the first ARM-powered computers were made. Chris is also a founder and director of two start-up companies; Yogitech SpA, which is an ARM technology partner in Italy specialising in fault-robust IC design, and Zentian Ltd., a Cambridge-based company developing speech recognition IP. Chris is a registered European Engineer, a fellow of the IET and vice chairman of the IET Microelectronics and Embedded Systems Network.
|
||||||
Related Articles
- Software rises in semiconductor IP market report
- Early Interactive Short Isolation for Faster SoC Verification
- Why Transceiver-Rich FPGAs Are Suitable for Vehicle Infotainment System Designs
- Shift Left for More Efficient Block Design and Chip Integration
- Design-Stage Analysis, Verification, and Optimization for Every Designer
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
|
E-mail This Article | 
|
|
Printer-Friendly Page |