From a hardware perspective I initially had a bit of trouble with this statement. It seemed like a software-centric statement that discounted the value of the hardware, but as I thought about it from a target system perspective it started to make sense.

For systems with very large numbers of units the NRE cost can become insignificant relative to the overall cost of the end device. If we think about an iPhone with more than 100 million units shipped last year, an SoC development cost of $25 million to $50 million becomes a relatively minor component of the overall cost of the unit. In this context it becomes incredibly important to invest in careful design processes that ensure the complexity in the hardware is thoroughly understood.

One way of improving the understanding of complex systems is to create abstract models of the system, which allow us to capture the important externally visible attributes of the elements without dealing with the internal complexity. This is exactly what we do in electronic system-level modeling. We create an abstract representation of our system that allows us to interact with it in a way that encapsulates the complexity in a model that we can use without dealing with the internal intricacies of the device.

For something with numbers in this range it is easy to justify the additional investment in making sure the complexity is well understood. But for other markets with lower numbers of units, how are we minimizing the cost impact of “increasing, system computational complexity”? Through reuse if IP we are able to amortize the cost associated with the computational complexity over many target systems, but this IP reuse comes with tradeoffs. What portions of a system can be built from general-purpose elements? What portions should be customized? To achieve power and performance goals, what compromises must be made to achieve an optimal system?

We see this challenge in many customers today. SoCs and IP that has been developed initially for very-high-volume end systems is being leveraged and used in low-volume applications to provide incredible capabilities in relatively specialized application spaces. But for this to be effective, the users of the IP must have a way of quantifying the effectiveness of the IP in their target system. The challenge today in minimizing the cost of computational complexity in our systems is not one of designing the complex system, but one of using the existing complex IP effectively and appropriately, and creating custom hardware design only for the portions of the system that will really benefit from the investment.

To this end, much of the use of ESL tools I see revolves around bringing the information contained in the complex hardware back to the system-application level. This is generally the application software developer. The user of the IP cannot afford to be mired in the complexity of the IP being used, but they do need to know if the IP is effectively meeting their needs. They also need tools and information to understand how to tune IP use and augment the IP when necessary to deliver a complete optimized system.

Ultimately, ESL modeling of our complex computation elements contributes significantly to minimizing the cost impact of that complexity on our systems.

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

We are always searching for the ideal solution. It would be wonderful if one model would work for all of our analysis, but unfortunately this is not the case. Many different levels of modeling are needed to answer different questions at different points in time. With the current methodologies and standards there is a lot we can do to leverage the modeling investment. The work done to create one model may be a portion of the work needed to create a model for another level of analysis. To enable this reuse, however, we do need to think about what the models will be used for. Moreover, we need to plan the modeling points to allow as much reuse as possible.

I believe general best practices have pretty clearly settled on a small number of modeling levels that are being fairly widely used for electronic system-level design. The focus in this level of design is on hardware, software and system validation and analysis. The names given to the various modeling levels may vary based on who you are talking to and what domain they are working in, but I think the abstraction points have coalesced into three specific levels of modeling before we get to the RTL implementation of the hardware.

Initially the most abstract level for the electronic system would be independent of the hardware implementation details, would abstract away the low-level driver issues, and would only model the unique custom hardware functions that will be accessed by software. This level of modeling would not require cross compiling of the software. Instead, the software would be compiled natively on the simulation host and software libraries are used to link the native host-compiled software to the unique hardware models required. This is often the initial level of homegrown hardware-software integration projects. There are also a number of commercial offerings targeting specific platforms. One example involves the AUTOSAR simulation stacks, and another involves Linux KVM user space emulation.

The next major step would be to add enough detail to allow execution of cross-compiled target software on the model of the hardware. This level allows detailed functional validation of the software, the hardware and the system interaction. At this level the target processor and full register interface for the software accessible elements must be defined. The communication paths must be defined, but the implementation of the communication paths is not necessarily needed. Many hardware architectural aspects of the system can be ignored or dramatically simplified such as the caches, bus and memory structure. The detail in the simplified models needs to match the areas being targeted for functional exploration. This is probably the most common level I see in terms of current implementation and usage of system level design today.

The final step before RTL implementation would be to add performance information for architectural and hardware software tradeoff analysis. This level targets the final decisions on what should be implemented in hardware and what performance requirements should be placed on that hardware. At this level we want accuracy in the communication paths, the processing nodes and estimates of the performance of each element. This is not a cycle-accurate model, but a performance model appropriate for tradeoff analysis targeting implementation decisions. Most of the questions related to system performance require this level of accuracy to provide a reasonable answer. Prior modeling levels do not have the architectural accuracy to be used as performance models.

Each of these abstraction levels can build on the information and models created at the level above. One model cannot answer all of the questions, but the set of models can answer many of the questions we would have prior to committing to the RTL implementation. There will still be questions that must be answered based on the RTL detail and other questions that will require even more detailed levels, but we want to and can answer many questions with the earlier more abstract models. By properly ordering our questions to correspond with the current model capabilities we can gain value from each level of model while leveraging the information defined and gathered at each modeling level in creation of the next level in the chain.

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

Initially, this sentiment appeared to be somewhat harsh and maybe even misguided. After all, massive interdependence between hardware and software determine the success or failure of many products today. SoCs are getting so large and the NRE cost is such that first pass success is often required to have a competitive project. Given the scale of the consolidation of hardware and software onto an SoC, I felt there should be a similar level of integration between the hardware and software developers. This felt right to me as a hardware developer, but it did not appear to feel right to the software developers.

After a little more reflection, I realized that the software developers and the hardware developers cannot be forced to work together. And, while the success of their products may be heavily influenced by the hardware and software working well together, the hardware and software engineers don’t necessarily have to work well together.

They really are working independently. Software developers don’t need to know that much about the details of the hardware design. They don’t need to know the intricacies and tradeoffs in the bus structure or the memory subsystem latency. But they do need to understand the impact of the way they write their software on the performance of the overall system, and they do need to understand if they are using the system as efficiently as possible.

It’s like driving a race car: I don’t need to know exactly how the engine functions, or how the steering connects to the wheels, but I do need to understand the power and performance capabilities delivered by these elements and use them effectively to achieve the best race results.

On the other side, hardware developers need the software to be able to understand and optimize the system for the true workload it will be facing . They don’t necessarily need to understand the software, but they do need to understand how the software uses the hardware, what kinds of utilization will be achieved, and where bottlenecks might exist in the system as it performs its intended function.

I believe the truth of the matter is that the hardware and software engineers do not need to work together directly, which is probably a good thing because often they don’t want to work together. Still, they each need to work in a context that makes the implications and decisions made by either side obvious to the other. Ultimately this is one of the tremendous values delivered by system-level design. The hardware community can create a virtual model of the system that is used by the software developers. Just like the racecar driver learns how to most efficiently drive the car by the very act of driving it, the software developer can learn how to most efficiently use the hardware through programming it, and the hardware developer can analyze the performance of the hardware under software load to optimize and tune the hardware.

In the end, I believe we will achieve tight integration of the hardware and software communities not by forcing the engineers to work together, but by linking their work through a virtual platform that benefits both communities without disrupting their development processes.

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

Recently I was involved in project discussions around this topic. One aspect of the discussions was to try to understand what level of accuracy was needed in the models being created to support software development. The discussion was challenging due to the vastly differing perspectives and concerns of the individuals involved. The hardware developers were responsible for creating the models of the platform and wanted to know what level of detail and performance was required in the model, but the hardware group was going to use the models in a very different way than the software team would be using them. The software team just wanted to be able to run their software. They didn’t want to deal with the complexities of the modeling.  The software group wanted the software to work as it would on the physical hardware when it became available. They wanted an interactive runtime performance as close to the real hardware as possible, and they wanted it now.

These very open-ended and competing requirements from the software developers didn’t help to focus the modeling requirements. Through additional discussion on the questions and tasks that needed to be addressed by the software developers a number of characteristics of the modeling platform were identified. For a portion of the development, a functional model would suffice. While developing initial software functions and modules the focus was on logical correctness of the software—the model would need to deliver a fast interactive runtime experience to allow for the interactive debugging needed to develop the functions. They had experience with transaction-level modeling at the loosely timed (LT) level and felt this would deliver a very good platform for this class of software development.

The system did have unique hardware content that was developed for a reason: They had specific targets for performance, throughput and power that must be met and those targets needed to be verified with the software running on the hardware. For this detailed verification they needed a cycle accurate representation. The only thing that would deliver the accuracy required for this sign off was the RTL model of the hardware. Due to the limitations of RTL. late availability, slow runtime performance, and limited ability to make changes, the RTL was accurate and appropriate for the final signoff. But it was not appropriate for use during the development of the system. Development of the system included both the hardware and software components of the system.

For a significant portion of the system-design process, which included both hardware and software, the LT models would not provide the accuracy required and the RTL had too many limitations. Compromise is much easier once the realities of the choices are accepted. The compromise was to enhance the transaction-level models to a level of accuracy that allowed for the performance, throughput and power analysis required to make the system design choices accurately. The approximately timed (AT) level of modeling defined by TLM 2.0 allowed for the accuracy, early access, flexibility and runtime performance required for this level of analysis.  AT-level modeling is a compromise that sits between the pure runtime performance of an LT model and the implementation accuracy of the RTL. While initially the groups were reluctant to accept the compromise, after understanding the alternatives they realized AT delivers a unique set of capabilities that cannot be addressed by the other modeling levels. That made it a worthwhile addition to their development process.

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

Recently I’ve been working with a customer that has been split over acceptance of a system-level design approach. A portion of the organization was willing to invest in SystemC transaction-level modeling and a portion relied solely on RTL and emulation for both system verification and software development. The situation has evolved to the point where the customer now can show the benefits and tradeoffs associated with both approaches. To me, one of the most satisfying outcomes of the customer’s activities is a growing understanding and appreciation that both approaches are valuable and worth investing in, and both provide specific benefit that will far outweigh the costs associated with the activity.

On the RTL side the customer believed, based on what they’ve seen in the past and a small amount of “frothy eloquence,” that they could perform the full-platform verification and achieve reasonable software execution speeds using emulation. This they have shown. And because the RTL is the final specification of what is being implemented, this is the ideal final sign off before tapeout.

On the TLM side they believed, based on industry information and relying slightly more on that “frothy eloquence,” that they could achieve a robust software development platform, which would also provide some level of system validation and performance feedback. Additionally this TLM approach would be more flexible, easier to deploy and experiment with, and significantly faster than the RTL implementation. They’ve now proven this is the case, and with significantly less effort they’ve been able to show that the software runs very efficiently on the TLM platform. They can both debug and verify detailed system attributes of the software interacting with the hardware. They’ve been able to quickly expand the usage of the TLM virtual platform model to additional software developers. And they’ve shown that the TLM platform executes approximately 50 times faster than the RTL on the emulator.

In this instance it’s nice to see an organization progressing from needing to believe the eloquent promises of a system-level design approach, to being able to quantitatively show, based on their own experience, the benefits of adding system-level design to their process.

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

In one case we were reviewing aspects of a potential design change, trying to decide the best way to approach a modification to an existing architecture. Through review of the existing specification and new requirements, as well as white-boarding of the potential modification, we came to general agreement on an approach to modify the system. It was agreed that it was a fairly low risk and a relatively straightforward modification to the design.

In this case the change was deemed to be simple enough that, part of the team went off and started modifying the RTL to implement the specification change immediately. A SystemC transaction level model of the original system existed as well. The estimate was that the RTL modifications and testing would take a couple of weeks and the transaction level model update and testing would take a couple of days.

During the review it was suggested that testing of the modifications in the transaction level model might not be needed. Through what some thought was an over abundance of caution it was decided to begin implementation of the changes in the RTL and the TLM at the same time. Modification of the transaction level model actually only took a few hours. The change involved altering the way in which a hardware accelerator was accessed in the design. This meant some restructuring of the busses, modification of the hardware accelerator interface and a change to the software driver. Initially the change appeared to work as expected, within one day the transaction-level model had been modified and some basic smoke testing of the change had been done to verify that it worked as specified.

A number of different use cases existed and a fairly significant amount of software was in place that would interact with the accelerator in various ways. Regression tests were set up for that night to run through all of the software tests on the modified architecture. The next day it was discovered that a number of the tests had not completed correctly. With a little bit of debugging, an issue with the interface was discovered that could cause a deadlock. It was a minor issue that required a small addition to the implementation of the hardware accelerator interface to avoid the situation. The specification was modified and the need for the change was pointed out to the RTL implementation team.

During a debrief discussion an interesting point came up. The RTL verification flow could not execute all of the software. It attempted to test all of the use cases, but not by running the actual software. In fact, this issue probably would not have been found until software had been run on a prototype board if the transaction level model had not identified the issue.

I’m not sure of the source, but an axiom that has been applied in both software and hardware worlds, “If it’s not tested, it doesn’t work!” In this case an addition to this would be to say that it should be tested as soon as possible.

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

It’s such a simple concept, but one that was forgotten in an interaction I had recently. In this case the goal of the organization was to have one set of tools for embedded software development and hardware/software verification. No one was quite sure why this was a goal or what the benefits of this goal would be, but somehow it became a requirement for the organization. As a result of this goal we found ourselves having a number of circular conversations.

Focusing on the needs of the software developers led to certain capabilities that were important and a good approach to delivering those capabilities was reasonably apparent, but looking at the flow of the verification activities we identified different needs, requiring a different mix of capabilities. In addition, there was a concern that some users would have to use both the software IDE flow and the verification flow. As we cycled through focusing on each target flow we found ourselves cycling through potential solutions with no single solution satisfying both tasks requirements.

Back to my epiphany on the beach—different conditions and activities require different kites. Similarly, different engineering tasks require different tools. Now that sounds pretty obvious, and I don’t think anyone would disagree that different tools are needed for RTL design versus layout, but the challenge is seeing that different types of the same basic tool may be needed for different activities. To someone who isn’t trying to kite-surf, a kite is a kite is a kite, but when you are trying to use it in a specific situation with specific wind and water conditions one kite may be very different from another.

When applying ESL methodologies and tools it’s important to understand that there are many different tasks and that different tools will be used for different purposes, even for one application such as our software IDE we may use different tools at different times. We need to understand when and why this may be needed, making the appropriate selections to allow the task to be completed as gracefully as possible.

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

I always get concerned looks from those going by in their enclosed vehicles—from some, “concerned” might not be the best description. On the motorcycle I’m prepared for the rain. My response to it isn’t the same as those traveling in an enclosure, but based on what I have to work with it isn’t a big deal. I think some of those going by in their enclosures would disagree and consider the situation unacceptable on a motorcycle. I understand my choice in putting myself in this situation, which makes dealing with the tradeoffs acceptable to me.

Recently I’ve been involved with two different organizations putting themselves in similar and very challenging positions. Each had very different levels of acceptance of the implications of the situation they were in. When we’re dealing with early system design, we may not have all of the details necessary to fully characterize a system. Architecture factors that affect the system performance and capabilities may not be fully implemented, or even well understood.

In this case, both situations involved engineers attempting to create early virtual prototypes for systems analysis. Both organizations had created SystemC transaction-level prototypes that allowed them to run software and get some level of performance feedback. On one side, the users of the platform had more of a hardware engineering focus. On the other, the users were much more software-centric. While some of the challenges each organization was dealing with were very similar, the responses to the issues were very different. Some of the key issues included accuracy of the platform, user interface to the model and completeness of the system.

Each organization had made a choice in putting themselves in a situation different from their traditional situation. In each they were having success, but the way they were dealing with the issues, and the issues they felt were most important were very different based on their previous experiences. As organizations adopt system-level design approaches, I believe it is very important to take into account the histories of the users. Some effort needs to be invested in understanding the use model expectations. In some cases the tools and techniques can be but in place to match expectations, while in other cases the expectations must be modified to accept dealing with the tradeoffs of the situation.

Similar to the reality that I do not have the same expectations from riding a motorcycle as I would driving a car, engineers and organizations should not expect the same issues when using a virtual prototype that they would expect in using a physical board. The capabilities and challenges of each are unique. Understanding this will allow us to make the best tradeoffs in our development processes.

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

After much browsing I decided on a Ducati, I picked it up a few weeks ago. It has an impressive number of user adjustable electronic controls, everything from ABS, traction control and computer controlled throttle. It’s a fun bike with plenty of power. The dealer made an interesting suggestion: The bike has quite a few settings and adjustments that can be made by the user, but he said to be careful not to play with the settings too long while the bike is not running. The electronics consume significant power and apparently don’t reduce the power draw much when the bike is on but not running. I guess they didn’t invest much in standby power for the electronics.

For a motorcycle that isn’t generally turned on when it’s not going to be running this probably isn’t a big deal, but it reminded me of conversations I’ve had with designers who don’t feel they need to design for anything except max power. The idea is that if you’re not running on a battery, power isn’t a big deal. I remember some statistics that had been published by Cisco a few years ago, which had shipped 5 million systems over a two-year period. If each system had conserved 1 watt they would have saved 16 million kilowatt hours of electricity per year. That would have eliminated the equivalent CO2 emissions of 12,000 cars. Even though they were plugged in they still realized the impact of power efficiency when you scale to a large number of units.

With a quick Google search I found a more current reference from standby.lbl.gov, “An individual product draws relatively little standby power, but a typical American home has forty products constantly drawing power. Together these amount to almost 10% of residential electricity use.” This is a significant impact on our energy consumption and a result of the attitude that power efficiency isn’t important for plugged in applications.

Historically hardware designers didn’t have the tools to design for much more than peak power considerations. Using current tools and languages, namely transaction-level modeling, TLM2.0 standards and ESL design methodologies, I’ve worked with customers optimizing their applications for all aspects of power use. Optimizing and balancing peak power for an application is an important factor. In fact, with the ESL approaches the peak power can be much more precisely characterized for an applications workload compared to approaches relying on spreadsheet worst case analysis. In addition to the peak power we can quantify the effects of low power and standby modes tuning the power draw to the workload that needs to be processed.

Subjectively I believe there has been growing recognition that all types of power consumption should be intelligently designed. We, as consumers, are going to use power to run all of the electronics we need to get through the day, but we are realizing that our electronics can and should be tuned to use only as much power as needed to do the work we are asking them to do. We, as designers, are realizing that the power efficiency of our designs is impacting the success of those designs in the market.

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

At DAC there was a significant amount of discussion on integrating the software with the hardware design. It appears to me to be generally accepted that the hardware cannot be designed in isolation. Optimization of the hardware requires analysis of the system, which requires inclusion of the software and real data sets to understand the implications of our trade-offs in the design. The SystemC TLM 2.0 standard generally has been effective at allowing us to model the system at a level appropriate for this mixed hardware/software performance analysis.

At FTF the discussion was around understanding the performance of the software on the hardware and the need to have an accurate model of the hardware to get early feedback on performance, also using this model to tune the software to the specific hardware capabilities. It was interesting to hear more software-focused users accepting the need that the software cannot be designed in isolation. The software must be developed in the context of the hardware it will be running on. These software and system centric users were looking at the capabilities that can be provided by SystemC TLM 2.0 models, to provide that early link of the software analysis with the hardware dependencies.

I believe it is very positive that the software, systems and hardware communities are coming together on the needs and benefits of modeling the system in a way that the interdependencies of the system can be understood by all of the different groups. Each group is accepting that their work cannot be completed in isolation. Each must take into account the decisions and trade-offs made by the others.

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