January 7, 2009

Overview

The following changes are introduced in this release:

• Fix for programming the CPLD on DPT5 and DPT6 boards.

• Updates to the API function library.

• Updates to the Linux device driver and boot script.

• Component versions for this release.

• Known problems.

Notes:

This release includes a new FPGA configuration for DPT5 and DPT6 boards. Run the dpflashup program after installation to update the FPGA configuration on DPT5 and DPT6 boards.

Fix for Programming the CPLD on DPT5 and DPT6 Boards

The FPGA configuration for DPT5 and DPT6 boards is fixed to resolve a problem with programming the CPLD device. The problem was introduced in version 1.5.5 of the FPGA with changes in the I/O configurations.

WARNING: If programming the CPLD device is attempted using version 1.5.5 or 1.5.6 of the FPGA, it could leave the board in an inoperable state. The CPLD device does not normally need to be re-programmed but using the the -f option with the dpflashup will attempt to re-program it.

Updates to the API Function Library

Operations in the API library that involve opening a device handle no longer attempt to access the boards using old device names when device access fails.

Currently, the device names begin with "dpt". Long ago they used to be named beginning with "pci". Operations such as pciopen, pci_open_chan, as well as some other functions that need to open the device first, used to try using the old names if the open failed using the new names. This was useful during the transitional period but is no longer relevant.

Updates to the Linux Device Driver and Boot Script

The use of the __init and __initdata attributes has been re-instated for the initialization routines and data when the device driver is built for 2.6 kernels. These attributes had been removed while debugging the driver registration problem that was fixed in the previous release.

The boot script installed in the RC directories for loading the driver and initializing the boards is modified to check for boards being installed before attempting to load the device driver. It checks by looking for the DPT board vendor and device IDs in the output of the lspci program.

Component Versions for This Release

The DPT software release includes several components of software, embedded code and hardware FPGA configurations. The major and minor version numbers are the same within each category. However the update version number of each component may vary depending on the number of changes and iterations each component has gone through between releases.

The components and their versions for DPT Software Release 1.5.3 are:

Software Components		Version
	API Library and Programs	1.5.3
	Solaris Device Driver	1.5.2
	Linux Device Driver	1.5.3
	Windows Device Driver	1.5.1
Embedded Code Components
	Embedded MIPS Loader	1.4.0
	Embedded MIPS Application	1.4.10
DPT4 Hardware Components
	PLD Configuration	1.4.0
	Host FPGA Configuration	1.4.5
	Expansion FPGA Configuration	1.4.1
DPT5 & DPT6 Hardware Components
	PLD Configuration	1.5.1
	FPGA Configuration	1.5.7

Known Problems

The following problems are known to exist in this release:
• The data buffers in the dual-port memory can overflow as channels are being started. The overflow can corrupt data for a channel whose buffer is using an adjacent area of the dual-port memory. The problem only occurs when a channel is being started and only occurs on DPT4 boards, not DPT5 or DPT6 boards.

  A suitable work-around for applications that open all their channels at start-up is to wait for all channels to be opened and then flush receive channels before using received data.

• 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,

• Switching to non-blocking I/O mode using the pci_chan_blocking function does not work in all cases for channels that are initially opened with blocking mode. The issue may be dependent on the host operating system as well as other factors. The pci_chan_blocking appears to be able to switch back and forth for channels opened initially with non-blocking mode.

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