This PR updates the PC and PL template instructions for SW and ARVM p… #557
Conversation
…rojects which have a sub-project structure
| @@ -113,7 +125,7 @@ | |||
| ### Feature Requirements | |||
| *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* | |||
| *For IP Cores or more complext projects, a user manual with requirements specification is produced at the PA gate, which may supersede this list of features* | |||
| *This template presents both PC and PL templates as well as instructions for use* | ||
|
|
||
|
|
||
| *In the **normal OpenHW project flow**:* |
There was a problem hiding this comment.
Not sure about the word normal in this context. Seems to imply that OpenHW also has an abnormal project flow.
| - *The PC as approved is retained in the programs repository* | ||
|
|
||
| - *The **PL***: | ||
| - *Is a separate document to the PC, which it updates and completes.* |
There was a problem hiding this comment.
What is the it in this sentence?
|
|
||
| - *The **PL***: | ||
| - *Is a separate document to the PC, which it updates and completes.* | ||
| - *The architecture, major features and project phases (the "what" - but not necessarily final level of detail)* |
There was a problem hiding this comment.
Maybe we can break this out to influence the authors of the PL to focus primarily on the features and project phases.
- The major features of the IP (the "what")
- Top-level project phases of the IP development
- High level architecture of the IP (not necessarily final level of detail)
There was a problem hiding this comment.
Following a talk with Duncan:
"If the project remains in the PC approved state for more than 6 months, the TWG chair will propose its cancellation and removal from the OpenHW dashboard, subject to TWG approval".
This is to avoid projects forever in the PC state.
| - *The **PL***: | ||
| - *Is a separate document to the PC, which it updates and completes.* | ||
| - *The architecture, major features and project phases (the "what" - but not necessarily final level of detail)* | ||
| - *The project team is identified* |
There was a problem hiding this comment.
Doubt this will be identified for a software project. You probably just have a lead, with the team identified at PA
| - *PC and PL are written as top-level projects addressing the target family.* | ||
| - *Any PC and PL sections intended for a particular target, e.g., preliminary feature list, are identified as target-specific* | ||
| - *The PA describes a "subproject" for a particular target. Each PA should contain the full feature list and project plan for a particular target* | ||
| - *There would normally be multiple PA sub-projects for top-level SW projects* |
There was a problem hiding this comment.
Can't help feeling an example would make this clear. E.g. PC/PL for the GNU Compiler Tool Chain and separate PAs for the GNU Compiler specifically for the CV32E40Pv1 and CV32E40Pv2 targets.
| *The flow for **OpenHW Advanced RISC-V Verification Methodology (ARVM)** subprojects:* | ||
| - *The ARVM PC is written as a top-level project addressing multiple ARVM subprojects* | ||
| - *The PL and PA describe an ARVM "subproject". The PA contains the full feature list and project plan for the subproject* | ||
| - *There will be multiple PL/PA subprojects for the ARVM top-level project* |
There was a problem hiding this comment.
This commentary is really helpful. Any chance of adding this to all the sections below?
| @@ -113,7 +125,7 @@ | |||
| ### Feature Requirements | |||
| *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* | |||
| *For IP Cores or more complext projects, a user manual with requirements specification is produced at the PA gate, which may supersede this list of features* | |||
There was a problem hiding this comment.
Just to check, I presume we are using US spelling throughout. "Supercede" would be British English spelling
Well if we had done this, we would now have no SW TG projects! I think we often need to keep PC there to indicate a project that we need, but which can progress no further until it is resourced. A regular review is fine, but I would expect many projects, at least on the software side to sit at PC for a long time. |
I'd prefer projects that we need, but can't launch, to be in a roadmap rather than sitting too long, maybe forever, at PC. |
|
@DBees One more comment. Your content is really useful commentary. You might like to provide it as Markdown comment, which won't then appeared in the rendered document. There is no explicit comment syntax in MarkDown, but the following blog suggests a number of convenient ways: https://www.jamestharpe.com/markdown-comments/ Personally I would go for the HTML style. There is one above this line - look at this as source code to see it :-) |
|
@DBees One more comment - you have assorted training whitespace. Just found this while I am using the template for the first time. |
…rojects which have a sub-project structure