October 30, 2006

Overview

The following changes are introduced in this release:

• Software modifications to mitigate channel buffer management problems.

• Windows batch and Unix script files for scripted diagnostic tests.

• Modifications to diagnostic programs.

• Component versions for this release.

• Known problems.

Note: This release includes a new version of the application code for the embedded MIPS processor. It is not necessary to update boards with the new code, but to do so, run the dpflashup program after installation to update the code on the DPT4 board(s).

Software Modifications to Mitigate Channel Buffer Management Problems

Previously reported problems with the dpchantest program have been tracked down to two primary issues involving management of the channel data buffers. The problems were known to cause data corruption and timeouts when run with multiple channels on faster host systems.

The first issue was that the transmit buffer bank interrupts were sometimes being inadvertently cleared by the pci_framer_tx_source and pci_hw_fast_clk library functions as they made changes to the settings in the transmit control register. These functions have been fixed to avoid clearing the interrupts. Similar operations have also been fixed in the code for the dph100test and dph100diag programs.

The second issue with channel buffer management involves saturation of throughput on the DPT4 local bus. When dpchantest first begins sending data to be transmitted, the transmit buffers are empty and the threads for each transmit channel generate and write data as fast as possible until the buffers are full. On fast host systems, the amount of data being downloaded to transmit buffers can overwhelm the board's local bus and prevent the MIPS processor from servicing the bank switch interrupts from its dual-port buffers in a timely fashion, causing corruption of data being fed to the outgoing E1 or T1 streams.

The bus saturation issue is resolved in the dpchantest by delaying the start of receive channel threads until the transmit channel buffers have been filled. Once filled, the rate at which the program can write new data is limited by the rate at which the buffers are emptied as the data is transmitted. The initial data transmitted may still get corrupted as the buffers are being filled but the receive channels don't see this data.

While the situation with dpchantest may be a worst-case scenario, other application programs need to be aware of the potential for these problems. See the discussion under known problems.

Changes were made to the embedded application program to help diagnose this problem. The updated code is version 1.4.9 and is included in this release. However, the changes do not affect normal operation of the board and it is not necessary to update the code on DPT4 boards that are already running version 1.4.8 of the embedded application code.

Script files (a batch file for Windows and a sheel script file for Unix) is now included in installation for running scripted tests on DPT4 boards. It runs the following diagnostic programs to provide a general diagnostic of the primary components of the board.

The Windows batch file is run with the following command line options:

    dpt4test.bat  minutes  seconds  cycles  ext_loop  board_name  quiet

The Unix shell script is run with the following command line options:

    dpt4test.csh  minutes  seconds  cycles  ext_loop  board_name  quiet

The minutes and seconds options specify how long the dpchantest program is run in each iteration of the script. The cycles option specifies how many iterations ir times to cycle through the script. The ext_loop option specifies whether to use external loop-back cables or use an internal loop-back in the framer chips. The board_name option specifies which board to test.

If quiet is specified as the final option, the diagnostic programs are run in a mode that produces less verbose output.

The default settings, are to test the board named dpt0 for 10,000 cycles, with dpchantest running for 2 minutes and 30 seconds, and the script will prompt the user about the use of loop-back cables. Note that loop-back mode is only useful for DPT4 boards with RJ-45 connectors.


Modifications to Diagnostic Programs

The dpchantest program is modified to work around local bus saturation issues, as described above. The -Z option (used to add delay between channel startup) is no longer functional although it is not an error to use it.

The dppiomem program is modified to exit with a status of 0 if it is successful or a status of 1 in case of errors so that the test script can determine and report its results.

The dpdebug program is modified to fix the commands for reading and writing registers in the Comet framers and has new commands for reading and writing values in the EEPROM.




Component Versions for This Release

The DPT4 software release includes several components of software and hardware FPGA configurations. All the components have the same major and minor version numbers. However the update version number of each component may vary depending on the number of changes and iterations each component has gone through between general distribution releases.

The components and their versions for DPT4 Software Release 1.4.8 are:

dppiomem	-	Tests SDRAM on the board
dpdpram	-	Tests the dual-port memory on the board using both non-burst and burst modes.
dpchantest	-	Tests MIPS channelization and framers

Component:	Version:
API Library and Programs	1.4.8
Solaris Device Driver	1.4.7
Linux Device Driver	1.4.7
Windows Device Driver	1.4.6
Embedded MIPS Loader	1.4.0
Embedded MIPS Application	1.4.9
PLD Configuration	1.4.0
Host FPGA Configuration	1.4.5
Expansion FPGA Configuration	1.4.1

Known Problems

The following problems are known to exist in this release:
• Large amounts of channel data being written to the transmit buffers can saturate the board's local bus, preventing the MIPs processor from obtaining access to the board's local bus long enough to miss buffer interrupts. This has been known to cause corruption of transmitted data and timeout errors reported by the dpchantest diagnostic program. The problem mostly appears on fast systems that are capable of downloading data fast enough to cause the local bus to saturate.

  The only work-around at this time is for applications to limit the rate at which they write data to transmit channels. The suggested limit is an aggregate download rate to approximately 24 Mbytes per second or, assuming all E1 channels are being used, 190 Kbytes per second per time slot.

• The DPT4 software is not currently compatible with Solaris 10 for x86 platforms due to a problem with allocating DMA memory.

  The Sparc platform version of Solaris 10 is compatible. Problems concerning compiler warnings have been handled with minor changes in the source code (described above).

• On rare occasions the DPT4 can hang during the initialization process. This has only been known to occur when being initialized the first time following a power cycle.