<!-- Title: 10:36:56  Sat Dec  1 2001 -->
<!-- Crewchief: jean -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<h3> 
See <a 
href="http://www-cdf.fnal.gov/internal/silicon/silicon_commission/job_lists/plan_120101.txt">Here</a> for draft of turn on requirements.</h3>


<!-- Date: Sat Dec 1 10:45:45 2001 -->
<pre>I reprioritized the requests and coerced Vladimir into agreeing to 
concentrate first on the problem of high current draw because FECLK 
is off for a long time before the init bitstream is latched. Please 
recall that fib command sequencies are universal and affect all 
channels in the fib on the same command clock. Therefore if you have 
already inited one channel and are initing the second one, the FECLK 
is switched off for both. Here is what I found out: 
 
A) My initial suspicion that the 132 ns clock was not being enabled after 
the init sequence is executed was not correct. The 132ns clock is enabled 
immediately after the last bit is sent. I couldn't locate any other 
MS sequence where the clock was unintentially disabled. 
 
B) Several VME commands are executed prior to the init sequence being 
executed. The commands are needed to stick the bitstream into the 
read/write fifo, write the number of init bits to the appropriate 
register, select the BN line in the multiplexer for the bitstream read 
back, enable MS vme commands, switch the manual strobe off so the init 
sequence is automatically executed and reset the MS command fifo. 
In theory none of these commands should have any effect on FECLK. 
 
C) In teststand mode the time between these VME commands is extremely long 
because they are executed by individual calls from the Java client to the 
server code over the network. The time scale of the high current state 
reported by V. and Gino is consistent with the time between VME commands. 
Both the handshake and RC execute one network call only to a server side 
routine that is the exact mirror of the Java client calls. The time 
between the VME commands is much shorter but the calls are identical. 
Therefore the high current state does not last long enough for the CAEN 
monitoring to catch it and trip during the handshake or RC. 
 
D) I tracked the FECLK disappearing to a single call to disable the MS 
command processor (toggle bit 0 in register c0004 to 0). This call is part 
of a sequence of actions to reset the MS command fifo. Its used during 
init and when you specifically reset the Fib command fifo from the expert 
menu. I suspect also during Fib master reset. 
 
E) Ken checked the fib logic and suspects that this call is causing the 
3 lines (bits) controlling the FECLK enable (3 states hi, lo , automatic) 
to tristate. He may be able to go into more detail on this. 
 
F) Neiter Ken nor I could think of a good reason why it is required to 
reset the MS sequencer command fifo before writing in the init command. 
Ken suspects its so that we have access to all of the MS fifo memory. 
 
G) I took the call out of the HDI init function in the Java client code, 
and everything still seemed to work fine + FECLKs were on all the time as 
they should have been. 
 
H) I'd like Gino and/or V. to look at the current behaviour after this fix 
before propagating to official Java and server code functions. Please 
 
source ~bishai/cvs/setup.csh 
 
on the online machines to pick up the modified Java client code. 
 
I) My understanding of the request to play with the relative timing of 
CALSR and CHMODE is that there is no evidence that the timing is causing 
bad current states but that there is a desire to determine exactly which 
command causes the Idvdd to start its descent.  
 
</pre>
<!-- Author: email from Mad Mary -->


<!-- Date: Sat Dec 1 11:01:49 2001 -->
<pre>There is a new disk available for data. 
In order to avoid the problem of disk full that we have encountered in the 
past I am going to move the logging of data from power supplies to the 
following directories: 
 
power supply data: --&gt; /cdf/svx-data1/datalog/ps/ 
temperature data: --&gt;  /cdf/svx-data1/datalog/temperature/ 
 
these directories will be available from web at the following URL: 
 
/svx-data1/datalog/ps/ 
/svx-data1/datalog/temperature/ 
 
for a few days the GUI-spy and the temperature spy will write data in both 
places. This will allow all of us to exercise a smooth transition for the 
various scripts. Then the above-mentioned directories will become the only 
place where we store these data. 
Archive data will be moved to 
 
/cdf/svx-data1/datalog/ps/archive/ 
/svx-data1/datalog/ps/archive/ 
 
The new gui-spy that does that is ready, but not tested, I'll send an 
e-mail when this is in place. 
The temperature spy still needs to be modified. 
The spy-spy will check on the space on this disk. 
 
</pre>
<!-- Author: Saverio&#39;s email -->


<!-- Date: Sat Dec 1 11:40:17 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030>more <a href= 
"http://www-cdf.fnal.gov/internal/silicon/silicon_commission/job_lists/monitor_113001.txt"> Notes on changes to monitoring for turning on.</td></tr></td></table>
<!-- Author: Sav and Tara email -->


<!-- Date: Sat Dec 1 13:35:55 2001 -->
<pre>Testing migration to new disk. 
GUI-spy off for a wee while or intermittently.</pre>
<!-- Author: Saverio -->


<!-- Date: Sat Dec 1 13:52:40 2001 -->
Tried to understand why we kill Vrbs sometimes when donwloading 
them.  Think it is interaction between slow monitoring and 
downloading.  Working on fix.  In process, trashed OS of VRB 
107 PREP 550280, replaced with VRB 119 550992.  107 should go back to PREP and have PROMs burned externally (version 1B06P)
<!-- Author: SCN -->
<!-- Comment: Sat Dec  1 14;40;06 comment by...SCN -->
In addition, VRBs in Slots 18 and 20 of b0svx00 (SB0W8,9,A,B) have new Vrb firmware in, in which the a Vrb channel times out after 20 microSecs after a L1A if it hasn't seen any data from the fib channel, and this channel just reports 0 bytes for that event.  I believe this is not the default behaviour, so it
needs some more software to activate this change.  These Vrbs
also have a (selectable) WYSIWYG feature and the "Stripping
leading Zeros" feature.
<!-- Date: Sat Dec 1 13:53:52 2001 -->
<pre>GUI-spy restarted. 
</pre>
<!-- Author: Saverio -->



<!-- Date: Sun Dec 2 14:36:08 2001 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_Dec__2_2001_143515.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-248  align='top'></td><td>   High digital current states:  Here is what I observed after Mary's sequence change in Feynman. When downloading chip init by "write" command FECLK doesn't stop and Idvdd doesn't go into the high state. When doing this with "Set Defaults" current jumps high and this seems to be synchronized with FECLK. This is why we suspected FECLK is responsible for high current state.    When svxdaq starts, "DAQ Init" also turns the digital current into the high state. (HRR turns it back). But this time, as it is seen on the next picture, FECLK starts shortly, and Ivdd still stays high. Although this may be the feature of FCC DAQ only, we have to understand what actually causes this high current state.    Mary kindly agreed to continue her investigation on Monday. </a></td></tr></table>
<!-- Author: Vladimir -->
<!-- Comment: Mon Dec  3 10;10;04 comment by...SCN -->
DAQ Init (in particular, Fib Init) probably turns off DDRs, and
clears the Command Clock, etc.
<!-- Comment: Mon Dec  3 11;07;23 comment by...Me myself and Mary -->
<pre>HRR does a fib reset and so does board init. I think to be safe
whenever the fib is reset we should toggle the 3 bits that enable
FECLK immediately after so that it is always on. I explicitely
put a FECLK enable into the SVX chip reset sequence which is
executated on an HRR. But we shouldn't have to wait to execute
a sequence, clocks should always be there. </pre>
<!-- Comment: Mon Dec  3 11;21;04 comment by...Me, myself and Mary -->
<pre>Set Defaults does a Fib Master Reset and switches of the MS
command processor to check and download correct sequencies
that is why FECLK gets switched off. I am not sure how to 
get around that without disabling the sequence checking in
Set Defaults. I recommend changing the Java interface
to allow a seperate button for checking sequencies. It might
happen someday. </pre>
<!-- Date: Sun Dec 2 14:37:18 2001 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sun_Dec__2_2001_143710.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-250  align='top'></td><td>  This is the second picture. Red is the DVDD current, and black is FECLK. </a></td></tr></table>
<!-- Author: Vladimir -->


<!-- Date: Sun Dec 2 20:30:57 2001 -->
<pre>Gui-spy stopped for migration tests.</pre>
<!-- Author: Saverio -->


<!-- Date: Sun Dec 2 20:45:23 2001 -->
<pre>GUI-spy restarted. 
The present version is writing log files in carbon copy 
to the two directories mentioned in an entry above. 
</pre>
<!-- Author: Saverio -->


<!-- Date: Mon Dec 3 09:34:46 2001 -->
<pre>Also the temperature spy now logs data ALSO in the new disk. 
/cdf/svx-data1/datalog/temperature/ 
</pre>
<!-- Author: Saverio -->


<!-- Date: Mon Dec 3 10:08:07 2001 -->
<pre>I think I now understand why I sometimes see the AVDD current drop when 
the bias voltage goes to standby. 
 
It is because a different ladder in that FIB turned off (presumably 
tripped on bias current while ramping down or something like that) 
and was turned back on. When it turns on, ALL ladders in the FIB get a 
handshake which drops their current by about a factor of 2. 
I checked two of the cases where this happened (SB0W0-1 on 8/12 and 8/15) 
and found a power cycle on a ladder in the FIB (previously I had just 
checked within the wedge). When the power for that ladder comes back on, 
it goes into a high current state but the other ladders go into a low 
current state. Presumably this is because the handshake beat the power. 
 
Steve, am I remembering the handshaking correctly, all ladders in that 
FIB get it right? ( note added by Jean - Steve says yes) 
 
I think that the reason for the lower AVDD current is that the handshake 
must turn off the preamp (ISEL=0). It would probably be better to use 
standard ISELs. Our original intent was to put the chips in a low current 
state at power on. Keeping the current (and thus thermal stresses) 
constant is probably more important (especially since high DVDD currents 
are the biggest power-on problem, not AVDD). So, I propose that the 
handshake bitstream be replaced by one from ISL. That will give 
16 chips with values similar to the running currents everywhere. 
 
</pre>
<!-- Author: David Stuarts&#39;s email -->



<!-- Date: Mon Dec 3 10:11:13 2001 -->
I am taking crate b0fib00 to test out new handshake protocals- 
don't worry, I don't need to turn any ladders on.
<!-- Author: SCN -->
<!-- Comment: Mon Dec  3 13;23;24 comment by...SCN -->
Handshaking protocal tested.  Here is what might happen if we like it<ol>
<li> PS CPU sends out list of "Wedges to be initialized" (normally 1 wedge long)
<li> FIB CPU  replys with which ones it knows of, and start a loop initializing those wedges (one process per fib).  This will continue for a maximum of 10 secs (again per fib).
<li> PS sends out wedges which are observed as powered (or doesn't, because the enables or 5 V Kill switches are off)
<li> If FIB is still initializing the powered wedges, it waits 50 ms and then ends the loop.  If it is not (i.e. 10 s have passed)
it executes one initialization.  In either case the FIB replys with the wedges it has initialized
</ul>

The advantage of this method is that the mean duration of the state where the chips are powered but not initialized is 0.5 * (time
of initialization loop) which comes out as 1.75 ms currently.
The timeouts are actually time based, not loop based, so they
will not change if the execution of the code gets faster or slower etc.  Also, if we ever turn on multiple wedges at once, 
this time will be a factor of (n fibs initializing) longer, since
they all share the same cpu, and only one fib can be initializing
at a time.
<P>
If this method is approved, it does not take long to update the
default code.  I believe someone is working on speeding up
the initialization execution, such that 1.75 ms might become 
order 10 microS or something. <P>
I am done with b0fib00 for now.
<!-- Comment: Mon Dec  3 13;26;05 comment by...SCN -->
I said something wrong.  It is true that one process is spawned
per fib needed to initialize the set of ladders.  Each of those
processes will run for a maximum of 10 s, but in parallel, such
that the maximum time is <B>NOT</B> (Number of Fibs)  * 10 s
but something closer to 10 s.  Note both the 10 s and the 50 ms
are just choices I made without too much thinking, and are easy to change.
<!-- Comment: Tue Dec  4 12;29;16 comment by...SCN -->
<h3> Post Meeting fallout </h3>
Decision of meeting was to not opt for this method (but save for 
potential future use) but rather simply send the bitstream to all 10 HDIS in a Fib after the PS tells the Fib the power is on, with these modifications<ul>
<li> The bitstream used should be the default ISL hammamatsu bitstream.
<li> The time between when the GUI sends the power up command and
when the GUI sees the power on, estimated at 1 sec, should be measured.
<li> The Fib should send one init sequence to the HDIs anyway in
some amount of time (20 s mentioned) in the case that the PS GUI
never sends "power on").
</ul>

I will try to implement these now.

<!-- Comment: Tue Dec  4 12;58;09 comment by...SCN -->
New Dummy bitstream<P>

To get this bitstream, I just brought up svxdaq and assigned
the file Hammamatsu_16chip.svx to a particular fib's HDI 0, then
tried to initialize it without power.  That failed (as expected), so svxdaq kindly spit out what it expected to read back in terms of bytes, which I take to be the desired bitstream.  Hammamatsu_16chip was originally from Dave Stuart as the default settings for all ISL Hammamatsu ladders.  The results are:
<pre>
  /* ISL hammamatsu bitstream */
  int dummyBitStream[394] = {80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 
			     99, 28, 76, 90, a, a8, 5a, 78, b, 10, 10, 10, 10, 10, 10, 10, 10,
			     10, 10, 10, 10, 10, 10, 10, 30, 13, c5, 1e, 12, 1, 55, b, 6f, 1, 
			     2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 66, a2, d8, 45, 22, 
			     a0, 6a, e1, 2d, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 
			     40, 40, 40, c0, 4c, 14, fb, 48, 4, 54, 2d, bc, 5, 8, 8, 8, 8, 8, 
			     8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 98, 89, 62, a7, 89, 80, aa, 85, b7, 
			     0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 33, 51, ec, 35, 
			     11, 50, b5, f0, 16, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 
			     20, 20, 20, 20, 60, 26, 8a, dd, 26, 2, aa, 16, de, 2, 4, 4, 4, 
			     4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, cc, 44, b1, df, 44, 40, d5, 
			     c2, 5b, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 
			     80, 80, 9a, 28, 36, 8c, 8, a8, 5a, 78, b, 10, 10, 10, 10, 10, 
			     10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 50, 13, c5, 96, 11, 1, 
			     55, b, 6f, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 6a, 
			     a2, d8, 34, 22, a0, 6a, e1, 2d, 40, 40, 40, 40, 40, 40, 40, 
			     40, 40, 40, 40, 40, 40, 40, 40, 40, 4d, 14, db, 46, 4, 54, 2d, 
			     bc, 5, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, a8, 89, 62, 
			     63, 88, 80, aa, 85, b7, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 
			     1, 1, 1, 35, 51, 6c, d, 11, 50, b5, f0, 16, 20, 20, 20, 20, 20, 
			     20, 20, 20, 20, 20, 20, 20, 20, 20, 20, a0, 26, 8a, cd, 21, 2, 
			     aa, 16, de, 2, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, d4, 
			     44, b1, 3d, 44, 40, d5, c2, 5b};
</pre>

<FONT SIZE=+2 COLOR=FF0000>This needs to be independently checked as correct before we implement it everywhere</FONT>
<!-- Comment: Tue Dec  4 13;13;04 comment by...SCN -->
<pre>Those are hex numbers, of course...</pre>
<!-- Comment: Tue Dec  4 13;37;21 comment by...SCN -->
Implementation done, tested.  Seems to work both in
initializing after receiving the VOLTAGE ON command and
in the absence of that command after 20 s.  Note<ul>
<li> The 20 s timeout init does not produce an acknowledgement
to the PS (since it never told the CPU to do it)
<li> However, if the VOLTAGE ON command should come after
the 20 s timeout, another init is done, and this one is acknowledged.
</ul>

The CPU can process other wedges while waiting for the 
20 s/VOLTAGE ON command, so this should not produce a delay of
(20 s * # wedges to initialize) I don't think.

<!-- Comment: Tue Dec  4 14;39;34 comment by...SCN, AJS -->
<pre>Tony Affolder said that if the above method is how we got the
bitstream using Hammamatsu_16chip.svx, it is good.  So, we take
that as "independent confirmation".</pre>
<!-- Date: Mon Dec 3 12:06:40 2001 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Dec__3_2001_120628.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-252  align='top'></td><td>Here are some old measurements on F001 ('99?)  in the beambox.  Power on+init at t=30,  Stop DAQ at t=41, power off at t=43. Temperature measured on the Silicon Sensor, close to the hybrid. </a></td></tr></table>
<!-- Author: Saverio -->




<!-- Date: Mon Dec 3 15:05:24 2001 -->
<pre>Begin cooldown of SVX/ISL to 6 deg C.</pre>
<!-- Author: Andy H. -->


<!-- Date: Mon Dec 3 16:31:45 2001 -->
<pre>Cooldown complete.  I have set the following temperature trip limits: 
 
SVX BH: 10 deg 
SVX DOIM: 15 deg 
SVX DDR: 15 deg 
 
ISL CC: 20 deg 
ISL CPC: 15 deg 
 
L00 sil: 10 deg 
L00 hyb: 10 deg 
 
These values should be fine-tuned as we gain operating 
experience with a fully-powered detector at 6 deg C. 
</pre>
<!-- Author: Andy H. -->


<!-- Date: Mon Dec 3 16:38:42 2001 -->
<pre>One other thing -- during the cooldown ISL_TE_CCW2L6_1OUT 
returned from its vacation to Planet Wack and is reading 
normal temperatures again.  If it stays with us over the course 
of the next few days we can put it back into the interlocks.</pre>
<!-- Author: Andy H. -->


<!-- Date: Mon Dec 3 17:32:16 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Meeting - 9:00 AM tomorrow, tuesday in Pump Room to 
discuss dying chips and turning back on 
 
Agenda 
 Reports 
   Chip currents - Tony 
   FCC investigations - Vladimir, email from Mary 
   thermal time profile - Andy F., Juan Pablo 
   Keep alive - Lester 
   handshake - Steve N. 
   David? 
 
 Discussion 
  ISEL bits in handshake 
  Turn-on proposal 
  Policies 
 
</pre></td></tr></td></table>
<!-- Author: Jean, Andy F. -->
<!-- Comment: Mon Dec  3 20;01;07 comment by...Me, myself and Mary -->
<pre>I love meetings that materialize out of thin air.</pre>
<!-- Date: Mon Dec 3 19:59:38 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>DEFAULT SEQUENCE CHANGE: 
 
Soft link to default sequencies has been changed to point to 
CPC_120301.seq 
 
Changes from CPC_092501.seq: 
 
1) Extra command clocks in PARST start and stop to fix SB5W5 
 
2) Added a FECLK enable to PARST start so that PARSTs can never 
occur when the 132ns clock from the fib is disabled 
 
3) Explicitely disable FECLK before mini-init. This is so the 
behaviour is consistent. During HRR fib reset disabled the clock 
so when mini-init was executed the clock was off until after 
the init was done. This way no matter what fib state we are in 
SVX3 chip reset sequence will do the same thing with FECLK.  </pre></td></tr></td></table>
<!-- Author: Me myself and Mary -->



<!-- Date: Mon Dec 3 20:06:33 2001 -->
<pre>Updated Some Java client code: 
 
1) Added entries to the "Ables" in Fib Expert menu to enable 
and disable the selected DDRs.     
 
2) Changed the HDI init code in Java so that the fib command fifo 
is only reset when it is full. This minimizes the problem with 
FECLKs and PRD2s being turned off when the fib command fifo 
is reset. 
 
3) Added a checkbox in Run Daq so that fib sequencies are checked 
and downloaded only if that box is selected. This will save some 
time and minimize fib resets. 
 </pre>
<!-- Author: Me myself and Mary -->






<!-- Date: Tue Dec 4 14:00:46 2001 -->
Blessed Handshake procedure implemented, needs testing, verification of ISL bitstream. 
See <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=81&frame=2&anchor=10:11:13'> 
Comments</a> at this link. 
Also <ul> 
<li> made change such that CMD fifo is cleared only when it is full 
<li> Allowed Masked Inits to be logged as good or bad, but not cause RC to fail the cold start. 
</ul> 
   
<!-- Author: SCN -->
<!-- Comment: Tue Dec  4 14;40;33 comment by...SCN, AJS -->
<pre>"Verification" by Tony done.  See above link.</pre>


<!-- Date: Tue Dec 4 14:51:17 2001 -->
<pre>Jean and I set all the hdi ONLINEFLAGS to 0 in the hdwdb (for SVX/L00/ISL).  To do this one runs the sql script: ~svxii/sql_scripts/tempmask.sql. </pre>
<!-- Author: Eva -->
<!-- Comment: Tue Dec  4 16;35;27 comment by...eva -->
<pre>Here is the script to restore - 

2) ~svxii/sql_scripts/restore_onlineflag.sql
Restores the ONLINEFLAG to the settings that Andy F. (SVX) and Chris H.
(L00/ISL) gave me a few weeks ago.

setup oracle
sqlplus username@cdfonprd
start script_name

Eva is going to make 3 scripts, one for each of L00, SVX, ISL</pre>
<!-- Comment: Tue Dec  4 17;22;48 comment by...Eva -->
<pre>Now there are four scripts (same directory):
restore_onlineflag_all.sql
restore_onlineflag_l00.sql
restore_onlineflag_isl.sql
restore_onlineflag_svx.sql</pre>
<!-- Date: Tue Dec 4 16:02:33 2001 -->
Also have made some changes for HDI inits masked in RC.  Esentially this maps to changing the meaning of the HDI address 
in the hdwdb, which is herby defined:<ul> 
<li> Lowest 4 bits is actual HDI address (0-4) 
<li> Next highest bit (bit 4, aka address + 16) is the  
"DO NOT FAIL COLD START IF INIT FAILED" bit.  All HDIs with this 
bit on will be initialized and read back normally, and  
the results including what was expected and what was read back 
are broadcast, but if it fails RC will not fail cold start. 
<li> Next highest bit (bit 5, aka address + 32) is the 
"don't even try to read back" bit, for those HDIs which we know fail and always will fail the init and we don't even want to fill 
up log files with them.  Currently no HDIs fall into this category.   
</ul> 
When normal HDIs (i.e. with neither bit 4 or 5 set) fail initialization, RC will still fail cold start and the expected and received bit stream will be published.  
These changes are implemented, and Saverio is  
thinking about/working on getting the GUI spy to record this information.  Also, there will be a lot less information once 
we can get past the "1 failed coldstart after reboot" problem, 
but that is for later.
<!-- Author: SCN -->


<!-- Date: Tue Dec 4 16:24:44 2001 -->
<pre>Email fron Tony with ladder list from looking at AVDD current 
histories.  Most ladders are very stable. 
 
        The old bad guys are: 
        SB0W0L2 A2 
        SB0W6L2 A2 
        SB1W8L2 A2 
        SB2W9L4 A2 
        SB3W6L4 BURNIN? 
 
        New potential bad guys: 
        SB0W1L2 A2? 
        SB0W3L2 A2? 
        SB0W10L1 A2? 
        SB1W11L1 A2? 
        SB4W11L2 A2? 
        SB3W3L0 INCREASING I_AVDD 
        SB3W5L1 INCREASING I_AVDD 
        SB1W1L3 VARYING I_AVDD 
 
</pre>
<!-- Author: Tony&#39;s email -->




<!-- Date: Tue Dec 4 17:25:53 2001 -->
<pre>Chris Hill reviewed the sequence changes from CPC_092501  
and CPC_120301. The changes expected in PARST start and stop 
noted in an earlier log entry have been verified. A change was  
noticed in the abort sequence which was not part of the intended 
list of changes: 
 
Basically abort acknowledge 
was delayed by a few MS clocks. This was tracked down to the 
fact that the change was implemented during the fib abort 
testing and saved into the CPC_092501 file on the FCC repository 
which is now different than the identically named file at B0. 
In the future this will be avoided so both repositories agree.  
Since this is the sequence with which the fib abort works it was  
decided to leave it in. 
 
I recommend that CPC_120301 be downloaded into the guinea  
pigs and be part of integration testing. 
</pre>
<!-- Author: Mary B. -->


<!-- Date: Tue Dec 4 19:50:21 2001 -->
<pre>Successfully ran the three guinea pig wedges in a partition 
with the hardware event builder, read all DPS on (a calibration  
mode). So far no reformatter problems at all or any other errors, 
running at around 500 Hz. 
 
We have not tried integrating with the rest of CDF; SCN may try. 
 
We observed the events with SiliMon, which seem fine.</pre>
<!-- Author: Lester -->


<!-- Date: Tue Dec 4 19:58:37 2001 -->
<pre>Ladders to standby. GUI reports any move I make as ERROR! 
But seems to perform the requested transition. 
</pre>
<!-- Author: Lester -->
<!-- Comment: Wed Dec  5 10;25;46 comment by...Andrew -->
<pre>This is fixed!</pre>
<!-- Date: Wed Dec 5 01:27:39 2001 -->
Did some tests of new code <ul> 
<li> Found odd conflict between only resetting the command fifo 
when necessary and sending a chip reset.  Back when we were having init trouble due to the SRC sequencing, we tossed in a 
CHIP RESET just before sending the bitstream-something the 
javaq based code does not do.  Turns out if we include both features, the readback of SB1W3 is systematically shifted by 1 
bit, even when I increase delays in various places up to a second.  If I either force a clear of the command fifo or  
I remove the chip reset, the readback is fine.  I chose for now 
to remove the chip reset, since it is probably immaterial and  
we know we don't want to reset the commmand fifo if we cna avoid it 
<li> The latest protocal of the handshake as proscribed in  
the meeting works.  (See <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=81&frame=2&anchor=10:11:13'>discussion</a>. 
I tried it only on SB0W11 L1, and the currents were DVDD 69 and AVDD 268 after power up, and did not change when I sent  
another handshake init w/o cycling power. 
<li> X Mode had a big bug only when running with more than 1 Vrb, 
it is mostly fixed but there are still some memory problems that  
need to be tracked down.  They don't seem to occur with 
only 1 Vrb being read out.  More tomorrow. 
</ul> 
 
I will try to leave our three Guinea pig wedges in the hands of 
CDF, and encourage Igor to run the Si monitors, at least for 
some time.  No Bias, though.  
<!-- Author: SCN -->


<!-- Date: Wed Dec 5 09:18:38 2001 -->
<pre>Email from David Stuart about getting all the spy scripts to work. 
 
&gt; I reverted to the old spy data URL location and the script listing which 
&gt; supplies are on now seems to work... 
 
Unfortunately, this means that my illegal condition monitoring daemon is 
also working now, and it is bitching about SB0W11 having 2VDOIM=1.76V and 
5VDoim=5.37V! This is a very large deltaV and the resulting DOIM currents 
are huge. Is that the way it is supposed to be?! 
 
I also noticed that all ladders in SB0W11 were power cycled twice although 
only L1 stayed on. SB0W6 had all laders power cycled twice as well with 
bias the first time (although it looks like L2 didn't cycle the second 
time). SB1W3 had all ladders power cycle once with L0 staying on. 
This may mean that the GUI or the CAENvolts masking failed. 
</pre>
<!-- Author: david&#39;s email -->


<!-- Date: Wed Dec 5 10:11:24 2001 -->
<pre>Guinea Pig Integration Tests 
 
G. Pigs SB1W3 L0, SB0W6 L0, and SB0W11 L1 turned on 
for integration in preparation for turning on system. 
 
System Turn-on preparations in place 
*Simple "wait-for-power" handshaks 
*Powering policy 
*Thermal policy 
*IMON monitoring 
*Silimon & SVXMON  
 
Exercised new HWDB, new handshake code, 
new caenvolts.dat and powerset.dat, L3 configuration, 
GUI, GUI spy, GUI spy-spy, IMON, xmode, dmode, 
and CDF data-taking.  Many features of xmode, IMON,  
GUI, and GUI spy eliminated. 
 
With these 3 ladders successfully integrated, can test  
the intended monitoring procedures and xmode before  
turning on system. 
 
</pre>
<!-- Author: ADF -->



<!-- Date: Wed Dec 5 13:21:44 2001 -->
<h3>Guinea Pig tending so far</h3><ul> 
<li> Found bug in X Mode causing memory problems 
<li> Ran many X Modes (about 500 Hz speed) just to  
see that it works.  Saw some intermittent problems 
in the analyzeEvent routine, added some protections and 
warning, and problems went away 
<li> Took some "No Output" Runs at various 500, 5000, and 11000 Hz Digitize + (mostly) Readout (Still L2A, but VRB CPU tosses data rather than reading it out).  Someone might want to see if they can see it in today's DVDD currents. 
<li> Also tried to interleave L2A with L2R, which failed. Did 
not yet investigate the reason, and this was at highest rate. 
Last night's cosmic run was using L2, but at a much lower rate 
(I think).  Maybe we still have a rate problem. 
</ul> 
Yet to do... 
<ul> 
<li> Download new sequences to GP fibs, test for functionality<BR> News Flash!  We'd like to do it for the SOC 
and look at Peds/Noise/DNoise before and after.  Maybe we can even do it in RC with SVXMon? 
<li> Investigate L2R quandry 
</ul> 
 
During all of this, All failed inits were broadcast, and all 
inits failed or successful were broadcast for SB0WB L0 because 
it is "Try to readback but don't sfail Cold Start" masked. 
<P> 
I updated a bunch of code and put all the crates back on the  
default code and ran them.
<!-- Author: SCN -->


<!-- Date: Wed Dec 5 13:50:24 2001 -->
<h3> 
Summaries of recent dying chip work<br> 
<ul> 
<li><a href= 
"http://www-cdf.fnal.gov/internal/silicon/silicon_commission/avdd2/meet_120501.txt"> Sav's summary of Tues Dec 5 Marathon meeting </a> 
<li><a href="http://www-cdf.fnal.gov/internal/silicon/silicon_commission/avdd2/fcc_120501.txt"> Mary's summary of FCC work on  
high currents</a> 
</ul> 
</h3>
<!-- Author: Jean -->


<!-- Date: Wed Dec 5 14:07:03 2001 -->
<pre>Current plan -  
------------ 
1. work on lists below 
2. overnight, run 3 G-pig ladders integrated into CDF 
 
what has to be done before adding more ladders 
------------ 
1. Test new fib sequence using SOC _ SN, DS, ADF 
    (changes listed in Mary's entry just above) 
2. Make handshake timing timing measurement in CAEN 
3. New daily checklists for pager carrier and diagnostic shift person - ADF 
4. monitoring fixes ( see separate list) - Igor, Sav, Tara 
5. IMON - ( Bias states, separate settings, log?) - RE 
6. log inits - Sav 
7. ISL VRB replacement 
8. CAEN currents file 
 
Monitoring fixes - small meeting 8:30 thursday in Silicon Room 
----------------- 
1. SVXMON & unpacker errors- Igor, Stan 
    stuck cell, missing chips, very low occupancy - 
    dumping of error events 
    report summary & Lester's script 
2. SiliMon - Tara 
    unhealty ladders/chips 
    strange occupancy by strip, low pulse height 
3. low noise in calibrations - ST 
 
</pre>
<!-- Author: Adf, Jean -->


<!-- Date: Wed Dec 5 15:09:51 2001 -->
<h3>Sequence Testing</h3> 
Taking the GPs and the SOC to test the new sequences<ul> 
<li> Run 134128 GPs and SOC unbiased. 
<li> Run 134130 GPS unbiased, SOC biased and new ISEL and bias ratio settings 
<li> Downloaded CPC_120301_a.seq (I had to copy CPC_120301.seq as it is read protected and owned by Mary) to Fibs b0fib00 Sl 10,13 and b0fib02 Sl 9.  I burned them in. 
<li> Run 134139 GPs w/ new Sequences-all init ok, currents look ok to an untrained eye (good thing we're logging it all). 
<li> Downloaded CPC_120301_a.seq to SOC b0fib03 Sl 12, burned it in. 
</ul> 
Someone can now take a PED_D mode run on the SOC (and the GPs) with it biased, then David can compare Peds/Noise/etc.  They also 
may want charge injection, though we forgot to do it before the 
change.  It is not hard to jump back should we need to do it. 
<P> 
Leaving the SOC off and the GPs on. 
Gotta Go!
<!-- Author: SCN -->


<!-- Date: Wed Dec 5 17:31:13 2001 -->
<pre>17:24 Ricardo Eusebi 
A new version of IMON is currently running in b0dap42.The new version 1.5 allows for independent good-caution ranges for AVDD DVDD VBIAS VBIAS1 DOIM2V and DOIM5V. 
This ranges are also independent for SVX, ISL and L00. 
This version also avoid the freezing and marking of channels (only in VBIAS and VBIAS1) if the current is to small while in a stand by condition. 
If the current is to large the channel is freeze and mark whether it's in stand by or not. 
</pre>
<!-- Author: Ricardo Eusebi -->


<!-- Date: Wed Dec 5 19:41:15 2001 -->
<pre>took another calibration run with the three guinea pigs and the  
SOC with the new sequences.  
 
I had problems running with software event builder, getting  
done timeouts. Apparently the evb was real slow. HWEVB worked  
fine. 
 
Also had problems  with chip editor. It crashes: 
 
Exception occurred during event dispatching: 
java.lang.NoClassDefFoundError: hdwdb/HdwDb 
 
(i was planning to check the settings on the SOC)</pre>
<!-- Author: Lester -->
<!-- Comment: Wed Dec  5 19;42;10 comment by...Lester -->
<pre>The run was 134208 by the way
</pre>


<!-- Comment: Thu Dec  6 11;21;20 comment by...SCN -->
<ul>
<li> Hmm, the sevb shouldn't give you DONE timeouts, only
BUSY timeouts.  DONE means data didn't go from Fib to Vrb.
<li> No Class Found error indicates either hdwdb was being rebuilt at the time or a setup problem.
</ul>

<!-- Date: Wed Dec 5 22:01:06 2001 -->
<P> 
I looked at the SOC in runs 134130 and 134208 which were taken as a test of the new sequences.  
<P> 
134130 was taken with the old sequence as a baseline. But, looking at the data, the p-side noise is low. This looks like the  very old sequence, from before the p/n asymmetry fix. 
It is possible that the sequence which fixed that problem was never downloaded (or burned) into this FIB. If it was not burned in, then I'd guess since we haven't run it in SVXDAQ mode, the new (aka old, aka p/n asymmetry fix) sequence would not have been loaded since the recent power cycling. 
<P> 
134208 has closer to the correct noise; it looks like it fixes the p/n asymmetry problem. One chip (8d) has higher noise than the others (2.5 vs 2.2) in the test sequence while it does not differ in the previous sequence. 
<P> 
There are no digital errors in about 10k events. 
<P> 
The currents look ok. AVDD current is about 500mA (with the ISELs and Bias Ratio Select settings in power conserving mode). I did see it drop down to about 450 mA a couple times. This may have been during the runs. I don't understand that. 
<P> 
I conclude that there is more work to do to verify the latest sequence. But, it is safe enough to leave it in the SOC for the night. (I assume that the same conclusion was reached on the SVXII guinea pigs.) 
<P> 
It would be nice to get some collisions with the SOC to look at the landaus etc to see if all is well in charge collection.   
<!-- Author: David -->
<!-- Comment: Thu Dec  6 09;45;50 comment by...SCN -->
Other than SOC in collision, what do work do we need to do?
The SOC was in over night, but somehow not biased I hear.
<ul>
<li> Is it possible for a sequence to affect only one chip
(in this case Id 0x8d) and not the others?  My guess is that
this is some other effect, not the sequence, but I could <I>easily</I> be wrong.  Is there a pedestal shift for that chip between the two runs?  Is it both noise and dnoise?  There was some beam in the machine, but it would be surprising to me 
if beam could cause a noise shift in one chip.
<li> What can change I_AVDD by 50 mA?  I can never keep straight
what changes DVDD and what changes AVDD.  Could this be a feature
of the SOC power conserving settings combined with a particular 
DAQ state (say, not getting the Keep Alive during a brief
Halt?  Did it happen overnight while the SOC was running?
<li> Fortunately, sequence modifying is no longer an
automatic feature-a person has to choose to do it, so hopefully
we won't need to ask "Who last ran SVXDAQ and when" anymore.
I don't know who downloaded the so called 010925 sequence
to fix the p/n assymetry, but it is possible that they
did not burn it in, or somehow the burn didn't take although
we haven't seen that before.  It is also possible that the SOC
fib was skipped since the SOC is often forgotten and
the ISL Central (i.e. other half of the fib) wasn't being run.
</ul>

I think we are trying to get CDF to stop so we can put the
biased SOC in collisions.



<!-- Date: Thu Dec 6 10:13:39 2001 -->
<pre>Run 134220 stopped bue to Flying Wire/Dead SVT crate, so I biased 
the SOC, and it will be in subsequent runs.</pre>
<!-- Author: SCN -->



<!-- Date: Thu Dec 6 15:02:35 2001 -->
<P> 
I looked at the recent data with SOC biased to check the new sequences.  
<P> 
The first run showed an ~20% charge loss on the p side (apparent by looking at the phi-z charge correlation even without matching tracks). This charge loss is similar to the old p/n asymmetry problem.  
<P> 
We were running the read and write amp currents low to minimize power dissipation. For the second run we increased those currents and the charge asymmetry went away. 
Studies done during the old p/n asymmetry diagnosis indicated that if the sequence did not give enough time for the signal to settle on the pipeline you get this asymmetry and it gets worse as the read/write amp current is lowered. 
<P> 
So, I think that the data makes sense now, the sequence is ok, but we can't push the read/write amp currents as low as we hoped. To fix the asymmetry we either need more time in the sequence or more current. It is easier to just eat the extra power than try to go through another sequence changing sequence, so we'll stick with the higher currents. 
<P>  
I think that the new sequences are good enough for now and am ready to start putting in ISL when the monitoring is demonstrated to work. 
<P>  
<!-- Author: David -->


<!-- Date: Thu Dec 6 20:02:19 2001 -->
<p>I copied all the old PS event files to the new disk: 
<pre>/cdf/svx-data1/datalog/ps/events/</pre> 
 
<br>The current PS event file is available at 
<pre>/cdf/svx-data1/datalog/ps/events/</pre> 
 
<br>or via web at <a href="/svx-data1/datalog/ps/events_si_caen.log"> 
/svx-data1/datalog/ps/events_si_caen.log</a><br>
<!-- Author: Saverio -->


<!-- Date: Thu Dec 6 20:07:38 2001 -->
<pre>Due to disk space problems,  
the gui-spy is now updating log files only in the new area: 
 
/svx-data1/datalog/ps/dump.now 
/cdf/svx-data1/datalog/ps/</pre>
<!-- Author: Saverio -->


<!-- Date: Thu Dec 6 20:14:58 2001 -->
<p><font color ="red">What's going on ?  
<br> Please, check the DISK SPACE usage on b0 cluster</font>  
 
<pre> 
Filesystem    usage   quota   limit    timeleft  files   quota   limit    timeleft 
/cdf/people2 994564  900000 1000000    3.4 days   7096       0       0             
/data1       603712  700000 1500000               6457       0       0          </pre>
<!-- Author: Saverio -->


<!-- Date: Fri Dec 7 12:18:24 2001 -->
<pre> svx-init-loggin 
This process spies on initializations. 
Writes:  
- all initializations that fail and  
- all initializations for ladders that have init response masked. 
 
Results available at: 
/svx-data1/datalog/daq/ 
 
file name is yyyymmdd.si_daq  e.g. 20011207.si_daq 
 
a spy is watching on this process and restarts it if not found.</pre>
<!-- Author: saverio -->