<!-- Title: 14:22:57  Fri Sep 27 2002 -->
<!-- Crewchief: SVT group -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
New logbook!


<!-- Date: Sat Sep 28 21:19:24 2002 -->
I put in an emergency fix in svtmon code to accomodate the new GB board. The problem arose when the program was stopped/started for a test. When the program start it scans the vme crate to find the board and apparently for the first time it recognized the new GB hence messing up the correct fision handle for the old GB board. 
The fix is ugly and temporary until the new code for the new board will be finisched. <br> 
<U><B>Until then do not swap slot for the old GB for any reason!</B></U>
<!-- Author: Marco (I was first!) -->


<!-- Date: Tue Oct 1 12:55:04 2002 -->
I put in the repository the changes needed to accomodate the new GB firmware,as soon as there is a valid fit in any barrel: <br> 
<UL> 
<LI> The old GB look up is updated as before 
<LI> Beam Position values are rounded to 10 um 
<LI> The appropriate 20 bit word is written in the new GB for  
the barrel that has to be updated 
<LI> a vme write to the GB "mailbox" register write is executed   
</UL> 
 
I have tested the mechanism with a fakehits run. The updated beam position values ends up correctly in the L2 buffer for SVDD. 
The old mechanism is still in place and seems not to be broken. 
<p> 
All the SVT crate have been rebooted to pick minor tweaks to the obnoxious SPYMON printout (but on b0svt06 beam fit are always printed out now). <p> 
 
lastbeam.txt file has been restored  
  
<!-- Author: Marco  -->


<!-- Date: Tue Oct 1 18:20:01 2002 -->
<p> 
I put some tentative 'instructions' on database updates on these pages: 
<p> 
<a href="http://hep.uchicago.edu/cdf/ashmansk/doc/svtcheckconsts_20020929.html"> 
http://hep.uchicago.edu/cdf/ashmansk/doc/svtcheckconsts_20020929.html</a> 
<p> 
<a href="http://hep.uchicago.edu/cdf/ashmansk/doc/svtinstallconsts_20021001.html"> 
http://hep.uchicago.edu/cdf/ashmansk/doc/svtinstallconsts_20021001.html</a> 
<p>  
<!-- Author: Bill -->


<!-- Date: Tue Oct 1 18:25:35 2002 -->
<p> 
We created mapset 
<a href="http://www-cdfonline.fnal.gov/cgi/ops/cdf_svt/map?offline_100030_20021001110150"> 
offline_100030_20021001110150</a> 
and installed it.  This should get back B0W5 and B3W9. 
<p>
<!-- Author: Alex, Roberto, Bill -->


<!-- Date: Tue Oct 1 19:42:00 2002 -->
Since cdfsoftb0 changed version today, I had to  
rebuild SVTSPYMON to use the same root version as cdfsoftb0 new release (based on offline 4.8.3, meaning root v3_03_07c), since HistoDisplayMain was not able to display SVTSPYMON histograms any more;<p> 
 
We can now again connect with HistoDisplayMain to SVTSPYMON without problems. SVTSPYMON has obviously been restarted, 
using the instructions provided in  
<A HREF="http://www-cdf.fnal.gov/internal/upgrades/daq_trig/trigger/svt/svtspymon/consumer.html#instructions"> SVTSPYMON instruction page </A> and it worked !
<!-- Author: Marco  -->


<!-- Date: Wed Oct 2 10:58:09 2002 -->
We're going to lose B4WBL1, and we're going to have BC mismatches on B4WAL2, but we regain B4WA(0134) as of this access, according 
to Chris and Steve.  
<!-- Author: Bill -->


<!-- Date: Thu Oct 3 19:06:18 2002 -->
We wrote a new mapset to the database (now the default), 
updating .fcons to remove radial shifts and updating 
patterns/layerMap for B4W11 (becomes X0X1235).  
<!-- Author: Taka, Roberto, Marco, Alex -->


<!-- Date: Thu Oct 3 19:07:24 2002 -->
We temporarily disabled svtvme_fer.c's Merlin error message 
reporting, because it seems to crash Messenger under some 
not-yet-understood circumstances.  One can still see the 
messages by logging into the crate with vxlogin or minicom.  
<!-- Author: Taka, Roberto, Marco, Bill -->

<!-- Date: Fri Oct 4 05:29:35 2002 -->
<pre>
 
Merger b0svt07/10: EEreg=0011, FIFOMT=1111, InpEna=1100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, 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: Fri Oct 4 09:19:30 2002 -->

<pre>

From ashmansk@HEP.UCHICAGO.EDU Fri Oct  4 09:15:10 2002
Date: Fri, 04 Oct 2002 09:14:47 -0500 (CDT)
From: Bill Ashmanskas <ashmansk@HEP.UCHICAGO.EDU>
To: svt@fnal.gov
Subject: Diagnosing SVX/SVT/L2 errors (fwd)

---------- Forwarded message ----------
Date: Fri, 04 Oct 2002 10:13:40 -0400 (EDT)
From: Stephen Miller <miller@umaxp1.physics.lsa.umich.edu>
To: cdf_aces@fnal.gov
Cc: ashmanskas@fnal.gov, nahn@fnal.gov
Subject: Diagnosing SVX/SVT/L2 errors


One kind of error which showed up last night is when some part of the
SVX doesn't send all of its data to the SVT/L2 system.

 This error may first be reported as either a L2 Decision timeout,
or a L1 Done timeout depending on which system first catches the error.
In the errorlogger these will show up as

L2 ERROR:
(MLE) b0dap59.fnal.gov:AWT-EventQueue-0:5:56:19 AM->  Level 2 Decision
Timeout
(MLE) b0l2de00:Messenger:5:56:23 AM->SvtMonitor: Sync error in L2
pipeline, event 11872

SVX L1 Done Error:
(MLE) b0svx04:Messenger:9:36:32 AM->Silicon Timeout:!DONE- Slots:  08:e400


If you see just the L2 error in the errorlogger, then SVX is probably
not the cause and the error is in the L2/SVT  systems.
If you see both errors or just the Silicon Timeout, then the problem is
SVX related and SVX should be paged.

When the run is in the HALT state, it is useful to run Bill Ashmanskas'
script ~ashmansk/bin/whodunnit  to find out the source of the
error.

Another clue is to look at the alpha minicom.
If the error message
SvtMon: Error: no data from SVT(0)
 shows up, then the problem is likely upstream of L2.

As usual, first try HRR to see get the run going again. If errors
are persistent then look at the above error messages to determine who
to page.


                  Stephen Miller  (for the L2 group).

</pre>

<!-- Author: bill (forwarding stephen's message) -->


<!-- Date: Fri Oct 4 15:45:51 2002 -->
<pre>
 
Merger b0svt07/10: EEreg=1011, FIFOMT=0111, InpEna=0100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, Ena&!MT=0000
Merger b0svt00/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt00/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt01/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt01/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt02/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt02/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt03/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt03/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt04/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt04/16: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt05/07: EEreg=0111, FIFOMT=1000, InpEna=1000, Ena&!MT=0000
Merger b0svt05/16: EEreg=0111, FIFOMT=1000, InpEna=1000, 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: Fri Oct 4 16:27:12 2002 -->
<pre>
 
Merger b0svt07/10: EEreg=0011, FIFOMT=1111, InpEna=1100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, 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: Fri Oct 4 19:00:21 2002 -->
SVX problem in B4W1 L0&L1 causing repeated bc mismatch detected in the merger. Since error reporting was turned off the ACES did  
not get the proper message, vxlogin in  to the crate revealed the mystery, though. <p> 
 
We disable from hwset the automatic DTO generation from crate b0svt00. 
  
<!-- Author: Marco & Alex -->

<!-- Date: Sun Oct 6 08:01:36 2002 -->
<pre>
 
Merger b0svt07/10: EEreg=0011, FIFOMT=1111, InpEna=1100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, 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: Sun Oct 6 16:47:14 2002 -->
<p> 
On Roberto's advice (and after we both looked at the results 
offline), I entered a new set of .fcon files into 
the database and wrote offline_100030_20021006161555.mapset. 
This should eliminate the 30um impact parameter bias in odd 
halfbarrels (my bug). 
<p>
<!-- Author: Bill -->


<!-- Date: Mon Oct 7 22:25:01 2002 -->
While setting up to take a look at Giovanni's constraint-aligned .fcon files, I happened to check SVT against svtsim for run 
152598.  I see that svt/svtsim mismatch rate has jumped to 
0.8% of tracks, dominated by SB0W0 and SB1W0.  In these two 
wedges, about 2/3 of tracks have a mismatch.  There seem to be 
errors on hit positions in many different ladders.  The obvious 
next thing to check would be whether the errors correspond to 
the same bit in the HF output word; on a quick peek, it looks  
as if there are multiple bits that can be wrong.  A single FIB 
would not produce errors in such a pattern (2 FIBS map onto 
2 HFs), nor would most stuff downstream of a Hit Finder (which would see all 6 wedges together), so the problem is very likely the HF, its VTM, its output 
cable, or the corresponding Merger input.  Between stores, we should exchange 
hf_w00_b0b1 with a nearby Hit Finder and see if the problem 
moves. 
(I also notice that 
these two wedges are listed as ~35% efficient by the spycheck 
script.)
<!-- Author: Bill -->


<!-- Date: Wed Oct 9 16:10:05 2002 -->
disable sync error in last merger "mrg_final" (b0svt06/slot 20) 
as source of SVT_ERR, hence of FREEZE. We should see the  
beam fitter fed with more tracks now, and the SPY histogram too. 
In the meantime we should understand better what's going on with  
wedge 01 which is the primary cause of this problem. 
<!-- Author: Marco  -->


<!-- Date: Wed Oct 9 19:36:00 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-2&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-2  width='300' align='top'></td><td>This ACNET plots shows that the SVT beam finder was  effectively dead during the period in which Lost Sync  in the final mergers was triggering FREEZE at every event.  Evidently there were never enough track to perform a fit  since yesterday at ~ 9:00 p.m. when the problem first  appeared.</a></td></tr></table>
<!-- Author: Marco  -->


<!-- Date: Wed Oct 9 19:46:04 2002 -->
Have disabled streams in HF corresponding to SB4W1.  
This may help resurrect the adjacent SB5W1. The change will be effective from next run (current is 152461).<P> 
 
Also have disabled the Lost Sync as source of SVT_ERR in final merger for wedge 0-3 (b0svt06/slot 8), to avoid the automatic FREEZE in crate 6. I had overlooked this before.
<!-- Author: Marco  -->


<!-- Date: Thu Oct 10 06:34:40 2002 -->
<pre>SVT HF board (SVT VME b0SVT00; slot4; hf_w00_z0z1) was swapped. 
(Board#31 -> #50) 
This was recommendation from Bill. 
 
Also I swapped GB test board (b0SVT06; slot14) w/ new firmware. 
This swapping does not affect any main stream data. 
 
</pre>
<!-- Author: Taka -->


<!-- Date: Thu Oct 10 09:40:33 2002 -->
<p> 
Here, as of yesterday, is the list of wedges that have been 
continuously dead in SVT in recent days.  I meant to include 
this in my slides Tuesday. 
<p> 
B0W6, B1W7, B2W5, B2WA, B3W8, B4W1, B4W6, B4W8 
<p> 
Wedges that were "inefficient" most of the time: 
<p> 
B0W0, B0W3, B0WB, B1W0, B1W4, B2W7, B3W7, B5W9 
<p>
<!-- Author: Bill -->


<!-- Date: Thu Oct 10 15:22:39 2002 -->
<b>A note on SVT Timing.</b> 
With reference to the Logic Analyzer trace obtained by 
Franco & Bill on Sept 12: 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=49&frame=2&anchor=20:59:35'> 
click here for picture</a> <br> 
The times in the picture can all be explained in terms of what we know and expect about the system. Bottom line: that is it, and that way it will stay. With one caveat though. I looked in the test stand and Hit Buffer there (#14) has a 20MHz clock. The correct speed should be 25. There is no reason why it should be 20. Anyhow, with that slow HB, the picture is explained as follows: 
<ul> 
<li>HF=MRG=33MHz = 30 nsec ==> I derive about 220 hits 
<li>AMS=30MHZ = 33nsec ==> 7.2 usec to read all hits from FIFO, plus 1.1usec to get the 1st road out ==> 8.3usec from first DS out from meger (MRDS) to first road out from AMS (AMSDS) 
<li>HB=20MHZ = 50nsec ==> 11usec to read all hits from FIFO, the 
HB is still reading Hots when the AMS sends out the last road ! After 11usec + 5x50nsec = 11.25usec (5 clock cycle latency in the HB to precess the first road) the HBDS starts 
</ul> 
If the HB were to run at 25MHZ = 40nsec, it would read all hits 
from its FIFO in 8.8usec and thus be ready to process roads about at the same time they come from AMS, as was verified already in 1999 during vertical slice test.<br> 
Bottom line is that there is no "dark area" and that other then driving the HB as fast as we can, there is no way to improve.<br> 
The 5 clock cyle delay to process the 1st road in the HB comes from the simulation and is already "tight". The 1.1usec in the AMS from last hit read from FIFO to first road out is indeed long, but is due to the long pipeline down and up the 4 level 
glue tree in the AM and there is nothing that can be done, it was subject of much study in the late 90's and the AMS microcode is as optimized as it can, I verified at the time with both simulation and oscilloscope that there is no wasted clock cycle. 
<p> 
It would be nice if Franco and Bill can repeat the test with the correct clock chip in the HB, to confirm all this. 
<p> 
The only way to dramatic improvements is to redisign with new hardware. Of course having fewer hits will help in the meanwhile.
<!-- Author: Stefano -->


<!-- Date: Thu Oct 10 15:54:48 2002 -->
 Marco and Taka implemented some primitive code in svtvme_fer.c to write down beam position information from new GB using SVDD. This allows us to compare directly impact parameter of SVT track in svtsim  with real data. 
<P> 
Starting this store a new card is appended to the SVDD bank. 
It has a card type of 12 (instead of 10 in the usual one, i.e. 
a 0xc00ff appears instead of 0xa00ff as cardtype field).  
The 6 data words in this card should be decoded exactly as the one in the old SVDD. No status bit field is implemented for the time being. <P> 
 
When Taka will be able to confirm that everything is OK we will switch cables and exchange also the contents  of the two cards.
<!-- Author: Marco and Taka -->


<!-- Date: Fri Oct 11 18:16:52 2002 -->
I have added a new card with 3D beam fit information in SVDD. 
This card has ID of 11. It stores X,Y position and the two  
slopes as determined by Luciano's fit + a fit status word. <P> 
 
The rest of the information in SVDD (with the special data for Taka's test of new GB firmware) is untouched.  
<!-- Author: Marco  -->


<!-- Date: Sat Oct 12 15:06:34 2002 -->
<pre>The SVT-COT phi matching got worse recently, it jumped from 3.5 to 4.5 
mrad, see fcdfsgi2:~oldeman/runsum/runsum.ps, page 9. 
   
There seems to be a 'slow wiggle' in the dphi vs phi plot, see for example 
fcdfsgi2:/cdf/scratch/oldeman/svttup/run152746.ps, page 15. 
 
We may be loosing a few percent in the COTSVT matching in L3 
</pre>
<!-- Author: Rolf Oldeman -->


<!-- Date: Sat Oct 12 15:39:03 2002 -->
<pre>Taka swapped test SVT-GB board again.  
 (b0svt06, slot14, board#003 -> 004) This is for bug fixing.  
(Note that this swapping doesn't affect anything about main  
stream data.) 
 
Yesterday, Marco and Taka found SVDD beam position from new GB  
sometime only has offset value. In the case that L2Buffer=1,2  
and 3,vme read out from new GB has 0 value. (Imidiately after it, 
svtmon.c added offset value. So, SVDD has only offset value)  
Marco, Alex and Taka confirmed it. This bug was due to firmwair 
bug, recognition of L2buffer was wrong. 
 
So, Taka fixed this part and confirmed using board simulation and  
standalone test. Then swapped again.  
 </pre>
<!-- Author: Taka, Marco and Alex -->


<!-- Date: Sat Oct 12 22:38:31 2002 -->
<p> 
Since the beginning of the store b0svt01 is throwing timeouts 
due to a sync error in b0svt01/04 aka HF3 for wedge 2 
which means B4-5/w2. Looking at marco's b0svt01_20021012215555.dat we see a bunch ID repeated twice in 
stream 1 from the HF in slot 04. We're not sure about the 
ladder<->HF streams map but there has been a swap from the silicon folks during this afternoon's access. Thwy swapped 
a fib (SB4W2-3).... paged Jason who's coming here... in 
the mean time we decided to mask the DTO mechanism from 
b0svt01. Since the ad-hoc initialization of SVT is no 
longer possible when the Si is integrated we had to 
commit a new change to the hwset database entries  
</p>
<!-- Author: Alex and Taka -->
<!-- Comment: Sat Oct 12 22;48;40 comment by...Alex and Taka -->
<pre>Ok ok.... here's the real information.... we messed up the numbers up there:
the error is in b0svt01/06, the spy dumps reveal problems in 
B5W2L1 (it's stream 1 in b0svt01/06).</pre>


<!-- Date: Sat Oct 12 23:50:48 2002 -->
<p> 
We just realized that B4W1 is completely masked off 
in the hwset. THe fib errors should be fixed since 
10/11 so we decided with Al that we should try reviving 
that wedge... just committed a new change to the svt 
hwset. 
</p>
<!-- Author: Alex and Taka -->


<!-- Date: Mon Oct 14 15:32:05 2002 -->
<pre><P> 
Just replaced HF in b0svt00/04 i.e. wedge 0 barrels 0-1. 
This is the HF Bill suggested to swap because we suspect 
it's producing errors from time to time. 
 
Old HF: serial number 50 is in the test stand UNPLUGGED 
New HF: serial number 31 is happily sitting in b0svt00/04 
        The fake-event test runs fine. 
I'm going to give SVT back to the ACE 
</P></pre>
<!-- Author: Alex -->
<!-- Comment: Mon Oct 14 18;27;29 comment by...Alex -->
<p>
If something, this is the proof
that what is done can indeed be undone.
Or, better said, I should read carefully
the e-log before fixing things:
I managed to put back exactly
the faulty board, according to
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=1&frame=2&anchor=06:34:40'>
Taka's entry in the e-log.</a>.
I'll fix things rightaway: board 31 is going
back to the test stand, board 50 goes back in wedge
0
</p>

<!-- Comment: Tue Oct 15 11;40;41 comment by...Stefano -->
Boars removed from SVT crates because bad of suspicious, should
not be simply put back in test stand. They must be labeled. I.e. a piece of paper attached to them.


<!-- Comment: Tue Oct 15 13;11;23 comment by...Alex -->
<p>
Thats in fact what I did. There's a piece of tape on 
the HF output that should let anybody who tries to useit aware at least of the fact that the board is suspicious.
It would be nice to have a "purgatory" cabinet or something
where we can sit suspicious boards instead of using the
test stand.</p>
<!-- Date: Tue Oct 15 11:47:43 2002 -->
I changed clock on HB14 to 25 MHz. This is the HB in the test stand, see <a href= 
'/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=1&frame=2&anchor=15:22:39'> 
used for timing studies </a>  
After this I found a low level (1/10^4) single bit error rate 
running the random test in the test stand. This is a "known" timing error, I think it will go away in the cooled crate. Unless is a side effect of Franco's added test point on DS_ line. See 
<a href="http://www-cdf.fnal.gov/~belforte/logbook.html">HB FNAL logbook</a>. It is worth trying the board in a cooled crate before touching it with the solder gun again.
<!-- Author: Stefano -->
<!-- Comment: Sat Oct 26 13;32;11 comment by...Stefano -->
The error rate was actually less then 1/10^6 output words. And showed up about 1/10^4 iterations of the random test.
<!-- Date: Tue Oct 15 20:31:23 2002 -->
SVT crates have been rebooted tonight. There are changes in 
svtvme,SVTbeam and svtmon package as follows:<UL> 
<li> <b> svtvme: </b> TevStore number is now shipped correctly to SVT crates in the configuration message. This allows to clear the SVTbeam statistics at each new store 
<li> <b> svtvme: </b> the Merlin error reporting has been reenabled (no crashes observed today), watch out for SVT crate hangs! 
<li>  <b> SVTbeam: </b> SVTbeam_initForce function allows to force the initialization of  SVTbeam package  
<li> <b> svtmon: </b> Introduces different timers for most common SPYMON task. Main time interval between cycles is controlled indipendently from spybuffer dump and sending of histogram through smartsocket. The default now are the following: 
<UL><br> 
<li>   main interval is 60 sec except in crate 6 where it is 2 sec 
<li>  dump and histogram update every 30 sec 
</UL><br> 
To change the above settings, the experts may use VxWorks shell commands that are now provided :<UL><br> 
<li> svtMainInterval  (int sec)    - change main interval 
<li> svtHistoInterval (int sec)   - change histogram interval 
<li> svtDumpIneterval (int sec)   - change spy dump interval 
</UL> 
</UL> 
<p> 
The effect of the above changes will be to have a valid beam fit in approximately 1/5 of the previous time without flooding the network with unnecessary messages. Also the SVTbeam statistic and valid flag will be reset at each new store. 
<!-- Author: Marco  -->


<!-- Date: Thu Oct 17 06:48:01 2002 -->
Test SVT-GB was replaced again. (b0svt06, slot14, board#004->003) 
This swapping is to confirm L2buffer beam position from new GB 
which was in create is really fine or not. (This changing is not 
related to main stream data anyway)  
<p> 
Also, I shanged firmware slightly to be smart for beam valid flag transfer though it is invisible for outside data. This does not affect beam position issue, basically. 
</p>  
<!-- Author: Taka -->


<!-- Date: Wed Oct 23 16:25:47 2002 -->
Two new things; 
<p> 
 (1) Taka swapped test SVT-GB board again. (b0svt06, slot14, board#003->004). This board has firmware with current best version to fix "inhibit timing problem". Previosly, GB allows 
VME to write beam position in "non-processing timing", so that 
VME sometimes fail to write it. (In terrible case, some barrels 
were updated, but the others were not updated). Current scheme 
allows VME to write beam position anytime.  
</p> 
(2) Marco found one possibility of sign bit problem. The code to 
read beam position from new GB, "svtvme_fer.c", never knows existing of "beam valid flag" in 21st bit in beam position bit. 
So, it can confuse sign bit and beam valid flag. 
This is due to lack of information from Taka to Marco, mainly. 
</P> 
<!-- Author: Marco and Taka -->
<!-- Comment: Wed Oct 23 17;25;13 comment by...Marco  -->
<pre>b0svt06 was rebooted to pick up the above mentioned fix in new SVDD readout, not yet default one.</pre>


<!-- Date: Sat Oct 26 13:30:34 2002 -->
I teared apart SVT test stand to test HB#14 in cooled crate b0l2de01. I removed from test stand the HB and two mergers (XTF-C actually). If spare mergers/HB are needed in a rush, feel free to take them from b0l2de01 regardless of my test being running, just pull the board out, the test program will stop at that time. 
<br> 
HB#14 is the one that was giving errors once/10^4 iterations of the random test in the test crate. It seems to work better now, wait for more statistic. 
<br> 
I could not make a SpyControl work on that crate. Do not know whey. Should be investigated.
<!-- Author: Stefano -->
<!-- Comment: Sun Oct 27 09;17;12 comment by...Stefano -->
The Spy Control problem turned out to be that the SC#14 that
I took from teh spare cabinet had no quartz. I sent e-mail to Franco asking him to make sure all spare SC's are usable.
<!-- Date: Sat Oct 26 17:25:27 2002 -->
I asked the silicon group  
<a href=  
'/cgi/elog/elog.pl?nb=2001&action=view&page=27&frame=2&anchor=09:11:33'> in their e-log</a>  
to look at the events (now sent to the error stream) where 
the silicon trigger data path hangs.   I cross reference it 
here in case you are interested too.
<!-- Author: Saltzberg -->
<!-- Comment: Sat Oct 26 17;26;39 comment by...DS -->
<pre>Rats, the URL cross reference didn't work.</pre>


<!-- Comment: Sun Oct 27 09;22;17 comment by...Stefano -->
Here is a new
<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=128&frame=2&anchor=22:45:47'>URL</a> to the SVX logbook that works. 


<!-- Date: Sun Oct 27 13:37:28 2002 -->
<pre>I replaced test SVT-GB again. (b0svt06, slot#14, board#004->003) 
This is to check new firmware for double buffering scheme. 
(Anytime, we can write beam position via VME and flag up "mail  
flag". This GB finds proper timing to update beam information for 
impact parameter correction.) 
Note that nothing will be happened in main stream data.</pre>
<!-- Author: Taka -->


<!-- Date: Mon Oct 28 12:18:22 2002 -->
<p> 
Updated the SVT mapset according to roberto's latest... 
Now we are using the following configurations: 
</BR> 
B1W0 (XX01235)</BR> 
B0W3 (X012X35)</BR> 
B2W8 (XX01235)</BR> 
</P>
<!-- Author: Alex -->


<!-- Date: Wed Oct 30 10:36:41 2002 -->
<pre>History of yesterday. 
We replaced 3 baords in b0svt00/wedge0 to measure SVT timing. 
We put in boards modified with test points on front panel. 
We found that the AMS that was put in was not working and left current one (#201) in. 
We made the floowing swaps: 
HB#14 from test stand to b0svt00/11 
MRG#3 from test stand to b0svt00/7 
HF#8 from test stand to b0svt00/6 
 
The boards that we removed from b0svt00 are now in the test stand, they are: 
HF#29 (from wedge00_b4b5) 
MRG#18 (from wedge00) 
HB#3 (from wedge00) 
 
</pre>
<!-- Author: Stefano, Franco, Alex -->


<!-- Date: Wed Oct 30 10:42:44 2002 -->
About the "bad AMS". We looked at it in the test stand and came to the conclusion that a"at least" it does not properly send HOLD on input and gets it Hit fifo overflown. Franco swapped the modified front panel on the last spare AMS from the cabinet (#216) and this time our test of running FAKEHITS hists through it was working.
<!-- Author: Stefano and Franco -->
<!-- Comment: Thu Oct 31 11;23;02 comment by...Stefano -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>I tested the hold mechanism of AMS#210 in the test
stand putting it in test mode and sending data to it.
It works perfectley. Much more investigations is needed.
</pre></td></tr></td></table>
<!-- Date: Wed Oct 30 10:43:58 2002 -->
<pre>Taka niticed that since yesterday, after we swap the boards in wedge00, the rate of mismatch svtsim/data on w00 z=4 and 5 has increased 100fold. This correspond to the swapped HF. Alex reseated it at 10am. We'll see.</pre>
<!-- Author: Stefano -->
<!-- Comment: Wed Oct 30 13;09;25 comment by...Stefano, Alex, Marco -->
<pre>Could not take data (L3 problems) after reseat. FOr next store we prefer to minimize changes and put back previous HF#29</pre>

<!-- Comment: Wed Oct 30 13;11;59 comment by...Alex Marco Stefano -->
<pre>Swapped out HF # 08 (B45W0) for HF # 29. HF #08 is in the test stand now.</pre>


<!-- Date: Wed Oct 30 13:17:23 2002 -->
Hit Buffers location after latest work/swap has been updated, please use SVT web pages to lookup the HB situation and 
make sure it is kept updated if/as you swap HB's around. 
 http://www-cdf.fnal.gov/upgrades/daq_trig/trigger/svt/BoardDocs/HitBuffer/miscellanea/HB_slots.html 
  
<!-- Author: Stefano -->



<!-- Date: Thu Oct 31 14:35:33 2002 -->
<pre>The new HF in b0svt00/6 (serial 29) is working fine. 
 
From Vladimir: 
The same run (153557) on the stream H 
 gives  2 failures 
   from 3658 processed events 
 
 ratio = 0.55 E-03 
 
so it is  consistent with stream A... 
 
 
</pre>
<!-- Author: Stefano -->


<!-- Date: Thu Oct 31 15:00:49 2002 -->
Swapped AMS in wedge 0 (b0svt00 slot 8) with AMS#216 which 
now has test points in front panel.  The bad AMS (#210) is in 
the test stand for debugging. We verified that the AMS we put in: 
<ul> 
<li> passes cold start 
<li> passes data through 
<li> SPYMON histograms from wedge 0 are OK 
</ul> 
We also connected logic state analyser to L1A,MRG,AMS,HB,TF and it all works. Franco has put toghether a program to acquire timing information to his laptop.
<!-- Author: Stefano & Franco -->


<!-- Date: Thu Oct 31 15:39:44 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030>I have looked at AMS #210. 
It is difficult to describe exactely. But I think one of the two FIFO chips on the input is broken. The fifo for the upper 16 bits behaves in a very odd way once it has been filled by writing until hold is generated. Something like 8 words are read from bottom of fifo, 8 from top of fifo, and so on. I do not think I'll be able to pursue this more, it should be investigated in detail by Geneve group. They may wnat to make sure they obtain a reproducible problem situation, replace the bad FIFO chip, run again.</td></tr></td></table>
<!-- Author: Stefano -->
<!-- Comment: Mon Nov  4 08;47;20 comment by...Yanwen  -->
<pre>Hi Stefano,  

	How did you test the hit fifo? 
Did you use ams_HitFifoCheck in ams_func.h ?
</pre>
<!-- Comment: Mon Nov 25 08;50;56 comment by...Stefano -->
<pre>HOW TO TEST AMS # 210
--------------------------

procedure to reproduce the problem with AMS board serial 210
This board failes if data are sent while the fifo is full,
i.e. when data flow into the board is throttled by the AMS hold.
Note that the HOLD itself does work. It is not a problem with
hold generation !

The test requires one merger board, plus the AMS.

Needed software: ams_menu and merger_menu
I suggest using two windows.

Following is example of how to do this on current SVT test stand
(output has been edited for readibility) UPPER CASE IS FOR COMMENTS

AMS_MENU                               MERGER_MENU
ams_menu			       merger_menu
cp tstsvt1			       cpu tstsvt1
sl 8				       slot 7
dr 100				       te
ID Prom read :      THIS CONFIRM       ims 0
0210 032SVT AM S    BOARD # 210	       oms 0
equencer Feb2000		       sww 1f   MAKE SURE HOLD FROM
USQ_OREG 17 Aug					HB IS DISABLED
ia		    CEAR FIFO
te
AMS: tstsvt1 slot 8 : tc

 Test Mode status : 1   MAKE SURE AMS
                        IS IN TMDE
AMS: tstsvt1 slot 8 : fs
Hit FIFO Status : 001    = EMPTY

NOW BOARDS ARE READY FOR TEST. FIRST THING IS TO FILL AMS FIFO
FROM MERGER_MENU:
Merger: tstsvt1 slot 7 : osi
offset and number of words to write (hex dec): 0 4
address 0: data word (hex)? ff
address 4: data word (hex)? ff
address 8: data word (hex)? ff
address c: data word (hex)? ff
 4 words written. 
Merger: tstsvt1 slot 7 : 
oms 2

NOW THE MERGER IS CONTINOUSLY SENDING 0xff TO AMS AND
FILLING ITS FIFO UNTIL HOLD ARRIVES
CHECK AMS_MENU:
AMS: tstsvt1 slot 8 : fs
Hit FIFO Status : 010   = HOLD + NOT_EMPTY

READ SOME WORDS FROM AMS FIFO:
AMS: tstsvt1 slot 8 : fb
 Number of words to read in the Hit FIFO (dec): 10
 Hit FIFO read with status: 10
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
AMS: tstsvt1 slot 8 : 

THAT IS AS IT SHOULD BE.
NOW STOP MERGER LOOP. IN MERGER_MENU
 Merger: tstsvt1 slot 7 : oms 0
Enter value (hex): MERGER TmodeOUTD Set to 0 
Merger: tstsvt1 slot 7 : osw
MERGER Out Spy Register Reset  

NOW CHANGE THE DATA WORD SENT FROM MERGER:
 Merger: tstsvt1 slot 7 : osi
offset and number of words to write (hex dec): 0 4
address 0: data word (hex)? ff000
address 4: data word (hex)? ff000
address 8: data word (hex)? ff000
address c: data word (hex)? ff000
 4 words written. 

NOW START MERGER LOOP AGAIN, SINCE THE AMS IS ASSERTING
HOLD NOTHING WILL BE SENT UNTIL AMS FIFO IS READ
 Merger: tstsvt1 slot 7 : oms 2
Enter value (hex): MERGER TmodeOUTD Set to 2 

NOW READ AMS FIFO AGAIN, FROM AMS_MENU
AMS: tstsvt1 slot 8 : fb
 Number of words to read in the Hit FIFO (dec): 16
 Hit FIFO read with status: 16
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
AGAIN
AMS: tstsvt1 slot 8 : fb
 Number of words to read in the Hit FIFO (dec): 6
 Hit FIFO read with status: 6
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
AMS: tstsvt1 slot 8 : fb 16
 Number of words to read in the Hit FIFO (dec):  Hit FIFO read with status: 16
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff0ff = 0001111 11110000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 
ff = 0000000 00000000 11111111 

AS CAN BE SEEN AFTER THE FIRST 6 WORDS THE READING FROM THE AMS
FIFO IS ALTERNATING 8 COPRRECT WITH 8 BAD WORDS. CORRECT BEHAVIOR WOULD
BE TO READ 0XFF 4000 TIMES (THE FIFO DEPTH) THEN 0XFF000 FOREVER,
INSTEAD THE LOWER BIT FIFO ARE OK, WHILE THE UPPER BITS FIFO SENDS
8 TIMES THE CORRECT DATA (0) THEN 8 TIMES THE DATA THAT ARE BEING
SENT NOW (FF) LIKE IF IT WERE ALTERNATING READING FROM THE TOP
INSTEAD OF THE BOTTOM OF ITS INTERNAL MEMORY. IT ALL LOOKS LIKE
ONE BIT INTERNALLY TO THE FIFO IS BROKEN.</pre>
<!-- Date: Sat Nov 2 17:29:40 2002 -->
<pre>The program to study SVT timing is ready. It can be found on the  
NT server, spinella/SVT_TIMING . Runs on windows machine  
and requires a GPIB interface.  
I runned it for about 3 hours last night. I attach the histogram 
of the measured L1A to TF_EE times for 460 events in 3 hours  
of run.  
</pre>
<!-- Author: franco -->


<!-- Date: Sat Nov 2 17:34:32 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-5&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-6  width='300' align='top'></td><td>here it is the histogram</a></td></tr></table>
<!-- Author: franco -->



<!-- Date: Thu Nov 7 12:53:53 2002 -->
Test of the new coldstart and spymon code for the new GB board:<br> <UL> 
<li> svtvme/svtmon code exists in my area ~rescigno/scratch/svtmon (svtvme) </li> 
<li> took SVT crate today to test the whole meachinism with fakehits </li> 
<li> coldstart is able to write last beam fit on new GB board 
and initialize the timing part of the old GB. No other initialization is currently needed for this board </li> 
<li> we have swapped the cable temporarily and tested the whole procedure including the beam fit with fakehitsNEWGB.hwset (in the svt_config area) </li> 
<li> testGB.hwset is ready to be loaded in the database as default when the actual switchover will happen 
<li> the last missing piece to write is the ability to write at coldstart the sin/cos table in new GB flashram. We overlooked this yesterday and Alex reminded us this point... 
<li> svtsim will be able to recognize the presence of the new board (especially for what the phi correction matters) with a special switch introduced in the hwset  
</UL>  
<!-- Author: Marco & Taka & Alex -->


<!-- Date: Wed Nov 20 10:28:58 2002 -->
<pre>The Merger in slot 7 crate b0svt00 has been reprogrammed. 
The new firmware allows the Merger to work both in 
deterministic and in non deterministic mode. A test with 
fake data has been performed by Stefano and it has been checked 
that the output spy of the track fitter looks reasonable 
and similar when comparing two set of data taken with the 
Merger in determ. e non determ. mode.</pre>
<!-- Author: Anna Maria -->
<!-- Comment: Wed Nov 20 12;25;47 comment by...Stefano -->
At present that merger is in deterministic mode. It will stay that way until explicitely changed, or reseated, or the crate is power cycled. If in doubt, check with dmr command in meger_menu, it should be 1. It can be changed with dms command in merger_menu if needed, the merger has to be in test mode in order to do it.


<!-- Date: Thu Nov 21 10:44:59 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-8&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-8  width='300' align='top'></td><td>Blow up of the output timinig of the merger. Clearly visible the time strucutre of hits from the 3 HitFinders. Note the gaps in the first HF data. Non-deterministic mode should make those gap go away. </a></td></tr></table>
<!-- Author: Stefano -->


<!-- Date: Thu Nov 21 10:49:17 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-9&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-9  width='300' align='top'></td><td>LSA timing for wedge0 in deterministic mode. Previosus image is a blow-up of this one.</a></td></tr></table>
<!-- Author: Stefano -->


<!-- Date: Thu Nov 21 15:10:54 2002 -->
<p> 
We added initialization of the MRG_DETERMINISTIC register for 
Merger boards to function mrg_coldstart in svtvme_fer.c.  We 
committed the changes to CVS, updated development svtvme, and 
rebooted b0svt00 to try it out.  It seems to do the right thing, 
both for the old Merger firmware (wedge 1) and the new Merger 
firmware (wedge 0).  The default in the C code is '1' (which 
would emulate the old behavior), and the value we put in the 
latest .hwset file (we updated it) is also '1'.  So nothing 
should change right now. 
<p>
<!-- Author: Anna Maria and Bill -->


<!-- Date: Thu Nov 21 15:13:20 2002 -->
<p> 
Oh, what the hell, we turned MRG_DETERMINISTIC to '0' for 
Wedge 0.  Interesting results expected on logic analyzer. 
<p>
<!-- Author: AMZ, WJA -->
<!-- Comment: Sat Nov 23 15;16;49 comment by...Stefano -->
<pre>Looked with LSA during data taking with SVX, merger output DS now appear to be without gaps, as it should ! Will try to cumulate statistics with Franco's program when SVX is up again.</pre>



<!-- Date: Tue Nov 26 16:37:16 2002 -->
<pre>I tagged current svtvme development version as v2_6 and made it 
 current. I also changed the boot instructions for the SVT crate 
 to use svtvme current instead of svtvme development 
 
I.e. I modified the file 
 /cdf/code-common/cdfonline/vxboot/ups/svtb.table 
 
The modification is: 
 
cdf_svt@b0dap30/ups#25&gt; diff svtb.table svtb.table~ 
63,64c63,64 
&lt; #     setupRequired(-j svtvme -d -q ${_dest_arch}) 
&lt;       setupRequired(-j svtvme -q ${_dest_arch}) 
--- 
&gt;       setupRequired(-j svtvme -d -q ${_dest_arch}) 
&gt; #     setupRequired(-j svtvme -q ${_dest_arch}) 
 
 
I.e. I moved the comment sign (#) from the line 
with "normal" svtvme, to the line with the -d qualifier. 
 
This can be undo at any time as needed, just ksu cdf_svt 
</pre>
<!-- Author: Stefano -->
<!-- Comment: Sat Nov 30 21;07;23 comment by...Marco  -->
We have to make attention here that svtmon (aka SPYMON) depends on svtmon. For this reason we use to rebuild the vxworks version of svtmon each time we update svtvme library (i.e. the developmnet version).
In this way, though, we must load the same version of svtvme in the crate that was used to build svtmon. If the two versions disagree we may have the troubles seen today (Saturday 11/30). 
I have temporarily fixed this by cutting a release of svtmon
(v1_9), declaring it current, building it with the "current" svtvme version (instead of the development as in the development svtmon version), and instructing the crate to load and run the "current" versions of both svtmon and svtvme. Everything seems now to be working....


<!-- Date: Tue Dec 3 14:04:01 2002 -->
<pre>Annamaria update the firmware of all the mergers in b0svt00-b0svt07.  
Now the processing time should be smaller. 
A request to everybody: PLEASE HANDLE THE SVT CABLES 
WITH CARE, BOTH FOR THE SAFETY OF THE CABLES AND THE 
ON-BOARD CONNECTORS. THERE ARE A COUPLE OF CABLES WHICH 
HAVE BROKEN CONNECTORS DUE TO MISUSE/ABUSE. THIS IS VERY 
DANGEROUS ESPECIALLY ON THE ON-LINE CRATES! IF YOU 
BREAK A CONNECTOR OR A CABLE YOU HAVE THE RESPONSABILITY 
OF EITHER REPLACING IT AND MAKING SURE THAT IT WORKS 
OR AT LEAST PAGING THE ON-CALL EXPERT AND NOTIFY THE PROBLEM. 
EVEN IF YOU THINK THE PROBLEM IS NEGLIGIBLE. LOOSE CONNECTORS 
AND OR DAMAGED CABLES ARE UNACCEPTABLE.</pre>
<!-- Author: Alex -->


<!-- Date: Wed Dec 4 00:59:25 2002 -->
Test of cold start w/ new GB is successfuly done. There 
<br> is no errors within 10 cold starts. 
<br>This update aims (in addition to previous our 
    modifications.); 
<br> (1) If GB FRAM table is lost, this automatically recovers. 
<br> Error handling is same as other boards. 
<br> 
<br> Only remaining things to do is 
<br> (a) Download new hwset and mapset 
<br> (b) swapping cables 
<br> It takes only 20 minuites or so. We will do these in proper timing.
<!-- Author: Taka and Marco -->

<!-- Date: Fri Dec 6 00:59:55 2002 -->
<pre>
 
Merger b0svt07/10: EEreg=0011, FIFOMT=1111, InpEna=1100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, 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=1000, InpEna=1111, Ena&!MT=0111
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=1000, InpEna=1110, Ena&!MT=0110
 
Ena&!MT summary: 00000000000000e006
 
</pre>
<!-- Author: svt whodunnit script -->


<!-- Date: Fri Dec 6 01:33:06 2002 -->
<pre>
 
Merger b0svt07/10: EEreg=0011, FIFOMT=1111, InpEna=1100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, 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=1000, InpEna=1111, Ena&!MT=0111
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=1000, InpEna=1110, Ena&!MT=0110
 
Ena&!MT summary: 00000000000000e006
 
</pre>
<!-- Author: svt whodunnit script -->


<!-- Date: Fri Dec 6 01:39:58 2002 -->
<pre>
 
Merger b0svt07/10: EEreg=0011, FIFOMT=1111, InpEna=1100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, 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=1000, FIFOMT=0111, InpEna=1111, Ena&!MT=1000
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: 000000000000001000
 
</pre>
<!-- Author: svt whodunnit script -->


<!-- Date: Fri Dec 6 01:43:30 2002 -->
<pre>
 
Merger b0svt07/10: EEreg=0011, FIFOMT=1111, InpEna=1100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, 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=1000, FIFOMT=0100, InpEna=1111, Ena&!MT=1011
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=1000, InpEna=1110, Ena&!MT=0110
 
Ena&!MT summary: 00000000000000d006
 
</pre>
<!-- Author: svt whodunnit script -->



<!-- Date: Fri Dec 6 02:01:17 2002 -->
Alex just came in in his pajamas and expertly debugged an SVT data 
flow problem.  I got to watch this from home, because Bill F 
is a believer in parallel processing.  Probably Alex will give 
the details about what was going on in SVT Wedge 0 that was 
affecting the data flow.  But here are some things that come 
to my mind that might make it less necessary for Alex to be 
called in in the future .... 
<p> 
The SVT 'whodunnit' script pointed fairly quickly to suspicious 
behavior in Wedge 0, which Alex was then able to figure out in 
about 10 seconds.  We might want to pursue the idea of the crate CPU polling 
all of the Mergers' EE registers on a HALT transition to see if 
anything looks suspicious, and issue a message to R_C if so. 
<p> 
David Saltzberg suggested at some point that it would be nice if 
SVT reported on its own cases in which it notices that it did 
not send data for a given L1A.  I think this could be implemented 
as a timeout in the GB (from L1A to SVT EE).  Or if we just do 
the above Merger register polling on HALT, L2 will report the 
error, but at least we'll then confess to being the cause, and in 
some cases point the finger back to SVX. 
<p> 
It would be nice to have a more realistic flow of data through 
all of SVT even when SVX is off, so that an internal SVT data 
flow problem can be detected before silicon is integrated. 
<p>  
<!-- Author: Bill -->
<!-- Comment: Fri Dec  6 11;20;45 comment by...Bill -->
One other thing I thought of but forgot to write down: many of the mergers' spy buffers, particularly in crate 6, are not 
dumped into the log files, so they don't provide information
about which channel didn't send data when this kind of error
occurs.  While the volume of data for a full spy dump may be
way too big for all of these channels, maybe just the last
10 or so end-event words from each merger channel would provide
enough information to debug this kind of thing.


<!-- Comment: Fri Dec  6 11;23;36 comment by...... -->
Here's a 
<a href=
'/cgi/elog/elog.pl?nb=2002&action=view&page=1017&frame=2&anchor=02:01:54'>link</a> to Alex's shift e-log entry.




<!-- Date: Sat Dec 7 12:17:05 2002 -->
Thanks to Bill Foster and Henry (WL) for this <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=1017&frame=2&anchor=03:07:02'> 
little quote </a> :p 
  
<!-- Author: Alex -->


<!-- Date: Tue Dec 10 02:37:06 2002 -->
New GB cold start w/ real run controller was tested on last Saturday and Sunday. (Actually, if coldstart succeeded, fakehits 
were planed to test). 
<br> But, cold start fails in reading FRAM contents to make sure 
stored data is consistent with memory array should be installed. 
<br> We are not sure what was wrong, but switchinig to read mode 
or FRAM reseting in firmware might be source of this error. 
<p> 
Now, I investigated this.(And this Monday, Marco had same problem.)  
<!-- Author: Taka -->


<!-- Date: Thu Dec 12 17:38:45 2002 -->
<pre>I am going to stop SVTSPYMON in a moment for a while in order to test the problem connecting to b0dap75. </pre>
<!-- Author: Subir -->
<!-- Comment: Thu Dec 12 19;06;02 comment by...Subir -->
<pre>SVTSPYMON is running again and may be connected in the usual way from HistoDisplayMain.

Well, took me quite a while to play with Root versions. Requires
-&gt; setup root v3_03_07c -q GCC_2_95_2
for successful connection from HistoDisplayMain which uses
  -&gt; setup root v3_03_09a -q KCC_4_0

So, if you have to restart SVTSPYMON do 

-&gt; ksu cdf_svt
-&gt; rlogin b0dap75
-&gt; source ~cdfsoft/cdf2.cshrc
-&gt; setup svtmon -d
-&gt; setup root v3_03_07c -q GCC_2_95_2
-&gt; svtspymon  

The fix is temporary and we must resolve the problem of Root versions once and for all. </pre>