More info on the switch
- Overall architecture
-
A summary description of the MCH board
- MCH Main board.
- MCH timing board
- MCH mini backplane.
WhiteRabbit switch MCH/AMC cards
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 listed below:
- 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)
Workflow:
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 site.
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 key clients.
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 other specs.
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
link
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...
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.
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.
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
BD.
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
BD.
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
wiki.
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.
-- Main.TomaszWlostowski - 12 Feb 2009
-- Main.JavierSerrano - 11 Feb 2009