 |
|
Complexity and Software Drive ESL SolutionsContributor: Synopsys, Inc. As system-on-chip (SoC) designs grow ever more complex, developers are turning to electronic-system-level (ESL) solutions. ESL provides tools and methodologies that let designers describe and analyze chips on a level of abstraction at which they can functionally describe behavior without resorting to the details of the hardware (RTL) implementations. This article explores the critical success factors of ESL tools with respect to the objectives of design cycle and risk reduction for highly complex hardware/software SoCs. The Typical 130nm SOC TodayTime-to-volume is, and will remain, a key factor for a successful SoC project. A design requiring a re-spin, apart from having higher design cost, reaches volume production at least 6-12 months later than intended, with a clear financial impact. So the key question is -- how can ESL help reduce the risk of a re-spin and contain design cost? To derive an answer, we take a closer look at the key design and verification tasks and, with this background, explore how and where ESL methodology and tools have the most impact. In a typical SoC (Figure 1) a large part of the SoC originates from IP blocks that have been used in previous designs, acquired from an internal IP repository, or (increasingly) licensed from external suppliers. There are three reasons for using IP: reducing risk, reducing silicon cost, and reducing design time.
A large part of the typical SoC is memory, which, depending on the application, can consume over 50% of the chip area. Even though memory is an essential component, and silicon effectiveness is critical, it does not require extensive design/verification resources. Well-established, specialized memory design and verification technology usually suffices. A very critical component is the SoC infrastructure required to provide effective data movement across the chip. Standardization is key here -- on the one hand the use of a standard on-chip bus (OCB) reduces the design time and risk, while on the other hand standardization is required in order to use the same IP in multiple contexts. Of course, the new design modules that need to be developed specifically for the project are also critical. For an SOC today, this covers approximately 10-20% of the total chip. This translates to roughly 1-4M gates for a typical 130nm chip. The Next-Generation SoCGeneral expectations are that, for the next generation of 90nm and 65nm designs, IP usage will further increase. The SoC will also contain multiple programmable elements, such as central processing units (CPUs) and digital signal processors (DSPs). Given these elements and the many (ever-larger) IP blocks, the ability to quickly assemble, simulate and analyze alternative architectures to find an optimal balance between performance, power, and silicon cost is growing increasingly critical to successful SoC design. For ever-larger chips with programmable elements, there is another task that is growing rapidly and strongly impacting SoC success: system and application software. For many products, a rapidly increasing amount of software has to be validated and/or developed. This involves more than just essential support software, such as hardware drivers. Complete operating systems need to be validated and new applications, exploiting the new hardware capabilities, need to be developed before the end products based on the SoC can be sold. Today, these software development tasks are typically performed only after a hardware prototype of the chip becomes available. For example, in the wireless domain, this approach often pushes out product release timelines because "the software is not ready yet." To resolve this issue, the concept of a "virtual prototype" has emerged. A virtual prototype is a high-speed (20MHz or more) functional model of the target chip that allows software development to start many months before a hardware prototype is available. The need to be able to quickly assemble, simulate, and analyze alternative architectures, and the need to start the software development tasks many months before a hardware prototype is available, drive today's ESL technology and methodology, and have the biggest impact on design time, silicon cost, and time-to-volume. The Emerging SoC Design FlowThe design flow toward which leading SoC developers are gravitating is depicted in Figure 2. It starts off with an ESL flow for three tightly related activities - product specification, architecture design, and the development of a software execution platform. A key requirement for this ESL flow is that it spawns a concurrent hardware and software development process, providing detailed specifications for the new logic blocks that need to be designed, and delivers virtual prototypes on which the software development task can be executed. Simultaneously, the virtual prototypes need to be able to provide estimates for performance, power, and silicon cost.
The ESL phase is followed by the concurrent execution of RTL design/verification and software development tasks, so that by the time a hardware prototype is created (which requires the RTL to be available), the necessary software is also available. Similarly, by the time physical design has been completed and the chips are coming back from the foundry, most or all of the required software is available and has been validated, ensuring a dramatically shortened final hardware/software integration phase. Critical Success Factors for ESL ToolsThe critical success factors for ESL tools in the context of this emerging SOC design flow shown in Figure 2 are: 1. The ability to quickly assemble virtual prototypes from a variety of IP (processors, DSPs, etc.) and infrastructure options (bus configurations). 2. The ability to run software on the virtual prototypes. This includes operating systems and application software, and hence requires high performance. 3. The ability to analyze the performance and perform estimates for power and silicon cost, including the ability to generate alternative HW/SW partitions. Once the architecture is established, additional features help in moving towards RTL implementation of the architecture: 4. The ability to reuse the architecture testbench/stimulus environment for verification in the downstream RTL design flow. 5. The ability to generate the corresponding RTL representation for the IP blocks, including the infrastructure. 6. The ability to automatically map the new logic blocks into RTL. The following sections provide more detail on the development steps implied by these critical success factors: 1) Assembling virtual prototypes SystemC has emerged as a preferred language to assemble virtual prototypes. This does not mean that all components of a virtual prototype are necessarily written or designed directly in SystemC. In fact, processor models or other large IP blocks are often modeled in C, C++, or other dedicated modeling languages. Specifically, digital-signal-processing functions are often are often modeled in C, MATLAB, or other dataflow design formalisms. Finally, there are often IP blocks for which only HDL representations are available, that need to be incorporated into the virtual prototypes. The models of the IP blocks originate from multiple sources, and are modeled with different levels of accuracy, often on different levels of abstraction. System architects need a language such as SystemC, with the appropriate abstraction mechanisms, to support the mixed-level modeling technology required to tie these functional blocks together in a methodologically coherent fashion. SystemC is well-suited to model the chip infrastructure on the appropriate level of abstraction. The separation between communication and function in SystemC allows effective modeling of cycle-accurate, cycle-approximate and functional models of the chip infrastructure. The new Open SystemC Initiative (OSCI) SystemC Translation-Level Modeling (TLM) Standard is one of the initiatives to help streamline the modeling. Transaction-level models for standard on-chip buses, such as the OCP-IP protocol, also help foster the development of virtual prototypes. 2) Running software on the virtual prototype To develop driver, system, and application software, the virtual prototypes have to be complete and must include all external interfaces. This is a key requirement that directly originates from the objective to fully validate the software components and run exactly the same (validated) software, without any modification, on the final hardware. Also, for test and verification purposes, designers must be able to model realistic traffic on these interfaces and connect real devices, for example a USB-connected digital camera, to the virtual prototypes, much as one would connect these devices to an actual hardware prototype. Finally, the same debuggers that software developers would use on the hardware need to run with the virtual prototypes. Although not a technical requirement, software engineers are very attached to their preferred tools. Actually, running software on a virtual prototype has many advantages when compared to running the same software on a hardware prototype. Specifically, better visibility into the virtual hardware when compared to the actual hardware allows for easier debugging of issues that cross HW/SW boundaries. 3) Analyzing performance and perform power/size estimates With high-level models of the hardware and the actual software applications and/or core algorithms running on the virtual prototypes, designers and system architects have the right ingredients to fully analyze the behavior of the architecture. This information is used for two purposes:
Clearly, both angles are often explored simultaneously. Depending on the actual project, either the hardware or the software may be more flexible. Specifically for dataflow-intensive applications, technology/tools that help offload functionality from a general-purpose application processor into dedicated hardware can dramatically impact both the performance and the power consumption of the SoC. 4) Reusing the testbench/stimulus environment While validating the architecture and analyzing the performance and power, the system architect creates a stimulus environment or testbench. It is a requirement that this testbench and a defined set of testcases can be fully reused once the design moves towards RTL implementation. There are two reasons for this requirement. First, verification engineers clearly want to avoid duplication - why build essentially the same testbench twice? But there is also a more fundamental reason. A single, unified testbench and test scenarios ensure that the RTL is being designed/assembled to implement the architecture correctly. Thus, the testbench becomes the golden reference used to verify that various configurations of the virtual prototype, possibly with a mix of ESL and HDL description, leading ultimately to a complete RTL model, behave the same. With at least a third of the total design cost spent on verification (according to many studies), the benefits of such a unified verification solution are substantial. 5) Generating/assembling the corresponding RTL On the architecture level, the designers or system architects define the configuration parameters for the IP and the on-chip buses or other infrastructure. Hence, tools that automatically generate the corresponding RTL, given a particular architecture model, are very beneficial. This is where standards such as SPIRIT (Structure for Packaging, Integrating and Re-using IP within Tool-flows) come into play. Even though many companies have solutions in place today, the SPIRIT initiative standardizes this process and aims at better IP interoperability between tools. In some cases, automatic infrastructure generation may be part of this process as well, saving a lot of time and avoiding errors that can lead to many hours of unnecessary debugging. 6) Creating the RTL for the new logic blocks With most of the RTL generated from predefined functional blocks and the infrastructure generated, the last remaining task is to make the newly designed functional blocks available in RTL. Traditionally, this is a manual task. However, in specific domains such as signal processing, there is some automation available today. For example, tools that automatically map dataflow representations of algorithms into RTL are becoming increasingly effective in terms of quality of results. ConclusionLooking at today's SoC designs, we have outlined why and how ESL tools and methodology play a key role in containing design cost and help ensure timely product release. The critical decisions impacting the performance and cost of the SoC are being made early in the project, using virtual prototypes. For example, the choice of processor core, the configuration of the chip infrastructure, and the selected IP blocks can have a significant impact on the cost of the chip. This is where design teams spend time to ensure an optimal balance between performance, power consumption, and area, and where ESL tools come in. The need to start software development early in the project also drives the need for virtual prototypes. Running and debugging software long before a hardware prototype is available allows software developers to benefits from an ESL-based flow. Finally, we have outlined two other important aspects that ensure a well-connected ESL-to-RTL flow. First, a unified verification solution is a requirement to ensure consistency between ESL and RTL models. Second, efficient RTL assembly and generation further streamline the ESL-to-RTL flow, reduce design time, and help designers create successful SoCs.
By Rindert Schutten, Synopsys, Inc.
| |||||
Reprinted from SOCcentral.com, your first stop for ASIC, FPGA, EDA, and IP news and design information. | |||||
