[Part 1 begins with an overview of the ground conditions for the case study, and with a decision-making flow chart for moving from the ARM to Intel Atom Microarchitecture.]
Split of Functionality across Processors, on the Basis of Upstream/Downstream Functionality
The next few sections give some example solutions based on cable modem functionality. Generic terms like upstream packets, downstream packets, control packets, map packets, and transmit scheduler are used in the following few sections. All of the block diagrams are designed to give the reader an idea of the splits possible. This paper does not go into detail on the cable modem solution, but rather to use the cable modem solution as an example.
Please read this section before proceeding
The following is a brief explanation of the overall cable modem design. This explanation will be relevant for the next four sections.
The cable modem design has three distinct types of packets – upstream packets, downstream packets and control packets. There are time-critical aspects in all of these packets. The most time-critical packet of these are called map packets. Map packets come in the downstream direction and are control packets. Map packets specify the time instance at which the next upstream packet can be sent. In the map packet, the next upstream packet can be specified to be scheduled 200µs from the time the map packet has been received at the cable modem. This creates a real-time requirement of 200 µs in which the map packet must be processed in the downstream direction so an upstream data packet must be prepared and sent out of the cable modem.
Most of this processing was executed using software. A component called Mini-MAC provided a basic level of filtering to figure out if a downstream packet is addressed to our cable modem. The rest of the processing, filtering, building, etc. of the packet was performed with software. The Phy was capable of both CDMA and TDMA transmissions.
Figure 4 Conceptual Design
In this design, all of the upstream processing was executed on one processor, which also performed the real-time map processing. All of the down-steam processing is done on a different processor, making use of two processors in this design. We also made use of a symmetric operating system, where different threads were programmed for a particular core affinity.
Figure 5 shows the practical design of this two processor solution. Area marked in red encapsulates the processing performed on processor 2. The other area shows Processor 1.
Figure 5 Practical Design
This approach is optimized across cores, as both processors split the work as well as the communication across the cores.
The communication across cores is minimal and also does not fall in a time critical path.
This approach needs the Mini-MAC to process classification of MAC control packets. Our hardware was originally designed in a manner where the hardware component (Mini-MAC) would process only destination address filtering. In this design, a hardware change was needed so MAC control packets could be identified in hardware and transferred to a separate queue before the software on a different processor started handling them.
If we need to code MAP/TxScheduler in assembly, then it will get a little trickier. For performance reasons, it might be necessary to code some critical parts of map processing and transmit the scheduler. Writing code in assembly is error prone and development usually is more cumbersome.