Design review

Home Electronics E-mail Notes Meetings Subsystems Search

Review planning

Vertex Architecture review: June 13 2002.
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Roland Horisberger, Peter Lichard, Leo Wiggers, Sandro Marchioro,
Richard Jacobsson, Ulrich Straumann
Report
  Design review Production readiness
SCTA March 14 -15, 2000. 
Documentation is available on the web
.
Reviewers: Francis Anghinolfi, Paul Aspell, Jorgen Christiansen,  Martin Feuerstack, Thomas Toifl

Minor incremental review 8 Nov. 2000.
Reviewers: Francis Anghinolfi, Paul Aspell, Jorgen Christiansen,  Jan Kaplon

Beetle chip chosen as baseline solution
Beetle Jan. 22 2003. 
Presentations are available on the web.
Reviewers: Jan Buytaert, Jorgen Christiansen, Jan Kaplon, Christian Bauer, Nigel Smale, Helmuth Spieler.
Report

An informal  BETTLE review was made June 25-26 2001 in Heidelberg with representatives from the sub-detectors using the front-end chip.

April 20, 2004, Heidelberg.
Presentations are available on the web

Reviewers:
Michael Schmelling (Chair)
Christian Bauer, Achim Vollhardt (Silicon Tracker)
Jan Buytaert, Massimiliano Ferro-Luzzi (VELO)
Martin van Beuzekom, Eddy Jans (VETO)
Jorgen Christiansen (LHCb management)
PRR report
Hybrid   January 16, 2006, CERN
Presentations are available on the web

Reviewers: Jorgen Christiansen, Achim Vollhardt,
Daniel Charlet.
PRR report
Repeater card  
LV card  
TTC and ECS control card  
Digitizer card  
     
Pile-up Veto Architecture review: (done as part of L0 trigger review, see below)
Beetle Jan. 22 2003. 
Presentations are available on the web.
Reviewers: Jan Buytaert, Jorgen Christiansen, Jan Kaplon, Christian Bauer, Nigel Smale, Helmuth Spieler.
Report

An informal  BETTLE review was made June 25-26 2001 in Heidelberg with representatives from the sub-detectors using the front-end chip.

April 20, 2004, Heidelberg.
Presentations are available on the web

Reviewers:
Michael Schmelling (Chair)
Christian Bauer, Achim Vollhardt (Silicon Tracker)
Jan Buytaert, Massimiliano Ferro-Luzzi (VELO)
Martin van Beuzekom, Eddy Jans (VETO)
Jorgen Christiansen (LHCb management)
PRR report
Hybrid   January 17, 2006, CERN
Presentations are available on the web

Reviewers: Jorgen Christiansen, Jan Buytaert,
Rui De Oliveira.
PRR report.
Optical link card   Planned CERN December 6 2006
Presentations will be available on the web.
Reviewers: Jorgen Christiansen, Renaud LeGac, Jean-Pierre Cachemiche, Guido Haefeli, Jan Buytaert.
Processing and output card  
     
IT+TT Architecture review: Feb. 17 2004
Presentations available on the web.

Reviewers: Jorgen Christiansen, Geoff Hall, Francis Anghinolfi, Paulo Moreira, Beat Jost, Leo Wiggers, Thomas Ruff, Vincent Bobillier
Report
  Design review Production readiness
Beetle Jan. 22 2003. 
Presentations are available on the web.
Reviewers: Jan Buytaert, Jorgen Christiansen, Jan Kaplon, Christian Bauer, Nigel Smale, Helmuth Spieler.
Report

An informal  BETTLE review was made June 25-26 2001 in Heidelberg with representatives from the sub-detectors using the front-end chip.

April 20, 2004, Heidelberg.
Presentations are available on the web

Reviewers:
Michael Schmelling (Chair)
Christian Bauer, Achim Vollhardt (Silicon Tracker)
Jan Buytaert, Massimiliano Ferro-Luzzi (VELO)
Martin van Beuzekom, Eddy Jans (VETO)
Jorgen Christiansen (LHCb management)
PRR report
TT Hybrid   September 2, 2005, CERN
Presentations are available on the web

Reviewers: Jorgen Christiansen, Jan Buytaert, Guido Haefeli, Paulo Moreira, Martin Van Beuzekom
PRR report
IT hybrid  
Digitizer board  
Service box controller   November 28, 2006, CERN
Presentations are available on the web

Reviewers: Jorgen Christiansen, Guido Haefeli,
Daniel Charlet, Achim Vollhardt
     
OT Architecture review:
April 22
2004 in NIKHEF
Presentations are available on the web.
Reviewers:
Jorgen Christiansen, Peter Lichard,
Werner Riegler, Gary Drake, Bernhard Schwingenheuer,
Adriano Lai
Report
  Design review Production readiness
OTIS June 5 2003.
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Peter Fischer,
Robert Szczygiel.
Report

An informal  OTIS review was made June 25-26 2001 in Heidelberg with representatives from the sub-detectors using the front-end chip.

April 27 2005 in NIKHEF
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Adriano Lai, Martin Van Beuzekom
PRR report
HV card  
Analog front-end card  
Otis card  
Link transmitter card  
Service card  
     
RICH Architecture review: March 24 2004
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Richard Jacobsson,
Dominique Breton, Paulo Moreira, Guido Haefeli, Vincent Bobillier
Report
  Design review Production readiness
Pixel chip June 5, 2001. 
Presentations are available on the web
.
Reviewers: Jorgen Christiansen, Paulo Moreira, Sandro Marchioro (part time), John Bibby, Fabio Formenti, Luciano Musa, Giorgio Stefanini
Report
November 24, 2003
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Francis Anghinolfi,
Walaer Snoeys, Jan Buytaert, Ulrich Trunk
PRR report
HPD socket card   June 16 2005 at CERN
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Achim Vollhardt, Luciano Musa, Alexander Kluge
PRR report
HV card  
L0 card  
LV card  
RICH L1 module   September 1 2006, CERN
Presentations are available on the web.

Reviewers: Jorgen Christiansen, Guido Haefeli, Niko Neufeld.
PRR report
HV   November 3 2005 at CERN
Presentations are available on the web
Reviewers:
J.Baechler, J.Christiansen, C.Joram
PRR report
     
Calorimeter Architecture review: 29 - 30 March 2001. 
Presentations are available on the web
.
Reviewers: Jorgen Christiansen, Veljko Radeka, Hans Dijkstra,
Beat Jost, Burkhard schmidt, Fabio Formenti, John Elias.
Report
  Design review Production readiness
Ecal/Hcal front-end chip   Orsay November 29, 2001.
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Christophe de la Taille, Eric Delagne.
PRR report
Preshower front-end chip Orsay November 29, 2001.
Presentations are available on the web.
Reviewers: Jorgen Christiansen,
Christophe de la Taille, Eric Delagne.
Report
CERN March 25, 2004
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Werner Riegler,
Paul Aspell, Federico Faccio, Pierre Jarron
PRR report
SPD front-end chip  
Ecal/Hcal front-end card CERN Feb. 16 - 17 2005.
Presentations are available on the web: day1, day2
Reviewers: Jorgen Christiansen, Renaud Le Gac,
Richard Jacobsson, Guido Haefeli, Roberto Campagnolo
Report
March 31, 2006
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Guido Haefeli,
Richard Jacobsson, Renaud LeGac,
Roberto Campagnolo
PRR report
 
CROC card Planned December 19 2006
Preshower very front-end card Made in global design review
SPD very front-end card Made in global design review
SPD control card Planned December 19 2006
Preshower/SPD front-end card June 13 2006, CERN
Presentations are available on the web.

Reviewers: Jorgen Christiansen, Guido Haefeli, Renaud LeGac, Roberto Campagnolo, Dominique Breton, Cyril Drancourt
PRR report
     
Optical mezzanines   CERN November 8 2005
Presentations are available on the web.
Reviewers:  Jorgen Christiansen, Xavier Vilasis Cardona,
Paulo Moreira, Renaud LeGac, Jean-Pierre Cachemiche
Olivier Duarte, Dominique Breton, Cyil Drancourt
PRR report
Trigger validation card   June 13 2006, CERN
Presentations are available on the web.

Reviewers: Jorgen Christiansen, Guido Haefeli, Renaud LeGac, Roberto Campagnolo, Dominique Breton, Remi Cornat, Pascal Perret
PRR report
Trigger selection card   June 13 2006, CERN
Presentations are available on the web.

Reviewers: Jorgen Christiansen, Guido Haefeli, Renaud LeGac, Roberto Campagnolo, Dominique Breton, Remi Cornat, Pascal Perret
PRR report
     
Muon Architecture review: March 27 2003
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Richard Jacobsson, Beat Jost, Renauld Legac, Guido Haefeli, Ulrich Uwer,
Robert Richter, Carlos Willmott 
Report

Muon timing review: Requested by the TB, a specific review of the timing alignment needs for the muon detector
was made at CERN July 5 2001
Presentations are available on the web
.
Reviewers: Jorgen Christiansen, Jacques Lefrancois, Hans Dijkstra, Philippe Charpentier, Ulrich Strauman, Luciano Musa

  Design review Production readiness
Carioca front-end chip CERN February 20, 2003.  
Presentations are available on the web
 
Reviewers: Jorgen Christiansen, John Oliver, Mitch Newcomer, Francis Anghinolfi, Adriano Lai, Ken Wyllie, Walter Snoeys
Report
Combined PRR
CERN June 18, 2004
Presentations are available on the web
Reviewers: Jorgen Christiansen, Francis
Anghinolfi, Federico Faccio, Luciano Musa
PRR report
Dialog front-end chip  
Sync TDC  
Front-end card   July 15 2005 at Roma - La Sapienza
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Werner Riegler, Jean-Pierre Cachemiche, Renaud LeGac
PRR report
IB board  
ODE board  
Control board  
     
Trigger processing card   March 17, 2006, CPPM, Marseille.
Presentations are available on the web.

Reviewers: Jorgen Christiansen, Guido Haefeli,
Adriano Lai, Paolo Ciambrone
PRR report
Trigger controller card  
     
TFC A general review of the TFC system was made at CERN January 21, 2004
Presentations are available on the web

Report
Readout supervisor A review of the Readout supervisor specifications have been made April 3, 2001 . August 26, 2005, CERN
Presentations are available on the web
Reviewers:
Jorgen Christiansen, Achim Vollhardt, Jean-Pierre Cachemiche, Guido Haefeli, Ken Wyllie, Philippe Farthouat.
PRR report
TFC switch A Review of the TFC switch specifications have been made November 7, 2000. A PRR was made as a part of a general TFC review
January 21, 2004
Presentations are available on the web
Throttle switch A Review of the throttle switch specifications have been made November 7, 2000.  
Throttle OR    
DAQ Review of combined DAQ/L1 trigger system 29 April 2003.
Presentations are available on the web
Reviewers: Hans Dijkstra, Olivier Callot, Jorgen Christiansen, Sergio Cittolin, Pere Mato, Jean Michel Jouanigot,
Pierre Vande Vyvre
Report
TELL1   July 26 2005 at EPFL
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Guido Haefeli, Dirk Wiedner,  Manfred Muecke, Nicolas Dumont, Walter Rinaldi, Jean-Pierre Cachemiche, Niko Neufeld. Richard Jacobsson.
PRR report
GBE  
ORC  
     
ECS  
Credit-card PC Glue card   CERN June 17, 2004
Presentations are available on the web
Reviewers: Beat Jost, Niko Neufeld, Clara Gaspar,
Guido Haefeli, Jorgen Christiansen
SPECS SPECS Slave and use in sub-detectors:
CERN June 21, 2004
Presentations are available on the web.
Reviewers: Jorgen Christiansen, Ioana Videau, Clara Gaspar, Ken Wyllie, Albert Zwart, Daniel Esperante, Lars Eklund, Dominique Breton,
Daniel Charlet.
Report
Orsay February 22, 2006.
Presentations are available on the web

Reviewers: Jorgen Christiansen, Clara Gaspar,
Lars Eklund, Daniel Esperante,
Tom Sluijk, Remi Cornat,
Xavier Vilasis Cardona, Dominique Breton,
Anatoli Konoplyannikov, Ken Wyllie.
PRR report
CAN ELMB    
     
L0 trigger Architecture review: July 4 2002. Presentations are available on the web.
Reviewers: Jorgen Christiansen, Hans Dijkstra, Jacques Lefrancois, Burkhard Schmidt, Thomas Ruf, Richard Jacobsson,
Philippe Charpentier, Philippe Farthouat, Joao Varela
Report
L0-DU   July 20, 2006, CERN
Presentations are available on the web
Reviewers: Jorgen Christiansen, Guido Haefeli, Renaud LeGac, Richard Jacobsson
PRR report
     
L1 trigger Review of combined DAQ/L1 trigger system 29 April 2003 .
Presentations are available on the web
Reviewers: Hans Dijkstra, Olivier Callot, Jorgen Christiansen, Sergio Cittolin, Pere Mato, Jean Michel Jouanigot,
Pierre Vande Vyvre
Report

Architecture review: June 14 2002. Presentations are available on the web.
Reviewers: Hans Dijkstra, Jorgen Christiansen, Thomas Ruf, Olivier Callot, Beat Jost, Leo Wiggers, Andre Bogaerts,  Nick Ellis
Report

     
EMC Review/workshop on grounding, shielding and power supply distribution.
May 26, 2005, CERN
Reviewers: Jorgen Christiansen,
Georges Blanchot (ATLAS)
Fritz Szoncso (TIS)
Fernando Arteche (CMS)
PLUS internal representatives from each sub-detector
Presentations are available on the web
Report
 

 

Design reviews

Design reviews are an extremely useful scheme to ensure sufficient quality of a given design. It consists of inviting a selected set of external people to analyze and verify that a given implementation seems to be capable of fulfilling its required functions. A design review should not be considered a judgment of a  given development, but should mainly be seen as a help to the designers to catch problems which may have been overlooked. Especially in HEP experiments, where large and complicated electronics systems are developed by a large community of people, the design review process is very important to insure that a fully working system can be made from the different bits and pieces.

Design reviews can be performed at different levels during a development project. The two major milestones in a project is normally considered to be its specification and finally its implementation. During the development phase of a project it is though normal to have several informal reviews within the project itself. In HEP experiments the TDR (Technical Design Report) plays to a large extent the role of a specification and feasibility review.  To insure that the final implementations will actually work in the system the implementation reviews are equally important.

The implementation design review for front-end electronics must be performed at the component ( ASICs), module ( PCB boards) and sub-system level before a final implementation can be considered ready for production (firmware is a bit special in this sense). A design review panel should contain a selected set of experts (3 - 5), selected by the corresponding LHCb coordinator, of which some can (should) come from outside the collaboration itself (e.g. experts from similar systems of other HEP experiments). A design review must be properly prepared to enable the reviewers to have access to sufficient documentation to understand important details of the implementation. The design review itself will consist of a single day with presentations given by the designers followed by discussions with the reviewers. The design reviewers are finally expected to make a (short) written summary including recommended changes before a final submission. The final review report will be given to the LHCb management to enable it to monitor the status of the electronics subsystems.

A design review should be performed at a time where most of the design has been finalized and all critical blocks are considered to work satisfactory. Enough time ( few months) must though still be available after the review to implement necessary changes identified during the review. Specification and general architecture reviews should be performed when a clear definition is available and before design work on the final implementation of the different components has started.

Within LHCb three levels of reviews are defined for the front-end electronics:

Architecture review

This is a review of the general architecture of a front-end electronics system with its components and the definition of their specifications. The specific requirements of the system must be shown to be understood ( e.g. detector signal, analog front-end, noise, calibration, synchronization, radiation, occupancies , , ) and appropriate solutions have been found. It must be demonstrated that the sub-system can be fully integrated into the overall LHCb front-end system and that it is compatible with existing specifications for such sub-systems. Sufficient emphasis on reliability and testability of the sub-system and its main components must also be demonstrated.

The architecture and specifications of the front-end electronics of a sub-detector must have been defined, at the latest, when the Technical Design Report (TDR) is finalized. The TDR itself and its supporting documents is therefore a natural basis to perform a general review of the electronics systems in a given sub-detector.

Design review

Prototypes of vital components of a subsystem should be reviewed by a set of selected specialists before being submitted for prototype production. This is especially important for ASIC (Application Specific Integrated Circuits) components as any subsequent design change has significant cost and time penalties. It must be demonstrated that the required functions in the component is well specified and in accordance with the specifications of the sub-system. The design must be presented in detail (e.g. schematics, block diagrams, behavioral models) and simulations of the performance of the circuit must be shown to give confidence that the design can conform with its specifications with realistic assumptions on its environment ( process parameters, temperature, supply voltage variations, and radiation effects). Testability issues must be addressed to demonstrate that sufficient features are available to perform detailed design verification testing and production testing of the component itself and the corresponding module and sub-system.

Production Readiness Review (PRR)

This is the final review of a sub-system or a vital component ( ASIC or board) before it can be considered ready for final production. Test results from prototypes must be presented to demonstrate that the implementation is fulfilling its required functionality within sufficient safety margins. The circuit must have been qualified to have acceptable reliability within the final environment ( e.g. radiation effects). The estimated yield and production test procedures must be shown to be compatible with cost and quality requirements.
When a design enters final production, complete design and manufacturing information must be stored in the LHCb EDMS database (Schematics, Layouts, Firmware, test results, user manual, etc.).

Points to take into account during reviews

  • Specifications

Are specifications complete and sufficiently clear.
Have sufficient margins for uncertainties been included in specifications. ( Noise, temperature, hit rates, radiation, etc.)
Have specifications been agreed upon in a well defined fashion.
Does specifications comply with general LHCb front-end, trigger and DAQ architecture.
Has sufficient flexibility been included for unknowns ( hits rates, noise, etc.) and potential future upgrades.
Are interfaces with other parts of the system well defined and agreed upon.
Does design comply with all specifications.

  • System integration

Has the integration into the final system been sufficiently taken into account (mechanical, electrical, radiation).
Has the device been tested on final modules.

On-site repair scenario.
Debugging and system test features.
Is sufficient on-line error monitoring implemented in design (buffer overflows, synchronization, SEU, etc.).
Is design compliant with general LHCb grounding rules.
Have EMC problems been sufficiently taken into account. (sensitive to and generation of Electromagnetic noise)
Are manual adjustments required.
Are large amounts of setup parameters required.
Does all setup parameters have read-back.
What kind of interface to the general ECS system is used
Are calibration/adjustment procedures well defined.
Has synchronization with rest of system been sufficiently considered.
Power requirements and its related cooling.
Does chips have high power modes that may exceed cooling capabilities.
Has power supply requirements been sufficiently analyzed ( sensitivity to noise in power supply, location of power supplies, non-standard voltages, sensitivity to over-voltage, etc.).
Safety aspects (fire, high voltage, gasses, halogen free cables, Halogen free PCBs, etc.).

  • Planning

Is current time schedule realistic.
Does schedule fit general project planning.

  • Cost

  • Is design critically dependent on single supplier.
    Expected Yield.
    Does production costs fit general budget of project.

  • Design procedure

Is it clearly identified who is responsible for the different parts of the design.
What kind of design tools have been used.

  • Design

Is architecture of design well planned.
Has a clear design hierarchy been defined.
Identification of major difficult parts of design.
Is design relying on low jitter clock or clock with strict requirements to duty-cycle.
Are multiple clocks used and how are clock domains interfaced to each other.
Is asynchronous logic used.
Have sensitivity to parameter matching in sensitive analog circuits been analyzed.
Have interface been sufficiently verified ( I/O signal levels, I/O loading, Drive currents, Protocol, Timing).
Reset and initialization procedure ( Async./sync. reset, power on reset, possible hazards before initialization).

Special for IC design:
Has well defined process, temperature and power supply corner parameters been defined for simulations.
Has design passed Design Rule Checking (DRC) with a well defined set of design rules.
Has electromigration rules been verified for power distribution and heavily loaded nets (clock)
Has Layout Versus Schematic (LVS) verification been performed.
Has timing verification tools been used to verify worst case timing.
Has design timing been verified with parasitics extraction.
Has RC delays been included in timing verification.
Has possible radiation effects been taken into account in process parameters.
Has chosen technology been qualified for radiation effects ( total dose, Neutrons, SEL, SEU)
Has IC packaging been sufficiently analyzed ( Pad layout, Pad spacing, Bonding length and angle, Package inductance, Ground bounce, Power supply, cooling, etc.).
Has design for testability been taken into account ( Fault coverage, Scan path, BIST, etc.). 
Is expected availability of technology (normally ~5 years) sufficiently long to ensure production.
What has been done to minimize crosstalk in mixed signal designs.

  • Verification

Has design verification tools been used and have they passed all checks ( Design Rule Checking, Layout Versus Schematics, Electrical Rule Check, etc.)
Is design sufficiently robust against parameter variations (IC process, temperature, supply voltage)|
Has design been sufficiently simulated with different parameter sets ( Spice, Verilog, VHDL, etc.)
Has compliance with design rules been checked sufficiently.
Has timing been properly verified with sufficient margins.
Has timing been verified with extracted parasitics.

  • Testing

Is design sufficiently testable during verification and production (should special test features like JTAG, internal test pulse generation, BIST, etc. be added).
Have well defined test procedures been specified.
Are sufficient personnel and equipment available for effective design verification and production testing.
What kind of test procedures will be used to insure radiation hardness.

  • Reliability

System effects of component failures ( is redundancy required ?).
Is design sufficiently robust against radiation effects (Total dose, Neutrons, Single event upsets, Single event Latch-up).
Protection against ESD.
Identification of weak components ( connectors, power devices, etc.)
Has temperature cycling test been made to qualify board quality.
How will quality be verified of final production

  • Documentation

Is sufficient and clear documentation available.
Is the design database sufficiently well organized to make future changes and enable it to be used as technical documentation.
Insurance of future access to design database ( Phased out commercial design tools during construction and running period = 15 years).
All final designs must be archived centrally via EDMS.

  • Prototyping

Have critical parts of the circuit already been prototyped
Has previous prototypes been sufficiently tested to find all potential bugs and have their cause been well determined. (beam tests and special test benches)
What changes has been made in parts which have been prototyped.

  • Production

Is Test and repair scenario realistic (especially for hybrids: Known good die, removal of failing chips).
Definition and implementation of production test.
Use of JTAG boundary scan.

Is design sufficiently robust (handling during production, ESD protection).
Will burn-in be required.

  • Maintenance

Is it well defined who takes care of future maintenance.

This page was last modified by JC on 29 April, 2014 . This page has been accessed Hit Counter number of times.