ESL: The state of the industry and what’s next?

By Ran Avinun, Cadence Design Systems -- 8/19/2008

Late in 2006 I wrote an article about ESL that referred to the need for enterprise system-level (ESL) solutions. That article referred to the two underlying goals or principles that have helped define ESL since the mid ‘90s and how ESL needed to broaden its overall scope to benefit the industry and fulfill its promise. Looking back, the initial two principles for ESL still hold true:

1: ESL must optimize the process of making architectural decisions for specific system characteristics (mainly for quality)

2: ESL must work towards verifying system-level functionary, including all hardware-software interfaces, before committing to silicon (in order to increase predictability and reduce time-to-market).

While ESL continues to remain in its infancy, there are signs within the industry pointing towards eventual mainstream usage. With the rapid migration towards advanced process nodes (high capacity), increased hardware and software complexity, and the pressure to reduce the number of ASIC/ASSP designs (including the need to use the same IP or in some cases the same device for multiple applications) – it is no wonder ESL is moving faster towards reality. In fact, in a presentation that ARM gave at a Cadence System Level Verification seminar, ARM stated that “Software complexity will drive industry change.” The ESL environments are also exposing a need to further increase efficiencies of design development. That is, the need to efficiently create multiple versions of a design (i.e. derivatives) without recreating entire RTL code structures.

Therefore, in addition to the two principles described above (with the intent to improve quality, predictability and time-to-market), there is an adding pressure to increase productivity.

Increasing productivity can be accomplished by reusing the investment made in ESL models, thereby moving design entry to a higher level of abstraction. For design: the number of lines of code needs to be written is lower since a synthesis tool will be adding in the details (such as pipelining, etc.). This means it takes less time to write the models, and that derivatives can be controlled via constraints. For verification: debug becomes easier (since it can be done at the transaction level and not the signal level), while simulation becomes much faster. In fact, the verification platforms created can be distributed to software programmers as an early development platform.

So if everything is so good, why aren’t we getting there faster? Lack of abstract models or System-Level IP, is a big reason for the slow ESL adoption. To create a high-performance platform of a device, as needed for ESL, this IP is needed. While custom blocks (the secret sauce) can be created, what can be done with legacy IP that is written in RTL? How should standard interfaces like PCIe or processors be handled? How can RTL designers write models for these custom blocks, when they are not familiar with this environment? Finally, there is a lack of automation and methodology in the whole ESL area, which is where tools can help significantly.

Obviously, there is another important question being asked by the EDA vendors: how can money be made there? Eventually, when the flow work and users will be convinced that they get higher productivity, they will be encouraged to migrate and money will flow into this domain.

In order to address the two principles above and the productivity gap, there are four areas that the industry -- EDA vendors, customers and the eco-system -- needs to focus on at the SoC level in order to accomplish the ESL promise.

ESL: How do we make progress?

1) Reusable System-Level IP/VIP

During the last decade, many users have struggled as they tried to maintain their system-level IP code using multiple levels of abstraction with multiple source files. Others have attempted to create architecture-level models/platforms after their RTL was defined. Rather than forcing designers to migrate their entire platform to a higher-level of abstraction, the initial focus needs to be at the IP level. This will directly address productivity issues (i.e. producing more RTL lines per day with higher level of re-use). To re-use IP models within different process nodes and different applications, the design intent (constraints) and the functionality of the design need to be separated. This separation is much simpler and easier to implement at the micro-architecture level if this concept is adhered to rigidly and the tools used support this methodology. By defining a single level of abstraction as the “golden” source with an automatic path (through synthesis) to verification and implementation, users will ensure higher productivity, increase re-usability with their newly created IP, and prevent maintenance for multiple sets of models.

In order to support this approach, the synthesis tool needs to support hierarchy, both control and datapath structures with incremental engineering change order (ECO) and should be able to automatically create IP in multiple levels of abstraction. As the number of new IPs, using high-level of abstraction, increases, an eco-system develops supporting the new methodology. System integrators and software developers will also be encouraged to use the original IP as part of the initial platform while designers will be able to re-use the same system-level IP for different applications by simply changing the constraints based on their specific needs.

The verification methodology should be created in parallel and support multiple levels of abstraction. It is expected that designers will initially use portions of their verification techniques within a higher-level of abstraction and will complete their verification and system-level validation at RTL level. Over time this will all lead to more of the RTL verification moving to higher-levels of abstraction. High-level synthesis capabilities promise trends in this direction. All this automation will drive designers and verification engineers to adopt these methodologies much quicker.

2)  Concurrent HW/SW High-Performance Platforms

As complexity and embedded software content of new systems increases, HW/SW pre-silicon development platforms become critical for software development and system integration. Project success is no longer being measured solely by “First Silicon.” What really matters now is “First Silicon with First Software.” Therefore, there is extreme pressure coming from internal software developers as well as end users, and even OEM systems companies, for early software development.

As developers are making choices about how to start software development early, several parameters must be considered: accuracy, performance, time-to-model/platform, debug capability, turnaround time, scalability/capacity, overall cost, and finally software levels (ROM code, diagnostics, drivers, firmware, applications etc.).

Options that SW developers have for early development platforms are to:

1.      Run the software on top of the previous hardware system.
2.      Run the software on top of a hardware platform that is modeled by a Virtual Platform. Note that there are multiple options when creating a Virtual Platform, which trade off accuracy and performance. They are, a Virtual Platforms with:

     a.       No timing, but accurate enough for software development – these are being called functional models, programmer’s view (PV) or Loosely Timed (LT)
     b.      Approximate timing and accurate enough for software development with HW dependency – these are being called Programmer’s View with Timing (PVT) or Approximately Timed (AT)
     c.       Cycle Accurate (CA) timing and accurate enough for software development with real representation of the HW design.

3.      Run the software on top of a hardware-assisted verification.

Options 2c and 3 provide the highest level of accuracy while options 1 and 2a are the easiest and fastest to implement.

Overall, the market has been turning to a combination of these solutions. Hardware-assisted verification (Option #3) has become the de-facto standard for system integration (hardware and software) in any mainstream flow. The main reason for this has been the time-to-model/platform combined with cycle accuracy and high performance. Since many of the SoC designs are derivatives, and most of the legacy IPs have been available in RTL, it has been relatively easy to integrate the designs in RTL. Within this category, emulation has been and still is the best HW/SW co-verification and full system validation platform, especially for large designs, fast bring-up time, fast compile time and full visibility. FPGA prototypes are being used mainly for software validation with small designs, a single IP or a sub-system with the promise of higher performance and lower cost.

While use of a previous hardware system (option #1) has been traditionally used in the past (especially for products with long design cycle and minimal HW changes), in the last few years the industry has started to employ the use of Virtual Platforms (option #2). These Virtual Platforms, though, have varied significantly in parameters they focused on (i.e. accuracy, performance, etc.). There had been a split in the development of high-performance, low timing accuracy (options 2a and 2b) and lower performance higher timing accuracy (option 2c). That seems to be changing, with ARM abandoning the cycle accurate approach (option 2c). Note most of the industry now seems to be focused on high performance platforms which offer no timing or approximate timing while cycle accurate timing is being used mainly for detailed performance analysis and with HW-assisted verification. The reason for this is that RTL models (and in most cases cycle accurate systemC models) are running too slow in simulation in order to use them for Software development and even for SW validation.

For the perceived future, we believe the most successful combination will be options #2a (combined with #2b in case timing is required) in the first (pre-RTL) phase for SW development, and then option #3 in the second phase for hardware/software validation. The level of abstraction can be selected based on the time-to-model/platform and the accuracy required. A hybrid (mixed-level of abstraction) environment is probably going to become popular as well. (In a recent presentation, ST has been discussed such a hybrid environment being used in their Set-Top Box business unit.)

3) Verification Methodology

Good system-level planning and management with metric-driven verification improve the overall ability to track measure and provide feedback on the design process. This allows different levels in the organization to be much more plugged into the process. At RTL, this methodology has been successful at block-level verification for simulation and testbench automation, and has recently been expended to formal and hardware-assisted verification.

At the system-level, the methodology needs to supports re-usable VIP and the creation of VIP with a specific set of verification checks that can be measured against the plan. For example, a good Compliance Management System (CMS) has the ability to ensure protocol compatability (see example). CMS allows users to expand to multiple levels of abstraction and create a protocol compliance reference (based on the originally created system-level IP) for the system integrator or the RTL verification engineer. Software extensions that are currently available have had quite an impact by helping to expand the metrics-driven verification approach to embedded software. In theory, the same Metric-Driven Methodology applies to RTL verification can be applied to embedded SW verification. It is important to create these solutions independently of the level of abstraction they are running at, so they will be able to be utilized with all the options mentioned above. For example, one will want to run these verification techniques with untimed models while other will want to use it with emulation. Many times virtual platform and/or HW-assisted verification solution are assembled but the software peers were not ready to hand-off their use cases. These techniques allow hardware to be verified with different software scenarios even if the full software (or firmware) is not available yet. Moving forward, it is expected that more of these Metric-driven techniques will be implemented in RTL expanded to the system-level including software and architectural development. Although there is no defined date for SW tape-out, the pressure to get out a complete working product (silicon and software) at certain timeframe makes SW developers “hungry” for such techniques.

4) Open Standards

Standards are important to the success of the future of ESL however let’s not be rigid about this. One of the challenges in the ESL domain is fragmentation. One of the reasons for this fragmentation is the fact that there are many small players in this domain. One could suggest that this is an indicator for an immature industry while others can argue that system is a result of an inflection point of many different tools: verification, design, HW debug, SW debug, processor models vs. peripheral models etc. When talking about standards here, there needs to be segmentation into different groups such as design standards, modeling standards, verification standards, IP packaging standards, SW standards etc.. Looking forward, the industry should endorse the existing standards (TLM, IP-Xact, SCE-MI, OVM etc.) however (and specifically in this young industry) the following questions need to be continually asked:

1. Is this standard answering the requirements today or does the standard need to be changed?
2. Is the standard being changed just in order to satisfy a specific company or in order to serve new trends in the industry?
3. In order to create a stronger eco-system and eliminate the fragmentation, should new standards be created?

As such, the need to enhance and create new standards in a young industry sometimes is as important as the need to endorse existing standards.

Looking today at the many models that represent processor IP providers, they are being created using proprietary format/language and then wrapped-up with SystemC TLM model. The main reason for this is that models created in SystemC were too slow and therefore different companies created different languages to address the need of high performance models. Is SystemC TLM 2.0 going to address this issue? Time will tell. Maybe for processor modeling the approach, we suggest, needs to be different, i.e. standardizes on the API and the interfaces rather than the models themselves.

The two most important priorities here are:

1. Standardization that will allow fast bring-up time for the SW development platform – i.e. the ability to extract IP models that have been created by different providers into a simulation/SW development platform environment. Obviously, this is one of the reasons that HW-assisted verification is still so popular for system integration (even if high-level of accuracy is not required).
2. Standardization that will allow definition of a synthesizable subset – in order to encourage more IP designers to start their coding in high-level of abstraction and map it to RTL through high-level synthesis automation.

ESL’s time has come

The ESL opportunity is out there, however the scope of what is needed has to be more inclusive of the entire system-level design and verification flow that includes a combination of the many options (or a subset of them) that are available today. The community will also find that many of the techniques that have been successful within block-level verification will be valuable as the move towards system-level development. So as we take a good hard look at what’s next we need to ensure that EDA vendors, IP providers, software developers, system integrators and verification engineers work closely together leveraging what works today to accelerate the process and drive broader ESL adoption.

 

Ran Avinun is marketing group director for system design and verification at Cadence Design Systems Inc. The 2006 paper mentioned can be found here.

© 2009, Reed Business Information, a division of Reed Elsevier Inc. All Rights Reserved.