You will be presented with the full text of a science research paper. Please write an abstract for this paper. Your response should include the abstract and no additional text.

Paper text:
the btev detector is a collider detector with two back - to - back forward spectrometers ( @xmath4 ) having sub - detectors in each arm for charged particle tracking , em calorimetry , rich particle i d and muon detection @xcite . at the core of the detector is a 30 station si - pixel inner tracker spanning @xmath5120 cm centered at the ir ( @xmath6 = 30 cm ) and immersed in a 1.6 tesla dipole field .
there are over @xmath7 active rectangular pixels measuring 50 @xmath8 400 @xmath9 .
each pixel station has two planes , one with narrow pixel dimension oriented in the @xmath10-direction and the other with narrow dimension in the @xmath11-direction .
btev will operate at a luminosity of @xmath12 @xmath13 s@xmath14 corresponding to @xmath15 interactions per beam crossing at a crossing rate of 7.6 mhz .
average event sizes will be @xmath5200 kb after zero - suppression of data is performed on - the - fly epsf    by front - end detector electronics . since every beam crossing will be processed , this translates to an extremely high data rate of @xmath51.5 tb / sec !    to handle this high rate , btev will employ a three - level hierarchical trigger architecture @xcite ( see fig .
[ btevtrig ] ) .
sparsified data from all detector components will be sent via optical links to level 1 ( l1 ) buffers .
data from the pixel and muon detectors will also be sent to the l1 trigger processor .
trigger decisions from the l1 muon and vertex trigger will be passed on to the global level 1 ( gl1 ) trigger manager whose decisions will be stored as a list of accepted crossing numbers by the information transfer control hardware ( itch ) .
l1 will reject  99% of all incoming events reducing the data rate by a factor of @xmath5100 to @xmath515 gb / sec .
levels 2 & 3 ( l2/3 ) will be implemented with a cluster of commodity cpu nodes . a request from an idle l2 node
will be sent to the itch which will respond by assigning an accepted crossing number to that node .
this node will then request a subset of the data ( pixels+forward tracking ) for that crossing from the l1 buffer managers .
a switch will combine pixel data with forward tracking data for the same crossing and route them to the buffer of an l2 node allowing a more refined analysis that will further reduce the data rate by a factor of @xmath510 .
if that passes the l2 selection criteria , the same processing node will then enter the l3 phase and request data from the rest of the sub - detectors be transferred from the l1 to the l3 buffers ( l2/3 buffers will simply be the ram attached to the processing node ) . using complete information from the detector , l3 will reduce the crossing rate by an additional factor of @xmath52 . since l3 will also be able to further compress the data in the accepted crossings by a factor of @xmath54 , the expected data rate out of l3 is @xmath5200 mb / sec .
the first phase of the l1 vertex trigger algorithm is the track finding phase @xcite which starts by finding the beginning and ending segments of tracks in two separate regions of the pixel planes , an inner region close to the beam axis and an outer region close to the edge of the pixel planes .
the search for the beginning and ending segments of tracks is restricted to these inner and outer regions respectively .
segments are found using hit clusters from three adjacent pixel stations in the defined regions .
inner segments are required to point back to the beam axis while outer segments are required to project outside pixel plane boundaries .
once these segments are found , they are then matched to form complete tracks in the segment matching stage .
after complete tracks are found , the vertexing phase @xcite determines the momentum of each track and calculates its transverse distance from the beam axis .
primary vertices are found by looping through all tracks with transverse momentum @xmath16 gev / c that appear to originate close to the beamline .
remaining tracks are then tested for their detachment from the primary vertices found .
a l1 vertex trigger is generated if there are at least 2 tracks in the same arm of the btev detector satisfying the following criteria : @xmath17 ( gev / c)@xmath18 , @xmath19 , and @xmath20 mm where @xmath2 is the impact parameter .
our studies indicate that the l1 vertex trigger is able to reject 99% of all minimum - bias events while accepting @xmath560 - 70% of the @xmath0-events that would survive our offline analysis cuts .
a block diagram of the l1 vertex trigger is shown in fig . [ l1vtx ] .
data from all 30 stations of the pixel detector are sent to fpga based pixel processors that group individual pixel hits into clusters .
hit clusters from three neighboring pixel stations are routed to fpga based hardware that find beginning and ending segments of tracks in the track finding phase .
epsf    segments found in this stage are sorted by a switch according to crossing number and routed to a dsp in the track / vertex farm .
this dsp performs the segment matching step of the track finding phase and the entire vertex finding phase .
based on initial studies done for the btev proposal @xcite , we estimate the average processing time for the combined segment matching plus vertex finding phase to take @xmath5330 @xmath21s on a single 167 mhz ti tms320c6711 floating point dsp . since the time between beam crossings is 132ns , this will require a total of @xmath52,500 dsp in the track / vertex farm in order to examine every beam crossing .
since hand - optimized assembly code can be difficult to maintain and debug , we are working on an optimized c version of the l1 segment matching and vertexing code .
a version is currently running on a c6711 dsk board in which we have replaced costly function calls with intrinsics that map directly to built - in dsp instructions and completely rewritten major sections of the code .
preliminary results indicate that this optimized c version is only a factor of @xmath54 - 5 slower than the hand - optimized assembly version used for initial timing estimates .
while we expect substantial gains in dsp chip performance in the next few years , we will continue to explore ways to improve code performance , resorting to hand - optimized assembly programming only when necessary .
we are developing a prototype board for the segment matching and vertexing portion of the l1 trigger with four dsp s on mezzanine cards .
onboard fpga input and output buffers will have an lvds interface to a host computer through which simulated data can be sent .
buffer managers in the fpga will channel data to and from each dsp via dma transfers .
trigger results from each processor will be sent through an fpga interface to an on - board @xmath21-controller that will format the results and forward them to gl1 through arcnet .
a host computer serving as a pixel trigger supervisor monitor will be connected to a second on - board @xmath21-controller through arcnet , allowing commands to be sent to the board , initialization of the dsp s , and providing hardware monitoring and fault detection .
jtag ports will also be available for real - time debugging and initial start - up of the prototype .
we are also implementing the l1 segment finding algorithm in fpga s and doing simulations and queuing studies of the algorithm with matlab .    as a final note btev will greatly benefit from a newly approved nsf funded project called rtes ( real time embedded systems ) @xcite which will develop a semi - autonomous , self - monitoring , fault - tolerant and adaptive framework for addressing issues facing complex computing architectures like that of btev .
we have designed a level 1 vertex trigger that will address the demanding requirements of btev .
we are currently working on optimizing a high - level version of the vertex trigger algorithm and developing a prototype board for investigating various aspects of the l1 vertex trigger hardware .
a. kulyavtsev et al . , btev proposal , fermilab , may 2000 .
p. lebrun , the btev triggers and data acqusition systems , talk presented at the session on new detector technologies , at the meeting of the division of particles and fields of the american physical society , columbus , oh , august 9 - 12 2000 .
gottschalk , btev detached vertex trigger , nucl .
instrum . meth . a 473 ( 2001 ) 167 .
r. isik , real - time pattern - recognition for hep , university of pennsylvania , preprint upr-233e , 1996 .
r. isik , w. selove , k. sterner , monte carlo results for a secondary - vertex trigger with on - line tracking , university of pennsylvania , preprint upr-234e , 1996 .
gottschalk , the btev daq and trigger system- some throughput , usability and fault tolerance aspects , proc .
chep 2001 , beijing , sept . 3 - 7 2001 , p. 628 .
btev is a @xmath0-physics experiment that expects to begin collecting data at the c@xmath1 interaction region of the fermilab tevatron in the year 2006 . 
 its primary goal is to achieve unprecedented levels of sensitivity in the study of cp violation , mixing , and rare decays in @xmath2 and @xmath3 quark systems . in order to realize this 
 , it will employ a state - of - the - art first - level vertex trigger ( level 1 ) that will look at every beam crossing to identify detached secondary vertices that provide evidence for heavy quark decays . 
 this talk will briefly describe the btev detector and trigger , focus on the software and hardware aspects of the level 1 vertex trigger , and describe work currently being done in these areas .