Improve Productivity Through Communication and Learning

I regularly spend time talking to people about the importance of the connection between embedded software and hardware design and verification. If you have been following my writing on cadence.com you know that it takes more than tools to succeed on a project that depends on hardware and software working together. I have written about embedded software verification and how to improve it. I have also written about companies that have reorganized people to report to common management that is responsible for both hardware and software.

At CDNLive! Silicon Valley 2009 we heard from Mohsin Riaz, an ISX user, about his HW/SW Co-Verification experience. One of the points that stood out was his description of increased communication between the hardware and software engineers to better understand the correlation between hardware and firmware. Getting people to sit in front of the same screen and look at interactions is a great learning experience that should not be undervalued.

Here are a few questions to think about to make sure your company fosters this communication and sharing:

• Can hardware and software engineers easily share data?
• In the Virtual Platform domain, are hardware and software engineers using the same tools?
• What is the best way to promote reuse and yet meet the distinct needs of hardware and software engineers?

The first question relates to configuration of file systems and servers. It should be easy to share data across networks and servers and to make sure there are no artificial barriers that force people to e-mail source files and executables around the company. Having this seamless access to data is sometimes more difficult when dispersed geographies are involved.

The second question about common tools is also important for fostering communication and learning. In the Virtual Platform domain sometimes software engineers create a model of the hardware using a particular tool and use it for software development. As expected, the first time they hit a question about how the hardware is supposed to behave they start asking hardware people to take a look (which is good), but since there is no shared modeling strategy and common tools there is a loss of productivity and implicit barriers are constructed. Sometimes hardware engineers to not participate in Virtual Platform activities because they think it's not their job.

The third question addresses the fact that hardware and software engineers have different needs. I'm all for specialization of disciplines. I have written about how the hardware discipline evolved into design engineers and verification engineers. I have also promoted that embedded software should evolve similarly into a separate design and a verification component. Maintaining this balance can be done by first sharing tools and models to get the maximum reuse and then providing views of the design that are customized according to a task being done. Now when there is an issue between hardware and software it's easy to change views and see all of the data that is needed for everybody to work together.

For Virtual Platforms hardware engineers probably need to debug and analyze the SystemC source code. Software engineers probably don't want to look at the SystemC source code, but are very interested in the programmers view of the device registers and memory. Having a common tool that can be configured for specific views is the best way to achieve economies of scale and at the same time maintain specialization.

One of the Virtual Platform product configurations that I disagree with is to provide a "software engineer" version of a tool and a "hardware engineer" version of a tool. In the software engineer version, certain things are removed such as the ability to debug the source code of the hardware model (because this should not be needed or cannot be done). In the hardware engineer version maybe the ability to debug the software is not provided because hardware engineers are not supposed to need this or know how to do it. Such segmentation only results in another implicit barrier to hamper productivity. In the end we are all the same and spend our days repeating the code, compile, run, debug cycle. Specific views within one tool is the best way forward. This is also increasing in importance as the hardware design methodology transitions from RTL to SystemC as the design input language using tools like C-to-Silicon.

One of the things that continues to annoy me as I continue to promote communication and learning is the assumption that hardware engineers work on Linux and software engineers work on Windows. There are many reasons for this, some are historical, some are actual requirements due to tool availability, and sometimes there is no basis for it. Sometimes a new employee shows up for work and there is a Windows machine on his desk so he assumes he should use Windows tools to develop software. Other times tool availability is a real issue. For example, many EDA tools are not available on Windows so hardware engineers cannot choose Windows.  Some embedded software cross-compilers are only available on Windows so again there is no choice.

Sure, it's easy to just say that all tools should run on Windows and Linux, but this doesn't meet the goals I described above about sharing data, using common tools, and providing task specific views, so even if it was easy to develop software for Linux, Windows, and Mac (which it isn't) it might provide users more options, but by itself this does not solve the problem.

Recently, I have seen some embedded software development kits use the strategy of a virtual machine to address multiple operating system support  issues. It comes not only from the cost to support multiple operating systems, but also from the complexity involved. With a complex embedded software development flow it may be easier to just provide a virtual machine with all the tools pre-installed and configured. The Maemo SDK from Nokia is one such example. With the computing power that is on the desktop of many engineers it is possible to easily continue to develop code using their favorite Windows editor and through file system sharing simulate it in a Linux Virtual Machine right on their desktop. Companies can also think about making virtual machine images easy to create and share. One interesting approach is SUSE Studio to easily customize what is actually needed for a virtual machine image and eliminate all of the unneeded software. I use VMware every day for software development. The VMware icon on my Windows desktop looks more like an application than an operating system. With so many advances in networking and virtualization it is starting to seem that the desktop operating system is less and less relevant when it comes to development tools.

In summary, to promote reuse, productivity, communication, and learning between hardware and software engineers while maintaining the benefits of specialization companies should:

• Eliminate barriers to sharing data
• Use the same tools and models
• Develop specialized views of hardware and software
• Eliminate artificial restrictions imposed by operating systems

Jason Andrews