Designing In The Rain

By Jon McDonald
Recently I was running some errands on my motorcycle when I got caught in the rain. Living in Florida, this is a fairly common summer occurrence. Generally, as long as it’s not too much of a deluge, I can continue through to my destination and dry off when I arrive.

I always get concerned looks from those going by in their enclosed vehicles—from some, “concerned” might not be the best description. On the motorcycle I’m prepared for the rain. My response to it isn’t the same as those traveling in an enclosure, but based on what I have to work with it isn’t a big deal. I think some of those going by in their enclosures would disagree and consider the situation unacceptable on a motorcycle. I understand my choice in putting myself in this situation, which makes dealing with the tradeoffs acceptable to me.

Recently I’ve been involved with two different organizations putting themselves in similar and very challenging positions. Each had very different levels of acceptance of the implications of the situation they were in. When we’re dealing with early system design, we may not have all of the details necessary to fully characterize a system. Architecture factors that affect the system performance and capabilities may not be fully implemented, or even well understood.

In this case, both situations involved engineers attempting to create early virtual prototypes for systems analysis. Both organizations had created SystemC transaction-level prototypes that allowed them to run software and get some level of performance feedback. On one side, the users of the platform had more of a hardware engineering focus. On the other, the users were much more software-centric. While some of the challenges each organization was dealing with were very similar, the responses to the issues were very different. Some of the key issues included accuracy of the platform, user interface to the model and completeness of the system.

Each organization had made a choice in putting themselves in a situation different from their traditional situation. In each they were having success, but the way they were dealing with the issues, and the issues they felt were most important were very different based on their previous experiences. As organizations adopt system-level design approaches, I believe it is very important to take into account the histories of the users. Some effort needs to be invested in understanding the use model expectations. In some cases the tools and techniques can be but in place to match expectations, while in other cases the expectations must be modified to accept dealing with the tradeoffs of the situation.

Similar to the reality that I do not have the same expectations from riding a motorcycle as I would driving a car, engineers and organizations should not expect the same issues when using a virtual prototype that they would expect in using a physical board. The capabilities and challenges of each are unique. Understanding this will allow us to make the best tradeoffs in our development processes.

—Jon McDonald is a technical marketing engineer for the design and creation business at Mentor Graphics.