This page is devoted for design of WhiteRabbit switch in microTCA form
factor. We have many things to do, but the most important ones are
build a prototype of switch MCH card as soon as possible to start
collaborating on HDL design. It doesn't need to support fancy uTCA
management features (like IPMI), this stuff can be implemented later
build a "piggyback" uTCA AMC with SFP module connected directly to
the backplane (to allow for MCH tests without building AMC card)
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.
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
product for this phase is a "Functional Specification" document posted
in the design wiki page by the Board Designer (BD).
Discussed during 2nd WR workshop at CERN. Now I'm pretty sure that
everybody knows what we need :). See minutes at indico
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.
3 Functional spec publication.done
Document is published and appropriate approvals are requested from the
Functional spec is available in SVN repository, although due to recent
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
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
functional spec. This includes all the information the device driver
developer will need to write the driver, including a detailed memory map
and sequence or state machine diagrams for sequential actions. Of
course, a very tight collaboration with the developer of the driver is
needed during the preparation of this document. Another important aspect
as this stage is design for testability. How the HW will be tested
should be described in this document.
Tech spec is being written along with schematics. Current version is
available in SVN repo
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
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)
6 Technical spec publication.
The document is published and appropriate approvals are requested from
the key clients.
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.
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
There was one SCH review at CERN about at 2009/03/17. Also I've reviewed
the project several times with Greg. Minutes and comments are in
link Since I haven't received any
feedback from mailing list, I assume everybody is OK with the mainboard?
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
More info PCBDesign
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.
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.
12 Test program.
The BD writes a test program using Nodal(no way, man, at least
for WR switch - TW) or its future replacement in order to test 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
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.
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.