Minutes

                            SLT meeting
                              Zeuthen
                           April 26, 27


Present:

H. Albrecht       R. Dippel     M. Feuerstack     A. Gellrich
J. D. Hansen      J. R. Hansen  H. Kolonoski      P. Kreuzer
I. Legrand        H. Leich      R. Mankel         M. Medinnis
C. Polenz         D. Ressing    F. Saadi          A. Schwarz
U. Schwendicke    H. Thurn      P. von Walter     P. Wegner
R. Wurth          J. Zweizig




1. the l2simu framework                             M. Medinnis

A general framework for writing code destined for a distributed system
of processors such as forseen for the SLT has been written and was
described. Processor configurations consisting of modules, their
interconnections and pointers to the processes which run in them are
specified in tables, mostly in a single file, called the configuration
file. The configuration file, together with the code destined for
running in the modules fully define an SLT configuration and algorithm.
The program also provides a means for HBGean-generated data to be routed
to appropriate modules (which simulate the L2 buffer). In its current
version, the program is appropriate for developing the logic of SLT
algorithms. Future versions will allow for some timing measurements,
better debugging facilities, etc. A memo describing this framework:
"Framework for L2SIMU: the SLT Simulation and Development Program" is
available.



2. FLT refit progress report                        H. Thurn

The first step of the SLT algorithm is the refit of tracks found by the
FLT. Progress on this step was reported. A realistic configuration file
exists which assigns one DSP to each section of the outer and inner
trackers, for each of six superlayers (96 modules plus a few
pseudo-modules), together with the interconnections and connections to
the L2 Buffer has been set up. The configuration was checked by
injecting data from leptons from Pythia generated J/Psi decays into the
system and propagating them through the system using only the generated
track parameters (not a Kalman filter). A Kalman filter algorithm for
the FLT refit has been designed. The next step is to turn it into code. 



3. Silicon algorithm: progress and benchmarks       J.D. Hansen

The Fortran code used for the estimates given in the TDR was rewritten
in C (although not yet in the L2Simu framework described above). [The
Kalman filter algorithm is essentially as before but the track
acceptance criteria are significantly different. MM]. The algorithm was
then benchmarked on various processors using the same data sample used
for the TDR estimates. The results are:

Processor  Clock(MHz)  <time/event>(msec)

  C40         40           21              (non-optimized)
  C40         40           13              (optimized but wrong result)
  T9000       20           15
  Pentium     90            3.5
  Alpha      270            1.2


These latencies could be reduced by processing projections separately
and each trigger track separately (factor of 4). Also, track candidates
can be processed in parallel at some level, even within the same
projection. However, the present algorithm keeps only 40% of the
triggers and is thus in need of some tuning.

[ MM: It is difficult to relate this to the estimate of 600 microsec per
      event given in the TDR. Blindly extrapolating from that estimate to
      the fully sequential algorithm used here, gives a value of 4 msec
      (compared to 13 msec above), but the estimate depends critically on
      the number track candidates generated per input track. The
      criteria for accepting or rejecting tracks in the new C code is
      significantly different from the Fortran code.]

Next, the benchmarks were repeated with a larger region of interest
which would be expected if only a point at the center of the magnet
(known to 1cm x 1cm) and the target dimensions were used to initiate the
track parameters. It was found that average event processing time
increased by a factor of 19 and that up to 1600 track candidates per
projection are generated. This justifies the conclusion that it is
necessary to refit the FLT tracks and extrapolate them through the
magnet to the superlayer immediately upstream of the silicon to give a
good starting point for the silicon.



4. Alternative algorithms                           I. Legrand
(In particular for the silicon tracker)

The Kalman filter is a fully sequential algorithm and furthermore
requires that several candidates be kept for each track initiator. It is
thus not well suited for a pipeline implementation. Some alternatives
were described. One possibility is to organize the hit strip data from
the silicon into 3-dimensional points before tracking. A method for
doing this was described: First, a Radon transform on all hits of a
quadrant in a superlayer is applied (The Radon transform is used, for
example, in medical imaging applications.) Next Fourier transform the
Radon transformed hit pattern. Real points appear as straight lines in
this space and can be found with a pattern matching technique since the
number of bins required in the transform variables is much reduced
(order 100 vs. 1500 in real space). The technique was tried using the
data sample mentioned above but found to fail because the stereo angle
of the silicon planes (+-2.5 degrees) is too small. The technique would
be optimal for a 45 degree stereo angle.

After 3-d points are found, they must then be turned into tracks. Three
techniques for doing so were mentioned: 1) A global track fit by
minimizing the variance of the points projected onto a plane. 2) Using a
Fourier transform. 3) Using a Hough transform. 4) A Kalman filter.



5. HBGean integration                               P. Kreuzer

The method of producing existing and future data sets by HBGean for use
by L2simu. The values of HBGean cards used were explained as was the
procedure for producing data files. The format of the data files
themselves and the mapping from plane number to physical detector was
described. The files are ASCII coded for ease in transporting and
downloading into target DSPs. At present, raw Geant hits are output. In
the future, we intend to use HBGean digitized hits. Other needed
developments: a realistic block describing data expected from the FLT, a
means of structuring ECAL data to avoid being overwhelmed by lots of
uninteresting (from the point of view of the SLT) pulse height info, a
more realistic field map, a means for generating SLT accepted events for
people studying the properties of triggered events.

6. the ADSP 21060 (SHARC) option                    R. Wurth

The board designed by R. Wurth and its present status was described. The
board is as described in the TDR (section "Sharc DAQ Option"), and
consists of a standard 6u VME board containing 6 ADSP 21060 ("SHARC")
chips. The 6 chips are connected via a global memory bus which also
provides a path via a VME-interface to the VME bus. All link-ports,
serial ports, interrupt request lines and flag lines are routed to
connectors which accept a single "interface board". The interface board
contains drivers and rows of connectors which allow independent access
to all ports and other lines via the front "panel". Unlimited numbers of
such boards can thus be interconnected in any arbitrary point-to-point
topology. The entire HeraB L2 Buffer, SLT, and Event Builder can be
built using networks of these boards (and nothing else).

A SHARC board has been built, under contract by an outside firm, for
DESY and was shown at the meeting. The board is currently under test by
the firm which built it and contains just one pre-production SHARC chip
(5 other SHARC chips have been procured but will only be mounted after
tests with the single chip). It is expected that the board will be fully
operational and available at DESY for running benchmarks by the end of
May. The price for quantity production of the board and of the ADSP chip
has not yet been fixed.

A scheme for buffer management, which requires very little CPU
intervention, relying almost entirely on the 10 DMAs in each SHARC,
a proposal for a raw-event format and a conceptual design for the Event
Builder were also presented. The scheme assumes that the SLT will
produce two signals: "accept event", and a "provisional accept" which has
the effect of removing the pointer to the event's buffer from the ring
buffer, allowing for longer storage. It is not possible to provide for
an L2 reject in this scheme without CPU intervention.



7. the C44 option                                   H. Leich

The design of a board specifically for the SLT and based on the
TMS320C44 from Texas Instruments was described. Superficially, the board
is strikingly similar (given its independent origin) to the board
described by R. Wurth. Instead of 6 SHARCs, the board contains 4 C44s
each of which accesses 512 kBytes of fast SRAM via local buses. The C44s
are connected together via the global buses which also connects to a VME
interface and a mezzanine card.  Three of the link ports from each C44
are routed to the front panel and the fourth link port from C44 is
routed to the P2 connector. The mezzanine card is intended to be the
access path from the L2 buffer for event data. It contains a C44, 512
kBytes SRAM, DS Link interfaces and drivers/connectors for the 4 link
ports.

The C44 board is not being proposed as a general solution to HeraB's L2
buffer/SLT/Event builder needs (as is the SHARC board) primarily because
of limitations on the length of cables connecting two link ports. It
should however be adequate for the needs of the SLT.

The C44 board has been designed and is 97% layed out. It is expected
that a prototype board will be manufactured starting in mid-May and will
exist by the end of May. It should be available for benchmarks by the
end of June.

8. host/processor communications in the C4x world   P. Wegner

The mechanisms for communicating between a host and a system of DSPs,
with emphasis on the C40, was reviewed. Two examples of models for
handling such communications are: 1) A single server running on the host
communicates with a single DSP in the processor network which is
responsible for forwarding messages to the other DSPs making up the
network. 2) Several servers run on the host, one for each DSP in the
system.

From the point of view of the application programs running on individual
DSPs, the server provides access to operating system services on the
host such as file I/O, graphics and the internet. From the point of view
of the host, the server provides a means of monitoring and controlling
the DSPs. Servers are built from a "host library" for code destined for
the host and a "target library" for code destined for the DSPs. Existing
servers differ enormously in complexity and capability ranging from
simple home-made libraries providing printf/scanf functions to systems
which include real-time multitasking operating systems (e.g. SPOX) which
run on the DSPs and code development packages. The NIKHEF server is a
relatively simple server consisting of libraries of routines which
provide the functionality of stdio. Two other systems were mentioned: 1)
The 3L system which provides a target library, a runtime system and a
configuration language. 2) The parallel programming environment
"TRAPPER" developed by Daimler Benz. In addition to the basic services,
TRAPPER provides design tools, configuration tools, a visualisation
facility and a performance monitor. An example of a SLT test system,
developed in the context of the EAST collaboration by UCL was described.
Software for it was developed on a '486 PC running OS9 and using
standard Texas Instruments C development tools. It was pointed out the
server needs of HeraB SLT group are not well defined and that before an
intelligent choice of server can be made, a software requirements
document must be produced. M. Medinnis will coordinate production of
this document. The relative availability of software tools for the
SHARC, C4x, C8x DSPs can also influence the choice of platform for the
SLT.

9. the C80 option                                   H. Leich

An alternative conceptual design for the DAQ/SLT/Event Builder based on
Texas Instruments' latest addition to the TMS320C family and Apple's
QuickRing was presented. The new design has some significant advantages
over the C40 and SHARC designs (as well as some disadvantages). The
advantages include: a drastic decrease in connector/cable count (more
than a factor of 5, at least for some parts of the system), flexible
routing of event data which will allow (for example) a farm
implementation of the SLT which would lead to higher reliability, higher
net I/O bandwidth, more MIPs per DMark, the use of a chip (the C80) which
is currently in production and available on industry-manufactured boards
(at least 7 suppliers) and which is targeted for mass-market
applications including video conferencing, networking and games, thus
assuring long-term availability and extensive software support.
QuickRing chips are also in routine production.

The C80 integrates 4 integer DSPs, a RISC processor with FPU, 50 kBytes
RAM, and a 400 MByte/sec DMA on a single chip. The DSPs have 64 bit
instructions which allow several parallel operations per cycle [alas
only on 32 bit integers and only 16 x 16 bit multiplies]. The peak
instruction rate is 2000 MIPS, 50 times that of the SHARC, [but this is
highly theoretical, the useful peak MIPS for our application is probably
less than 10 times a SHARC, but still quite respectible]. The current
cost of the C80 is 1450 DM.

QuickRing was developed by Apple and National Instruments, primarily for
connecting workstations. Up to sixteen nodes can be connected to a
single ring. Rings can be connected by means of bridges. The total
single node bandwidth is 400 MBytes/sec (200 in, 200 out). The
theoretical throughput on a single 16 node ring is 1700 MBytes/sec.
QuickRing bridges operate at 200 MBytes/sec (x 2) and can be as long as
10 meters. For longer distances, bridges can be constructed using HP's
Gigalink, but with half the bandwidth. The QuickRing chips cost $30-$40.

In the design shown for HeraB, each FED would have a QuickRing
interface. Up to 15 FEDs would be connected on a single ring. The FED
rings would be connected by bridges to two rings: one for distribution
to an SLT farm and another for distribution to the third level farm. The
SLT itself would be connected to rings with bridges to the SLT
distribution ring. While the design looks quite interesting, more detail
must be added, in particular bandwidth considerations, the implications
of integer arithmetic for the SLT, and a more careful comparison of the
advantages of this approach over the two other proposals, before a
decision can be made to build evaluation hardware. And we must keep in
mind that the decision on DAQ architecture is required by the end of
1995. Leich, Medinnis, and Zweizig agreed to produce a document by the
time of the May meeting with the needed details. Hopefully, at that
time, a decision will be made whether to continue developing this option
in parallel with the others.

It was pointed out that the networking scheme based on QuickRing would
also lend itself to a RISC-based (e.g. Alpha or PowerPC) SLT system. The
particular advantages and disadvantages of a RISC-based SLT vs. C80
should also be discussed.

10.Common DAQ Architecture                          D. Ressing

A discussion of the material contained in the memo "Common DAQ
Architecture" (April 5, 1995) as well as a proposal for a data protocal
and data format was presented. The above memo summarizes the logical
architecture of the DAQ and the flow of messages and data through from
the FED to the 3rd level farm. The pathes needed by the control, trigger
and DAQ streams were discussed.

11.Where we stand and where we are going 
   (Review of SLT Milestones)                       All

As a result of a request by W. Hofmann, a new set of milestones for the
SLT was generated. The new set is meant to have more definite and easily
measurable goals than those presented in the TDR. These milestones were
discussed and revised to be consistent with other HeraB milestones, in
particular the decision on DAQ/SLT Architecture and the test runs for
1996 and 1997. The revised list follows. For now, we are still on
target.


Fully running prototype boards: C44, SHARC                        end June  95
(as described by R. Wurth and H. Leich)

Fully developed Kalman-filter algorithm which can be              end Sept  95
used for GEANT simulation and serve as a basis for
performance evaluations, both efficiency/rejection and
eventually processor load

Results from realistic* benchmarks designed for                   end Nov   95
one or two boards with goal of understanding
execution times of parts of the algorithm and 
understanding message passing protocols and providing
data for comparison of the two architectures.

*(Realistic means: using fragments of SLT algorithm, 
running on different DSPs and passing messages via
links and global memory and using hit data from MC.)

Architecture decision (C40, C80, SHARC or ?)                      end Dec   95
(This implies that the SLT interface with the outside
 world, in particular the FED be established at this time.)

Prototype hardware capable of running significant chunks of       end June  96
the algorithm (order 5% of full processor)

physical SLT/L2_buffer/FED integration                            end Dec   96
- tested with MC data injected into FED

Fully running prototype system capable of propagating track       end Feb   97
through a slice of the spectrometer/silicon system in situ
(data from real hardware)

Hera-B test run: measurement of the B cross section               end March 97

final hardware design work finished, production start             end March 97

processor assembled                                               end March 98