From: quarrie@cds001.cebaf.gov (David Quarrie)
Subject: Re: RT GC Should use Better Hardware
Reply-To: quarrie@cds001.cebaf.gov (David Quarrie)
Organization: CEBAF (Continuous Electron Beam Accelerator Facility)
Date: Mon, 5 Oct 1992 13:12:31 GMT

--
In article <1992Sep29.203430.26882@actrix.gen.nz>,
Des.Kenny@bbs.actrix.gen.nz writes:
|>  
|>  Another example is at CEBAF, The Continuous Electron Beam
|>Accelerator
|>  Facility in the U.S. 
|>  
|>  "CEBAF is an electron accelerator with an energy of 4 GeV/c
|>scheduled for
|>  completion in 1994.
|>  It is designed to allow the the detailed investigation of the quark
|>  structure of the nucleus and will support several experiments
|>operating
|>  simultaneously at three end stations."
|>  see TOOLS USA, August '92, Prentice Hall.
|>
|>  The hardware is custom built. It will be required to support a 10KHz
|>event
|>  rate with up to 10 KBytes per event.
|>
|>  So we are looking at a sensitivity of 0.1 ms to trap events.
|>
|>  This is real time enough. I guess it could be safety critical 4
|>GeV/c
|>  sounds like a lot of juice to let run wild.
|>
|>  The hardware has fast data paths ( FASTBUS) , an Event Builder
|>module
|>  and a Processor Farm , all connected to workstations and a host.
|>
|>  The application software is written in Eiffel.
|>
|>  
|>  Hard real time , almost always means a serious look at the entire
|>system
|>  Hardware and Software.
|>
|>  -- Des Kenny
|>     Objective Methods Ltd
|>     PO Box 17356
|>     Wellington
|>     New Zealand
|>

Much as I'd like to agree with the above, I think I should point out that the
real-time aspects of the above system are not written in Eiffel. We did do some
studies to show that we could cross-develop Eiffel applications running on our
VxWorks real-time nodes involved in the actual data acquisition data flow, but
finally decided not to do the implementation using that technique. Thus Eiffel
is used only for the non time-critical sections (controlling the data
acquisition,
downloading modules and monitoring the status of the experiment and
accelerator)
but is not involved with actually moving the data through the system.
Our reasons
for not using Eiffel were basically concerns about garbage collection
with the
sometimes very limited physical memory in some of the readout
controllers and
maintenance of the cross-development environment (which involved
redefining the
C_COMPILER environment variable to point to the 68k cross-compiler and a
parallel
Eiffel installation etc.). 

Given our successful experience using Eiffel for the non time-critical
sections,
we're re-evaluating that decision and might redo things so that only the
actual
readout of the hardware and RPC handling is in C. One factor in that
decision 
will be the licencing policy for the Eiffel run-time library for a
cross-developed
target (which I believe will be different under Eiffel 3 than it was
under 2.3).

-------------------------------------------------------------------------------
	David Quarrie					CEBAF MS 12H
							12000 Jefferson Ave
Internet: quarrie@cebaf.gov				Newport News VA 23606
DECnet  : cebaf::quarrie				Tel: (804) 249-7562
BITNET  : quarrie@cebaf					Fax: (804) 249-7363
Newsgroups: comp.lang.smalltalk