Virtual machine architecture needed for complex processing, next-gen wireless

Virtual machine architecture needed for complex processing, next-gen wireless
Advances in wireless technologies have ushered in an array of new standards that enable revenue-generating applications built on faster data rates, increased network capacity and improved voice quality. The impact of these standards is to drastically raise the level of engineering complexity for product developers by increasing processing requirements, requiring support for packet-based services and introducing the need for multimode devices to provide contiguous service coverage.

The combination of these challenges has been increasingly disruptive to wireless-systems developers as they attempt to meet time, functionality and cost requirements. These challenges will only exacerbate the problem of meeting the DSP and other processing requirements of next-generation wireless devices — the ones beyond 3G.

The solution to solving the complex development problems facing next-generation system designers is to implement a new development paradigm: an integrated system-level design tool and an embedded run-time virtual-machine element that manages the underlying system complexity and provides a hardware-abstraction tool to enable code reuse.

Hardware abstraction is a new idea for wireless Layer 1 development, but it has been successfully deployed in other development areas. The history of non-real-time computing is a story of the management of complexity through the genuine emergence of reusable components with encapsulating application programming interfaces. The approach proposed involves applying those well-proven concepts in the "hard real-time" domain, and offers designers a radical and timely solution to the problem of building multimode, multiband and multifunctional wireless devices.

The realization that there is a need for a hardware-abstraction layer is the beginning of the challenge. Hardware abstraction needs to be part of a virtual-machine architecture that also provides system management. Creating a virtual machine capable of functioning as hardware abstraction and as a Layer 1 system manager requires a sophisticated development environment to guarantee successful deployment.

By necessity, this development environment must differ from the current static approach of co-simulation design flows. It must address the reality that the only way an efficient end system can be deployed is through the use of a virtual-machine layer, integrated design flow and optimized, application-aware run-time — one derived as a result of system simulation. Reentrant design tools provide the appropriate approach.

Reentrant design flows make it possible to take a working design or set of design components and rapidly repartition it to a different candidate hardware target process, driving in the critical cost metrics such as dollars per channel. The addition of a native run-time virtual-machine element makes the portability from one target to another an easier task to achieve. Design elements are no longer wedded to the underlying baseband, but are tied to a highly portable virtual-machine layer instead.

The virtual-machine element is integral to the design environment because it supports multivendor intellectual property — both at the high-Mips "transform" level and at the stack level — through the co-simulation of multiple systems' (UMTS FDD and GSM in compressed mode) independent constraints.

This design flow supports DSP, ASIC, FPGA and dedicated accelerators. It is largely a software-based paradigm, which makes it easier for the end user. Targeted at the creation of architecture-neutral software and commoditized, high-Mips transforms (engines), the embedded run-time software makes this design flow unique because it can handle multichannel systems where resources — for example, hardware endpoints implementing a Viterbi decoding function or a rake finger array in a wideband-CDMA chip-rate ASIC — are logically shared or scheduled between a number of logical "user plane" data paths.

The virtual-machine environment is produced as a result of the reentrant design process. It is used as the run-time software substrate for physical-layer stack development to manage the details of complex, multichannel wireless systems. The virtual machine manages requests from the high-complexity, low-Mips "executive" code through to the hardware and software instances of implementations of the normalized behavioral types that were set up during the partitioning phase in the system design.

The three key functions of the virtual-machine run-time are:

• Resource management,

• Parallel scheduling that is aware of partitioning decisions at design time,

• Engine dispatcher.

The resource-management facilities are critical since the hardware-abstraction layer makes the high-level stack code architecture-neutral. With its direct links to the underlying hardware now managed by the virtual machine, the protocol stack needs the resource-management capabilities provided by the virtual machine. The resource manager also gives a regulated set of real-time operating system capabilities to higher-level software, which works over the RTOS implementations already in place. The virtual-machine run-time element detects common threading, interrupt, memory and resource-management models, which will then be mapped onto the existing primitives for any third-party RTOS by its run-time implementation.

The push for complex digital processing has resulted in a rise in parallelism, the use of multiple DSP cores on-chip and in hardware. Parallel architectures make it necessary to support parallel and random scheduling for dispatch of engine requests. Most RTOSes do not support this, and those that do support a small amount of parallel execution do not identify the partitioning decisions made at design time.

The wireless virtual-machine software provides a parallel scheduling system that is configured beforehand by the design process with the design-time mappings, endpoint communication primitives and simulated resource and recorded data flow. High-level code can request execution of high-Mips transforms through the parallel scheduler API. An added advantage of the virtual-machine layer is that it enables code to communicate between cores with different RTOSes, which is important when partitioning between a DSP and a RISC core.

Another element of the run-time is an engine dispatcher, which supplies a bridge between the messaging layer and the actual code that fulfills the responsibility of an engine, whether in hardware or software. During this process, the high-level code requests completion of an engine using the parallel scheduler, which will map it onto a hard or soft data path. Then the scheduler sends a package of memory handles to the appropriate dispatcher endpoint via the message-passing primitives stemming from the resource-management layer. Lastly, the engine dispatcher gets the request, localizes memory, using DMA if need be, and then activates execution of the transform.

After this is finished, the dispatcher informs the control code layer. When a hardware implementation is used, the dispatcher manages the communications. It also DMAs the data into the appropriate memory-mapped addresses, creating a record to start the computation. Then it waits for the interrupt callback that specifies when the cycle is finished.

Flexible data transfer components, endpoints, make it possible under this flow to have efficient "pipelined" hardware implementations. Memory buffering is used only by the last block in the chain, which will communicate with a more latent DSP, for example. The design flow takes care of adding the right endpoints to the system, based upon the user's partitioning decisions. This enables users to quickly and transparently shift deployments between dedicated function hardware and more general processors.