During the early stages of investigation, the DRMP was envisaged as a Plat- form Architecture, with an abstract base architecture that is derived by de- signers into a real design as dictated by their own specific requirements. Later research then focused on a three-protocol specific architecture and forms the primary subject for this thesis. However, the vision for a platform architec- ture was revisited later and it is discussed briefly in this section. Further investigation in this area can make the DRMP a truly commercial and en- during platform architecture.
4.3.1
Platform-Based Design
The Platform-Based Design (PBD) approach to SoC design allows the de- signers to start with a pre-designed and verified SoC platform that has been designed for a specific type of application. The Virtual Socket Interface Al-
liance (VSIA)1 describes a platform as [93]:
1The VSIA became defunct in 2008, and has been superseded by the Open Core Pro-
“A platform comprises an integrated and managed set of com- mon features upon which a set of products of product family can be built. In the SoC context, it is a library of Virtual Compo- nents (VCs) and an architectural framework consisting of a set of integrated and prequalified software and hardware VCs, models, Electronic design automation (EDA) and software tools, libraries and methodology to support rapid product development through architectural exploration, integration and verification.”
and a platform-based design as:
“Platform-based design is an integration-oriented design ap- proach emphasizing systematic reuse, for developing complex prod- ucts based upon platforms and compatible hardware and software VCs, intended to reduce development risks, costs, and time-to- market.”
A platform design can be technology-driven, architecture-driven or applica- tion-driven. A platform’s target application spectrum can be quite broad or quite narrow, depending on the requirements of the application domain. A platform has a Foundation Block along with a library of pre-verified Virtual Components, and a derivative design can be designed in view of the specific
requirements. Fig. 4.5 shows the typical route for creating such a derivative
design. Interested readers are referred to [83, 78, 22] for more discussion on
platform-based design methodology.
4.3.2
Evolving DRMP into a Platform Architecture
There are three main reasons for proposing that the DRMP be evolved into a platform architecture. They are interdependent and are elaborated as follows:
1. While investigating the three protocol MACs for deriving a suitable set of RFUs, it was observed that there is some functionality in the MAC
New VC VC Authoring Foundation Block Design Derivative Design Platform Design Methodology Derivative Design Methodology
Staged Level Platform Level Derivative Chip Sub-block requests Optimised Sub-block Peripheral Block Authored Sub-block Foundation Block, Peripheral Block VC Library VC = Virtual Component
Figure 4.5: Flow of Hardware Design in Platform-Based Design Methodology
[90]
protocols that requires hardware acceleration, yet is completely unique to each protocol. It was mostly control-logic dominated, like ARQ and ACK generation that fell into this category. This presented a problem because the RFUs were meant to be function-specific, reconfigurable or parameterizable to accommodate small variations from one protocol to another. Hence, to implement hardware accelerator functions that were unique to each protocol, it was decided that one of two approaches could be taken:
One could include a certain area of FPGA-logic in the hardware co- processor and these could be programmed by a hardware designer at
design-time. The other option was that the designer could include
fixed-logic RFUs for the specific protocols in question at design time. Both these approaches fit in quite well with a platform-based design
approach, where the designer would take the foundation-block (the DRMP), and either add FPGA-logic and program it, or add fixed-logic RFUs. These add-on IPs could be custom-built, or could be taken from a library of Virtual Components that have been verified to work with the DRMP.
2. If we look at the two options considered in point 1, the first option of
including FPGA-type general-purpose reconfigurable logic makes the device more future-proof but less power-efficient. The other option of including specialized RFUs for a certain set of protocols will result in a more rigid device that is also more power-efficient. Each designer using the DRMP IP will have his or her own constraints for a specific application, and will be designing to hit a certain trade-off between flexibility and power-efficiency. A platform-based approach to using the DRMP thus leaves the designer the flexibility to choose the more flexible or the more power-efficient functional-units, thus enable hitting the sweet spot where the balance of flexibility and power-efficiency is optimal for the specific application intended.
3. While the prototype model has been investigated in view of three pro- tocols only, the DRMP design effort always had as an objective the design of an almost universal MAC processor that could be used for current and future MAC protocols. A platform architecture allows the flexibility to derive the DRMP for new protocol versions in very short time periods, since the designer will be starting from a pre-designed and verified platform. So, while some hardware design effort for intro- ducing new protocols is not completely eliminated, a platform-based design approach gives a reasonable middle-ground where derivative de- sign for a specific target device can be made with comparatively very little design effort.
The above three points resulted in a convincing case for the evolution of
the DRMP as platform architecture. Rabaey et al. [73] also propose the
communication design requirements in energy consumption, cost, size and flexibility, with a short time-to-market. It could follow a design approach
as presented in figure 4.5. The VC library could contain pre-designed and
verified RFUs that designer could choose make an optimal derivative design for their specific requirements. Even the extended-ISA feature of the CPU could be customized for each derivation, if required. The platform IP could be accompanied by a software development environment and a prototyping tool to further reduce the design effort. A platform-based design thus fits in very nicely with an architecture like the DRMP, and if the platform and accompanying tools are further investigated and matured, a very practical commercial IP can be realized.