Few people know the embedded OS and software development tool market as well as Jim Ready - after all, he played a key role in its formation. At Ready Systems in 1981, he developed VRTX, the first commercially viable real-time operating system (RTOS). In 1999, as founder of MontaVista Software, he pioneered embedded Linux commercialization. Ready recently joined Cadence as chief technology advisor for software and embedded systems.
In this Q&A interview Ready discusses his role at Cadence, his background with the RTOS market and embedded Linux, the software development tools market, the role of virtual platforms, and the opportunities for EDA vendors in embedded software development.
Q: Jim, what is your job responsibility at Cadence?
A: The title says it all. Lip-Bu Tan [Cadence CEO] asked me to advise him and anyone else at Cadence around software issues that relate to embedded systems. Hopefully I can make a good contribution here.
Q: Where were you before, and how did you end up at Cadence?
A: I was the founder of MontaVista, the pioneer of embedded Linux, and I did that from 1999 to May of this year. Two and a half years ago MontaVista was acquired by a very good semiconductor company, Cavium. I stayed to make sure that transition was complete and things were stable. I had known Lip-Bu for many years and he asked me to join him in looking at the future of software for Cadence, and it was an opportunity I couldn't refuse.
Q: You pioneered the first commercially available RTOS in 1981. This opened a new marketplace that attracted a number of players. What made you realize there was an opportunity here?
A: My first real job was with ROLM, which built hardened computers for the military. These were big boxes, massive minicomputers. At the same time Zilog, Intel and AMD were producing all these little microprocessors. And it became obvious, eventually, that minicomputers would be replaced by microprocessors in various forms, which were going into embedded systems - and they would need software.
It struck me that what embedded microprocessors needed was what embedded minicomputers already had, which was an RTOS. With Ready Systems we set out to build a processor-independent RTOS. Just at that time the C language was starting to come out, so for the first time we had a portable, processor-independent environment for embedded computing.
Q: How well did that work out?
A: It worked well in a number of ways. The ultimate winner was Wind River Systems, which got to upwards of $400M in sales. Ready Systems got up to $25M and we then merged with Microtec, which was acquired by Mentor Graphics in 1995. I was at Mentor for three years, and then in 1999 I started MontaVista.
Q: Why did you switch from providing a commercial RTOS to offering embedded Linux?
A: That was really interesting. First, many telecom customers were pushing on Ready Systems/Microtec, and Wind River, to enhance RTOSes to look more like Unix. Secondly, in the early 1990s I was playing around with Linux at home just as a hobby. As I kept following it there was more and more interest. Then I read one article about side-looking radar that, in its first version, used VRTX and Unix in a two-card VME cage. The next version used Linux only. I thought, I'm being replaced!
Then it dawned on me that I could make an embedded version of Linux and completely disrupt the RTOS market. And so we did.
Q: Linux is open source. What value did MontaVista add?
A: The last thing a large customer wants is the latest version of Linux, with 10 million lines of constantly changing, untested source code. We offered commercialization, support, and enhancements. We pioneered real-time Linux, flash file systems, fast booting, and all sorts of things. This led people to pay real money to obtain Linux versus the ancestor they could download for free.
Q: There are far more software developers than hardware designers, yet the EDA market is considerably larger than the embedded software tools market. Why is that?
A: If you're building a semiconductor device, there is no choice but to give Cadence or Synopsys money. You cannot physically make a processor or a chip without the tool chain. They are not nice to haves, they are as fundamental as the silicon wafer. And the tools are very difficult to develop. Semiconductor companies have the ability to monetize tool costs by selling chips.
There's no sharp delineation like that in the embedded market. The software world is awash in good and bad alternatives. There are lots of options, including open source. There is no magic tool that will suddenly increase productivity by 10X. The gating factor in software development is not a missing tool - it's the complexity of what you're doing. It's just hard.
Q: Given these dynamics, where are the opportunities for EDA vendors in the embedded world?
A: Open source is the most dramatic example of reuse on a massive scale. But it creates situations where the lines of code you have to own, understand and test are far beyond what a team of 10 or even 100 can do. I think there's a management of complexity opportunity, given mountains of constantly changing open source.
Virtual platforms represent an opportunity because the lack of visibility into hardware slows things down. Being able to get drivers done and bring up an OS early is very valuable. But just to be clear, it's not where most of the software developers in a project are. They're out in the applications space. I think the role of virtual platforms beyond hardware/software bring-up is going to be really application dependent. There will be cases where many copies will be sold because of the unavailability of target hardware.
Another important point is that SoCs are not general-purpose processors that can go anywhere - they're targeted to specific markets. The lesson here for EDA folks is that if you are going to enter the software business, be very careful about paying close attention to vertical markets.
Q: People have been talking about hardware/software co-design and co-development for a long time. Are they finally happening?
A: With co-development, you're building a new chip and you build a virtual platform so the OS guys can get going. Co-design is where you have some notion of what the system is going to do but you haven't partitioned it yet, or decided what goes into hardware and what goes into software. TLM [transaction level modeling] provides one way to decide how you're going to partition, and actually try things out.
Co-design probably happens more than hardware/software co-development, because that's what architects do - they try to figure out what goes down into the silicon.
Q: Finally, where do you see opportunities for Cadence in the embedded world?
A: It's pretty clear that the Virtual System Platform is a critical element for our semiconductor customers. Hopefully that bodes well for Cadence. We're new to it, so we don't have 10 years of legacy. We have an open, scalable, and connected approach that I find pretty interesting.
Part of the reason I'm here is to figure out what the rest of it is. I wouldn't have come if I didn't think there was significant opportunity. As I've also mentioned to Lip-Bu, maybe part of my value would be knowing what not to do. In that context, I'd say the search is on to find the next disruption, the next RTOS or embedded Linux, that will change the way things are done. My job is to discover, along with some unbelievably good talent here, what that disruption is.
This is a nice informational posting of Embedded Software Development. thanks for sharing it.