This template is divided into two parts:
- The Project Concept (PC) required fields are shown in the first part.
- The additional Project Launch (PL) required and optional fields are shown in the second part.
Delete any sections not needed for your proposal
The normal proposal flow is:
- The PC proposal is prepared and presented to TWG. The PC proposal introduces the project and explains the market drivers and the "why"
- TWG grants PC gate with feedback, or rejects PC gate with feedback
- If PC granted, additional work is carried out to prepare the PL proposal.
- The PL proposal contains updates to the PC fields and adds additional fields. The PL proposal explains the "what" of the project.
- For software porting projects, the PL should contain the feature list
- For IP core or other complex projects, the PL should contain a high level feature list (the user manual with feature specification is developed for the Plan Approved gate).
Part 1, PC fields: The PC proposal introduces the project and explains the market drivers and the "why"
Part 2, PL fields: The PL proposal explains the "what". Some of it can be updated directly from the PC proposal
Components are major project components or groups of features.
- A project may have, for example, 1-10 components.
- Components detail the "The what" at high level, not detailed level
- Components don't consider timeline.
- For example
- Component 1 "Compiler changes for standard instructions."
- Component 2 "Compiler changes for custom instructions"
- Component 3 "Updates to compiler tools".
High level view of timeline, for example timeframe for each component
What is the impact of doing/not doing this project on the OpenHW ecosystem. Why is OpenHW best suited to do this project
This is a list of technical artifacts produced by the project
Features are more granular than Components. For SW porting projects, this list serves as the detailed project reference for features For IP Cores or more complext projects, a user manual with requirements specification is produced at the PA gate, which may supercede this list of features
These are external factors on which the project depends, such as external standards ratification, external technology input, etc.
Which TG will be involved, such as SW, HW, Verification, etc.
This is a list of major resources/people required to implement the project and indication of whether the resources are available
Architecture (internal blocks and interconnections), and context (depiction of the the project content within its operational context), are both encouraged where appropriate to depict functionality to both subject matter experts and to non-experts
A full project plan is not required at PL. A preliminary plan, which can be for instance the schedule for completion of component or feature list, together with responsible resource, should be provided. Full details should be provided at PA gate.
A list of known risks, for example external dependencies, and any mitigation strategy