1. Uli Schäfer JEM0 hardware history and status JEM - The next iteration : many questions, few answers test plans and time scale

2. Uli Schäfer the JEM0 saga end 2000JEM0 schematic capture and board layout 02.01.2001board designs to PCB manufacturer (ANDUS) 31.01.2001first PCB run failed 19.02.2001second PCB run 'successful' : 1 PCB produced, 3 broken tracks 20.02.2001some minor layout errors discovered, manually corrected. 06.03.2001PCB and components sent out for assembly (MAIR) 25.04.2001module received back with all Spartan-II chips rotated by 180° backplane connectors not very well aligned but probably ok. 27.04.2001module sent for re-work (populate with spare chips). message from manufacturer: another chip failed, send a spare chip 29.05.2001module received back with Virtex-E mounted incorrectly: Vcc short to GND. Possible reason: board too large, FR-4 boards tend to be mechanically instable at soldering temperature. 19.06.2001module back in Mainz. Visual inspection shows no obvious problems. Start electrical tests 20.06.2001JTAG chain doesn't work. Break chain to configure CPLDs. 26.06.2001start work on FPGA configuration via VME

3. Uli Schäfer considerations for Jem0.1 Are the problems with JEM0 related to board size ? We are using large and expensive high-density modules. Apparently the probability for failure of an individual chip is high. The probability for all chips correctly mounted in first try seems very low. Since re-balling seems unreliable we will require a high fraction of spare components. The assemblist seems to have no tools to perform connectivity tests. - How can we improve the turnaround time of test/rework/test cycles ? (Do we require an automated JTAG/BS test setup?, cost? see below) - How many rework cycles are required ? - How many rework cycles will be tolerated by boards/components ? Should we reduce the size of seviceable/replaceable parts? Since we rely on common modules we cannot go for 6U modules, though JEMs could easily fit in 6U format. But: We might be able to shrink module size by using daughter modules. Even the mother board size could be reduced by CAMAC-style slide-mounted PCBs. Virtex-2 will soon be available with 684 user-I/O in 1.28mm pitch. Will it make a difference? -- Whatever we do : it might drive up module cost ! --

4. Uli Schäfer module test and rework At present Mainz don't have an automatic B/S system. Only a small fraction of all devices on JEM0 are B/S-able --> Do we need to purchase a stand-alone test system ? Are Software / PC-based systems available ? Can Cadence design data be fed into B/S systems to automatically calculate test vectors ? Do we have to go for B/S-able devices only ? (cost, availability) No BGA rework tools available at Mainz. -->Do we need to purchase a F-BGA capable re-work system? Are non-vapour-phase systems sufficiently reliable at all?

5. Uli Schäfer Serial link chips for JEM0.1 JEM0 carries 88 LVDS link chips, 44 each on solder side and component side of the 1.6mm thick PCB. Problems during vapour phase process are possibly due to insufficient stability of PCB --> For next module iteration one might prefer a more rigid, thicker PCB --> No LVDS link chips on solder side ! So as to keep LVDS tracks short we would have to go for higher density compatible deserialiser devices (Nat.Semi., Altera Mercury, Xilinx... ?) Due to high component density JTAG/Boundary Scan highly desirable 1) 92LV1260 6-chann.compatible to DS92LV1021 no B/scan ! 2) Mercury 8/18-chan.compat. to 92LV1021 (and HP G-link)firmware req'd ! 3) Xilinx ? Virtex-2 hard cores not yet available. Deserialiser soft cores too slow ! 4) ??? --> Though we have a working scheme using DS92LV1224 on JEM0, we can only benefit from any higher density deserialisation scheme. Only lack of human resources and expertise on Altera presently prevents us from exploring Mercury devices.

6. Uli Schäfer JEM0 test plans and time scale ? connectivity tests, link tests partial algorithm tests with pseudo-random numbers With time scale slipping there won't probably be full algorithm tests in Mainz. --> slice test !