SW-Developer's Dream

Has happened to all of us. Our best bud Fritz has just finished a fancy board and drops it off on our desk. "Can you make it work? You know, write a driver and some software?". And, yes: "Can you get it done by tomorrow?". If he was nice then there is a manual, otherwise the meeting minutes from 8 months ago will have to do. Then, while designing this driver we come across some odd features of that board. We wonder what was going on in Fritzes head - why would he make certain things work in a way that makes our life more difficult? There has probably never been proper communication and some basic things we just assume to work in a particular way so we never requested specific semantics explicitly.

Thus the idea - thanks to John D. - to create this blog where we can assemble a "wish-list" of basic features we believe are important to us. Hopefully it starts a dialogue/interface between HW and SW designers...

So let's kick-off with a few things that come to my mind

• A detailed manual certainly helps.
• Firmware version number should be available to be read from a register so that SW can figure out the FW-version at run-time. The documentation should refer to these same version numbers and document changes between versions.
• It is desirable to use modern, dynamic configuration methods (for base-adresses, interrupt vectors etc.) as defined by PCI, VME64x etc. rather than "jumpers". If jumpers cannot be avoided them make their current setting available to SW via a register.
• When there are moderate to large amounts of data to be transferred (especially over VME) then try to implement efficient transfer modes (BLT, wide datapaths, new technologies like 2eVME etc).
• Commonly, there are multiple status bits in registers that are set by HW and cleared by SW. Occasionally, I have seen "clear-on-read" semantics, i.e., the bits clear automatically when SW reads the status register. This can be a real pain since it may be that different SW modules deal with different bits, hence it is very desirable that individual bits can be cleared under SW control so that a particular SW module may selectively clear the bits it is "responsible" for. Commercial HW commonly provides "clear-on-write-one" or "clear-on-write-zero" semantics. This means that a bit (which can only be set by HW, not SW) is cleared when SW writes a one (or zero) but left alone when a zero (or one, respectively) is written.
• If a particular state of the HW is spread over multiple registers then provide a way for SW to obtain a coherent reading. E.g., by latching multiple registers when the "lowest" one is read.
• Prefer level-sensitive interrupts to edge-sensitive ones. It is much easier to ensure that no interrupts are lost with level-sensitive interrupts.
• Provide interrupt status and mask registers. Status should be asserted even while interrupts are masked (and the status bits should use e.g., "clear-on-write-one", see above). This facilitates testing and debugging.
• Most OSes and thus driver software assumes that a VME interrupt vector is assigned by the OS and can be programmed on the board. Hence, HW should provide a register where the vector can be programmed and it should provide this vector during an VME IACK cycle.
• Provide a method for SW to completely reset a board to initial, power-up state.
• Reset should put the board in a useful, default state.
• Manual should specify that currently unused or "reserved" bits must always be written e.g., with zeroes by SW. This helps backwards-compatibility.

Developers: Please use this blog to capture ideas and experience on this topic. The content will be reviewed and moved to the web page upon ratification by the committee members and management.

To Add a Post:

1. Log into Confluence by clicking the 'Log In' link at the upper right hand of the screen in the blue ribbon.
2. Select the 'Add+' pull-down menu at the upper right hand of the main screen and select 'Blog post'.
3. Add a link back to the EPICS Software Standardization Page (you can copy the link at the bottom of this page and paste it into your post).
4. In the 'Label' field at the bottom of the page, add "epics-device-driver-sw-standardization".
5. Click 'Save'

Back to EPICS Software Standardization Page

bold » bold
italic » italic
strike » strike
under » under

Headings:

Large heading!

Medium heading

Small heading...

Lists:

• Bulleted point

1. Numbered point

Linking:
title » Link a page
title » In space with 'dev'
http://host.com » Remote link
phrase@shortcut » Shortcut
Note: alias » Custom link title

Tables:

What Tom said about XAL and acceleration sounds pretty accurate.
Apparently nothing has been done in that arena since I left (that was
one of my projects). I have been out of the loop for so long now, that
my judgment is probably impaired, however. The container for holding RF
gap objects could not be created proper because the way the lattice was
generated from the machine representation. If the lattice generation is
fixed, then I think the acceleration problem goes away.

Then in followup to question:
> What's the significance of the sentence "... the way the lattice was
> generated from the machine representation." What should we fix about
> it?
The XAL XML configuration file contains the machine representation. In order to do simulation you must create a model representation from it. Actually the model representation is created from the machine representation data structure in dynamic memory. It does so using the "lattice generator", which was originally written by Wolf-Dieter Klotz, on sabbatical. Well, he took the machine representation and flattened out the whole thing so that you could not have nested elements. RFGaps were supposed to live in RfCavities where they would get the phase and amplitude information. Obviously this is impossible under the current configuration. The lattice generator needs to be fixed. That is the last thing I was working on when the plug was pulled. I didn't finish, but my code is probably still in the repository. It's pretty close to finished, actually.

Hope that makes sense.
Chris

Hi Greg,

XAL's acceleration modeling is incomplete.

While the XAL online model does model acceleration, there are some
subtle details lacking that we will be implementing at some point in
the future. For example, RF cavities may add energy to the incoming
particles depending on the cavity phase. However, the online model
does not currently account for the particle's velocity and hence
arrival time when calculating the acceleration. We plan to correct
this as soon as we have time. Also, support for beam loading has
recently been added as an option.

RF cavities are treated with the linear matrix approximation. The
online model does not model the actual field profile, and probably
won't ever. It isn't really that kind of tool.

regards,
-tom
_________
Tom Pelaia, Ph.D., R&D Staff
Spallation Neutron Source, Accelerator Systems Division
Oak Ridge National Laboratory

On Oct 31, 2005, at 2:23 PM, Greg White wrote:

> Hi, ...
> does XAL model acceleration?
>

Stuart Marshall said in the IT&T seminar today, that KIPAK are already using a Mac Xserve system, and that it's already configured by taylor!