The DRMP platform targets hand-held/portable devices - in other words devices where power is an important consideration. For power-insensitive devices, the more attractive option for incorporating flexibility is to imple- ment the MAC entirely in Software or an FPGA.
It is meant to target multi-standard hand-held devices that need to deal
with multiple wireless standards at the same time. Such devices are al-
ready present in the market and the trend is towards greater integration of standards in a single device. Eventually, this platform could be used for Software-defined radios. But that is not the main target and so the unique considerations associated with SDR’s were not addressed in the project. It is also meant to address the wireless protocols that can be typically ex- pected in consumer devices. So WiFi, Bluetooth, WiMAX are the protocols that will be targeted. Protocols like Zigbee which are not designed for con- sumer devices were not considered. The reason for aiming at consumer de- vices is that these devices tend to be produced at massive scales and in such scenarios it becomes possible to justify a domain-specific hardware platform. Having run simulations involving transmission and reception of packets of
three different protocol modes concurrently, the results have confirmed that the processing of packet on the DRMP architecture takes a fraction of the
actual duration of the packet (See table 5.1 on page126).
In section5.5, these results were discussed, where it was seen that the DRMP,
clocked at 200 MHz, manages to process the transmission and reception of three packets simultaneously at data rates of 20 Mbps—yet the functional units remain idle for more than 90% of the time. The power-saving oppor- tunities offered by this time-slack and the limited interconnect requirement
in the hardware co-processor were also discusssed. In section6.1, the power-
consumption of the DRMP was estimated, without using any power-saving
techniques that were discussed in section 6.2.
With these results, there is effectively a proof-of-concept that the DRMP can replace up to three MAC processors in a hand-held device. This should make it a attractive SoC IP for the hand-held device market in one the following contexts:
• an IP on another higher-level SoC • a chip on a System-in-Package (SiP) or
• a packaged chip on a PCB — though considering the form factor of the target devices, this option is unlikely.
The potential customer thus could either be a chip manufacturer or a device manufacturer. The possible considerations of an expected customer looking to use this IP in one of the above scenarios will now be discussed, along with where the DRMP stands at present in view of these considerations.
6.3.1
Power-Efficiency
The tool used to model the DRMP (Simulink), and the way its been used (abstract functionality, relatively exact timing) imply that only a crude first- order estimation of power and area expected to be used by the DRMP, can
be made. It should be noted though that the DRMP is not an attempt to optimize the power-efficiency or gate-count. It aims to provide the flexibility needed to incorporate multiple MACs in a single device, while keeping the power-efficiency acceptable for a hand-held device. That is to say, the aim is to keep the power consumption below a certain threshold of acceptance for hand-held devices; and certainly less than that of the architectures tra- ditionally used where flexibility is required e.g. microprocessors or FPGAs.
Table6.5gives the first order estimates of gate count and power consumption.
A 0.25um technology and operating frequency of 85 MHz is assumed for estimating the power consumption. It was found that the first-order estimate of die area was within acceptable range for mobile devices.
In brief, the first order calculations indicate that the DRMP will indeed be suitable for power and resource sensitive hand-held devices. But some effort to get more accurate estimates would be in order before committing more resources to this architecture’s further development.
6.3.2
Performance
Performance here means the throughput—how fast can the DRMP process
packet data. The aim is simply to achieve throughput above a certain
threshold—the real-time throughput requirements imposed by the protocol. Once that threshold is crossed, nothing is gained by further improvements in the performance. Fortunately, because of the cycle-approximate model of the DRMP, it is quite straightforward to decide if the DRMP is meeting the timing requirements of the protocol. Results from the prototype model indicate that the DRMP will comfortably meet the throughput requirements of the protocols being considered even when running at a moderate 200 MHz operating frequency and processing three protocol data streams at 20 Mbps concurrently.
6.3.3
Cost
The DRMP, if it is to be commercialized, will involve the complete design, synthesis and fabrication of a SoC, and hence the cost will be in the order of millions of dollars. It is however targeting a mass-market of consumer hand-held devices which includes mobile phones, smart phones, PDAs and laptops etc. If the DRMP is used by a fraction of device manufacturers in this market for implementing the MAC layer on their devices, one is easily looking at a figure of millions of chips per year. If the DRMP is used by even one mainstream wireless consumer device manufacturer, the economies of scale would bring the price tag to an acceptable value.
6.3.4
Programmability and Extensibility
It is important to note that DRMP is planned to be configurable at two distinct levels. One is the dynamic, on-the-fly reconfiguration for concurrent multi-mode operation on a device. This aspect of DRMP’s configuration has been the focus of this research, and it is at this level that the current results are very significant. The other level of configuration is the DRMP’s ability to evolve or change functionality over time to incorporate other protocol MAC functionalities in the same hardware IP. This is the future-proofing aspect of this architecture. Further research needs to be done to elevate the DRMP from a 3-MAC-protocol specific architecture to a more general purpose MAC
processor, as discussed in section 4.3.
In terms of the DRMP’s programmability, the current model meets an im- portant requirement of a flexible, future-proof device. Among other things, to make an architecture flexible and future-proof, it needs to have high-level programmability. In context of the MAC layer, the designers need to meet very strict time-to-market constraints in the fast evolving world of wireless standards. That the DRMP is domain-limited results in a very simple API for it. The functional units in the DRMP, in the prototype at least, are flex- ible but function-oriented; i.e. the hardware elements are closely matched
to the intended functionality. Configuring them does not require a general- purpose programming paradigm like RTL design in an HDL. The way the RFUs have been partitioned, it is expected that in most cases, all it would take to configure an RFU to make it work with a new protocol would be the loading of some parameters. In the prototype, in which three protocols are expected to be implemented, a simple function call is all that is required for an microprocessor to access the resources offered by the flexible hard- ware co-processor. Any reconfiguration required is done automatically by the hardware co-processor. No other programming of hardware is needed. It should be noted that the DRMP’s prototype is designed to be extensible by third-party system and hardware designers. The reconfigurable functional units (RFUs) in the DRMP, which do all the MAC operations partitioned to hardware, have a well-defined interface. They are not homogeneous, but they are clearly categorized into a number of classes, and their hence their interface for carrying out a function as well as reconfiguration is well-defined. It will thus be relatively straightforward for a third-party to extend the DRMP by designing their own RFUs and integrating them into the Hardware Co- Processor in the DRMP.