The Minimum Platform Architecture is structured around required functionality over time. As such, the key elements of architecture and design (flows, interfaces, etc) are organized into a staged architecture, where each stage will have requirements and functionality that lead to specific uses. Stages build upon prior stages with extensibility to meet silicon, platform, or board requirements.
Early in a development cycle, engineering is focused on creating the platform and acquiring basic functionality. This can be pursued within simulation and emulation environments, or on real hardware. This often includes creating a new set of silicon and platform source code that handles the basic differences between the new target and prior solutions. Often this entails reuse of the prior generation silicon support and existing feature sets.
Later development engineering effort is focused on enabling the full range of functionality, supporting all deltas in the new platform - typically in the form of reference designs and lead products. Next, platform development is focused on scaling. This involves customer enabling and aligning products for time-to-market and silicon roadmaps. Finally, there is sustaining, maintenance, and derivatives activity. These are characterized by smaller changes to existing production-worthy solutions, repurposing them opportunistically.
Figure 1 shows the basic Minimum Platform Architecture. The enabling steps for a Minimum Platform solution should occur in the following order to add complexity over time, and only where it is necessary. This progression from minimum required to more full-featured permeates the design of the boot flow, modules implemented, and collection of components into firmware volumes.
Develop a board solution around the minimum platform. This involves
implementing the essential board information and initialization defined in
the Minimum Platform board API.
Add silicon initialization support. For many silicon vendors this
will be accomplished through the use of binary blobs with well-defined
interfaces. In any case, the silicon initialization invocation is performed
from the board code.
Add advanced features, which are typically implemented in the form of
source code designed to be generically plugged into a large number of diverse
Add product-specific features that are required for product initialization.
This support is not part of essential board organization or maintained as a
generic advanced feature. It is enabled in the advanced feature stage.
Figure 2 shows the same basic idea can be represented as a Venn diagram with three fundamental steps.
This architecture is reflected in these areas:
Source code in modules, packages, and resulting binary components
Execution in control, data, error, and debug flows
Functionality as solutions evolve from initial to complete
Scaling from silicon development to products