August 11, 2009
Overview
The following changes are introduced in this release:
Items Specific to LightParser2:
Items Specific to LightParser:
Items Specific to DPL3:
General Items:
LightParser2: Fixed Bug in the API for Optical Receive Configuration with Packet Processing FPGA
A bug is fixed in the cac_if_rx_mode and cac_if_rx_mode_rate functions that affected operation with the packet processing FPGA configuration. The problem caused the framer for SDH signals to be left in the disabled state.
Also affected are the cac_packet_config_rcv and cac_packet_map_sdh functions that use the cac_if_rx_mode function when configuring the optical ports.
Component Versions for This Release
The API and device driver components have the same major and minor version numbers. Similarly, the "Hardware Support" versions have the same major and minor version numbers as the corresponding FPGA or FPGA type. 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 component versions for Software Release 0.9.5 are:
| Software Components | Version | ||
| API Library and Programs | 0.9.7 | ||
| Linux Device Driver | 0.9.6 | ||
| Solaris Device Driver | 0.9.6 | ||
| Hardware Components | FPGA Version | Support Version | |
| LightParser Spartan FPGA Configuration | 0.8.2 | 0.8.2 | |
| LightParser Virtex FPGA Configurations | |||
| Standard SDH/PDH variation | 0.7.0 | 0.7.0 | |
| ATM variation | 0.7.3 | 0.7.3 | |
| HDLC variation | 0.9.2 | 0.9.2 | |
| SDH/PDH Transmit variation | n/a | n/a | |
| LightParser2 Virtex FPGA Configurations | |||
| Standard SDH variation | 0.5.0 | 0.5.0 | |
| SDH Parser variation | 0.5.0 | 0.5.0 | |
| Packet Processing variation | 0.5.0 | 0.5.0 | |
| LightParser2 Boot FPGA Configuration | 0.0.1 | 0.0.1 | |
| DPL3 Main FPGA Configuration | 0.9.1 | 0.9.1 | |
| DPL3 Expansion FPGA Configurations | |||
| E3 G751 E1 variation | 0.9.1 | 0.9.1 | |
| DS-3 T1 variation | 0.9.0 | 0.9.0 | |
| E3 G832 Bulk variation | 0.9.0 | 0.9.0 | |
| Generic variation | 0.9.1 | 0.9.1 |
NDFs, announced and unannounced, are not properly handled for TU-11 and TU-12 pointers. This problem is resolved in an experimental, pre-release FPGA configuration, version f.28, included in the distribution. To load this configuration run the dplp_flashup program as shown below:dplp_flashup -uv -xf dplp0Some unannounced TU-3 pointer changes are not handle correctly which causes the tributaries fro the affected pointers to go out of sync.Data corruption has been reported when recording raw, descrambled STM-1 signals that include AU3s. This condition can normally be cleared up by resetting and reconfiguring the parser.
Using the clock extracted from the electrical (CMI) port in STM-1 mode causes some data corruption. Work-around is to use the local clock reference when receiving electrical STM-1.
The ATM version of the Virtex is not able to frame DS-3 streams from SDH streams. A work-around is to route the raw DS-3 streams from SDH input through the Quad-T3 port, loop the signal back in and frame the DS-3 signals from the Quad-T3 input.
Detection of ATM client channel overflow (pointers to the bulk ATM buffer that are no longer valid) is not yet implemented in the ATM service of the device driver.
Under certain circumstances, bit errors have been seen in one or two E1 streams demultiplexed from an E3 contained in a TUG-3 from an AU-4 in the first STM-1 (signal structure: STM-1->AU-4->TUG-3->VC-3->E3->E2->E1). The errors have not been observed in other STM-1s with this structure or with other signal structures. The problem has also not been observed if the gapping for the STM-1 is set to the minimum of 48 using the -m or -g48 command-line option to the lp2_parsercfg program.In the SDH parser, DS-3 streams from the fourth STM-1 cannot be framed or extracted using their default stream IDs.
Optical port transmit in the STD and Parser FPGA designs is limited to transmitting SDH signals at nominal rates based on the board's local clock or using direct re-transmission (loop-through) from an optical input. Although the optical transmitters can be configured to send arbitrary rates, there is not a way to use such rates for moving data.
Handling of extended packet lengths in the packet processing FPGA is not yet complete. Continuation "chunks" for HDLC (POS and LAPS) packets larger than 3072 bytes are implemented but packets that are aborted after one or more chunks are not terminated properly. Jumbo Ethernet packets from the electrical or optical ports are not yet supported.
The statistics counters for optical and electrical GIGE packets cannot be cleared except by reloading the FPGA configuration.
Support for comprehensive GIGE interface status is not yet implemented in the API.
Raw E3 or DS-3 streams cannot be transmitted from the host because there is not a way to bypass the L3 framer.Bulk E3 or DS-3 payload content cannot be transmitted in alignment with the E3 or DS-3 frame sync. Bulk payloads that require such alignment, such as PDH structures cannot be transmitted from the host.
Memory suitable for DMA allocation may become unavailable over time. When this occurs, applications may not be able to open channels requiring large DMA buffers. Currently, the only work-around is to apply the bigphysarea patch to the 2.6 kernel.When using the 64-bit variant of the Linux kernel included with Red Hat Enterprise 4, DMA buffer allocation is limited to about 12 MB. This problem has been found in all RHEL4 updates up to and including RHEL 4.7. Currently, the only work-around is to apply the bigphysarea patch to the 2.6 kernel. This problem has not appeared in Red Hat Enterprise 5, which has been tested up to RHEL5.2.