Wrap up of SVT workshop October 27-28 1998 at University of Chicago
-------------------------------------------------------------------
compiled by S.Belforte with everybody's help
A: HARDWARE SPECS AND SIMILAR:
------------------------------
1. L2Buffer ID:
- Checking for consistency is not implemented, we only use event
tag to generate lost-sync if needed.
- The merger will pass on the L2id from the first enabled input
stream (A in general).
- The Hit Buffer will pass on L2id from the HIT stream
2. SVT error:
- the register that causes a board to assert SVT_Error must
be cleared by VME as well
3. Lost-Lock:
- A4 on P2 is designed as Lost-Lock line (one of the SVT-reserved
user defined termianted bus lines on the backplane)
- The Hit Finder will drive this line low via OpenCollector
if a G-Link lost-lock is detected
- The Hit Finder will also assert CDF_Error in this case
- Each Spy_Control slave will monitorthe Lost-Lock line,
will handle it as it does with SVT_Error and will add it
in daisy chining OR to a dedicated line of the G-Bus (the
line that was previously spare).
- The Master Spy Control will monitor the Global Lost-Lock
line on the G-Bus and in response to its assertion will
send an LVDS signal to the SVX SRC.
- More details of this signal to the SVX SRC are to be defined by
Colin Gay.
4. CDF_Error:
- error conditions that require system re-sync for recovering
are declared SEVERE. (non-severe errors are those who may
spontaneusly clear with the next event).
- severe errors are (so far): lost-lock, lost-sync, fifo-overflow
- each board that detects a severe error will assert CDF_Error if
possible. If AMS and/or HB can not be modified to comply
with this, they will stay as they are.
- Details on how the CDF_Error condition is handled will be
written down by Luciano in the error handling document on the
web.
- If some board will not be able to properly assert CDF_Error, the
Merger will have the fall-back capability to assert CDF_Error
if it detects a severe error in the incoming ENdEvent word.
This feature will be enabled/masked via VME.
5: Spy_Master:
- the Spy Control prototype will be built as designed till
before the workshop with the following changes:
- it will implement Lost-Lock logic as 3. above
- space will be left on the fropnt panel and pcb for the
possible addition later of 2 KEL connectors and needed
drivers/receivers/fifo's to spy on the SVT data stream,
in such a way that this function could be added without
changing the "existing" layout.
6. LED's:
- Internal Error LED is removed
- The 3 LEDs at bottom are:
GREEN : RUN
RED : CDF_ERROR
YELLOW : SVT_ERROR
- if a board does not implement CDF_Error assertion, the
red led will always be off.
- in response to a steady clock (DS_ eg.) the LED may either
stay alwayson or flash at low frequency (eye detectable), while
the latter is nice, it is not mandatory.
7. Error_Registers:
- error registers in each board will be implemented according
to Luciano's document
- in addition a board may have a shadow register that stores
the condition that generated SVT_Error but is not reset by
INIT. This is not mandatory for all boards, though.
8. P0/P3:
- it is reccomended for all baords to prepare "holes" in the
PCB for installation of P0 and 5-rows P3 even if not used now,
also the P0 power pins should be connected to Vcc-in.
9. Firmware versioning:
- all boards containing flash rams will have a register with
the ram content version number, so that at run init the control
program can quickly check that the trigger configuration is the
correct one.
- the low level software must make sure this register is updated
each time the flash ram content is changed
- a checksum will be added to each table (if possible) to cross
check the RAM content against the version number
10. Track Fitter 5/5:
- if a road has hits in 5 silicon layers, the TF will only use
4 pre-defined layers.
- Giovanni will look asap at the effect of this on efficiency
11. Track Duplicates (if 4/5 or 4*):
- The TF will not try to remove duplicates.
- Duplicates may be a serious problem, Tsuyoshi and Giovanni will
try to estimate the number of dulicates
- as first solution we (Giovanni?) will explore in detail the Pt
threshold a' la Tsuyoshi by generating a set of patterns that
implements 4/4 at low Pt, 4/5 at high Pt, and computing
efficiency, number of roads etc. etc.
12. Track Fitter:
- The TF will handle up to 4 hits per SS.
- The TF will add bits in the output track packet indicating
the pattern of long and short clusters
13. Beam position:
- we rely on beam being stable and centered
- TF will not adjust dynamically for beam spot movement
- Giovanni will understand how SVX will be aligned to COT and beam
at the same time
- We allow for the beam to be offcenter as much as 10mm at start of
the store
14. Merger:
- the merger will not have output FIFO's. Data to be sent out will
be stored in output Spy Buffers
- when the meger compares an input stream to one spy bufffer content
and find a mismatch, the following may happen (enabled by VME):
- assert signal on test point (Front panel if possible)
- assert error bit
- generate HOLD
15. Documentation:
- we will use the web to put togheter the documentation for each
board
- a FNAL mirroring of Pisa pages to speed up access will be attempted
by Stefano
B: NEWS TO REMEMBER
-------------------
1. Alignment:
- so far it looks OK: specs and mechanical stress analysis are ok.
- wait for measuerements from hardware
- we worry a bit because present specs are 100microrad for each
system and for each relative alignment, rahter then 100urad overall
- we (Giovanni?) have to make clear to SVX builder that 100urad
is an absolute spec on maximum deviation, not an RMS
2. Test Stand:
- there will be an SVT crate in the test stand area in B0. This is
co-ordinate by Aesook/Peter. We have to follow up on this.
C: VERTICAL SLICE
-----------------
We agreed on a set of tentative decisions. To be revised soon for change or
confirmation.
1. Schedule:
- vertical slice test is April 1 to May 30
- we gather boards in B0 as they are done with board specific
tests at home, starting march 1st.
- when the Hit Finder or the Track Fitter have passed internal
tests, Pisa will provide one old merger to check board external
connection.
- we try to have one of each board in B0 by end of march
2. Coordinators:
- overall test (worry about everything): Stefano
- code (coding style consistency,cvs,docuemntation): Xin (+Thomas)
- hardware (crates,cpus and other non-SVT boards,terminals,cables): Ray
- SVX DAQ: Ray
3. Manpower:
- as a baseline, Chicago, Geneve, and Pisa+Trieste will provide
one person each to cover the test period
- board experts will be available as needed
4. CDFVME:
- server side software for each board will be provided by the
board builders in-coordination-with/helped-by Thomas
- this code will beput in the online cvs repository at B0
5. Platform:
- code will be written in Java and C
- main code repository wil be SGI machine at B0
- modules in C may be run also on the client side
- we expect to use standard Unix (Sun/SGI) and PC running Linux
- server side code will be developed on Unix platforms
- NT is not required nor requested for the B0 test
- simple test stand code in Java will run on NT. C code used on
the client side (e.g. SVTSIM) may just run, if not, it is not clear
at present how much effort we should make to port it.
6. SVTSIM:
- the SVTSIM package will be broken into single baord simulation
units
- same C code will be used for online and offline, in general in
any place where SVT simulation is needed
- Giovanni will provide Java wrapping to run SVTSIM pieces on
client side (CDFVME approach can be used for this, JP says)
7. Spy Monitor:
- the Rome group will provide software to cover the basic functions:
read the buffers after random freeze and or error, sort into
event fragments, assembe pieces for the various buffers that
belong to the same event, compare for consistency at the cable ends.
8. DataBase:
- we will use the final online DB to do all memory lookups/patterns
storing/retreiveing for the vertical slice test.
- Xin will take care of database.
Stefano Belforte (
stefano.belforte@pi.infn.it)