| Silicon real estate advances have inevitably led to the complete integration of microprocessor subsystems together with custom hardware and software on single devices. This advancement has brought with it a range of opportunities and issues, including upheavals in design methodology. The typical embedded platform consists of one or more processors together with bus structures and supporting components. This is not a new idea, as companies have reused processor subsystems on PCBs for years. However, its application within single integrated circuits to create an application specific standard part (ASSP) which may be reused across multiple products with associated cost and risk reductions, is relatively new. This trend continues, with analysts even predicting the growth of ASSP usage. Embedded platforms have imposed new constraints on already complex IC design methodologies. Multiple companies have been working on efficiency improvements for the embedded platform design process, deriving various methods including leveraging C models for different purposes, abstract device communication, operational speed testing with emulation, and pre-verified intellectual property. Different stakeholders in the business have driven industry wide methodology cohesion through standards and cooperation. A methodology involving the use of C, C++, and SystemC models is becoming established whereby common system blocks may be utilized across software, hardware, and verification specializations. This is augmented with the use of transaction modeling and other emerging techniques. Embedded processor methodology
Many methodology issues relate to the fact that the hardware and interconnected software must be made to work before chip fabrication with limited opportunity for error correction, a major difference over printed-circuit-board (pc-board) based platforms. Consequently, effective verification and debug becomes more important This fundamental difference has driven many requirements, a significant one being early software test. In traditional methodologies, software and hardware are designed separately, with the first opportunity to run the software on the new hardware occurring late in the design process and often utilizing an emulator. While still appropriate for application software, the lower-level code that interacts directly with hardware must be verified early. A software error at this level could result in a hardware change and a costly fabrication iteration. The effective integration of software and hardware flows has been sought after by many systems companies. Such a mechanism would lead to a reduction in late design errors while also improving overall efficiency. A method has recently evolved where C, C++, and SystemC models are used to validate higher-level system specifications. These models are abstract, processing transactions and/or performing algorithmic transformations. They also have the capacity to allow detailed cycle level functionality to be added for specific design flow phases. As the system model is completed, components are provided to the various specialized teams. The software engineers can use the more abstract Instruction Set Simulator (ISS) model of the processors, bus transactions, and register operation to check their code. The C derivative coded models allow direct linking to the software, thus streamlining testing. The models may be provided to the hardware designers to serve as operational specifications for comparison purposes with their RTL code. This requires a more detailed abstraction. Promoters of the process are working out how key nodes and other comparison points may help in this regard. The verification team uses the models to duplicate the platform environment for fast testing. The majority of the platform may be represented using C based models, allowing basic software to be interconnected with the custom HDL code. Automated testbenches created using the SystemC SCV standard or an automated verification language can be used to duplicate external inputs. Assertions allow specification details to be verified This method allows for concurrent hardware software development and verification environment production, enabling integration testing of system components even during their development. The major issue with this approach is the varied range of abstraction levels required of the models. As the same basic model cannot be used for both hardware and software easily, a method must be found to bridge the gap. Transactions usage as a convenient abstraction for inter-block communication is part of the solution. By allowing software models, hardware models (through bus functional models) and verification tests to communicate at the transaction level, commonality between the diverse models is enabled. As such, transactions become fundamental when applying this methodology. Linking the elements
While examining this methodology it should be remembered that software, hardware, and verification are quite different, and these differences need to be considered. Hardware design is time and spatial in nature, with event causality being key. Hardware debugging takes this into account while providing the infrastructure for design comprehension over a variety of abstractions. Hardware verification is typically performed using a simulator, post processing the results. Hardware debug may also include implementation and physical analysis of the design. Software debug is more interactive in nature and partly performed during code creation. The software is compiled and then run without a simulator. Software debug does not focus on time-based events, except in the case of multi-threading but is sequential in nature. More complex data structures, for example a processor stack, require special examination. The combined hardware-software debugger must clearly provide the features necessary for both specializations, for example wave and stack tracing. It must facilitate post-processed interactive use models. The use model must be linked between software and hardware domains such that the entire debug system operates together treating the components as one operational unit. For many hardware designers and driver developers, the boundary between software and hardware is blurred. A debugger or development system is required that allows complete, transparent interaction between both domains, with an easy-to-use interface that enables appropriate operational modes for software and hardware with effective capabilities for their analysis. Hardware and software
The key requirements for a modern embedded platform debugger are: - Hardware debug capabilities, including event and structural evaluation;
- Interactive software development environment capabilities;
- HDL, C-based and HVL language coverage at various abstractions;
- Abstract transaction visualization; and
- Integrated debug use model.
There are two possibilities that could meet these requirements. Firstly, hardware capabilities may be built into a software development environment or visa versa. Although this might seem a reasonable option, given the basic differences in use model the debugger will likely be deficient in one area or the other. Alternatively, after appropriate enhancements for transaction and language support, effective hardware and software debuggers may be intelligently integrated with synchronization mechanisms. This is the proposed debug/development solution for the SystemC based methodology. For this, a loose coupling between software and hardware debuggers allows for a reasonable degree of interaction with time synchronization and memory and register views on both sides, while also preserving the flexibility and natural use models already well-established in each domain. Also, SystemC support is provided on the hardware side and in the software debugger, given the multiple uses for the SystemC code for hardware blocks and verification, requiring both debug use models. Transaction support is the key for this environment and this is provided in both the waveform display and more advanced spreadsheet view. With this capability, it is possible to monitor software execution while also examining bus transactions to check expected functionality, thus ensuring consistency across the domains. This environment meets the needs of the embedded platform design engineer regardless of specialization, while retaining a level of use model simplicity. The complete debug system
As embedded platforms become more prevalent, additional functionality will be built into the debug environment that makes design comprehension more straight-forward. IP integration, advanced verification management, debug of emulation output, assertions, mixed signal, and advanced memory debug must be addressed to further enhance the effectiveness and efficiency of embedded platform analysis. The proposed environment provides an ideal base for further enhancements across the emerging embedded platform methodology. Yu-Chin Hsu (ychsu@novas.com) is vice president of research and development and Dave Kelf (dave@novas.com) is vice president of marketing at Novas Software Inc. (San Jose, Calif.)  See related chart See related chart | 
