... | ... | @@ -25,7 +25,7 @@ Please note that workflow described below has been created for |
|
|
traditional designs done in CERN's BE-CO-HT section, like VME cards. In
|
|
|
case of WR switch there might be some slight differences.
|
|
|
|
|
|
- **Requirements gathering and documenting.** **done**
|
|
|
1 **Requirements gathering and documenting.** **done**
|
|
|
|
|
|
*This answers the question "What do we need?" It does not enter at all
|
|
|
into the details of how we intend to do it. It is a user view. The end
|
... | ... | @@ -37,13 +37,13 @@ everybody knows what we need :). See minutes at |
|
|
\[\[http://indico.cern.ch/conferenceDisplay.py?confId=43741\]\[indico
|
|
|
site\]\]
|
|
|
|
|
|
1 **Meeting about functional specs.** **done**
|
|
|
2 **Meeting about functional specs.** **done**
|
|
|
|
|
|
*The BD, Project Manager (PM) and others meet and we discuss the
|
|
|
document. The minutes of this meeting are posted in the design wiki page
|
|
|
by the BD.*
|
|
|
|
|
|
2 **Functional spec publication.** **done**
|
|
|
3 **Functional spec publication.** **done**
|
|
|
|
|
|
*Document is published and appropriate approvals are requested from the
|
|
|
key clients.*
|
... | ... | @@ -52,7 +52,7 @@ design decisions, it has to be greatly corrected and improved. It should |
|
|
be also converted to \!LaTeX to keep the same style/formatting as the
|
|
|
other specs.
|
|
|
|
|
|
3 **Technical specification.** **done, partially**
|
|
|
4 **Technical specification.** **done, partially**
|
|
|
|
|
|
*The BD writes a document stating how he will tackle the design problem,
|
|
|
i.e. how he intends to fulfill the requirements expressed in the
|
... | ... | @@ -70,26 +70,26 @@ but it's already a bit outdated due to changes in clocking system and |
|
|
choice of FPGAs and PHYs. Also \!TeX sources need to be cleaned up a
|
|
|
little bit...
|
|
|
|
|
|
4 **Meeting about technical specs.** **done**
|
|
|
5 **Meeting about technical specs.** **done**
|
|
|
|
|
|
*The BD, PM and others meet and we discuss the document. The minutes of
|
|
|
this meeting are posted in the design wiki page by the BD.*
|
|
|
There are some things which need to be explained better (e.g. the idea
|
|
|
of Digital DMTD phase detector)
|
|
|
|
|
|
5 **Technical spec publication.**
|
|
|
6 **Technical spec publication.**
|
|
|
|
|
|
*The document is published and appropriate approvals are requested from
|
|
|
the key clients.*
|
|
|
|
|
|
6 **Planning.**
|
|
|
7 **Planning.**
|
|
|
|
|
|
*The BD posts information on the wiki concerning the breakdown of the
|
|
|
design process in different milestones with the relevant actors clearly
|
|
|
visible. The BD must keep this information up to date throughout the
|
|
|
complete design process.*
|
|
|
|
|
|
7 **Schematics review.** **done, several times**
|
|
|
8 **Schematics review.** **done, several times**
|
|
|
|
|
|
*When schematics are ready, the BD organizes a meeting in the section to
|
|
|
review them. The results of the review are documented in the wiki by the
|
... | ... | @@ -100,7 +100,7 @@ the project several times with Greg. Minutes and comments are |
|
|
Since I haven't received any feedback from mailing list, I assume
|
|
|
everybody is OK with the mainboard?
|
|
|
|
|
|
8 **PCB review.**
|
|
|
9 **PCB review.**
|
|
|
|
|
|
*After layout is ready, the BD organizes a meeting in the section to
|
|
|
review it. The results of the review are documented in the wiki by the
|
... | ... | @@ -108,19 +108,19 @@ BD.* |
|
|
More info
|
|
|
\[\[https://www.ohwr.org/twiki/bin/view/OHR/WhiteRabbit/PCBDesign\]\[here\]\]
|
|
|
|
|
|
9 **HDL design.**
|
|
|
10 **HDL design.**
|
|
|
|
|
|
*For this phase, please consult the "HDL release procedure" and use
|
|
|
common sense to see what parts apply to a "first release". Use official
|
|
|
BE-CO-HT design guidelines throughout.*
|
|
|
|
|
|
10 **HDL review.**
|
|
|
11 **HDL review.**
|
|
|
|
|
|
*For cards with FPGAs, after HDL is ready, the BD organizes a meeting in
|
|
|
the section to review it. The results of the review are documented in
|
|
|
the wiki by the BD.*
|
|
|
|
|
|
11 **Test program.**
|
|
|
12 **Test program.**
|
|
|
|
|
|
*The BD writes a test program using <strike>Nodal</strike>(no way, man,
|
|
|
at least for WR switch - TW) or its future replacement in order to test
|
... | ... | @@ -128,14 +128,14 @@ his design. The program must be stored in a well-known repository, along |
|
|
with its user manual. A pointer to this repository is supplied in the
|
|
|
wiki.*
|
|
|
|
|
|
12 **Design report.**
|
|
|
13 **Design report.**
|
|
|
|
|
|
*The BD documents his design choices in this report. The intended
|
|
|
audience is another hypothetical designer that would inherit this design
|
|
|
(or the same designer 5 years after designing the hardware and
|
|
|
forgetting about it). This report must be posted in the wiki.*
|
|
|
|
|
|
13 **User manual.**
|
|
|
14 **User manual.**
|
|
|
|
|
|
*The BD documents the system for the user, including procedures to test
|
|
|
the board using the test program. This document is posted in the wiki.*
|
... | ... | |