1. Purpose and scope
The reference architecture is the part of every derivative's architecture that the derivative does not design. It fixes the common processor, memory and interconnect structure, the way subsystems attach to it, the interfaces between hardware and software, the security foundation and the debug and trace facilities. Around that fixed core it defines the variation points: what a derivative may size, add, remove or choose, and the rules it must follow so that the platform's IP, software, tools and conformance tests still work on it.
Getting the variation points right is the hardest part of the stage. Too few, and later products need deviations that break the platform's promise of reuse. Too many, and every option has to be verified, modelled, supported in software and tested for conformance across the platform's whole life. The commonality and variability analysis started in Platform Strategy & Definition is finished here, with each variation point tied to the products that need it and to its cost.
In scope: the reference architecture specification, the final commonality and variability analysis, the platform interface specifications, the software platform architecture, the boot and firmware architecture, the platform threat model and security architecture, the performance and power model used to check the architecture, the platform verification plan in first form, the tools and build infrastructure plan, the first platform baseline definition and the change control the architecture is placed under. Out of scope: the dated roadmap, the lead product choice and IP sourcing, which follow in Roadmap & Derivative Planning against this architecture, and the virtual platform itself, the IP design and the software implementation, which follow once the roadmap commits the platform.
12 more sections for registered members.