December 12, 2011
Overview
The following changes are introduced in this release:
Items Specific to LightParser2 and LightParser2e:
Items Specific to LightParser:
Items Specific to DPL3:
General Items:
LightParser2 and LightParser2e: New Demonstration Program for Section Overhead Streams
Section overhead extraction is supported in the parser FPGA configuration for LightParser2e boards and in the the basic FPGA configuration for LightParser2 boards.
New Memory Allocation Driver Module for Linux
Cacmem allocates and maintains a pool of DMA-capable memory and shares it with the hardware device drivers when they request memory for channel buffers. The memory pool is allocated when the first hardware device driver module loads and registers with cacmem, typically during system boot. When channels are closed and their buffer memory is relinquished, the memory is returned to the cacmem pool, not to the system, and remains available for channel buffers.
A new utility program called cacmem_ctrl is used to display memory allocation statistics and to control the allocation pool. Using this program it is possible to increase or decrease the amount of memory in the pool.
The Linux hardware device drivers for LightParser2/2e, LightParser and DPL3 are modified to make calls to the new module to register themselves with cacmem and to allocate and relinquish channel buffer memory. The configuration and installation process of the hardware device drivers are updated to include the cacmem module. The device drivers can be configured, at build time, to use cacmem for channel buffer allocation or to continue using the allocation method provided by the Link 2.6 kernel.
Details for configuring and installing the cacmem module with the hardware device drivers are included in the updated software installation instructions and a new document, cacmem_usage, describes operation and management of the module.
New and Modified API Functions and Macros
The channel I/O functions listed below are modified to re-examine the queue handling mode if it is not set in the channel handle. This resolves an issue in the case that the channel is opened prior to establishing the queue handler mode.
The channel open functions, cac_chanopen_stream(), cac_chanopen_list(), and cac_chanopen_mask(), now check for requested buffer size of 0 and return an error with errno set to CAC_ERR_BUFFERSMALL. The change was actually made is a common and local sub-function.
The cac_chan_source() function now sets the RX channel stream level to L4 for optical ports that are being configured to extract SOH streams. Applications no longer need to explicitly set the stream level for SOH streams as long as cac_chan_source() is called after setting the optical port's receive modes with cac_if_set_rx_mode() or cac_if_set_rx_mode_rate().
The cac_if_get_cdr_rate() is fixed to consider loss of signal status from the port's SFP when looking for LOS errors.
A new function, cac_modes2typestr(), is added the library. This function converts a channel mode value (for example CAC_CHANNEL *channel->modes) to a short string describing the stream type. The caller passes in a character array, as well as it's size, to be filled in with the result. Examples of the string at "E1", "DS-1", "STM-1", etc.
The cac_chan_sim_clr() function is modified to set the parser simulator's L1 mode into bit-mask mode so that all L1 simulation streams are disabled. Previously, stream 0 was left enabled.
The cac_sdhgroomer_map() function is modified to substitute the unequipped canned pattern when mapping signals from the output of the parser module for stream indexes that are beyond the of number of STM-0s available from the parser. This is in support of the transmit parser capability to be released in the near future.
New macros are added for specifying optical and Ethernet I/O ports. They are synonyms for exiting macros:
New error code macros are added to the library that will be used in a new release of the parser configuration functions in the near future.
New and Modified Utility and Diagnostic Programs
The lp2_chantest, dplp_chantest and dpl_chantest programs include the following changes:
The new utility program, cacmem_ctrl, is included with the new memory allocation driver described earlier.
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 1.0.5 are:
| Software Components | Version | ||
| API Library and Programs | 1.0.3 | ||
| Linux Device Driver | 1.0.4 | ||
| Solaris Device Driver | 1.0.1 | ||
| Hardware Components | FPGA Version | Support Version | |
| LightParser2e Virtex FPGA Configurations | |||
| SDH Parser variation | 0.6.4 | 0.6.4 | |
| Packet Processing variation | 0.6.0 | 0.6.0 | |
| LightParser2e Boot FPGA Configuration | 0.0.2 | 0.0.2 | |
| LightParser2 Virtex FPGA Configurations | |||
| Basic SDH variation | 0.6.1 | 0.6.1 | |
| SDH Parser variation | 0.6.0 | 0.6.0 | |
| Packet Processing variation | 0.6.0 | 0.6.0 | |
| LightParser2 Boot FPGA Configuration | 0.0.1 | 0.0.1 | |
| 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 | |
| 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 |
Under certain circumstances, bit errors have been seen in one or two E1 streams de-multiplexed 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.
Optical port transmit 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 demanding data from the host.
Transmit capability for LightParser2e is limited to 2 channels of raw SDH streams (direct to the optical ports). Attempting to use the lp2_chantest program with simulation modes using more than 10 or 11 transmit streams using simulation results in data errors.
The Packet Processing FPGA configuration for LightParser2e suffers from the following issues:
SFPDP copy modes do not work in version 0.6.0 of the LightParser2 implementation of the packet processing FPGA. A work-around is to use version 0.5.0 from Release 0.9.5 and use the -C option with the lp2_init program to have it ignore the apparent version conflict.
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 frames from the electrical or optical ports are not yet working in the packet processing FPGA.
The statistics counters for optical and electrical GIGE packets cannot be cleared on LightParser2 boards, except by reloading the FPGA configuration.
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 dplp0
Some unannounced TU-3 pointer changes are not handle correctly
which causes the tributaries from the affected pointers to go out of sync.
Data corruption has been reported when recording raw, de-scrambled 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.
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. To resolve the issue, use the cacmem memory allocation module.
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.7.