The Big Picture... answering the big picture questions will help to design and implement solutions in many of the smaller tasks.
Big picture question 1: Is there/will there be a finalized list of LLRF BSA PVs or should this be open-ended, i.e. design a system that can handle an ever-increasing number? Note that Franz-Josef is currently asking for new BSA PVs that originate on IOCs that are not on the private LLRF network. Adding these would require long-haul ethernet cabling to klystrons in the gallery and even additional switch if no free ports.
Big picture question 2: Will the BSA acquisition PVs be moved off to a Linux server so that the IOC does not have to take the load? This action would make big picture question 1's answer be able to be the open-ended solution.
If the IOC has to handle an open-ended load, it may be necessary to add mvme6100s to the crate and divide up the code across the processors.
Big picture question 3: What is the plan for beam-based longitudinal feedback? I.e. where will this processing reside? Originally, it was planned to reside on the LLRF VME crate at Sector 20. That is the reason ALL of the
LLRF local fast feedbacks reside in one IOC.
Big picture question 4: How does the AIP LLRF upgrade, including MKSU and SCP applications, fit into the picture? We need to make decisions that allow a path for this.
Tasks: in the order I plan to do them

- Fix laser jumps at startup and after source change. Be able to boot up correctly with any source (before, laser phase was always initialized to use 119 MHz source and then operator could switch to 2856 MHz after init). Automate the bucket preservation when changing from 119 MHz source to 2856 MHz source. Done 11/24/2008

- Implement Laser Phase BSA. Done 11/21/2008
- Create PVs for PAC ADCs (new from Ron, 9/16/2008). Done 10/2008

- Design/implement udp protocol for sending I and Q adjusts from VME to PAC over 2nd ethernet. BPM app is monitor only. LLRF does control. The second ethernet could be used to send the adjustments out. Note that this is AFTER BSA has occurred. BSA PVs are only actual values, not setpoints. Determine how this data will be sent to PAC (i.e. new task or triggered by incoming data) In progress, started during downtime. Progress difficult while during running.

- Modify PAC software changes to do waveform calculation in FPGA. Jeff Olsen has changed the FPGA code to do this calculation. Coldfire can now stop doing the calc and just set values into newly defined registers. Done 10/2008. Installed on laser, TCav0, TCav3, S29 and S30 PACs. The rest still need to be reprogrammed in situ via JTAG port

- Standardize BSA PV names. Need framework if new ones are to be added. May affect archiver.Template written for what is needed. Physicists requested this not be installed 11/17/2008  

- GUI standardization. Various Panel changes - # decimal points... in progress, ongoing

- Temperature monitors - assign so that we can use these. need names, offsets, scale factors

- Gun Tune Feedback - during last week of the run (11-18 Aug), Joe was asking for additional changes because of the results of the 120 Hz gun processing. He observed that integral term was zero. Need to investigate. unknown scope

- PAC position absorption by VME when feedback enabled (done only for Laser phase loop so far) In progress for laser. Opinions differ re: is this necess anywhere else

- Access security for PVs to protect values. This would be nice, but probably not going to happen this fall

- 6/30/2008: new request for alarms when phase,ampl setpoints do no agree with actual averaged values. Done but may have a race condition with average amplitude since it ALREADY was alarmed when below threshold. 1 day

- LCLS PLL Oscillator: Use event to reset request instead of write_bo. Grab data waveforms each trigger and process them for analysis.

- Finish testing of phase cavity BSA. Done for all PCav1,2,3 and 4. 11/24/2008
- (Optional) Add the option to send the full waveform OR the processed values. This is probably not going to get done this fall

- (Optional) Write new code to handle the full waveform if sent from PAD. The processing done on the PAD now would be implemented on the VME, but now, with floating point, calcs could be different. This is probably not going to get done this fall

- PADs and PACs needed for Klystron test lab stations -- started 4/21, waiting for network subnet to be configured (new rule: only 1 subnet per switch)

- PAC for Bob Hettel of SPEAR - started 4/22. hardware ready

Ongoing tasks:

- Add alarms to channels at all levels with summaries propagated up
- Save and restore new channels
- Archive new channels

- Check archiver for disconnected channels

New, from Joe Frisch, Franz-Josef 9/16/2008

1.        RF feedbacks need to respond fast to changes in operating points (redundant with my task list)
2.        Add diagnostic klystron PADs to BSA (new. see big picture questions)
3.        Set up a test stand in the gallery for BSA testing (new)
4.        Laser BSA (redundant with my task list)
5.        Phase Cavity testing (requires test setup)(redundant with my task list, although I wasn't going to use the test setup)
6.        Second Ethernet for PACs (redundant with my task list)

Ron's additions to 9/16/2008 list:

- Read out and process PAC slow ADCs
Done. Details above
- There is a large amount of PAD test software done by Bob Steele before he was laid off.  I need someone to support this software.  No problem today.
- Test software for PAD second ethernet port.  Assign MAC address and store in database.  Would like to incorporate this into work started  by Bob Steele.
- Test software for PAC including PAC second ethernet port. 
Assign MAC address and store in database.  Till started first part of this and Vojtech will work more on this.  Nothing has been done with second Ethernet port. kdk comment: The part that Till started has nothing to do with the second eth port. It is a mod that moves calcs out of coldfire into the FPGA. I think this is two separate tasks. We could, in theory, install the BSA upgrade and then separately, upgrade the FPGAs. I think this way is a more cautious upgrade path. (redundant with my task list)
- AMRF will needs a test station and software to maintain LCLS LLRF chassis. After tests this past summer, we now know that 120Hz operation will require separation of LLRF feedbacks into four 30Hz channels.