SONET/SDH Compiler. Introduction. SONET/SDH Compiler v2.3.0 Issues

Transcription

1 January 2005, Compiler Version Errata Sheet Introduction This document addresses known errata and documentation changes for version of the SONET/SDH Compiler. Errata are design functional defects or errors. Errata may cause the SONET/SDH Compiler to deviate from published specifications. Documentation changes include typos, errors, unclear descriptions or omissions from current published specifications or product documents. These documentation changes or clarifications will be incorporated into an upcoming release of the SONET/SDH Compiler. SONET/SDH Compiler v2.3.0 Issues Altera has identified the following issues that affect the SONET/SDH Compiler v2.3.0: 1. The AIRbus Interface May Not Return a Data Transfer Acknowledge for an Undefined Address Range on page Incorrect Data May Be Returned When the AIRbus Interface Reads from the Transmitter Section Trace Message Buffer on page The APPLY_3FRM Field of the Transmitter Transport Control (TXT_REG_CTRL1) Register Does Not Behave as Intended on page The srxval Signal Gates the Change in Loss of Signal Detection, Loss of Frame Detection, & Severely Errored Frame Reporting on page If Deasserted, the srxval Input Signal Causes the Framer to Immediately Go Into the LOF State on page RDI-L Is Not Updated Until the Framing & Alignment State Machine Reaches the SYNC State on page RDI-P Is Not Updated Until the Pointer Processor State Machine Reaches the NORM State on page The Detection of AIS-P or LOP-P Can Cause the Corresponding RDI-P Value to Be Inserted in the Wrong Paths on page 6. Altera Corporation 1 ES

2 9. The RDI-L Value Inserted Into the Transmit Frame Keeps a Constant Value on page The RDI-P Value Inserted Into the Transmit Frame Keeps a Constant Value on page Path Overhead Processing Is Unreliable for Certain OC-48 Variations on page The Bit Error Rate Monitor Does Not Perform as Specified on page The Midbus Interface mtxerr Signal Does Not Behave as Defined on page The Stratix GX Transceiver Requires a Specific altgxb Megafunction Reset Sequence on page The Default Value for Memory-Based Registers Should Be Set to X on page Incomplete Conditions in Table 3-3 of the User Guide on page 12. The AIRbus Interface May Not Return a Data Transfer Acknowledge for an Undefined Address Range By asserting the data transfer acknowledge (dtack) signal, the MegaCore function indicates that the AIRbus access has been completed. However, some variations of the MegaCore function fail to assert the dtack signal for accesses to certain addresses. All variations of the MegaCore function that incorporate the SONET/SDH overhead processor (SSPROC) are affected. The AIRbus interface hangs when accessing addresses in the range of addr[msb:msb-1]=2'b11 because the dtack signal does not get asserted. Ensure that you access only the address ranges listed in the top-level memory map of the HTML register file generated by IP Toolbench during the MegaCore function generation. 2 Altera Corporation

3 v2.3.0 Issues Incorrect Data May Be Returned When the AIRbus Interface Reads from the Transmitter Section Trace Message Buffer The transmitter section trace message buffer (TXT_PRC_J0_MSG_BUF) holds the J0 trace message to be inserted into outgoing frames. Although the AIRbus interface writes to memory correctly, it does not read from it correctly. All variations of the MegaCore function that incorporate the SSPROC are affected. Reading from the TXT_PRC_J0_MSG_BUF may return incorrect data. To retrieve the correct memory contents, clear the BUF_INS field of the transmitter J0 control (TXT_PRC_J0_CTRL) register, and read each memory location twice in succession. The second reading provides the correct data. The APPLY_3FRM Field of the Transmitter Transport Control (TXT_REG_CTRL1) Register Does Not Behave as Intended The GR-253 (SONET) specification specifies that no pointer increment or decrement should be performed within three frames of the previous pointer increment, decrement, or new data flag (NDF). (The SDH specification has no such requirement.) Setting the APPLY_3FRM bit is supposed to restrict the allowable pointer increments and decrements to satisfy the SONET requirement. However, setting this configuration bit causes the transmitter to restrict pointer movements for only two frames, and only after a pointer increment or decrement, not after an NDF. The SONET transmitter does not restrict pointer increments or decrements for any number of frames after an NDF. Altera Corporation 3

4 All variations of the MegaCore function are affected. The SONET transmitter may generate pointers that violate this three-frame window of restricted pointer movements, causing problems for the downstream receiver. Do not assert any pointer increments or decrements within three frames of any other pointer movements or NDFs. This applies to AIRbus- or Midbus-induced pointer movements. The srxval Signal Gates the Change in Loss of Signal Detection, Loss of Frame Detection, & Severely Errored Frame Reporting The srxval signal, used to validate the srxdata bus, is unnecessarily gating the reporting of a state change in the loss of signal (LOS), loss of frame (LOF), and severely errored frame (SEF) fields of the receiver transport interrupt status (RXT_REG_IS) register of the SONET/SDH receiver data path (SSRX_DATA) block. All variations of the MegaCore function are affected. If the srxval signal is deasserted and a change of state occurs for LOS, LOF, or SEF, the state change interrupt is not reported in the corresponding bits of the RXT_REG_IS register. 4 Altera Corporation

5 v2.3.0 Issues If Deasserted, the srxval Input Signal Causes the Framer to Immediately Go Into the LOF State The MegaCore function s current behavior causes the framer to immediately go into the LOF state when the srxval signal is deasserted. The MegaCore function s intended behavior is for the framer to enter the SEF state immediately, and to eventually enter the LOF state if the SEF condition persists for 3 ms. All variations of the MegaCore function are affected. If the srxval signal is deasserted, the framer immediately reports a LOF condition. RDI-L Is Not Updated Until the Framing & Alignment State Machine Reaches the SYNC State The line remote defect indicator (RDI-L) communicates receiver-line defects to the upstream (transmitting) device or MegaCore function. After a reset, the RDI-L sent to the upstream device does not get updated until the framing and alignment state machine reaches the SYNC state. However, once the framer reaches the SYNC state, the RDI-L is continuously updated even if the framer exits the SYNC state, provided no reset is applied. All variations of the MegaCore function are affected. The RDI-L does not get updated after a reset until the SYNC state is achieved. Altera Corporation 5

6 RDI-P Is Not Updated Until the Pointer Processor State Machine Reaches the NORM State The path remote defect indicator (RDI-P) communicates receiver-path defects to the upstream (transmitting) device or MegaCore function. After a reset, the RDI-P for that path does not get updated until the pointer processor state machine reaches the NORM state. However, once the pointer processor for that path reaches the NORM state, the RDI-P for that path is continuously updated even if that path exits the NORM state, provided no reset is applied. All variations of the MegaCore function that incorporate the SSPROC are affected. The RDI-P does not get updated after a reset until the NORM state is achieved. The Detection of AIS-P or LOP-P Can Cause the Corresponding RDI-P Value to Be Inserted in the Wrong Paths The receiver generates the RDI-P value, a path specific indication, from the detection of an AIS-P or LOP-P condition and transmits that RDI-P value back to the upstream device. This RDI-P value may be erroneously inserted into more than one path, thus falsely indicating RDI-Ps in paths that do not have AIS-P or LOP-P conditions. 6 Altera Corporation

7 v2.3.0 Issues All channelized variations of the MegaCore function that incorporate the SSPROC are affected. An RDI-P value may be inserted into paths that do not have AIS-P or LOP-P conditions. The RDI-L Value Inserted Into the Transmit Frame Keeps a Constant Value The receiver generates the RDI-L value, a path specific indication, and transmits that RDI-L value back to the upstream device by automatically inserting the value into the transmit frames. However, an error in the MegaCore function causes the inserted RDI-L value to keep its value if all of the bits in the TXT_PRC_AUTO_RDIL_CTRL register are disabled. The kept value is the RDI-L code before all bits in the TXT_PRC_AUTO_RDIL_CTRL register were cleared. All variations of the MegaCore function that incorporate the SSPROC are affected. The RDI-L value may retain an undesired RDI-L code. Enable any bit in the TXT_PRC_AUTO_RDIL_CTRL register. Altera Corporation 7

8 The RDI-P Value Inserted Into the Transmit Frame Keeps a Constant Value The receiver generates the RDI-P value, a path specific indication, and transmits that RDI-P value back to the upstream device by automatically inserting specific RDI-P codes into the transmit frames. However, an error in the MegaCore function causes the RDI-P code to keep its value if all of the AUTO_LOP_RDIP, AUTO_TIMP_RDIP, or AUTO_LCDP_RDIP bits of the TXP_PRC_AUTO_RDIP_CTRL1, TXP_PRC_AUTO_RDIP_CTRL2, or TXP_PRC_AUTO_RDIP_CTRL3 registers, respectively, are disabled. The RDIP-P keeps a constant value until one of those bits is set again. All variations of the MegaCore function that incorporate the SSPROC are affected. The RDI-P value may retain an undesired RDI-P code, and may render the DEFAULT_RDIP_CODE ineffective. Enable any of the AUTO_LOP_RDIP, AUTO_TIMP_RDIP, or AUTO_LCDP_RDIP bits of the TXP_PRC_AUTO_RDIP_CTRL1, TXP_PRC_AUTO_RDIP_CTRL2, or TXP_PRC_AUTO_RDIP_CTRL3 registers, respectively. Path Overhead Processing Is Unreliable for Certain OC-48 Variations The SONET/SDH receiver processor (SSRX_PROC) and the SONET/SDH transmitter processor (SSTX_PROC) process and generate path overhead information. Most of this processing consists of tracking specific bytes in successive frames for each path, checking for consistency, and comparing to expected values. All OC-48 variations of the MegaCore function that are channelized to STS-1 or STS-3C are affected. 8 Altera Corporation

9 v2.3.0 Issues On the receiver side, the path overhead processing results are incorrect, causing a number of path-related interrupts to be asserted. On the transmitter side, the path overhead bytes that are inserted into the outgoing stream may be incorrect. The Bit Error Rate Monitor Does Not Perform as Specified The bit error rate monitor identifies signal degrade and signal fail conditions. The SONET/SDH Compiler User Guide specifies that each bit error rate monitor uses a sliding window protocol in which the sliding window size is decomposed into eight sub-windows. The size of the sub-windows is defined by the contents of the following registers: RXT_PRC_SD_SET_SUB_WIN, RXT_PRC_SD_CLR_SUB_WIN, RXT_PRC_SF_SET_SUB_WIN, and RXT_PRC_SF_CLR_SUB_WIN. However, the algorithm implemented in the MegaCore function differs from the documentation because it uses a sliding window consisting of seven sub-windows, the size of which correspond to the contents of the registers plus 1. All variations of the MegaCore function that incorporate the SSPROC are affected. The bit error rate monitor reports signal degrade and signal fail conditions based on an algorithm that is not consistent with the documentation. Altera Corporation 9

10 The Midbus Interface mtxerr Signal Does Not Behave as Defined The mtxerr signal can be used to alter some of the data transmitted on the line side. However, because of an error in the MegaCore function, the mtxerr signal does not always behave as specified, leading to unexpected data in the transmit data. All OC-48 and OC-192 variations of the MegaCore function that have a path signal greater than STS-3C. Asserting the mtxerr signal does not always produce the expected results, which can be problematic because the mtxerr signal can be used to insert errors on a variety of overhead bytes. The Stratix GX Transceiver Requires a Specific altgxb Megafunction Reset Sequence The Stratix GX Transceiver User Guide states that a specific reset sequence should be followed to reset the altgxb megafunction. This sequence is not implemented in the SONET/SDH MegaCore function. All variations of the MegaCore function that use the altgxb megafunction are affected. The SONET/SDH MegaCore function does not comply with the recommended Stratix GX transceiver reset sequence. However, no problems have been encountered. 10 Altera Corporation

11 v2.3.0 Issues The Default Value for Memory-Based Registers Should Be Set to X Many of the registers defined in the MegaCore function's register map are memory based, not flop based. The memories cannot be reset, and are not initialized to any value when the MegaCore function is reset. Altera recommends that you write to the memory-based registers required by your design to initialize their content and ensure predictable behavior. All variations of the MegaCore function are affected. A MegaCore function reset does not clear the contents of the memory-based registers. Two workarounds are possible: Write the content of all memory-based registers required by your design to ensure that they contain the desired value. or Reprogram the FPGA. This initializes all memories to zero. To help you identify the memory-based registers so you can implement the workaround, the default values of the memory-based registers have been changed to 'hx in v2.3.1 of the SONET/SDH Compiler User Guide. These default values have also been changed in the source code for the HTML register files generated by IP Toolbench during the MegaCore function generation. Altera Corporation 11

12 Incomplete Conditions in Table 3-3 of the User Guide In Table 3-3: STS Signal Label Mismatch Defect Conditions, on page 3-23 of the SONET/SDH Compiler User Guide, there is no condition covering when the expected functionality is 'h00 and the received payload label is not 'h00. These conditions have been added to v2.3.1 of the SONET/SDH Compiler User Guide. Contact Information Revision History For more information, go to Altera s mysupport website at and click Create New Service Request. Choose the Product Related Request form. Table 1 shows the revision history. Table 1. Revision History Version Date Details of Change 1.0 January 2005 First release of the SONET/SDH Compiler errata sheet for v Innovation Drive San Jose, CA (408) Applications Hotline: (800) 800-EPLD Literature Services: lit_req@altera.com Copyright 2005 Altera Corporation. All rights reserved. Altera, The Programmable Solutions Company, the stylized Altera logo, specific device designations, and all other words and logos that are identified as trademarks and/or service marks are, unless noted otherwise, the trademarks and service marks of Altera Corporation in the U.S. and other countries. All other product or service names are the property of their respective holders. Altera products are protected under numerous U.S. and foreign patents and pending applications, maskwork rights, and copyrights. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly agreed to in writing by Altera Corporation. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. 12 Altera Corporation