<!-- Title: 11:36:11  Fri Jun 14 2002 -->
<!-- Crewchief: silicon -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>end of access. Preparing to integrate.</pre>


<!-- Date: Fri Jun 14 11:38:28 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_14_2002_113819.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-556  align='top'></td><td>SB0W2L2 dropping readout after phi side. Top: bit 7 Bottom: OBDV. Note the five bit seven spikes, this could be the 5 z-side chips a4-a0? </a></td></tr></table>
<!-- Author: Lester -->


<!-- Date: Fri Jun 14 11:39:52 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_14_2002_113949.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-558  align='top'></td><td>SB0W2L2, showing poor quality OBDV for phi side chips.  38% duty cycle, and some leading edge spikes. The FIB is still able to clock this in, apparently.</a></td></tr></table>
<!-- Author: Lester -->


<!-- Date: Fri Jun 14 11:43:13 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_14_2002_114306.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-562  align='top'></td><td>SB1W2L2 showing odd double bump of bit 7 for the passing  priority. (the latter is a legitimate chip ID.) <ul> <li>Top: bit 0</li> <li>Middle: OBDV</li> <li>Bottom: bit 7</li> <ul></a></td></tr></table>
<!-- Author: Lester -->


<!-- Date: Fri Jun 14 11:45:43 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_14_2002_114539.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-564  align='top'></td><td>SB1W2L2 formerly dropped readout internal at Chip 85. Investigated in access, it still does stop sending OBDV at the end of chip 85. <ul> <li>Top: bit 0</li> <li>Middle: OBDV</li> <li>Bottom: bit 7</li> </ul> </a></td></tr></table>
<!-- Author: Lester -->


<!-- Date: Fri Jun 14 11:48:27 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_14_2002_114815.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-566  align='top'></td><td>SB1W2L2: Recently this ladder moved from dropping readout  at chip 85 to dropping readout randomly in chip 89. Looking at light, see sometimes that chip 89 has spurious bit 7 activity and poor quality signals on other bits when  these spurious spikes occur.  <ul> <li>Top: bit 0</li> <li>Middle: OBDV</li> <li>Bottom: bit 7</li> </ul></a></td></tr></table>
<!-- Author: Lester -->


<!-- Date: Fri Jun 14 13:39:05 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-569&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-570' ></a></center>
<!-- Author: Gino -->
<!-- Comment: Fri Jun 14 13;44;59 comment by...Gino -->
<pre>SB4W8L2, started to gave us trouble on the 10th of January.

Here is what I get from a simple grep on the run error log file during the few minutes around the time of failure.

(MLE) b0l3gate1.fnal.gov:main:2:36:28 AM-&gt;Host b0eb15.fnal.gov, task tRec_0
(MLE) b0tsi02:Messenger:2:36:24 AM-&gt;BUSY timeout
(MLE) b0tsi02:Messenger:2:36:28 AM-&gt;BUSY timeout
(MLE) b0tsi02:Messenger:2:36:33 AM-&gt;BUSY timeout
(MLE) b0svx01:Messenger:2:35:15 AM-&gt;Silicon Timeout:BUSY- Slots:  12:e140
(RC)   2:36:42 Halt -&gt; HALTED
(RC)   2:36:49 Recover -&gt; RECOVERED
(RC)   2:36:55 Run -&gt; ACTIVE
(MLE) b0l3gate2.fnal.gov:main:2:37:00 AM-&gt;Error on L3 node b0l3113 (partition 0) Sun Feb 10 02:36:58 2002 l3_node 
(MLE) b0l3gate2.fnal.gov:main:2:38:38 AM-&gt;Error on L3 node b0l3238 (partition 0) Sun Feb 10 02:38:37 2002 l3_node 
(MLE) b0l3gate2.fnal.gov:main:2:38:42 AM-&gt;Error on L3 node b0l3078 (partition 0) Sun Feb 10 02:38:40 2002 l3_node 
(MLE) b0l3gate2.fnal.gov:main:2:38:42 AM-&gt;Error on L3 node b0l3078 (partition 0) Sun Feb 10 02:38:40 2002 l3_node 
(MLE) b0l3gate2.fnal.gov:main:2:38:54 AM-&gt;Error on L3 node b0l3025 (partition 0) Sun Feb 10 02:38:52 2002 l3_node 
(MLE) b0cot09:Messenger:2:38:58 AM-&gt;Runtime Error 5, Event 928073: data truncated
(MLE) b0cot11:Messenger:2:38:57 AM-&gt;Runtime Error 6, Event 928073: data truncated
(MLE) b0cot00:Messenger:2:38:57 AM-&gt;Runtime Error 4, Event 928073: data truncated
(MLE) b0cot10:Messenger:2:38:59 AM-&gt;Runtime Error 6, Event 928073: data truncated
(MLE) b0cot08:Messenger:2:38:56 AM-&gt;Runtime Error 6, Event 928073: data truncated
(MLE) b0l3gate2.fnal.gov:main:2:38:57 AM-&gt;Error on L3 node b0l3207 (partition 0) Sun Feb 10 02:38:55 2002 l3_node 
(MLE) b0l3gate2.fnal.gov:main:2:38:57 AM-&gt;Error on L3 node b0l3114 (partition 0) Sun Feb 10 02:38:56 2002 l3_node 

We have to investigate more into the possibility to lower our trip limits for the LV currents.</pre>


<!-- Date: Fri Jun 14 13:57:02 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_14_2002_135645.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-572  align='top'></td><td>SB3W2L0 OBDV glitch which may cause dropping readout. OBDV has normal length and duty cycle, etc Otherwise. Also  spurious bit seven activity during priority passing was seen. (as seen in e122 noted above).</a></td></tr></table>
<!-- Author: Lester -->


<!-- Date: Fri Jun 14 14:00:45 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_14_2002_140026.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-574  align='top'></td><td>Sb1W4 light showing internal dropping readout at the end of  chip A6. OBDV continuesfor another 2 chips but no data is  seen. (Note delayed time base of trace) Traces are <ul> <li> Top: bit 6</li> <li> Middle: bit 7</li> <li> Bottom: OBDV</li> </ul></a></td></tr></table>
<!-- Author: Lester -->
<!-- Comment: Fri Jun 14 14;03;15 comment by...L -->
<b>This is SB5W1L4 sorry. </b>


<!-- Date: Fri Jun 14 15:33:01 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_14_2002_153255.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-576  align='top'></td><td>SB2W5L4 dropping readout after 10 chips, and some activity  on the other bits after end of readout.  Note delayed time base. Traces: <ul> <li>Top: bit 2</li> <li>Middle: bit 7</li> <li>Bottom: obdv</li> </ul> </a></td></tr></table>
<!-- Author: Lester -->


<!-- Date: Fri Jun 14 15:37:41 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_14_2002_153737.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-578  align='top'></td><td>SB2W5L4 showing beginning of readout of First chip ID which is clocked in as 8d. Traces: <ul> <li>Top: obdv</li> <li>Middle: bit 7</li> <li>Bottom: bit 2</li> </ul> Note spurious activity on bit 2, this could cause  chip if 89 to come in as 8d. Similaryly could cause  chip 87 to come in as 83, as seen offline. Still a mystery as to why the readout begins at 89,  and why the init reaback is fine.</a></td></tr></table>
<!-- Author: Lester -->


<!-- Date: Fri Jun 14 21:15:32 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-579&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-579  width='300' align='top'></td><td>The blue line is ISL_TE_CCE1L6_1OUT.  The first step is me turning IB4W5L1 to STBY.  The second step is me turning IB4W5L3 to STBY.  The temperature then plateaus at 16 deg C. This is close to the 18 deg C trip limit, so I increased the flow to CCE1 (from 1.8 to 1.9 lpm), resulting in the small (< 1 deg) temperature drop.  As I have yet to even turn on the L6 ladders in IB4W0, I conclude that the flow through CCE1.1 is insufficient.  Unfortunately the CCE1 pressure at the COT face is already 12 psia so I can't increase the flow much further.</a></td></tr></table>
<!-- Author: Andy H. -->


<!-- Date: Fri Jun 14 21:51:02 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-580&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-580  width='300' align='top'></td><td>I turned IB4W1L1, IB4W1L3, and IB4W2L1 to STBY.  ISL_TE_CCE1L6_2OUT (greyish line) rose by a degree.  So CCE1.2 is sufficiently cooled.</a></td></tr></table>
<!-- Author: Andy H. -->


<!-- Date: Fri Jun 14 22:25:15 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-581&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-581  width='300' align='top'></td><td>I turned IB3W0L4 and all of IB3W1 to STBY.  ISL_TE_CCE2L6_2OUT increases by about 3 degrees (you don't see the ramp-up because I realized a little late that I was plotting the wrong thing).  It looks like ISL_TE_CCE1L6_2OUT gets heated up by the ambient temperature.  I then increased the flows on CCE2 and CCE3 to try and cool CCE1.2 and CCE2.2 a little more.  It had a small effect.  Anyway I conclude that CCE2.2 is sufficiently cooled.</a></td></tr></table>
<!-- Author: Andy H. -->
<!-- Comment: Fri Jun 14 22;50;39 comment by...Andy H. -->
I realized that IB3W1L3 and IB3W1L4 are cooled by CCE2.3, which
is still blocked.  I turned those ladders off and ISL_TE_CCE2L6_2OUT and ISL_TE_CCE1L6_2OUT dropped by a degree or
two.  <b>So I think a mistake has been made.  The ladders cooled
by CCE2.3 (still blocked) are enabled in the HDWDB and the ladders cooled by CCE2.1 (unblocked) are disabled.  An ISL
expert should confirm my suspicions!</b>


<!-- Comment: Tue Jun 18 14;47;24 comment by...CH -->
<pre>Andy is correct, E1.2 and E2.3 were mixed up.  See below.</pre>
<!-- Date: Fri Jun 14 22:56:21 2002 -->
I turned all of IB5 to STBY.  The effect on the temperatures 
on the newly-unblocked lines was negligible.
<!-- Author: Andy H. -->


<!-- Date: Fri Jun 14 23:17:38 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-582&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-582  width='300' align='top'></td><td>I turned IB1W4L3, IB1W5L1, IB1W5L3, and IB1W0L1 to STBY.  No significant temperature rise is seen.  Conclusion: CCW1.1 is sufficiently cooled.</a></td></tr></table>
<!-- Author: Captain Tedium -->


<!-- Date: Fri Jun 14 23:28:09 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-584&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-584  width='300' align='top'></td><td>I turned IB1W3L1, IB1W3L3, and IB1W4L1 to STBY.  ISL_TE_CCW1L6_3OUT (yellow line) increases a little.  Conclusion: CCW1.3 is sufficiently cooled.</a></td></tr></table>
<!-- Author: Andy H. -->


<!-- Date: Sat Jun 15 00:04:52 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-585&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-585  width='300' align='top'></td><td>The greyish line is ISL_TE_CCW1L6_2OUT.  The first step is me turning IB1W0L3 and IB1W1L1 to STBY.  The second step is IB1W1L3 to STBY.  The third step is IB1W2L1 to STBY.  The temperature is pretty close to the trip limit and I still haven't turned on IB1W2L3.  Conclusion:  CCW1.2 is insufficiently cooled.</a></td></tr></table>
<!-- Author: Andy H. -->


<!-- Date: Sat Jun 15 00:24:15 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-586&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-586  width='300' align='top'></td><td>The blue line is ISL_TE_CCW2L6_2OUT.  I turned IB2W0L3, IB2W0L4, IB2W1L1, IB2W1L2, and IB2W1L3 to STBY all in one go.  This is the line that was opened last year, and it had a plateau temperature of 14.6 deg, which is where it looks like it's heading now.  Note how ISL_TE_CCW1L6_2OUT picks up the ambient.  Conclusion: CCW2.2 is sufficiently cooled (which we knew already).</a></td></tr></table>
<!-- Author: Andy H. -->
<!-- Comment: Sat Jun 15 00;38;42 comment by...Andy H. -->
I was off by one -- the ladders turned to STBY in IB2W1 were L0, L1, and L2.
<!-- Date: Sat Jun 15 00:37:46 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-587&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-587  width='300' align='top'></td><td>Turned IB2W1L3, IB2W1L4, and IB2W1L1 to STBY.  ISL_TE_CCW2L6_3OUT (pink line) hardly rises at all.  In fact ISL_TE_CCW1L6_3OUT (yellow line) picks it up more than anything.  Conclusion:  CCW2.3 is sufficiently cooled.</a></td></tr></table>
<!-- Author: Andy H. -->



<!-- Date: Sat Jun 15 01:12:49 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-588&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-588  width='300' align='top'></td><td>The red line is ISL_TE_CCW2L6_1OUT.  The first step (very gradual) is me turning IB2W2L2 to STBY.  The next is IB2W2L3.  The next is IB2W0L0.  The last one is IB2W0L1 and IB2W0L2 at the same time (my patience is now at an end). The temperature is pretty close to the trip limit, and when we turn on the rest of the silicon it will probably be uncomfortably close.  Conclusion:  CCW2.1 is insufficiently cooled.</a></td></tr></table>
<!-- Author: Andy H. -->


<!-- Date: Sat Jun 15 02:22:09 2002 -->
<h1>Summary of all this</h1> 
The following lines are still blocked:<br> 
CCE1.3<br> 
CCE2.3<br> 
<p> 
The following lines were opened but provide insufficient cooling:<br> 
CCW1.2<br> 
CCW2.1<br> 
CCE1.1<br> 
<p> 
The following lines were opened and are providing sufficient cooling:<br> 
CCW1.1<br> 
CCW1.3<br> 
CCW2.2 (last year)<br> 
CCW2.3<br> 
CCE1.2<br> 
CCE2.2<br> 
<p> 
The status of CCE2.1 is unknown; its ladders are disabled in the 
HDWDB and I'd like to understand why this is so before I do 
anything with it (cf. the comment in 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=113&frame=2&anchor=22:25:15'> 
this entry</a>).  
<p> 
The "insufficient cooling" lines aren't a lost cause; we need to 
look at these carefully and think about whether or not we could 
live with higher temperature trip limits. 
<p> 
After consultation with David Stuart, we decided to kick out all 
ladders associated with lines that weren't cooling easily.  To 
do this I looked at Table 3 in CDF note 5553 and kicked out any HDI containing a module associated with an imperfect cooling line.  I loaded the new CAENvolts.dat into the GUI.  I also 
turned L00 and SVX to STBY in case there were any surprises to 
be had.
<!-- Author: Andy H. -->
<!-- Comment: Sat Jun 15 02;31;47 comment by...Andy H. -->
<pre>The ladders booted were:

IB1W0 L3
IB1W1 L1 L3
IB1W2 L1 L3
IB2W0 L0 L1 L2
IB2W2 L2 L3
IB3W1 L2 L3 L4
IB3W2 L0 L1 L2
IB4W0 L1 L3
IB4W5 L1 L3
</pre>


<!-- Date: Sat Jun 15 13:05:30 2002 -->
<pre>Came in to try to run. Ran into problems with the FIB crate  
configuration in cold start. Seems not to reflect the hardware 
database. Emailed SCN. 
 
Also, SB2W10 software tripped this morning at 7am. Not a good 
sign since its been superfibbed... 
</pre>
<!-- Author: Lester -->
<!-- Comment: Sat Jun 15 18;51;56 comment by...Gino -->
<pre>I found a way around the problem.
Every FIB channel with the Online flag set to 0 was still failing coldstart if the mask bit was at 0 as well.

By changing the mask bit to 1 for all the FIB channels that are OFFLINE the problem was solved.

I ENDED UP CHANGING THE MASK BIT IN THE HDWDB FROM 0 TO 1 FOR ALL THE FOLLOWING FIB CHANNELS.

e130
e034
e0b1
e002
e254
e083
e063
e060
e142
e434
e404
e3a3
e481
e482
e494
e463
e380
f544
f540
fa04
fa14
fa40
fa50
f401
f402
f403
fa24
fa34
f312
f313
f314
f532
f450
f451
f453
f844
f854
f804
f814
f222
f223
f103
f111
f113
f004
f824
f834
f200
f201
f202
f121
f123
f230
f231
f232
f233
f234
f320
f321
f322
fa44
fa54
f330
f331
f332
f333
f334

This list include the 4th channel of the L00 fibs and even the half FIBs that are not used for ISL.

When SCN comes back he should look into this and find the real source of the trouble.
</pre>
<!-- Comment: Sun Jun 16 18;00;14 comment by...SCN -->
Guessing it has something to do with this
<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=111&frame=2&anchor=11:16:37'>
modification to Fib downloading code for access</a>.  Will fix tomorrow AM.  Thought I fixed it, but didn't try the code
on <B>OFFLINE</B> ladders.
<!-- Comment: Mon Jun 17 08;16;34 comment by...SCN -->
Should be fixed now.  Will test when am sure it won't be disruptive to current activities
<!-- Comment: Mon Jun 17 15;25;31 comment by...SCN -->
<h3>Unmasking</h3>
Code fix works (just restoration of pre access code) so I took
the following actions regarding the MASK bit for ChipChains in the hardware database, whose purpose is to make sure that
things which should definetly not be powered are not.  (MASK = 0 means powerable, MASK = 1 means NOT).<ul>
<li>Set MASK = 0 for all SVXII 
<li> Set MASK = 1 for all non-existant pieces of Silicon (HDI 4 of L00, Portcard 3 of ISL Central)
<li> Set Mask = 0 and Reason = 0 (was 99 i.e. ISL Cooling) for all West ISL
<li> Set Mask = 0 for East ISL where Reason != 99
</ul> 
I did this after consulting with Chris and Gino-there are a few
issues<ul>
<li> The use of SVXII power supplies for L00 may require that
L00 HDI4s revert to unmasked and/or online
<li> I may have erased some decisions about masking out "partially cooled ladders" on the ISL West, but we can remask as desired
<li> I may have made some error.  Someone should check that 
uncooled ISL East is in fact masked off appropriately.
</ul>
Ways to prevent this in the future are<ul>
<li>Test with RC more than 4 wedges before the expert leaves
<li>Get more experts
</ul>
<!-- Date: Sat Jun 15 15:10:39 2002 -->
<pre>There was an SVX power supply trip.  At the request of the experts, I reset the trip from the CAEN window.</pre>
<!-- Author: Jim Kraus -->
<!-- Comment: Sat Jun 15 15;11;34 comment by...Jim Kraus -->
<pre>The trip was sent by B2 W10 L3</pre>


<!-- Comment: Sat Jun 15 22;35;36 comment by...Gino -->
<pre>This wedge was turned ON once again in the afternoon. So far no problem.</pre>
<!-- Date: Sat Jun 15 17:48:00 2002 -->
<pre>e4b0	SITEMATICALLY reads back an extra bit HIGH on the MASK 
	for charge injection. I masked the bitstream readback. 
 
06-15-2002 05:05:41 CDT : 1024135541 Init Fib e4b0 hdi 5 ERRORS: tried 4 chips:  
 sent:   00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 
 16 2d 36 d0 c6 3f 48 f8 0d 00 10 00 10 00 10 
 10 00 10 00 10 00 10 00 d0 a2 c5 16 9a f8 07 
 bf 01 00 02 00 02 00 02 00 02 00 02 00 02 00 
 00 56 b4 d8 05 13 ff 30 e1 37 00 40 00 40 00 
 00 40 00 40 00 40 00 40 00 c0 8a 16 fb 60 e2 
 26 fc 06   
 read:                                                
                               30             
                                              
                                              
                                              
                                             </pre>
<!-- Author: Gino -->


<!-- Date: Sat Jun 15 17:51:19 2002 -->
<pre>e382	reads back ffs during INIT 
	in readout all you get is 00d0d0c2 c2 
	Lester swapped an the RX for this guy during the access 
	Before the access it INITED. 
	Removed from HDWDB. Set its online FLAG to 0. 
</pre>
<!-- Author: Gino -->
<!-- Comment: Sun Jun 16 10;31;23 comment by...Gino and Lester -->
<pre>Went in the collision hall during the controlled access.
Swapped fibers for e382 and e380.
Now the ladder SB3W8L2 initialize but still reads out c2c2.
Swapped everything back. 
The problem with SB3W8L2 is not yet understood.
</pre>




<!-- Date: Mon Jun 17 14:04:56 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Jun_17_2002_140440.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-590  align='top'></td><td>DVDD currents for SB2W10 at the time of the software protection trip on saturday 06/15/2002. BLACK is L0, RED is L1, BLUE is L2, GREEN is L3 and TURQUOISE is L4</a></td></tr></table>
<!-- Author: Gino -->
<!-- Comment: Mon Jun 17 14;18;36 comment by...Gino -->
<pre>L0 and L4 do NOT show any change in DVDD current.
L1, L2 and L3 clearly show very similar behavior vs time. 
The magnitude of the current changes is such that only 
the L3 tripped bringing down the whole wedge.



</pre>



<!-- Date: Mon Jun 17 16:43:06 2002 -->
<h3> Repeated Bytes timeout</h3> 
I am implementing in certain Fibs new firmware where the Fib truncates the readout after seeing the same byte for a programmable number of consecutive clocks (between 7 and 13 
repetitions), which should in principle ameliorate if not 
eliminate the long readout times from "00f3".  Chris gave me  
a list of flagrant 00f3 perpetrators<table> 
<tr><th>Ladder<th> # <th> crate <th> sl <th> Updated? 
<tr> <td> e033 <td>214 <td> b0fib00 <td> 11 <td> N  
<tr> <td>e114 <td>53 <td> b0fib00 <td> 12 <td> N 
<tr> <td>e140 <td>58<td> b0fib02 <td> 12 <td> Y 
<tr> <td>e141 <td>30<td> b0fib02 <td> 12 <td> Y 
<tr> <td>e142 <td>25<td> b0fib02 <td> 12 <td> Y 
<tr> <td>e144 <td>185<td> b0fib02 <td> 12 <td> Y 
<tr> <td>e204 <td>49<td> b0fib00 <td> 17 <td> N 
<tr> <td>e240 <td>17<td> b0fib02 <td> 17 <td> Y 
<tr> <td>e241 <td>18<td> b0fib02 <td> 17 <td> Y 
<tr> <td>e242 <td>24<td> b0fib02 <td> 17 <td> Y 
<tr> <td>e243 <td>16<td> b0fib02 <td> 17 <td> Y 
<tr> <td>e244 <td>20<td> b0fib02 <td> 17 <td> Y 
<tr> <td>e250 <td>148<td> b0fib02 <td> 17 <td> Y 
<tr> <td>e2b2 <td>18<td> b0fib00 <td> 19 <td> N 
<tr> <td>e2b3 <td>13<td> b0fib00 <td> 19 <td> N 
<tr> <td>e362 <td>24<td> b0fib06 <td> 9 <td> Y 
<tr> <td>e364 <td>227<td> b0fib06 <td> 9 <td> Y 
<tr> <td>e384 <td>18<td> b0fib06 <td> 10 <td> N 
<tr> <td>e450 <td>38<td> b0fib06 <td> 11 <td> N 
<tr> <td>e452 <td>16<td> b0fib06 <td> 11 <td> N 
<tr> <td>e453 <td>13<td> b0fib06 <td> 11 <td> N 
<tr> <td>e514 <td>428<td> b0fib04 <td> 16 <td> Y 
<tr> <td>e593 <td>12<td> b0fib06 <td> 19 <td> N 
<tr> <td>f034 <td>11<td> b0fib01 <td> 9 <td> N 
<tr> <td>f040 <td>12<td> b0fib03 <td> 10 <td> N 
<tr> <td>f512 <td>27<td> b0fib07 <td> 10 <td> N 
<tr> <td>f513 <td>54<td> b0fib07 <td> 10 <td> N 
<tr> <td>f810 <td>21<td> b0fib03 <td> 16 <td> N 
<tr> <td>fa41 <td>18<td> b0fib07 <td> 17 <td> N 
</table> 
Where # is the number of occurances and Updated? is "Did I put new firmware i".  In the next running we should see if <ul> 
<li> we get the desired reduction of 00f3 from these ladders 
<li> Any new problem crop up with the updated Fibs 
</ul> and 
then we can apply this to all Fibs.  
I also updated Fib code to access the timeout register, 
and rebooted all Fib crates.  
<!-- Author: SCN -->
<!-- Comment: Thu Jun 20 14;34;33 comment by...SCN, Reid -->
<h3>Oops</h3>
Actually, f512 and f513 ARE updated.
<!-- Date: Mon Jun 17 17:25:22 2002 -->
<h3>Updated VRb firmware</h3> 
Applied vrb2603P.hex to Vrbs in b0svx03 and b0svx04 and some of b0svx05.  Will finish with others later or tomorrow.Gotta go.  
<!-- Author: SCN -->
<!-- Comment: Tue Jun 18 14;07;06 comment by...SCN -->
<h3>Updated VRB firmware everywhere</h3>
Updated all VRBs to latest firmware, vrb2603P.hex, which
should shorten the constant term (i.e. that which does not scale with occupancy) of minimum time between Fib READOUT from
11 uS to like 9 uS  (<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=110&frame=2&anchor=22:09:12'>previous study</a>) by allowing the VRB to drop Read Busy before it is
quite done updating all the counts etc.

<!-- Date: Tue Jun 18 02:47:20 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-592&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-592  width='300' align='top'></td><td>Got paged because ISL_TE_CCW2L6_1OUT exceeded the 18 deg C trip limit.  The history plot shows it had been slowly climbing since silicon was turned off yesterday.  I disconnected/reconnected it at the PLC input module and it returned to normal.  We should keep an eye on it; this RTD has been flakey in the past (we had it masked out of the interlock code for a while).</a></td></tr></table>
<!-- Author: Andy H. -->



<!-- Date: Tue Jun 18 14:46:31 2002 -->
<pre>As noted by Andy above, There was a mistake in the original 
communication of cooled ISL lines on the East.  As a result, we 
"commissioned" E2.3 which is not cooled instead of E2.1 which  
is cooled.   
 
We need to fix this on a controlled access asap. 
We will need access to both corners (SE top and NE bot) and do 
the following: 
 
1) For E2.1 = IB3W0L0,L1,L2,L3 and IB3W2L2,L3 
   - remove jumpers 
   - check bias splitting 
2) For E2.3 = IB3W1L3,L4 and IB3W2L0,L1,L2 
   - re-insert jumpers 
 
Operationally, this mistake has the following consequences until 
the problem is addressed on access: 
 
A) IB3 has its IFIX interlock INACTIVE to avoid inadvertently 
   turning on uncooled lines.  No one should change this. 
B) Ladders in IB3 are offline.  This was done using the online 
   flag for FIB_50 and FIB_55.</pre>
<!-- Author: Chris Hill -->



<!-- Date: Wed Jun 19 03:13:25 2002 -->
<pre>Report from a short access: 
SB2W10 
	symptoms:	DVDD software protection trips. 
		Measured the width of FECLK to be 36-37 nsec  
			(standard) 
 
</pre>
<!-- Author: Gino -->


<!-- Date: Wed Jun 19 03:21:08 2002 -->
<b>Controlled Access</b><p> 
Changed the bias-shorting jumpers for three ISL supplies. 
<ul> 
<li>IB3W0 No longer has any shorting jumpers in it 
<li>IB3W1 Has shorting jumpers for L3 and L4 
<li>IB3W2 Has shorting jumpers for L0 and L1 
</ul> 
The resistances for each bias line on these three supplies were re-measured.  They are all symmetric except those which have been jumpered, they have a short between positive and reference (as they should.)<p>
<!-- Author: Napora -->


<!-- Date: Wed Jun 19 03:39:58 2002 -->
<pre>report from short access. Investigated light from e382.  
OBDV not present, rest of data seems to be fine. 
Need to fllow up at bore, but this may be fourth DOIM 
transmitter bit failure...</pre>
<!-- Author: Lester -->


<!-- Date: Wed Jun 19 03:41:12 2002 -->
<pre>report from short access. Investigated light from e382.  
OBDV not present, rest of data seems to be fine. 
Need to fllow up at bore, but this may be fourth DOIM 
transmitter bit failure...</pre>
<!-- Author: Lester -->


<!-- Date: Wed Jun 19 13:20:19 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-593&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-593  width='300' align='top'></td><td>New temp trip limits</a></td></tr></table>
<!-- Author: Andy H. -->

<!-- Date: Wed Jun 19 13:20:53 2002 -->
<p><font size=+1> Test E-log message from calibration framework </font>
<p><pre>
Test</pre>
<!-- Author: nielsenj -->
<!-- Comment: Wed Jun 19 13;21;47 comment by...same guy -->
Updated the e-log address in the calibration framework.


<!-- Date: Wed Jun 19 14:08:41 2002 -->
<pre>Integrating the silicon. 
SB0W3L3 (e033)	changed the HDI address from 8 to 24 INIT  
		BITSTREAM READBACK MASKED 
 
SB5W4L2 (e542)	changed the HDI address from 2 to 18 INIT 		 
		BITSTREAM READBACK MASKED 
 
SB3W8L2 (e382)	Was reintegrated yesterday for the studies during  
		the access and we forgot to kick it out. I did IT  
		now. 
 
</pre>
<!-- Author: Gino -->
<!-- Comment: Wed Jun 19 16;05;07 comment by...CH -->
<pre>During integration the following also occured:

LB1W5L3 removed from the HDWDB due to DVDD OV.

SB1W10L4 trips on bias (30V draws 1020 uA).
Trip limit raised to 5000 uA.
 </pre>
<!-- Date: Wed Jun 19 16:02:17 2002 -->
<pre>Prior to integration Andy and I worked on the insufficiently 
cooled lines:   
 
CCW1.2 
CCW2.1 
CCE1.1 
 
Trip temperatures temporarily raised to 25 deg. 
 
We powered on SVX,L00,ISL.  We did not coldstart (this would 
reduce power consumption due to ISEL settings) so these tests are  
conservative. 
 
CCW2.1  
------------ 
Turned on IB2W0L0,L1,L2,L3 and IB2W2L2,L3   
Inlet temp = 8.6, Outlet Temp = 16.8 after plateau. 
DeltaT is same magnitude as west line opened in Oct. 
While this is not understood, cooling appears sufficient. 
These ladders have been turned online in the HDWDB. 
 
CCE1.1  
------------ 
Turned on IB4W0L1,L3 IB4W4L3 and IB4W5L1,L3   
Inlet temp = 8.9, Outlet Temp = 16.1 after plateau. 
DeltaT is same magnitude as west line opened in Oct. 
While this is not understood, cooling appears sufficient. 
These ladders have been turned online in the HDWDB. 
   
CCW1.2  
------------ 
Turned on IB1W0L3 IB1W1L1,L3 and IB1W2L1,L3   
Inlet temp = 9.0, Outlet Temp = 23.7 after plateau. 
DeltaT is too large, we powering off ladders, starting w/those 
closest to the outlet RTD. 
Turn off IB1W2L3: Outlet Temp = 21.5 after plateau. 
Turn off IB1W2L1: Outlet Temp = 20.2 after plateau. 
Turn off IB1W1L1, L3: Outlet Temp = 17.0 after plateau. 
This circuit has insufficient flow to run more than one ladder. 
These ladders have been taken offline in the HDWDB. 
IB1W3L3 remains online in HDWDB.  It has partial cooling from 
circuit CCW1.1 
 
Trip temperatures reset to 20 deg.</pre>
<!-- Author: Chris Hill -->



<!-- Date: Wed Jun 19 18:58:19 2002 -->
<pre>fair amount of trouble today integrating the Silicon with CDF. 
 
What is the biggest problem we are dealing with is the fact 
that the total bytes count in VRBs do not always match the 
sum of the individual channels bytes count. 
I think this shows up as a Busy timeout. 
Furthermore there is a high rate of reformatter errors that I  
analized For run # 146832. Here is what I could figure out: 
 
1449 TOTAL number of reformatter errors 
 
43 Duplicate  	37 of them from e472 (reading e460) and  
		6  of them from e453 (reading e440) 
 
147 0xc1c4c4c4 all of them from e472 
 
1207 VRB word not consistent with the existing one 
		I believe this is the new kind of crap we have 
		Steve Nahn is going to work on this after dinner. 
 
Still missing 52 of them that I'm not able to locate yet. 
 
Maybe the two problems are correlated.  
We had the L3 people to implement a dump of informations for the  
interesting evts. We are going to look at it offline. 
 
</pre>
<!-- Author: Gino -->


<!-- Date: Wed Jun 19 23:47:53 2002 -->
<pre>PROBABLE DOIM FAILURE FOR SB5W4L2 
Here is the record from the PS logfile of the change in 
DOIM current last sunday 
 
New time 36335 Sun Jun 16 10:05:35 2002 
1384  0 -32767     5.39  1945.00  
New time 36706 Sun Jun 16 10:11:46 2002 
1384  0 -32767     5.39  1615.00 
 
New time 36677 Sun Jun 16 10:11:17 2002 
1383  0 -32765     1.93  1095.00 
New time 36706 Sun Jun 16 10:11:46 2002 
1383  0 -32765     1.92   935.00 
 
BAsically there is a step DOWN by ~1/6 at 10:11:xx 
 
Here is what we were doing at that time: 
 
Sun Jun 16 10:06:35 Run 146652 ACTIVATE 
Sun Jun 16 10:16:27 Run 146652 TERMINATE 
 
 
THIS COULD BE A COINCIDENCE BUT WE WERE RUNNING THE TORTURE TEST 
WHEN THE DOIM CURRENT DROPPED. 
THAT CURRENT NEVER CAME BACK and I CONSIDER THIS A PERMANENT FAILURE. 
Hopefully I'm wrong.</pre>
<!-- Author: Gino -->


<!-- Date: Thu Jun 20 00:54:06 2002 -->
<h3>Vrbs UnUpdated</h3> 
We undid this 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=113&frame=2&anchor=17:25:22'> 
Vrb firmware upgrade</a> which was suppossed to cut 2 microsecs 
off the readout time (out of 11) but it caused all sorts 
of errors, chiefly <ul> 
<li>SCPU errors where the total byte count is not the sum of the individual byte counts 
<li> BNK-VRBWRD RF errors where the TSL1A byte (sent on L1A) is mismatched but the Event number (sent on L2A) is not. 
</ul> 
With the old firmware we were able to run successfully but for 
a bad Glink 1 on b0svx08 Sl 18/ b0fib01 sl 12 IB2W0/W1 which causes DONE timeouts.  For the moment we disabled this 
Fib (in principle, one could just take out Channels 2,3,4 until 
the next controlled access when we can swap out the Glink). 
<P> 
We can now declare the Silicon re-integrated with COT, CCAL, PCAL, etc.  Just in time for them to drop the store...(sigh) 
 
  
<!-- Author: SCN -->


<!-- Date: Thu Jun 20 07:52:45 2002 -->
<pre>Bringing silicon in to run since MCR has no new store to put in  
and left old store in. Made new CAENvolts to reflect missing  
FIB_39. 
 
While powering external trip on b4w9, random single channel  
External trip. Came on again by itself? No message about repower- 
ing in GUI. 
 
</pre>
<!-- Author: Lester -->

<!-- Date: Thu Jun 20 13:04:07 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W5 L0 
<li>problem n: 32 
<li>Action: Diagnosis_update
<li>entered by: lmiller 
<li>description is: Looked at the FTM which came from here; the socket for bit 1+ of  channel 5 of this FTM has lost its insert. Will be given to ESE for repair when the other interesting RX's in it have been  studied. </ul>
<!-- Author: Problem DB -->
<!-- Comment: Thu Jun 20 15;53;50 comment by...Lester -->
<pre>Yeeha the elog entry thang is working again! Thanks to Nielsenj</pre>
<!-- Date: Thu Jun 20 14:42:28 2002 -->
<h3> Less and Less 00f3</h3> 
We did a quick study of the 00f3 firmware fix with the data taken 
last night.  We found in the worst offender from <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=113&frame=2&anchor=16:43:06'>before</a> e514 and with Chris's help verified that it is truncating the 00f3 after 8 identical bytes. 
We also confirmed that there was no sign of higher rate of reformatter error from the Fibs which were updated.  Given 
the Vrb debacle, and the fact that already SVT sees a big difference, we'd like to take a couple of stores to make sure that there is no PHYSICS implications of the firmware change 
before applying it everywhere. 
<!-- Author: SCN, Reid -->



<!-- Date: Thu Jun 20 16:17:49 2002 -->
<h3>Silicon Controlled Access report Phase 1</h3> 
I replaced Glink 1 of fib in b0fib01 Sl 12.  The Glink Synch errors reported by the VRB went away, and I tested with 
Fib2Vrb and also with the SRC sending triggers (no ladders on) 
and no sign of Glink Synch problems occured. They were  
constant independent of data taking state, so it appears 
this is fixed.
<!-- Author: SCN -->


<!-- Date: Thu Jun 20 18:34:20 2002 -->
<b>Controlled Access</b> 
<ul> 
<li>The Ovv on LB1W5 DVDD3 turned out to be the fault of the supply.  It was pulled and replaced.  The new supply was LB tested and passed ok <i><b>except</b></i> for VBias 3.0 which trips Unv when it should trip Ovc instead (it does still trip though.)  Since time was short the executive decision was made to use this supply, but not this bias line. 
<li>The crowbar was replaced for LB1W3.  Perhaps this will solve the problems with the bias line tripping. 
<li>A crowbar was put on the supply powering the pitWIB.  This is intended as a diagnostic tool to investigate the fuses blowing in the L00 crowbars.  I would like this supply left powered with the bias voltages at 120V for all channels as often as possible--even during shots. 
</ul><p>
<!-- Author: Napora, Mumford, Hill -->
<!-- Comment: Thu Jun 20 22;38;53 comment by...Gino -->
<pre>Can we turn ON a supply without any load on the CPC 2VDOIM?
I guess NOT so we ahve to think about this test.
</pre>
<!-- Date: Thu Jun 20 20:08:03 2002 -->
<pre>Commissioning ISL ladders on E2.1: 
 
Add ladders to HDWDB and input operating bias voltages.  
 
Slowly turn on IB3W0L0,L1,L2,L3 and IB3W2L2,L3. 
All ladders power ok, cooling is sufficient on this line, 
deltaT(outlet-inlet) = 1.4 deg C. 
 
Test IB3W2L2,L3 in SVXDAQ. 
Both ladders init OK. 
Ramp up bias OK. 
Take data (isl/ne/data/laser455.svx) OK. 
 
Test IB3W0L0,L1,L2,L3 in SVXDAQ. 
Ladders init OK, except L2 fails readback. 
Currents are initialized values for all ladders. 
Ramp up bias OK. 
Take data (isl/se/data/laser840.svx) get errors on L2. 
L2 has bit 3 stuck low. 
This is responsible for init failure and data errors. 
   
I have masked off init readback for IB3W0L2 in the HDWDB. 
 
These ladders are commissioned, all are online in HDWDB.</pre>
<!-- Author: Chris Hill -->

<!-- Date: Thu Jun 20 20:11:14 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0 L2 
<li>problem n: 514 
<li>Action: Init_RB_mask
<li>entered by: chill 
<li>description is: <pre>Bit 3 stuck low.</pre> </ul>
<!-- Author: Problem DB -->




<!-- Date: Fri Jun 21 13:01:13 2002 -->
<pre>Worked at FCC. 
Taken a L0 ladder that is running well. 
Removed Jumper connection for DGND without any impact on the performances. 
Removed Jumper connection for DVDD and we: 
1.	INITIALIZE CORRECTLY ALL THE TIMES. 
2.	When reading out we get the PHI chips perfect and for 
	the Z chips we get only CHIP ID, CAP ID (the correct one) 
	the first channel and its data and c2c2 termination 	 
	carachter. 
 
Typical event looks like  
DataBlock 142 
0238160b 10000000 04104100 02120000 00000000 00000000 00000000 00000000  
e0002cfc 8311002a 01380228 03390439 05290638 07390838 09290a38 0b2a0c28  
0d290e38 0f28102b 1138122b 133a142b 1528162b 17291838 19291a39 1b2b1c38  
1d381e38 1f3a2038 212b2229 23382429 25292639 27392828 29392a39 2b382c3a  
2d3b2e3a 2f283029 313a322a 33293428 3538363a 37383838 39383a29 3b383c38  
3d293e38 3f394039 4138422b 43384438 4529463a 47384839 49284a39 4b384c39  
4d284e28 4f29503b 5128522e 53285438 552a5639 57285839 59285a38 5b285c29  
5d3a5e2e 5f286028 61396239 63386428 652b662b 6738682b 69286a38 6b386c2b  
6d286e3b 6f287039 71387228 73387428 7528762b 772a7828 79297a28 7b2a7c2b  
7d287e28 7f288211 00380128 02390328 04280528 06380738 0838092b 0a3b0b28  
0c280d38 0e380f38 10281138 1228133b 14291538 16281738 18291938 1a3b1b2a  
1c391d38 1e281f28 202e2138 22382328 2438252b 2638273a 283b2939 2a382b38  
2c3a2d28 2e382f2b 30283128 3228333a 343a3529 3628372a 382b3928 3a2a3b38  
3c393d29 3e393f38 40284138 422a4338 4438452f 462b4738 48284938 4a2b4b28  
4c284d29 4e284f28 50295139 5228532a 5429553b 56285738 5838592c 5a385b3b  
5c385d28 5e285f39 60296138 62386338 64386529 66296729 682a6938 6a386b29  
6c296d2b 6e286f2a 70387128 7238732a 742a752e 7628772b 782b792b 7a2e7b2b  
7c2a7d2b 7e2a7f24 a111001e a011001a c2c20000 00000000  
 
Here is the behavior of the currents for the AVDD and DVDD: 
 
Condition		AVDD		DVDD 
 
perfect			354 mA		79 mA 
 
After removing DVDD 
connection to the Z side 
 
After Initialization	~470 mA		72-77 mA 
 
During readout		the analog current jumps up-down from  
			470 mA to as high as 560 mA 
			While the Digital current stays stable 
 
We then downloaded into the Z chips ISEL bits=0s and Rdriver  
bits=0 in order to minimize the Z side power consumption and we got: 
			400 mA		72-77 mA 
 
This Behavior is very similar if NOT identical to SB3W8L0 that  
is NOW NOT integrated because it trips on AVDD over current (the  
limit in CDF is at 500 mA and the PS cannot supply more than 600 mA). 
 
We will try between stores to minimize the current consumption on  
SB3W8L0 and see if we can get good data from the PHI side as we  
did on the bench. 
 
Maybe we can recover the PHI side of SB3W8L0 with the advantage  
of giving another usefull wedge to SVT and impact our trigger  
capabilities. 
 
Furthermore there is another device (SB4W9L4) with very similar  
symptoms that could be recovered (only the PHI side) in the same  
way. Let's see the outcome when we can apply the changes. 
 
IF all this works we clearly have another kind of JUMPER FAILURE. 
 
</pre>
<!-- Author: Cigdem & Gino -->
<!-- Comment: Fri Jun 21 13;13;00 comment by...Gino -->
<pre>I crosscheck the bonding diagram used here at SiDet and the DVDD 
and DGND bonds are always in pair (there are two bonds per 
connection) so it is very unlikely that the bonds are gone but 
more likely that the JUMPER FAILED. NOT A BIG SURPRISE.
Probably the edge of the VIAS are acting as SLOW BLOWING FUSES.
</pre>

<!-- Comment: Fri Jun 21 21;21;20 comment by...Gino -->
<pre>This approach has been applied to Sb3W8L0 and SB5W5L0.
Here is what we did:

Settings:	IdvddSb3W8L0	IdvddSB5W5L0 	IavddSB3W8L0 IavddSB5W5L0
Normal 
Bitstream	25		80		442		420
setting ISEL
bits to 0s
for chip 0	25		80		409		390
setting ISEL 
bits to 0s
for chip 1	25		80		371		363
Setting 
Rdriver bits
to 0s		NO CHANGE 	NO CHANGE	NO CHANGE	NO CHANGE
Setting BIAS 
RATIO SELECT
to 0s for 
chip 0		25		80		364		357
Setting BIAS 
RATIO SELECT
to 0 for
chip 1		25		80		358		352

The 2 LADDERS ARE NOW TAKING DATA HAPPILY AS FAR AS THE PHI SIDE 
IS CONCERN. THIS IS A STATEMETN THAT APPLIES TO TRIGGER RATE
WITHOUT ANY BEAM IN THE MACHINE. IT WILL BE VERIFIED AT HIGHER 
TRIGGERRATE ON THE NEXT STORE. THIS COULD IMPROVE THE 
PERFORMANCES OF OUR L2 TRIGGER (SVT).

THE JUMPER IS CLEARLY THE FAILURE MODE. 


</pre>
<!-- Date: Fri Jun 21 15:24:54 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W7 L2 
<li>problem n: 39 
<li>Action: Diagnosis_update
<li>entered by: lmiller 
<li>description is: Needs to have the light looked at since the RX swap seems to  have failed to see if there are internal issues.  </ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 21 15:53:24 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1 L2 
<li>problem n: 516 
<li>Action: Diagnosis
<li>entered by: lmiller 
<li>description is: Since the access began giving back garbage (no first chip.. could be garbled data) at a few percent rate and having reformatter errors. Needs light investigation. </ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 21 16:21:11 2002 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3 L3 
<li>problem n: 339 
<li>Action: Diagnosis_update
<li>entered by: lmiller 
<li>description is: Drops readout chip 85 almost 100% since access (was lower rate). Needs light investigation. </ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jun 21 18:23:03 2002 -->
Monitoring report for Run 146849 
<BR> 
 
<Pre> 
---------------------- 
chipconfigtest_146849 
---------------------- 
 
ILLEGAL BITS: SB3W3L4C10 has ISEL of 0x0 
ILLEGAL BITS: SB4W3L2C4 has ISEL of 0x0 
NON-STANDARD BITS: LB0W2L3C0 has ramp ped of 7 
 
****** RUN HAS ILLEGAL OR NON-STANDARD CHIP SETTINGS ****** 
 
---------------------------- 
adc distribution "anomalies" 
---------------------------- 
 
SVX: 
e033: adc bump.  chip 3 channel 111  
      <a href="http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=110&time=13:26:13"> here is an example </a> 
e052: adc bump.  chip 8 channel 52 
e100: adc bump.  chip 2 channel 77 
e1a3: adc bump.  chip 8 channel 79 
e1b1: adc bump.  chip 4 channel 33 
e224: adc bump.  chip 11 channel 72 
e250: for each chip only half the channels are read out. 
      DEM shows 100% erros.  Bit 6 stuck low. 
      See plots below. 
e283: sick. DEM shows 100% errors. c2c2c4 
e304: adc bump.  chip 10 channel 2 
e402: adc bump.  chip 9 channel 10 
e461: adc bump.  chip 4 channel 40 
 
ISL: 
f143: newly cooled. adc dist. looks strange. 
      chips 4-7 read all channels almost all the time. 
      other chips have no physics.  see plots below. 
      <a href="http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=112&time=05:00:32"> In e-log: </a> drew no bias0 current and were not depleted. 
      Need to add to pbdb. 
f153: newly cooled.  
      adc bump.  chip 4 channel 69 
f222: newly cooled.  chip 7, chip 10 some channels have 
      ped saturated at 240.  see plots below.   
      bias currents show no ibias0 and ibias1. 
f223: newly cooled.  just like f143. not in pbdb. 
f413: newly cooled.  same as above.  In pbdb. 
      <a href ="http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=112&time=17:29:48"> elog entry </a> 
f453: newly cooled.   
      adc bump.  chip 2 channel 117 
 
</Pre>  
<!-- Author: Eva H. -->


<!-- Date: Fri Jun 21 18:25:29 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_21_2002_182511.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-595  align='top'></td><td>First page:ADC distribution for e250 for run 146849. Second page: Pedestal vs. channel.   For each chip only half the channels are read out. Bit 6 stuck low. </a></td></tr></table>
<!-- Author: Eva H. -->


<!-- Date: Fri Jun 21 18:31:02 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_21_2002_183051.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-601  align='top'></td><td>First page: ADC distribution for f143 for run 146849.  Black =  all chips, colors = chips 4-7.  black distribution  on the left is chip 8 and shows no physics. All other chips (besides 4-7) are like this. Second page: ped vs. channel Third page: example event. Drew no bias current.</a></td></tr></table>
<!-- Author: Eva H. -->


<!-- Date: Fri Jun 21 18:33:42 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_21_2002_183314.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-603  align='top'></td><td>First page: adc distribution for f222 for run 146849. Second page: ped vs. channel Third page: sample event. For chip 7, chip 10 some channels have ped saturated at 240. Bias currents show no ibias0 and ibias1.</a></td></tr></table>
<!-- Author: Eva H. -->



<!-- Date: Fri Jun 21 21:59:13 2002 -->
<pre>Taken a few hours of cosmic to watch the behavior of SB3W8L0. 
The outdome is some reformatter errors here described: 
 
Total reformatter error  
	1037 
Duplicate fib IDs 
	22 
		18 of them are e453 
		2 of them are f024 
		2 of them are e472 
 
Detector ID not known (yet?) 
	1015 
 
	0xc1c4 ending up on the FIB header  
		623 
			623 of them (all) are e472 
 
			 21 of them are e074 
 
 
	WRONG FIB header  
	Example 
0xf2004afc  0xf2014afc  0x00000000  0xf2034afc  0xf2044afc  0xf2104afc  0xf2114afc  0xf2124afc  0xf2134afc  0xf2144afc 
 
		371 
			371 of them (all) from f202</pre>
<!-- Author: Gino -->