<!-- Title: 14:01:25  Mon Jul 21 2003 -->
<!-- Crewchief: Steve -->
<!-- Op1: some other people -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<h3>Current Activites</h3><ul> 
<li> Stack and Store and Stack and Store and... 
<li> Two SRC tests 
<li> PS oddities gone away? 
<li> How long will she go? 
<li> Prepare for shutdown 
</ul>  


<!-- Date: Mon Jul 21 14:41:12 2003 -->
<pre>Today we took from Silicon office and transferred to SiDet: 
- VRB S/N 142 EquipID #551016 
- FTM S/N 132 	      #565876 
- FIB S/N 134         #560619 
plus one MVME CPU sponsored by Bill Badget. 
Equipment will be used to build teststand @ Sidet. 
</pre>
<!-- Author: Rainer,Joong -->


<!-- Date: Mon Jul 21 18:36:14 2003 -->
Store 2810 in, but SVT plot not cooperating (will try again 
later).  Having intermittent L1 DONE timeout problems due 
to 2nd SRC operation.  Theorizing as to the cause, rate is 
not high enough to warrant removing the 2nd SRC.  Current thought 
is that there are occaisional L2 decisions that just take a long 
time, and the TS hits it's L1DONE timeout for the 2nd SRC before 
it can deliver the L2 message.  Need some proof...
<!-- Author: SCN -->


<!-- Date: Mon Jul 21 19:30:34 2003 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Jul_21_2003_193025.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2367  align='top'></td><td>SVT plot for store 2810.  Look!  Wedge e3a is back!</a></td></tr></table>
<!-- Author: Jason -->


<!-- Date: Mon Jul 21 21:06:22 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2368&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2368  width='300' align='top'></td><td>SVT plot, looks OK</a></td></tr></table>
<!-- Author: SCN -->


<!-- Date: Tue Jul 22 12:45:21 2003 -->
<h3>More on 2 SRC Mode</h3> 
We had L1 DONE timeouts roughly once every 10-50 minutes over night (See <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=607&frame=2&anchor=07:52:53.180'>main elog</a> and  <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=tsi&action=view&page=11&frame=2&anchor=23:58:26'>TSI elog</a>  
for discussion-it could either be an SRC problem or a TS problem or simply that the timeout isn't long enough.  However, it 
was also pointed out that the L1 DONE deadtime was quite high, 
and from the <a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/Level1Time?TABLE=LEVEL1_CONDITIONS&Y=L1DONEDEADTIME&WHERE='RC_RUNNUMBER=166479'&TITLE=L1DONEDEADTIME_Run_166479&XLABEL='seconds'&YLABEL='%''>plots</a> it looks like occassionally you have to wait a 
long time for the L1 DONE to come back, although it may not  
cause a timeout.<P> 
Today, because of low luminosity we decided to move L00 and ISL over to the 2nd SRC temporarily to see what else we might need 
to fix in Two SRC mode.  The running was ok, and shows definite  
improvement on the SVT tails (pictures to follow) but we still had Pipeline out of Synch where ISL and L00 were on one  
pipecell, and SVXII was on another.  The two SRCs are sending 
the CHIP RESET at the same time (picture to follow) so it appears 
something is wrong either with the pipe depth setting or some other delay in the SRC.  The Bunch crossings and Event IDs are in 
synch, so we seem to be getting the right buffers.<P> 
We put everything back in single SRC mode while we ponder this for a while. 
  
<!-- Author: SCN -->


<!-- Date: Tue Jul 22 12:48:24 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2369&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2369' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2370&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2370' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2371&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2371' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2372&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2372' width='300'></a></center>
<!-- Author: SCN -->
<!-- Comment: Tue Jul 22 12;49;09 comment by...SCN -->
<pre>Effect of 2 SRC Mode on SVT processing time.  First two plots 
are with 1 SRC, second are with 2 SRCs.</pre>


<!-- Date: Tue Jul 22 12:53:11 2003 -->
<center><a href='/elog/notebooks/silicon/Tue_Jul_22_2003_125249.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2374' ></a><a href='/elog/notebooks/silicon/Tue_Jul_22_2003_125300.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2376' ></a></center>
<!-- Author: SCN -->
<!-- Comment: Tue Jul 22 12;57;08 comment by...SCN -->
<h3>Comparison of CHIP_RESET signals</h3>
On the left, you can see that both SRCs receive the TS RECOVER
command (0xB) at the same time (the O marker) and send (or at least process)
the CHIP RESET (0x53) at the same time.  We did find that one SRC had the "L1 Delay" parameter set to 47 while the other one had it at
40, but we don't know what this parameter means.  Anyway, there is no evidence here for why the pipecaps would be out of synch.
We should <ul>
<li> Study the pipecap progression to see if it is a shift or if it is random (via daqana)
<li> Check to see if ISL/L00 had physics in this run.
</ul>


<!-- Comment: Thu Jul 24 15;09;55 comment by...SCN -->
Took my dump of 10 events from <i>/data1/svxData/offline/consDump/2SrcRaw.txt</i> and compared the Capacitor IDs for e000 (SVXII) with those of f001 (ISL/L00) and saw
<table>
<tr> <th> Event <th> SVXII <th> ISL/L00 </tr>
<tr><td>1 <td>27 <td>1b</tr>
<tr><td>2 <td>18 <td>15 </tr>
<tr><td>3 <td>0c <td>25 </tr>
<tr><td>4 <td>12 <td>26 </tr>
<tr><td>5 <td>26 <td>0d </tr>
<tr><td>6 <td>05 <td>2a </tr>
<tr><td>7 <td>20 <td>2b </tr>
<tr><td>8 <td>02 <td>1d </tr>
<tr><td>9 <td>21 <td>13 </tr>
<tr><td>10 <td>18 <td>1c </tr>
</table>
This doesn't look like they are shifted by any amount.  Talking with Lester, we think that it is very possible that long L2 decision times mean the keepalive supplants the L1 DONE as
shown in <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=tsi&action=view&page=11&frame=2&anchor=23:58:26'>the TSI elog</a>.  This woudl explain both the L1 DONE timeouts and (probably) the 
mismatched pipeline IDs.  One test we might do is try to run 
but disallow the keepalive, see if that is the cause. 


<!-- Date: Tue Jul 22 15:07:12 2003 -->
<b>Access Summary</b><p> 
Rainer and Stan went in to investigate SB2W5L2. The bit 0 high didn't show up in the pretest, but after swapping the DOIM cable with channel 6 (SB2W5L1) the bit 0 high problem appeared in the DAQ channel (7). There were no errors after swapping back. Channel 7 should be monitored to see if the bit 0 high shows up again. We only had about 40 minutes so it was decided that nothing be done to this guy until we know for sure if the problem comes back.
<!-- Author: David, Rainer, Stan -->


<!-- Date: Wed Jul 23 09:41:46 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2378&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2378' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2377&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2377' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2379&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2379' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2380&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2380' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2381&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2381' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2382&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2382' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2383&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2383' width='300'></a></center>
<!-- Author: SCN -->
<!-- Comment: Wed Jul 23 09;43;40 comment by...SCN -->
<pre>IB0W4L0 has had a lot of pinkie on DVDD.  Looks like fairly high occupancy on the Z side of one of the ladders, probably since BiasRatio change.  Soon we should address the thresholds, but 
for now I'll change the IMON high limit, which is currently at 405.</pre>

<!-- Date: Wed Jul 23 10:30:02 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W3L0 
<li>problem n: 1027 
<li>Status: needs_access
<li>Type: RX
<li>Action: Diagnosis_update
<li>entered by: nahn 
<li>description is: Bit 0 error is back, since 7/7/03, but sporadic (see bit reporter) Not critical, can wait for shutdown if necessary (doesn't affect trigger, fixed in offline) 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B0W3&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jul 23 11:31:13 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L4 
<li>problem n: 1082 
<li>Status: needs_access
<li>Type: RX
<li>Action: Incident
<li>entered by: nahn 
<li>description is: Bit 0 Low 100% since run 166367 7/19/03.  No obvious cause. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jul 23 14:08:54 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2384&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2384' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2385&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2385' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2386&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2386' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2387&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2387' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2388&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2388' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2389&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2389' width='300'></a></center>
<!-- Author: SCN -->
<!-- Comment: Wed Jul 23 14;16;28 comment by...SCN -->
IB1W4L0 (aka B1 Ladder 24) Red in SVXMon for high occupancy
on Z side.  Indeed, it seems pretty high-potential threshold adjustment?


<!-- Date: Wed Jul 23 14:21:27 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2390&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2390' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2391&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2391' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2392&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2392' width='300'></a></center>
<!-- Author: SCN -->
<!-- Comment: Wed Jul 23 14;24;25 comment by...SCN -->
SB0W1L0 has one chip Red in SVXMon for High Mean Charge and
High RMS Charge (not sure which).  Occupancy seems a little low?  Known to be flaky AVDD2, is this another symptom?

<!-- Comment: Tue Aug 26 15;35;47 comment by...David -->
Typo in above comment - this ladder is SB1W0L0.
<!-- Date: Wed Jul 23 14:26:18 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W0L0 
<li>problem n: 604 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: nahn 
<li>description is: Red in SVXMon for anamolous ADC behaviour, see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=164&frame=2&anchor=14:21:27'> elog</a>.  Is this another symptom of AVDD2?  
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jul 23 16:08:47 2003 -->
<h3>Quench</h3>  Post Checkout ok (b0fib02's messenger died 
at some point, and it needed repartitioning).  <H1>I temporarily moved the PS GUI back to b0dap42 so that b0dap44 can be taken down and moved to the control room</h1>
<!-- Author: SCN -->


<!-- Date: Wed Jul 23 16:11:39 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2393&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2394  width='300' align='top'></td><td>SVT plot for last store.  Looks fine</a></td></tr></table>
<!-- Author: SCN -->


<!-- Date: Wed Jul 23 17:15:18 2003 -->
<h3>SVXMon survery</h3> 
I spent some of the morning looking at SVXMon, determining what was red and why.  Here are my results 
<table>  
<tr> <th> Hunk of Si <th> Map <th> Cause <th> Action </tr> 
<tr><td> IB0W0L0 All<td> Cell ID  <td> Bit 3 known low <td> Needs Bore investigation </tr>  
<tr><td> IB1W4L0 Z<td> Status  <td> High Occupancy<td> Suggest threshold tuning </tr>  
<tr><td> IB5W5L1 2nd ladder<td> Cell ID  <td> Second ladder in HDI has bit 1 low <td> Mask it in <FONT COLOR=ORANGE>SVXMon</FONT>?<BR>Gold pin RX in shutdown </tr>  
<tr><td> LB0W3L0 <td> Status <td> Bit 0 low <td> Needs access, but not high priority </tr>  
<tr><td> SB0W3L4 Few Phi Chips <td> Cell ID <td> Bad Command signals <td> Timing cable investigation </tr>  
<tr><td> SB0W4L3 Z <td> Cell ID <td> Bit 7 stuck high <td> RX swap in shutdown.  Mask in <FONT COLOR=ORANGE>SVXMon</FONT>? </tr>  
<tr><td> SB1W5L2 Phi<td> Cell ID<td> Bit 5 high (again) <td> Verify internal, Mask in <FONT COLOR=ORANGE>SVXMon</FONT>? </tr>  
<tr><td> SB2W7L1 <td> Cell ID<td> No Light bit 1<td> Mask in <FONT COLOR=ORANGE>SVXMon</FONT>? </tr>  
<tr><td> SB2W8L4 <td> Cell ID <td> Bit 0 low 100% sinc 7/19  <td> Suggest RX Investigation/Swap </tr>  
<tr><td> SB2W9L4 <td> Cell ID <td> Bit 2 high since 7/17 <td> Suggest RX Investigation/Swap</tr>  
<tr><td> SB3W1L4 Phi <td> Status <td> High Occupancy <td> Needs more threshold tuning (or limit tuning?)</tr>  
<tr><td> SB1W0L0 <td> Status <td> Mean Charge/Std Dev out of Limits b/c of AVDD2 <td> Mask in <FONT COLOR=ORANGE>SVXMon</FONT>?</tr>  
<tr><td> SB4W6L3 <td> Cell ID <td> No light Bit 3<td> Mask in <FONT COLOR=ORANGE>SVXMon</FONT>? </tr>  
<tr><td> SB2W10L4 Phi<td> Status <td> "High" Occupancy (just barely)<td> Tune <FONT COLOR=ORANGE>SVXMon</FONT> </tr>  
</table> 
Some of these things are new problems now on the access list.  Others should <FONT COLOR=ORANGE>either be masked off in SVXMon as a known problem, or SVXMon should have some limits tuned because it isn't really a problem</FONT>.  I will try to do this during my last pager week.
<!-- Author: SCN -->


<!-- Date: Wed Jul 23 21:56:09 2003 -->
<h3>L00 PS goes nuts</h3> 
Got paged because, out of nowhere with nothing going on, LB1W0 PS got a 5V DOIM overcurrent trip, which took down the whole wedge.  
Shift Crew attempted to recover, but got the same trip.  I came, tried to turn on just the PC, got a Internal Trip, but tried again and it seems to be staying up.  I turned all ladders to STANDBY individually (L2 and L3 tripped on DVDD once, but the second time seem ok) and now all is well.  Glad I didn't have to 
power cycle the rack (it is Crate 15, one of the unhockerables).
<!-- Author: SCN -->


<!-- Date: Thu Jul 24 07:34:03 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2395&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2396  width='300' align='top'></td><td>Paged for SB3W6L2 pink on Bias.  Looks like leakage current  just taking crossing the boundary.  Will adjust upper limit to 500 uA. <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=613&frame=2&anchor=07:31:07.339'> Short term history</a> in Main elog. </a></td></tr></table>
<!-- Author: SCN -->



<!-- Date: Thu Jul 24 16:24:05 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2397&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2397  width='300' align='top'></td><td><h3>Store Lost</h3> Post quench  (though it was not a quench) Checkout OK.  RF station lost about 10 minutes before the store, but ABORT Gap already swept out by TEL.  This is the SVT plot for the Store, looks OK.</a></td></tr></table>
<!-- Author: SCN -->


<!-- Date: Thu Jul 24 16:30:51 2003 -->
<pre>setup fer; ~wittich/bin/reload_alpha.sh</pre>
<!-- Author: Shazaam -->


<!-- Date: Thu Jul 24 22:47:34 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2398&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2398  width='300' align='top'></td><td>Next Store, SVT plot looks good.  Had a reoccurance of the <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=164&frame=2&anchor=21:56:09'>LB1W0 trip</a> during Proton load-same symptoms, same fix.  Else things are OK. </a></td></tr></table>
<!-- Author: SCN -->


<!-- Date: Fri Jul 25 13:28:32 2003 -->
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=164&frame=2&anchor=21:56:09'>This LB1W0 PS tripped again</a>, according to Gino just as he closed netscape. 
Coincidence?  I think so.  Anyway, he recovered it with no troubles.  I think it is time we reboot this rack after the next store. Also noted in <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=617&frame=2&anchor=12:46:29.844'>Main log</a>.   
<!-- Author: SCN -->


<!-- Date: Sat Jul 26 07:54:14 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2399&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2399  width='300' align='top'></td><td>SVT for store 2821.  Trigger conditions OK</a></td></tr></table>
<!-- Author: SCN -->


<!-- Date: Sat Jul 26 12:12:18 2003 -->
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=620&frame=2&anchor=11:04:00.994'> 
LB0W1</a> tripped on 5V DOIM again.  It recovered after some work, but we will remove this guy on the next CONFIG.  HDWDB and CAENVolts file generated, ace left with instructions.  I will 
try to recover it by rebooting the rack between stores. 
 
  
<!-- Author: SCN -->

<!-- Date: Sat Jul 26 12:16:39 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W0All 
<li>problem n: 1084 
<li>Status: needs_work
<li>Type: VDOIM
<li>Action: Removed_hdwdb
<li>entered by: nahn 
<li>description is: Frequent 5V DOIM trips, so will be removed for the rest of this store until we can try to solve the problem permenantly. 
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=L00&wedge=B1W0&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Jul 26 12:30:38 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2400&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2401  width='300' align='top'></td><td>Nothing very odd about 5VDOIM currents on LB1W0 in the last month or so...</a></td></tr></table>
<!-- Author: SCN -->
<!-- Comment: Sat Jul 26 23;27;08 comment by...SCN -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=621&frame=2&anchor=23:02:43.069'>Reset the Rack</a> so now the wedge is back in. 



<!-- Date: Sun Jul 27 16:56:09 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2402&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2403' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2404&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2405' ></a></center>
<!-- Author: SCN -->

<!-- Date: Sun Jul 27 16:58:03 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L1 
<li>problem n: 1085 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: Incident
<li>entered by: nahn 
<li>description is: Moved upper limit from 440 to 460, left variance of 10. Will look at occupancies later.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=164&frame=2&anchor=16:56:09'>elog</a>   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Jul 27 23:20:48 2003 -->
<h3>Even More on 2 SRC Mode</h3> 
After discovering (again) that the SRC that was in the diagnostic 
crate ("Doc") does not function, I removed the SRC in b0svx06 and 
put it in the diagnostic crate for testing.  I found that in 
both normal mode and tracer Mode it does not send the 
keepalive signal anytime between a L1A and the corresponding L1DONE, but it does send it outside of this restriction.  This 
should keep the keep alive from interfering with the normal L1DONE.  I managed to test it with the L2 Processors in 
a torture test (only the WiR silicon) and had no L1 DONE timeouts, even with the keepalive period set ridiculously small.<P> 
However, another change to handle the <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=161&frame=2&anchor=17:23:28'>VRB header corruption</a> has made it impossible to test the SRC without connecting it to a VRB and readout.  This means one cannot have just the SRC and the TS protocols excercised, because the SRC will hang up in its state machine waiting for a Scan Busy signal from the VRB.  I asked Sal and Lester to have another go at  
making a disable for this feature available so we can test the second SRC and the TS in a real run without having to put some 
Silicon on it.  Once this is done, we're ready to start testing things again.
<!-- Author: SCN -->


<!-- Date: Sun Jul 27 23:40:34 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2406&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2406  width='300' align='top'></td><td>SVT for last store (a little late).  PS-the link off the Silicon Expert page for the gif files works again!</a></td></tr></table>
<!-- Author: SCN -->


<!-- Date: Mon Jul 28 07:50:26 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2407&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2407  width='300' align='top'></td><td>SB1W3L4 VBIAS <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=625&frame=2&anchor=07:06:19.747'>trips this morning</a>. Looks kinda bad.  Need some quiet time to look at it.</a></td></tr></table>
<!-- Author: SCN -->

<!-- Date: Mon Jul 28 07:54:30 2003 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L4 
<li>problem n: 329 
<li>Status: needs_study_time
<li>Type: BIAS
<li>Action: Removed_hdwdb
<li>entered by: nahn 
<li>description is: Tripped on VBIAS again, 3 times without chance of recovery. <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=164&frame=2&anchor=07:50:26'>See elog</a>   
<li>See <a href="http://nkek15.fnal.gov/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jul 28 07:59:40 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2408&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2408  width='300' align='top'></td><td>SVT plot for store 2826.  Looks ok.  Note SVXMon has sb1w3l4 as YELLOW because we removed it post-CONFIG and didn't feel like spending  another 5 minutes of deadtime.  Should clear up at next CONFIG.</a></td></tr></table>
<!-- Author: SCN -->


<!-- Date: Mon Jul 28 08:31:33 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2409&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-2409  width='300' align='top'></td><td>I think the longer readout times etc in ISL come basically from higher occupancy in the Wings.</a></td></tr></table>
<!-- Author: SCN -->