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.

By Jon McDonald

Just because a problem can be solved doesn’t mean it has been solved.

Last week I was on a panel at the ISLPED conference in San Francisco. This conference is focused on low power, and the panel addressed some of the things that are being done and some things needed for low power analysis exploration and trade-offs. While the panel was very interesting, one question that was especially interesting came up. Toward the end of the panel discussion a professor stood up and asked the panel what all the fuss was about.

According to him, all of the problems and solutions we had been discussing on the panel were solved 10+ years ago. Why were we treating our ideas and issues as something new when there is significant published work addressing these issues? His comments resonated with a common perception I’ve seen when people talk about what is being done in system-level design. I think the real crux of his statement applies beyond the low power focus of the statement, as well.

Many people consider ESL to be a new area, a missionary market for tools and design methodologies, but how can this be true? Many large companies have been doing system level work for decades; I would hazard a guess that there isn’t a large complex electronic system designed in the last decade that hasn’t had some system-level analysis done before detailed design began. So what’s the big deal now with ESL being the vogue new design area? I think this really comes to the question the professor was asking and the issue we need to understand.

Theoretically and academically we understand the system-level design problem. We understand what kinds of things can be modeled. It’s not too difficult to create a high-level model in the language of your choice for some kind of system-level tradeoff. Whether it is power or performance related doesn’t really matter. People have been doing exactly this for a long time. There have been a number of challenges associated with this process. It’s been largely a roll-your-own endeavor. You weren’t going to get a lot of help in terms of tools, models or building blocks to help you quickly put your system together.

For a large system the level of effort in building a high-level analysis model from scratch, while less effort than implementing the design, could be very significant. So the system analysis problem could be solved, but practically the level of effort required dramatically limited the widespread application and capabilities of system level design and analysis.

The big buzz today is that we now have standards for defining our high-level models, along with tools and methodologies for the design and analysis of these systems.

Standard languages such as SystemC and a standard for defining and interfacing system-level models at the transaction level, such as TLM 2.0, give us the ability to build tools and methodologies that enable system-level analysis while minimizing the effort required to put together a useful system-level analysis exploration model.

I believe the buzz today is coming from the realization and acceptance that the capabilities are available and economically viable—in fact economically necessary—to perform useful system-level analysis while focusing on the system intent. We don’t need to create all of the ESL building blocks from scratch. We can leverage all of the tools and models that are available, and we can see that many more tools and additional models are becoming available every day.

The fuss, as the original question asked, is because we have reached a transition point. We’ve moved from a theoretical understanding of what can be done in system-level analysis to a point where tools and models make it practical to achieve dramatic improvements in the design process by understanding and analyzing the ESL representation of the system before building the system.

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

I’m at DAC this week, where there is a lot of interest and discussion on what’s going on in design and what’s going to happen to designers. One conversation with a university professor gave me a “eureka” moment.

The professor had a student who really loved RTL design. The student asked him where he could get a job doing this, and the professor suggested the student move to India.  While this is not entirely true, I believe the sentiment brings home a significant issue hardware designers are facing today. RTL design is becoming, or perhaps has already become, a commodity.

As a hardware engineer in a world where my profession is a commodity, how can I expect to survive?  I believe the secret to success—the secret to “future-proofing” your professional capabilities—is to understand that an engineer’s value comes from his ability to solve a problem. If RTL design is becoming less and less of a problem then we have to figure out where the hard part of design is today.

I believe the current challenges in design are in the area of defining the architecture. We need to understand what we are going to build and we need to characterize the performance and prove the efficiency our hardware will achieve before we build it.

By understanding the design at a more abstract level I can make tradeoffs at the system level, define performance characteristics, make tradeoffs between hardware and software and between implementation alternatives, and I can balance the cost, performance and power consumed by my system before implementing my design. The RTL design itself may be a commodity, but defining the hardware that should be built and making the architectural decisions that define what RTL should be built absolutely are not commoditized skills.

In my opinion, RTL hardware designers need to begin this transition to become architectural designers. Someone who does not understand hardware concepts is not going to be effective at making the tradeoffs required to create a successful system design. As a hardware designer, if I expand my capabilities to embrace an understanding of the system level, embrace the concept that hardware design does begin above RTL, then I will be able to leverage my hardware understanding into the future. I will be a valuable contributor to the emerging and challenging portion of the hardware design task by creating unique architectural solutions to meet systems cost, performance and power optimization problems. And I will “future-proof” my value as a hardware designer.

–Jon McDonald

Last week I was sitting in a meeting having an extended discussion on what information and benefits could be derived from an ESL transaction model of a system.  It reminded me of the words of those immortal philosophers, The Rolling Stones, “You can’t always get what you want, but if you try sometimes you just might find, you get what you need”.  I believe this is a philosophy that needs to be taken to heart by those struggling with the move to transaction level modeling.

I see a recurring struggle in the minds of many people new to ESL; they have all this hype and optimism that ESL will solve all of their problems.  Guarantee that their systems will work and be successful. Of course this optimism is dashed by the cold hard reality that design is still design.  Intelligent decisions need to be made.  Trade-offs need to be understood, the costs and risks must be weighted to make the best choice for the target application of the system.  This is where ESL shines.

People want a panacea where any designer can describe a system at a high level and from this understand all the trade-offs implied by their architecture.  What they get is the ability to quantify the choices and decisions that are made.  They have to understand what it is they are doing, what questions need to be asked and they have to intelligently model, exercise and analyze the system to get the information allowing them to implement an optimal architecture.  ESL provides the ability to quickly understand the system and understand the trade-offs that are being made before the design is committed to a particular architectural alternative.  To be fair, those new to ESL often have this expectation because they’ve been oversold, overhyped and promised the world to justify the investment needed to get to ESL.

The challenge is to identify what you really need immediately from the system level analysis. It’s usually easy to come up with a list of things you want, but what do you really need?  You’ll never get everything you want, but if you try to indentify what’s really important, what are the choices that are going to have the largest impact on your system; you may just find you get the information you need at the transaction level.

I would invite those of you who’ve had some experience finding what you need, or figuring out what you wanted that really was not needed at this level, to share your knowledge.

–Jon McDonald

Jon McDonald talks about the multitude of choices in multicore design and what to do about it. Click here to watch the video.

I’m in southern California today at the EDA Tech Form. I’ve been thinking about a conversation I had recently with a colleague. He’s been doing system-level modeling for a few years and has been an advocate for transaction-level modeling and ESL in his company. He has had tremendous success in identifying and fixing system-architecture issues before implementation, as well as saving his company from pursuing business that they would not have been able to satisfy based on their current product architecture. Yet he still has trouble convincing project groups to invest in the up-front ESL modeling and analysis that has delivered his success.

I’ve been struggling to understand the perspective of the project groups he is dealing with. As I was driving through the unpredictable SoCal traffic this morning, which stopped occasionally for no apparent reason, I was struck by an analogy that applies to this RTL implementation-focused perspective. My thinking was this: If I think of the highways as corresponding to the hardware in an electronic system, the cars to the data and the decisions made by all the drivers as the software, then look at this from a road-centric view, then I might gain some insight into the RTL focused perspective. As a public works professional if I analyze the use of the highways through a functional point to point perspective, analyzing the ability of a car to get from point A to point B and how long that takes in isolation, I may find that the highways are completely adequate. However this does not exercise the system in the way it will actually be used. It does not take into account the chaotic interaction of the millions of cars and drivers over time that occasionally bring traffic to a complete standstill.

As a hardware designer focused on the hardware implementation, I may prove that the hardware works exactly as it is designed to work, but at this RTL implementation level we cannot run real software interacting with real data without building the actual system or implementing a prototype of the system. This is one of the reasons to bother with ESL design. At the transaction level of abstraction I can create a system on which I can run actual software processing real data sequences that quantify what will happen in the system under much more realistic situations than I can explore in RTL. Not that this is a perfect representation of the end system, but it is much closer to the ultimate use case than we can get at the lower level.

If we think of the hardware in isolation you can easily come to the conclusion that you can adequately test and verify the hardware at the implementation level (RTL), but if you try to get closer to reality you need to work at a more abstract level to handle the workload scenarios needed to get effective information. Ultimately ESL allows us to get closer the old aerospace adage, “Fly as you test, test as you fly.” That’s why we’re bothering to invest in ESL design and analysis in the first place.

–Jon McDonald, technical marketing engineer, Mentor Graphics