By Jon McDonald
Way back in college when I first learned about “delayed binding” I was absolutely ecstatic. In its most general interpretation this is not just a software concept. It’s a way of life. The important part of the concept is to understand that a decision or an action should not be taken until it needs to be taken.

This is a relatively simple concept with very broad implications and wide areas of application. It can be very frustrating to some people, including my wife. She sees it as procrastination. But from my perspective it is actually a very proactive approach. I would prefer to delay an action as long as possible, gathering additional information, continually evaluating the potential options and only committing to a particular choice when it is actually required to make that commitment.

I have had a number of discussions with various customers recently that has brought me back to the value of this philosophy as it can be applied to ESL design processes. A wide range of customers are applying ESL design techniques and attempting to link the various portions of their engineering processes. They often look at starting with systems engineers capturing the initial model of the system in UML or SysML. This initial model may then feed into the architecture design team as an abstract transaction level model, often in SystemC.

The architecture design team can refine this model, generally getting to a loosely timed (LT) SystemC TLM2.0 representation. This functional representation of the architecture is the starting point for virtual prototyping and architectural exploration. The LT TLM representation can be refined with target implementation characteristics to an approximately timed (AT) model which then becomes the reference point for the RTL implementation.

At each stage along this process it is absolutely critical that we apply the philosophy of delayed binding to the models we are creating and the decisions we are making. In my mind this is the art of the system-level engineering process. We must understand what level of detail and what level of accuracy are required at each level. Making an implementation decision too early in the process can force a system implementation down a path with little chance of delivering a successful product. The beauty of applying multiple levels of abstraction in our design process is that each level can address the questions, considerations and tradeoffs that need to be made at that level to allow us to move forward. By keeping each level as abstract as possible we realize a process that allows for optimal incremental refinement. Each level of decision can be made with all of the information available at that level.

With the tools and techniques we can apply today, the spirit of the delayed binding philosophy can be efficiently applied to the ESL design process to achieve more optimal systems with very flexible implementations—but only if we can resist the urge to over constrain the implementation before it needs to be constrained. Don’t let anyone tell you it’s procrastination. It is really keeping all options open as long as possible, leading to an end system implementation with the best possibility of success.

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

By Jon McDonald
I was at DAC last week. Over the course of the week I had a chance to talk with a significant number of customers and others in the industry. As has been the case the past few years there was good interest in system-level design. But from my perspective the tone of the discussions experienced a major shift this year.

In the past, much of the discussion was around “why—why should I look at the ESL tools and, if I do want to look, what do I need to look at?” This year over the three days of full meetings I don’t think I spent any time talking about “why” adding ESL capabilities makes sense. People were much more interested in detailed discussions about how to add ESL to their flow in the most efficient ways. I didn’t get any pushback on the need to make the change.

It was refreshing to move beyond some of the theoretical discussions around value and justification to more practical matters of deployment and integration with existing flows or point capabilities. I believe this transition is another sign that the ESL market really is maturing and being accepted as a valuable and desirable addition to the electronic design flow.

An interesting aspect of this transition was highlighted for me by one of my discussions with one of our customers. This customer was in the process of expanding their usage from a relatively small number of initial users who had been using the tools on production projects, but in more of a pilot project mindset, to a wider deployment as a standard part of the design flow for all projects. In the initial projects the focus was on the basic capabilities: Was it possible to achieve the modeling accuracy, extract the analysis metrics and realize the simulation performance at the transaction level that would enable them to make the needed design decisions before the implementation was frozen? In this mode the value of the feedback and the impact of the choices on a projects viability meant that they were willing to work outside their standard flow. In fact, they wanted to and did work closely with us to drive product direction.

In the new mode the focus is shifting to integration with the rest of their design flow. Consistency and repeatability have increasing importance, as they expect a broader design community to begin to benefit from the ESL capabilities.

A challenge we have as an industry is to satisfy the needs of the mainstream users while continuing to enhance and innovate the capabilities we deliver in our ESL tools. As users it is important to understand your position for deployment of these tools. During initial deployment, exploration of the capabilities and applying these capabilities outside the standard flow will be critical to success.

From my perspective I’m very excited about the changes and challenges as we move into this phase of expanding deployment. I believe the possibilities and investment in ESL tools and methodologies will expand dramatically this year. The more we can facilitate the early adopters in our customers and deliver mainstream capabilities to the broader engineering communities the more resource will be available to extend the boundaries of our ESL design and analysis capabilities.

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

By Jon McDonald
I’ve heard a few comments recently questioning how good is good enough. How good does a device have to be before it’s above questioning its capabilities? When designing some new whiz-bang device how do we know when we can stop?

I think most engineers will agree there is always room for improvement. There are additional optimizations, refinements or alternative approaches that may yield a better design, but we just haven’t had the luxury of time to explore these optimizations and design alternatives. And all of this without even mentioning the additional features that can always be added to improve our device.

In engineering we have many competing priorities. Continuous improvement is an oft-quoted mantra. At the same time most engineering organizations are very risk averse. If something hasn’t been done before then no one wants to try it for the first time on their project. Hardware design groups are very good at implementing a given function. The challenge we have is that faithful implementation of a function does not necessarily result in a successful device.

There are many factors affecting our success, some under our control and some not. The RTL implementation process is one of the things squarely under our control, but that’s not enough for today’s devices. The ability to determine whether our RTL implementation is the best is generally beyond the resources available to be applied. Generally we cannot try many different implementations with dramatically different architectures to see what best addresses our goals. We have a well-defined, reasonably predictable process for implementation but it’s just too expensive to radically depart from what we’ve done in the past for a given RTL implementation.

Looking at what’s happening in system-level design, and specifically what is happening with transaction-level modeling, organizations are creating early models of their systems for multiple purposes. Everything from performance analysis to virtual prototyping is being tried at the transaction level. I believe one of the biggest reasons organizations are so interested is that transaction-level design provides the ability to get a better answer to the question, ‘How good is good enough?’

Personally, I don’t believe we will ever top improving our ability to answer that question. ESL is just another step on the path of continuously improving our understanding and ability to predict and quantify the design choices we have before us.

The fun part of this is that we are opening up our ability to question the status quo. Now that we have a way of quantifying our possibilities we can justify the risk associated with a radical new approach by showing what will be gained by the wager. We don’t have to accept an implementation just because we’ve always done it that way. Ultimately we can take our designs that have been good enough in the past and show that they can be much better than we ever expected.

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

By Jon McDonald
The other day a friend asked about the battery life on my iPhone. I love the phone by the way; he was disappointed with how often he had to recharge his. I responded with the one thing I had tried—turn off the Bluetooth.

With that one change I have been pretty happy with the time between charges. His question got me thinking about the battery life of the phone, and I started paying attention to how long the iPhone would run between charges. I noticed that at home my iPhone seemed to last significantly longer than when I traveled. Initially I thought the longer life might be due to the level of use, but after checking this on a few trips and comparing it to my use at home, there was not a significant difference

I started looking through the settings to try to find something that could explain this difference. After some very poorly controlled experimentation I realized if I switched off the 3G network when I traveled, switching it on only when I needed higher bandwidth for a particular application, then the battery lasted much longer. Curiously the battery life appeared to be much closer to what I was experiencing at home. At home I leave the 3G on, but I also connect to my home WiFi network. My theory is that when connected to WiFi, the WiFi connection is used for data and the 3G service is turned off, or at least put in a significantly reduced power mode.

To me this was a shocking realization—that a product with such a large number of units produced in which battery life is of crucial importance could be so poorly optimized for power consumption was absolutely amazing.

Look at the two generally known ways of improving battery life on the iPhone. First turn off Bluetooth. Why do I need to turn it off? Why isn’t the phone smart enough to know if it is being used or not and power it down when not in use? Yes, you could say it always needs to be available, but if you look at the typical use case, connecting to a headset, the phone is the master, the phone knows when it needs to make the connection, so it could turn the Bluetooth function on and off as needed. Based on the reduced battery life I see when Bluetooth is on, even when not connected, it appears to be poorly optimized for the actual capabilities that are being used.

Turning off the 3G is a similar tradeoff. For normal phone calls and even push e-mail notification, I don’t really need the 3G performance, but if I want to browse the Net, use the maps, or any other higher bandwidth application, I want 3G on. Why isn’t the phone optimized to turn the 3G on only when needed? Apparently it does a better job of power optimization when WiFi is available. From my experience turning on 3G causes significant reduction in battery life, even if I’m only making phone calls. I can manually turn 3G on and off, but this is very cumbersome. The phone knows what is being done and should be able to control this setting automatically.

This kind of problem is an example of the issues ESL modeling can help address. By creating an abstract model of the system and exercising that abstract representation under realistic use cases, we can optimize the system performance and the power consumption for the work that needs to be performed. If we don’t know what work needs to be done, we cannot optimize the system. This is a crucial problem for the hardware designer. If we only look at the hardware in isolation, we don’t know what trade-offs can be made to optimize the system. However, if we look at what the system is actually doing, we can optimize the configuration of the system to deliver the needed performance for the minimum power.

I don’t believe it is a problem with the iPhone hardware. It’s a problem with the way the hardware is being used. This is a very sobering indication of how much potential there is for intelligent ESL design. It is also encouraging. By understanding the system power and performance in the context of the work that needs to be performed, we open up the possibility for incredible optimizations that are simply not possible in other design domains. With a smarter iPhone my friend can spend more time exploring the latest applet and less time tethered to a power cord.

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

By Jon McDonald

Return on investment is a subject that comes up frequently when people are thinking about adopting higher-level design approaches. After all, we are talking about adding work—we need to model, design, simulate and analyze the system. All of these tasks take time and cost money. So what are we getting in return?

Before we can think about the return, we have to identify what we are trying to accomplish by doing all of this work before starting the real implementation process of RTL design.

We want to predict the future. Before we implement the system we want to understand the implications of our design decisions. If we want to identify a return on investment for this extra work, we have to assume we would have made an incorrect decision without it. Now we are basing the ROI on the probability of making that incorrect decision, and we’ve started down that slippery slope of justifying the return based on statistics. Not that this can’t be done, but it involves much more complex math than we would typically want to see in bulletproof, management-accessible ROI. I believe we need to think about the justification for this investment in the same way we think about the justification for an insurance policy.

This reminds me of the doctor who explains to the patient the options to treat a medical condition without committing to a recommendation. Why can the patient make the decision better than the doctor who has had many years of training? It is because there is no way to prove that one course of treatment will always be better than another. The tradeoffs being made by the patient are subjective; they require a basic understanding of the options and impacts of choices beyond the field of medicine.

We are dealing with a similar problem when we make the jump from a natural language specification to the RTL implementation. The implementation choices made are subjective. It is expensive, difficult and sometimes impossible to prove the best implementation in RTL. Sometimes we can’t even determine if the implementation is acceptable at the RT level.

At the system level we have the flexibility to quantify some of these choices. We can’t prove everything, but we can quantify some of the implications of our selections. This gets to the core problem of an ROI evaluation: Through the ROI we look to prove that value is achieved. Nothing can prove that we could not have achieved the same result by jumping directly to RTL implementation, but system-level design provides incredibly valuable information that allows us to make educated design choices—insurance that we understand the implication of our choices.

So it comes down to how lucky you feel. If you’re really lucky, you may never need your insurance policies. If you’re design groups are lucky, you might get an acceptable implementation. But from what we are seeing in the design communities, our luck is running out. We need the insurance delivered by the additional information we can gain from the system level to guide our implementation choices.

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

By Jon McDonald

Irrational exuberance is running rampant. Design managers believe all their systems engineers and software programmers are going to be able to drive the hardware design process from a high-level description.

OK, perhaps irrational exuberance is a bit strong and it may not be quite rampant, but I’ve heard statements recently both from customers and suppliers pushing in this direction. For those of you who were around for the last big design shift—from schematics to RTL—you may remember hearing these kinds of statements back then. Managers believed or were sold the story that hardware design was going to be more like software as design moved to RTL. Back then there were a number of projects that tried to have software programmers writing the RTL code. What I remember most are some spectacular failures, primarily because the people writing the RTL did not understand the hardware implications of the choices they were making.

Fast forward 20-plus years and everyone is excited about another change in the abstraction of hardware design. We have many hardware design projects starting at a transaction level. Combine this with the growth of UML and other abstract descriptions for driving the systems engineering and software processes, and we have people again thinking that the need for hardware engineers is going to be replaced by software, and systems engineers having their abstract descriptions automatically synthesized to hardware. The problem with this kind of thinking is similar to what happened two decades ago. Without a good understanding of what you want, and the implications of your choices on power and performance of the hardware, you will end up with a very fast path from an abstract model to a garbage implementation.

High-level languages are not causing the problem. High-level descriptions give us phenomenal power to explore the requirements of our systems and the potential tradeoffs of different implementations. Still, we have to understand the implications of the approaches we are pursuing. Abstract descriptions and high-level synthesis tremendously leverage the power of a hardware designer to explore the design space much more thoroughly than would be possible in RTL, but we must be realistic. Nothing comes for free. Garbage in will give us garbage out in our transformation from a high-level description to RTL, just like it does in every other area of human endeavor.

Personally, I don’t see the need for good hardware designers diminishing. I see the need for hardware designers capable of leveraging the power and capabilities of high-level design exploding. Perhaps irrational exuberance is not appropriate, but at least some excitement about the possibilities enabled by high-level design is warranted.

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

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.

By Jon McDonald
Lies, damn lies and statistics. Occasionally I get the impression that some engineers feel we’ve just taken that step beyond statistics in our ESL modeling.

In a recent discussion I was very pointedly reminded of the subjective nature of abstract design and analysis. Like most predictions, you don’t really know what’s going to happen until it actually comes to pass. Using abstract modeling, ESL design is trying to predict what will happen when you build something before building it. No one has a perfect understanding of things that have not yet been done, but we can make educated decisions based on current knowledge and refine our decisions as more information becomes available.

This is a very important concept to keep in mind as we go through our design processes. We can start with estimates, guesses by another name, of our expected system capabilities. We can estimate performance and power characteristics to make some very early decisions on a project’s viability and the best approach for the design tradeoffs. As we get more detail on what we will be doing we may build spreadsheets to capture some of the dependencies between our choices. As our system understanding increases we may come to a point at which the number of variables and the interaction of these variables is too complex to effectively maintain in a spreadsheet.

At this point creating an abstract model of our system may make sense. With an abstract model we can start to explore much more detailed analysis, we can create models that allow us to understand the detailed system performance and power consumption of our system. Our models may be able to process realistic data sets, run software and exploring the efficiency of our hardware platform for its intended task.

All of this gives us a fantastic amount of information and understanding of our target design, but it is critical to remember that the accuracy of our understanding is limited by the accuracy of our models. We need to remember this fact and understand that knowledge of our design is continuously being refined. As we learn more from our decisions moving through implementation, we need to verify the effects of these implementation decisions on our earlier assumptions and models. Creation of an abstract platform for a new design is not a single exercise completed and frozen as we move to the next step. It is a continuous process of improving the accuracy of our abstract platform to reflect the decisions and trade-offs identified as we go through implementation.

Mark Twain popularized the disparaging view of statistics. I believe this largely hinged on the perceived practice of claiming faulty conclusions by selectively misusing statistical data. If we hope to achieve the full value from our abstract modeling and avoid negative interpretations, we need to accept the fact that our abstract platforms are continuously evolving representations of our current understanding of our target implementation. The accuracy of the models at any given time is very subjective, subject to the current visibility we have into the implementation decisions we have yet to make.

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

By Jon McDonald

Sometimes something becomes so simple and clear it’s shocking. I recently experienced such an epiphany. It started with a typical discussion on hardware software relationships and tradeoffs. How do you know what should be done in which?

Realistically there is no automatic method to determine the proper partition. The best we can do is to propose a potential solution, then test that solution against our problem space. We’ve been doing this for a long time. Hardware designers propose a potential implementation, and then go through the steps of verifying and analyzing the performance and capabilities of that proposed solution. How do we know if a power or performance problem in our system is due to the hardware or to the way the software uses the hardware?

ESL methodologies and transaction-level modeling techniques have allowed hardware engineers and architects to quickly characterize their systems and understand the impact of the tradeoffs they are making. What happens on the software side? Software has become a huge part of almost every system designed today. In most organizations, a limited analysis of at least some of the software running against the hardware is performed. In the vast majority of cases the software is developed in isolation, or at best against a functional model of the system, possibly a hardware prototype or a virtual prototype, with no feedback on the efficiency with which the software uses the hardware.

How can we reasonably expect to develop efficient software for a particular hardware platform without feedback on the effectiveness of the software we are developing? For virtually every area of endeavor in which performance is critical, the optimization flow involves performing the activity, measuring the result, making a change and repeating the process. For the optimization flow to result in improvement it is critical that an accurate metric is available to measure the effectiveness of the various approaches. Yet in many power or performance critical applications no accurate metric is available for the software developer to compare alternatives approaches to a problem. Without an accurate metric how can we be surprised when our systems do not perform to the expected potential?

By leveraging our ESL models to provide not just an executable virtual prototype, but a virtual prototype that accurately reflects the power and performance capabilities of the hardware, we can converge on an efficient software implementation that takes advantage of the capabilities provided by our hardware platform. Without measurement we are developing our software hoping for the best. With an accurate ESL platform to run our software against we can quantitatively understand the efficiency of our software running on our hardware and ultimately realize the most efficient system for a given combination of hardware and software.

For me that simple idea of measuring the software running on the hardware was a surprisingly natural way of leveraging the ESL model already being created for hardware performance analysis. In fact, after thinking about it I have trouble understanding how we can expect performance or power critical software development to succeed without an accurate metric to measure against.

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

By Jon McDonald
Earlier this week I was sitting in the airport waiting for my flight 
to depart. I was connecting through Atlanta. This happened to be one of the days that Atlanta was receiving heavy rains causing flooding 
and occasionally closing the airport.

First the flight to Atlanta was 
delayed an hour, then two, then three. Meanwhile my connecting flight 
had been cancelled and I’d been rebooked on a flight the next morning. Finally this connecting flight the next morning was canceled and at this point the airline, which will remain nameless although it should be obvious to anyone who has ever connected through Atlanta, could not get me to my destination in time to make my meeting. Needless to say this was a very frustrating experience that 
stretched over a number of hours with many changes in the information being communicated and very little confidence in the reliability of 
the information that was delivered.

Once I calmed down and started thinking about what was really going 
on, I realized that the largest factor in my “FRUSTRATION” level 
was the lack of predictability. If I had known earlier in the process what the issues were, I could have explored other options. I could 
have tried other airlines, or at the very least I could have canceled the trip earlier, gone home and had a relaxing enjoyable evening with my family.

This lack of predictability is a fundamental problem in designing any complex electronic system. Traditional RTL processes do not provide visibility into all of the choices that are being made in the design architecture early enough in the process to allow viable options to be explored. Not that I would ask anyone to admit to this experience, but imagine senior management’s frustration with this lack of predictability in a 
design project, continually shifting schedules and performance capabilities.

The system we expect to implement, the performance, power consumption and time it will take to develop are largely guesses 
during the specification phase. Intelligent guesses, informed by 
experience and history, but guesses nonetheless. By the time we get 
enough information from the RTL implementation to validate our assumptions it is often too late to make the changes needed to address 
the issues related to our earlier guesses.

This predictability is exactly the kind of issue that can be addressed 
with a well-formed system-level design methodology. Start with an 
abstract model of what you know and what you assume, validate and 
explore the model and the assumptions, explore the sensitivity of the 
design to the assumptions, then refine the model through the process, bringing back more detailed information as it becomes available. With 
this approach we have a better basis for making our design choices and 
identifying the impact of our choices and assumptions early enough 
in the process to make the information useful.

Shocking as this may seem, even a frustrating delay at the airport can 
be viewed as a morality tale for yet another reason to move to high-level design. What’s your opinion?

–Jon McDonald is the technical marketing engineer in Mentor Graphics’ design creation business unit.