28478-ERR-003-A_15 [TE]
MUSYCC Non-Conformance;
| 型号： | 28478-ERR-003-A_15 |
| 厂家： | 
TE CONNECTIVITY |
| 描述： | MUSYCC Non-Conformance |
| 文件： | 总3页 (文件大小：53K) |
| 中文： | 中文翻译 | 下载： | 下载PDF数据表文档文件 |
500391A
July 15, 2002
CN8478/74A/72A/71A—Rev. C.
Errata: MUSYCC Non-Conformance
Product Affected:
MUSYCC CN8478/74A/72A/71A devices—Rev. C
Non-Conformance Information
This information specifies the known anomalies and non-conformance to stated information
for the MUSYCC CN8478/74A/72A/71A devices.
The revision C is designated by Revision ID = 0Ch in CN8478 PCI Configuration Space—
Function 0 and Function 1.
1. Jump Service Request
Description:
MUSYCC cannot process a jump service request from a host-owned, no-poll message
descriptor. What is meant by the word “from” is as follows. During message descriptor
processing, if MUSYCC encounters a host-owned descriptor, MUSYCC stops processing that
message descriptor and proceeds to check other groups for a message descriptor that it has
permission to process. If polling is set, MUSYCC returns to that same message descriptor to
see if it has permission to process that message descriptor. The message descriptor where
MUSYCC stops, due to host ownership, is the “from” message descriptor. This message
descriptor is a sentinel, or a placeholder, to which MUSYCC must always return. If polling is
disabled—by setting the No Poll (NP) bit to 1 in the message descriptor—MUSYCC will not
check that message descriptor again until the host requests it to do so through a jump service
request. When a jump service request is issued, MUSYCC is supposed to jump to the message
descriptor that is pointed by the transmit head pointer. However, MUSYCC first returns to the
“from” message descriptor to confirm buffer ownership. If the “from” buffer is MUSYCC-
owned, then MUSYCC returns to process the transmit head pointer, and the subsequent
message descriptors, correctly completing the jump service request. If the “from” buffer
remains host-owned when MUSYCC returns to it after a jump service request, then correct
completion of the jump service request only occurs for the first few jump service requests after
device initialization. After about three jump service requests (which remain pointing to host-
owned buffers), MUSYCC stops responding to subsequent jump service requests and that
channel must be reactivated to continue normal channel processing. During this failure
condition, MUSYCC starts to poll the sentinel message descriptor (for the specific channel that
requested jump service), even if the message descriptor is configured for No Poll (NP bit = 1).
Mindspeed Technologies™
Mindspeed Proprietary and Confidential
1
CN8478/74A/72A/71A—Rev. C.
Errata
Recommended Actions:
Before issuing a jump service request, the host must change the ownership of the sentinel
message descriptor to MUSYCC-owned. Then, the host can issue a jump service request. The
root cause for the jump service request failure as described above is that MUSYCC checks the
ownership of the message descriptor where it last stops, or the sentinel message descriptor,
upon a jump service request. If ownership of the sentinel message descriptor is host-owned,
MUSYCC suspends further processing of message descriptors for that channel.
2. Receive Out-Of-Frame Misreporting
Description:
This errata concerns the misreporting of Receive-Out-Of-Frame (ROOF) interrupts by
MUSYCC when it is in 4xE1 mode. In this setup, four T1/E1 framers (Bt8370) are connected
to the same serial bus. The 32 time slots out of the total possible of 128 time slots available on
the serial bus are allocated to framer # 1 every 4th time slot, starting with time slot 0. The 32
time slots for framer # 2 start on time slot 1, and continue every 4th time slot. The 32 time slots
for framer # 3 start on time slot 2, and continue every 4th time slot. The 32 time slots for
framer # 4 start on time slot 3, and continue every 4th time slot. For example, the 32 time slot
of framer # 1 for an E1 rate are mapped to time slots 0, 4, 8, 12, …, and 124. When a framer
detects a ROOF event, it generates a ROOF signal toward MUSYCC. The ROOF signal, active
high, appears on the PCM time slots allocated to it. For example, for framer 1, ROOF signal
assertions appear in time slots 0, 4, 8, 12, …, and 124. Upon detection of ROOF assertion,
MUSYCC is supposed to report back to the host which channel has a ROOF. However,
MUSYCC reports the incorrect channel number. ROOF assertion by framer 1 is reported by
MUSYCC as coming from the prior time slot, for example time slot 127 instead of time slot 0,
on the channel assigned to framer 3 through PCM time slot map. A ROOF assertion by framer
2 is reported by MUSYCC as coming from framer 1, instead of framer 2, on all or part of the
channels assigned to framer 1. A ROOF assertion by framer 3 is reported by MUSYCC as
coming from framer 2 instead of framer 3, on all or part of the channels assigned to framer 2.
A ROOF assertion by framer 4 is reported by MUSYCC as coming from framer 3 instead of
framer 4, on all or part of the channels assigned to framer 3. Often, MUSYCC reports ROOF
on both the correct channels assigned to the framer as well as on incorrect channels assigned to
another framer’s time slots.
Recommended Actions:
None. MUSYCC’s ROOF input signal cannot operate in a multiplexed environment, where
more than one framer (or physical layer device) attaches to the ROOF input. Therefore, only
ROOF operation wherein all time slots of the serial port are connected to a single physical
layer device is supported.
Alternatively, a software fix is available, depending on the kind of framers being used. It is
possible to check the Out-of-Frame (OOF) status on the framer, then when a ROOF condition
is reported by the framer, the host programs the framer to insert all 1s (abort code) onto the
receive data output for all time slots associated with that framer. This software workaround
forces MUSYCC to abort channel processing on any channel mapped to a framer during an
OOF condition.
2
Mindspeed Technologies™
Mindspeed Proprietary and Confidential
500391A
CN8478/74A/72A/71A—Rev. C.
Errata
3. Flywheel Mechanism [SFALIGN = 0] Does Not Function Properly in the Receive
Direction
Description:
The flywheel mechanism in MUSYCC [SFALIGN = 0, bit field 15, value = 0; page 5-16,
Table 5-10 (100660E)] in T1 mode for the receive direction does not function properly and
results in reception of corrupted data. It does work in the transmit direction or E1 mode.
Recommended Actions:
Make certain that RSYNC is supplied to the receive port for proper operation if the serial port
is configured for T1.
4. Soft Group Reset May Not Function Properly
Description:
If MUSYCC is polling a large number of channels without any messages being transmitted or
received, a Soft Group Reset may result in other active channels in other groups of the device
to be deactivated. This condition is very unlikely because the likelihood of no messages being
present in either direction on a large number of channels is very minimal.
Recommended Actions:
Do not issue an SGR (Soft Channel Group Reset); instead, issue a Service Request Channel
Deactivation for selected channels/direction within a group.
500391A
Mindspeed Technologies™
Mindspeed Proprietary and Confidential
3
相关型号：
28478FAZ
Dual and Quad Micropower Single Supply Rail-to-Rail Input and Output (RRIO) Op-Amp
INTERSIL
©2020 ICPDF网 联系我们和版权申明