fmc-nanofip issueshttps://ohwr.org/project/fmc-nanofip/issues2022-07-12T12:20:53Zhttps://ohwr.org/project/fmc-nanofip/issues/64Actions and Recommendations from the nanoFIP FMC Dependability Analysis2022-07-12T12:20:53ZVolker SchrammActions and Recommendations from the nanoFIP FMC Dependability AnalysisA = proposed Action; R = Recommendation TBD ; see also [full report](https://edms.cern.ch/document/2683622/1)
To be checked if completed or ~~strikethrough~~ if obsolete
- [ ] [R] Use of a faster triggering fuse than FEASTMP / [bPOL](https://espace.cern.ch/project-DCDC-new/_layouts/15/start.aspx#/index/Home.aspx) DC/DC converter OCP on radtol system board to prevent short circuits of the nanoFIP FMC from affecting the radtol system board. In addition, faster triggering than RaToPUS OCP to prevent from bringing the DI/OT crate down.
- [ ] [R, optional] Use of ‘DRB’ packages for the linear voltage regulators to further optimise the heat dissipation.
- [ ] [R] Implementation of a Front End Computer (FEC) check to identify a potential lost fieldbus communication and/or lost node, e.g. from a wrong DIP switches configuration. Additional application specific mitigation (e.g. fail-safe) to be implemented upon detection.
- [ ] [R] Performance of a bus/node identification test on installation and after replacement to declare the bus segment as operational. -> user manual
Note: A wrong DIP switches configuration can affect up to two DI/OT crates.
- [ ] [R] Implementation of a check performed by the radtol system board to verify the communication with the nanoFIP FMC, e.g. to write to a nanoFIP register, read back, and compare. Potential failure modes: ‘FMC data line/pin open’
- [ ] [A] Tests at top performance parameters for functional validation of the nanoFIP FMC.
- [ ] [A] Validation tests at determined environmental stress limits (see [here](https://edms.cern.ch/document/2593588/1.1)) and top performance.
- [ ] [A] High stress tests to determine the robustness and sufficient margin for both functional errors and hardware failures against different stresses (see [here](https://edms.cern.ch/document/2593588/1.1)).
- [ ] [A] High quality requirements during the PCB and PCBA production process (IPC class 3), supported by a high level of inspections. Final End of Line functional test bench (“PTS”), as well as potentially intermediate component test benches to be designed and used.
- [ ] [R] Special attention to be paid during the assembly process of the DIP switches as well as during the subsequent functional testing and screening campaign.
- [ ] [A] Screening (temperature cycling) and reliability testing (run in) as outlined [here](https://edms.cern.ch/document/2593588/1.1).
- [ ] [R] Comprehensive failure monitoring, root-cause analysis and failure data analysis (Weibull analysis) for all units installed.https://ohwr.org/project/fmc-nanofip/issues/63Ensure good connection between the carrier front panel and SUB-D connector fo...2022-06-03T08:37:14ZVolker SchrammEnsure good connection between the carrier front panel and SUB-D connector for EMChttps://ohwr.org/project/fmc-nanofip/issues/61JTAG chains2022-05-05T14:59:03ZEvangelia GousiouJTAG chainsI think the JTAG chains in blue are essential:
- Programming of the nanoFIP ProASIC3 from the JTAG header on the FMC-nanoFIP board
- Programming of the SB FPGA from the nanoFIP JTAG controller (NF-JC) with a bitstream coming through the WorldFIP bus (this passes from GPIOs on the FMC connector, not the dedicated JTAG ones)
![image](/uploads/a6de6ddcdf27f07c03e71b5dca5132a5/image.png)
The JTAG chain in pink though, is it really essential?:
- Programming the SB FPGA through the FMC-nanoFIP JTAG header or programming the nanoFIP FPGA from a header on the SB
- Would other boards, other than the DI/OT SB, need this chain?https://ohwr.org/project/fmc-nanofip/issues/60One-shot triggers2022-05-05T14:31:20ZEvangelia GousiouOne-shot triggersInstead of having one-shot triggers to extend pulses for the LEDs, we could drive directly the LEDs from FPGA outputs.
On sch-v2 there was the option to:
- either tap on the CYC_I and FD_CDN_5V from the PCB and use one-shot triggers to extend them to become visible in the LEDs,
- or to drive directly the LEDs from the FPGA
IIRC at the time of v2 we did not want to touch the FPGA code (by driving the FPGA_LED_WB and FPGA_LED_FB to be the extended versions of the CYC_I and FD_CDN_5V), and we were making use of the one-shot triggers.
On the sch-v3, the one-shot triggers are the only option to drive the LEDs.
Now though that we will anyhow open the FPGA design, I think we could have gone for the direct FPGA outputs and get rid of all the one-shot triggers circuitry; like this we simplify the BOM and the components that need to be tested under radiation.