By Jon McDonald
Power has been an active area of discussion for me recently. It’s come up in a more concrete way than in past conversations: customers are more interested in discussing details and not as interested in the abstract concepts. An interesting outcome of this is that now we need more context, we need to understand what we mean when we talk about power analysis at the abstract, system level. What is needed? What is appropriate to measure or estimate? And what level of accuracy can be expected?

Sometimes people have differing assumptions about the way something is going to be used that make one person’s obvious statement, obviously incorrect to another. I recently had a discussion with someone very involved with the power analysis and power optimization of a processor core. We were discussing what needed to be modeled and what level of accuracy we could expect to achieve in the transaction level model. At a high level we broke the power down into static, clock tree and dynamic, with the dynamic being the power associated with the device doing some specific processing. His contention was that it didn’t really matter what was being done because if you know what was on and what was off you could get a pretty accurate estimate of the power. I’m sure if I made this statement to a group of people, some would agree thinking this an obvious statement and some, like myself, would think this statement obviously wrong.

I should give a bit more perspective. From his point of view the power the device consumed was independent of what the device was doing. This is another way of stating what was already stated, but in a way that I had even more of a problem accepting. After discussing this for a bit we came to the realization that we had very different assumptions about the way our information would be used. Looking at an operation in detail, it was true that the watts consumed by the core were not significantly based on the operation. However, the length of time it took to complete an operation could vary greatly, so the power was indeed independent of the operation, but the energy, joules, consumed varied significantly dependent on the operation performed.

Once we got past our assumptions about the way the power information was going to be used, it became clear that an abstract model could be constructed that would track a relatively small number of variables corresponding to the power domains and clock frequencies used. With this information, the model could accurately predict the power of the device, but this was not enough to understand the energy being consumed. To do so, we have to add details about the task and operations being performed, which determines the length of time at a particular power level. This combines well with our transaction level modeling approach; for a given transaction we can define the time it takes and the power it consumes. At this level of modeling, and a reasonable understanding of the work a system will be performing, we can make an accurate prediction of the energy consumed by the system and even the dynamic power profile of the system.

An interesting outcome of this discussion was that even static power could vary significantly with the work being performed. Actually, I would argue that most modern systems don’t really have static power. With multiple power domains, dynamic voltage and frequency scaling, the only way to know the power profile is to understand and model the workload along with the system.

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

By Jon McDonald
A subject came up today that has come up on numerous occasions: “How often will the transaction-level model with timing, AT, be used versus the functional model, LT?”

This is a common question; the answer is often very specific to the user. The kinds of questions and the analysis required will drive the level of accuracy required in the models.

It’s probably easiest to start by thinking about the kinds of things that need timing and power accuracy. The first statement that comes to mind is “any software execution that is timing dependent,” but this feels a little too much like a circular definition. What we’re really looking for is system activity that varies based on the order of messages. For this to be true there must be multiple threads of interacting execution. Multiple processing activities progressing concurrently will generate this situation.

It may be easier to define the class of systems that are not potentially subject to timing issues. Any system with a single thread of execution would not be subject to timing dependencies. This is a pretty limiting restriction.

Thinking about most multiprocessor systems, they generally would have many areas of critical timing interaction. In the general case I believe most hardware systems will have multiple activities progressing and interacting to deliver the required performance. This does not mean that all of the verification and analysis should be done using the AT level, but that verification and analysis of the system at the AT level is a critical step in the overall development process.

I’ve heard a number of well-informed individuals take the position that AT analysis isn’t needed. Their contention is that LT for functional verification is enough, then they would go right to RTL. But what happens if an issue that is discovered in the RTL causes an architectural change? Generally, changing the architecture once RTL implementation has begun is a very expensive proposition.

The benefit of AT transaction-level analysis is to begin to understand the performance implications of our architectural decisions without investing the effort of implementation. We can make a relatively small incremental investment by adding the AT timing and power performance information to the LT models, allowing us to quantify our tradeoffs. Once we understand the timing and power implications of our choices then we can invest in the implementation of the architecture we know will meet our system needs.

Back to the original question, the first level of question, “Does it work,” will be addressed at the LT level of abstraction. Once you understand if it works, the next level gets to the questions related to, “Does it meet performance requirements?” How much time is invested in verifying function versus verifying performance expectations will provide the balance between LT and AT analysis.

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

By Jon McDonald
Recently at dinner we were discussing a new video game my son wanted. My wife and I were less than thrilled with the game due to some of the adult themes I had seen in the reviews. As my son was trying to convince us that it was an acceptable game he fell back on the old standard justification: “All my friends are playing it!”

This is one of the poorest reasons for anything, as far as I am concerned. In my mind it’s an indication of cowardice or sloth. Either you’re afraid to present the real reasons or you’re too lazy to come up with defensible arguments. I tried to explain this to my son in a somewhat gentler way, but still trying to get him to understand the issues.

After dinner I was thinking about the reasons I hear for selection of a particular architectural alternative. By far the most common justification is, “That’s the way it was done on another project.” I realized that this sounds suspiciously like my son’s justification. To be fair, in the past “prior experience” was a very effective way of making the decisions. It was often too expensive or difficult to analyze alternatives in any meaningful way. Basing a decision on something that worked in the past was often the most reliable path to success.

With the current state of system-level design, I think we’ve crossed an inflection point. It’s no longer defensible or successful to continue with an approach simply because it was done on another project. The cost of failure and the margins required for a successful project require a more informed understanding of the implications of our decisions. Today I can characterize my architecture and make reasonably accurate predictions about the functional, performance and power implications of my choices before I commit to the implementation. Given these capabilities, relying on the reasoning that “they did it this way before” is getting to close to my son’s justification. The reasons behind it are driven by fear of change or lack of willingness to invest in quantitative analysis. It’s a nicer way of saying it, but it still comes back to cowardice or sloth.

Think about it on your next project, what are your preconceived notions, what are the assumptions you assume to be true because they were in the past? If something is being done just because “it was done that way before,” is it really too difficult to test that assumption? Could an investment in system-level analysis enable the project to make more informed decisions? Ultimately the better we understand the implications of our decisions the more successful our projects are likely to be.

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

By Jon McDonald
I am just back from vacation. My wife and I spent two weeks in Italy. While there we toured the Tuscan countryside, Florence and Rome. We had a rental car for the time in Tuscany. In Rome we didn’t keep the car. Watching the different types of cars and the way they were driven gave me a good analogy for an issue I’ve had a number of discussions on.

As people think about ESL design and what’s most important, I often get the question “What’s more important, software or hardware?” I have heard Gary Smith say, “It’s the System Stupid,” which in my mind implies both hardware and software, but that’s really not enough, either. It’s not just the system. It’s the system and how that system is being used. What is the environment around the system? The environment in which the system has to interact has a huge effect on the decisions that should be made to create a successful system implementation, impacting both hardware and software decisions as well as partitioning.

Getting back to my Italian car analogy, the car would be the hardware, how I drive the car and what I put into the car would be the software, while the roads or in some cases lack of roads I travel over would be the environment.

In the Tuscan countryside there are many dirt roads, locally described as “white” roads. The “white” roads were quite a surprise the first time we discovered one. The countryside is fairly hilly, and since we didn’t pack as efficiently as we might have, we required a significant amount of room in the car. These issues biased us towards a fairly powerful somewhat larger car for our time in Tuscany.

When we got to Rome, getting that larger vehicle to the hotel was a bit of a challenge. In Rome the tiny Smart Cars are very common, and I believe very practical. They fit through amazingly small spaces, and they were parked in virtually any small open space along the road, and in some cases on the road. If I look at the car choices, from our ESL perspective, the car would be the hardware.

What we needed to put into the car would correspond to the software. I could have used either a Smart Car or the larger car we had in the countryside if I only looked at those things. I actually saw a Smart Car carrying more luggage than we had.
In much the same way I can run the same software on many different hardware implementations. In our cars, which one is more appropriate depends on the environmental requirements in which the car is being used. What combination of hardware and software should be realized in my system depends on the environment in which the system must function.

This leads to one of the key points to understand when thinking about ESL design and tradeoffs. We cannot optimize a system or even choose the best hardware/software partitioning without understanding and analyzing how the system will work in its target environment. ESL provides the methodology and abstraction to allow us to quantify these implementation choices and analyze them in the appropriate context before we invest in a particular implementation.

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

By Jon McDonald
If I have flipped a coin 1,000 times and it’s come up heads every time what are the odds that I will get another head on the next flip? The odds on the next flip are still 50/50. The fact that I observe a uniquely unlikely situation has no impact on my current probability, and frankly any sequence of prior results would be equally unlikely. I find some of the same thinking applies when discussing unit-level verification relative to system-level verification.

I recently read a piece by Russ Klein, on finding a hardware problem through software execution. The problem was astronomically unlikely to occur when looking at the hardware without the system context. This resonated with a number of conversations I’ve had with customers recently. When you look at the state space of an element, how do you direct the verification process without knowing how the element is going to be used in the system? Looking at the system, what do I define as a working system? A system may be completely acceptable with a set of elements that may not be acceptable when looking at individual unit level tests, but the way the elements are used in the system results in an acceptable even efficient system.

The point of system-level design is understanding the function and performance of the system. This may be a bit simplistic, but I believe it is important to understand the function of the system in a mode of operation as close to the end system use case as possible, before we worry about exhaustive verification of the system, or the elements of the system.

The state space for most modern complex systems is enormous. Very few designs can be exhaustively verified. The best starting point for testing is to use the system in the way it is intended to be used. The state space may be huge, the odds of being in any given state minuscule, but the application of the system function will drive the system through specific state sequences. The fact that an application drives the system through a sequence of incredibly unlikely states is not really unlikely at all. Most individual system states are unlikely, but the operation of the system must go through some sequence of states to function. When we look at the states in context of the operation of the system, being in a particular state is unavoidable. Looking at the states without the system context makes testing the appropriate states very unlikely.

I think hardware verification at times focuses too much on the unit-level perspective and not enough on the system level context. By understanding the system’s context, the function and performance requirements at the electronic system level, we can appropriately direct the verification for the individual units.

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

By Jon McDonald
Which came first the chicken or the egg? Based on some of my recent discussions I could ask the question in a slightly different way: “Which came first, the hardware or the software?” Depending on your point of view and personal bias the answer may appear obvious, but from what I’ve seen it can be very dependent on your current engineering situation. Adopting one perspective when the other is more appropriate could lead to significant difficulty in a project.

Looking at a specific project, I may find that the software is being re-used from a previous project on a new platform. In this case the software came first and the ESL platform models must be capable of dealing with the hidden assumptions that may have been made in that legacy software. In a specific recent case transaction-level models were being developed for a virtual platform to run legacy software and leverage legacy drivers. The models were developed and tested based on the hardware spec and tested with the software drivers provided by the hardware IP supplier. I’m sure everyone will be shocked to find that when the legacy software was run on the platform it didn’t work. Still more shocking, we found that the legacy drivers had been interfacing to the hardware in ways that were outside the specified interface methods. One specific issue was that the legacy drivers relied on byte addressing of certain registers even though the hardware was specified to support word addressing only.

In this case the software came first and the software drove the requirements of the hardware models. The hardware model may have perfectly implemented the hardware specification, but because it did not implement the unspecified behavior of the hardware block, the hardware model was assumed to be incorrect.

In another project, the software did not exist before the hardware architecture was created. Hardware models were developed using load models for the software. The software and drivers were then developed on the virtual platform. In this case the transaction-level hardware model was the executable spec against which the software was developed. In this situation there was very little risk of the software inadvertently using the hardware TLM outside the specified modes, since the TLM embodied the specification.

Which comes first? Which way is correct? The answers depend on your particular situation. It’s important to understand that the flexibility exists to apply ESL techniques to projects relying heavily on legacy components as well as projects built significantly from scratch. Depending on the situation, different requirements and assumptions may be made with respect to what is considered “correct.” Ultimately which came first doesn’t matter. Both hardware and software exist and must work together as smoothly and early as possible to facilitate successful projects.

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

By Jon McDonald
“Know thyself.” That advice is promoted in so many different forms it’s hard to know where it started. I have been involved in a number of projects recently in which these words would have greatly simplified the project flow. “Simplified” is probably not quite the right word. The issue in this case is not to simplify the project, but to properly understand, characterize and communicate the complexity inherent in electronic system design today.

At DAC last month I had a bit of an epiphany about the acceptance of ESL through the highest levels of the management chain. This acceptance is very encouraging and many may feel it’s been too long in coming.

The steps we must take from this position of acceptance to leverage this state of grace are critical. I believe these steps need to be centered on identifying what we know, what we don’t know, and what are the most important things we need to know. In other words we need to “know ourselves.”

From an ESL perspective this involves understanding the state and capabilities of the various disciplines within our organizations that must work together to attain the benefits of this ESL revolution. Numerous times I’ve seen projects struggle and stall because the drivers did not understand or did not want to admit to the limitations of their own organizations. Make no mistake, adopting an ESL methodology is a revolutionary endeavor. The key is to understand that it does not have to be, nor should it be a revolution for all of the groups involved at the same time.

There are many potential areas where we can start the revolution, but the shape and path of a successful revolution must be planned based on knowing both the organization’s strengths and weaknesses. If the hardware group is at a point of needing more detailed analysis to determine the optimal implementation, hardware may be the best focus for the initial steps down the path. Much can be done at the hardware architectural analysis level without having to disrupt the systems or software groups. Likewise software or systems may be the most receptive areas. Ultimately all areas of the hardware/software/systems engineering organizations will be affected and benefit from the ESL revolution.

By knowing ourselves we can begin in the area that allows a smooth transition with early tangible benefits that will allow this ESL revolution to feel like the natural progression of the engineering processes.

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

By Jon McDonald
Over the past few weeks I’ve spent a significant amount of time at industry shows, the largest of which is DAC. It was interesting to hear the tone of the conversations this year around ESL. ESL has reached a level of acceptance such that it is now being co-opted and interpreted to cover an amazing array of activities.

I have felt for a while that the electronic design industry in general has moved to a point of acknowledging that moving up in abstraction and adopting ESL techniques is a worthwhile investment in time and resources. From many of the conversations I had at DAC it appears that senior management at many companies has bought into the vision, they know they need it and in many cases they have given the order to “Make it so!”

Now it gets interesting. We have management “buy in,” with a vast array of options for what could be done with that “buy in.” Many companies have an existing process built around natural language specifications and ad-hoc analysis at the system level, diving right into RTL development for the hardware pieces and C/C++ for the software. It doesn’t take much imagination to see that to “Make it so!” can become a very daunting task. To deliver on this decree what, what do we need to do first? How do we decide what capabilities will deliver the most value in our environment?

In the past I’ve often been in the position of having a vision match at the lead technical level, then needing to work for agreement from management. In some ways I feel we’ve moved to having the management vision match but need to build the vision match with the technical leaders. In the former case the details of the vision match are well agreed. At the technical level the vision is generally detailed, very complete and specific. The vision fits with what was being done at the technical level because it was developed at the technical level.

In this new case the vision is of necessity more abstract. Details need to be filled in, consideration of the current processes must be addressed and the steps required to begin achieving the value of the vision must be prioritized.

This is an incredible change in perspective. It makes it much easier to get started, but more difficult to manage expectations. As ESL continues to mature the companies that perceive the most value and achieve the highest return on their ESL investment will be the companies that understand both their gaps in the specification to implementation process and their gaps in management vs. technical vision and expectations.

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

By Jon McDonald
I’ve been struggling to come up with a good way of answering a recent question: “Do ESL approaches provide benefits for FPGA design?” I have an initial gut answer that’s somewhat unsatisfactory. Thinking through the subject I can see ways of looking at the question and getting both a “yes” and a “no,” but that’s probably an indication my thinking is not yet clear enough to reach an answer.

I’ve tried to come up with a metaphor to this question that would help in thinking about the possibilities, but I haven’t had any success. What it really comes down to is that the question is incomplete. I believe that often techniques applied to one area of thinking can provide benefit for other unrelated areas, but when we try to move knowledge from one specific area to another we need a clear understanding of what we are trying to accomplish. In a general sense, it would be hard to believe that some benefit for FPGA design could not be derived from ESL approaches. But what are we trying to accomplish? Fundamentally, ESL is focused on a somewhat more abstract view of the system—what and how. What does it needs to do? How should it be done? What constraints need to be met? How do you meet those constraints? What performance and power characteristics are required? And how can these requirements be met?

With ESL approaches we are trying to determine what a system should do and how that system should be implemented before we commit to the implementation. In my thinking a project starts with what and how. Only after we know what and how, can we implement the solution to satisfy the need.

With this flow of reasoning ESL approaches do not apply to the implementation of the FPGA design, but they do apply to what the FPGA needs to do and how the FPGA should do it. For example, to determine if we use more parallel hardware resources or fewer faster resources to process some data we could create an ESL model that would allow us to quickly explore different potential performance, size, power implementations of a function and that function’s use in the system. ESL techniques can help us understand the implications of our implementation decisions before we commit to the implementation, but the ESL techniques are not changing the details of the implementation process.

The answer, I believe, is that ESL approaches do help us determine what our FPGA should be doing and architecturally how it should be done, but the detailed implementation of a design does not gain great benefit from ESL approaches.

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

By Jon McDonald
I have talked to a number of people recently about the justification for investing in an ESL methodology. “What’s the ROI?” is a question I hear fairly often.

I’m currently on vacation in New York City with my family, and during the trip I’ve realized just how subjective ROI can be. What’s the ROI on a $23 deli sandwich? At home I’d never think about paying that much, but in New York I almost consider it a bargain. My ROI is totally personal and also very much dependent on my current situation.

In a design engineering environment there are a number of potential benefits of applying an ESL methodology, but each benefit is only a benefit to you if it has an impact for you. That might sound a little like a “yogi-ism,” so I’ll rephrase it a little: “It only matters to you if it matters to you.” The important thing that’s really come into focus for me is that no one can tell you what the ROI of the investment is for you. You have to understand your own problems, your challenges and your opportunities for optimization.

Best practices can be great things to learn from. Best practices can provide direction and framework for thinking about an ROI, but the ROI only means something if it is specific to your situation, to your particular challenges and opportunities.

I’ve witnessed this in customer adoptions of ESL flows. The most successful customer deployments I’ve seen have been when the customer started by identifying and understanding their own problems, identifying the goals for improvement and how they were going to measure their success against those goals—before they thought at all about the specifics of what an ESL methodology could provide. Once they got to the point of thinking about the ESL methodology they didn’t get distracted by the bright and shiny promises offered by vendors, but they were able to focus on the capabilities that would allow them to realize value based on their specific needs.

At the end of the day if you don’t know yourself, and know what something is worth to you based on your particular situation, you are not going to be able to judge the value of the capabilities provided to you.

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