<!-- Title: 11:08:42  Mon Aug 16 2004 -->
<!-- Crewchief: Stan Forrester -->
<!-- Op1: Florencia Canelli -->
<!-- Op2: Marcel Stanitzki -->
<!-- Op3: Antonio Boveia -->
<!-- Op4: Reid Mumford -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Last week before shutdown. 
 
Waiting for beam after Tevatron power problem.  Silicon was  
running in free run mode.  Tried to shift to CDF clock but  
experienced problems. Clock expert called in.  Recovered SVX  
trips. SB2W8L0 continued to trip.  Several attempts at trip  
recovery did not work.  Hockerized SW bot bot, still nothing.  
While attempting to adjust start up current limits handshake  
problem encountered.  Svxinter rebooted on this indication.   
PSGui and Imon restarted.  SB2W8L0 tripped twice more and  
stayed in stby on third attempt. 
 
 
 
 
Quote of the week: "In the beginning there was nothing. God said, 'Let there be light!' And there was light. There was still nothing, but you could see it a whole lot better."-- Ellen DeGeneres</pre>


<!-- Date: Mon Aug 16 11:12:10 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4907&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4907  width='300' align='top'></a></td><td>snapshot for IMON just after inital trips this morning.</td></tr></table>
<!-- Author: ssf -->


<!-- Date: Mon Aug 16 18:33:21 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4908&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4909  width='300' align='top'></a></td><td>SVT spymon for store 3736 / run 186302 with lumi 60E30</td></tr></table>
<!-- Author: Rong-Shyang -->

<!-- Date: Mon Aug 16 21:04:43 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 366
Calibration type  : standard
Run period tag    : Aug_2004
DPS-off run       : 186236
DPS-on run        : 186235
Requested by      : Jason Nielsen
Main process id   : 43343491
Comment           : resubmit
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Mon Aug 16 21:07:38 2004 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 366 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 186236
DPS-on run       : 186235
Requested by     : Jason Nielsen
Submitted        : 2004-08-16 21:04:38
Completed        : 2004-08-16 21:06:34
Status           : FAILURE
Comment          : resubmit

Last processing stage reported : checking silicon configuration
Failure diagnostics :
Beam info for run 186236 is not in the database. Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->
<!-- Comment: Wed Aug 18 10;36;40 comment by...Jason -->
<BR>
Yes, indeed, there were no data about the beam conditions in the online database from Aug. 13 - Aug. 16, and these runs were taken on Aug. 14.<BR>
I've contacted the online DB group and asked them to insert this information manually into the beam conditions database so that we can process this calibration job.
<!-- Comment: Tue Aug 24 15;03;48 comment by...Jason -->
OK, Bill Badgett has done this now.
<!-- Date: Tue Aug 17 17:46:46 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Tue_Aug_17_2004_174627.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4911  align='top'></a></td><td>e500 bit 3 high for 0.5 pb^-1 physics run 186302.  See pdb.</td></tr></table>
<!-- Author: boveia -->

<!-- Date: Tue Aug 17 17:50:24 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W0L0 
<li>problem n: 647 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Bit 3 high problem came back for run 186302 only.  monitor for recurrence. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Aug 17 19:25:26 2004 -->
L2 pulsar test today. Refer <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=612&frame=2&anchor=11:32:31.747'>here</a>. 
<pre>
- Tend to have Pulsar test with test SRC Steve and Marcel setup up last Friday, but failed. The trigger suppervisor didn't get L1D from test SRC. Apparently there is some setting (one register bit?) needed to be set and only Steve and Greg know how to do it, but they are both out of town. 
- So since the new trigger table has been tested with no silicon; pulsar with test SRC combination has been tested. we just go to 
- new tigger table with silicon but still Alpha making L2 desision. 
- change prescale to have L1 at 1KHz 
- change Alpha to Pulsar with 1KHz L1A, then gradualy increase L1A rate to 12KHz by releasing prescale. 
- The test was done ok. There was some struggle on starting SVXMon due to the output of the test is StreamI only. we swich to runSVXMon_allstream.tcl and could log events but due to different expectation of mean charge lots of cells show red. Checking at detail on plots (occupancy, mean charge and rms charge), we conclude silicon was running fine. 
 
</pre>
<!-- Author: Gino, Marcel and Rong-Shyang -->
<!-- Comment: Tue Aug 17 20;07;44 comment by...Get Smart -->
There is no secret register in the TS.  This theory is <b>wrong</b>.  There is a possibility that a CONFIG after the CONFIG for this partition wipes out a register, but if you have the whole system, this is rather unlikely.  A look in the TSI log, a call to Badgett or Andrew Martin or Michael Schmidt or Ke Li might have helped discover the so-called "secret" register, but I think perhaps it was something not related?  Many CONFIGs
in a row worked during the "no-beam" tests...

<!-- Comment: Tue Aug 17 23;09;49 comment by...Rong-Shyang -->
<pre>Marcel talked to Andrew (Martin?) and was told that one register has to be set. So the theory is from him. We also were told that it can be done by using something like Golbal L2 Gui ... But we didn't even want to try and lead to more trouble.</pre>

<!-- Comment: Tue Aug 17 23;56;45 comment by...Marcel -->
I talked to Andrew Martin and he said in order to use the L1DONE line from the back it has to be switched. We checked the TSI elog and found an entry how to swap the RXPT cables, which we did not do. 
Obviously, it was not enough to include the tstsvx1 crate in the config in it was working then.  L1DONE was sent correctly by the SRC and at some point we decided not to waste more beam time on this, since we already new the behaviour of the test SRC with the Pulsar crate.<br>
My point is:<br>
Since we did not touch the SRC crate at all and did not do anything different concerning including the crates, we concluded, this must be the TSI. And obviously, since there was no difference there, something is <b>NOT</b> set correctly in the TSI. And in the TSI elog Jonathan did not find anything concerning this. 





<!-- Date: Wed Aug 18 04:21:09 2004 -->
<pre>Called in for Ifix ISL cooling warning. TE-CCW1-2OUT reads 19.2 C.  Warning level is 19 C Alarm level is 20 C.  Silicon Cooling (Mircea) coming in.   
 
Shift crew running with out silicon right now. 
 
CC WEST 1 Temps all show a small jump about 12:30 to 1:00 a.m.but no drastic jump.  </pre>
<!-- Author: stan -->
<!-- Comment: Wed Aug 18 04;44;59 comment by...stan -->
<pre>ISL Chiller system, chiller output temp increased by around 0.4 C around 1233 this morning.  Many temps in the ISL cooling system jumped at that point, but TE-CCW1-2OUT jumped into the warning state which gave us the warning.

Chiller output set point is 6 C and the actual temp is now 7.9 C.  By contrast the same indication in SVX has a  -6 C set point and an actual reading of -6.3.

I O.K.ed silicon to be included in the run while Mircea continues to investigate exactly what is going oin with the chiller.

</pre>
<!-- Date: Wed Aug 18 04:22:43 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4913&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4913  width='300' align='top'></a></td><td>Temp.</td></tr></table>
<!-- Author: Mark -->
<!-- Comment: Wed Aug 18 04;23;44 comment by...stan -->
<pre>ISL CC West 1 cooling plots</pre>



<!-- Date: Wed Aug 18 04:46:38 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4914&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4914  width='300' align='top'></a></td><td>snapshot</td></tr></table>
<!-- Author: rslu -->


<!-- Date: Wed Aug 18 05:09:11 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4915&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4915  width='300' align='top'></a></td><td>SVTspymon plot for current run</td></tr></table>
<!-- Author: stan -->


<!-- Date: Wed Aug 18 05:14:21 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4916&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4916' width='300'></a></center>
<!-- Author: Rong-Shyang -->
<!-- Comment: Wed Aug 18 05;18;10 comment by...Rong-Shyang -->
<pre>In the snapshot, you can see the TE_CHSUP (left side) is running at 7.8~8C while the setting is 6C.</pre>
<!-- Date: Wed Aug 18 05:15:48 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4917&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4917' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4918&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4918' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4919&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4919' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4920&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4920' width='300'></a></center>
<!-- Author: Rong-Shyang and Stan -->
<!-- Comment: Wed Aug 18 05;17;14 comment by...Rong-Shyang -->
<pre>All the ISL temp got raised (also east side) at midnight.</pre>



<!-- Date: Wed Aug 18 06:54:39 2004 -->
<pre>Update on the ISL cooling problem: The water temperature from 
the chiller is coming warmer than the set point. We suspect a 
pen valve in the system is blocked, so the amount of heat 
carried away is limited. I tried lowering the chiller set point 
temperature, without any success. Immediate plans: Bill N. is 
trying to contact an expert which should be here in few hours. 
Keep you updated...</pre>
<!-- Author: Mircea Coca -->


<!-- Date: Wed Aug 18 06:56:42 2004 -->
<h3> Another Pulsar test</h3> 
We did another Pulsar test this night. We proceeded in the following sequence: 
<ol> 
<li> Alpha driving, no Silicon </li> 
<li> Pulsar driving, no Silicon </li> 
<li> Alpha driving, with Silicon </li> 
<li> Pulsar driving, with Silicon </li> 
</ol> 
we adjusted the prescale, so that we were running first at 9 khz and than go up to 21 kHz. Test was successful. 
<!-- Author: Marcel,Rong-Shyang and Ted, Burkhard -->


<!-- Date: Wed Aug 18 06:58:32 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4921&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4921  width='300' align='top'></a></td><td>Current of AVDD of e574.</td></tr></table>
<!-- Author: Rong-Shyang -->


<!-- Date: Wed Aug 18 06:59:03 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4922&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4922  width='300' align='top'></a></td><td>current of AVDD of e551</td></tr></table>
<!-- Author: Rong -->


<!-- Date: Wed Aug 18 07:03:36 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4923&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4923  width='300' align='top'></a></td><td>current of avdd of f500</td></tr></table>
<!-- Author: Rong -->

<!-- Date: Wed Aug 18 07:13:44 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W7L4 
<li>problem n: 1329 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: rong 
<li>description is: Imon limit change, see<a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=209&frame=2&anchor=06:58:32'> here</a><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1090</td><td>1100</td></tr>
<tr><td><b>Lower</b></td><td>1070</td><td>1090</td></tr>
<tr><td><b>Upper</b></td><td>1100</td><td>1110</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W7&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Aug 18 07:15:22 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L1 
<li>problem n: 1330 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: rong 
<li>description is: Imon limit change, see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=209&frame=2&anchor=06:59:03'> here</a><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>525</td><td>530</td></tr>
<tr><td><b>Lower</b></td><td>515</td><td>520</td></tr>
<tr><td><b>Upper</b></td><td>530</td><td>535</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Aug 18 07:16:35 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L0 
<li>problem n: 1331 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: rong 
<li>description is: Imon limit change, see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=209&frame=2&anchor=07:03:36'> here </a><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1105</td><td>1115</td></tr>
<tr><td><b>Lower</b></td><td>1080</td><td>1110</td></tr>
<tr><td><b>Upper</b></td><td>1115</td><td>1120</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Aug 18 09:44:08 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4924&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4924  width='300' align='top'></a></td><td>Current for avdd for f030</td></tr></table>
<!-- Author: Rong-shyang, Petra -->

<!-- Date: Wed Aug 18 09:47:48 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L0 
<li>problem n: 1332 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: rong 
<li>description is: Imon change, see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=209&frame=2&anchor=09:44:08'> here</a><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1065</td><td>1075</td></tr>
<tr><td><b>Lower</b></td><td>1030</td><td>1060</td></tr>
<tr><td><b>Upper</b></td><td>1075</td><td>1085</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=L0">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Wed Aug 18 13:48:15 2004 -->
Chiller expert adds freon to ISL chiller because a leak is suspected. We were just up to the alarm level of 20C when he did that and the temperature came quickly down again. Last time I looked it was down to 17C.  
 
Let's watch this to find out how big the leak is and then repair it during the shutdown...
<!-- Author: Petra -->
<!-- Comment: Wed Aug 18 13;51;00 comment by...Petra -->
Ah ja and apparently the sono alarm did not go off although one of the temperatures went up to 20C... Mircea, could you verify how this could happen?



<!-- Comment: Thu Aug 19 08;21;40 comment by...stan -->
Temp did not quite reach the 20.0 C level topped out at 19.88 C. <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=209&frame=2&anchor=08:17:34'>
see plot</a> with temperature indications here.
<!-- Date: Wed Aug 18 16:22:53 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4925&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4925  width='300' align='top'></a></td><td>Recent temp history of CCW1 </td></tr></table>
<!-- Author: stan -->


<!-- Date: Wed Aug 18 17:47:31 2004 -->
<center><a href='/elog/notebooks/silicon/Wed_Aug_18_2004_174631.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4927' ></a><a href='/elog/notebooks/silicon/Wed_Aug_18_2004_174644.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4929' ></a><a href='/elog/notebooks/silicon/Wed_Aug_18_2004_174656.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4931' ></a><a href='/elog/notebooks/silicon/Wed_Aug_18_2004_174714.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4933' ></a></center>
<!-- Author: Marcel -->
<!-- Comment: Wed Aug 18 17;57;24 comment by...Sebastian, Lashkar, SCN, Marcel -->
<h3> SRC: Fib Abort before L1DONE</h3>
This afternoon we spent some time understandingthe behaviour of the SRC concerning the following situation:
<ol>
<li> L1A </li>
<li> Digitize, Readout sent to the FIB </li>
<li> READ_BUSY goes high </li>
<li> You receive a L2R before the FIB/chips are done with Digitize</li>
</ol>
By Construction, the SRC should send FIB_ABORT on receiving L2R if READ_BUSY is high, but only after the L1DONE.<br>
Why does this matter. The SVT people are planning to spy on L1 Trigger bits, if they do not see any tracks from L1, they would L2R immediately ... reducing the L2 decision time significantly.
If you happen to send a FIB_ABORT during Digitize, very bad thing happen (SCN), so you would like be sure, the SRC behaves as the state machine says<br>

We first checked how things are looking using the SRC in Automatic Trigger mode. In this mode, the L2R is sent only after the Read_BUSY goes low. (First plot from left). As READ_BUSY is already low, there are no FIB_ABORT commands.
Then we tweaked the TSI emulator of the SRC to send the L2R after Digitze or READOUT (plot 2,3). Now you starting to see FIB_ABORT (0x41), but still they are only send after L1DONE.<br>
So far so good. Then we decided to look for a FIB_ABORT before a L1DONE, knowing, if this happens, it would be pretty rare.<br>
So we measured the time between FIB_ABORT and L1DONE, knowing, it has to be always like 25 mus, if things are right, because we refer to already the next L1DONE. In like 3 million events, we did not see anything like this. (Plot 4). <br>

At this point Steve joined in and made a fancier LA trigger to catch these things and we will keep running it over the night.








<!-- Comment: Thu Aug 19 09;55;23 comment by...Marcel -->
<h4> Update </h4>
After 1E9 L1A accepts, there has been no incident, where a FIB_ABORT was before a L1DONE.
I think, the SRC performs as expected.

<!-- Comment: Thu Aug 19 10;52;14 comment by...sebastian -->
<br>
The RSM firmware (v23r12 aka 33) only allows FIB ABORTS after PRD2s, ei, after the digitization of the data has been compleated. 
If then a L2R comes in while in RD_BUSY then the SRC sends an abort to the FIBs. Note that a PRD2 implies a L1_DONE (return capacitor to the pipeline). Of course the test is needed...
<br>
<!-- Comment: Thu Aug 19 10;54;08 comment by...sebastian -->
<br>
The documentation is not correct (it claims FIB aborts can be send during digitization), have to correct this in the new doc.
<br>
<!-- Comment: Thu Aug 19 13;29;58 comment by...sebastian -->
<pre>Learned from Steve and Marcel that one can shorten the digicounter (in state 9) and generate a L1_DONE duting digi and thus a FIB abort during digi (see Steve's entry further down). </pre>
<!-- Date: Wed Aug 18 19:11:57 2004 -->
<pre>Following the ISL Chiller problem from this morning:  
An expert was brought at noon and found that the chiller was  
low on charge; he charged it and the ISL chilled water 
temperature is back to the nominal point (6 C).  </pre>
<!-- Author: Mircea Coca -->


<!-- Date: Thu Aug 19 08:17:34 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4934&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4934  width='300' align='top'></a></td><td>CCW1-2Out high temp reached 19.88 rather than the 20.00 alarm level.</td></tr></table>
<!-- Author: stan -->


<!-- Date: Thu Aug 19 09:29:21 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W2L1 
<li>problem n: 1282 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: rong 
<li>description is: ADCMon shows resonable distribution in 186352. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->







<!-- Date: Thu Aug 19 14:05:25 2004 -->
<center><a href='/elog/notebooks/silicon/Thu_Aug_19_2004_135923.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4936' ></a></center>
<!-- Author: SCN, Marcel, Sebastian, Lashkar, Gino -->
<!-- Comment: Thu Aug 19 14;13;01 comment by...The gang -->
<h3>Testing Fib Aborts</h3> 
SVT wants to stop processing the Silicon data as soon as possible if it turns out that SVT triggers will not be used in a particualr event, which means that it we might finally see a L2R before the Silicon is done with READOUT, such that the SRC will send the
FIB ABORT (FIB1  = 0x41 at the SRC, FCMD = 0x01 at Fib backplane)
signal.  The SRC sends this if it has a L2R and sees the READBSY signal still high. So, we used the test crate to test a few things <ul>
<li> First, the SRC should never send a FIB ABORT during DIGITIZE, or more precisely, before it's L1DONE counter has expired.  To test this, we told the SRC to send L2R during DIGITIZE, using the "Fake readout" to give a long READBSY signal, and spying on the BE CLOCKs coming out of the FTM to see
what the Fib is doing.  Here you see after the L1A a L2R about 2 &#956;s later, but the FIB ABORT signal at the O marker 14.94 &#956;s 
just after the L1DONE signal.  In this case the Fib was in fact truncating READOUT only after a few clocks.  <P>
The upshot is we looked both in the firmware and tested the hardware for the SRC sending ABORT before L1DONE and never saw it, so it looks ok (more to follow).


<!-- Comment: Thu Aug 19 14;13;19 comment by...    -->
<pre></ul></pre>

<!-- Comment: Thu Aug 19 14;13;38 comment by...  -->
</ul>


<!-- Date: Thu Aug 19 14:14:24 2004 -->
<center><a href='/elog/notebooks/silicon/Thu_Aug_19_2004_135938.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4938' ></a></center>
<!-- Author: The gang -->
<!-- Comment: Thu Aug 19 14;17;18 comment by...Tutti Mundo -->
In this case, we wanted to see what the FIB does if it actually
recieves a FIB ABORT during the DIGITIZE loop, so we artifically
set the L1DONE counter short.  Now the FIB ABORT (O Marker) comes
only 3.7 &#956;s after the L1A, during the DIGITIZE.  It appears the
FIB still completes the whole DIGITIZE sequence, giving us an added sense of security that even if the SRC does send it, the FIB ignores it.


<!-- Date: Thu Aug 19 14:18:55 2004 -->
<center><a href='/elog/notebooks/silicon/Thu_Aug_19_2004_135951.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4940' ></a><a href='/elog/notebooks/silicon/Thu_Aug_19_2004_140013.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4942' ></a><a href='/elog/notebooks/silicon/Thu_Aug_19_2004_140026.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4944' ></a><a href='/elog/notebooks/silicon/Thu_Aug_19_2004_140036.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4946' ></a><a href='/elog/notebooks/silicon/Thu_Aug_19_2004_140043.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4948' ></a></center>
<!-- Author: Das Welt -->
<!-- Comment: Thu Aug 19 14;24;13 comment by...Toda la Gente -->
In this case, we extended the number of BE Clocks the FIB sends for
READOUT from 20 to 1024, so that we could actually see the Fib READOUT stopping when the ABORT is sent.  Then we rolled the L1DONE counter back  from 80 counts (first picture) to 70, then 50, then 30, then 15 (in the DIGITIZE cycle) and you can see the BE CLocks for READOUT getting progressively shorter.  You can also see
<ul>
<li> There is always a mini-digitize after the BE Clocks stop
<li> Even when the ABORT comes during DIGITIZE, there still are
a few BE CLOCKS for READOUT.  Probably this is the FIB inserting its header and 0xC8C8 into the READOUT stream.
<li> The same chip commands are always present in every case.
</ul> 
Now we have confidence we understand what gives



<!-- Comment: Thu Aug 19 15;07;08 comment by...Dwarfish speakers (Die sieben Zwerge) -->
<pre>
0x00000000:  00700d01 00000000 00000000 00060006 00060006 00060006 00060006 00060006
0x00000020:  e0a019fc c8c80000 e0a119fc c8c80000 e0a219fc c8c80000 e0a319fc c8c80000
0x00000040:  e0a419fc c8c80000 e0b019fc c8c80000 e0b119fc c8c80000 e0b219fc c8c80000
0x00000060:  e0b319fc c8c80000 e0b419fc c8c80000

</pre>
This is what the VRB sees after doing a SRC Emulator L2A  to a VRB buffer and then reading the VRB pipeline FIFO. The FIB always send at least the header.
So GLINK_DATA_VALID will go up and down again.

<!-- Date: Thu Aug 19 14:26:24 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Aug_19_2004_142616.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4954  align='top'></a></td><td>For completeness, we had the SRC send the ABORT before DIGITIZE, and you see you get no DIGITIZE nor READOUT.  If 
this actually happens, it is OK for the Silicon but will screw up the SVT.</td></tr></table>
<!-- Author: Le Monde -->


<!-- Date: Thu Aug 19 14:27:37 2004 -->
<center><a href='/elog/notebooks/silicon/Thu_Aug_19_2004_140056.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4950' ></a><a href='/elog/notebooks/silicon/Thu_Aug_19_2004_140110.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4952' ></a></center>
<!-- Author: E&#39;rybody -->
<!-- Comment: Thu Aug 19 14;43;42 comment by...Marcel, Sebastian, Lashkar, Gino, SCN -->
<h2>Testing with SVXII</h2>
We then moved to subject the SVXII FIBs to the ABORT signal. TO do this we <ul>
<li> used a run configuration based on calibration, but changed 
the TS L2 option from Auto L2A to Auto L2 Alternate, which alternately sends L2A and L2R, with the L2 decision 8 &#956;s after the L1 decision.  After some trouble with the Resonance deetector because we were going too slow, we took run <href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=186408">186408</a>
in this configuration, which ran for a while.
<li> Switched the FFO in the test crate to listen to the SVXII SRC, so we could spy on the FIB commands coming down the backplane and see what the Fib sends to the Chips via the FTM
<li> Monitored currents with IMON
</ul>
 During our efforts, we <b>only</b> saw 
<ul>
<li> SB0W5L2 current change because we went into DPS OFF (see <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L2">PDB</a>)
<li>  SB0W3L4 go pink but it is a <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L4">jumper failure</a> with a lot of other problems</ul>
 so <B>it is clear there is no systematic trend in currents when the SRC sends FIB ABORT.</b><P>
What you see here is on the (Fib) backplane of the Test crate and  what is coming out of the FTM, where now the Test crate FFO is hooked up to the SVXII SRC (previously it was the Test SRC).  ON the left is a trace snapshot where the FIB ABORT is sent about 13 &#956;s after the L1A, and it does cut off the READOUT (so indeed we are sending it) and the right a blow up of what happens after
the ABORT, where you can see the mini digitize is still executed.<P>
As a result of this test, we feel comfortable with the idea that the SRC might tell the FIBs to ABORT more frequently than they used to.



<!-- Date: Thu Aug 19 22:46:46 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4955&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4955' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4956&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4956' width='300'></a></center>
<!-- Author: stan -->
<!-- Comment: Thu Aug 19 22;55;12 comment by...Stan -->
<pre>Completed IV Bias Scan with David Stuart. RC was run with SVXCalib_DPS off because the normal configuration lacked a valid trigger table. 

Two pinkies during the IV Bias Scan.  SB0W5L2 has a history of acting up under DPS off conditions.  SB0W3L4 also has a history of high DVDD excursions, but I can confirm that this is directly related to starting/stopping/pausing a run.  

System was run through coldstart to check out system post bias scan.  The two offending currents returned to normal.</pre>
<!-- Date: Thu Aug 19 22:51:21 2004 -->
<pre>IV Bias scan  
 
dV	Run   evt start evt end 
---------------------------------------- 
 0	186434	 
 0	186435 
 2      186436	   0	  400 
 4      186436	 550	 1000 
 6      186436	1100	 1500 
 8      186436	1600	 2100 
10	186436	2200	 2700 
12	186436	2800	 3200 
14	186436	3300	 3700 
16      186436	3900	 4300	 
18	186436	4400	 4800 
20	186436	4950	 5140 
20      186438     0	 350 
22	186438	 450	 670  	 
24	186438	 800	 1000  
26	186438	1150	 1420 
28	186438	1600	 1950 
30	186438	2050	 2350 
32	186438	2500	 2850 
34	186438	3000	 3300 
36	186438	3450	 3800 
38	186438	3900	 4300 
40	186438	4300	 4600 
42	186438	4700	 5000 
44	186439	   0	  425 
46	186439	 500	  900 
48	186439	1000	 1350  
50	186439	1400	 1750 
52	186439	1825	 2225 
54	186439	2300	 2725 
56	186439	2800	 3200 
58	186439	3300	 3650 
60	186439	3700	 4150 
63	186439	4200	 4550 
66	186439	4600	 4850	 
70	186439	4900	 5086 
80	186440     0        300 
20      184440   400	   700	 
 0	184440	 800	 1200 
------------------------ 
 
We had two pinkies during this time and 
needed to reconfig a couple times for b0fib02 to pass. 
 
Check the system after with coldstart. 
</pre>
<!-- Author: David Stuart and Stan Forrester -->
<!-- Comment: Fri Aug 20 11;39;58 comment by...bbrau -->
<pre>For the record, this was a quiet time noise vs bias scan.</pre>
<!-- Date: Fri Aug 20 10:04:00 2004 -->
<pre>Try to power up e322 (SB3W2L2) during quiet time, but still get OverVoltage immediately. It trip so fast that if we try the whole wedge off/standby, it failed to power even PC. 
</pre>
<!-- Author: Gino and Rong-Shyang -->


<!-- Date: Fri Aug 20 13:10:25 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L3 
<li>problem n: 84 
<li>Status: fixed
<li>Type: software_protection
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: All chips look reasonable.  No problems seen.  Fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Aug 20 15:24:37 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L4 
<li>problem n: 345 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Still a problem at the level of 30-40% of events. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Aug 20 17:38:55 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Aug_20_2004_173818.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4958  align='top'></a></td><td>While trying to understand the blue wire that Bashful is missing on the VME logic, found that Dopey has a potential conflict there, since it has two lines diving the flip flop clocks of the VME addr lines. The picture shows the blue wire from U12 pin 4 to the U14 clk, Dopey has this wire but pin 3 comming out of U13 is not disconnected. According to Vince this may cause trouble. Marcel checked that DSB0 and DSB1 can be different. </td></tr></table>
<!-- Author: lashkar, marcel, sebastian -->


<!-- Date: Sat Aug 21 21:47:00 2004 -->
<pre>Came in for final P-bars and found L00 West 1&4 and ISL B0W1, B1W0 and B1W1 indicating off on the PSGui.  There is no indication of a trip on the text window of the GUI (last entries were 9:59 Friday night associated with the work Gino and Rong were doing on SB3W2,)  No other indications, Global Alarms ISL and LOO were both green. 
 
Placed all off wedges in standby.  Curious. 
 
</pre>
<!-- Author: stan -->
<!-- Comment: Sat Aug 21 21;55;55 comment by...stan -->
fib03 sheparded a few minutes prior to my comming in and noticing the off wedges.  <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=625&frame=2&anchor=21:28:03.537'>
see shift log entry. </a>


<!-- Comment: Sun Aug 22 04;38;03 comment by...Stan -->
<pre>From discussion with rong and marcel: From the log files it looks like communications with crate may have been lost first. -> Failure of Fib03 to config and off wedges may be symptoms of same problem rather than one causing the other.  Can not be completely certain becasue of the lack of time stamp on the handshake error message.</pre>
<!-- Date: Sun Aug 22 04:31:11 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4959&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4959  width='300' align='top'></a></td><td>SVTSpymon</td></tr></table>
<!-- Author: stan -->



<!-- Date: Sun Aug 22 05:49:54 2004 -->
<pre>Some DAQ/trigger/consumer test after store came in. 
 
- CSL test w/o and w/ silicon.  
- Pulsar test with more timing function in the firmware. Again, did alpha w/ silicon; pulsar w/o silicon; pulsar w/ silicon. 
- SVT bypass test with silicon.  
- CMU trigger table w/o then w/ silicon. The L1A rate is only 50Hz and Silicon was running fine also. 
</pre>
<!-- Author: Stan, Marcel and Rong-Shyang -->


<!-- Date: Sun Aug 22 14:36:56 2004 -->
fib02 refused to cold start during post quench check out.   
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=627&frame=2&anchor=13:34:10.373'> 
See shift log </a> entry.  SB2W2L4 taken out of Hwd db and system now will config. 
 
  
<!-- Author: stan -->
<!-- Comment: Sun Aug 22 14;39;22 comment by...Rong-Shyang -->
<pre>e224 is still in HWDB, I just mask the INIT readback.
This guy has flaky readback problem and has readback failure occasionary.</pre>


<!-- Date: Sun Aug 22 14:39:34 2004 -->
<pre>ISL Global Alarm, pwrsupply "trip in IB2W2 portcard and perhaps others"  THis wedge is supposed to be out.  Tried to reset trips to see if that would make the GA indication go away.  Worked but had to restart IMON to make trip indications go back to black.</pre>
<!-- Author: stan -->


<!-- Date: Sun Aug 22 15:45:27 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4960&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-4960  width='300' align='top'></a></td><td>SVXspymon</td></tr></table>
<!-- Author: stan -->
<!-- Comment: Sun Aug 22 15;45;56 comment by...stan -->
<pre>inital lum = 65</pre>

<!-- Date: Sun Aug 22 17:47:37 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W4L4 
<li>problem n: 434 
<li>Status: unfixable
<li>Type: AVDD2
<li>Action: Init_RB_mask
<li>entered by: rong 
<li>description is: INIT readback failed occasionally and causes ACEs to issue 'Sheperding' on fib02 too often. Mask ther init readback. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W4&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Aug 22 22:02:16 2004 -->
<center><a href='/elog/notebooks/svt/Sun_Aug_22_2004_062114.ps'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-263' ></a><a href='/elog/notebooks/svt/Sun_Aug_22_2004_062237.ps'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-265' ></a></center> <BR> 
<p> SVT processing time with bypass scheme or reqular running.</p>
<!-- Author: Rong-Shyang -->