<!-- Title: 18:32:57  Wed Oct 15 2003 -->
<!-- Crewchief: Usual Suspects -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>A new page...</pre>


<!-- Date: Wed Oct 15 18:36:48 2003 -->
<pre>We investigated the ACE complaint about svt03 having 
difficulties in config. They were very well reproducible 
(100% !!!) and we traced them back to a possible failure 
in the TF/21 (serial number 10). Replacing it with the 
one in the test stand seems to solve the problem. 
Also, we noticed some weird VME corruption with the 
old TF which don't show up anymore with the new one: 
sometimes the communucation with other boards (e.g. AMS 
in slot 8) was affected and corrupted data was observed. 
 
We give now back the crates to the aces and ask the TF 
experts to have a look at the incriminated board! 
</pre>
<!-- Author: Alex and Roberto -->
<!-- Comment: Thu Oct 16 03;41;49 comment by...stefano -->
this is the same board that used to require a reseat in order to corretely respond to initialization (cold start) after power cycle. I would not be suprised if was again that the last power cycle put the VME i/f of this board in a funny state. See the SVT e-log  <a href=
'/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=7&frame=2&anchor=09:31:56'>
May 27 2003</a>
</ul>

<!-- Comment: Thu Oct 16 04;03;28 comment by...Stefano -->
See also
<a href=
'/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=3&frame=2&anchor=20:27:30'>
Jan 25 </a>


<!-- Comment: Thu Oct 16 04;05;02 comment by...Stefano -->
<pre>See also
&lt;a href=
'/cgi/elog/elog.pl?nb=2003&action=view&page=420&frame=2&anchor=16:30:03.251'&gt;
May 20 &lt;/a&gt;</pre>

<!-- Comment: Thu Oct 16 04;06;21 comment by...Stefano -->
See also<a href=
'/cgi/elog/elog.pl?nb=2003&action=view&page=452&frame=2&anchor=15:34:07.476'>
May 31 </a>


<!-- Date: Wed Oct 22 21:43:59 2003 -->
 
I request L2 touture test for validation of the GB functionality of 2nd channel (so called ch#1) in slot6 of b0svt06. 
(This has new utility/timing firmware). If this works well, L2 touture has no problems in proceeding 
after recabling.<p> However, I found that L3 rate is dropped 0 Hz after this recabling. It looks like 
we have a problem in using both ch#0 and #1 in coincide. Some investigations for this problem are 
needed.   
<!-- Author: Taka -->
<!-- Comment: Fri Oct 24 01;16;10 comment by...Taka  -->
I did the GB functionality test using fakehits mode again. I found that yesterday's conclusion was
wrong because I used wrong hwset files.  After using right hwset file, 2nd channel of slot6 GB works well. <p> 
I added the cable to 2nd channel of slot6: <br>
normal case; slot6 1st channel (processor) -> slot14 1st ch (utility/timing for SVTD) -> slot14 2nd channel (utility/timing),
<br> 
this case; slot6 1st ch -> slot6 2nd ch (timing/uyility) -> slot14 1st ch -> slot14 2nd ch <br> 
We can conclude there is no interference between 1st and 2nd channels of slot6 working. <p>

By the way, I found another problem in fakehits.hwset for the variable "spy_tf_gbReadoutSVTD" (for SVTD readout variable). If we changed this value from "0011" to "0111" (readout channel wis changed 1st channel to 2nd one), we can't start fakehits mode any more. I don't know the reason of this at present, but I should investigate as soon as possible. 

 




<!-- Date: Fri Oct 24 18:08:11 2003 -->
<pre> During 2nd attemption of figuring out of the SVTD readout  
problem, I had different error of AMB in creat 1 (b0svt01). 
Error message is as follows. &lt;p&gt; 
 
amb(slot9,amb_w02_0): mapSet=_cached_ hwSet=_cached_ w=2 b=0 
checkMemoryFragment: nerr=5759 
&lt;br&gt; 
FER_E_SVT, writeMap(amb_w02_0/AM0pat): checkMemoryFragment mismatch (nerr=5759) 
 
 
checkMemoryFragment: nerr=5962 
FER_E_SVT, writeMap(amb_w02_0/AM0pat): checkMemoryFragment mismatch (nerr=5962) 
 
 
FER_E_SVT, amb(slot9,amb_w02_0): pattern write failed 2nd try 
 
 
  svtvme_amb_coldstart returns -200 
Cannot configure readout - check readout list. 
Readout process not started. Error status: 1 
Error Processing Readout List ! 
Sent ack to Run Control: 1 ERROR ERROR  
FER-E-SVT, (info) hc=3253526858 mc=358150100 
 
ssage from RTserver: Connection established.&lt; 
 
 I will swap the board. 
</pre>
<!-- Author: Taka -->
<!-- Comment: Fri Oct 24 19;47;26 comment by...Taka -->
 I swapped AM board#20 (b0svt01, slot9) to board#12 (teststand, slot6). <br>
After swapping, coldstart is working well again. <br>
I put board#20 to teststand slot6.<p>

I send this to expert.


 



<!-- Date: Fri Oct 24 22:06:22 2003 -->
 If I remove one GB (slot13) from b0svt06 and recable, reading SVDD and SVTD 
itself looks fine beacause we have error message when we don't  
have any SVDD and SVTD information.  
I can conclude slot6 GB functionality is fine. <p> 
 
I want to prove this using L2 touture and cosmic ray run with changing, "stephen4.hwset" and "nosvx.hwset". At present, many  
people is working around B0, I cannot test. But, tomorrow,  
I will be able to do it, hopefully. 
 
 
  
<!-- Author: Taka -->


<!-- Date: Sat Oct 25 09:07:32 2003 -->
 Greg Field found that SVT had problems in L2 touture run, 
dropping L2 rate to 0Hz. (L2 claims that SVT doesn't send any 
data) <br> 
 
 At first, I doubt GB itself, but swapping the boards, changing the constants, and so forth are not valid so much. 
But, after changing outputs of final MRG board (ch1 -> ch2), 
it looks fine now. <br> 
But, creat6 system is very sensitive to hardware change so, 
we need be careful as much as possible.  
 
  
<!-- Author: Taka Maruyama -->


<!-- Date: Sat Nov 1 02:51:52 2003 -->
I found that the line: <br> 
"spy_tf:kludge_gbTimingSlot := 0" <br> 
in coldstart of the b0svt06 creat#6. <br> 
This should be removed since we don't have GB for gbTiming,  
so that this may be a source of the mysterious "spy_tf_gbReadoutSVTD 0111" stack as I found on 1 week ago. <p> 
 
If I set "spy_tf_kludge_gbTimingSlot = d" apparently in fakehits.hwset,  stack was not appeared in the fakhits run. 
Related codes in svtvmr_fer.c will be removed.  
<!-- Author: Taka -->


<!-- Date: Sat Nov 1 07:38:31 2003 -->
We had failure of running cosmic ray run from 4:00 due to b0svt06 error. <br> 
Since Giovanni wants to know what I did , I describe it: <br> 
 
(1) We found b0svt06 had something problem in cosmic ray run 
   (Run#172815: <a href= 
'/cgi/elog/elog.pl?nb=2003&action=view&page=912&frame=2&anchor=03:45:13.672'> main log </a> ) <br> 
 
(2) But, I never found SVT creat6 problem using fakehits mode. 
   So I guess this might be due to connection between b0svt06 and 
   other guys. <br> 
 
(3) I tried to investigate this problem, again. <br> 
 
(4) I found that there are no L2A events even in fakehits of 
   using "auto L2A". But this is another issue and Greg found a  
   candidate of the source of this problem. See <a href= 
'/cgi/elog/elog.pl?nb=2003&action=view&page=912&frame=2&anchor=07:17:28.606'> mainlog for Greg's comments</a> <br> 
 
(5) I turned off the power cycle of b0svt06 around Greg's coming. 
<br> 
 
(6) Greg and I found that b0svt06 was fine again. 
  though not sure 100% what is most effctive. <br> 
 
 That's all.    
 
 
 
 
  
<!-- Author: Taka -->


<!-- Date: Sun Nov 2 03:51:49 2003 -->
I found that last 5 lines of hwset file are no use but harmful now:  
<p> 
# <br> 
# GhostBuster to measure SVT timing  <br> 
# <br> 
gb_timing_GB_CTRL0_A			6194A     # tag tracks <br> 
gb_timing_GB_CTRL1_A			645A                   <br> 
gb_timing_GB_CTRL0_B			40000000  # timing     <br> 
gb_timing_GB_CTRL1_B			30000000  # passthru   <br> 
gb_timing_GB_XFT_UNIQUE			1         # bust ghosts <p> 
And this is a source of stacking of data taking start when we changed the "spy_tf_gbReadoutSVTD" from "0011" to "0111". 
If we erase these lines of hwset, run starts smoothly and SPYMON 
histograms appeared using (slot13, ch#1) of b0svt06. <p> 
I will try recable and merging functionalities of GB after this  
erasing.
<!-- Author: Taka -->


<!-- Date: Sun Nov 2 12:12:17 2003 -->
<pre>What I did for SVT were: 
&lt;BR&gt; 
(1) Erase harmful 5 lines in database file (hwset) for SVT configuration. &lt;a href= 
'/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=10&frame=2&anchor=03:51:49'&gt; [SVT 
e-log] &lt;/a&gt; These lines cause svt creats stuck after changing SVTD readout channel since they are 
un-assigned register any more. &lt;BR&gt; 
(2) Try svtvme_fer.c code debugging for SVDD cable readout part. (But in vain at present, 
unfortunately). This code wants to read out all of SVT GhostBuster board channels (0-2ch) for 
assignes slots. However, we don't have such a readout functionality in ch#0, slot#6 one. So, this 
should be removed in using slot6 GB only.  
 
In this time I had error in compiling the svtvme library like: &lt;p&gt; 
gmake: *** No rule to make target &lt;br&gt; `/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/include/stddef.h', needed by `src/callbacks.o'.  Stop. &lt;br&gt; 
I'm not sure 50% I compiled svtvme library really. 
 
Next time, I investigate we need to debug more or not. All 
hardware configuration and svtvme codes are same as this morning except for database file. Should 
be work without problems in cosmic or so.  
</pre>
<!-- Author: Taka Maruyama -->
<!-- Comment: Mon Nov  3 07;28;52 comment by...Stefano -->
The error from gmake is harmess (only affects svtgui). Anyhow I have fixed it and e-mailed details to Taka and svtgui expert (Subir). I have modified Makefile so this will not happen again.


<!-- Date: Wed Nov 5 17:58:07 2003 -->
I found one more screwed up register part in svtvme_fer.c. 
I update and commit it, now we have update svtvme library. <br> 
 
After this, I test this configuration and there is no problem  
in fakehits. Done.  
<!-- Author: Taka Maruyama -->


<!-- Date: Sat Nov 8 00:45:16 2003 -->
<table border=0><td><tr><td bgcolor=#e0e030><table><tr><td><a href=/cgi/elog/elog.pl?nb=2003&action=view&page=-11920&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2003&action=view&page=-11920 width='300' align='top'></td><td>It looks like SVT works well in cosmic ray run (run#173573: cosmic w/ SVXII). <BR> 
Left: #SVX hits in wedge11 from SVTSPYMON. <BR> 
right: Processsing timing in SVT of cosmic ray run <BR> 
Of course, other wedges #hits looks fine also. </a></td></tr></table> 
 
 
</td></tr></td></table>
<!-- Author: Taka -->


<!-- Date: Sat Nov 8 05:12:07 2003 -->
For HF ISPY mode fakehits: 
(1) For firmware changing (to avoid MRG board FIFO full): 
   We need to propagete MRG board hold signal to 10 HITMAN chips. 
   (front panel -> MOP chip -> boot chip -> 10 HITMAN chips) 
   This is almost done except for real firmware installation.<br> 
 
(2) We need to prepare for the input information of the ISPY 
   from svtsim or SPY buffer. 
   This will be done by Roberto. 
 
(3) svtvme_fer.c should be modified to install dummy data to ISPY 
   in the coldstart. We have prototype codes in private area, so  
   that, this will be done in near future. 
 
 
 
  
<!-- Author: Taka Maruyama -->


<!-- Date: Sun Nov 9 07:41:30 2003 -->
I bring the HF board in teststand slot#4 (seq#51) to UC to figure 
out the way to install the firmware. I will plan to bring back this guy this Wednesday. <br> 
 
By the way, Un-ki also bring TF back to UC. 
We need to carry this TF here also.  
<!-- Author: Taka Maruyama -->


<!-- Date: Sun Nov 16 10:53:52 2003 -->
Roberto has been called by shift crew around 5:30 because SVT crate 5 was <a href="http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=957&frame=2&anchor=01:28:49.194"> failing</a> cold start (now this is called CONFIG !). 
We trace this from  
<a href="http://www-cdfonline.fnal.gov/daq/runSummary/errorlog/errorfile174161.log">r_c error log</a> to 
the "usual" AM board failing during pattern write. 
<p> 
This time is <b>AM 0 for wedge 10 i.e. b0svt05 slot 9</b> 
<p> 
We log into cdf_svt account and run the test program 
<pre> 
cd tools/am_test 
./am_test_vme_linux 
</pre> 
this clearly diagnose a problem with AMPlug 09 
<br> 
We will swap AM board with good spare (if we find it !) 
 
 
<!-- Author: Roberto & Stefano -->
<!-- Comment: Sun Nov 16 11;09;48 comment by...roberto & stefano -->
<table border=0><td><tr><td bgcolor=#e0e030>The bad AM is serial number 4<p>
We swapped the bad AM Board with the last good one from
test stand. We verified that bad boards still fails am_test_vme_linux on test stand, and new one passes both on test stand and on b0svt05. The new AM is serial 15.
</td></tr></td></table>

<!-- Comment: Sun Nov 16 11;15;37 comment by...R & S -->
<pre>The new board also passes CONFIG R_C transition. We hand SVT to the ace.</pre>


<!-- Date: Mon Nov 17 16:25:54 2003 -->
Problematic TF (once in b0svt03 slot12) is brought to FNAL again. 
Coldstart tests for this was performed in 400 times and there  
were no problems. It looks like there is something trobles in connection between b0svt03 and this TF, specifically.  <br> 
Anyway, 400 times is not so lagrge number, so that I will repeat 
this test a little bit more. ( 1000 times coldstarts correspond to  
1/2 month in normal data taking)
<!-- Author: Taka -->


<!-- Date: Wed Nov 19 00:27:15 2003 -->
20 times coldstart tests were performed with the VME hardware  
turning on/off. (this is suggested Stefano Berforte.) <br> 
There is no coldstart errors. <br> 
Next time, I will try 400 times coldstart test with different 
mapset in each time as Un-ki suggested. 
  
<!-- Author: Taka -->
<!-- Comment: Wed Nov 19 00;27;58 comment by...Taka -->
<pre>This is statement for TF coldstart.</pre>


<!-- Date: Wed Nov 19 14:20:00 2003 -->
TF 100 times coldstart tests with different mapset in each time were performed. There is no problems. <br> 
Un-ki doubted that interface between b0svt03 and TF. <br> 
But, anyway, we can use this board as spare so far. <p> 
If there is any problems in b0svt03 TF (slot12), we will  
investigate more. 
  
<!-- Author: Taka Maruyama -->
<!-- Comment: Wed Nov 19 14;21;47 comment by...Taka -->
Of course, this TF is the board described in top of this page 
<a href=
'/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=10&frame=2&anchor=18:36:48'>
description </a> 


<!-- Date: Wed Nov 19 19:32:48 2003 -->
<pre>tested spymon/coldestart/readout using only GB in slot 6 for everything. Need to work little more tomorrow before committing the new code to repository and make permanent changes to harwdware setup, hwset and code. 
 
</pre>
<!-- Author: Taka and Marco  -->


<!-- Date: Fri Nov 21 17:09:44 2003 -->
<pre>Present status of spare AM board after testing: 
 
board #   status   location 
 
 04       ok      test stand 
 07       ok      test stand 
 20       ok      cabinet 
 28       bad     cabinet 
 
The spare AMS #10 in now in the test stand and seems to work. 
The other AMS, 01, in now in the cabinet.</pre>
<!-- Author: Roberto, Luciano -->


<!-- Date: Fri Nov 21 19:42:56 2003 -->
Marco implimented the svtspymon program to clean up b0svt06. <br> 
And test was succeeded. <br> 
now, we can use only one GB board for (1) beam subtraction, (2) timing measurement and (3) SVDD and SVTD readout. <br> 
We don't need slot12 MRG and slot13 GB in b0svt06 any more. <br> 
However, This cofiguration requires changing of (1) normal run  
hwset, (2) fakehits.hwset (for SVT fakehitss mode), (3) stephen4.hwset(for L2 torture) and (4) nosvx.hwset (cosmic?). <br> 
I changed these files for GB readout part, like <br> 
(1) spy_tf_gbReadoutSlot d --> 6  <br> 
(2) spy_tf_gbReadoutMask 11 --> 22 <br> 
(3) spy_tf_gbReadoutSVTD 0011 --> 0111 <br> 
I can guarantee these files are fine. But, if you have problems 
using these files, please call Taka Maruyama using cel phone (in B0 white board) 
 
 
 
  
<!-- Author: Taka Maruyama -->


<!-- Date: Mon Nov 24 00:28:42 2003 -->
<table border=0><td><tr><td bgcolor=#e0e030>Masa estimated current beam position from COT BeamMon at minimum bias data. Please see  
<a href='/cgi/elog/elog.pl?nb=2003&action=view&page=979&frame=2&anchor=12:49:07.072'> 
main log book </a> <br> 
Beam position at present is not different signicantly from that of before shutdown as expected. 
 
</td></tr></td></table>
<!-- Author: Taka -->


<!-- Date: Mon Nov 24 02:54:17 2003 -->
I entried the d0<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=981&frame=2&anchor=02:25:05.018'> 
[main log] </a>  
, d0 vs phi 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=981&frame=2&anchor=02:33:01.210'> 
[main log] </a>  
 and SVT occupancy plots 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=981&frame=2&anchor=02:34:55.976'> 
[main log] </a> using old beam position (before shutdown). 
Beam position is amazingly similar!!.  
<!-- Author: Taka Maruyama -->
<!-- Comment: Mon Nov 24 03;12;22 comment by...Taka Maruyama -->
<BR>
<cite>-- Mon Nov 24 03:10:32 comment by...Taka Maruyama --  </cite><table border=0><td><tr><td
bgcolor=#e0e030>Beam position comparison barrel by barrel between before and after shutdown using
SVT beam position fitting. <BR>
barrel#0(x): -2287.23um (new) vs -2111.63um (7-Sep) <BR>
barrel#1(x): -2190.11um (new) vs -2040.00um, <BR>
barrel#2(x): -2075.23um (new) vs -1968.55um, <BR>
barrel#3(x): -1972.96um (new) vs -1902.55um <BR>
barrel#4(x): -1852.42um (new) vs -1818.87um <BR>
barrel#5(x): -1734.09um (new) vs -1731.88um <p> barrel#0(y): 5210.67um (new) vs 5278.79um (7-Sep)
<BR>
barrel#1(y): 5251.25um (new) vs 5323.27um <BR>
barrel#2(y): 5279.34um (new) vs 5343.72um <BR>
barrel#3(y): 5330.70um (new) vs 5391.74um <BR>
barrel#4(y): 5351.44um (new) vs 5415.28um <BR>
barrel#5(y): 5394.40um (new) vs 5439.40um <BR>
x position is slightly farer (max 80um), but y position is closer than before (max 70um).
</td></tr></td></table> 


<!-- Comment: Mon Nov 24 03;33;29 comment by...Taka Maruyama -->
<table border=0><td><tr><td bgcolor=#e0e030>One more comment. We have one more additional hole in SVT occupancy plot.(B4W4). </td></tr></td></table>

<!-- Comment: Mon Nov 24 03;35;47 comment by...Taka Maruyama -->
Quick validation between svtsim and SVTD is fine using run#174774
data although this data has quite small number of events.


<!-- Date: Mon Nov 24 06:29:53 2003 -->
<pre>
 
Merger b0svt07/10: EEreg=0001, FIFOMT=1111, InpEna=0001, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt00/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt01/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt01/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt02/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt02/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt03/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt03/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt04/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt04/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt05/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt05/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 001111111111110000
 
Executive summary: silicon dunnit
 
</pre>
<!-- Author: svt whodunnit script -->


<!-- Date: Mon Nov 24 06:29:53 2003 -->
<pre>
 
Merger b0svt07/10: EEreg=0001, FIFOMT=1111, InpEna=0001, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt00/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt01/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt01/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt02/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt02/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt03/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt03/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt04/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt04/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt05/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt05/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 001111111111110000
 
Executive summary: silicon dunnit
 
</pre>
<!-- Author: svt whodunnit script -->


<!-- Date: Mon Nov 24 06:31:27 2003 -->
<pre>
 
Merger b0svt07/10: EEreg=0001, FIFOMT=1111, InpEna=0001, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt00/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt01/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt01/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt02/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt02/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt03/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt03/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt04/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt04/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt05/07: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt05/16: EEreg=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 001111111111110000
 
Executive summary: silicon dunnit
 
</pre>
<!-- Author: svt whodunnit script -->


<!-- Date: Mon Nov 24 07:30:34 2003 -->
<pre>
 
Merger b0svt07/10: EEreg=0001, FIFOMT=1111, InpEna=0001, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 000000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->


<!-- Date: Mon Nov 24 07:39:50 2003 -->
<pre>
 
Merger b0svt07/10: EEreg=0001, FIFOMT=1111, InpEna=0001, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 000000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->