In Chapter 1, the scope of the research was defined. The DRMP is meant
to be used in consumer hand-held devices that are both multi-standard and power-sensitive. To start the design process for an architecture, some as- sumptions were made, and the requirements and constraints were defined. Together they served as a guide for the research effort and the architectural choices.
3.2.1
Assumptions
• The platform will switch dynamically between three different wireless protocols as required. It will only implement the MAC layer function- ality.
• The implementation of the PHY layer implementation, whether in re- configurable or fixed logic, is independent of the MAC implementation. The PHY implementation may be on a dynamically reconfigurable ar- chitecture too, or there may be a separate fixed logic implementation
for each protocol2 (See fig 3.1).
• It is assumed that the target device may be transmitting or receiving concurrently via up to three different wireless standards. E.g. the user may use a WLAN protocol to access the internet, while concurrently using a WPAN protocol to access peripheral devices.
• No assumptions have been made about the operating system running on the host application processor or about its performance.
• It is assumed that the host application processor will allow Direct Mem- ory Access (DMA) access to MAC platform for frame transfers. • Although the platform is intended to implement the complete MAC
layer, the research focuses on a subset that demonstrates its viability. • The DRMP is expected to replace the MAC implementations of three
different wireless MACs in a device. Where there was a separate device for each protocol MAC, there will now be one device, the DRMP, that handles the data of three MACs simultaneously, and interfaces to the corresponding three PHY layers.
3.2.2
Requirements and Constraints
The requirements and constraints for the architecture were considered keep- ing in mind the scope of its intended application. These requirements were broad and abstract, but they impacted the design decisions that eventually led to the DRMP architecture as it stands now.
• Power: Due to the nature of the target market, the power-efficiency is a key optimizing parameter for the DRMP architecture design effort. However, since the device is meant to be flexible enough to implement 2In context of protocols belonging to the IEEE 802 family, which have been the focus of this research, the MAC-PHY interaction is explicitly specified by the standard.
different MAC layers, so certainly there is a trade-off. The objective is to provide a lower-powered alternative to a CPU or FPGA based flexible solution, such that it can be used in a power-sensitive consumer hand-held device.
This power constraint also implies a certain limit on the overheads allowed for the provision of flexibility. These overheads should be con- siderably less than those of general-purpose flexible architectures like FPGAs or CPUs.
• Flexibility and Programmability: The requirements for flexibility can be better appreciated in three separate categories: Design-time flexibility (or platform derivation), Compile-time flexibility (or pro- grammability) and Dynamic flexibility (or dynamic reconfiguration). Design-time flexibility is needed because the DRMP is not meant to provide general-purpose flexibility for all possible MAC implementa- tions. Hence there should be a mechanism to quickly make changes in the architecture to adapt it to new protocols with novel functionality that need hardware acceleration.
The platform should have a clear Application Programming Interface (API) that allows programmers to use the available hardware resources for MAC implementation. The hardware architecture should be trans- parent. It should be convenient to use so that new protocols can be quickly deployed. The strict time-to-market constraints of the con- sumer wireless market dictates this requirement for quick and conve- nient programmability.
The platform should be able to dynamically reconfigure quickly enough to handle interleaved packets of three different protocols without com- promising the real-time constraints. The requirement was introduced to allow concurrent use of multiple wireless protocols in consumer hand- held devices.
There should not be any redundant flexibility in the device so that the overheads are kept to a minimum.
• Performance: The platform is meant to be a domain-specific one and so it only needs to be able to deal with the real-time requirements of the MAC protocols. That is, it should be able to process the packets fast enough to make them available to the upper and lower layers when they are required, as dictated by the protocol. Processing the packets any quicker is not going to add any value to the platform.
• Area and Cost: Although area has a relationship with the power- efficiency, it is considered separately from power considerations. Power optimization techniques can result in considerable efficiency even with a large silicon area. The area of the device is thus constrained primarily by the cost. The architecture is targeted for use in consumer devices, and the area and the resulting cost should be appropriately suitable. • Integration: The platform should provide clear and standardized in-
terfaces to all externals like the PHY layers or the upper layers. It should transparently fit in the protocol stack of a multi-standard hand- held device. There should not be any assumptions on the architecture of the Application SoC itself.
• Standards Compliance: The platform is meant to comply entirely with the published standards that it implements. However, because of the complexity of the standards, it is unrealistic to design a fully standard-compliant platform within a single doctorate project. There- fore liberties were taken in this area but not to the extent that the experimental results are rendered meaningless.