Soc Concurrent Development Page 1 of 7

SoC drawer: SoC concurrent development Page 1 of 7 SoC drawer: SoC concurrent development Establish a disciplined process for hardware and software co -design, integration, and test Sam Siewert ( [email protected] ), Adjunct Professor, University of Colorado Summary: A system-on-a-chip (SoC) can be more complex in terms of hardware-software interfacing than many earlier embedded systems because an SoC often includes multiple processor cores and numerous I/ O interfaces. The process of integrating and testing the firmware-hardware interface can begin early, but without good management and testing, the mutability of firmware and early stages of hardware design simulation can lead to disastrous setbacks for a project. This article teaches system designers about tools and methods to minimize project churn. View more content in this series Date: 20 Dec 2005 Level: Intermediate Activity: 687 views Comments: 0 ( Add comments ) Average rating (based on 17 votes) This article is the third in the SoC drawer series . The series aims to provide the system architect with a starting point and some tips to make system-on-a-chip (SoC) design easier. SoCs are either configurable or reconfigurable. Configurable SoCs are constructed from core logic that can be reused and modified for an application-specific integrated circuit (ASIC) implementation; reconfigurable SoCs use soft cores and field-programmable gate array (FPGA) fabrics that can be reprogrammed by simply downloading new in-circuit FPGA programming. The mutability of SoCs in terms of firmware and FPGA fabric is attractive because it allows for modification and addition of features. Likewise, for configurable SoCs, the mutability during early co-design and co-simulation allows for quick design changes in both hardware and firmware, making for a very agile project. The downside to this increased flexibility and mutability of hardware is that too much change without a process can result in project churn. Churn comes about when the addition of one new feature breaks one or more existing features, or degrades stability or performance. Ideally, with a disciplined process, new firmware or hardware features can be added to an SoC line of products with little or no churn. The keys are the early identification and use of tools that support a disciplined process for development, and the establishment of policies for their use that help the project evolve. An overview of concurrent hardware/firmware engineering for SoCs The emergence of advanced electronic design automation (EDA) tools, hardware design languages (HDLs), test benches, and co- simulators (allowing firmware to run on simulated hardware designs) has helped speed SoC time-to-market. Partly as a result, it's now expected that, once SoC silicon has arrived, firmware should be up and running and ready to ship not long after. This can be done by testing firmware early, during hardware design, and making careful trade-offs between implementation of functions and features in either hardware or firmware. However, starting the process of hardware and firmware integration and test early also helps shorten time-to-market immensely, especially if disciplined processes are defined early so that final integration and test has little to no churn. (See the http://www.ibm.com/developerworks/power/library/pa -soc3/index.html 4/25/2009 SoC drawer: SoC concurrent development Page 2 of 7 information on EDA tools in the Resources section below for more on this.) Figure 1 shows major milestones in an SoC project from the perspective of hardware development, test, and firmware development. There are four main phases where hardware/firmware testing employs different tools and methods to move the overall system design forward. In the first phase, transaction- level models (TLM), built with C or SystemC, can be used to test the hardware/firmware interface and analyze trade-offs between feature implementation in hardware alone, firmware alone, or some combination. Use of an instruction set simulator (ISS) for the processor cores used can be helpful. With an ISS, firmware is tested at the instruction level; although the tests are not cycle-accurate, they allow for early deployment of the firmware code development tool chain. The second phase begins once enough of the hardware design is complete that cycle-accurate register transfer language (RTL) simulations can be run with basic firmware boot code. An RTL simulation can ensure that firmware will come up on real hardware with little delay once it has been fabricated. At this point, the hardware team typically has significant verification work to do, and the firmware team has significant feature development and testing to complete. So, in phase three, the TLM model can be further developed and used (mostly by the firmware team) to continue code development and testing pre-silicon. The cycle-based TLM simulation also allows for regression testing of firmware so that stability and feature interactions can be tested as the firmware base matures. This is likely to be the longest phase of the overall co-design life cycle. In the fourth and final phase, post-silicon, hardware/firmware integration requires quick firmware "bring up" as designed, along with diagnostic tests to assist with post-silicon hardware verification. Figure 1. Hardware/firmware testing and integration phases http://www.ibm.com/developerworks/power/library/pa -soc3/index.html 4/25/2009 SoC drawer: SoC concurrent development Page 3 of 7 Overall, the co -design and co -simulation tools provide a method under which a system can be developed with frequent feedback from integrated testing at progressively refined levels: from transaction to cycle- accurate simulation, and then to actual integrated testing. Early and continuous re-testing (regression) is important because it helps to identify and fix problems early. However, the rapid pace of feature addition often causes backslides, where the stability and performance of the system suffer as features are added. Ideally, feature count, stability, and performance would monotonically increase throughout the phases of the development life cycle. Most often, however, performance and stability decline as features are added and only begin to improve again as the feature set becomes more constant. In each phase, with a disciplined development approach, you can keep stability, performance, and the feature set all improving. It's likely that there will be apparent declines as you move from phase, as increased fidelity of testing will lead to the discovery of more esoteric and detailed issues. However, constant progress can be maintained, at least within a phase. One of the simplest methods is disciplined regression testing combined with change management tools. Firmware bring-up post-silicon should be quick Given the availability of high-quality co-design techniques, such as the IBM ChipBench™, and co- simulation techniques using instruction set simulators and SystemC transaction level models and core models, firmware bring-up and post-silicon verification should take weeks rather than months. Often, firmware will be up and cycling only days or even hours after silicon arrives back from fabrication. How to keep iterative co-implementation on track during development phases Some tips on how to keep features and modules on track: Identify hardware and firmware module owners to take responsibility through entire life cycle. Require tests to be developed in parallel with module development. Require early adoption of nightly testing using TLM simulation and/or RTL simulation. Adopt configuration management version control (CMVC) tools that allow for feature addition branches and version tagging. While the recommendations above are followed in most projects, they often aren't implemented until the end of the process shown in Figure 1 . Starting early and automating tests for nightly regression is now possible with EDA and co-simulation tools available for SoCs. In the days before early verification tools were available, hardware and firmware development proceeded much more independently than they can now. A typical process included independent development of firmware on an emulator while hardware was designed and developed, with most of the co-testing done during the final post-silicon verification. Despite advances in verification tools, many SoC developers still work along lines established in those days, and thus don't adopt testing and regression processes, or configuration and version control, to the extent that they should. CMVC tools such as ClearCase provide great management for HDL and C code ClearCase® was developed for multisite, multiproject repositories, and can manage source and binary files. It can readily be used by both hardware and firmware development teams and to test releases with integrated co -simulation. http://www.ibm.com/developerworks/power/library/pa -soc3/index.html 4/25/2009 SoC drawer: SoC concurrent development Page 4 of 7 Source CMVC Since EDA and HDLs for SoC design make the hardware development process similar in nature to firmware development, both hardware and firmware can and should use configuration management tools -- the same ones, if at all possible! This almost seems blasphemous to organizations that have grown accustomed to a silo model for hardware and software development, where a quick hand-off is made post-silicon, and interaction is otherwise minimal. One difficulty when testing changing firmware on changing hardware is that stability often suffers: this can greatly impede the progress of both hardware and firmware development teams. This problem can be solved by having the hardware team make releases of simulators to the firmware team. Likewise, the firmware team should make releases of boot code and diagnostic code to the hardware team. Both teams need well-disciplined processes for maintaining versions and releases. One way to go about this is to maintain a main line of C code or HDL that is guaranteed to be stable. As hardware or firmware developers add code, they do so on branches from the stable main line, and merge new features and bug fixes made on code branches back to the line.

Load more