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.

By Jon McDonald
Over the past few months I’ve worked with a number of customers on new designs. Thinking about how these designs were evolving in the various organizations led me to an interesting epiphany related to the application of Gall’s Law to system design.

Gall’s Law is a rule of thumb from John Gall’s Systemantics: How Systems Really Work and How They Fail: “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”

This was very apparent in each of the “new” designs I saw. The traditional approach is to get something working, then continue to enhance and evolve the design over a number of generations of new products. This strategy gives us a reasonably reliable path to a working complex system, but it can take a long time to get there.

I realized that what we are trying to do with system-level design is not change Gall’s Law, but change the level of definition—and therefore the level of effort—required to get the initial system working and make each successive refinement. By leveraging the abstraction of the transaction level we are able to quickly get the initial working system.

Another less obvious benefit is that the flexibility of the system is much wider at the transaction level than at the RTL. We can take a working system and make significant architectural changes to the system with simple evolutionary steps. Many of the changes we can make by evolving our previous working system would have required a more significant redesign using traditional RTL approaches. This would potentially require us to start from scratch on portions of the design.

I’ve noticed improvements in the ability of the customers I’ve worked with recently to be creative with the architecture. Because they can quickly evolve a working architecture into many unique and creative options at the transaction level, they are able to have much greater freedom in their system implementation.

System-level design is not changing the rules for designing complex systems. System level-design techniques and transaction level modeling are changing the way the rules are applied to complex systems design.

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

By Jon McDonald
When something comes up once it may be an anomaly, but when the same thing comes up multiple times in a short period of time there’s a good chance it is a more general trend.

At Mentor we have tools focused on Systems Engineering and UML/SysML, as well as SystemC ESL/TLM focused tools. We have invested effort in integrating the tool flows, but I had not seen significant drivers for a combined flow. Recently I’ve been involved with three customers deploying very similar UML/SysML-to-SystemC combined flows. Through these interactions it has been interesting to see how the users in the various groups are focusing on their particular portion of the design space and applying their bias to the other space.

The flow that is emerging at all three customers has the systems engineers using UML/SysML to specify the system in much the same way they have been doing the specifications since beginning to use UML/SysML. From the UML/SysML they then generate a SystemC model for use as the initial functional core, which can be used to start the architectural model in the SystemC ESL/TLM domain. The model that is created in SystemC from the UML/SysML is a direct 1-to-1 mapping of the UML/SysML to SystemC; the initial SystemC model will simulate and can be verified to behave as defined by the original UML/SysML description.

There were a number of challenges in achieving a flow from the UML/SysML to the SystemC. First, not all of the UML/SysML was targeted to SystemC. Only those portions that were potential targets for hardware implementation were targeted to the SystemC. Second, the systems engineers had to spend some time to ensure that the UML/SysML they were creating was complete and consistent. Previously they had been using the UML/SysML for documentation and some of the initial specifications were incomplete or inconsistent. In attempting to execute the models in the SystemC, domain errors in functionality or completeness became very obvious. And third, a good deal of discussion focused on ensuring that the systems engineers were not implying architectural restrictions that were not required by the target systems. Achieving this required the systems engineers to focus on the requirements of the system, attempting to keep the UML/SysML descriptions independent of the implementation choices.

In the SystemC domain the focus was on taking the abstract functions and beginning to partition the elements into a potential architectural solution. At this point the architectural possibilities could be explored, beginning to map the abstract sc_interface-based communication to specific TLM2.0 communication paths and implementations surrounding the UML defined messages.

Through the course of these exercises it struck me as interesting that the issues and changes in perspective required to effectively move back and forth between the UML/SysML domains and the SystemC/TLM domain are very analogous to the change in perspective required in moving from RTL to SystemC/TLM. Ultimately I believe tremendous value can be derived from streamlining the flow from the Systems, to Architecture, to Implementation. Each stage can leverage the previous and jumpstart the following stage. Significant investment has been made in the ESL link to RTL. I believe the Systems to ESL link is ready for investment, as well.

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

By Jon McDonald
It’s all about the models. Sometimes I get the feeling that progress is blazing along. Everyone I talk to is interested in ESL design. The value of the capabilities and possibility of dramatic impact on the design process is monumental. It’s kind of like having an amazing sports car that will blow everything off the track but you are stuck on an island with no track and no way off. You need a bridge to get you somewhere interesting.

In today’s ESL world there are many powerful tools offering powerful capabilities, but those capabilities can only be used and compared to other options if they can be run on the same track. In my thinking the models become the track—not just the track, but the roads, the bridges and the infrastructure to allow commerce.

Having standards like TLM 2.0 for model interoperability has given us a tremendous path to realize the benefits of an ESL design methodology quickly. I’ve started to see users demanding models from their IP vendors. In some cases decisions about which IP to use have been significantly influenced by the availability of transaction level models suitable for early ESL design and analysis. This is the trend that I believe will ultimately transport us to a state in which models are ubiquitous.

As users depend on models of the IP to perform early tradeoffs, it will become impossible to successfully deliver IP without providing these models, which in turn will magnify the benefits realized by early ESL design and analysis. It will be much faster and more reliable to get to that initial working architectural model leveraging existing IP rather than creating everything from scratch.

As users we can help the process along. There is no justifiable reason not to support the standard languages and interface specifications. As users—by making it known that model availability and open-model conformance to the standard is a requirement—the economics of success will lead IP providers, model providers and tool suppliers to deliver the models that everyone needs to be successful in adopting ESL.

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

By Jon McDonald
I am amazed how often simulation performance comes up when discussing SystemC and transaction-level modeling. Some of this I can understand. If you are new to transaction-level modeling the implications can take a while to get a handle on.

Fundamentally it is difficult to justify the investment in TLM if the models are not significantly simpler to write and significantly faster in simulation. Many times I’ve heard the complaint that the simulation is too slow and when I look closer at what is happening the problem is not in the SystemC simulation or the transaction-level concepts, but in the way the models are being written.

Today this came up from someone who had been using SystemC for quite a while to do what they thought of as transaction-level modeling. In looking at their example it struck me that most of the problems I see in users trying to move to the transaction level are caused by the fact that they don’t really understand what it means for the model to be driven by the transactions.

A simple example might help me articulate the point. Think of a timer that you program with a value and it counts down triggering an event at 0. One way I see this coded would be the following:

while (count != 0) {
count = count – 1;
wait (clock period); }
myevent.notify();

This is fairly simple but very inefficient and does not align with the transaction-driven concept of TLM. If you switch to a transaction-driven way of modeling you could write this as:

wait(clockperiod * count);
myevent.notify();

In the first example the cycles are counted to identify the point at which the action should be taken. In the second case the single wait is executed waiting the appropriate amount of time before the action is taken. This simple concept comes up over and over again when I look at new, and sometimes not so new, users creating what they think are transaction-level models.

In my mind the first case is not a transaction-level model; this snippet is really modeling the cycle by cycle activity of the model. All of that cycle activity is happening without any outside interaction, nothing comes in and nothing goes out, but the model is doing some work every cycle. In the second example the calculation is done to identify the time at which some action should be taken and the model simply waits for that long. There is no need to perform any of the cycle-by-cycle activity. The second approach is slightly simpler and significantly more efficient from a simulation perspective. I’ve seen examples where correcting this type of problem can take a simulation of a few hours down to a few minutes.

From what I’ve seen many of the complaints about simulation, performance of TLM-based SystemC designs can be addressed by fixing the models. If the models communicate with transactions and only send the transactions that need to be sent then the SystemC TLM approach can be comparable to a dedicated C/C++ model.

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

By Jon McDonald
A rose by any other name is still a rose.

I have had the opportunity to speak with a number of different groups recently, covering everyone from systems engineers focused on specifications and documentation to software teams, architects and implementation groups. Each group has their own unique language, their own unique way of communication. Some of the most entertaining conversations have taken place when the meetings have had more than one of these groups represented. Each group uses certain words that are overlaid with significant assumptions based on their specific domain. I’ve seen extended animated discussions due to this difference in interpretation of the same words.

In applying ESL design techniques we need to bridge these various domains, hopefully enabling a common understanding between the groups representing these differing domains. With all the different semantics it can be very difficult to achieve consensus even though the competing statements may actually be describing the same things.

I believe one of the central pillars of ESL is the adoption of the concept that elements communicate using abstract transactions. In my mind this statement is very simple and very clear, but unfortunately it must be interpreted in other contexts. What I think of as a transaction may be thought of as a message to a software developer, an event to systems engineer or a signal to an architect. Each of these groups uses different terms and in some cases the same term is used in different ways from one company to another.

As I’m thinking about this I am struggling with a way of expressing this in a concise unambiguous way. What is this transaction that is so central to ESL? In many people’s minds ESL and Transaction Level Modeling are synonymous. “A transaction is a message between elements.” While that’s a true statement it isn’t a very satisfactory definition because it relies on another heavily loaded term, “message,” which is has different implications for different groups.

What if I define this transaction concept as the communication of some instruction with the data associated with that instruction? That may be a bit better, but it’s still incomplete. I have to add that the communication occurs as a conceptual atomic activity. There we have another incredibly loaded phrase, “conceptual atomic.” To me this is very concise and carries a very specific meaning, but for those of you interpreting this outside the context of my mind it may not be as clear.

I’m beginning to feel like I’m in the midst of an extended animated discussion with myself, which I don’t believe is a productive activity. Unfortunately, I believe the only conclusion I am able to draw is that we must rely on the heavily overloaded terms used in the various domains. Our challenge is using the right term in the appropriate domain to communicate the correct understanding, which is after all the very basis of the transaction to begin with.

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

By Jon McDonald
I’m on a cruise this week. I’m spending some time thinking about things other than work, but from time to time even normal life does have an impact on esoterically engineering concepts.

As the cruise has visited a number of different ports my wife and I have made many assumptions—assumptions about what we both want to do in port, assumptions about what will be available, what the local attractions might be like, and assumptions about what each of us is thinking about all of the previous assumptions. Some of those assumptions turned out to be not very accurate, the most disruptive being the last category listed.

It struck me that in designing complex systems, engineers make a monumental number of assumptions. We assume that two people can read the same specification and will understand what is needed from that specification. We assume that what we intend to implement is what we have actually built. We assume that what we built will meet the needs of the system. The entire design process could be viewed as built on a series of assumptions.

To be fair making intelligent assumptions is the only way to build increasingly complex systems without reducing the process to a completely serial endeavor that would take much longer than we have to deliver the end system. I believe some of the most significant areas of improvement in the design process have come from a desire to reduce the number of assumptions that are being made in getting from the specification to the end system.

This desire to reduce the number of times we assume is significantly addressed by adopting ESL approaches. We can quantify and analyze the implications of our choices in defining an architecture to implement our specification. This becomes an unambiguous definition of at least a portion of what our system is intended to deliver. I found on my cruise that assumptions about what we expect someone else to do are often the most costly.

In system design we need to clarify the assumptions made between the Systems Engineering, Software and Hardware groups. When the work of these groups is based on disagreeing assumptions the cost of these variations can be extremely high. By designing at the system level and sharing this design between the groups we can greatly minimize the number of assumptions, which ultimately allows us to deliver a more robust system in the end.

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

By Jon McDonald
Recently I have been involved in a number of activities with customers, bringing together their hardware, software, algorithm, and systems engineers to understand how to improve their processes using ESL capabilities. This included inviting experts from the various EDA technology areas to explore the best approaches for applying the full range of ESL capabilities to specific customer situations.

This ended up being a very enlightening experience. It clearly reminded me of the story of the blind men describing the elephant—each of the experts, including myself, being a blind man, the engineering processes encompassed by ESL being the elephant, and the customer being the wise man with a vision of the entire beast.

In our case the experts broke down into four rough categories, which corresponded well with the customers’ engineering organizations. The software engineers identified most closely with the UML expert. Together, they identified a number of ways in which the process could be improved, one of the most significant being the formalization of classes and methods before implementation. The hardware engineers were in sync with the SystemC expert. Both were interested in characterizing hardware performance, identifying ways in which design decisions affecting implementation could be better understood before going into detailed implementation. Algorithm developers identified with the analog expert. Finally, the systems engineers were most interested in the SysML slant on UML, seeing value in the clear specification of the system before beginning the design process. For each domain, formalizing the characterization of the system, providing a capability to understand the decisions and tradeoffs, was key, but each area had significantly different ways of achieving this goal.

Each of the experts had a compelling vision about how to improve the process. In looking at each area independently it was relatively easy to understand the capabilities and advantages of applying the technology to the problem. The challenge was that while each specific area was reasonably well understood, the complete process required the integration of the independent areas for the smooth operation of the engineering organization.

For me, this highlights one of the most significant challenges in applying ESL techniques and realizing the benefits of ESL process improvements. Each discipline in our engineering processes can benefit from the application of ESL techniques, but to understand and realize the maximum benefit we have to understand and appreciate that these disparate organizations work together to deliver a complete product. Thus, our application of ESL technology must improve the process in each particular area while linking each area with the rest of the development process.

Just as our elephant cannot be completely or accurately described by focusing on only a leg, trunk, or tusk, the ESL process is not completely described by systems, software, or hardware domains alone. It is all of these domains working together that delivers the amazingly productive process that a full ESL solution offers.

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