One approach to mitigating the mapping problem is to restrict both the protocol systems and the possible implementation architectures. Since the “abstract”
specification really defines a class of implementations, one can choose a subset by
architecture and implementation. The loss of some generality and flexibility can be offset by the ability to develop and reuse a library of implementation components with well-understood and adequately characterized high-level abstractions. This library can be created manually and tested extensively, easing the mapping for the class of protocols of interest.
To develop such an architectural template we will need several pieces of information:
1) An architectural template that defines the physical resources (hardware, microprocessor, DSP, etc.) that are typical in the implementation domain (wireless, mobile communications)
2) A functional model of that partitions the protocol into processes that will be implemented in software and processes that will be implemented in hardware
3) A model of the communication between hardware processes, between software processes, and between hardware and software processes
The first problem restricts the implementation space to implementations that would be suitable for the domain of wireless, mobile computing. Systems with an ultra-high performance microprocessor, or multiple microprocessors could be ruled out for portable applications. Thus, we will look for a general architecture that would be suitable for the constraints of portable, handheld devices that must be low-cost, small form-factor, and energy efficient.
The second problem is one of taking a very general specification and breaking it into smaller pieces that can be mapped onto hardware or software. Such decisions are based on a rather complex set of tradeoffs that include factors such as energy
efficiency, throughput constraints, how frequently a task is executed, and the flexibility and cost advantage of implementing in software.
The third problem is that of providing an infrastructure that is consistent with the abstractions provided by the high-level specification language. For example, SDL processes communicate over channels that provide a logical inter-process communication path; a process sending a signal cannot specify the delivery mechanism that moves a signal to the destination process. Thus, to provide a natural mapping between an SDL process and an implementation process, we would like to provide an infrastructure that provides a service equivalent to the SDL channel.
Tools that create an executable software implementation of an SDL system are commercially available. Typically, these tools consist of a code generator that creates a collection of C language procedures that correspond to SDL processes.
The execution environment consists of a scheduler and a set of user-supplied library routines (e.g., system clock, interprocess communication primitives) that provide a message-passing interface between the SDL system and the
“environment”.
Since our goal is to map onto a mixed hardware/software, we will need a modified strategy that will allow us to selectively map pieces of the SDL system onto a hardware implementation and map other pieces onto a software system. By designing a set of interface routines that provide the infrastructural glue between the hardware and software, we can develop a reusable methodology.
RF + Mixed Signal
Baseband Signal Processing
MAC/Data link Protocol
Logic
µProc
DSP FPGA
Custom Logic
System bus
Memory Architectural
Mapping
Figure 6— 2. Typical Embedded System Architecture
6.3.1 A domain-specific implementation template
The focus of this thesis is on embedded systems implementation of link layer protocols for wireless systems. It is envisioned that wireless communication systems of the future will be realized in a single-chip implementation that provides the RF, mixed signal, baseband processing, and link-level protocol control all on a single die.
Such an architecture is depicted in Figure 6— 2. Although conceptually there is a clean functional delineation between the RF/Mixed signal, signal processing, and protocol subsystems, what complicates the implementation is that these functional
lines begin to blur. For example, the media access protocol typically controls part of the functionality of the other two subsystems.
The power amplifier in a transmitter, for example, can be controlled by both the media access and the data link protocols. In a half-duplex frequency-hopping transceiver, the power amplifier must be shut down prior to changing frequencies.
Digital circuitry in the signal processing layer may also be controlled by logic in the data link protocol, as in the case of variable-rate error correction coding1.
At the block-diagram level, there are few differences between such a device and the InfoPad portable terminal architecture presented in Chapter 2. What they have in common is a mixture of custom-logic components, reconfigurable-logic components, and general-purpose processor that are connected via communication paths (busses).
Ideally, we would like to be able to take functional blocks from each of the high level domains (mixed signal, DSP, and protocol) and map these blocks down onto the desired architecture, and have an automated way of generating the necessary infrastructural “glue.” Unfortunately, this capability does not yet exist. For the present purpose, we restrict our attention to the problem of mapping the functional units of the protocol down onto our architectural template.
1 Typically error correction coding is associated with the data link layer (above the media access layer in the OSI stack). With a variable rate code, there must be controller that
6.3.2 A template for computation and communication in mixed hardware/software implementations
Figure 6— 3 depicts a logical model of the architectural template for an embedded system implementation of a system of communicating finite state machines. The system consists of a collection of state machines that are mapped onto either a software process or a hardware process. These state machines communicate using either message passing or by using a direct read/write to evaluate or modify a variable in another process.
The execution environment consists of an interprocess communication API that supports both of these communication mechanisms. The high-level specification for any of the processes sees the same API, independent of where the process will be implemented.
HP1 HPN
…
SP1 SPN
…
Interface Fabric
HW/SW IPC Layer SW/HW IPC Layer
IPC Abstraction Layer IPC Abstraction Layer
Figure 6— 3. Architectural template for embedded system implementation
6.3.3 Partitioning strategy: the SDL process as the smallest partitioning unit
The architectural template described in the preceding section provides a framework that will allow us to map SDL processes onto either a hardware or software process in the implementation. One of the tenets of this thesis is that link-level protocols for high-bandwidth, low-latency wireless communication in portable devices must be tailored with the implementation domain in mind. Bandwidth efficiency, energy efficiency, and support for mobile networks cannot be ignored in the design of the protocol system. Thus, at least in the structural partitioning of functionality, the specification must have some consideration of the possible implementations.
Because of this, it is not unreasonable to require the specification to partition functionality into indivisible units that can be directly mapped to a software or hardware process. Our approach is to jointly consider the implementation template as the formal (SDL) specification is developed, and to use the SDL process as the smallest unit of partitioning. These processes are later assigned to either hardware or software resources, and the appropriate interprocess communication support can be generated. In designing each process we will consider its likely implementation – whether hardware or software – and will attempt to avoid designing a process that will end up being partitioned into a partial hardware and partial software implementation.
For example, the IEEE 802.11 protocol requires MAC entities to maintain a
“network allocation vector” that tracks, to the extent possible, media access requests by other MAC entities. When a station needs to use the media, it sends a short “request to send” (RTS) that includes the transmit duration of the following
(CTS) message that also includes the length of the upcoming payload packet. Any listening station who hears such an exchange is required to note the length of the payload (plus a following “acknowledgement” packet) as part of its network allocation vector, and it must refrain from using the media until its network allocation vector is cleared.
It would be possible to capture this functionality in a single state machine that encapsulated all of the required behavior, but the resulting state machine would handle events that span about 6 orders of magnitude of time duration. If this state machine were described as a single SDL process it would be impossible to partition the functionality onto the appropriate hardware and software elements of a typical implementation.
An alternative strategy, and one that would be much better suited for mapping to a mixed system, is to partition the system along lines of similar time granularity.
Thus, in our example, we might identify a state machine that tracks the network allocation vector and puts the rest of the system to sleep when the network is to be occupied for a sufficient period. Another state machine might handle the low-level bit-to-word construction, and a third state machine might interpret these incoming words to determine how the network allocation vector should be updated.
With this guiding principle for our specification, we are able to utilize commercial code generators to produce the code for the processes that are mapped to software.
For the processes that are mapped to hardware, the refinement approach presented in the previous chapter can be employed. What remains is to provide the communications interface between the hardware and software, and the execution environment for the software processes.
6.3.3.1 System partitioning and code generation
In the current SDL specification, there is no provision for partitioning a system or for specifying execution priorities among processes. Commercial SDL tools provide code generation directives that are embedded in the comments or informal text of the SDL specification.1 These directives allow the user to specify the partitioning granularity for code generation along SDL block and process boundaries.
These code generation tools assume that the entire system is to be mapped to software, and that operating system support will be used to provide the infrastructure. Since our implementation will include a mix of hardware and software, a precise mapping from SDL to our hybrid system is difficult, since the synchronous hardware subsystems and the microprocessor execute independently.
Once again, an informal mapping is used whereby we capture the essential features of the SDL model in the final system, but lose the ability to formally verify if the implementation behavior implies the specification behavior.