Development managers and architects for today's system-on-a-chip (SoC) designs can choose from a wide range of development tools and methodologies to achieve development goals in the hardware/software co-development space. As is well-known, an SoC is a single chip that forms a self-contained system that generally includes one or more microcontroller, microprocessor and/or digital signal processor cores, one or more memories, one or more input/output (I/O) devices and software for controlling the system, including the I/O devices. One concern of developers of embedded software, such as used in an SoC, is achieving timely access to target hardware on which to run code. This is particularly true in the case of SoC applications because product time-to-market pressure is high.
Because of this high time-to-market pressure, software developers are forced to develop the software in parallel with the hardware that will make up the final SoC product. This means that the actual hardware on which the software will run is not available during development. Consequently, current state-of-the-art SoC software development often relies on hardware emulation, or software co-simulation to provide a development environment for the new software code. In emulation or co-simulation, the hardware is mapped onto an emulation/co-simulation platform that mimics the behavior of the entire SoC. Once programmed, the emulation/co-simulation platform enables both the hardware and the software of the SoC to be tested and debugged. The main constituents of a software co-simulation platform are models of hardware blocks at different levels of abstraction (transaction-level, cycle-accurate, behavioral to name a few) written in industry standard languages (e.g., SystemC, VHDL, Verilog). The process of developing embedded software on such hardware emulation/software co-simulation platforms can be very slow compared to the speed of the actual SoC hardware on which the software will eventually run.
For example, booting up complex code, such as operating system code, on an emulator/co-simulation takes an excessively long time and is, therefore, not practical. Consequently, a drawback of this process is that the development code must be executed on the emulator in small segments. Breaking up the development code into these small segments is very time-consuming and inefficient. Additionally, debugging the development code via simulation software does not allow its execution at full, or even near full, system operating speeds.