By Jon McDonald
Recently we’ve been doing some minor remodeling in our house—nothing requiring major contractors. It’s mostly smaller things that unfortunately require a significant amount of personal involvement. Over the course of the past few weeks we’ve had a number of “projects” that we’ve started, then had to undo what was done because we were interfering with another area of work. More than I would like to admit, we fell into the trap of getting ahead of ourselves in the work.

I’ve been working with a customer recently who has fallen into a similar trap in their system modeling. They have been creating fairly accurate, approximately timed, transaction-level models of their system. The system is fairly complex and dealing with many different possibilities at any one point in time. The model has gotten overly complicated because they’ve been trying to deal with problems before they need to.

Essentially, they are trying to predict the next step and be ready for that next step before it happens. From a hardware designer’s perspective this is a very good way of achieving high-performance designs, but this is a level of detail that is only appropriate for the RTL design. This level of detail leads to a tremendous amount of complexity that doesn’t need to be addressed at the transaction level.

The main “rule” I tend to use in transaction-level modeling is: “Avoid any activity in the model that does not correspond to some transaction coming into the model or going out of the model.” This rule is helpful in changing your perspective from RTL to transaction-level.

In this case, the customer followed this rule fairly well, but it wasn’t enough. At each point when a transaction was received they were trying to prepare for what might be coming next. They were getting ahead of what they needed to do to handle the current activity. This involved setting up a lot of data, but some of that setup would not be used, or in some cases had to be undone once the next transaction actually occurred.

The key disconnect in modeling was not in generating activity that did not correspond to transactions, but in doing a lot of work in anticipation of the next transaction. In transaction-level modeling, when a transaction occurs you can do as much work as needed to handle that transaction with no benefit of having pre-computed some of the work previously. The model can perform its work in any amount of “simulated” time, regardless of the length of time it takes for the model to run on the host.

This is very different from the RTL perspective of having a limited amount of computation that can be performed in each clock cycle, which leads to my second rule for transaction-level modeling: “Don’t perform any computations until the result of the computation is needed.” For an RTL designer adopting these two rules in your approach to transaction-level modeling should help ensure your models are as simulation efficient as possible, and as simple to code as possible.

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

By Jon McDonald
I had an interesting discussion with a customer recently. They were involved in the architectural specification of a fairly complex piece of silicon. They spent a significant amount of time designing the part to work under worst-case power characteristics and defining the power supply requirements for the device in this worst-case use mode.

The conversation started with the question: “If we already are designing everything to support worst case power characteristics, why should we care about modeling anything else?” For a system used in a steady state, this may is a reasonable point of view. The system we were discussing had numerous general-purpose processing elements and was targeted for a wide range of end-user applications.

In trying to come up with a good analogy I started thinking about my Suburban and why I would want to know anything other than the worst-case gas mileage. I have a fuel indicator that shows the instantaneous mileage. Driving uphill, or under some heavy load, I often see it drop down to 1 or 2 mph. If I had to plan all my trips and refueling stops around that worst-case mileage, I would be stopping at a gas station every 30 miles. Luckily I do a little better than the worst case in most of my driving. For planning it’s much better to think about the mileage resulting from the expected load. By watching the instantaneous mileage I get feedback that helps me improve the efficiency of my driving under different conditions and allows me to plan the next stop based on the load I’m carrying.

I believe 20 years ago if you were designing something that plugged into the wall you may have considered your power availability to be infinite. Knowing your system was designed to work under a worst-case power draw may have been perfectly acceptable. Today I think most engineers would agree that some level of power conservation should be attempted in virtually all systems.

By modeling the power consumed by my device accurately under various use cases the end user of my device can get some feedback as to how efficiently they are using the device in their application.

Getting back to the original question, if I only care that I can get my device to work, then worst-case analysis may be good enough. If I have a reasonably complex system with multiple ways in which it can be used to solve a given problem, then it becomes valuable to have a model that gives me more accurate feedback as to how efficiently various approaches to solving a problem will use the system.

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

By Jon McDonald
I was sitting in a meeting this week and someone made the statement, “I have to have a cycle-accurate model.” This was a meeting discussing early delivery of system models for software development, performance and power analysis. The final RTL didn’t even exist for the device in question, yet somehow the thinking was that a “cycle-accurate” model was required. I hear this point of view fairly often. I believe it’s a knee-jerk reaction to the historical role of models in the eyes of hardware designers.

During the discussion we explored two questions that evolved from the “cycle-accurate” statement. First, why are the cycle-accurate models needed? What analysis or decisions are going to be made based on the results of these cycle- accurate simulations? And second, what sources of cycle-accurate models exist or could be created? When will they be available? And what is the cost or pain associated with using the possible models?

I’ll start with the second point. For this organization there were historically two possible sources of a “cycle-accurate” model. One is the RTL implementation. The RTL has the benefit of being a required deliverable that was going to be created by the hardware design group as a normal part of the development process and is, by definition, 100% accurate.

There were four distinct disadvantages to this option: 1) The RTL was not available early in the process; 2) It is subject to continual change throughout the development cycle; 3) The simulation performance of the RTL severely limited the amount of software and the types of analysis that could be done, and 4) There are security and cost issues associated with distributing the RTL.

The second historical option was to create a cycle-accurate C/C++ model. This approach had been taken a number of times. The benefits were a model that could be freely distributed, the object code was reasonably secure, and the simulation performance was somewhat better than the RTL. Again there were four disadvantages: 1) The model was generally not available before the RTL; 2) It required continuing investment to track the RTL; 3) It was an expensive additional cost to develop, and 4) While it was faster than the RTL it still wasn’t fast enough for much of the desired software execution and analysis.

Now going back to the first question, why are the models needed, there were two main drivers. First to support software development, this use case involved the largest number of end users. Second to prove the value of the device through performance analysis of the models potential impact in their customers’ applications, this case did not involve as many users but drove tremendous value through using the model to win sockets.

For the software development user, there was no need to have a cycle -accurate model. A fast functional model would provide the best simulation performance, which was the primary need of the software developers. The second use case, performance analysis, could be addressed with the cycle-accurate models, but after further discussion it was acknowledged that the cycle-accurate models had two many disadvantages to be effective in achieving the ultimate goal of winning the socket. Some compromise was needed to balance the simulation performance with the timing and power accuracy. In the end we came to the conclusion that a cycle-approximate model which was about 90% accurate would provide the confidence needed in their customers to “win the socket.”

For their use cases, and I believe for many potential users, the TLM2.0 approach of creating a loosely timed (LT) model for the software developers and an approximately timed (AT) model for use in the performance analysis case would allow the user to select the optimal trade-offs between simulation performance and accuracy to meet their specific needs.

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

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.