Creating An SoC Virtual Platform For Embedded Software Development

Fig 1. In developing embedded software, virtual platforms are used at very high abstraction levels. The blue blocks represent the virtual model and the green blocks represent the software that can be developed and verified using these virtual models.

Fig 2. A virtual platform as a tool for software development/validation and SoC design validation can be broken down into several design components. These include system IP models, memory models, processor models, communication models, accessing host interfaces in the Virtual Platform, and debugger interface support.

Fig 3. This diagram shows how a USB port of the host computer is accessed within a virtual platform. The host-controller model is contained within the virtual platform as a register-accurate model. This model must meet the specifications of the USB host-controller IP block in the SoC.

Today's system-on-chip (SoC) designs incorporate various input-output capabilities and are multi-core systems with fast communication protocols. SoCs often incorporate various processing elements for multimedia and networking applications. The convergence of computing, communications, and multimedia data processing onto one chip pushes SoC complexity in two areas: SoC integration and software development.

No company today designs the complete SoC itself; they source the complement of IP cores from different vendors. Integrating IP from different vendors in a single SoC and making them work is a highly complex task. The IP vendors are under pressure to support all the popular interfaces and make their IP suitable for a wide range of customers. To address SoC integration issues, the industry has been moving toward standardizing the IP core interfaces to achieve high reuse. The Open Core Protocol-International Partnership (OCP-IP) is a standards forum focusing on SoC integration concerns. OCP-IP defines a high-performance, SoC bus-independent interface between IP cores. This makes the IP core independent of the architecture and design of systems in which they are used.

SoC developers not only need to achieve high performance, but the product also must be flexible and programmable. As a result, SoCs are becoming software intensive. Software content on these SoCs comprises low-level firmware, device drivers, telecom/communication stacks, operating system (OS) code, and application software, etc. Development and validation of so much software is a big challenge.

To address these software development challenges, the industry has been adopting more abstract simulation models, which can deliver enough performance and accuracy to enable software development to begin in parallel with chip development. In this phase, software developer goes through multiple build/execute/debug cycles and overall productivity depends on the simulation speed and ease of debug. The Open SystemC Initiative (OSCI) is a standards forum focusing on defining the standards for creating software models of SoC. SystemC is a standard language for modeling of SoC. OSCI TLM2.0 is a standard library for transaction-level modeling. OCP-IP has created an advanced modeling kit by extending OSCI TLM2.0 for the Open core protocol.

The OSCI and OCP-IP standards have the potential to address most of the challenges in current SoC designs. We at CircuitSutra have demonstrated the virtual platform by using the modeling standards from OCP-IP and OSCI. A demo virtual platform is available for free download from the OCP-IP website.

Using the virtual platform for embedded software development instead of using an FPGA board provides several advantages. It allows hardware design and embedded software development to proceed in parallel, hence reducing the time to market for electronics product. It also provides more powerful debug features needed to develop and verify complex software for a multicore SoC. This article discusses how to create an SoC virtual platform for embedded software development.

It is critical to choose the correct abstraction level when creating an SoC virtual platform. The abstraction level defines how much timing accuracy you will see in simulation as well as the functional accuracy of the hardware models. Which level is right for you? It depends on your purposes for using the virtual platform. These might include embedded software development, RTL verification, architectural exploration, and performance optimization. We will limit discussion to embedded software development, which requires use of the virtual platforms at very high abstraction levels. Various abstraction levels are relevant to this use case for a virtual platform. Blue blocks represent the virtual models. Green blocks represent the software that is developed and verified using these virtual models.

The Programmers’ View

A virtual platform that provides a level of abstraction known as the Programmers’ View (PV) includes the Instruction-set simulator (ISS) of the processor and the register accurate transaction-level models (TLMs) of the peripherals. Providing this virtual platform to the software team enables them to develop the hardware abstraction layer and device drivers and run these on the platform. They develop the complete software stack (middleware and application software) on top of this. Alternatively, instead of different layers, there can be a small embedded application which itself programs the registers of the peripherals and accesses the functionality of the SoC. The device driver and hardware abstraction layer is very much specific to particular hardware. It is critical to model correctly all the registers that are visible to device drivers and the functionality associated with these registers.

The embedded software that will execute on this virtual platform must comply with the tool chain used to create the target SoC. This platform is binary compatible with the real hardware. The binary that executes on this virtual platform can also execute on the real hardware as it is.

To create this virtual platform we need:

• The specification of the SoC, which is the same specification required by the team developing the hardware-dependent software layer, and
• The tool chain of the target SoC to cross-compile the embedded software.

When we speak of SystemC models for the purpose of embedded software development, the Programmers’ View is the most popular abstraction level used in the industry. Most TLM standardization work targets this abstraction level. The OSCI TLM 2.0 base protocol (LT methodology) and OCP-IP TL4 standards are suitable for creating the models of IP blocks at this abstraction level.

In the rest of this article we will focus on the Programmers’ View abstraction level.

The Algorithmic View

The Algorithmic View is not just a model of the hardware; it is a model of hardware and software as a complete electronic system. There can be different Algorithmic View models depending on which layers of the software stack are included in the model and depending on which layers of the software stack will be developed and verified using these models.

The Algorithmic View (AV1) represents the virtual platform that simulates the functionality of the SoC and hardware abstraction layer (HAL)/device-driver layer together. It exposes the same API interface provided by the real device-driver layer, and can be used to develop the higher layer of the software (generic middleware). The middleware layer is very generic and not specific to any particular hardware. Real-time operating systems (RTOSs) have a generic functionality but can also have some hardware-specific components. This virtual platform abstracts the bulk of the low-level hardware functionality. Thus, there is no need to model the low-level details of hardware.

The processor model need not be at the instruction-set level; it can be an assortment of mathematical functions implemented in C/C++. The peripheral models are not register-accurate. Rather, these are TLMs implemented using C/C++ functions. TLM 2.0 interfaces are not required, there is no standard TLM interface definition available for creating the models at this abstraction levels. SystemC is required only if there is some need to model the concurrency and to maintain the proper sequence using events. The device-driver layer does not implement the actual device driver that programs the registers; instead it will be a dummy layer that simply uses the peripherals through function calls.

The embedded software that will execute on this virtual platform need not be complied with the tool chain of the target SoC. If you compile the software on the host computer using the native host compiler, the executable will run on the host computer. This platform is not binary compatible with the real hardware; the same binary cannot be executed on the real hardware as it is. High-level code developed will be compatible between the emulated system and real hardware. You can compile the same embedded application code with the target tool chain to generate the binary that can be loaded on real hardware.

To create this virtual platform we need:

• The specification of the SoC, and
• The specification of the API interface of the HAL/device-driver layer, which is required also by the developers of the middleware layer using the device drivers.

The Algorithmic View (AV2) represents the virtual platform that simulates the functionality of both the SoC and HAL/device-driver layer and the middleware layer. It exposes the same API interface that is provided by the middleware layer, and can be used to develop and execute the embedded application directly. This is the highest abstraction layer of the electronic system usable for the development of embedded application software. For other aspects, this abstraction is quite similar to the AV1 abstraction explained above.

To create this virtual platform we need:

• Specification of the SoC, and
• The specification of the API interface middleware layer. The same specification will have to be provided to the team who will develop the embedded application.

What Goes Into A Virtual Platform?

A Virtual Platform as a tool for software development/validation and SoC design validation can be broken down into several design components. These include:

• System IP models
• Memory models
• Processor models
• Communication models
• Accessing host interfaces in the Virtual Platform
• Debugger interface support

To create a typical virtual platform of a SoC, we can take the existing virtual platform of some standard board as the starting point. Most of the virtual platform tool vendors provide the virtual platform of some reference board.

The various design components of a virtual platform are elaborated in the following subsections.

System IP Models

Every SoC consist of several IP blocks interfacing and communicating with each other. The register-accurate models of these IP blocks are created using SystemC and TLM2.0.

Models are best when created in conformance to the STARC TLM guidelines. Under these guidelines, core functionality is separated from the interfaces. This allows the maximum code reuse across different abstraction levels. Different kinds of interfaces might be required depending on the virtual platform environment in which the IP model is integrated. One may change the interfaces without influencing the core functionality.

The IP models use the OSCI TLM 2.0 interfaces for connecting with the system bus. OSCI TLM 2.0 is a standard that has greatly enhanced the model-to-model interoperability. The models from different vendors can be seamlessly integrated together to form the complete virtual platform. Almost all the commercial virtual platform tools support the standard TLM 2.0, hence models created in conformance with the TLM 2.0 standard work in any commercial virtual platform environment.

The OSCI Configuration, Control, and Inspection (CCI) working group is defining a standard mechanism for configuration, control and instrumentation of the models. Today, each tool has its own preferred means of instrumenting models. This requires the model developers to provide different instrumentation using different tools. The OSCI CCI standard will take interoperability to the next level by providing model-to-tool interoperability and streamlining the exchange of information between them. OSCI CCI is based on GreenConfig, an open-source mechanism available from GreenSocs. GreenSocs also provides the plug-in for different vendor tools; hence the models created using GreenConfig can be instrumented by any tools. The OSCI CCI standard still unreleased, so until then it is advisable to use GreenConfig for creating the models. Greensocs provides an open-source library.

At the heart of typical system IP models are the four components as listed below. System IP blocks are best modeled with these components remaining mutually exclusive of each other:

1. Communication interfaces (explained in detail below in the Communication Model section)
2. Computation block (this constitutes the state-machine implementation of the functionality of any IP)
3. Register interface (one may implement the register set of an IP as a separate C++ class/SystemC module with implementation of registers and individual fields as C++ datatypes or SystemC datatypes. Creating a common register interface provides optional reconfigurability of size, fields, read-only/write-only, masking, and attaching events or callbacks whenever any read-write operation happens. The register interface should be able to interact with the computational block and the computation block should have access to read/update registers. There is no industry-standard way to implement the registers in a SystemC model; different vendors support different mechanisms. An open-source implementation, Greenreg, is available from Greensocs.)
4. Timing

It is possible to develop models of these IP devices at different abstraction levels with different timing details.

Untimed Models

An untimed model is a purely untimed, register-accurate model created using the blocking interface of TLM2.0. It uses TLM2.0 transport calls with zero-annotated timing delays. Moreover, it models functionality of the IP without any timing details. Implementation without any SystemC thread enables emulation of the parallel operation in real hardware. Having no thread in the IP model makes the complete system very fast. That is because there is no context switching of threads; all operation takes place on a single thread of simulation process. Untimed models are suitable for virtual platforms for embedded software development; however, some software components that depend on the timing of some operations in IP will fail. For example, if the software developer does not expect an IP block to raise an interrupt upon updating of a given register, the software will not properly handle nested interrupts at fast rates.

Loosely-Timed Models

One may use the blocking transport calls of TLM2.0 with some annotated timings. Minimum timing details corresponding to the IP functionality, which are necessary for the embedded software, are modeled as well. In addition, it is possible to create these models without using any SystemC thread or by using a minimum number of threads. The IP model may realize the delay by calling wait, or by using the threads sensitive to timed events. If the delay stems from register access or a functionality corresponding to register access, then instead of realizing the delay, the IP model can send the delay back to the initiator by updating the annotated timing argument of the blocking transport call. Due to context switching, multiple threads result in slow simulation.

Use of temporal decoupling can enhance the system speed by reducing the amount of context switching between threads. Temporal decoupling allows a thread to run ahead of simulation time by keeping track of time through a local variable, and then sync up with the simulation kernel when Quantum has been reached.

Timed Models

More accurately timed models are created by using the non-blocking interface of TLM2.0 using the AT methodology or by extending the base protocol for more timing points. The functionality of the IP can also be modeled with accurate timing details. These IP models are created with multiple SystemC threads to emulate the real concurrent operation of real hardware with their timing detail. These models are not suitable for the purpose of embedded software development.

We can create the model in such a way that timing is configurable, making the same model usable in  different use cases.

Memory Models

Memory is a very important component in a SoC. The majority of the communication traffic in an SoC consist of memory reads/writes. Thus, to create a fast virtual platform, memory models must be highly optimized for read/write access.

Memory models should be compliant with OSCI TLM2.0. In addition to the core transport interfaces, the memory models should also implement the DMI interfaces defined in OSCI TLM2.0. By default for memory read/write, the instruction set simulator (ISS) will call the blocking transport function. Due to high memory access traffic, the number of transport calls will be very high and that will have an impact on the simulation speed. Using the DMI interface, a pointer for the memory data is passed to the ISS/master model so that the ISS can directly access the memory instead of making the transport function call.

The memory model should not realize the read/write processing delay by calling the wait for each read/write call. Calling the wait frequently can have severe impact on the simulation speed. Instead of realizing the delay itself, the memory model should send the annotated delay to the initiator through the transport call argument. This will provide the flexibility to the initiator to use temporal decoupling so that instead of calling wait after every transport call, it may sync up after many transport calls.

Processor Models

You’ll need a software model of the processor core creating the virtual platform of the SoC. Most of the companies create the processor model using some proprietary technology based on C/C++. Wrapping the processor model in a TLM2.0 wrapper enables integration with other TLM2.0-compliant models of IP blocks to create the complete virtual platform. Processor models come from the processor companies or the virtual platform tool vendors. There also are some open-source processor models also available (OVP, Qemu, etc.).

There can be different kinds of processor models. ABI-compliant (or ISS) processor models are nominally instruction-accurate models. ISS models also can be cycle-accurate for use in the virtual platform with accurate timing details, or they can be untimed models for use in the virtual platform at a higher abstraction level for embedded software development.

The tool chain of the target processor compiles the embedded software that will run on the virtual platform. The instruction set simulator reads the instruction set of the target CPU and generates host instructions to simulate those target instructions in the virtual platform. It also maintains the internal state of the processor (registers). However, runtime translation of code on an instruction-by-instruction basis will result in a slow simulation; this is a consequence of the ISS speed, which is slow compared to the host processor. Applying various optimization techniques in the ISS may enhance the simulation speed. For example, QEMU uses the caching of runtime-translated instructions.

Then there are non-ABI-compliant processor models, which require native compilation. In such an approach, the target software running on the virtual platform is compiled with a special native compiler that translates the target software code into the instruction set of the host computer to simulate the behavior in the virtual platform. Because no runtime code translation is applied, this approach results in fast system simulation. However, development of these native compilers and handling of memory and peripheral read/write instructions in the virtual platform is complex. Such systems require more time to design and develop.

Communication Models

Communications in the context of an SoC can be divided into two categories. For one, there is on-chip communication between the various IP blocks, and for another, there are the external interfaces for communicating with peripheral devices.

First, let’s look at on-chip communication. SoCs consist of one or more processor cores and numerous other IP blocks. All these blocks transfer data amongst themselves by means of pins and wires. When creating the models at higher abstraction levels, we need not create the pin-level interface. Instead, we can conduct the data transfer using high-level function calls using transaction-level models (TLMs). TLMs provide a huge performance enhancement compared with pin-level models.

Most of the SoC uses some flavor of memory-bus protocol through which the processor core (master) communicates with all other IP blocks (slaves). OSCI’s  TLM2.0 standard provides the transaction-level interfaces for the memory mapped bus protocol. There are different SoC buses popular in the industry (AMBA, PLB, etc.); these have different protocol definitions and timing details. However, while creating the models at higher abstraction levels, these lower-level functional and timing details need not be modeled. OSCI TLM2.0 provides a high-level “base protocol” that can represent any memory-mapped bus at higher abstraction levels.

OCP-IP defines a high-performance, bus-independent interface between IP cores. This makes the IP core independent of the architecture and design of systems in which they are used. The Open Core Protocol provides a configurable set of features that is a superset of the features delivered with any memory-mapped SoC bus. The standard interface allows the IP cores to connect with any SoC bus.

OCP-IP also provides a comprehensive modeling kit that represents OCP-compliant models at different abstraction level. This kit extends the OSCI TLM2.0 standard for OCP protocol-specific details. The TL4 and TL3 abstraction levels defined in the OCP-IP modeling kit are the higher abstraction levels; these are similar to the base protocol in OSCI TLM2.0. The TL2 and TL1 abstraction levels are the lower abstraction levels, which model the finer protocol details (functionality and timing) as per the OCP protocol. When creating models for the purpose of embedded software development, it is sufficient to create the models at the TL4 abstraction level. For any SoC that uses OCP for communication, it is highly recommended to use the OCP-IP Modeling Kit to create the virtual platform. It will allow you to refine the virtual platform to lower abstraction levels by simply replacing the TL4 sockets with lower abstraction sockets (TL2 and TL1), or by using the proper adaptors, thus making the virtual platform suitable for RTL verification, architectural exploration, and so on.

Apart from the pins corresponding to memory-mapped communication, the IP blocks in an SoC may also have other pins for communication, such as the interrupt line of an interrupt controller or the gate input of a timer. These are individual pins that cannot be clubbed with other pins to form a communication protocol.

One way to model these pins is to use the standard SystemC ports (sc_in, sc_out). Communication through these SystemC ports is based on the events and update cycle of the SystemC scheduler, which impacts the simulation performance. More signals means greater degradation of simulation speed. Further, when creating abstract models of such pins, it is advisable to use the function calls for the communication instead of using the pins themselves. You may define a TLM interface that can carry the value of the signal through a payload variable. Another way to accomplish this is by using the extension mechanism of the OSCI TLM2.0 to define a new protocol or, in other words, by replacing the generic payload with a custom payload. In this case, you define a new TLM protocol for each signal; the connection is made through a one-to-one initiator and target socket connection.

Another way can be to define a common TLM protocol for all such signals in an SoC. To do so, add a payload data member or each signal as a payload extension. In this case a bus will have to be used to route the signal from initiator to target, as all the initiator sockets of the IP blocks will connect to the target socket of the bus while all the target sockets of IP blocks will connect to the initiator sockets of the bus. Using the bus instead of one-to-one connections does not provide any performance advantage, but it may provide some convenience in making the connections. However, that convenience comes at the cost of defining a more complex TLM protocol and modeling an extra component (the bus). This makes sense only if there are many such signals in the SoC.

External Interfaces

An SoC also provides interfaces for communicating with external devices. Examples of these interfaces are USB, Ethernet, WLAN, CAN, UART, I2C, SPI, SATA, and others. At higher abstraction levels, there is no need to model these protocols in bit-accurate or cycle-accurate fashion to achieve similarity to the actual physical media. Instead, we can transmit complete packets using function calls and annotated timings. While creating the models of IP blocks that use these communication protocols, there is no need to create the pin-accurate models. While the TLM protocol must be defined for each of these communication protocols, all the IP pins corresponding to the communication is abstracted away by TLM sockets.

OSCI’s TLM2.0 defined the standard TLM interfaces and base protocol for the memory-mapped buses. However, for non-memory-mapped buses (USB, Ethernet, WLAN, CAN, UART, I2C, SPI, SATA, etc.), there are no such standard TLM interfaces and protocols yet defined. TLM protocols for each of these communication buses have to be defined for creating their models at higher abstraction levels. OSCI TLM2.0 provides an extension mechanism that goes beyond the base protocol, and new TLM protocols can be defined for non-memory-mapped buses by extending OSCI TLM2.0.

The focus of this article is use of virtual platforms at higher abstraction levels for the purpose of embedded software development; this requires creating the untimed or loosely timed models using the blocking interface of OSCI TLM2.0. Thus, while extending TLM2.0 for non-memory-mapped buses we can just focus on the blocking interface.

Extending TLM2.0 for a non-memory-mapped bus requires defining a new payload specific to that bus. The payload will have the variables corresponding to TLM commands (similar to read and write in base protocol), the transmitted data, and the control signals (for handshaking protocol) associated with those commands. If we want to create more timing-accurate models (approximate-timed or cycle-accurate) at lower abstraction levels, we will need to use the non-blocking interface of TLM2.0. In such cases, we will also have to define the phases corresponding to the timing points in a transaction. The number of phases will depend on the number of timing points in a given transaction. For greater timing accuracy, we will need more timing points and hence more phases.

It is not necessary to extend OSCI TLM2.0. One can also define different interfaces (function calls) and protocols for each non-memory-mapped bus. Moreover, extending TLM2.0 does not warrant interoperability, because different persons extending TLM2.0 for a specific non-memory-mapped bus may define different payloads. That means models from different vendors cannot be connected out of the box, and some kind of adaptors will have to be created to connect them. The industry needs a standardization initiative for defining standard TLM protocol for the popular non-memory-mapped buses.

However, extending TLM2.0 does provide some advantages as compared to defining your own interfaces, as listed below:

• The common infrastructure and utilities (sockets, memory manager, PEQ, quantum keeper, and so on) provided as part of TLM2.0 can be reused.
• It is good to use the standard interfaces (b_transport and nb_transport) and standard terminologies for different modeling concepts (LT, AT, timing annotation, temporal decoupling, and so on). All these concepts will be applicable to any communication bus and not just the memory-mapped buses. Instead of defining different terminologies for each bus, it is better to use consistent terminology for generic concepts.
• The extension mechanism defined in TLM2.0 provides a standard mechanism to have TLM protocols for different variants of the same communication bus, or the TLM protocol for the different modeling abstraction of the same bus.

SoCs with a specific non-memory-mapped interfaces will have the controller IP corresponding to that interface. For example, if an SoC provides an Ethernet interface, then it will have a Ethernet controller IP, or if it provides the USB interface, it will have the USB host/device controller IP. The models of these controller IP blocks will have a TLM2.0 socket on one side, through which the processor can access the registers of these blocks. On the other side, the controller IP will have the interface-specific TLM socket (USB-TLM, Ethernet-TLM, and so on). This interface-specific socket connects with an external device. The external device should also understand the same TLM protocol.

When creating models of such IP blocks, you will need a generic back end to handle the interface-specific TLM communication for the external device. The model of the external device can use this generic backend component and implement the device specific functionality. If an external bus interface allows ultiple connections, then you should create a virtual bus model (router) that allows connecting multiple devices through the interface-specific TLM socket. Such a layered approach allows connecting the virtual platform with different kind of backbends (virtual model of the external device, physical interface on host computer or the RTL of external device, and so on).

Accessing Host Interfaces in the VP

Any SoC provides the interfaces for connecting with the external devices. The embedded software running on the SoC can access the external devices through these interfaces. While creating the virtual platform of a SoC, one of the challenges is how to test these external interfaces. One mechanism is to create the SystemC models of the external devices and connect these device models with the SoC through the TLM sockets corresponding to these external interfaces. The embedded software running on the virtual platform will access the software models of these external devices. This is not the best mechanism; for testing the real software, the best way is to use the real external device. The host computer on which the virtual platform executes provides some general-purpose interfaces (such as USB and Ethernet). If we can access these physical interfaces of the host computer in the virtual platform, then the software running on the virtual platform will be able to communicate with the real-world physical devices. This provides a very powerful virtualization environment for testing the embedded software.

Let us look at how to access a USB port of the host computer inside the virtual platform. The host-controller model is contained within the virtual platform as a register-accurate model. This model must meet the specifications of the USB host-controller IP block in the SoC; it could be some standard host controller (such as EHCI or UHCI) or a vendor-specific controller. The standard USB driver in the guest operating system (running on the virtual platform) should work fine with the model of the host controller just as it does with the real host-controller hardware. At the back end, this model exposes the transaction-level APIs for the USB transfer (USB-TLM1).

The USB back end is a layer that processes the USB-TLM1 communication from the host controller model and connects with the USB device through the virtual USB bus model. The USB device in this case can be a virtual model of the USB device, or it can be the USB back-end driver. The latter acts as a USB application in the user space of the host computer. On one end it interacts with the USB stack of the host computer to access the USB port of the host computer, while on the other end it hands over the USB data to the back-end model, which passes it to the USB host-controller model (through USB-TLM1 APIs). The back-end driver must be developed for a specific host OS (Linux/Windows), and it is independent of the guest OS running on the virtual platform. You may also use platform-independent libraries, such as libusb, to gain user-space API access to the USB stack. Similarly, we can access any other interface available on the host computer (Ethernet, WLAN, printer, speaker, microphone, LCD screen, camera, and so on).

Debug Interface

One of the advantages of using a virtual platform for embedded software development instead of using the FPGA board is that the virtual platform provides powerful debugging features. With use of multicore systems on the rise, debugging such systems and reproducing bugs in them can be very challenging. Virtual platforms make the debugging of applications much easier; it provides better visibility into hardware and software simultaneously at run time. A virtual platform should provide the following features for debugging:

• Loading of binary code in simulated memory or flash device
• Provide an interface for connecting the debugger (GDB stub/OCD interface export). Debugger can be used to debug the embedded software running on the virtual platform.
• Controlling the state of execution of virtual system, such as running and stop mode
• Interface to get/set internal state register, variable of the SoC/IP model
• Saving and restoring the simulation state of the virtual platform at any time
• Tracing any transaction between different IP or back-end model at run time

Development is proceeding on advanced debugging tools that work with virtual platforms. For example, one may use SystemC-aware debuggers to debug the embedded software along with the hardware threads.

CircuitSutra focuses on SystemC-based SoC modeling services The company has created a demonstration virtual platform of an ARM-based SoC using the OCP-IP modeling kit. This virtual platform boots the Linux operating system in about five seconds and is suitable for embedded software development. It is available as a free download from: http://www.ocpip.org/vp_package.php.

References:

\\[1\\] OSCI TLM2.0 Language Reference Manual
\\[2\\] OCP-IP Modeling Kit
\\[3\\] OSCI CCI: Requirement specification for Configuration Interfaces
\\[4\\] GreenSocs: Open source infrastructure for SoC modeling (www.greensocs.com)
\\[5\\] Zeeshan Anwar, Reusable Device Simulation Models for Embedded System Virtual Platforms
\\[6\\] STARC compliant demo SystemC models (http://www.circuitsutra.com/downloads.php)