# ICECUBE \"Phase 1\" DAQ Work Plan

# "Plan B" , "Workplan H"

# LBNL Engineering 

### Author: **David Nygren**

25 April 2002

**Version 1.0, 25 April 2002, RHMinor,** added comments from Bob
Stokstad, clarified relation to current cost estimate, restored string
18. This description is the basis for the cost estimate of 25 April
2002.

**Version 1.1, 11 May 2002, DRNygren,** added explicit descriptions of
actions for each subtask, at request of Bob Paulos.

**Version 1.2, May 13, 2002 RHMinor, DRNygren, CMcParland, R.
Stokstad,** updated document list. Corresponds to
Plan_B_Deliver_vsn1.2.doc and daq_cost_vsn1.0.xls

## [Overview]{.underline}

In its current state, this document consists of narrative descriptions
of tasks associated with three general areas:

-   IceCube DAQ Architecture

-   The \"preproduction\" DOM Main Boardwith software and firmware;

-   DOM HUB Design and Software + Documentation;

Numerous documents that are part of all this work are also listed. While
the work plan will evolve, as needed, to reflect current status, Version
1.0 dated 25 April 2002 is used for the basis of the cost estimate
spreadsheets of the same date.

Although this work plan includes IceCube DAQ Architecture, it does not
cover software development for higher level functions such as string
processor, global trigger, event builder, etc; these are not Phase 1
deliverables.

The costs included in this document are [only]{.underline} for estimates
for **engineering and software professionals,** plus resources needed by
them for each sub-task. Any effort by technicians, machinists, etc, is
implicitly included in the estimates, not separately broken out in the
subtasks. Travel costs are not included. The effort of physicists is not
included; their effort, spread throughout many of these tasks, is
largely directed toward scientific activities such as analysis, article
and report preparation, organizational matters, etc. Travel costs,
management costs and Physics support are included in the cost
spreadsheet 3.3.1.xls.

The units for effort to produce Phase 1 deliverables are person-days;
resources are in units of k\$. Initials of the estimators accompany the
estimates for each subtask. Priorities are not yet imposed on the
subtasks in this narrative. As soon as is practical, the plan\'s tasks
will be transformed to a schedule format to permit definition and
assessment of milestones.

[Estimators:]{.underline} Jerry Przybylski ***(GTP)***, John Jacobsen
***(JJ)***, Chuck McParland ***(CMcP)***, Thorsten Stezelberger
***(TS)***, David Nygren ***(DRN)*** , Robert Minor ***(RHM), Bob
Stokstad (RGS), Peter Denes (PD).***

Of particular urgency is the **DOM HUB Design Document**, as this
document will serve as the basis of an informal MOU between LBNL, DESY
and the ICECUBE Project Office. The contents of this document must be
agreed to by the participants before design effort should start.

#### Roles and Responsibilities

**LBNL**: DOM Main Board circuitry, architecture, software, and
firmware, except for feature extraction. DAQ architecture, and
experiment control software. Fast communication, DOM + DOM HUB
architecture and requirements, in concert with DESY.

**DESY:** Fast communication, DOM HUB architecture, requirements and
firmware, in concert with LBNL. Detailed circuit design of the DOM HUB
in accordance with the DOM HUB Design Document. K-H. Sulanke will travel
to LBNL for part of one year to participate in this area. This work plan
does not include this work, but the effort is included in the cost
estimates for the DAQ for Phase One. Please see file 3.3.1.xls for
information.

**Stockholm**: FPGA code for feature extraction within the DOM. The
effort for this work is not included in this work plan.

**Penn:** String processor software, including string trigger is not
included in this work plan, but will be included in later phases of the
project.

## [Estimated Effort Summary:]{.underline}

Please see the cost estimate spreadsheets for details.

## 

##  

## [Elements of the Workplan:]{.underline}

## [Documentation:]{.underline} 

This element includes effort for documentation preparation. The
engineering effort to produce the documents is listed elsewhere in this
document.

-   DAQ System Requirements ***4 (DRN)***

-   DAQ Software Requirements

```{=html}
<!-- -->
```
-   DAQ System Architecture ***4 (DRN)***

```{=html}
<!-- -->
```
-   DOM MB ***4 (DRN)***

-   DOM HUB ***4 (DRN)***

-   Master Clock Distribution ***2 (DRN)***

-   Test Software Suite ***6 (DRN)***

```{=html}
<!-- -->
```
-   DAQ Hardware Requirements

```{=html}
<!-- -->
```
-   DOM Main Board ***6 (DRN)***

```{=html}
<!-- -->
```
-   DOM HUB ***4 (DRN)***

-   Master Clock Distribution ***2 (DRN)***

```{=html}
<!-- -->
```
-   DAQ System Design

```{=html}
<!-- -->
```
-   DOM MB Prototype Design Document ***5 (DRN)***

-   DOM MB Software Design Document ***5 (DRN)***

-   DOM HUB Prototype Design Document ***5 (DRN)***

-   DOM HUB Software Design Document ***5*** ***(DRN)***

-   Master Clock Design Document ***3 (DRN)***

```{=html}
<!-- -->
```
-   Test Results

```{=html}
<!-- -->
```
-   DOM Main Board Performance ***6 (DRN)***

```{=html}
<!-- -->
```
-   Two DOMs/twisted pair ***4 (DRN)***

```{=html}
<!-- -->
```
-   Other (Tech notes, presentations) ***5 (RHM)***

> **Sub-total: 74**

## [DAQ System Architecture:]{.underline}

Although Phase 1 R&D work will primarily focus on development and
implementation of the DOM Main Board (MB) design, software requirements
and design documents for the DAQ system including the DOM HUB must be
produced during the same time period. These documents will formalize the
performance requirements for all elements of the DAQ system, namely the
String Processor, Global Trigger, Event Builder and DAQ Monitor. While
actual implementation of these components will take place in a phased
manner during the IceCube construction effort, it is necessary to have
their design finalized, documented and reviewed during this first phase
of effort. Validation of design will include some minimum level of
simulation to verify expected network data transfer and message rates.
These simulations will be based on performance measurements taken from
simple "mock-ups" of critical code sections in each of the above
software components. These programs will ultimately become part of the
IceCube Test System described below. It should also be pointed out that
a fairly complete version of the String Processor code will be required
for both the initial single string test and the following six string
test. While these tests are not scheduled until after phase 1,
development of the String Processor code will need to preceed these
scheduled tests.

> **[ACTIONS:]{.underline}**

-   In consultation with the members of the Software Working Group and
    other stakeholders, define the framework for the ICECUBE DAQ
    software architecture;

-   Prepare Documents as noted and initiate acceptance process through
    Project Office, following procedures.

-   Simulate network behavior.

*Estimated EE effort:*

*Estimated CS effort: **20 (JJ)***

*Estimated sr. CS effort: **30 (CMcP)***

*Estimated TBD CS effort: **15 (CMcP)***

*Estimated resources:* **Access to an array of networked Linux PCs will
be required. It is expected that resources will be available either at
LBNL or within the collaboration. Network switches may be required to
simulate environment found at IceCube. If necessary, \~\$3K.**

## [DOM Main Board, LED Beacon Board Engineering & Software:]{.underline}

-   **Fast Communication:** There is little if any doubt that fast
    communications at the level needed for IceCube can be achieved. Fast
    communication is, however, tied up with other issues, such as timing
    \"synchronization, and boot-strap mode. It seems desirable to avoid,
    if possible, a design choice that limits flexibility.

> An activity by the DESY group has demonstrated that more than 500 -
> 1000 kbits/s may be reliably transmitted/received over 2+ km of
> twisted quad using the commercially available HDLC protocol as offered
> by Altera. HDLC offers the benefit of immediate availability and a
> mature implementation. It recognizes bits through the use of analog
> filtering and discriminators. It may ( or may not) have some
> undesirable features such as the need to tailor the equalization
> filters as a function of depth, or perhaps leaving the line in an
> unbalanced DC state (ignorance on our part at the moment).
>
> At the media access layer, Jerry Przybylski of LBL has proposed to
> exploit a fast bipolar pulse (δ\' shape) of reversible polarity for
> modulation. The encoder/decoder for the δ\' modulation exists. A 1440
> ns pulse period is possible, corresponding to 700 kbaud. The
> modulation scheme is essentially independent of the data encapsulation
> scheme of HDLC, or any other likely protocol. In other words, the
> normally encoded serial data generated by the protocol can be passed
> directly to the (δ\', -δ\') modulator.
>
> The δ\' shape is very similar to the bipolar waveform used for time
> synchronization functions, differing only in duration. Since the
> leading edge appears to be the best choice for timing measure, the
> length of the pulse should not affect resolution or accuracy, provided
> the cable is \"quiet\". In the (δ\', -δ\') scenario, the fast
> communications \"receiver\" would consist of the FADC already in place
> for the timing measurements; it would look directly at the arriving
> waveform without need of filtering components. Code in the FPGA would
> apply digital filtering, baseline tracking, etc., as needed. This
> offers the flexibility inherent in any programmable digital processor,
> and would avoid a possible need to tailor filtering constants as a
> function of depth. On the other hand, the resources within the FPGA
> needed for this modulation/ demodulation scenario would be larger than
> with an analog decoder.
>
> In any case, fast communication must be seamlessly integrated with the
> time \"synchronization\" functions. This requires that the
> twisted-pair lines be quiet prior to transmitting a timing pulse, and
> that the timing pulse be \"launched\" at a known offset relative to
> the capture of the clock value in either the DOM MB or the DOM HUB. It
> appears that the actual instant (defined as = clock value when leading
> edge appears) of waveform generation can be captured and loaded into
> the data packet \"on the fly\". In this perspective, every transmitted
> packet can be time-stamped and digitized, without significant penalty
> in resources or effort to do this. Conversely, every received packet
> can be time-stamped \"on the fly\" as well. Both DOM MB and DOM HUB
> will be capable of this, since their circuitry is mandated to be
> equivalent, in order that the RAP method may avoid systematic error.
> However, the higher level software need not attend to the information
> content provided by the clock value and/or leading edge digitizations;
> these will be utilized only as needed to maintain the level of
> accuracy. For this to work robustly, the API must be established that
> places the correctly associated relevant time-stamps of packet
> transmission and packet waveform reception.
>
> It is important to note, that in the functionality as defined above,
> the machinery of time-stamping automatically senses the appearance of
> the data packet leading edge, and loads the corresponding value of the
> clock at the predetermined slot into the packet. Because of this,
> there is no constraint on software, protocol, or modulation schemes as
> to when a packet transmission must occur. This important feature makes
> all the timing functions, including RAP, completely transparent.
> Higher level software algorithms must be written to cope with variable
> time intervals between points in the fits - a trivial requirement.
>
> A further requirement for the fast communication capability is that a
> boot-strap mode be available that will provide the highest level of
> safety in communications to the DOM MB, presumably similar or
> equivalent to the 38kbaud technique in use now for string 18. In other
> words, fast communication functions shall not be necessary to start
> the DOM MB from a power-down state, and initiate higher levels of
> functionality from the surface.

The fast communication process must not introduce noise into the PMT
signal capture process. While this is definitely a concern during
circuit design and PCB layout, it would seem unlikely to depend upon
protocol choice.

> **[ACTIONS:]{.underline}**

-   Determine if the DOM MB hardware can be designed to permit the use
    of either a digital or analog demodulator, preserving boot mode,
    etc.; while the digital waveform capture is necessary for timing
    functions, the analog demodulator may be necessary for boot mode.

-   Design and make a test setup to demonstrate that the timing, noise,
    speed and bootstrap requirements are preserved.

-   Complete circuit design applicable to both DOM MB and DOM HUB, in
    concert with DESY colleagues;

```{=html}
<!-- -->
```
-   Produce technical note describing anticipated performance for DOM
    MB.

-   Determine impact of protocol selection on software applications
    executing on both the DOM MB and DOM HUB. Analyze interaction
    between firmware implementation and low level software drivers to
    insure proper and efficient messaging behavior between DOM MB and
    DOM HUB. Document key features and behavior requirements needed in
    final implementation.

*Estimated EE effort: **20 (GTP)***

*Estimated CS effort: **6 (JJ)***

*Estimated Sr CS effort: **20 (CMcP)***

*Estimated TBD CS effort**: 20 (CMcP)***

*Estimated resources: **\$2K***

-   **Bootstrap Scenario**: Guaranteed communications must be available
    to each DOM MB after power-up. The existence of two DOMs/twisted
    pair will force some changes to the approach now in use for
    string 18. In short, the DOM MB must be receptive and responsive
    immediately after power-up, so that very short commands from the
    surface can sequentially initiate higher levels of functional
    response.

> **[ACTIONS:]{.underline}**

-   Modify existing bootstrap scenario to match new DOM MB design, which
    may likely involve an embedded CPU within the FPGA. Substantial
    circuit design changes are appropriate, involving new block diagram,
    even though basic scenario will be similar.

-   Demonstrate that the bootstrap methodology is robust against all
    foreseeable operational circumstances, and that risk of loss of DOM
    due to bootstrap failure is below established performance
    requirement;

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **12 (GTP)***

*Estimated CS effort: **1 (JJ)***

*Estimated Sr CS effort: **10 (CMcP)***

*Estimated resources: **\$2K***

-   **Feature Extraction:** Most of the ATWD waveforms will be single
    photoelectron (SPE) pulses, for which timing information is crucial.
    Amplitude information is of only secondary interest, once a decision
    has been made that the pulse is an example of an SPE. The algorithm
    that makes the determination whether a waveform should be classified
    as SPE or not, is of crucial importance, since the SPE waveform will
    be discarded after feature extraction, and useful information about
    pulse timing and amplitude compressed to a simple datum of just a
    few bytes. The feature extraction algorithm must be simple enough to
    reside in the FPGA and involve only integer arithmetic. It must
    produce a measure of timing that introduces negligible systematic
    error in timing accuracy or degradation of resolution, it must be
    robust in the process of decision whether a waveform is complex or
    SPE so that event characterization will not be distorted, and it
    must operate quickly enough that no significant dead-time is
    introduced. Feature extraction is essential if the IceCube array is
    to operate without local coincidence, since the amount of data
    generated by the DOM MBs without feature extraction plus local
    coincidence would exceed the bandwidth of the twisted pair.

> **[ACTIONS:]{.underline}**

-   Demonstrate that a simple feature extraction firmware exists that
    can be integrated into the general FPGA design;

-   Demonstrate that the flow of data from ATWDs can be handled without
    dead-time or system crashes;

-   Evaluate test results to show that this functionality meets the
    performance criteria set for feature extraction

-   Interact with Collaboration members extensively to establish that
    possible future developments displaying grater sophistication can be
    integrated.

*Estimated EE effort: **5 (GTP)***

*Estimated CS effort: **3 (JJ)***

*Estimated Sr CS effort: **4 (CMcP)***

*Estimated resources: **- 0 --***

***Does not include effort by Stockholm effort. (RGS)***

-   **Simultaneous Read-Write:** This is an essential but as yet
    unimplemented feature of the current DOM MB design. It requires FPGA
    design only to realize at this point. There should be sufficient
    resources in the FPGA to accomplish this goal. At present, the DOM
    MB loopS through a cycle of capture, digitize and transmit for each
    wave-form. The issue here is to determine if noise is introduced at
    the instant of waveform capture by the digital activity associated
    with transmitting previously acquired data. This task is
    intrinsically connected to the need to buffer data, so that large
    blocks of data can be framed together. It is a requirement that
    simultaneous read-write be shown to work.

> **[ACTIONS:]{.underline}**

-   Design and integrate firmware into the DOM MB FPGA design and DOM MB
    application software. This will require *Event Buffering*
    functionality to be operational (see next subtask section).

-   Test behavior to establish that buffering/read/write functionality
    is robust. This means that data corruption is insignificant,
    according to the level established in performance requirements
    Documents.

-   Measure messaging efficiency, *i.e.,* determine if FPGA + RTOS are
    handling transactions efficiently.

-   Establish that no dead-time is introduced during data acquisition
    via ATWD or FADC.

-   Transfer tested code to String 18 DOMs to permit data acquisition of
    muon events.

*Estimated EE effort: **10 (GTP)***

*Estimated CS effort: **2 (JJ)***

*Estimated Sr CS effort: **8 (CMcP)***

*Estimated resources: **- 0 -***

-   **Implement Event Buffering:** Fast communication is effective only
    when a large block of data is ready for transfer. This obviously
    requires that the DOM MB be able to format and buffer events in
    large blocks which can be retrieved from memory, even while new
    events are being stored. This is a fairly complex software/firmware
    task involving shared memory, and access control arbitration between
    FPGA and CPU. A considerable effort was made previously by Forrest
    Anderson, but most of this code has been tested, and our ideas about
    implementation have evolved from that era.

> **[ACTIONS:]{.underline}**

-   Modify existing DOM MB software application to accrue many events
    using an established format. Initially, this will not involve
    feature extraction; final software must be able to accommodate both
    compressed and uncompressed event formats.

-   Test functionality using dummy data to show that data corruption is
    insignificant.

-   Test functionality using real data from Lab DOMs.

-   Transfer tested code to String 18 DOMs to permit data acquisition of
    muon events.

*Estimated EE effort: **20 (GTP)***

*Estimated CS effort: **3 (JJ)***

*Estimatedsr CS effort: **10 (CMcP)***

*Estimated TBD CS effort**: 10 (CMcP)***

*Estimated resources: **- 0 -***

-   **Quad Cable Impedance Modifications**: In the current design, power
    for the DOM MB flows through termination resistors at both source
    and sink. This wastes substantial power. Signal termination may be
    realized without forcing the DC to pass through the resistors. It is
    undesirable to increase the DC source voltage beyond about 100 V for
    a variety of reasons such as personnel safety, and reliability
    (MTBF) of the DC/DC converter in the DOM MB. This circuit
    engineering task may affect the choice for fast communication
    protocol, since the likely design path will include inductors to
    pass the DC, capacitors to block DC and pass the AC signals, all of
    which will introduce time constants and ballistic effects.

> **[ACTIONS:]{.underline}**

-   Establish the maximum permissible distortion of the timing
    synchronization pulses, so that the electrical engineering goals are
    understood.

-   Explore simple designs using passive components, especially
    inductors with desirable resonance characteristics.

-   Simultaneously explore technical benefits of DC-DC converters to
    establish the supply voltage range; this affects the DC current and
    hence the ferrite saturation characteristics of particular
    inductors.

-   Perform timing tests using the LBNL DOM pair to measure the
    performance of the impedance modifications for both power
    dissipation and timing.

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **10 (GTP)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CSeffort: **0 (CMcP)***

*Estimated resources: **\$1.5K***

-   **Common-Mode Noise Rejection:** The twisted-pairs that carry the DC
    and AC will be vulnerable to some extent to external noise sources,
    especially noise sources such as motor controllers for drilling and
    winch operations. Some evidence now exists based on work by DESY
    that a better differential receiver design may be employed at both
    DOM MB and DOM HUB.

> **[ACTIONS:]{.underline}**

-   Work together with DESY collaborators to understand and measure the
    performance of their design, including robustness against
    discharges, overloads.

-   Measure performance of mutually agreed circuit design, as shown by
    timing resolutions and other criteria.

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **5 (GTP)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **\$1K***

-   **Communications Overload Recovery:** This is an example of
    straightforward circuit design. The original DOM MB design was
    hurried and inappropriate component values were used. The new design
    may also exploit new products with more desirable recovery
    characteristics.

> **[ACTIONS:]{.underline}**

-   This requires measurements using overload pulses to ensure that no
    pathology or risk is present in that circumstance.

*Estimated EE effort: **1 (GTP)***

*Estimated CS effort: **0 (JJ) ***

*Estimated Sr CSeffort: **0 (CMcP)***

*Estimated resources: **- 0 -***

-   **Delete optical fiber interface:** String 18 is a hybrid design,
    and optical communications are not needed for IceCube. This is a
    short easy task.

> **[ACTIONS:]{.underline}**

-   Eliminate components in circuit design that are no longer relevant.

*Estimated effort: **0***

*Estimated resources: **0***

***Estimate to be added at later date as required -- not included in
cost estimate 25 April 2002 (RHM)***

-   **Neighbor logic:** The modifications desired for this functionality
    are to obtain flexibility in operation. By using two transformers
    instead of one, the neighbor logic can, by FPGA design modification,
    be operated as a \"coherence length\", rather than be limited to
    nearest or next-to-nearest neighbor operation. The FPGA design would
    be changed to accept signals from either direction, and propagate
    them uni-directionally, but with ever-diminishing duration.
    Eventually, the signal length would become zero, thereby ending the
    coincidence correlation. Thus, by varying the initial signal
    duration, the coherence length can be chosen at will. Or, the
    original nearest-neighbor or next-to-nearest neighbor logic can be
    retained by programmatic choice. The circuit design changes would be
    minimal; however, test effort (accounted for elsewhere) to
    understand optimal behavior is substantial.

> **[ACTIONS:]{.underline}**

-   Perform DOM MB circuit design changes;

-   Perform simulations to demonstrate that a coherence length is
    possible;

-   Modify FPGA design to permit individually generated pulses of
    controlled length;

-   Test circuit design on bench to measure pulse characteristics, using
    a length of cable appropriate to "octopus" concept;

-   Show that two DOMs can properly detect the new pulses;

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **3 (GTP)***

*Estimated CS effort: **1 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **\$0.5K***

-   **Implement ATWD ping-pong for dead-time reduction:** This general
    feature has been implemented successfully by T. Stezelberger in
    KamLAND, using however, VHDL code for Xilinx FPGA. Nevertheless, the
    experience and code should be almost directly useful for IceCube.
    The additional resources within the Altera FPGA need to be
    considered as part of the choice of size. The effort has not yet
    been estimated.

> **[ACTIONS:]{.underline}**

-   Transfer Xilinx-oriented code to Altera, modifying as needed to
    integrate into DOM MB FPGA code;

-   Modify DOM MB application software to track existence of
    dual-provenance data;

-   Test codes to establish that ping-pong functionality is seamless,
    and that data integrity is maintained;

-   Measure analog performance to demonstrate that each channel is
    performing symmetrically.

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **5 (GTP)***

*Estimated CS effort: **2 (DRN)***

*Estimated CS effort: **20 (TS)***

*Estimated resources: **\$0.5K***

***Note: this effort is not included in the cost estimate of 25 April
2002 , will be added in later iteration (rhm)***

-   **Integrate three PMT gain channels to ATWD**: Due to time
    constraints, only two PMT signal channels were implemented, although
    a third ATWD channel is available. In string 18, this channel was
    implemented to provide calibration features, not yet exploited;
    these test features need to be re-examined as to need. Since the
    potential dynamic range from physical processes is so large, it is
    desirable to implement a third gain path, similar to that achieved
    for KAMLAND. Connected to this task is the need to demonstrate low
    noise behavior of the DOM MB circuitry, so that the high gain
    channel, which has the ATWD launch discriminator, will operate in a
    stable fashion with thresholds in the 1 mV range.

> **[ACTIONS:]{.underline}**

-   Review KamLAND design, eliminating high-power parts;

-   Simulate performance to establish that low-power version will meet
    specs;

-   Make prototype board of 3-range analog signal-processing chain,
    except for ATWD.

-   Measure performance of 3-range analog signal-processing prototype
    board;

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **10 (GTP)***

*Estimated CS effort: **1 (JJ)***

*Estimated Sr CS effort: **1 (CMcP)***

*Estimated resources: **\$9K***

-   **Demonstrate Low Analog Signal Path Noise:** Unwanted noise can
    arise from a variety of sources, compromising performance. One
    source observed in string 18 is the PMT HV base, almost surely the
    DC/DC converter coupling back through the interface. More generally,
    this task may be characterized as the application of known design
    and layout practices, in concert with a \"systems\" design approach,
    that will reduce noise to the irreducible source levels inherent in
    the PMT itself and amplifiers prior to the ATWD and launch
    discriminator.

> **[ACTIONS:]{.underline}**

-   In consultation with other electrical engineers, as appropriate,
    reach a consensus as to general design and layout principles;

-   Emphasize choices affecting analog performance technical design
    approaches at each Design Review.

-   Measure performance of each prototype board, including simultaneous
    read/write and any other potentially noisy operation.

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **6 (GTP)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **\$8K***

-   **Delay Line Choice:** The ATWD requires a PMT signal delay of about
    70 ns prior to presentation to the ATWD inputs. Most of this arises
    from clock resynchronization, propagation delays in the high-gain
    signal path to the launch discriminator, etc. The actual delay
    depends on DOM MB clock frequency, number of desired baseline
    samples, etc. In string 18, this delay was implemented as ordinary
    coax. It resulted in an awkward looped bundle nested under the DOM
    MB. Relatively heavy, it presented mounting and strain relief
    challenges, as well as concerns about reliability of the soldered
    connections to the DOM MB. The main virtue of this solution was that
    the signals were relatively undistorted after passage through. Thus
    there is motivation to consider a lumped delay line, á la KAMLAND,
    as a attractively compact alternative to the normal coax. The
    concern about this form of delay line is that it involves a fairly
    large number of internal solder joints, which may compromise
    reliability. Another possibility then, is to use a stiff
    self-supporting rigid coax that could even serve to add mechanical
    strength; concerns about reliability would seem to be the smallest
    for this possible solution. The task is to make an early but robust
    decision for this component.

**[ACTIONS:]{.underline}**

-   Consult with UW Physics/SSEC Engineering personnel who may have
    relevant expertise;

-   Review technical performance criteria for trade-offs;

-   Evaluate different technical pathways against performance
    requirements;

-   Reach a decision including risk, cost, assembly/integration,
    factors;

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **6 (GTP)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **\$4K***

-   **FADC PMT Data Stream:** The PMT anode signal path is split not
    only to channels of the ATWD, but also to a dedicated 10-bit FADC
    running at the DOM MB clock frequency. The motivation for this data
    stream is to capture very long signals that would be observed for
    extremely energetic events at a distance from the DOM, for which the
    ATWD record is too short for complete capture. At these longer
    times, a highly structured signal is not expected. For the ADC to
    capture the signal without aliasing or loss of information,
    pseudo-gaussian shaping with a σ roughly equal to the clock period
    is needed. In other words, the PMT signal must be "stretched" by
    about a factor of six. The inescapable penalty is some loss of
    pulse-pair resolution; still much can be recovered, in principle.
    This data stream in string 18 had been unexamined until now (8
    May, 2002) due to lack of available FPGA design effort. Data is now
    being collected and examined; record boundaries need attention, but
    noise looks good. Both software and firmware effort is needed to
    integrate this data stream together with the ATWD record in a useful
    format.

> **[ACTIONS:]{.underline}**

-   Design and write FPGA code to capture and integrate FADC data
    stream;

-   Test code in LBNL DOM pair, demonstrating robust behavior;

-   Transfer robust code to string 18;

-   Establish integrity of string 18 data stream;

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **10 (GTP)***

*Estimated CS effort: **2 (JJ)***

*Estimated CS effort: **2 (CMcP)***

*Estimated resources: **- 0 -***

-   **PMT FADC Dynamic Range:** At the DOM/DOM HUB meeting held at Penn,
    the idea to utilize a piece-wise linear transfer function gained the
    most support, relative to other possibilities such as square-root or
    log(amplitude). The design issues here need to be examined to see
    what is reasonably possible. The alternative approach to use two
    FADCs to achieve a higher dynamic range was felt to be
    inappropriate.

> **[ACTIONS:]{.underline}**

-   Consult with stakeholders to establish technical goals. This may
    require a mini-meeting by video- or teleconference. Context of this
    meeting should include technical preparation so that trade-offs are
    understood.

-   Reach a decision as to acceptable limitations in performance and
    choose pathway;

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **8 (GTP)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **\$1K***

-   **Two DOMs/Twisted Pair:** This requirement imposes fundamental
    changes in the basic communications, and affects several aspects of
    software and firmware design. In addition, a network to split power
    and signals between the breakouts and the DOM pair must be included.
    The network has been at least partially designed, but reliability
    and packaging issues remain. A second option is to simply \"add\" an
    unterminated DOM to the twisted pair using only a short-stub cable.
    This second option eliminates all parts, packaging, and connectors
    of the impedance matching network, with a presumed reduction in risk
    and cost; Instead, this second option introduces a small impedance
    blip whose magnitude is directly proportional to the stub length.
    The second option needs considerable effort to characterize all
    expected systematic and resolution effects on timing. Initial tests
    show an impact that is in the ballpark expected. Software changes
    may be sufficient to compensate for pulse shape degradation. The
    software issues, such as conversion to a strict master/slave
    relationship, affect nearly all aspects of messaging, including the
    bootstrap process. Part of this task is to show that the excellent
    timing resolutions demonstrated with string 18 also can be achieved
    with two DOMs per twisted pair.

> **[ACTIONS:]{.underline}**

-   Evaluate different technical approaches, which span the range of
    possible degrees of termination. This involves both circuit design
    and algorithmic design;

-   Organize a mini-meeting among the stakeholders to evaluate test
    results;

-   Reach a consensus decision that the degradation in performance using
    two DOMs/pair is understood and that the performance meets
    requirements;

-   Produce technical note describing anticipated performance for DOM
    MB.

-   Evaluate impact of signaling mechanism on low level communications
    with bootstrap. Evaluate design to verify ability to selectively
    communicate with either DOM on the twisted pair during under both
    high speed and bootstrap communications models.

*Estimated EE effort: **11 (GTP)***

*Estimated CS effort: **8 (JJ)***

*Estimated Sr CS effort: **10 (CMcP)***

*Estimated TBD CS effort: **10 (CMcP)***

*Estimated resources: **- 0 -***

-   **Evaluate TOYOCOM Oscillators:** This revisits the outstanding work
    done earlier to assess the frequency stability and phase noise of
    the TOYOCOM products now in string 18. The test set-up will need to
    be re-established, and modified somewhat to match the new devices
    characteristics, and also to permit more devices to be tested,
    perhaps as many as three strings worth, *i.e.,* about 200 parts.
    Initial tests of one of the new batch indicate promising results,
    *i.e.,* stability of frequency is comparable to string 18.

> **[ACTIONS:]{.underline}**

-   Re-establish the high precision test-bed used on an earlier batch of
    oscillators;

-   Measure a statistically significant sample evaluation of the recent
    batch Toyocom devices;

-   Promulgate results expeditiously, as results affect system behavior;

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **15 (GTP)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **\$7K***

-   **PMT HV Base Interface:** The PMT HV base needs an interface that
    provides complete decoupling of any noise related to the DC/DC
    conversion. To realize this decoupling will require the replacement
    of the analog HV control with a digital interface, ground plane
    design to eliminate ground loops. This task requires continuing
    liason with those responsible for the base design, and testing to
    prove that the goals of noise suppression and HV stability are met.

> **[ACTIONS:]{.underline}**

-   Establish and maintain close communication with UW and Mainz
    regarding performance specifications and interface;

-   Test PMT HV base with DOM MB as available to establish
    compatibility;

-   Test PMT HV base with DOM MB as available to establish absence of
    degrading noise in DOM MB analog performance;

-   Produce technical note describing anticipated performance for PMT HV
    base with DOM MB.

*Estimated EE effort: **10 (GTP)***

*Estimated CS effort: **1 (JJ)***

*Estimatedsr CS effort: **0 (CMcP)***

*Estimated resources: **- 0 -***

-   **PMT Base Production Testing:** We feel that we should be involved
    to make sure all needed performance requirements are met, and
    appropriate tests are done, and check results, even though the
    primary responsibility lies elsewhere. As is well-known, HV
    subsystems are notorious for problems and MTBF. For example, in the
    requirements, GTP asked for a higher temperature PCB material to
    reduce the damaging effects of the soldering process. Until proven
    otherwise, we should look carefully for PCB degradation associated
    with soldering to the PMT pins. Several other tests are foreseen,
    but do not need to be listed here.

> **[ACTIONS:]{.underline}**

-   Involvement in design, test, and production phases;

-   Close communication with UW physics/SSEC engineering to ensure
    integrity.

-   Produce technical note describing anticipated performance for PMT HV
    base with DOM MB.

*Estimated EE effort: **2 (GTP)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **- 0 -***

-   **LED Beacons:** The GaN LED beacons work well, but little attention
    could be given to their optimization, especially to a calibration of
    the absolute light output, as viewed from some distance from the
    sphere. Both amplitude and frequency can be controlled. The
    requirements for the beacons have not been set. This task requires
    effort on the part of the physics collaborators to determine the
    precise goals and requirements. There may be more engineering effort
    needed to realize these requirements, once they are well-defined.
    There has been discussion of adding \"light output waveform\"
    capability. While certainly possible, this would represent a
    complete redesign of this capability, and no effort has been
    allocated toward this possibility.

> **[ACTIONS:]{.underline}**

-   A mini-meeting will be organized to establish the needs and
    corresponding requirements for calibration and event simulations;

-   Performance requirements should be set and ratified.

-   Design effort should be estimated for the ratified requirements, and
    engineering costs adjusted;

-   Design modifications to LED Beacon Board;

-   Produce technical note describing anticipated performance for DOM
    LED Bacon Board.

*Estimated EE effort: **5 (GTP)***

*Estimated CS effort: **7 (JJ)***

*Estimatedsr CS effort: **0 (CMcP)***

*Estimated resources: **\$4K***

-   **DC-DC Converters:** The string 18 DOMs used a commercial part from
    Ericsson to convert the \~80 VDC to ±5VDC. A few of these parts
    displayed early failures, despite an advertised MTBF of more than a
    million hours. In addition, the devices needed considerable
    filtering and decoupling to avoid noise injection. The family of
    DC-DC converters Ericsson offers accepts input from 36 VDC to 72
    VDC, lower than the \~100 V we would choose. Furthermore, the
    efficiency of these parts is less than can be obtained by custom
    design. Some effort is needed to determine whether newer commercial
    parts can offer the desired performance, or whether a custom
    discrete design provides a preferred solution.

> **[ACTIONS:]{.underline}**

-   Consult with experts as appropriate;

-   Review performance requirements for trade-offs;

-   Evaluate attractive commercial candidate parts for efficiency,
    noise, filtering, robustness;

-   Reach a decision that incorporates all factors.

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **15 (GTP)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **\$1K***

-   **FPGA with Embedded ARM CPU, or not?** New product offerings from
    Altera provide an opportunity to combine the FPGA and an ARM CPU in
    one package. The product of particular interest would be a hard-core
    CPU with \~100K gate FPGA. The costs would be attractively reduced
    relative to separate packages, and reliability would presumably be
    enhanced. One large BGA with 484 I/O traces would be used, rather
    than two 256 pin devices. With fewer interconnects on the PCB,
    rerouting layout time will be reduced. Noise may be reduced since
    most digital activity is confined within one chip. The smaller
    feature size, in concert with reduced trace numbers and lengths,
    will substantially reduce power dissipation. The software and
    firmware implications of this choice are not yet fully explored, but
    may be manageable, and may offer advantages in system operation. For
    example, the buffering of events to accommodate simultaneous
    read/write may be facilitated by an embedded CPU. On the other hand,
    the bootstrap procedure must be reconsidered and perhaps
    restructured. This decision needs to be managed so that the risk of
    surprises along the way is minimized.

> **[ACTIONS:]{.underline}**

-   Consult with Altera personnel;

-   Identify and evaluate risk factors and commercial trends;

-   Estimate effort levels for either technical path;

-   Reach a technical decision, documenting the basis for choice.

-   Produce technical note describing anticipated performance for DOM
    MB.

-   Evaluate available RTOS for Altera ARM architecture and select OS
    for production DOM MB and application. Evaluate and select suitable
    software development tool chain for application porting from
    existing string 18 processor.

-   Evaluate proposed features of Altera ARM part for their impact on
    operation of both existing and to be developed DOM software
    components.

*Estimated EE effort: **20 (GTP)***

*Estimated CS effort: **1 (JJ)***

*Estimated CS effort: **20 (CMcP)***

*Estimated TBD CS effort: **35 (CMcP))***

*Estimated resources: **\$4K***

-   **IceTop Design Variant:** IceTop presents several important
    differences in operation relative to IceCube. Will heating be
    required at all times to protect components from damage, or will
    heating be needed for stable operation, but not for damage? The
    bandwidth needed to transport IceTop data may be substantially
    higher than the \~10kbyte/s per DOM anticipated for IceCube. The LED
    Beacon board may not be needed, or perhaps modified.

> **[ACTIONS:]{.underline}**

-   Consult with ICETOP personnel to ensure that requirements are
    mutually understood and consistent with ICECUBE system design goals;

-   Establish that differences exist only in software and firmware;

-   Establish impacts for DOM HUB, if any;

-   Establish impacts for Master Clock, if any;

-   Include variant impacts, if any, as part of PDR;

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **10 (GTP)***

*Estimated CS effort: **8 (JJ)***

*Estimated Sr CS effort: **? (CMcP)***

*Estimated resources: **\$8K***

-   **New DOM Main Board Layout:** Clearly, with all the circuit design
    changes, the DOM MB layout will be essentially new. Changes may
    occur in the LED beacon board as well.

**[ACTIONS:]{.underline}**

-   Choose software tools that optimize results;

-   Perform new bottoms-up layout according to circuit design schematic
    and general layout principles;

-   Hold review to provide opportunity for stakeholders and outside
    experts to evaluate the layout organization;

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **35 (GTP)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **\$3K***

-   **\"Production Engineering\":** All components will have to be
    carefully selected, and in some cases tested, for compatibility with
    -40^o^ C; for ICETOP, the working temperature is likely to be about
    -48^o^ C. String 18 DOMs were not engineered for reliability due to
    the extreme schedule pressures imposed by the deployment window, and
    there have been several failures. For the production DOM MB version,
    component selection and fabrication procedures will require
    substantial investigation to maximize reliability within cost
    constraints.

> **[ACTIONS:]{.underline}**

-   Consult with UW SSEC experts, and with experts that they recommend;

-   Establish temperature cycling facility that meets both temperature
    range and cycling needs;

-   Explore and understand available literature concerning impact of low
    temperature on MTBF of parts, procedures, and PCBs;

-   Identify highest potential parts and fabrication risks;

-   Perform some destructive testing to determine reliability of specs
    and parts;

-   Hold review to provide opportunity for stakeholders and outside
    experts to evaluate the proposed plan for production engineering;

-   Establish crude but useful estimates for MTBF;

-   Produce technical note describing anticipated performance for DOM
    MB.

*Estimated EE effort: **40 (GTP)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **\$7K***

-   **DOM Main Board Fabrication:** After design, at least two, and
    probably three versions will be fabricated and loaded. Parts need to
    be purchased, organized, and delivered to chosen vendor. Vendors may
    need to be pre-qualified by some criteria to maximize reliability.
    The unpleasant recent history experienced by the KamLAND group
    suggests the need for diligence. Assumptions are that the first run
    is four machine-loaded boards, the second run is six machine-loaded
    boards, and the third run (the DOM MB \"production\" model) will be
    18 boards, then as many as 28 DOM MBs will be built. Cost
    assumptions are \$2K set-up charge for machine-loading (incurred
    three times  \$6K), \$10K for all three loading cycles, \$18K for
    parts (for 28 boards), and \$8K for three different PCB production
    cycles.

> **[ACTIONS:]{.underline}**

-   Following ratified plan for production engineering, embark on plan
    for fabrication of DOM MBs as scheduled;

-   Pre-qualified vendors will be visited prior to contract award, and
    monitored during fab;

-   Produce technical note describing fabrication process and
    procedures.

*Estimated EE effort: **15 (GTP)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **\$42K***

-   **DOM Main Board Test:** This requires the existence of an
    operational test setup, including firmware/software. The
    availability of a temperature-cycling facility which can reach as
    low as -55 ^o^ C is essential. Documentation of results will absorb
    significant effort.

> **[ACTIONS:]{.underline}**

-   Establish a DOM MB test-bed which can support the Test Software
    suite;

-   Perform tests that establish performance of DM MB against
    performance requirements. This is an extensive list of tests that
    will need to be defined as a separate document;

-   Hold a mini-meeting to present and evaluate intermediate results;

-   Revisit technical measurements as found necessary;

-   Produce technical note describing measured performance of DOM MB.

*Estimated EE effort: **30 (GTP)***

*Estimated CS effort: **4 (JJ)***

*Estimated Sr CS effort: **20 (CMcP)***

*Estimated TBD CS effort: **30 (CMcP)***

*Estimated resources: **\$7K***

-   **ATWD Evaluation**: The development of the ATWD ASIC was
    underfunded, leading to insufficient testing and documentation of
    performance and behavior. Questions have been raised as to whether
    design flaws might exist, not yet fully appreciated, but potentially
    troublesome for Icecube. No flaws sufficient to warrant a new design
    version are known at present,

**ACTIONS**:

-   An evaluation of the ATWD will be performed to verify its'
    suitability for use in Icecube. Simulations will be used to
    investigate behavior reported by Kamland.

*Estimated EE effort: **40 (PD,RHM)***

*Estimated Sr. EE effort: **80 (PD,RHM)***

-   **DOM Main Board Software:** As enumerated above, there are a number
    of key features that remain to be implemented and demonstrated.
    Several key features, fast communications, buffering of large blocks
    of PMT trigger and waveform data, simultaneous access and
    synchronization of shared data between FPGA and DOM application, are
    yet to be implemented in software. Work on these features has been
    enumerated above. However, DOM HUB design and testing as well as DAQ
    string processor design will require the development of a simulated
    DAQ test system. This system will begin with the porting of existing
    and new DOM software to run as a collection of programs on a
    standard PC-based Linux system. This effort will involve primarily
    the overall design and implementation of the DOM portion of that
    test system.

> **[ACTIONS:]{.underline}**

-   Produce Design Document describing software design and anticipated
    performance;

-   Produce technical note describing measured performance.

*Estimated EE effort: **3 (DRN)***

*Estimated CS effort: **20 (JJ)***

*Estimated Sr CS effort: **25 (CMcP)***

*Estimated resources: **\$12K***

-   **DOM Main Board Firmware Integration:** Many changes will be
    necessary, as described in many of the sub-task descriptions above.
    Effort will be needed to integrate and debug the fully fledged code
    with all capabilities included. Debugging effort may be extensive,
    and difficult to plan for precisely.

> **[ACTIONS:]{.underline}**

-   Produce technical note describing firmware design and anticipated
    performance;

-   Produce technical note describing measured performance.

*Estimated EE effort: **30 (GTP)***

*Estimated CS effort: **5 (JJ)***

*Estimated Sr CS effort: **10 (CMcP)***

*Estimated resources: **\$6K***

## [DOM HUB]{.underline}

-   **DOM HUB Design Document:** The goal of this document is to provide
    a stable base for DOM HUB design effort by describing all aspects of
    DOM behavior and control, timing scenarios, fast communications,
    network loads, messaging, and string processor behavior. The
    descriptive nature of this document is required for several reasons.
    First, as a detailed inventory of DOM HUB capabilities, it will
    provide the basis upon which staff at LBNL and DESY will logically
    divide the tasks associated with the design and implementation of
    the DOM HUB. Second, in combination with the software requirements
    document mentioned earlier, it will provide a common view of
    expected behaviors in a known set of usage scenarios. Such a
    thorough, commonly held understanding is necessary for successful
    implementation of this key element of the ICECUBE DAQ at separate
    institutions. Preparation of this document has begun. **:** We will
    produce a DOM HUB Software Requirements Document concurrently with
    the DOM HUB Design Document.

> **[ACTIONS:]{.underline}**

-   Prepare DOM HUB Design Document in concert with DESY collaborators;

-   Review DOM HUB Requirements at Engineering Requirements review;

-   Consult with UW Project Office as appropriate to maintain
    consistency with all software and configuration management issues.

*Estimated EE effort: **15 (GTP)***

*Estimated CS effort: **10 (JJ)***

*Estimated Sr CS effort: **15 (CMcP)***

*Estimated resources: **- 0 -***

-   **DOM HUB Software Requirements Document:** We will produce a
    software requirements document covering the required capabilities
    and behaviors expected from the DOM HUB. This document will be based
    on the ICECUBE high level software requirements document now being
    produced by the Software Advisory Group. The DOM HUB software
    requirements document will extend the overall system design
    principles found in the ICECUBE document down to the DOM HUB and DOM
    subsystem level. It will contain a mixture of both DOM HUB use case
    scenarios as explicit requirements governing the functionality and
    behavior of the DOM HUB software. Use case scenarios will illuminate
    known circumstances and operations within which the DOM HUB will be
    accessed and used. These should provide a complete set of operations
    within which the DOM HUB plays an explicit role. Explicit
    requirements will place performance and behavior constraints on the
    DOM HUB software when used in these various scenarios. This document
    will be fully consistent with its parent document, the ICECUBE
    software requirements document, and will act as the project's first
    top-to-bottom design and implementation cycle.

> **[ACTIONS:]{.underline}**

-   Prepare DOM HUB Software Requirements Document in concert with DESY
    collaborators;

-   Ratification through established project procedures.

*Estimated EE effort: **2 (DRN)***

*Estimated CS effort: **4 (JJ)***

*Estimated CS effort: **15 (CMcP)***

*Estimated resources: **- 0 -***

-   **DOM HUB Hardware:** The detailed circuit design, layout,
    prototyping, and testing of the DOM HUB will to be the
    responsibility of the DESY group. As noted, the main effort for LBNL
    will be in the generation of the DOM HUB Design Document and DOM HUB
    Software Requirements Document.. Nevertheless, some effort on our
    part will be needed for coordination and integration. Video
    conferencing about detailed design aspects is expected to take time
    and preparation.

**[ACTIONS:]{.underline}**

-   Collaborative development of DOM HUB Design Document, followed by
    coordination during detailed design of DOM HUB hardware by DESY
    group.

*Estimated EE effort: **4 (DRN)***

*Estimated CS effort: **5 (JJ)***

*Estimated Sr CS effort: **5 (CMcP)***

*Estimated resources: **- 0 --***

-   **DOM HUB Software:** Initial implementation of DOM HUB software
    framework.

Functionality includes communication and testing of DOM HUB interface
and design.

> **[ACTIONS:]{.underline}**

-   Design interface mechanisms and data structures for interface
    firmware and Linux driver software.

-   Design and implement Linux driver to above specifications.

-   Provide rudimentary application-level test software to verify
    operation of driver/hardware interface.

-   Design of low-level data buffering structures and mechanisms.

-   Design and implementation of DOM HUB external interface software.
    This primarily consists of TCP/IP port and messaging mechanisms for
    programmatic interactions between DOM HUB and other systems.

-   Implementation of DOM MB data buffering mechanism and DOM HUB test
    program to verify correct operation.

-   Coordination as appropriate with other software designers.

*Estimated CS effort: **80 (JJ)***

*Estimated CS effort: **30 (CMcP)***

*Estimated resources: **- 0 -***

-   **Test System Software Requirements:** Phase 1 activities are not
    aimed at full production of DOM MBs and DOM HUBS in volume. When
    such production does begin however, a robust, production quality
    testing environment will be needed. As part of Phase 1, we
    anticipate specifying the software requirements for a production
    test environment that will assist the production, deployment and
    maintenance of ICECUBE DAQ and computing hardware and software for
    the life of the experiment. While some discussion has already taken
    place, we feel that Phase 1 activities will provide a fertile
    environment for fully developing and finalizing the requirements for
    such a system. It is unlikely that Phase 1 funding will allow
    development of any production level testing software. That effort
    will follow in subsequent production phases.

> **[ACTIONS:]{.underline}**

-   Write test software suite requirements document, describing scope
    that will permit an evaluation of the DOM MB and DOM HUB performance
    and behavior. The software should be able to span all of the
    relevant capabilities, so that all performance requirements
    established for ICECUBE may be tested.

*Estimated EE effort: **2 (DRN)***

*Estimated CS effort: **2 (JJ)***

*Estimated Sr CS effort: **10 (CMcP)***

*Estimated resources: **- 0 -***

## [String 18]{.underline} 

-   **Simplified PMT Data Buffering scheme**. This is a simplified data
    buffering mechanism that will allow the capture of multiple events
    in look back memory. Data thus captured will be read out using
    existing slow communications link and existing readout routines.
    This capability is now essentially realized.

**[ACTIONS:]{.underline}**

-   Modify current DOM CPU application to create a large buffer size;

-   Modify current DOM CPU application to maintain pointers and byte
    counts, *etc*, to permit downstream analysis to unpack events.

*Estimated CS effort: **5 (JJ)***

*Estimated Sr CS effort: **5 (CMcP)***

*Estimated resources: **- 0 -***

-   **\"DOMSERVER\" Software**: Several distinct elements remain to be
    completed, some of which are now nearly complete, others in
    progress.

> **[ACTIONS:]{.underline}**

-   DOMCOM control/autonomous sending of messaging to DOMs;

-   Communications state machine which prevents conflicts or collisions
    between messages coming from DOMSERVER threads, or externally, from
    the executive;

-   Migrations of SYNCSERVER software functions, *e.g.,* time
    calibrations, into DOMSERVER;

-   Automatic retrieval of data and sending to the software package
    EBTRIG, (formerly known as PennDAQ);

-   Many more subtasks, as defined in \"String 18 Operations in
    Detail\", by **JJ**

*Estimated EE effort: **1 (DRN)***

*Estimated CS effort: **12 (JJ)***

*Estimated Sr CS effort: **1 (CMcP)***

*Estimated resources: **- 0 -***

-   **\"DOMEXEC\" Software:** This is the String 18 \"executive\". It
    controls both DOMSERVER and EBTRIG.

**[ACTIONS:]{.underline}**

-   Design script to integrate operations of the two software modules,
    presenting a reasonably straightforward interface to user.

*Estimated EE effort: **0 (DRN)***

*Estimated CS effort: **9 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **- 0 -***

-   **Buffering of DOM Data**: This task will hopefully have substantial
    overlap with the IceCube DOM firmware/software. Experience gained
    here should be very valuable. This task is closely related to the
    *Simplified PMT Data Buffering* task. This capability is now close
    to full realization.

> **[ACTIONS:]{.underline}**

-   Modify current FPGA design to interleave memory access between CPU
    and FPGA;

-   Modify current DOM CPU application to manage multiple events.

*Estimated EE effort: **3 (DRN)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0 (CMcP)***

*Estimated resources: **- 0 -***

-   **Commissioning Plan**: This process is proceeding very well so far,
    but in an *ad hoc* manner. Benefits should occur if an orderly plan
    is evolved.

> **[ACTIONS:]{.underline}**

-   Define priority sequence for string 18 tasks, balancing Icecube
    development goals with physics content analysis.

*Estimated EE effort: **10 (GTP)***

*Estimated CS effort: **1 (JJ)***

*Estimated Sr CS effort: **2 (CMcP)***

*Estimated resources: **- 0 -***

-   **Event Capture** and **System Efficiency:** Not every event needs
    to be acquired and analyzed. However, a captured event need to be
    acquired with all DOMs live and ready to acquire data; in other
    words, events partially registered are of little to negative value
    for analysis. Goals need to be set for what fraction of all possible
    events need to be acquired to achieve analysis goals. This is also
    tied up with fast communications if a fraction larger than what
    \"slow\" communications can provide. This is also connected
    intimately with the next subtask.

> **[ACTIONS:]{.underline}**

-   Analyze relationship of physics content with effort levels to obtain
    data sets of optimum size for Icecube event characterization.

*Estimated EE effort: **2 (DRN)***

*Estimated CS effort: **1 (JJ)***

*Estimated Sr CS effort: **1 (CMcP)***

*Estimated resources: **- 0 -***

-   **Data Analysis Goals:** These have not yet been written down with
    clarity, and are needed to integrate other collaboration members
    into a wider effort.

> **[ACTIONS:]{.underline}**

-   Work together with Icecube collaborators to define goals for string
    18 software developments, balancing effort level estimates against
    return for Icecube.

*Estimated EE effort: **0 (DRN)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **1 (CMcP)***

*Estimated resources: **- 0 --***

-   **Timing Tests with Atomic Clock:** The new rubidium clock will be
    more stable than the GPS units that have been previously used. These
    tests are underway, made possible by heroic efforts on the part of
    String 18 team. Initial analysis indicates that the resolutions now
    observe fall in the range of 1 - 2 ns rms, a truly excellent result.

> **[ACTIONS:]{.underline}**

-   Using current software and firmware, make new measurements of DOM
    Toyocom oscillator clock stability in the lab, and at the pole, with
    the goal of identifying sources of noise in either the DOMCOM cards
    and the string 18 DOMs.

*Estimated EE effort: **2 (DRN)***

*Estimated CS effort: **0 (JJ)***

*Estimated Sr CS effort: **0** **(CMcP)***

*Estimated resources: **\$1K***

***Not included in estimate of 25 April 2002. (RHM)***