Carpentry Lessons Applied To ESL

By Jon McDonald

Electronic system level design and analysis. How many tools fall under this general description? How many languages are applied in the various stages of system design and analysis?

I was recently preparing for a customer presentation in which we were covering most of Mentor’s tools in this area—not all of Mentor’s tools, but a subset of the tools related to the system design space. Adding it up we were covering six different major product areas including UML system engineering, analog/mechanical system modeling, requirements tracing, transaction-level design, embedded software, and high-level synthesis. Each of these areas requires domain specific knowledge, and in most cases different languages are used in each of these areas.

I found myself wondering how we could expect a customer to make sense of all of these different areas. Are all of these languages and tools really required? In a previous engagement I actually received pushback on introducing a new tool because it was felt that it would be too confusing to the customer. On the surface this may make sense, but it’s important to dig a little deeper to try to identify the unique capabilities and problems addressed by each of the tools in the different design areas.

Much as a carpenter has many different tools in his toolbox, engineers have many different tools that can be applied to solve different types of problems. Like the carpenter, engineers need to be careful in the application of their tools to different problem spaces. As a weekend woodworker, when I have a hammer in my hands everything starts to look like a nail. I’ve used my hammer as a screwdriver, scraper, wedge and I’m sure in many other ways it was not intended to be used, some of which probably were very unsafe applications.

As an engineer I’ve seen tools applied in ways they were not intended. As an intelligent problem solver I may be able to address a problem with a number of different tools, but it is important to apply our tools in a way that allows us to leverage our capabilities with the power of the tool rather than waste time trying to strip wire with a hammer. It’s not that you can’t strip wire with a hammer, but there are just more efficient ways of solving the problem.

Given that I’ve opened up this can of worms I’d like to take a shot at positioning at least a few of these tool areas. This comes with the usual disclaimer that I am basing this on nothing but my own opinion. I would be delighted to hear how others might agree, disagree or extend this positioning.

To effectively understand what tools to apply we have to understand what questions we are trying to answer. The first question we need to address is “what” are we trying to do? This may sound obvious, but I’ve experienced many situations in which projects are driven to start implementing something before they really understand what the thing is even supposed to do. The better we understand “what” needs to be done the higher the chances that our system will actually do what we expect it to do. I would use a UML tool like Bridgepoint to address this first question.

Next we need to ask “how” we are going to do it. How is an important question and it is paramount to understand the tradeoffs in the different potential approaches, the “how,” without actually building them. This level of exploring how things might be done requires an accurate representation of our system. I would address this with transaction-level design in SystemC with tools like Mentor’s Vista to explore potential approaches without going down to the implementation level.

Once we know “what” and “how” then we can just do it. This gets us to the step of implanting what we want and how we want it. I believe it’s generally agreed that once we get to the implementation level, RTL, we have exited the domain of electronic system level design.

We also need to think about the tools that address questions crossing the “what,” “how,” “do it” areas. Once we have decided how we will proceed with our implementation, high level synthesis tools like Catapult C can automate the path to hardware implementation.

I believe that to understand which tool to apply we must understand the questions we are asking at that moment. I’ve been in a number of situations in which customers wanted a recommendation on tools without understanding the question they need to be asking. While it would be nice to know if I need to take the hammer or the screwdriver out of the drawer, I won’t know which tool is needed until I know if I’m dealing with a nail or a screw. In much the same way I believe the rich set of tools available for system-level design can be optimally applied only if we understand what questions we are trying to answer. If we understand the problems we need to solve, the tools that provide the greatest leverage will be much easier to identify.

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