Technology Backgrounder: nESL™ System Level Debug
Introduction
The use of embedded processors, application
specific standard parts 
(ASSPs), and complete System on Chips (SoCs)
has now become mainstream. This is an inevitable trend given
the reduction in both physical implementation and functional
verification risks afforded by their use.
With the increased usage of these complex
devices, design and verification methodologies have to
encompass new techniques and technologies to cope with the
additional requirements imposed by new methodology constraints
The debug of these devices becomes significantly more difficult
given the behavior comprehension issues associated with the use
of advanced 
components, complex
communication protocols, functionality coded in software and
hardware, as well as intricate, diverse verification
environments.
The Novas nESL™ system-level debug product targets these issues by adding significant capability to the Novas Verdi™ Automated RTL debug system, while also ensuring operation across modern, diverse methodologies.
ESL-based Designs and Design Methodologies
Electronic System Level (ESL) methodologies typically augment existing RTL design elements with various specialized components. Debug of traditional Register Transfer Level (RTL) code structures has already been shown to require 35% of an engineer's time [1]. The complexity of debug for ESL-based designs is compounded by the lack of familiarity with all of the various elements required to model and verify the system within its complete verification environment. Modern systems often include a range of processor types, advanced bus protocols, black box intellectual property from a variety of sources, and both low level and application software. Figure 1 shows an example of a typical system block diagram.
Abstract C, C++, or SystemC models are often used to verify overall design operation before RTL code is created for custom components, with follow up comparisons utilized between the abstract C-based models and RTL synthesizable blocks. Verification environments may consist of SystemC models, Processor Instruction Set Simulators (ISSs), specialized testbench hardware verification language (HVL) code, assertions, and of course RTL models.
Software engineers, particularly those writing code that interacts directly with the hardware such as driver models, can no longer separate themselves from the hardware design process. They must now ensure correct operation of their code prior to chip fabrication by utilizing C models of the hardware and debugging by observing the entire system. Ultimately, the entire system must be integrated together and re-verified, often using an emulator or rapid prototyping system. Figure 2 shows this methodology flow.
Debug Evolves to Meet ESL Requirements
Driven by market trends in the areas of advanced systems and IC design, debug as we know it today must and is evolving to provide greater degrees of design comprehension, process automation, and methodology unification.
Advanced systems, such as those from Novas, support a simple, logical and automated flow for debugging designs. The fundamental characteristic of these systems is their unique capability to provide designers with views and insight into intended design behavior, even if they have no prior knowledge of how the design was created. This is enabled by an underlying set of debug-specific databases that store and organize design information to make debug an efficient and integrated part of the overall design process.
By the nature of ESL design techniques as described earlier and the companies that employ them, debug inevitably requires a more application-specific approach than has traditionally been offered by EDA suppliers. Specific platforms are employed across multiple designs, sometimes provided by third parties. IP and design reuse is commonplace within these methodologies, all resulting in a reduction in the amount of original hardware design.
Debug can no longer be thought of as simply finding the root cause of an observed problem. It must enable more effective design understanding, allow for greater process efficiency, and operate across diverse methodologies throughout the entire systems-to-silicon development cycle. Therefore, ESL-based debug must take into account some relatively new concepts in order provide the optimum level of abstraction and automation. Specifically, this includes:
- support for high-level modeling languages;
- higher level design and verification techniques including transactions
- Integration of software debug with HDL and testbench debug
The Novas nESL Approach.
Novas is tackling this complex challenge with a single environment that facilitates high-level design methods and provides a common interface for debugging across the entire system development flow. This includes the debug of on-chip communications-related structures such as buses, interfaces and IO components.
Building upon the powerful capabilities of its
core debug technology platform, Novas provides a unified,
layered approach that bridges the HDL and system/software
domains with:
Advanced Debug Technologies
utilized for RTL debug, including assertion
analysis, hardware verification language (HVL) code debug, and
mixed-signal visualization, as well as ESL-specific
capabilities such as transaction visualization and analysis,
SystemC code debug from both the hardware and software point of
view, and software debug in parallel with hardware debug
through comparisons of software and hardware operations.
Complete Methodology Coverage that spans the entire ESL methodology - vertically from system modeling, through functional RTL, to emulation and rapid prototyping - as well as horizontally, leveraging RTL simulation, testbench and assertion engines, SystemC and ISS models, analog code and DSP data signals, etc.
Application of Debug Knowledge and Experience to combine the power of multiple techniques, such as interactive software debug, event-based hardware debug, verification and assertion code debug with automated methods for tracing and visualizing cause-and-effect relationships.
nESL: Advanced Debug Technologies
The Novas nESL product leverages the existing capabilities within the Novas core debug platform as well as providing new, more advanced functionality as illustrated in Figure 3 and described in more detail in this section.
Transaction Visualization and Analysis
The use of transactions to observe complex communication either on or off a system, or between its components, is becoming mandatory as modern communication protocols have become so complex that identifying packets of information from the 1's and 0's in a communication stream is all but impossible. Transactions are also used for other applications such as advanced testbenches.
The decoding, visualization and analysis of transactions is a foundation component of the nESL product. The Novas nWave™ module allows transactions to be shown (see Figure 4) as blocks with key information included as part of the display. Single transactions split in time with other transactions between them, or transactions that are overlapping on the same bus may both be easily displayed and understood.
More advanced analysis tools have also been integrated as part of nESL capabilities. A spreadsheet mechanism provides the flexibility to perform the range of analysis functions that may be required, including sorting and filtering on a variety of transaction properties. For example, this tool allows for bus loading analysis, verification of repeated calls to specific address locations, consistency checks between read and writes across multiple busses, and interaction between multi-processor devices, etc.
A key aspect of transactions is the extraction of abstract information from signal data. Transactions may be provided from a variety of sources. The nESL Open Transactor Interface (OTI) is an Application Procedural Interface (API) that may be used by end-users, IP vendors, and other EDA companies to code transaction converters. One reason why this is necessary is due to the fact that Verilog and VHDL do not have a transaction specification built within the language standard and as such transaction data from these HDLs must be converted from signals.
SystemC SCV transactions may be read directly into the system without conversion, and this will also soon be true of HVL transactions from 'e' and Vera®. Users can write transaction recognizers using simple C routines to detect required data patterns within HDL signal sets. IP vendors may do the same to drive IP transactions into the waveform database, a use model that has already been deployed by companies such as Denali Software and SpiraTech. Novas will provide an IP library encompassing many protocols, which already includes an AMBA transaction converter. If in the future SystemVerilog is enhanced to provide transaction support, the Novas nESL offering can be easily enhanced to include this standard.
SystemC Code Debug
The use of SystemC for creating system models and verification code is also becoming more commonplace, and is a key driver behind new system methodology ideas. As SystemC is a class library standard that provides timing, structural and verification features on top of the C++ programming language, its usage may be flexible in nature. It can be programmed utilizing a more interactive software style, including stacks and other common software data-structures, as well as a hardware style utilizing timing cycles and electronic structures.
The nESL product includes a SystemC hardware trace window similar to an HDL trace window. It parses the SystemC code and hides details of the class library, allowing the code to be observed in an HDL style with signals, registers, etc. traced and accessed across the debug environment. Also included is a connection to standard software debuggers that allow the SystemC code, or indeed any C or C++ code, to be debugged in a software style, tracing the software stack and observing key variables.
Hardware Software Co-Debug
The debug of software, particularly lower level code that interacts directly with the hardware structures, such as reading from and writing to registers and processing interrupts, is critical before the device is fabricated. Driver developers must be able to observe the interaction that their code generates with the device hardware to ensure correct operation. A common verification methodology is to use the system processor, driven using the system software, to control the blocks under test, again requiring that the software operation be observed in effect as part of the verification testbench.
Software engineers often have favorite debuggers and integrated development environments (IDEs). In addition, specific processors such as the ARM 7, 9, and 11 series come with their own ISS models and associated debuggers. As such, it is important that the hardware environment operates with the range of required debuggers. The nESL solution provides an open interface that allows debug environment services to be accessible and integrated with software debuggers as needed. The ARM Realview debugger and the well known GDB and DDD debuggers have already been integrated to provide such interactions as cross probing between software and hardware registers, synchronization of time to show the software instruction executed coincident with the resulting bus transactions, as well as several other useful functions.
nESL: Complete Methodology Coverage
As stated, ESL-based methodologies are characterized by the application of a wide range of tools and techniques. If a debug environment is unable to handle even one of these methodology components, then eventually a bug will occur which will be masked from the debugger and require a significant amount of engineering effort for its discovery, assuming it gets noticed at all.
The nESL debugging environment covers all known tools, techniques, and languages employed in modern systems methodologies. Novas is uniquely positioned to achieve this goal, as its vendor-independent, open approach allows collaboration and integration with a multitude of partners.
The nESL product works with all major RTL verification and simulation tools. It supports verification environments including Verisity's Specman™ and Synopsys' Vera tools. It allows assertion debug across PSL, OVA and SystemVerilog assertions. SystemC, Verilog, VHDL and SystemVerilog may be used within the system. It supports a range of models from various companies, such as ARM and Denali. It operates with mixed-signal simulators and provides analog signal display. Of significant note, given the importance of emulation within ESL methodologies, Novas has OEM relationships with all the major vendors including Cadence, Mentor and Verisity. Therefore, the nESL environment can process output from whichever emulation solution is selected by the designer.
nESL: Debug Application Knowledge & Experience
In addition, Novas has developed a considerable amount of debug expertise and innovative visualization and analysis technologies that can be applied at the system level. All of the leading RTL debug solutions developed by Novas may also be used within a system debug solution, allowing for the fast tracing of bug causes in RTL code and the clear visualization of device behavior, a critical first step in bug detection.
Conclusions
ESL-based design is now prevalent across the electronics industry and has become an important element of risk reduction strategies as designs get larger and more complex. ESL methodologies bring their own set of requirements as well as stressing existing techniques for bug detection and elimination. The nESL product tackles the complete range of debug issues associated with complex systems by providing a series of powerful and unique capabilities to minimize the engineering costs associated with system debug.