|
|
|
# More info on the switch
|
|
|
|
|
|
|
|
- [Overall architecture](Overall)
|
|
|
|
- [A summary description of the MCH board](SwitchMCH)
|
|
|
|
- [MCH Main board](MCH-MAIN-board).
|
|
|
|
- [Main FPGA](MCHMainFPGA).
|
|
|
|
- [Main CPU](MCHMainCPU).
|
|
|
|
- [MCH timing board](MCH-CLKB-board)
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
- **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
|
|
|
|
\[\[http://indico.cern.ch/conferenceDisplay.py?confId=43741\]\[indico
|
|
|
|
site\]\]
|
|
|
|
|
|
|
|
1 **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**
|
|
|
|
|
|
|
|
*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.
|
|
|
|
|
|
|
|
3 **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
|
|
|
|
\[\[https://www.ohwr.org/svn/WhiteRabbit/trunk/documentation/specifications/technical_spec/switch_technical_spec.pdf\]\[here\]\],
|
|
|
|
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**
|
|
|
|
|
|
|
|
*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.**
|
|
|
|
|
|
|
|
*The document is published and appropriate approvals are requested from
|
|
|
|
the key clients.*
|
|
|
|
|
|
|
|
6 **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**
|
|
|
|
|
|
|
|
*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
|
|
|
|
\[\[https://www.ohwr.org/svn/WhiteRabbit/trunk/circuit_board/CHANGELOG.txt\]\[here\]\].
|
|
|
|
Since I haven't received any feedback from mailing list, I assume
|
|
|
|
everybody is OK with the mainboard?
|
|
|
|
|
|
|
|
8 **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
|
|
|
|
\[\[https://www.ohwr.org/twiki/bin/view/OHR/WhiteRabbit/PCBDesign\]\[here\]\]
|
|
|
|
|
|
|
|
9 **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.**
|
|
|
|
|
|
|
|
*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.**
|
|
|
|
|
|
|
|
*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
|
|
|
|
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.**
|
|
|
|
|
|
|
|
*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.**
|
|
|
|
|
|
|
|
*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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Files
|
|
|
|
* [wrdev.tar.gz](/uploads/ec19e85c2ce3e26569c645770e9fd46e/wrdev.tar.gz)
|
|
|
|
* [wrdev.tar.gz](/uploads/dd5baf3764c2d4b3affbd0a5c7c484c0/wrdev.tar.gz)
|
|
|
|
* [sdimage.gz](/uploads/1e46a8ac9af30d23193cefe8e12ab575/sdimage.gz) |
|
|
|
\ No newline at end of file |