Mentor’s New Embedded Strategy

If there is a trend I can detect in verification in 2013, it is taking verification environments and making the user interface, scripts, and tools work uniformly across the whole spectrum of possible verification “substrates” from virtual platforms, FPGA boards, emulation, actual chips, RTL simulation and so on. Mentor is taking this basic idea up another level to the embedded software developer. Today they have announced the Mentor Embedded Sourcery CodeBench Virtual Edition (try saying that 3 times after a few beers).

Mentor acquired Code Sourcery in 2010, a major player in open-source software development and supplier of the most popular software development environment (or IDE, the I stands for ‘integrated’) used inside major semiconductor companies by their software engineers. It is downloaded 15,000 times a month. It is free, so Mentor doesn’t make any money directly from that.

What Mentor have done is made it so that software engineers can use the CodeBench that they are used to using. But under the hood, they can actually be running on a QEMU-based virtual platform, or on one of Mentors Veloce emulators, or on an FPGA prototype, or on the real silicon, or on a reference design board. RTL is far too slow for software development, but for all I know that might work too.

From the software engineers point of view, all the details of the hardware such as RTL or signal traces, are hidden and he or she only needs to worry about software-like stuff. If a problem is detected that might be a hardware issue, the design engineer can pick up signal traces and dig down into the details without requiring understanding all the software or how to work inside CodeBench.

The basic idea is to give the software engineer just enough information from the hardware that they can get their job done and not have to worry about the hardware or learn lots of alien stuff. And similarly, for the hardware engineer, to let them work in their environments without needing to become an expert on the embedded software environment or code.

I worked for VLSI Technology for years and I like to say that I have silicon in my veins, although by background I’m a programmer. But when I worked at VaST and Virtutech I started to see things from the embedded software developers point of view. For instance, I was at a Cisco supplier conference and the CTO spoke at a keynote. IOS, Cisco’s router operating system, is 25M lines of code and another 30M lines of code to test it (I suppose what we’d call VIP in EDA). The developers of that code neither know nor care what SystemC is, or how you synthesize a chip. It is just a big register map to them. When I did a computer science degree in a galaxy far far away I actually learned some hardware design. Nowadays, I don’t think they teach that stuff. They probably don’t even teach assembly code. If you can do C++, Java and Python you are good. The point I’m making is that the abstraction level the software people work on is so far removed from what the hardware people are doing that it is hard to communicate.

This looks very good to me. Not in the sense that it is rocket science breakthrough technology. But it addresses the social aspects of software/hardware co-design and doesn’t take as a fundamental assumption that the software developers and the hardware developers are in adjacent cubes and speak a common language. Especially, it doesn’t assume that taking hardware design tools and interfacing them to some software environment with a “software engineer” skin is going to work.