ESL at the inflection point

By Marc Serughetti | No Comments | Posted: March 1, 2008
Topics/Categories: EDA - ESL | Tags:

Electronic system level (ESL) design is moving to a new stage in its development, advancing from a proof-of-concept environment to one that is seeing its adoption and deployment at the forefront of design.

The article terms this shift ‘ESL 2.0’. The reason for this goes beyond mere marketing hype. Inherent in the transition defined above is the fact that ESL is, as is often the case with a 2.0-type advance, undergoing a change more in how it is used rather than in terms of the fundamental technologies of which it is composed.

Given the increasing challenges presented by multi-core design, ESL 2.0 is therefore defined as a second generation of ESL solutions that enable the efficient design and development of processor-centric, software-heavy products with complex interconnects and memory architectures.

This article sets out the evidence for saying that an on-going transition to ESL 2.0 world is well under way and examines the forces behind it. It also provides examples of how ESL technologies are now influencing the way in which engineers approach new designs and how companies are using them for new product development, adapting and improving both their own internal design flows and also their relationships with end-customers.

Many technologies have come to their inflection point by moving from the proof-of-concept phase to the adoption-and-deployment phase in a production environment. Electronic system-level (ESL) design is no different. This article discusses that on-going transition and the forces behind it. Through examples, it will also illustrate how ESL technologies are changing the way developers are approaching new designs and how companies are implementing new product development in conjunction with their customers and ecosystems.We will refer to this new ESL reality as ESL 2.0. Although the use of the “2.0” nomenclature may look like marketing hype, it has a clear relation to other 2.0 technology evolutions where the major change lay in how the technology was used and deployed rather than in a change to the underlying technology itself.

ESL from proof-of-concept to deployment

Let’s first look at how we define ESL 2.0. From our point of view, ESL 2.0 refers to a second generation of ESL solutions that aim to facilitate the design and development of processor-centric, softwareintensive products with complex interconnect and memory architectures, all in a production environment.

The need for ESL 2.0 has been – and continues to be – driven by the breakdown of old design methods and the emergence of new design challenges, led by the needs to create better semiconductor products faster and use multicore architectures. There is also a need to break down the barriers that have traditionally isolated the activities and thinking of each development team in a typical design flow, thus enabling the whole enterprise to get better designed ICs into customers’ hands sooner. ESL 2.0 addresses both of these demands. ESL 2.0 is characterized by a combination of:

The application of ESL technologies and methodologies to a larger community of users. This includes the architectural and hardware development teams that ESL has traditionally addressed, but now also extends to engineers involved in software development, system integration and test;
The rapid rollout and use of ESL technologies and methodologies in a production environment; and
The use of virtual hardware platforms in the larger enterprise and its ecosystem by members of the marketing and business development departments.

Virtual hardware platforms are at the core of ESL 2.0. They can be used by the wider community, exchanged within or across company boundaries, and applied to production designs. ESL 2.0 is not one fixed event, but rather an inflection point, the consequences of which are important for companies using ESL technologies and for companies delivering ESL technologies.

The growing pains of ESL

Given the description of ESL 2.0 above, it is important to clarify this transition in terms of some of the key trends, events, and facts from the past few years of ESL’s history and its time in the proofof- concept stage.

ESL has its origin in the EDA industry. Its EDA origin has often placed ESL at an abstraction level above RTL in the mind of hardware developers. However, this view omits the important context of a design as a ‘system’ (i.e., a combination of hardware, software, and the environment in which these both evolve).
Initial ESL strategies tended to be company-specific and aimed at finding answers to specific design problems. Alternatively, they were based on proprietary languages and technologies. As long as the deployment of the technology was either design task- and/or company-specific, it was obviously difficult to deploy subsequently on a wider scale. ESL was too discrete.
ESL has spawned a lot of innovation. The emergence and development of standards like SystemC and transaction-level modeling (TLM) each marked a significant step in the initial evolution of ESL. But, like most standards, they faced detractors and competition from proprietary technologies, resulting in confusion about the objectives the standards were trying to achieve and a slowness in their acceptance by the wider design community.
The majority of companies have been experimenting and developing proof-of-concept designs with ESL, while at the same time utilizing old methods in production. This also put the deployment of ESL technology in an early adopter category that slowed growth.
Single-core application designs with simple interconnects did not require a significant change in development methods. Typical design methods worked pretty well and thus the status quo was not greatly disturbed; until requirements such as multicore began to place more stress on traditional flows, ESL technologies were not recognized as delivering adequate value.
A significant part of the design is reused from project to project. However, early-stage ESL technologies often assumed that a new design would start with its technologies and did not incorporate a design reuse component.

The main consequence of all of this was that the benefits ESL could deliver to its users were vastly underrated.

In a recent presentation at the 2007 Design Automation Conference, the Venture Development Corporation, an analyst firm based in Boston (www.vdc-corp.com), set out some of their key observations about the state of ESL, which they derived from a comprehensive market research study:

The ESL tools market is emerging and experiencing growth.
There are signs of opportunity and change.
Significant migration to ESL will require coordinated changes.
Future growth in ESL will be the result of deliberate customer decisions.
ESL is not just about changing system, hardware, and software development, but also about bridging existing engineering methods.

Multicore: a driver for ESL adoption

New engineering challenges have emerged in the design of multicore- based platforms. Complex memory hierarchy, intelligent interconnects, heterogeneous processors and cores, and multiple dependent software stacks must come together as a system where multiple requirements for areas such as performance, power, functionality, and time-to-market must be met.Modeling, simulation and analysis at a higher level of abstraction, serving both the hardware and software communities, provide ways for engineering teams to build more efficient bridges between each other, and thereby enable concurrent engineering.

Figure 1. Design risks without ESL

The development costs associated with multicore designs are increasing. Companies are now forced to invest so much in a design that they cannot risk late project changes or even project cancellations without them having serious consequences for the entire enterprise. Concurrent engineering must become a reality, not only within a company, but also across the supply chain. This implies that companies need to be able to capture and validate their requirements at the early stage of the design flow more efficiently. This requires that the ecosystem of technology surrounding the design is available to all the teams involved as early as possible. It also means that companies must provide their customers with a solution that accelerates those customers’ own product development. There is now a requirement for products to not only be designed better and faster by a company’s engineering team, but also for the products to be designed sooner into their customers’ products.

An ESL methodology, based on a higher level of abstraction, provides an efficient medium that can be used to create a continuous engagement with customers and the ecosystem. This ensures that the right product is being created and delivered, and that the customer can develop its product faster and achieve faster time-torevenue.

As multicore is a key driver for ESL adoption, we will consider in more detail three solution areas relevant to multicore design: architecture design, processor design and software development.

Figure 2. Platform architecture design using traffic generation

Architecture design

In system-on-chip (SoC) projects, those elements noted above of multicore designs, complex memory hierarchies, intelligent interconnects, heterogeneous processors and IP cores, and multiple dependent software stacks must come together as a system. This means that architects need to focus on the challenges associated with the optimization and performance validation of the backbone interconnect and global memory subsystem of the SoC. Architects are looking to ESL methods to greatly improve the analysis and decision-making process. They know RTL methods are too slow and lack the visibility needed to analyze design performance, configure complex on-chip interconnects, and optimize the global memory hierarchy. The results are over-design, cost increases, schedule delays, and re-spins (Figure 1).

Using ESL methodologies and technologies, architects can measure, analyze, and optimize performance throughput before software is available using non-functional workload models to generate transaction traffic. Later in the design, they can also perform the same task using a complete cycle-accurate platform model and software. Such an approach (Figure 2) results in improved product performance and lower cost, while design cycle time is reduced by 50% compared with traditional RTL methods.

Processor design

In multicore design, processing elements introduce a variety of challenges for the design of high-end application processors, programmable accelerators, and software development tools. Some of these challenges include:

Current digital signal-processors (DSPs) are running into scalability limitations. They are no longer applicable for nextgeneration, high-density video and wireless basestation systems. The challenge is that a significant effort is involved in moving from proof-of-concept to production mode for the next generation of massively–parallel, programmable architectures. As much as a 150- 200 person-month effort can easily be required. Sometimes this effort is made, but no satisfactory result is achieved.
There are many factors that dictate the need for a programmable accelerator solution. These include multi-standard support, a large variety of modes in next-generation algorithm designs, and the need for a 10X performance increase, to name a few. These factors are then augmented by others including the large number of different skill-sets required to provide a programmable solution that includes hardware, software and software development tools. All this imposes a huge burden upon today’s developers.
Low-level software development productivity for existing customized DSPs or custom processors limits the deployment of these customized solutions. The challenge is getting advanced software development tools – such as debuggers, simulation models, assemblers, linkers,macro-assemblers, peephole optimizers, and C-compilers – into the hands of the software developers.
The limited speed, visibility and controllability of currently available star IP processor models on virtual platforms prevent the successful deployment of virtual platforms for early software development and early performance validation. To update the model to the latest simulation technology requires the implementation of the entire processor model and this is a huge effort.

Addressing these challenges – and thereby accelerating the design cycle – requires an automated set of tools. These tools need to be integrated to create a seamless flow from processor design to architecture design and software development. Such a flow is illustrated in Figure 3.

Figure 3. A seamless flow from processor design to architecture design and software development

Software development

Multicore design presents multiple challenges for the software development flow from programming right through to test. Today, though, the focus is on system integration and test. The time required for test is increasing because the systems are more complex to set up, understand, and finally execute. As a result, it is essential that development teams be able to start their activities earlier, even where the physical hardware is not available. They need the technology that will provide the performance required. In this area specifically, a dependency on the physical hardware availability and the current simulation performance of RTL does not meet these requirements. As a result, methods based on a higher level of abstraction that deliver higher simulation speeds are becoming increasingly necessary. It is now essential that the team has the ability to optimize the time spent simulating through higher simulation speeds, better debug and analysis tools, and new advanced capabilities that simply are not available with physical hardware.

Virtual hardware platforms (Figure 4) are targeted at software development and provide three key benefits:

Early availability: virtual platforms can be made available well ahead of physical silicon. They remove the strict dependency on the availability of a physical board. In addition, virtual platforms can be scaled to meet the requirements of the design and development team using them. For example, during operating system porting, the modeling of only a certain part of the system is required. Virtual platforms optimize hardware/ software concurrent engineering.
Accessibility: as a software package, virtual platforms can be made available in a matter of minutes to distributed teams across the world. In addition, it is much simpler to set up such platforms than it is to set up the physical hardware.
Productivity: observability and controllability of all the hardware blocks, determinism, and non-intrusive debugging are just some of the key capabilities that make virtual platforms a powerful productivity-oriented tool.

Figure 4.Virtual platforms provide a simplified development environment

An integrated infrastructure

ESL technologies have proven over the past few years that they result in optimized product performance, reduced development cycle time, and improved customer satisfaction. The development of standards such as SystemC/IEEE1666, TLM and SPIRIT has created a viable risk mitigation foundation that is driving a traditional evolution of ESL technologies from proprietary and inhouse solutions to standards-based solutions. Those technologies have also moved from proof-of-concept to the level of maturity required for large-scale deployment. Meanwhile, the demands of multicore design are causing traditional methods to break down. Consequently, we are entering the ESL 2.0 era.

To really harvest the benefits of ESL, companies need to approach the problem with a view to updating their business processes rather than simply accelerating the design task (Figure 5). ESL 2.0 deployment must be considered in the context of the enterprise as it affects engineering, marketing, and supply chain relationships. Companies need to implement ESL as an infrastructure that applies internally and externally.