<!-- Title: 21:11:17  Sat Oct 14 2000 -->
<!-- Crewchief: Bill Ashmanskas -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Start a new file, as of 2000-10-14 21:12  


<!-- Date: Sun Oct 15 22:33:43 2000 -->
Fixed memory leak in svtvme_initialise_generic() that 
was (I think) the cause of the 1.25MB/hour leak in 
b0svt0[12].  Track Fitter coldstart now runs as part 
of R_C startup.  Hit Finder code now capable of reading 
"register file" if it exists, for tweaking register 
contents without recompiling.  Also, barrel numbers are 
parsed from metaKey value now.  
<!-- Author: Bill Ashmanskas -->


<!-- Date: Sun Oct 15 22:48:59 2000 -->
Changed spy buffer monitor sampling time from 1 second to 10, 
so that we have the possibility to see more roads.  This will 
take effect next reboot. 
<p> 
Disabled stream 8 in crate 1 HF and stream 7 in crate 2 HF, 
since they don't seem to be read out by FIBs.  I hope this 
eliminates lost sync errors seen by hit finders.  This will 
take effect next coldstart.  
<!-- Author: Bill -->


<!-- Date: Mon Oct 16 01:06:24 2000 -->
That didn't eliminate HF lost sync errors, oddly enough.  Needs 
more investigation. 
<p> 
By the way, I noticed the other day while poking around with 
the TXPT that the TXPT connection to b0svt00 seems not to work, 
and that the connections to b0svt04 and 05 seem to be reversed 
(as were the ones to b0svt02 and 07 before JDL and I swapped 
them).  
<!-- Author: Bill -->


<!-- Date: Mon Oct 16 18:49:09 2000 -->
Alexei Semenov is running AMboard random test. 
He found that the svtvme_mon task was interfering 
with his test, so we stopped the monitoring for 
the moment.  We should reboot the crates when this 
overnight test is finished (to restart the monitor).
<!-- Author: Bill -->


<!-- Date: Mon Oct 16 20:43:49 2000 -->
We could take a short run with svt_spy_manager alone. DAQ collected 20K events with no errors. Now there is some evidence 
that all the problem found over the last week-end were due to accidental coincidences. There was also a trial with an svt crate. Failed for some known reason, that's good news! 
Give back all the svt crates for overnight tests.  
<!-- Author: marco r.  -->


<!-- Date: Mon Oct 16 21:56:17 2000 -->
svtvme library now stores run number from readout list and 
writes it out with monitor message.  Also, parity bit of 
pseudo-xtrp data had been miscalculated--oops.  (Stefano 
had computed the right answer, and Bill convinced him 
(incorrectly!) that he was wrong ....)
<!-- Author: Bill -->


<!-- Date: Tue Oct 17 12:44:19 2000 -->
I am done with the test of the updated coldstart.  Will post 
results later.  I have removed the Track Fitters from the 
configuration message for now, because it appears that we need 
to exercise the coldstart code a bit more.  
<!-- Author: Bill -->
<!-- Comment: Tue Oct 17 23;22;37 comment by...Bill -->
I get the expected fake roads out when I run the updated
coldstart code, so it seems OK.  The Track Fitters are
back in.
<!-- Date: Tue Oct 17 19:08:32 2000 -->
We got a chance of running the svt spy monitor with the hardware event builder after event builder people finished their work (around  6:00 p.m.) but then the svt cold start failed because of unanticipated changes in the merger config files. We give all the crate back to Alexei for overnight am board test.  
<!-- Author: marco r. -->


<!-- Date: Tue Oct 17 19:58:49 2000 -->
<pre>I am running AMboards random test for overnight.</pre>
<!-- Author: Alexei -->


<!-- Date: Tue Oct 17 20:26:49 2000 -->
<pre>Stefano and Bill cleaned/changed all REG files for cold start 
in svt_config to make switch settings readable, accurate and 
commentable. This lasted more then anticiapted and caused some 
troubles to Marco. Apologies, now works.</pre>
<!-- Author: Stefano belforte -->


<!-- Date: Tue Oct 17 20:30:29 2000 -->
<pre>Changed some SVT baod switch settings: 
NOTICE: WEDGE 4 is now in its place (b0svt02, left), 
        WEDGE 5 is in b0svt1 right (swapped with 3) 
The hardware configuration now is the same as final one, 
except for 3 and 5 which are swapped to please barrel 4 cabling. 
Set HB MaxLayer to 5 for all boards, i.e. 6 layers. 
</pre>
<!-- Author: Stefano Belforte -->



<!-- Date: Wed Oct 18 00:36:32 2000 -->
I just turned b0svt01, 02, 06, and b0l2de01 back over 
to the shift crew.  They started a run, we configured 
without error.  
<!-- Author: Bill -->


<!-- Date: Wed Oct 18 00:51:43 2000 -->
Made several changes (largely aesthetic) to the 
coldstart code.  Moved TFs to the final locations 
corresponding to wedges 2 and 3.  Added TF crate's 
Mergers to the readout list, and added register 
files for them.  Modified Spy Control 
prepare-to-coldstart routine (runs before all other 
SVT coldstarts) so that it clears all possible 
sources of SVT_INIT_ before other boards attempt 
to configure.  Verbose printing is now off by 
default, but is enabled if the svtMode string in 
Run_Control contains the substring "verbose". 
Boards are now configured in slot-number order, 
which (visually) is pretty cool.  Run number 
now appears in spy buffer snapshot.  
<!-- Author: Bill -->


<!-- Date: Wed Oct 18 00:57:47 2000 -->
Things I hope we can do before Friday: 
<ul> 
<li>Investigate and cure lost sync errors in Hit Finders 
<li>Check bunch ID synchronization between SIXD, SVTD, TFRD 
<li>Take a test run with silicon in which HF output goes 
straight to L2 readout, for validation against simulation 
<li>Gain more confidence, from simulation and by talking with 
SVX experts, in our ability to find good clusters; implement 
bad-channel suppression if necessary. 
<li>Set up Track Fitters to run in "test mode 1," in which 
Hit Buffer output is replicated in Track Fitter output 
</ul>  
<!-- Author: Bill -->


<!-- Date: Wed Oct 18 10:48:57 2000 -->
<pre>Apparently during the night we had again a conflict between  
running SVT standalone diagnostics and SVT crates being 
included in the run. Maybe we need to try again tonight?</pre>
<!-- Author: Luciano -->


<!-- Date: Wed Oct 18 18:28:21 2000 -->
The shift crew made a shrot run with SVT in. I looked at 
data on TrigMon and everything appear OK. 
SVT is now OFF the 
readout list and Alexei starts overnight test of AMboard.
<!-- Author: Stefano Belforte -->


<!-- Date: Wed Oct 18 21:39:18 2000 -->
<pre>I just started random test for b0svt00,01,03,04,05 for overnight.Am_test_data_loop tests do't passed for crate b0svt02 ( for phi=4, for all amplugs for 2 amboards...may be there are some problems with AMS?). 
 
</pre>
<!-- Author: Alexei -->


<!-- Date: Thu Oct 19 11:19:49 2000 -->
I am using svt crates 01, 02, 06, and b0l2de01 for Level 2 tests.
<!-- Author: Jane -->
<!-- Comment: Thu Oct 19 11;59;10 comment by...Jane -->
I'm finished with those crates for now.


<!-- Date: Thu Oct 19 13:22:07 2000 -->
I'm going to try to take a run that includes SVX and SVT, with 
the Hit Finder output going straight to the readout.  
<!-- Author: Bill -->


<!-- Date: Thu Oct 19 15:07:57 2000 -->
I just put the Track Fitters into the SVT chain, so that Jane 
will get things that look like tracks for her test.  She should 
be able to run daqtest/svt/svtwja_nosvx and see tracks.  Beat 
me up if it doesn't work.  -Bill
<!-- Author: Ashmanskas -->


<!-- Date: Thu Oct 19 17:09:46 2000 -->
<pre>

I am planning to test some Hit Finders with a GSTM in crate b0svt03 for
several hours.  Please let me know if this with interfere with your plans
in any way.  I will probably be working on either the 2nd or the 3rd floor
of B0.  -Bill

</pre>
<!-- Author: Ashmanskas -->
<!-- Comment: Thu Oct 19 17;12;15 comment by...rvidal -->
 I sent this myself by email...it seemed to work for me!??


<!-- Date: Thu Oct 19 17:31:22 2000 -->
<pre>

This is a test of e-mail entry from cdfsga.fnal.gov

</pre>
<!-- Author: Ashmanskas -->



<!-- Date: Thu Oct 19 18:39:24 2000 -->
<pre>Crate b0svt00 is currently in use by runControl for spy monitoring test.</pre>
<!-- Author: marco  -->
<!-- Comment: Thu Oct 19 21;39;02 comment by...marco -->
Crate b0svt00 removed from run control and rebooted.
No problem seen with the monitoring program. Still the rate was too low for drawing firm conclusions. More test after the next shot
<!-- Date: Thu Oct 19 19:07:42 2000 -->
We hand over b0svt01,02,06 and b0l2de01 to shift crew for preparation for tomorrow's shot.
<!-- Author: Stefano -->



<!-- Date: Fri Oct 20 01:55:17 2000 -->
b0svt05 (which is never part of the run) has been showing up 
disturbingly red on the ace's status panel for a while, and 
there is no note in the logbook about it, so I rebooted it.  
<!-- Author: Bill -->


<!-- Date: Fri Oct 20 04:09:49 2000 -->
Added SVT monitoring task for b0svt06, so that we can monitor  
Track Fitter input and output.  Stefano thought that this 
minor change was worth the risk, so that we can see what we're 
doing tomorrow. 
<p> 
Fixed chip IDs in HF init, to match spy buffer data.  I expect 
this to eliminate the "invalid data" errors from HF. 
<p> 
Now run HF in "merger test" mode, in which Merger chip merges 
FIFOs deterministically, which is the mode that I used when 
testing the boards (because the ospy data were easier to  
interpret, i.e. without sorting by barrel/ladder).  The feature 
that disables input streams (e.g. for missing silicon) had been 
tested in the deterministic merger mode but not in the normal 
mode; it turns out that a seemingly minor bug in determinstic 
mode is more problematic in normal mode.  The fix is a success: 
no more lost-sync errors. 
<p> 
I adjusted the stream-disable masks to account for Steve Nahn's 
heroic recovery of the recently-thought-to-be-dead half-ladders. 
<p> 
Elena and I looked into some bunch crossing numbers in SIXD, 
SVTD, and TFRD, and learned that SVTD=TFRD-5, while SIXD=TFRD+42. 
Since L2B comes along with L1A, the fact that we have a fixed 
offset in bunch ID should have no effect on our readout, but we 
should fix it after the store. 
<p> 
UnKi inserted the Track Fitters (production boards), configured 
to run in "test mode 1" in which input data are copied to 
output. 
<p> 
I have a GSTM in slot 9 of crate 6, which is able to send data 
over fibers to HFs in slots 6 and 15 of crate 3.  This was part 
of the test to narrow down the "lost sync" problem. 
<p> 
If it turns out that the FIBs are really sending something 
on the disabled streams, then those streams will report FIFO 
overflow, eventually.  If this happens, we should mask the 
error bit (from the .HF-REG text file). 
<p> 
See shift log for discussion of svtd banks, l2de00 vs 01, etc. 
<p> 
Good night!  (Wake me up if I screwed anything up.) 
<p>
<!-- Author: Bill -->


<!-- Date: Fri Oct 20 10:42:18 2000 -->
The Chip ID update I mentioned above didn't stick, because 
I didn't commit the change (it was the last thing I worked on) 
or rebuild the library; the other changes are in.  I will not 
touch it unless I show up in person in the control room and 
see that there is plenty of time and hear also that there is 
no objection from Luciano, Stefano, etc.
<!-- Author: Bill -->
<!-- Comment: Fri Oct 20 12;56;19 comment by...Bill -->
The change is now in.



<!-- Comment: Fri Oct 20 13;52;28 comment by...Bill -->
Law of unintended consequences: the simple fix I put in for
chip IDs caused HF coldstart to fail, because I exceeded the
limit of 20 rams per board coded into svtvme_private.h.  I
bumped this limit up to 50, but probably we should set it up
to be computed dynamically at some later update.
<p>
I also made it possible to replace the ospy test data with
data from a file called metakey.HF-OSPY.

<!-- Date: Fri Oct 20 13:07:38 2000 -->
<pre>I put a new set of SVT maps in cvs for configuration nom_wide_fakeXFT, with fixed ss alignment. The TF files are there in the "old style" format. This goes under cvs tag v1-0. If changes are needed during the weekend we will make a v1-x version later. 
 
It is up to the people on shift to actually replace them in the SVT download area.</pre>
<!-- Author: Giovanni -->



<!-- Date: Fri Oct 20 14:32:25 2000 -->
SVT is back to the Ace.  See shift log entry.
<!-- Author: Bill, Stefano, AnnaMaria -->


<!-- Date: Fri Oct 20 15:15:22 2000 -->
At a task priority of 500, SvtVmeMon never runs during a run, 
so I try 230.  (I guess Marco and Stefano already had some 
experience with this.)  
<!-- Author: Bill -->


<!-- Date: Fri Oct 20 18:42:39 2000 -->
AnnaMaria, Bill and myself put in svt_config area the new 
patterns and related maps from Giovanni. Things are now also 
consistent between disk area and cvs repository. All know fixes 
for known problems are in.
<!-- Author: Stefano -->
<!-- Comment: Fri Oct 20 18;43;21 comment by...Stefano -->
Details have been sent by e-mail to svt@fnal.gov


<!-- Date: Fri Oct 20 19:27:20 2000 -->
I removed the Track Fitters from the SVT chain as we 
wait for a deeper understanding of TF TestMode 1. 
SVT hardware configuration is exactely the same as last 
weekend shot.  
<!-- Author: Stefano B. -->


<!-- Date: Fri Oct 20 20:46:46 2000 -->
As we were told that a shot was imminent, I had to cut my 
losses and put the SVT together in a way that could at least 
get us the SVTD readout, even if not the spy buffer readout. 
So I did so. 
<p> 
Arnd has provided an update to fer ("setup fer meyera") that 
prevents the SVT crates from sending anything to the VRBs.  It 
also calls svtvme_l2aCallBack() every level 2 accept.  This 
can be used to implement the polling of the spy buffers.  I 
find that it is no trouble to poll the spy buffers and stick 
the results in a big string somewhere, synchronously with the 
readout, but that getting the data off the crate is a bit slow 
with the "write to file" method. 
<p> 
Arnd doesn't understand, however, why anything we do, as long 
as it is at "high" priority, should cause a timeout. 
<p> 
So for now, the monitoring is a no-op. 
<p> 
I think, actually, that Marco and Subir already have the 
technology to export the results off of the crate, so perhaps 
now we have everything we need.
<!-- Author: Bill -->


<!-- Date: Fri Oct 20 21:35:34 2000 -->
<pre>I put in a new hf_xtrpfake.HF-OSPY file in svt-config area 
so that next time RC starts it sends fake XFT tracks corrected 
for the new patterns/maps files. From now one SVT is in business 
as usual.</pre>
<!-- Author: Stefano -->


<!-- Date: Sat Oct 21 14:36:23 2000 -->
I am using b0l2de00 in partition 4 for some Level 2 tests.
<!-- Author: Jane -->
<!-- Comment: Sat Oct 21 15;47;39 comment by...Jane -->
Also using SVT crates (tracking 1 & 2, fitting 6) and b0l2de01.

<!-- Comment: Sat Oct 21 17;11;01 comment by...Jane -->
Crates are returned to the Ace.


<!-- Date: Sun Oct 22 14:17:33 2000 -->
I am using b0l2de00 in partition 4 for Level 2 tests.	
<!-- Author: Jane -->
<!-- Comment: Sun Oct 22 14;28;50 comment by...Jane -->
Also b0l2de01 and the SVT crates (tracking 01 and 02, fitter 06)

<!-- Comment: Sun Oct 22 21;18;52 comment by...Jane -->
I gave the crates back to the shift crew.	


<!-- Date: Mon Oct 23 09:03:27 2000 -->
<pre>I am using b0l2de00 and partition 4 for some quick 
tests</pre>
<!-- Author: Stephen -->
<!-- Comment: Mon Oct 23 14;51;48 comment by...Stephen Miller -->
I'm finished with the L2 crate. I successfully ran about 17M 
events at a rate of 5KHz (with no real readout). Occassionally
the Alpha would hang after a few million events. Ending the run
and doing coldstart (which resets the board) would get it to 
continue running.
Partition 4 must be used when L2processors are used.
<!-- Date: Mon Oct 23 10:02:44 2000 -->
(1) See recent note in shift logbook about status of SVT crates. 
<p> 
(2) I am using b0svt05 for code development.  
<!-- Author: Bill -->
<!-- Comment: Mon Oct 23 20;26;37 comment by...Bill -->
I am no longer using any SVT crates.

<!-- Date: Mon Oct 23 18:13:10 2000 -->
I stored in cvs the latest code I used for generating SVT maps, including TFs and some other fixes (not yet final, though). (That's svt_config/source/svt_ram_gen)
<!-- Author: Giovanni -->


<!-- Date: Mon Oct 23 19:49:19 2000 -->
Temporarely bypass AMS/HB in "rc crates". We send Hit Finder's 
output directely to the readout in SVTD bank. Merger output that was going to HB goes to output merger instead. AMS's have been downloads with a microcode that ignores hold. Micorsequencer code 
with and withou hold is now (with doc) in USEQ* subdirectories 
of svt_config area. This configuration is there at the beginning of present store.
<!-- Author: Stefano & Bill -->


<!-- Date: Mon Oct 23 20:23:17 2000 -->
Put SVT back into default configuration. AMS obeys hold, data go through HB. HB output to SVTD. All data for present store from run number 102259 (0x18f73) on are in this configuration. All previous run numbers have HF output in SVTD.
<!-- Author: Stefano -->



<!-- Date: Mon Oct 23 22:11:03 2000 -->
On Friday, Arnd set up SVT crates (keyed on presence of 
"SVTX" dummy bank and "SVX" readout type) such that 
svtvme_l2aCallBack() is invoked every L2A.  I made this 
return immediately most of the time; if >60 seconds have 
elapsed since last spy buffer poll and event number is 
evenly divisible by 100 (to synchronize the crates), then I poll the spy buffers and 
write the result into a 64 KB global string. 
<p> 
Today I borrowed Jim Patrick's vxhttpd.c and hacked it to 
write out this global string upon connection to TCP port 
2520 (the number of COT cells, or 4 x (660 - 30)).  It 
seems to work without causing done timeouts, though there 
are a couple of flaws: (a) when it runs (once/minute), it 
takes about 30 msec to complete, compared with Arnd's 
recommended 1 msec; (b) the server appears not to be 
terribly robust, and can be confused, it seems, by 
connections that get prematurely hung up.  Anyway, the 
idea is for this port to be polled not by Jane User's 
web browser but by a single cron job on a B0 PC, which 
would then mirror it to someplace web-accessible. 
<p> 
With this change, we are able to pariticipate in the run 
without giving up our spy buffer polling or causing the 
Ace to hate us for generating done timeouts. 
However, this is still an ugly hack.  
<!-- Author: Bill -->


<!-- Date: Tue Oct 24 11:39:03 2000 -->
Removed HF ospy, HB hspy, AMS hspy from "tracking" crate 
spy polling, to reduce data volume.  Rebooted crates. 
Tested OK. 
<p>  
<!-- Author: Bill -->


<!-- Date: Tue Oct 24 13:37:48 2000 -->
setup svtmon v0_1 added in the default setup list in the svt bootstrap procedure for svt crates. I will go on testing the rest of the complete machinery on crate b0svt05. I will have to reboot it now and maybe also at a later time. Nothing will happen to the ACE crates even if they have to reboot them.  
<!-- Author: marco r. -->

<!-- Date: Tue Oct 24 14:19:56 2000 -->
<pre> 
Spy Buffer dumps from current store obtained
via latest Bill's daemon on the CPU are
on B0 cluster in /data1/belforte/svtspy
I will also copy them on fcdfsgi2 disk since
/data1 is pretty full. Look for data in
/cdf/data03/s1/hardware/svxii/svt/svtspy.
</pre>
<!-- Author: Stefano -->


<!-- Date: Tue Oct 24 14:52:11 2000 -->
<pre>

Here is an analysis of the Hit Finder spy buffer data for the two events
that happened to be in the HF spy buffers in the first file from last
night that I looked at in Stefano's spy dump area, filename
b0svt02_20001023221927.dat.

wedge 3, run 102265, near event 245900

simulated HF output:
2588f0 258910 2597f0 2d8e75 2da7c8 310420 310970 315358 315398 311ab0
311b50 311c30 311d90 311ea0 3120b0 312260 312c90 3135b0 21852c 21c568
2d05b8 31a900 31a920 60102b

actual HF output:
2488f0 248910 2497f0 2c8e75 2ca7c8 300420 300970 305358 305398 301ab0
301b50 301c30 301d90 301ea0 3020b0 302260 302c90 3035b0 20852c 20c568
2c05b8 30a900 30a920 60192b

wedge 3, run 102265, near event 245900

simulated HF output:
2587f8 2588f0 258910 2597e8 2907b8 2d8e75 2da7d8 310420 310970 3112c0
311850 311b50 311d90 315e38 311e7b 311ea0 312260 312880 312a10 312c90
3135b0 218540 2d47d8 2d1b48 2d1be8 2d2820 31a900 31a920 60102c

actual HF output:
2487f8 2488f0 248910 2497e8 2807b8 2c8e75 2ca7d8 300420 300970 3012c0
301850 301b50 301d90 305e38 301e7b 301ea0 302260 302880 302a10 302c90
3035b0 208540 2c47d8 2c1b48 2c1be8 2c2820 30a900 30a920 60182c

Notes:

To first (and second, I would say) order, it works!

Invalid data error bit being set can be explained by this: chip IDs count
from "d" on layer 4 in w2b2, w2b3, w3b2, but from "c" in w3b3???

Fifo overflow error bit being set can be explained by this: need to mask
off fifo overflow for the fifos corresponding to the disabled halfladders.

I have the wrong barrel number loaded, which accounts for bit 16 of the
hits.  (I noticed this at some point, and plan to fix it, but decided at
the time I saw it that any more tinkering with coldstart code at that
moment would be more dangerous than beneficial.)

Because barrel number is different, events with odd numbers of hits have
different parity between board and simulation.

</pre>
<!-- Author: Ashmanskas -->



<!-- Date: Tue Oct 24 19:45:49 2000 -->
I'm going to try here to summarize today's 4pm SVT meeting, 
since that meeting resulted in a lot of planned activities 
for tomorrow.  Feel free to add comments. 
<p> 
<ul> 
<li>We want to integrate the Marco/Subir monitoring code with 
the real SVT startup, before the next store.  Marco is now putting in the finishing touches, and testing in his own partition. 
<li>We don't want to have to live in fear of stepping on FER's 
toes in our crates, so we want to carry out some intensive 
tests in a separate parition, e.g. CPU intensive task, VME 
intensive task, large volume of smartsockets data.  Jim Patrick 
endorses this, but would like us to e-mail him so that he knows 
what is going on if we happen to break something, and also of 
course to wait until the current store ends.  Marco and Stefano 
are going to try to make the crates sweat.  It is not clear 
whether or not this requires any dedicated DAQ time (e.g.  
hardware event builder); probably little, if any. 
<li>We want to read some spy buffer data (e.g. from one Merger 
board) into the event builder, so that we can validate SVT 
against other data that are available offline.  Arnd Meyer has 
provided a hook with which we can send him data.  Anna Maria 
and I plan to have it working by Wednesday or Thursday, such 
that one Merger board in crate b0svt03 receives a duplicate 
copy of the output of the "final Merger" from b0svt06, and 
formats its most recent data into a bank on every L2A. 
<li>We need to make SVT coldstart failures report more 
meaningful information, using Merlin messages.  Arnd told me how 
to do this, but it requires a few lines of code to be written. 
I hope I can do it tonight. 
</ul>
<!-- Author: Bill -->


<!-- Date: Tue Oct 24 20:00:21 2000 -->
I'm taking b0svt03 for FER tests.  
<!-- Author: Bill -->
<!-- Comment: Tue Oct 24 20;21;03 comment by...Bill -->
I'm switching from 3 to 4.  Bus errors, etc., in coldstart?!


<!-- Comment: Tue Oct 24 23;22;54 comment by...B -->
I'm no longer using any crates.

<!-- Comment: Tue Oct 24 23;27;41 comment by...Bill -->
I changed some Spy Control settings (disabling global signals)
on crate 4.

<!-- Date: Tue Oct 24 20:31:27 2000 -->
Current data has many events with empty SVTD bank. Jane found that
this is a "feature" of Run_Control when there are too many words, due
to the amplug #7 in w02_1 getting beserk. As a temporary cure
new microcode has been downloaded in AMS boards to enforce the
output road limit. Also the -REG file has been modified to set this
limit to 10. The change was done for w02 and w03 using new_ucode
script in svt-config. reset_ucode can be used to put things back.
This in in effect starting with run number 102316.
<!-- Author: Stefano -->



<!-- Date: Tue Oct 24 20:45:30 2000 -->
b0svt02 failed coldstart again. I asked the ACE to repeat it while looking for errors at the console output. This second time everything went OK. We are still clueless.
<!-- Author: Stefano -->

<!-- Date: Tue Oct 24 21:06:32 2000 -->
The road limit is working. No events with empty SVTD that I can
see with AC++Dump anymore. The extra ffffff are still there, but Jane
says she understand this and only needs the time to put a fix in. Data
should be correct
until the EE anyhow.
<p>As a side effect I notice that the beserk
Amplug 7 in w02_1 is now effectively killing wedge2, i.e. when it sends
out all its roads they appear first in the output and since the output
is cut at 10 roads, no other roads can make it.
Since the 1000+ bad roads where anyhow confusing the readout, it was
impossible to find good roads in wedge 2 anyhow in this situation, so
we may not have lost anyting, all in all.
<p>
This behaviour is unexpected since roads come out in numerical order and
the bad ones (5c03 etc.)
are near the end (plug 7 out of 16 of the 2nd amboard), not even our
fake road (225, i.e. amplug 0 of board 0) is output. This means that
the bad amplug declares "match" before the count/shift sequence is
complete.
<p>
We still have no clue at why this Amplug is so sick. It will be swapped
asap.
<p>
<!-- Author: Stefano -->



<!-- Date: Tue Oct 24 22:22:21 2000 -->
I'm taking b0l2de00 for standalone tests.
<!-- Author: Jane -->
<!-- Comment: Wed Oct 25 01;41;06 comment by...Jane -->
I'm finished with b0l2de00. 
<!-- Date: Tue Oct 24 23:09:07 2000 -->
Yes!  It is now possible to use the hook provided by Arnd in 
FER to read Merger spy buffer into a bank, using code in 
svtvme library.  This is only tried so far with software 
event builder, and is basically reproducing what Anna Maria 
was able to do in August, but now we use (a) Arnd's code  
for the top level and (b) svtvme library (instead of raw 
VISION calls) for the bottom level.  Now we need (1) to test 
this when crate data are synchronized to L1A and (2) to try 
it with the hardware event builder (which I think will require 
changing some DIP switches on our VRB). 
<br>  
<!-- Author: Bill -->





<!-- Date: Wed Oct 25 11:00:13 2000 -->
Shift crew has been asked not to include SVT for the rest of today's day shift. 
<p> 
I asked Stefano for crates 4 and 6 for the next 30 minutes. 
<p>  
<!-- Author: Bill -->
<!-- Comment: Wed Oct 25 11;46;30 comment by...Bill -->
I am now done with crates 4 and 6, but may need them back
later in the day, if Jim Patrick has time to help me test
with hardware event builder.



<!-- Date: Wed Oct 25 12:09:48 2000 -->
<b>SVT crates</b> allocation for the day <b>25 Oct</b><br> 
Let's try this way. We add comment to this entry as we book/release crates among ourselves  
<!-- Author: Stefano -->
<!-- Comment: Wed Oct 25 12;10;12 comment by...Stefano -->
I use b0svt01

<!-- Comment: Wed Oct 25 12;10;33 comment by...Marco -->
Marco has b0svt05

<!-- Comment: Wed Oct 25 12;10;56 comment by...Stefano -->
Subir has b0svt03

<!-- Comment: Wed Oct 25 12;22;06 comment by...Bill -->
I have nothing (was using 04, 06, and l2de01).
<!-- Comment: Wed Oct 25 13;05;06 comment by...Stefano -->
I handed over b0svt01 to Alexei to swap bad Amplug.
<!-- Comment: Wed Oct 25 13;42;22 comment by...Sefano -->
Subir releases b0svt03
<!-- Comment: Wed Oct 25 14;16;00 comment by...Bill -->
Bill has b0svt04

<!-- Comment: Wed Oct 25 14;26;30 comment by...Stefano -->
Alexei releases b0svt01
<!-- Comment: Wed Oct 25 14;49;05 comment by...Stefano -->
Bill has all crates
<!-- Comment: Wed Oct 25 16;01;55 comment by...Bill -->
Bill has crates 0,1,2,6, and l2de01

<!-- Comment: Wed Oct 25 17;18;46 comment by...Bill -->
I am not using any crates, but note change in svtboot.vxsh; I
also need to put cables and config files back in place for b0svt04.

<!-- Comment: Wed Oct 25 19;29;54 comment by...Jane -->
I am using svt01, 02, 06, b0l2de00, 01.
<!-- Comment: Thu Oct 26 00;02;36 comment by...Jane -->
I am finished with svt01, 02, 06.
<!-- Comment: Thu Oct 26 00;39;23 comment by...Jane -->
I forgot to say, I'm also finished with l2de00 and l2de01.
<!-- Date: Wed Oct 25 12:19:29 2000 -->

<p>
I tested, with the software event builder, readout of a Merger board's
spy buffer against the standard SVTD readout, by taking a run that
included b0svt06 (to send a fake track every L1A and do the fanout),
b0svt04 (for the spy buffer readout), and b0l2de01 (for the normal
SVTD readout).  I did not format the bank as a "trigger" bank, so there
are a couple of extra header words in SVTD that do not appear in SVTY.
Also, I put one 0xDeadBeef word at the end of SVTY, as a marker.  For
this simple test, the answer is the same between the two banks,
except that bits 11 and 16 (fifo overflow and SVT->L2 parity error)
are set in SVTD but not in SVTY.  I speculate that fifo overflow is
the fault of the poor Merger that sits in b0l2de01 and has no way to
get an SVT_INIT_  pulse before each run starts; I don't know about the
parity error.
<p>
Of course, if L1 accepts are pipelined, then the current readout scheme
will cause SVTY to miss some data, because data will come through while
the spy buffers are frozen.  Probably it would be better to read the
Merger's input FIFO instead of the spy buffer.  But that has nothing to
do with getting the basic readout to work.
<p>
The next big step would be to make it work with the hardware event
builder, which requires a few minutes of DAQ guru magic and a few
minutes of Ace DAQ time.
<p>

<pre>

cdf1% ~/junk/a.out -test A20001025113349.test | more

SVTD data: 000001 000003 00000e 000001 000003 00000b 406d8e
 210b09 2510d3 291c0a 2d2243 140620 200064 610c8e
SVTY data: 000001 000003 00000d 000007 000007
 210b09 2510d3 291c0a 2d2243 140620 200064 60048e 2dbeef

SVTD data: 000001 000003 00000e 000001 000003 00000b 406d21
 210601 250910 290f5c 2d1241 140900 200064 610c21
SVTY data: 000001 000003 00000d 000007 000007
 210601 250910 290f5c 2d1241 140900 200064 600421 2dbeef

SVTD data: 000001 000003 00000e 000001 000003 00000b 406d53
 210b09 2510d3 291c0a 2d2243 140620 200064 610c53
SVTY data: 000001 000003 00000d 000007 000007
 210b09 2510d3 291c0a 2d2243 140620 200064 600453 2dbeef

SVTD data: 000001 000003 00000e 000001 000003 00000b 406d85
 210601 250910 290f5c 2d1241 140900 200064 610c85
SVTY data: 000001 000003 00000d 000007 000007
 210601 250910 290f5c 2d1241 140900 200064 600485 2dbeef
</pre>
<p>
<p>
<!-- Author: Bill -->




<!-- Date: Wed Oct 25 12:41:30 2000 -->
<pre>L2 processor note: 
 
 During tests with Clist, the L2 processor board had 8 bits that 
were stuck high for VME transactions. Another problem was that 
the GA* bits could not be read from the backplane.  
The cause of the problem was that the L2 processor was not fully  
seated in the slot, although it had enough connections for power 
and to handle VME transactions correctly. 
 
Please don't remove the L2 processor from the crate unless 
absolutely necessary. When installing the L2 processor, the  
board needs to be pushed in by hand after the handles have been 
used to initially seat the board. 
 
</pre>
<!-- Author: Stephen Miller -->






<!-- Date: Wed Oct 25 14:41:32 2000 -->
<pre>Just now I changed bad amplug #07 (S.N.737) for amboard #01 
(b0svt01, slot #10) to new one (S.N.790). 
All tests (Am_test_vme,am_test_data_loop, random) passed for 
this amboard.</pre>
<!-- Author: Alexei -->




<!-- Date: Wed Oct 25 17:17:33 2000 -->
OK, bank SVTY appears in the output for run 102374, taken with 
the hardware event builder! 
<p> 
Jim Patrick found that our VRB had a bad channel (for b0svt06); 
replaced it.  Crates 00, 01, 02, 06 are OK, using Jim's vrbtest. 
Crates 03, 04, 05 have suspected CDF clock problems.  Crate 07 
has some sort of CPU configuration problem. 
<p> 
Bill Badgett set the "online" flag for VRB_69, which is in slot 
12 of b0vrb00, and services our crates.  Now whenever we are 
booked in a run with the hardware event builder, our crates will 
send data to the EVB via the VRB.  This also implies that we 
must not include crates 03, 04, 05, or 07 in runs with the 
hardware event builder until the Tracer/VRB link test passes  
for those crates. 
<p> 
Right now I am loading the "meyera" version of FER and my own 
version of svtvme into the crates at boot, to be compatible with 
using the hardware event builder.  It should now be safe to 
incorporate my changes into svtvme, but we still need to load 
Arnd's FER until he next updates development. 
<p> 
We should sit down and figure out just what we want to read 
out with this Merger board. 
<p>  
<!-- Author: Bill -->




<!-- Date: Wed Oct 25 20:55:18 2000 -->
<pre> I tested all amboards for crate b0svt01,02 again. 
The results of tests were: 
  1. Crate b0svt01 - errors for plug#07(amplug#790,amboard#01, slot10)and for plug#03(amplug#504,amboard=26, slot18)during am_test_vme tests. 
  2. Crate b0svt02 - errors for plug#07 (amplug#575,amboard#08, slot19)detected by am_test_vme tests too. 
 I replaced: 
     amplug#790 to amplug#428, 
     amplug#504 to amplug#438 and 
     amplug#575 to  amplug#492. 
 After replacement all test for crates b0svt01,02 passed.</pre>
<!-- Author: Alexei -->




<!-- Date: Thu Oct 26 00:55:59 2000 -->
I changed the svt_mon task that is called by fer at each L2 so that it dumps the MRG/AMS/HB Output spys before the others. I tested this on b0svt01/2/6. <br>The code is svtvme_mon.c and is included in svtvme_th.o.
<!-- Author: Stefano -->


<!-- Date: Thu Oct 26 12:21:54 2000 -->
<b>SVT crates</b> allocation for the day <b>26 Oct</b><br>  
We add comment to this entry as we book/release crates among ourselves.<br>
<!-- Author: Stefano -->
<!-- Comment: Thu Oct 26 12;22;29 comment by...Stefano -->
Francohas b0svt03 to look at AMBoard coldstart failures

<!-- Comment: Thu Oct 26 12;23;18 comment by...Stefano -->
Ace uses 0/1/2/6 and l2de01 to test new SVT readout

<!-- Comment: Thu Oct 26 13;01;04 comment by...marco -->
I will take crate b0svt05, b0svt04 and svt_spy_manager for further tests


<!-- Comment: Thu Oct 26 18;55;09 comment by...Stefano -->
Crate b0svt03 is free
<!-- Comment: Thu Oct 26 20;52;04 comment by...marco  -->
crate 4 is now free. I will use crate 5 and svt_spy_manager for a night long test. 
<!-- Comment: Fri Oct 27 00;40;56 comment by...Bill -->
Bill has crate 3 for error message test
<!-- Comment: Fri Oct 27 01;43;16 comment by...Bill -->
Crate 3 is now free.
<!-- Date: Thu Oct 26 13:55:45 2000 -->
I will be using l2de00 for about another half an hour (until the shift crew has time to try to put it in the run).
<!-- Author: Jane -->
<!-- Comment: Thu Oct 26 22;34;18 comment by...Jane -->
I am using l2de00 again.  
<!-- Comment: Fri Oct 27 01;56;21 comment by...Jane -->
I'm not using l2de00 anymore -- I gave it to the shift crew, who succeeded in integrating it with the rest of the run. 
<!-- Date: Thu Oct 26 14:41:54 2000 -->
<pre>SVT readout from crate 0 (SVTY bank) was tested in the global partition and it works. Banks are there with hardware EVB and latest FER code. The trigger rate was low. The Ace keeps SVT crates (0/1/2/6+lede01 now) in the standard set from now on. 
</pre>
<!-- Author: Stefano -->


<!-- Date: Thu Oct 26 14:56:14 2000 -->
<pre>Giovanni is preparing a new set of constants for SVT with 
a beam spot radius of 5 mm. He will put the new set in a new 
directory in CVS. As soon as this is done and we have 
a confirmation from Giovanni that we can proceed, 
we should update svt_config and do all the checks that we can 
in order to be ready for the upcoming shot with the new 
constants. Stefano has volunteered to take care of this.</pre>
<!-- Author: Luciano -->


<!-- Date: Thu Oct 26 17:07:47 2000 -->
I just created a new SVT configuration in cvs: <B>nom_wider_fakeXFT</B>. This has a the 5mm beam spot, replaces layer 3 with layer 4, and should be tried in next shot. 
See svt_config web page for details. 
  
<!-- Author: Giovanni -->
<!-- Comment: Thu Oct 26 21;11;04 comment by...Stefano & Franco -->
The new patterns are now in. We keep previous AMS microcode with road limit and .REG files. Old svt_config directory has been saved in<br> /cdf/code-common/cdfonline/svttest/svt_config_SAV_26oct00
<br>
Run Control coldstart works.


<!-- Comment: Fri Oct 27 16;46;24 comment by...Giovanni and Annamaria -->
It looks like there was a bug in swapping the layers and this config is not usable without a fix...best thing at this point seems to be to go back to the old one.
<!-- Date: Thu Oct 26 21:17:48 2000 -->
New SVT readout code is now running in b0svt00. At each L2 accept 
the Hit fifo AMS in slot 17 is read into SVTY bank (not dumpable with AC++Dump yet) and should contain an identical copy of SVTD bank from L2 (almost). A maximum of 1000 words is read each time.
<!-- Author: Stefano -->





<!-- Date: Fri Oct 27 01:44:33 2000 -->
SVT coldstart now uses Merlin message facilty to report 
failures.  Changes are committed to svtvme library and 
updated in developmnet, and will take effect upon reboot. 
Tested on crate 3.  
<!-- Author: Bill -->



<!-- Date: Fri Oct 27 10:34:17 2000 -->
I rebooted b0svt00 and asked the Ace to add it (not done yet), see main logbook. 
I manually disabled spy monitoring on b0svt00 (just in case) we have to remember to do this by hand after each reboot.<br> 
The new patterns again do not trigger on the xtrpfake data we send. We need new fake events (and forgot yesterday). <br>
<!-- Author: Stefano -->


<!-- Date: Fri Oct 27 10:56:23 2000 -->
I am using l2de00 until noon, when it will go back to the shift crew.
<!-- Author: Jane -->


<!-- Date: Fri Oct 27 11:10:50 2000 -->
<b>SVT crates</B allocation for the 
day <27 Oct> 
We add comment to this entry as we book/release crates among ourselves.<br>
<!-- Author: Stefano -->
<!-- Comment: Fri Oct 27 11;11;35 comment by...Stefano -->
Ace has 0-1-2-6

<!-- Comment: Fri Oct 27 11;12;03 comment by...Stefano -->
Franco has 3 (test AMB coldstart)

<!-- Comment: Fri Oct 27 13;01;02 comment by...marco (x3502) -->
I will go on with test on crate 5...


<!-- Comment: Fri Oct 27 15;38;21 comment by...Stefano -->
I take b0svt00 for readout tests


<!-- Comment: Fri Oct 27 20;31;53 comment by...marco  -->
i have done with crate 5 but please leave it free for subir tonight
<!-- Date: Fri Oct 27 15:41:41 2000 -->
b0svt00 crashed again. No message on the console. It was taken out of data taking (store in progress). I'll test the readout with Soft EB.<br>
<!-- Author: Stefano -->




<!-- Date: Mon Oct 30 20:17:11 2000 -->
<pre>I put the new files from Giovanni (nom_wider_fakeXFT) in 
svt_config area (done at 18:33). I created a file of 
fake tracks and put it in the svt_config area (done at 18:37). 
I checked the data in the Merger in the L2 crate: roads are 
coming out but with no XFT track. The problem is in the   
files hb_w*.HB-ROADS.</pre>
<!-- Author: Anna Maria -->