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
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

Return on investment is a subject that comes up frequently when people are thinking about adopting higher-level design approaches. After all, we are talking about adding work—we need to model, design, simulate and analyze the system. All of these tasks take time and cost money. So what are we getting in return?

Before we can think about the return, we have to identify what we are trying to accomplish by doing all of this work before starting the real implementation process of RTL design.

We want to predict the future. Before we implement the system we want to understand the implications of our design decisions. If we want to identify a return on investment for this extra work, we have to assume we would have made an incorrect decision without it. Now we are basing the ROI on the probability of making that incorrect decision, and we’ve started down that slippery slope of justifying the return based on statistics. Not that this can’t be done, but it involves much more complex math than we would typically want to see in bulletproof, management-accessible ROI. I believe we need to think about the justification for this investment in the same way we think about the justification for an insurance policy.

This reminds me of the doctor who explains to the patient the options to treat a medical condition without committing to a recommendation. Why can the patient make the decision better than the doctor who has had many years of training? It is because there is no way to prove that one course of treatment will always be better than another. The tradeoffs being made by the patient are subjective; they require a basic understanding of the options and impacts of choices beyond the field of medicine.

We are dealing with a similar problem when we make the jump from a natural language specification to the RTL implementation. The implementation choices made are subjective. It is expensive, difficult and sometimes impossible to prove the best implementation in RTL. Sometimes we can’t even determine if the implementation is acceptable at the RT level.

At the system level we have the flexibility to quantify some of these choices. We can’t prove everything, but we can quantify some of the implications of our selections. This gets to the core problem of an ROI evaluation: Through the ROI we look to prove that value is achieved. Nothing can prove that we could not have achieved the same result by jumping directly to RTL implementation, but system-level design provides incredibly valuable information that allows us to make educated design choices—insurance that we understand the implication of our choices.

So it comes down to how lucky you feel. If you’re really lucky, you may never need your insurance policies. If you’re design groups are lucky, you might get an acceptable implementation. But from what we are seeing in the design communities, our luck is running out. We need the insurance delivered by the additional information we can gain from the system level to guide our implementation choices.

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

The question about ESL language is the right one comes up over and over again.  As customers begin to understand the benefits of modeling and analysis at the system level, they must address this question as one of the first steps in getting started.

What language should be used for ESL—SystemC, SystemVerilog, UML or M? Technically, you can create an ESL/TLM platform in any language you would like. I’ve seen large corporations doing system-level modeling in all of these languages, and then some C/C++, VHDL, and even Java, have been used to do various levels of analysis at the system level. While much of the choice in language is subjective, it’s a good idea to have an understanding of the tradeoffs of using one language vs. another. These tradeoffs include language constructs and semantics, as well as issues outside the language itself—such as tool support, third-party IP availability and access to knowledgeable engineers.

While all of the mentioned languages have supporters, the two main languages I see organizations applying and trading off today are SystemC and System Verilog. At a very high level, the differences between the languages are pretty simple to characterize. SystemVerilog is primarily focused on verification and maintains all of the RTL level focus inherited from its Verilog base. The enhancements related to directed test generation, assertion definitions and coverage metrics are all very valuable capabilities, and all are closely tied to the RTL implementation domain. SystemC is C++. The libraries and standards that define SystemC extend C++ to be a language well suited to transaction-level model definition and simulation of this modeling level.

Because SystemC is based on C++, there are a huge number of experienced users and off-the-shelf examples and libraries that can be used for a wide range of functional modeling applications. The SystemC constructs add enough hardware-specific capabilities to allow the language to support TLM modeling without getting bogged down in the complexity introduced in addressing verification challenges.

I see many customers using both languages and using the languages together. For all of you who have explored the options for creating ESL models and simulations, what tradeoffs have you looked at? What were your ultimate decisions? I welcome any comments from readers to understand the choices between all of the possible ESL languages and methodologies. 

–Jon McDonald, technical marketing engineer, Mentor Graphics

I was talking to a customer last week about his most recent ESL activities and he brought up a question that I’ve heard from many different sources : “How accurate does my ESL model need to be?” The level of timing accuracy, and even function accuracy, needed for effective system level analysis is a very dynamic question, with different answers for different organizations, and even different stages of the design process.

I’ve seen many cases where adopting ESL techniques has been successful and those where it has not worked. One of the significant contributing factors in the failed cases is engineering obsessing about the accuracy of the models they are creating. As organizations look at moving to higher levels of modeling, they naturally come up with a wish list of all the possible things they would like to accomplish with these abstract models. The problem occurs when they then take this wish list and try to satisfy all of it right away in the model requirements.

Moving to a new methodology and trying to answer all the possible questions you might want to answer in one step is a monumental task. Organizations that have been successful in adopting ESL focus their initial system modeling task on the simplest questions that will have a significant impact on key architectural decisions. Then they create ESL/TLM system models to answer those specific initial questions. By taking a small revolutionary step in creating the initial ESL/TLM system, they can then refine this system model in an evolutionary process of increasing complexity and accuracy, ultimately answer ing all of the questions before beginning implementation.

I am eager to hear if you have had the same experience , or not , when creating ESL models. So I’ll propose a few open questions for any of you who have been involved in a successful ESL/TLM modeling effort:

• What has worked for you?
• What level of accuracy did you require in your models?
• What types of issues were you addressing with your effort?