<!-- Title: 10:07:17  Mon Nov 29 2004 -->
<!-- Crewchief: corrinne  -->
<!-- Op1: all the Sili people -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>New week, new file</pre>


<!-- Date: Mon Nov 29 10:14:47 2004 -->
Got a trip this morning on L00 Flow too low on the West side.  Tried to look at this in the history plot but shows up as "no data".  Should fix that.  Cleared the interlock and all is well again.
<!-- Author: Eva H. -->
<!-- Comment: Mon Nov 29 10;19;54 comment by...Eva H. -->
 According to the cryo e-log, the resin was changed for both ISL and L00 chillers. Likely cause of the trip.

<!-- Comment: Mon Nov 29 10;22;28 comment by...Eva -->
meant, SVX chiller...

<!-- Date: Mon Nov 29 14:13:55 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W4L2 
<li>problem n: 948 
<li>Status: needs_observation
<li>Type: FE_amp_osc
<li>Action: Diagnosis_update
<li>entered by: cmills 
<li>description is: Ran this ladder with svxdaq.  FEO symptoms appear to be gone, even with ISEL integrator bits set to the standard 1010.  Corroborating plot in elog. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Nov 29 14:18:40 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Nov_29_2004_141831.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5402  align='top'></a></td><td> </td></tr></table>
<!-- Author: corrinne -->
<!-- Comment: Mon Nov 29 14;19;38 comment by...corrinne -->
<pre>Here's the plot referred to in the above pdb entry.  This does not show the grassy pedestal associated with the "front end osciallation" problem.</pre>


<!-- Comment: Mon Nov 29 14;23;37 comment by...corrinne -->
<pre>This was generated running the chips in nn mode but readall mode looks no different. </pre>
<!-- Date: Mon Nov 29 14:21:37 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Nov_29_2004_142133.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5404  align='top'></a></td><td> </td></tr></table>
<!-- Author: corrinne -->
<!-- Comment: Mon Nov 29 14;22;46 comment by...corrinne -->
<pre>For comparison, this is f140 showing the FEO symptoms in its last 4 chips.  This was generated with the chips in readall mode and the isel integrator bits set to 1010.</pre>



<!-- Date: Mon Nov 29 16:33:14 2004 -->
Stopped cooling/interlocks for approx. 1 hour to install new PLC hardware for iFix PC upgrade.  All is back to normal now.  
<!-- Author: Eva H., Andy H. -->


<!-- Date: Mon Nov 29 16:40:48 2004 -->
<pre>FTM # 564054 was tested with CH5 bit zero stuck high. This was diagnosed by swapping neighbouring channel RXs. Bit zero on channel 5 stayed high. 
 
RXs used were RX0470 and RX0721.  
 
The board needs to be sent back to Prep.</pre>
<!-- Author: Ankush Mitra, Rong-Shyang Lu -->


<!-- Date: Tue Nov 30 17:35:56 2004 -->
<h3> Teststand at FCC </h3> 
We got one FTM back from prep which checked out ok ...<br> 
Then we investigated, why channel 1 on the SVX WIB is not working anymore. After sevral attempts and some recabeling on the portcard, we have found the following: 
<ul> 
<li>On this portcard only channel 0 and 3 are still working</li> 
<li>1,2,4 fail for different reason</li> 
</ul> 
Due to this, please only use 0 and 3 for any Board tests at FCC 
  
<!-- Author: Marcel -->
<!-- Comment: Tue Nov 30 17;36;24 comment by...Marcel -->
Too fast forgot Ankush and Rong-Shyang


<!-- Date: Tue Nov 30 19:13:15 2004 -->
<pre><br><b>SRC FPGA Usage</b><br> 
This is the status of the FPGAs. Above 70-80% usage 
routing problems start. No recent modifications 
of PIPECAP, ERRLOG and FIBINT were done. No problems 
with the other ones. 
 
<pre> 
VME 
Number of External IOBs            70 out of 74     94% 
Number of CLBs                     29 out of 100    29% 
 
TSI EMU 
Number of External IOBs            89 out of 138    64% 
Number of CLBs                    306 out of 484    63% 
 
MCLK 
Number of External IOBs           105 out of 120    87% 
Number of CLBs                    155 out of 224    69% 
 
RSM 
Number of External IOBs           178 out of 192    92% 
Number of CLBs                    576 out of 1024   56% 
 
TAXI 
Number of External IOBs            54 out of 74     72% 
Number of CLBs                     61 out of 100    61% 
 
BUFMAN 
Number of External IOBs            50 out of 70     71% 
Number of CLBs                    134 out of 224    59% 
 
FIBINT 
Number of External IOBs            73 out of 120    60% 
Number of CLBs                    175 out of 224    78% 
 
ERRLOG 
Number of External IOBs            94 out of 129    72% 
Number of CLBs                    300 out of 400    75% 
 
PIPECAP 
Number of External IOBs            45 out of 61     73% 
Number of CLBs                    313 out of 400    78% 
</pre></pre>
<!-- Author: Sebastian -->


<!-- Date: Tue Nov 30 21:29:41 2004 -->
<br><b>MCLK firmware (SRC)</b><br> 
MCLK r1v12 has one timming constraint not met: 
<pre> 
Asterisk (*) preceding a constraint indicates it was not met. 
 
-------------------------------------------------------------------------------- 
  Constraint                                | Requested  | Actual     | Logic  
                                            |            |            | Levels 
-------------------------------------------------------------------------------- 
* TS0 = MAXDELAY FROM TIMEGRP "FFGRP" TO TI | 16.129ns   | 16.979ns   | 2     
  MEGRP "FFGRP" 16.129 nS                   |            |            |       
</pre> 
 
I changed the firmware to fix this. With Marcel we swapped the 
new PROMs in SVX and ISL but found problems with the SVX SRC 
(we didn't see any signals comming back from the FFO). The  
problem was fixed by changing back to the old MCLK PROM.<br> 
We put back the old PROMs in SVX and ISL and took the system 
through a coldstart. I will test the new PROM in the testand 
tomorrow (something I should have done in the first place).<br>  
<!-- Author: Marcel/Sebastian -->
<!-- Comment: Tue Nov 30 23;55;51 comment by...Marcel -->
One should add, that we found this problem while testing the Ghostbuster after we swapped Firmware. Everything on the SRC looked perfectly ok. So we would only catch the problem by doing something with the FFO/Fib's or for that case the readout return signal from the FFO. 
So in most of our tests, we would not have seen this ... earliest maybe with the pigs. It is alos not clar why the new firmware worked fine with DOC, but Happy had problems with it. 


<!-- Comment: Wed Dec  1 15;23;31 comment by...Sebastian -->
<pre>Looked at MCLK1.16 in teststand and the FFO return is missing. Checked with MCLK1.12 and the return signal is there. Tried two
SRCs. </pre>


<!-- Comment: Thu Dec  2 13;53;40 comment by...Sebastian -->
<br><b>MCLK 1.13 OK</b><br>
Increased the routing effort when compiling, this reduced the
SLOCLK timming from 69.246ns to 44.253ns (the 100.000ns is not
good enough). We can put this PROMs in SVX and ISL when we have the chance.
<!-- Comment: Thu Dec  2 16;55;43 comment by...Sebastian -->
<br>Marcel and I tried the "new" MCLK firmware in SVX/ISL. We found
that we could <b>not</b> even sync the FFO glinks from SVX. However , unfortunately, the same firmware works on the teststand. Looks like the timming of the signals (in SVX) comming out of the SRCTM is not correct and the FFO does not understand it. We should find a way to look into the SRCTM-FFO signals. If it's only a SRC-FFO problem, why it works on the testsand (and from ISL we could also sync the Glinks)? 
<!-- Date: Wed Dec 1 16:42:11 2004 -->
Got a brand new VRB from the PREP. I tested it. It is fine and as a spare now.
<!-- Author: Tuula -->
<!-- Comment: Thu Dec  2 13;37;36 comment by...Marcel -->
Just as an information, the new VRB (459) is at the tstsvx1 teststand in the trigger room, I 've updated the Firmware yesterday night 


<!-- Date: Thu Dec 2 09:13:30 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Dec__2_2004_091325.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5406  align='top'></a></td><td> </td></tr></table>
<!-- Author: corrinne -->
<!-- Comment: Thu Dec  2 09;22;48 comment by...corrinne -->
Comparison of data from ISL test stand where the control line LIA* has been cut. (See next elog entry by me for more explanation).  Black = isel integrator bits = 1010 (default), Red = isel integrator bits = 1111 (FEO "fix").  Cutting L1A* gave data which most resembled data from the FEO candidates (see entry 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=225&frame=2&anchor=14:21:37'>
here </a> 
for an example).  But, changing the ISEL bits does not make the symptoms disappear.  That, combined with the fact that cutting L1A* tends to cause of digital errors (CAP ID) but none of the three "good" FEO candiates cause them, makes it seem unlikely that this is the culprit.





<!-- Comment: Fri Dec  3 18;37;01 comment by...corrinne -->
The "next elog entry by me" is this webpage:<br>
<a href="http://b0sili01.fnal.gov/~cmills/feo_studies.html">
front end oscillation studies </a>
<!-- Date: Thu Dec 2 17:13:05 2004 -->
<h2> B0dap42-44 reboot </h2> 
We had to reboot these because of problems with the NFS (you don't want to know ...). Everything is back up and should be fine. 
  
<!-- Author: Corrine & Marcel -->


<!-- Date: Fri Dec 3 08:23:06 2004 -->
<h2>Plan for Quiet Time Studies</h2> 
We've put in a request to have 6 hours of quiet time.  When we get it, this is the plan:<br> 
<ol> 
<li> start up detector and DAQ ~ 1 hour (less?) 
<li> run cosmics ~ 1 hour 
<li> DMODE calibrations ~ 30 min 
<li> bias scan ~ 4 hours 
</ol> 
In parallel: 
<ul> 
<li> IMON work 
</ul> 
Necessary people: pager carrier (corrinne), spl (Rong), daq person (sebastian?), Ben if possible, Mircea and/or Dean for IMON updates.<br> 
Any comments, things to add?<br>
<!-- Author: Rong and corrinne -->


<!-- Date: Fri Dec 3 12:11:33 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5407&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5407  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author: corrinne -->
<!-- Comment: Fri Dec  3 12;15;28 comment by...corrinne -->
<b>f522</b> was out of the hwdb due to <b>persistant DVDD OC trips</b>.  I powered it up to see if the problem was peristant and got no trip.  I powered it down (all the way to off) and back up again to see if it would behave well again.  It did.  I leaving it <b>in the hwdb for now</b>.<p>
One comment is that I did use svxdaq to issue a config after bringing the wedge to standby.  It may trip if there is no immediate config.  

<!-- Date: Fri Dec 3 12:21:21 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W2L2 
<li>problem n: 383 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Added_hdwdb
<li>entered by: cmills 
<li>description is: successfully biased ladder twice.    <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=225&frame=2&anchor=12:11:33'> see here for details </a>. re-integrating. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Dec 3 13:14:40 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Dec__3_2004_131437.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5409  align='top'></a></td><td> </td></tr></table>
<!-- Author: corrinne -->
<!-- Comment: Fri Dec  3 13;24;19 comment by...corrinne -->
Antonio reported that this ladder (SB3W0L4) has a low number of reconstructed clusters and low collected charge.  Might have been a bias issue.  Compared noise and dnoise for <b><font color=red>biased</font></b> and <b>unbiased</b> (above).  It looks like the ladder is probably biased but it's difficult to tell.  
<p>
There is a <b>hot strip</b> around channel 1280.  It can't be a pinhole (I think) because the bias leakage current that is read back is 0.0uA.  <p>
Saved .svx files in <br> b0dap42:~/svxii/daq/svx/e304_{nobias,biased}_cmills.svx<br>



<!-- Date: Fri Dec 3 18:34:01 2004 -->
<h2>Front End Oscillation Studies</h2> 
I've put together a webpage describing all of the studies I've done so far on the Front End Oscillation problem.  It can be found 
<a href="http://b0sili01.fnal.gov/~cmills/feo_studies.html"> 
here 
</a>.
<!-- Author: corrinne -->



<!-- Date: Sun Dec 5 19:32:25 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_Dec__5_2004_193201.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-5421  align='top'></a></td><td><b>Test of GLink-FFO return-MCLK firmware</b> <br> 
<ul> 
<li> Tested MC1.14 (69ns delay) on Bashful in tstsvx1. Saw the FFO return and the GLink sync signals (as shown in the plot). (J11 GND-signal pins inverted.. Thanks to Steve, I only lost about an hour on this last Friday). 
<li> Swapped in Dopey. With MC1.14 can not see the FFO return on LA. Can sync the FFO-SRC GLink but, can not 
see the traces in the LA. J11 seems not to be working on Dopey. Changed to MC1.1, the FFO returns are there, but 
still the LA traces of the GLink sync are not. 
<li> Tried Sneezy. FFO return ok, GLink sync signals are there (idem Bashful). 
<li> Hooked up the LA to FIB_INT in SVX and checked that the 
GLink sync signals look OK with MC1.12. Didn't try with 
MC1.14 to avoid causing more problems to the Ace... 
</ul></td></tr></table>
<!-- Author: Sebastian -->