IP software integration is being done. However, a customer is not likely to buy all their IP blocks from a single vendor, and they're likely to have a preexisting software base into which the need to integrate software.
This is a really difficult problem for the IP vendors, because of budget and skill set. There are dozens of real-time operating systems, dozens of relevant Linux kernel versions, dozens of compilers, and every customer's final integration is different. It's not easy to manage, and it's hard to make this work match the IP vendor's business models. It's not reasonable to expect the IP business unit to develop much more than what they're doing today: all customers would have to pay for that effort, but only some of the customers would use it.
So instead the IP vendors rely on partners who have experience in the relevant technology. For example, IP vendors like Synopsys partner with MCCI to deliver USB 3.0 device and host support solutions. The IP vendor uses our stack when testing their IP, and we work closely with them for problem resolution and (if necessary) software work-arounds. Then MCCI works with the customers to integrate our software with the rest of their system. This model seems to work well for customers who are integrating IP, and want integration assistance.
I'm with Terry on this one. Tools suppliers can only take it so far, so it's up to specialized IP suppliers such as Ceva, mentioned here, to provide point solutions for application-ready IP + software. But working with the tool vendors to close the gap is critical as the IP blocks increase in size, functionality, and software requirements. I too would really like to know who's really enabling this.
My first reaction to reading this article was "What is he talking about?". Then I remembered back in the old days when we used to have to cobble together protocol stacks and math libraries from different venders and try to make it all work together. The closest to that that I have had to do recently was to integrate a proprietary 802.11 driver into a 2.6.x version of Linux. On the other hand, we just finished an upgrade based on Linux 3.6.8 which includes an open-source version supporting the same chipset.
There are still some places where third-party software needs to be integrated. USB 4.0 has been slow in coming, but seems to be on track for the near future. Some of the more exotic comm stacks may not yet be supported. From what I hear, Thunderbolt support is still shaky, for example. The bottom line, though, is that Linux and the various efforts around it have swallowed up most of what used to be the software IP market. Practically everything below the application layer (and even big chunks of that, in many cases) are readily available in very high-quality code. Even when the code is not up to snuff, the open-source model converges very quickly to improve it. If the software IP market really has disappeared, it is because it has been replaced by something that works better for system developers.
@LarryM99 I hear you, but at the lowest levels of the stack, where software meets hardware, someone has to provide that software, and it has to be able to integrate into the rest of the stack. Given that the hardware piece is often very adaptable and capable of supporting multiple protocols it can be a tricky problem. Companies such as Tensilica not only have to provide hardare IP and the tools top create them, but also tools to create the software that goes along with them. I know that in this case it is creating things such as compilers and linkers, but the problem seems to be analogous to other types of hardware as well.
Brian, I had to look up Tensilica since it has been a while since I heard that name. I can see where their customers would be looking for IP for specific protocol stacks, but I have to wonder how much market share they are getting for new designs versus FPGA cores or other design options. It reminded me of a recent story here on EE Times about how cellular base stations were moving to standard PC hardware instead of expensive specialized hardware. It seems like the embedded world is in the beginnings of a similar move, where the platforms are standardizing around Linux running on an ARM core on an SoC with an auxiliary FPGA. The more standardized that architecture becomes the less need there is for specialized software IP.
That may be true in some design areas, but if we consider the smart phone world, FPGAs are too power hungry to be viable. They also want maximum cost reduction which means integration into as few packages as possible. I think we will see more consolidation in both hardware and software platforms over time and this will help.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.