Penn Hardware and Software Notes

pic of sno rack Below is the list of hardware and software discoveries that we have made.

Penn DAQ programming golden rules.

These are rules that we have set up here at Penn to try to avoid subtle bugs in the HW/SW interaction. They are mainly intended for Penn internal consumption, but others might get some use out of them, too, so they are included here for that purpose.

  • #0: It's a code problem.
  • #0.5: In the rare occasions where rule #0 does not apply, it's an XL1-XL2 cable problem.
  • #1: Thou shalt not commit VME reset without notifying the entire western world, or at least the SNO collaboration
  • #1.5: Thou shalt not commit XL2 reset lest thy hast turned the PMT Control Juice (aka HV) to a sensible setting for the relay state to change.
  • #2: Thou shalt deselect all boards upon exiting thy function if thou hast selected any.
  • #3: Thou shalt leave thy motherboard in a well-defined state upon leaving thy function.
  • #4: Thou shalt not run pedestals with active triggers on more than 1000 channels.
  • #5: Thou shalt turn on the timing rack before turning on the SNO racks, and turn off the SNO racks before turning off the timing rack. The SNO racks should not be on with their CTC's connected to MTC/A's with the timing rack off.

    • Hardware problems with solutions and workarounds.

  • the two worst problems, for which there are no workarounds, unfortunately.... pic of silly people
  • First word problem: The problem refers to the behavior that the first bundle read out of the memory after coming out of a read lockout has garbage in its first 32 bits. The solution is a change to one of the xilinx files. We are presently testing a fix that looks promising. This problem has been fixed. A fixed Xilinx download file has been sent to UW.
  • Ch 31 has wide RMS on pedestals: This problem manifests itself during pedestal data taking. For certain values of GT delay, the channel with the highest priority (ch 31 if all are enabled) will have a wider pedestal width. This is due to a 'feature' where the CMOs chips puts out its DATA_AVAILABLE flag before the data is actually available. The workaround is to increase the delay between GT and pedestal, though UW and TRIUMF report that this does not work for them. The final answer involves a change in the sequencer xilinx chip.
  • MVME167 strangeness: JFW reports (and we have just recently also seen) strange behavior on the FECs when the MVME167 is plugged in. We do not understand this currently, and have no suggestions for workarounds at present. It probably has to do with a subtle bug in our SNObus to VME interface. This problem has been fixed. A fixed Xilinx download code was sent to UW.
    • tac non-linearity gif
  • TAC non-linearity: Another CMOS chip feature, this one is 'solved' via the use of long GTVALID times, which makes this problem appear only for channels that occur very much before GT. This 'early light' is of lesser physics interest than in-time or late light.(Get the complete CMOS/bipolar timing diagram, and click on the image of the slope to get a very nice postscript plot of the non-linearity done by Mark Neubauer.)
  • Bogus higher order GT IDs: At this point, the CGT5000, which provides the high oder bits to the FEC's GT ID, is still being tested. It would behoove people to ignore the upper eight bits of GT ID on the FEC at present.

    A related problem first reported by Paul Keener here is the appearance of out of sequence GTs during event building. It appears that under certain circumstances, there is bit rot in the first LW of a pmt bundle, including the GT ID and sometimes other parts of this word (Get the SNO FEC bit mapping.) This pretty serious problem is under investigation now.

    This problem has been solved and involves a new Xilinx bitstream that is being tested and used at site presently. (It also requires a small wire....)

  • Wide widths on selected QHS CMOS cells: Rich Helmer originally reported that daughter boards were causing the MB to fail in testing at TRIUMF due to wide RMS on pedestal data taking for selected, repeatable collection of QHS cells. Richard VdW has confirmed this behavior and is investigating the causes and consequences. At this point, there is no known workaround for this problem.

    • Related Penn Electronics documentation

    Here are some docs and links that are pertinent to the Penn Electronics effort.
  • FEC32 description doc The closest thing to a user's guide we presently have, this document is unfortunately a bit out of date. Take its wisdom with a grain of salt. Also in postscript format.
  • The extensive trigger document is available from Mark Neubauer. This is a complete description of the SNO Trigger system, in postscript only at this point.
  • The main Penn SNO site, with links to related hardware and software site.
  • As of Nov 5, 1997, there is a new flat address scheme for the SNO electronics crate mapping. Not for the faint of heart or the casual visitor, I'm afraid.
    •  pic of timing rack
    Number of visitors: counter
    Peter Wittich

    $Id: problems.html,v 1.9 1997/11/15 20:18:50 wittich Exp $