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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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