a
SHARC Processor
Silicon Anomaly List
ADSP-21467/21469
ABOUT ADSP-21467/21469 SILICON ANOMALIES
These anomalies represent the currently known differences between revisions of the SHARC®ADSP-21467/21469 product(s) and the
functionality specified in the ADSP-21467/21469 data sheet(s) and the Hardware Reference book(s).
SILICON REVISIONS
A silicon revision number with the form "-x.x" is branded on all parts (see the data sheet for information on reading part branding). The
silicon revision can also be electronically read by reading the REVPID register either via JTAG or DSP code.
The following DSP code can be used to read the register:
UREG = dm(REVPID);
Silicon REVISION
REVPID[7:4]
0.2
b#0001
0.0
b#0000
ANOMALY LIST REVISION HISTORY
The following revision history lists the anomaly list revisions and major changes for each anomaly list revision.
Date
Anomaly List Revision
Data Sheet Revision
Additions and Changes
03/05/2014
K
Rev B
Added Anomaly: 15000029,15000031.
05/17/2013
J
Rev B
Added Anomaly: 15000028. Modified anomaly: 15000014.
07/20/2012
I
Rev A
Added anomaly: 15000024.
02/14/2012
H
Rev A
Added anomaly: 15000023. Modified anomaly 15000022.
01/09/2012
G
Rev 0
Added Silicon Revision 0.2.
11/28/2011
F
Rev 0
Modified anomaly: 15000020.
04/18/2011
E
Rev 0
Added anomalies: 15000021,15000022.
09/29/2010
D
Rev 0
Added anomalies: 15000018,15000020.
03/11/2010
C
PrF
Added anomaly: 15000016.
11/03/2009
B
PrD
Added anomalies: 15000010, 15000011, 15000012, 15000013,
15000014, and 15000015.
03/01/2009
A
PrC
Initial release
SHARC and the SHARC logo are registered trademarks of Analog Devices, Inc.
NR003870K
Information furnished by Analog Devices is believed to be accurate and reliable.
However, no responsibility is assumed by Analog Devices for its use, nor for any
infringements of patents or other rights of third parties that may result from its use.
Specifications subject to change without notice. No license is granted by implication or
otherwise under any patent or patent rights of Analog Devices. Trademarks and
registered trademarks are the property of their respective owners.
One Technology Way, P.O.Box 9106, Norwood, MA 02062-9106 U.S.A.
Tel: 781.329.4700
www.analog.com
Fax: 781.461.3113
©2014 Analog Devices, Inc. All rights reserved.
Silicon Anomaly List
ADSP-21467/21469
SUMMARY OF SILICON ANOMALIES
The following table provides a summary of ADSP-21467/21469 anomalies and the applicable silicon revision(s) for each anomaly.
No.
ID
Description
0.0
0.2
1
15000002
Incorrect Popping of stacks possible when exiting IRQx/Timer Interrupts with DB modifier
x
x
2
3
15000003
IOP Register access immediately following an External Memory access may not work
x
x
15000004
Effect latency of some System Registers may be 2 cycles instead of 1 for External data accesses
x
x
4
15000005
Writes to LCNTR, CURLCNTR and LADDR from Internal Memory may fail if there is a DMA block conflict
x
.
5
15000006
Specific Core Stall may not execute as expected
x
x
6
15000007
Frame Sync Edge Detection (FSED) feature in SPORT TDM mode does not work
x
.
7
15000010
Incorrect value when the results of Enhanced Modify/BITREV Instruction are used in the very next
Instruction
x
x
8
15000011
Incorrect Execution of CALL(DB) Instructions in VISA operation, under specific conditions
x
.
9
15000012
Latency with external FLAG-based Conditional instructions involving DAG register post-modify
operation
x
x
10
15000013
Input leakage current drawn by MediaLB pins may be higher than expected
x
.
11
15000014
Special PLL Initialization Sequence required if MediaLB interface is used in DMA-driven transfer mode
x
x
12
15000015
Data error when reading large (>4096 words) block of data over DDR2 interface
x
.
13
15000016
When PM accesses are used, some Instructions may get corrupted under specific conditions
x
.
14
15000018
SPORT DMA may not work as expected, when SPORTs from the same DMA group access both the
external memory and internal memory for data and/or TCB and other peripheral DMAs (including SPORT
DMAs in other groups) are also enabled in parallel
x
x
15
15000020
PLL Programming may not take effect under specific conditions
x
x
16
15000021
After an emulator halt at the instruction before ‘idle' instruction, the Core Timer stops decrementing
even after code execution restarts
x
x
17
15000022
Corruption of Link Port Receiver Data
x
.
18
15000023
A three column data access over DM bus immediately following an indirect delayed branch (db) may not
work as expected in VISA mode
x
x
19
15000024
Execution of the instructions in VISA space from internal memory may execute corrupted instructions
when either of the two most recent write operations has updated the locations holding these
instructions or the neighboring locations
x
x
20
15000028
Internal Memory write gets incorrect value in presence of external memory access in Type-1 instruction
under certain conditions
x
x
21
15000029
UART stop bit width smaller than expected for UART divisor values of 3 or greater
x
x
22
15000031
Read access and Write access Breakpoint do not function reliably for external memory data address
ranges
x
x
Key: x = anomaly exists in revision
. = Not applicable
NR003870K | Page 2 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
DETAILED LIST OF SILICON ANOMALIES
The following list details all known silicon anomalies for the ADSP-21467/21469 including a description, workaround, and identification
of applicable silicon revisions.
1. 15000002 - Incorrect Popping of stacks possible when exiting IRQx/Timer Interrupts with DB modifier:
DESCRIPTION:
If a delayed branch modifier (DB) is used to return from the interrupt service routines of any of IRQx (hardware) or timer interrupts, the
automatic popping of ASTATx/ASTATy/MODE1 registers from the status stack may not work correctly.
The specific instructions affected by this anomaly are "RTI(DB);" and "JUMP(CI)(DB);".
This anomaly affects only IRQx and Timer Interrupts as these are the only interrupts that cause the sequencer to push an entry onto the
status stack. This anomaly applies to both internal and external memory execution.
WORKAROUND:
Do not use (DB) modifiers in instructions exiting IRQ or Timer ISRs. Instructions in the delay slot should be moved to a location prior to the
branch.
Note: This workaround may be built into the development tool chain and/or into the operating system source code. For tool chains and
Operating Systems supported by ADI, such as VisualDSP++ and VDK please consult the "Silicon Anomaly Tools Support" help page in the
applicable documentation and release notes for details.
APPLIES TO REVISION(S):
0.0, 0.2
2. 15000003 - IOP Register access immediately following an External Memory access may not work:
DESCRIPTION:
If an instruction making an access to an IOP register immediately follows another instruction that performs an access to external memory,
the IOP register access may not occur correctly.
WORKAROUND:
Separate the two instructions by inserting another instruction in between them, such as a NOP.
APPLIES TO REVISION(S):
0.0, 0.2
NR003870K | Page 3 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
3. 15000004 - Effect latency of some System Registers may be 2 cycles instead of 1 for External data accesses:
DESCRIPTION:
The following registers that have an effect latency of 1 (the maximum number of instructions it takes for a write to these registers to take
effect) will instead have an effect latency of 2 if any of their bits impact an instruction containing an external data access:
MODE1, MODE2, MMASK, SYSCTL, BRKCTL, ASTATx, ASTATy, STKYx, and STKYy.
For example, consider the following sequence of instructions:
bit set MODE1 BR8;
nop;
//Sufficient if not immediately followed by external memory access instruction
nop;
//Extra NOP needed if following instruction accesses external memory
pm(i8,m12)=f9; //i8 is pointing to an address in external memory
Registers other than the ones listed above are not affected by this anomaly.
Note: This anomaly is independent of whether the instruction itself resides in internal or external memory. Rather, the anomaly is
encountered if there are external memory data accesses within the two instructions immediately following the register modification.
WORKAROUND:
If any of the above registers with an effect latency of 1 is modified, it is recommended that no accesses involving external memory (over
either PM or DM bus) are performed in the two instructions immediately following the register modification. It is recommended to insert
two NOPs after such register modifications.
APPLIES TO REVISION(S):
0.0, 0.2
4. 15000005 - Writes to LCNTR, CURLCNTR and LADDR from Internal Memory may fail if there is a DMA block
conflict:
DESCRIPTION:
Writes to LCNTR, CURLCNTR and LADDR from internal memory (either as a DM access or as a PM access) may fail when a DMA transfer to/
from the same block occurs in the same cycle.
For example, consider the following instruction:
CURLCNTR = dm(i0,m0);
Now consider any DMA access involving the same memory block as pointed to by address (i0+m0). If the DMA and the above write
align in such a way that DMA transfer happens in the same cycle as the above instruction, then the above write will fail.
Note: This anomaly also occurs if (i0+m0) points to a memory-mapped I/O register.
WORKAROUND:
1. Change the DMA to source/target a different internal memory block thereby avoiding any DMA block conflict.
2. Instead of loading these registers directly from memory, they can be loaded indirectly as a 2-step process as shown below:
r0 = dm(i0,m0);
CURLCNTR = r0;
APPLIES TO REVISION(S):
0.0
NR003870K | Page 4 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
5. 15000006 - Specific Core Stall may not execute as expected:
DESCRIPTION:
Under certain specific conditions outlined below, one type of core stall that is normally incurred does not get executed. In certain cases
this can cause incorrect code operation.
When PCSTK is loaded, and an RTS/RTI is executed immediately afterward, there is a stall as the return waits for a writeback of PCSTK
before the return.
Example1:
[1] PCSTK = dm(i0,m1);
[2] RTS;
Example2:
[1] PCSTK = dm(i0,m1);
[2] RTI;
If: The memory access in instruction 1 is to a memory-mapped IOP register.
-ORDMA is simultaneously accessing the same bank as the memory access in instruction 1.
Then: Stall does not occur, and this results in the RTS/RTI vectoring to some undefined location instead of the value from PCSTK.
WORKAROUND:
Add a nop between instructions 1 and 2.
Note: This workaround may be built into the development tool chain and/or into the operating system source code. For tool chains and
Operating Systems supported by ADI, such as VisualDSP++ and VDK please consult the "Silicon Anomaly Tools Support" help page in the
applicable documentation and release notes for details.
APPLIES TO REVISION(S):
0.0, 0.2
6. 15000007 - Frame Sync Edge Detection (FSED) feature in SPORT TDM mode does not work:
DESCRIPTION:
The newly defined Frame Sync Edge Detection (FSED) feature in SPORT TDM mode does not work. This feature was introduced to ensure
that when a SPORT is operating in TDM mode with external clock and frame sync, it waits for an active edge of the external frame sync
signal before initiating SPORT RX/TX transfers, regardless of whether it was enabled during the time of the frame sync signal being at an
active level.
WORKAROUND:
Do not set the FSED bit (bit 2 within the SPCTLNn register). This will ensure that the SPORT functions identically as on prior products.
APPLIES TO REVISION(S):
0.0
NR003870K | Page 5 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
7. 15000010 - Incorrect value when the results of Enhanced Modify/BITREV Instruction are used in the very
next Instruction:
DESCRIPTION:
In the following specific sequence of instructions, the memory or the register load in INSTR3 will not contain the correct updated value
of the DAG register Ia from INSTR2, but rather its value from INSTR1:
INSTR1: Ia = <immediate load | register load | memory load>;
INSTR2: Ia = MODIFY|BITREV (Ib, Mc);
INSTR3: <memory load | register load> = Ia;
Note: This anomaly is only applicable in the case where Ia and Ib are unique and different.
WORKAROUND:
The user must avoid the above exact sequence of instructions which might produce an incorrect result.
Note: This workaround may be built into the development tool chain and/or into the operating system source code. For tool chains and
Operating Systems supported by ADI, such as VisualDSP++ and VDK please consult the "Silicon Anomaly Tools Support" help page in the
applicable documentation and release notes for details.
APPLIES TO REVISION(S):
0.0, 0.2
8. 15000011 - Incorrect Execution of CALL(DB) Instructions in VISA operation, under specific conditions:
DESCRIPTION:
Direct and indirect CALL(DB) instructions might not be executed correctly if all of the following specific conditions are true:
1. The CALL(DB) instruction being executed belong to the Variable-Instruction-Size Architecture instruction set (i.e., VISA instructions).
2. An interrupt occurs simultaneously such that it causes the CALL(DB) instruction to be aborted.
3. A DMA block conflict causes a core pipeline stall to occur in the immediate cycle following step 2.
If all of the above conditions are true, the CALL(DB) instruction is never executed, and consequently the function call is missed. Upon
returning from the interrupt, program execution resumes from the instruction immediately following the CALL(DB) instruction.
Note1: A DMA block conflict occurs if instructions and DMA data buffers are stored in the same internal memory block. The DMA activity
itself could either be a peripheral or external port DMA, or a DMA engine associated with one of the dedicated hardware accelerators.
Note2: This anomaly only affects conditional and unconditional CALL(DB) instructions in VISA and does NOT apply to traditional (i.e., nonVISA) CALL(DB) instructions. The anomaly also does NOT apply to any other VISA branch instructions (such as delayed/non-delayed
CJUMP and JUMP instructions) or to non-delayed CALL instructions.
WORKAROUND:
The anomaly can be avoided if any one of the following workarounds is followed:
1. Ensure that there is no DMA block conflict. In other words, DMA data buffers must be placed in a different internal memory block than the
block(s) containing instructions.
2. Avoid the use of CALL(DB) instructions in VISA functions.
3. When building an executable, modules or functions containing CALL(DB) instructions are built using traditional instruction set and not
VISA instruction set.
APPLIES TO REVISION(S):
0.0
NR003870K | Page 6 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
9. 15000012 - Latency with external FLAG-based Conditional instructions involving DAG register postmodify operation:
DESCRIPTION:
External FLAG-based Conditional instructions involving DAG register post-modify operation must not be followed immediately by an
instruction that uses the same index register.
For example, in the following instruction sequence shown below:
INSTR1: IF COND dm(Ia,Mb); //any instruction that involves post-modify operation
INSTR2: dm(Ia,Mc); //any instruction that depends on updated Ia value
The value of the DAG index register in INSTR2 will either be Ia or (Ia+Mb) depending on whether INSTR1 was aborted or executed.
In the unique case where COND is an external FLAG condition (for example, say FLAG2_IN) which is set asynchronously by an external
source or event, the necessary internal stalls which would result in the DAG index register getting the correct value do not take effect, and
consequently the value of the DAG index register in INSTR2 may not contain the correct and expected value.
WORKAROUND:
Separate the instructions in the above sequence by at least two NOPs.
APPLIES TO REVISION(S):
0.0, 0.2
10. 15000013 - Input leakage current drawn by MediaLB pins may be higher than expected:
DESCRIPTION:
The maximum specified input leakage current for MediaLB interface in 3-pin mode is around 1uA. However, in the MediaLB interface
present on ADSP-21462W, ADSP-21465W, and ADSP-21469W, this value may be significantly higher under worst-case conditions (for
example, around 116uA). This will not damage any other devices on the MediaLB bus or limit the number of devices that can share the
bus.
WORKAROUND:
Remove (or omit) the external 47Kohm pulldown resistor that are usually present on the board. The purpose of this resistor is to ensure
that the signals are driven low when none of the devices on the bus is actively driving the bus, and is no longer needed as our processor's
MediaLB pins have internal pulldowns of their own.
Note: The effect of not having this external pull-down resistor on the bus may have an influence on the Bus Hold Times of a signal.
Therefore, customers are advised to measure their bus hold timing and ensure that they do not violate the values specified in the
datasheet.
APPLIES TO REVISION(S):
0.0
NR003870K | Page 7 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
11. 15000014 - Special PLL Initialization Sequence required if MediaLB interface is used in DMA-driven
transfer mode:
DESCRIPTION:
The MediaLB interface's DMA clock may lose synchronization with the processor's internal clock if the procesor's PLL is placed in bypass
mode as part of the initial initialization sequence.
WORKAROUND:
Use the following instruction sequence while initializing the PLL if using MediaLB interface in DMA-driven transfer mode:
1. Disable clock to the MediaLB interface.
ustat4 = dm(PMCTL1);
bit set ustat4 MLBOFF;
R2=dm(MLB_VCCR); // any "dummy" read of an IOP register outside of the core to force
// clock synchronization between core and peripheral clock domains
dm(PMCTL1) = ustat4;
2. Place PLL in bypass mode.
3. Proceed with programming PLL parameters as per default guidelines. Provide sufficient delay in order for the changes to take effect,
again as per default guidelines.
4. Bring PLL out of bypass mode and re-enable the clock to the MediaLB interface:
ustat1 = dm(PMCTL);
bit clr ustat1 PLLBP;
ustat4 = dm(PMCTL1);
bit clr ustat4 MLBOFF;
dm(PMCTL) = ustat1;
dm(PMCTL1) = ustat4;
Ensure that the above instruction sequence is executed from within internal memory, is not interrupted, and that there is no background
DMA activity.
Note1: The above procedure does not need to be followed if the MediaLB interface is not used in a system, or if the MediaLB interface is
expected to operate only with core-driven data transfers.
Note2: For programming the PLL parameters, the work-around as mentioned in Anomaly ID 15000020 should be followed.
APPLIES TO REVISION(S):
0.0, 0.2
12. 15000015 - Data error when reading large (>4096 words) block of data over DDR2 interface:
DESCRIPTION:
If there are more than 4096 uninterrupted continuous sequential reads from external DDR2 memory (they may be either core-driven
accesses or DMA), there will be a data error observed at the 4097th memory location of the destination buffer, in the form of a replicated
data word (the same word as was read into the 4096th location).
WORKAROUND:
Implementing any one of the following workarounds will avoid the problem:
1. Limit the size of uninterrupted reads from external DDR2 memory to less than or equal to 4096 32-bit words.
2. Disable DDR2 read optimization. But note that doing so will affect performance.
APPLIES TO REVISION(S):
0.0
NR003870K | Page 8 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
13. 15000016 - When PM accesses are used, some Instructions may get corrupted under specific conditions:
DESCRIPTION:
When specific PM accesses are used, either the PM instruction or some Instructions which follow this instruction may get corrupted. The
problem is seen when the PM accesses has any of the below conditions:
1. Conflicts with another core/DMA access to the same memory block
2. Accesses any of the memory mapped(IOP) registers
3. Accesses the external memory space
CASE 1 (applicable for both VISA and NON-VISA mode):
The single instruction loop which has the PM access instruction described above as part of the instruction in the loop, may not work as
expected. The PM instruction in the loop while being fetched from the cache may get corrupted. This is applicable for both counter based
and non-counter based loops. For counter based loops the corruption occurs only if the count value is greater than four.
Example1:
lcntr=x, do (pc,1) until lce;
dm(I0,M0)=R10, pm(I12,M10)=R10;
// x > 4
//PM access meets one of the conditions described
Example2:
lcntr=x, do (pc,1) until lce;
R10 = pm(I12,M10);
// x > 4
//PM access meets one of the conditions described
Example3:
do (pc,1) until forever;
R10 = pm(I12,M10);
//PM access meets one of the conditions described
CASE 2 (applicable only for VISA mode):
A code sequence which includes two successive PM instructions and the second PM access instruction is compressed and meets one of
the conditions described above, may not work as expected. The instruction(s) following the second PM access (while getting fetched
from the cache) may get corrupted. The particular instruction(s) which get corrupted is dependent on the size of the instructions
following the above sequence and their alignment in the Instruction Alignment Buffer (IAB). This anomaly is not applicable for the pm
sequence which is formed by the first and last instruction of a hardware loop containing pm accesses.
Example1:
pm(I12,M10)= <imm_data>;
dm(I0,M0)=R10, pm(I12,M10)=R10;
//PM access 1, <imm_data> - can be 16-bit/32-bit
//immediate value compressed or uncompressed
//PM access 2 compressed, meets one of the conditions
//described
...
...
Instruction(s) following this sequence may get corrupted.
Example2:
pm(I12,M10)= <imm_data>;
R10 = pm(I12,M10);
//PM access 1, <imm_data> - can be 16-bit/32-bit
//immediate value
//PM access 2, meets one of the conditions
//described
...
...
Instruction(s) following this sequence may get corrupted.
Note: This anomaly is seen especially at low operating temperatures, but it is not limited to any particular operating temperature range.
WORKAROUND:
Applicable for CASE 1:
NR003870K | Page 9 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
1. Avoid memory block conflict stalls for these scenarios by moving either the core/DMA access or the PM access to different memory block.
2. Avoid single instruction loops having program memory access by unrolling the loop. This can be done by one of the following ways:
a. Replicating the instruction and correspondingly reducing the loop count
b. Adding another instruction or NOP instruction to the loop
c. Breaking the instruction which contains pm access into two separate instructions.
3. Disable the cache for the problematic PM accesses.
BIT SET MODE2 CADIS;
nop;
nop;
lcntr=x, do (pc,1) until lce;
dm(I0,M0)=R10, pm(I12,M10)=R10;
BIT CLR MODE2 CADIS;
nop;
nop;
// x > 4
// PM access meets one of the conditions described
Note: Disabling the cache may affect the performance of the hardware loop. The PM instruction in the loop will always stall and the loop
will take double the time than the cache enabled case.
Applicable only for CASE 2:
1. Avoid memory block conflict stalls for these scenarios by moving either the core/DMA access or the PM access to different memory block.
2. Add a "nop" or a non-PM access instruction between the two problematic PM accesses.
3. All sequences of PM accesses with length more than 1 should remain uncompressed from second instruction onwards. This can be done
by using the assembler directive ".NOCOMPRESS".
pm(I12,M10)= <imm_data>;
.NOCOMPRESS;
dm(I0,M0)=R10, pm(I12,M10)=R10;
.COMPRESS;
//PM access 1, <imm_data> - can be 16-bit/32-bit
//immediate value
//Disable compression
//PM access 2, meets one of the condition described
//Enable compression
4. Replace the pm access with the dm access.
5. Disable the cache for the problematic PM accesses.
BIT SET MODE2 CADIS;
nop;
nop;
pm(I12,M10)= <imm_data>;
dm(I0,M0)=R10, pm(I12,M10)=R10;
//PM access 1, <imm_data> - can be 16-bit/32-bit
//immediate value
//PM access 2, DM access points to the same
//memory block resulting in a block conflict
BIT CLR MODE2 CADIS;
nop;
nop;
Note: Some of these workarounds may be built into the development tool chain and/or into the operating system source code. For tool
chains and Operating Systems supported by ADI, such as VisualDSP++ and VDK please consult the "Silicon Anomaly Tools Support" help
page in the applicable documentation and release notes for details.
APPLIES TO REVISION(S):
0.0
NR003870K | Page 10 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
14. 15000018 - SPORT DMA may not work as expected, when SPORTs from the same DMA group access both
the external memory and internal memory for data and/or TCB and other peripheral DMAs
(including SPORT DMAs in other groups) are also enabled in parallel:
DESCRIPTION:
The SPORT DMA channels for the SHARC processors are arranged in 4 groups as follows:
a.
b.
c.
d.
Group 1 : DMA channels for the SPORTs 0 and 1 (SP0A,SP0B, SP1A and SP1B)
Group 2 : DMA channels for the SPORTs 2 and 3 (SP2A,SP2B, SP3A and SP3B)
Group 3 : DMA channels for the SPORTs 4 and 5 (SP4A,SP4B, SP5A and SP5B)
Group 4 : DMA channels for the SPORTs 6 and 7 (SP6A,SP6B, SP7A and SP7B)
The SPORT DMA may not work as expected, when the SPORTs from the same group are enabled in DMA mode with read/write
transactions to both internal and external memory and another DMA also enabled in parallel. This problem is applicable for both the
normal DMA mode and DMA chaining mode of SPORT DMAs.
When the problem occurs, the data read from the memory may not be correct for the SPORT transmit DMA. For the chaining DMA
operations, additionally the TCB may also not be loaded correctly. For the receive DMA case, the data written to the memory will be
correct but the latency between two successive writes will increase.
WORKAROUND:
1. For normal DMA mode, place all the SPORT DMA buffers belong to the same group either in internal memory or in external memory,but
not on both.
2. For DMA chaining mode, place both the SPORT TCBs and SPORT DMA buffers belong to the same group, either in internal memory or in
the external memory, but not on both.
APPLIES TO REVISION(S):
0.0, 0.2
NR003870K | Page 11 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
15. 15000020 - PLL Programming may not take effect under specific conditions:
DESCRIPTION:
The PLL programming in software may not work as expected under specific conditions of temperature, frequency, and operating voltage.
This can be because of one or both of the following issues:
1. The PLL may not get programmed to the new multiplier (PLLM) value in software. The reason for the failure is that the new PLL multiplier
value configured using the PLLM bits is not updated correctly and the PLL continues to use the previous multiplier value only. The
symptom of this issue will be that the PLL will continue to work at the old frequency (regardless of the new value programmed). This
issue is however not seen for the cases where any portion of the PLL divider circuitry alone is re-programmed (such as for example
INDIV, PLLD, LPCKR, or SDCKR/DDR2CKR ratios).
2. The PLL may fail to enter the bypass mode because of either of the following two possible reasons:
a. If setting of the PLLBP bit coincides with certain specific alignment of internal clocks (not visible externally). Since the offending
internal alignment is not visible externally, though a code may not show this failure, it is still recommended to use the
workaround mentioned below. It should also be noted that though adding/ removing few instructions (e.g. "nop" instructions)
before the instruction which sets the PLLBP bit may either avoid or cause the failure, it shouldn't be used as a workaround.
b. If the CCLK: SDCLK/DDR2CLK (SDCKR/DDR2CKR) ratio is programmed to 4:1 and it coincides with a specific alignment of internal
clocks(not visible externally), some internal clocks may lose mutual synchronization. This synchronization is necessary for the
PLL to enter into the bypass mode. Thus, if this change is followed by a code which sets the PLLBP bit, the PLL may fail to enter
into the bypass mode. Like in the issue (a), in this issue as well, though adding/removing few instructions before (e.g. "nop"
instructions) the instruction which performs the SDCKR/DDR2CKR ratio change may avoid or cause the failure, it shouldn't be
used as a workaround.
This issue is not applicable for cases where the PLLD, and (or) the LPCKR(ADSP-2146x only) clock ratios are alone reprogrammed, or if
the SDCKR/DDR2CKR ratio is programmed to ratios other than 4:1, without any modifications to the PLLM and the INDIV bits.
The following are some of the symptoms of this issue:
i. The synchronization between SDCLK/DDR2CLK and peripheral clock (PCLK)may be lost as a result of which the core might hang when
trying to perform core external port accesses (AMI/SD/DDR2DRAM).
ii. Some of the peripherals (e.g. SPORT, UART etc.) may run at an unexpected frequency after the PLL programming.
iii. Entering into the bypass mode is important for the PLLM/INDIV change to take effect. Thus, another symptom of this issue is that the new
PLLM and (or)INDIV values may not take effect. But if the failed bypass entry is followed by a SDCKR/DDR2CKR or PLLD change to a
new value, the new PLLM and (or) INDIV may erroneously take effect. However, it should be noted that this phenomenon is not
guaranteed and should not be used as a workaround.To understand this better, let us consider a scenario where at a particular
point,CLKIN=25 MHz, PLLM = 8, SDCKR=4, INDIV=0, and PLLD=2, which gives fCCLK=200MHz. Let us assume a case where it is only
required to reprogram the PLL to a new PLLM value (say 16) to get CCLK speed of 400 MHz.While in another case, in addition to the
PLLM change to 16, it is also required to change the SDCKR ratio to 2.5 to get SDCLK speed of 160 MHz. Assume that the following
code is used for both the cases where the SDCKR change step is not applicable for the first case.
//Set the new value of PLLM (16) and set the PLLBP bit to enter the bypass mode
ustat1 = dm(PMCTL);
bit clr ustat1
PLLM63;
bit set ustat1 PLLM16 | PLLBP;
dm(PMCTL) = ustat1;
lcntr=4096, do delay1 until lce;
delay1:nop;
//Clear the PLLBP bit to come out of the bypass mode
ustat1 = dm(PMCTL);
bit clr ustat1 PLLBP;
dm(PMCTL) = ustat1;
lcntr=16, do delay2 until lce;
delay2:nop;
//Change the SDCKR ratio from 4 to 2.5 - only applicable for the second case
ustat1 = dm(PMCTL);
bit clr ustat1 SDCKR3_5 | SDCKR4;
bit set ustat1 SDCKR2_5 | DIVEN;
dm(PMCTL) = ustat1;
In this scenario, if the PLL fails to enter into the bypass mode because of any of the above two mentioned issues, the new PLLM value
NR003870K | Page 12 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
(16) will not take effect and the CCLK may still continue to run at 200 MHz even after the PLLBP bit is cleared. For the first case, the
CCLK will always remain at 200 MHz as there was no SDCKR/PLLD change. However, for the second case, the CCLK will be 200 MHz
before performing the SDCKR change to 2.5. But, after the SDCKR change, the new value of PLLM (16) may erroneously take effect
and the CCLK speed may change to the expected value i.e. 400 MHz and consequently the SDCLK may also be changed to the
expected value (160 MHz).
WORKAROUND:
CASE 1 - issue 1 and 2(a)
To take care of the issues 1 and 2 (a), the following sequence should be used to re-program the PLL in software when PLLM and/or INDIV
change is required:
1. 1st write to the PMCTL registerIf SDCKR/DDR2CKR change is also needed and the final/required values of both PLLD and SDCKR are 4:
Set the PLLD to 8, set the DIVEN bit, and do not change the PLLM value.
Else:
Set the PLLD to 4, set the DIVEN bit, and do not change the PLLM value.
2. Wait for at least 16 CCLK cycles.
3. 2nd write to the PMCTL registerClear the DIVEN bit, set the INDIV bit, and set the PLLBP bit. PLL goes into the bypass mode the first time.
4. Wait for at least 4096 CCLK cycles.
5. 3rd write to the PMCTL registerClear the PLLBP bit. PLL comes out of the bypass mode.
6. Wait for at least 16 CCLK cycles.
7 4th write to the PMCTL registerSet the new PLLM and INDIV values, clear the DIVEN bit, set the PLLBP bit. PLL goes into the bypass mode the second time.
8. Wait for at least 4096 CCLK cycles.
9. 5th write to the PMCTL registerClear the PLLBP bit. PLL comes out of the bypass mode.
10. Wait for at least 16 CCLK cycles.
11. 6th write to the PMCTL registerSet the new PLLD, SDCKR/DDR2CKR, and LPCKR (only for 2146x) values, and set the DIVEN bit.
12. Wait for at least 16 CCLK cycles.
The following important points should be noticed regarding the PLL programming sequence mentioned above:
1. Step 1 takes care of the issue 2(a) by changing the PLLD to 4 or 8 which avoids the occurrence of the offending internal clock alignment
condition while setting the PLLBP bit.
2. Steps 3-6 take care of issue 1 by setting INDIV and bringing down the VCO frequency below fVCOmax/2 (please refer to the
corresponding data sheet for the fVCO expression and the fVCOmax specification). This implies that:
a. These steps are not needed if the VCO is already running at a speed less than fVCOmax/2.
b. There is no workaround for the case where the PLL has to be re-programmed to a new PLLM value, the VCO is running above
fVCOmax/2, and the INDIV bit is already set. Since the reset value of the INDIV bit is zero, this restriction applies only to a case
where the PLL has to be reprogrammed more than once in software.In such a case, for all the PLL programming attempts other
than the last one, the VCO speed should always be less than fVCOmax/2 if the INDIV bit is set. If the VCO speed more than or
equal to fVCOmax/2 is required, use INDIV =0 with half of the PLLM value than the one which would have been used with
INDIV=1(it may however result in loss of fCCLK precision).
3. Steps 7-10 are the normal PLL programming sequence to program the new PLLM and/or INDIV values.
4. Steps 11 and 12 are required only if the required value of PLLD is different from the one programmed in step 1 and/or if SDCKR/DDR2CKR
and/or LPCKR (2146x only) change is required.
NR003870K | Page 13 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
Example assembly code sequence:
#include <def21469.h> // for ADSP-2146x processors
// #define PLLD4_SDCKR4
//Uncomment this line if the final/required values
//of PLLD=4 and SDCKR/DDR2CKR=4
//Step 1
#ifdef PLLD4_SDCKR4
//If the final/required values of PLLD=4 and SDCKR/DDR2CKR=4
ustat1 = dm(PMCTL);
bit clr USTAT1 PLLD16 ;
bit set USTAT1 PLLD8 | DIVEN ;
dm(PMCTL) = ustat1;
#else
//If !(the final/ required values of PLLD=4 and SDCKR/DDR2CKR=4)
ustat1 = dm(PMCTL);
bit clr USTAT1 PLLD16 ;
bit set USTAT1 PLLD4 | DIVEN ;
dm(PMCTL) = ustat1;
#endif
//Step 2
lcntr=16, do first_div_delay until lce;
first_div_delay: nop;
//Step 3
bit clr ustat1 DIVEN;
bit set ustat1 INDIV | PLLBP;
dm(PMCTL) = ustat1;
//Step 4
lcntr=4096, do first_bypass_delay until lce;
first_bypass_delay:nop;
//Step 5
ustat1 = dm(PMCTL);
bit clr ustat1 PLLBP;
dm(PMCTL) = ustat1;
//Step 6
lcntr=16, do second_div_delay until lce;
second_div_delay:nop;
//Step 7
ustat1 = dm(PMCTL);
bit clr ustat1 INDIV | PLLM63;
//Set the new values of PLLM and INDIV here: PLLM18, INDIV=0 in this example
bit set ustat1 PLLM18 | PLLBP;
dm(PMCTL) = ustat1;
//Step 8
lcntr=4096, do second_bypass_delay until lce;
second_bypass_delay:nop;
//Step 9
ustat1 = dm(PMCTL);
bit clr ustat1 PLLBP;
dm(PMCTL) = ustat1;
//Step 10
lcntr=16, do third_div_delay until lce;
third_div_delay:nop;
//Step 11
ustat1 = dm(PMCTL);
NR003870K | Page 14 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
//0x1C0000 is mask for the DDR2CKR bit field
bit clr ustat1 PLLD16 | 0x1C0000 | LPCKR4;
//Set the new values of PLLD, DDR2CKR, and LPCKR here:
bit set ustat1 DDR2CKR2 | LPCKR3 | PLLD2 | DIVEN;
dm(PMCTL) = ustat1;
//Step 12
lcntr=16, do fourth_div_delay until lce;
fourth_div_delay: nop;
Example C Code sequence:
#include <def21469.h>
#include <cdef21469.h>
// for ADSP-2146x processors
// #define PLLD4_SDCKR4
//Uncomment this line if the final/required values of
//PLLD=4 and SDCKR/DDR2CKR=4
int temp,i;
//Step 1
#ifdef PLLD4_SDCKR4
//If the final/required values of PLLD=4 and SDCKR/DDR2CKR=4
temp=*pPMCTL;
temp&=~PLLD16 ;
temp|=(PLLD8 | DIVEN) ;
*pPMCTL = temp;
#else
//If !( the final/required values of PLLD=4 and SDCKR/DDR2CKR=4)
temp=*pPMCTL;
temp&=~PLLD16 ;
temp|=(PLLD4 | DIVEN) ;
*pPMCTL = temp;
#endif
//Step 2
for(i=0;i<16;i++);
//Step 3
temp&=~DIVEN;
temp|=(INDIV | PLLBP);
*pPMCTL = temp;
//Step 4
for(i=0;i<4096;i++);
//Step 5
temp=*pPMCTL;
temp&=~PLLBP;
*pPMCTL = temp;
//Step 6
for(i=0;i<16;i++);
//Step 7
temp = *pPMCTL;
temp&=~ (INDIV | PLLM63);
//Set the new values of PLLM and INDIV here:
//PLLM18, INDIV=0 in this example
temp|= (PLLM18| PLLBP);
*pPMCTL = temp;
//Step 8
for(i=0;i<4096;i++);
//Step 9
temp = *pPMCTL;
temp&=~PLLBP;
NR003870K | Page 15 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
*pPMCTL=temp;
//Step 10
for(i=0;i<16;i++);
//Step 11
temp=*pPMCTL;
//0x1C0000 is mask for the DDR2CKR bit field
temp&=~(PLLD16 | 0x1C0000 | LPCKR4 );
//Set the new values of PLLD,DDR2CKR, and LPCKR here:
temp|= (DDR2CKR2 | LPCKR3 | PLLD2 | DIVEN);
*pPMCTL=temp;
//Step 12
for(i=0;i<16;i++);
CASE 2- issue 2(b)
To take care of the issue 2(b), the following sequence should be followed if SDCKR/DDR2CKR ratio change to 4 alone is required without
changing PLLM and INDIV values, and another PLLM and (or) INDIV change is required afterwards:
1. 1st write to the PMCTL registerSet the PLLD to a value different than the original one and set the DIVEN bit.
2. Wait for at least 16 CCLK cycles.
3. 2nd write to the PMCTL registerSet the PLLD to the original value back, set the SDCKR/DDR2CKR to 4, and set the DIVEN bit.
4. Wait for at least 16 CCLK cycles.
Example assembly code sequence:
#include <def21469.h> // for ADSP-2146x processors
//Step 1
ustat1 = dm(PMCTL);
bit clr USTAT1 PLLD16 ;
//Example: set PLLD8 if the original value is PLLD4
bit set USTAT1 PLLD8 | DIVEN ;
dm(PMCTL) = ustat1;
//Step 2
lcntr=16, do div_delay1 until lce;
div_delay1: nop;
//Step 3
ustat1 = dm(PMCTL);
//0x1C0000 is mask for the DDR2CKR bitfield
bit clr USTAT1 PLLD16|0x1C0000 ;
//Example: set the original value (PLLD4) back and set DDR2CKR4
bit set USTAT1 PLLD4 | DIVEN|DDR2CKR4 ;
dm(PMCTL) = ustat1;
//Step 4
lcntr=16, do div_delay2 until lce;
div_delay2: nop;
Example C code sequence:
#include <def21469.h> // for ADSP-2146x processors
#include <cdef21469.h>
int temp, i;
//Step 1
temp=*pPMCTL;
NR003870K | Page 16 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
temp&=~PLLD16 ;
//Example: set PLLD8 if the original value is PLLD4
temp|=(PLLD8 | DIVEN) ;
*pPMCTL = temp;
//Step 2
for(i=0;i<16;i++);
//Step 3
temp=*pPMCTL;
//0x1C0000 is mask for the DDR2CKR bitfield
temp&=~(PLLD16 | 0x1C0000 );
//Example: set the original value (PLLD4) back and set DDR2CKR4
temp|= (DDR2CKR4 | PLLD4 | DIVEN);
*pPMCTL=temp;
//Step 4
for(i=0;i<16;i++);
Note: The following points are applicable for all the above mentioned workaround codes:
1. Applicable only for ADSP-2147x: It is possible that while executing some of the steps of the workaround code, the VCO speed may go
below its minimum specified value in the datasheet. This is allowed only during the execution of the workaround code as long as the
VCO speed is not less than 150MHz. However, after the execution of the complete workaround, the VCO speed should adhere to the
limits specified in the datasheet.
2. Both assembly and C workaround codes can be used in the VISA/NON VISA mode.
3. Both assembly and C workaround codes can be used with/without interrupts enabled.
4. Optimization should be disabled for the C workaround codes. Various compiler pragmas can be used to selectively turn off the
optimization during the workaround codes. E.g. the code below turns off the compiler optimization before the workaround code and
turns it on (back to command line optimization settings) again afterward.
#pragma optimize_off
Put the workaround code here….
#pragma optimize_as_cmd_line
APPLIES TO REVISION(S):
0.0, 0.2
NR003870K | Page 17 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
16. 15000021 - After an emulator halt at the instruction before ‘idle' instruction, the Core Timer stops
decrementing even after code execution restarts:
DESCRIPTION:
When the processor is halted at a breakpoint in an emulator session, the core timer correctly stops decrementing and restarts when code
execution is resumed. However, if the emulator breakpoint is placed at an instruction just before an idle instruction, the core timer
remains halted even after the code execution is resumed.
In the example code below, the core timer remains halted after code execution is resumed following the core halt at Instruction1. The
same behavior is seen if Instruction1 is executed by ‘single stepping'.
Enable_Core_timer:
……
Bit set MODE1 TIMEN;
……
……
Instruction1;
Idle;
Instruction2;
Instruction3;
// Placing breakpoint here causes the anomaly
Note: This issue impacts only Emulator session debug.
WORKAROUND:
None
APPLIES TO REVISION(S):
0.0, 0.2
NR003870K | Page 18 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
17. 15000022 - Corruption of Link Port Receiver Data:
DESCRIPTION:
Under rare conditions, the asynchronous assertion (going high) of LACKx signal by the Link Port receiver (to resume a halted transfer from
the transmitter) may not be detected properly by the transmitter. As a result of this, the transmit data changes as expected but the Link
Port Clock stays high, thereby resulting in data corruption at the receiver end.
The symptoms of this anomaly are observed as the receiver missing the least significant byte (the first byte) at the reception of a particular
word. Consequently, the corruption will be propagated as a byte shift for the rest of the transfer.
The occurrence of this anomaly is observed to be independent of Link Port frequency as well as to the ratio of Core Clock to Link Port
Clock frequencies, although the probability of error over time will change based on different ratios.
The probability of error can be reduced by reducing the core frequency, and setting the ratio of core-to-link-port-clock divide ratio (LCLKR
bit field in the PMCTL register) to the slowest possible value of 1:4.
Error recovery from a data corruption can be achieved by implementing a simple re-transmit protocol in conjunction with the above
steps.The link port transmitter embeds a simple checksum as part of the transmitted data payload. This checksum is calculated by the link
port receiver and if the checksums don't match, the receiver requests the transmitter to re-transmit the previous data block (via a simple
communication protocol, such as a Flag).
WORKAROUND:
The anomaly can be avoided if the receiver does not de-assert (low) its LACKx signal during the course of the data transfer.
1. In the case where the link port receiver is an FPGA, this can be achieved by increasing the depth of the receiver FIFO sufficiently so that it
can completely accommodate all transmitted data without having to de-assert the LACKx signal.
2. In the case where the link port receiver is another ADSP-21469, the anomaly can be avoided by using the following link port protocol:
a. For DMA-based transfers, set up the DMA block transfer size to two 32-bit words. Disable the transmitter inside the "DMA external
transfer done interrupt". Use the LTRQ interrupt to wake up the link port transmitter again when LACKx goes high and re-enable
the transmitter inside the ISR to send the next two words, and so on.
b. For core-driven transfers, load the 2-deep TX FIFO with two 32-bit words. The link port transmitter will then poll for its LPBS bit and
disable the transmitter when the transfer is complete. Use the LTRQ interrupt to wake up the transmitter when LACKx goes high
and re-enable the transmitter inside the ISR to send the next two words, and so on.
Note: This anomaly has been fixed for revision 0.2 of silicon. However, in order to enable the fix in silicon, add the code below to the link
port initialization code, as shown in the example below. Note that LSYNC_EN bit is only available in revision 0.2 of silicon.
#define LSYNC_EN
(BIT_6)
r0 = LP_DMA_CHAIN_CONFIG | LTRAN| DMACH_IRPT_MSK | LSYNC_EN ;
dm(LCTL0) = r0;
APPLIES TO REVISION(S):
0.0
NR003870K | Page 19 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
18. 15000023 - A three column data access over DM bus immediately following an indirect delayed branch
(db) may not work as expected in VISA mode:
DESCRIPTION:
A three column data access (e.g. 40 bit extended precision access or a 48 bit PX registers access) over DM bus may not work as expected if
all the following conditions are met:
1. The code is running in VISA mode.
2. The access immediately follows an indirect* delayed branch instruction (e.g. call (db) or jump (db)).
The anomaly is applicable for both read and write as well as for both direct and indirect accesses. This is however not applicable for IOP
and external memory data accesses. Following are few example scenarios in which the anomaly may occur:
Scenario 1: 40 bit data access using RF registers - The following code may show the failure if the corresponding IMDWx bit is set to
enable 40 bit data access:
jump(m8,i8) (db); //Indirect delayed branch instruction
r0=dm(i1,m1);
//This 40 bit read access may fail
nop;
Scenario 2: 48 bit data access using PX register - The following code may show the failure irrespective of whether the corresponding
IMDWx bit is set or not:
call(m8,i8) (db); //Indirect delayed branch instruction
dm(i1,m1)=px;
//This 48 bit write access may fail
nop;
Scenario 3: 40 bit data access using "rframe" instruction - The "rframe" instruction (performed as "i7=i6, i6=dm(0,i6)") may fail as well
if the corresponding IMDWx bit in the SYSCTL register is set. It is noticeable that the "rframe" instruction is generated by the compiler for
C codes. It is not used for assembly codes generally.
jump(m8,i8) (db); //Indirect delayed branch instruction
rframe;
//The 40 bit read access "i6=dm(0,i6)"
nop;
may fail
The occurrence of the failure depends upon the relationship between target address of the indirect branch (e.g. i8+m8 in the above
examples) and the address of the three column data access.
* This anomaly is applicable only for the indirect branch instructions using DAG2 registers. PC relative branch instructions are not affected
by this anomaly.
WORKAROUND:
1. Do not perform such data access immediately after the indirect delayed branch instruction. If possible, move the access to the second slot
of the delayed branch. For example, putting the "rframe" instruction in the second slot of the delayed branch in the above
code(scenario 3) will avoid the failure:
jump(m8,i8) (db); //Indirect delayed branch instruction
nop;
rframe;
//The 40 bit read access "i6=dm(0,i6)"
moved to second slot
2. Use direct branch instead of indirect branch.
3. Use normal indirect branch instead of delayed indirect branch. This may however result in additional branch latency. Also, this
workaround may not be helpful if the delayed branch was being used to be able to execute the two instructions in the (db) slot
atomically.
4. Use PM bus instead of DM bus for such data accesses. This may however cost additional core clock cycle because of the PM bus conflict
with the instruction fetch. E.g. replacing the DM access by PM access (i1 replaced by i9) in the above code (scenario 1) will avoid the
failure:
jump(m8,i8) (db);
r0=pm(i9,m9); //DM replaced by PM, i1(DAG1) replaced by i9(DAG2) for PM access
nop;
5. Use NON-VISA mode for such data accesses.
NR003870K | Page 20 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
Note: Some of these workarounds may be built into the development tool chain and/or into the operating system source code. For tool
chains and Operating Systems supported by ADI, such as VisualDSP++ and VDK please consult the "Silicon Anomaly Tools Support" help
page in the applicable documentation and release notes for details.
APPLIES TO REVISION(S):
0.0, 0.2
NR003870K | Page 21 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
19. 15000024 - Execution of the instructions in VISA space from internal memory may execute corrupted
instructions when either of the two most recent write operations has updated the locations
holding these instructions or the neighboring locations:
DESCRIPTION:
When the internal memory is written to a location containing or neighboring to a VISA (Variable Instruction Set Architecture) instruction
and this write happens to be one of the two most recent internal memory writes, subsequent execution of such VISA instruction may fail.
The write to the neighboring location will affect only if this write involves either one or two of the 16 bit words after the VISA instruction.
Note that the offending write can be of any type (short word-16bit, normal word-32/40/48 bit, or long word-64 bit). Additionally, source
of write operation could be core-driven or DMA-driven.
It should be noted that this issue is applicable even for the case where the internal memory is initialized with VISA instructions for the first
time. For example, this issue may be encountered after boot loading the application after processor comes out of reset. It however may
not be seen with the default boot kernels as they initialize the interrupt vector table (IVT) locations at the end of the boot loading process.
Since the IVT code is always expected in non-VISA mode, the memory writes corresponding to the IVT initialization will make sure that
any previous writes to VISA memory space are flushed out from the FIFO.
There is a two-deep write FIFO at the interface of each of the internal memory blocks. Under normal circumstances, the operation of these
FIFOs is transparent to the users. Any write operation to a block of internal memory is first performed to the FIFO. The FIFO pushes the
write to the memory array eventually in the non-read cycles. In a non-read cycle the block is not accessed for read operation by either the
DMA or the core for instruction or data. Depending on availability of non-read cycles, last two writes to a block can stay in the FIFO for
indefinite time.
A read operation first looks for data in the FIFO of the relevant memory block. This is termed as "data forwarding" by the FIFO. If either the
respective FIFO is empty or address match fails, memory array is accessed for the data. Both the explicit data read performed in the user
code and the instruction fetch performed by the program sequencer go through this process.
However, "data forwarding" by the FIFO does not work correctly for fetch of VISA instructions, leading to corruption of the instruction.
VISA instructions are always fetched in packets of three short words irrespective of the actual size of the instructions that are executed.
Consequently a VISA instruction can be corrupted if the relevant fetched packet is fully or partially forwarded from the FIFO. Thus the
failure may be seen even when one or two neighboring short words are updated in recent writes (not necessarily the VISA instruction
itself).
The symptoms of this anomaly can be seen in variety of ways such as:
- Core might hang or the execution might go to a recoverable or non-recoverable unknown state.
- The affected instruction may not be executed as expected after the offending write.
For example, assume that the affected instruction is "r1=0xABCDEF12" whose opcode is "0x0F01ABCDEF12" and is stored at a short word
location starting at "0x124314". Suppose a short word write is performed to the location "0x124315" such that 0xABCD is changed to
0x0000 and the instruction changes to "0x0F010000EF12" i.e. "r1=0xEF12".
.section/sw seg_code_block0;
r0=0;
dm(0x124315)=r0; //Offending write instruction
r1=0xABCDEF12: //Affected instruction at address "0x124314"
This write makes the latest instruction content to be pushed to the FIFO. Now, because of the anomaly, the instruction might not be
fetched correctly as "0x0F010000EF12" and might still be fetched as "0x0F01ABCDEF12" which is the old value stored in the memory array
and the content of R1 may be seen as "0xABCDEF12" even after apparently executing the instruction "r1=0xEF12".
It has to be noted that in case of C code, there are few interrupt set-up functions such as interrupt(), interruptcb(), interruptf(), interrupts(),
interruptss() which use self-modifying code to configure interrupt registers. The internal memory writes involved in this self-modifying
code may trigger this anomaly as well.
Note: This issue is seen only with instructions in VISA space executing from internal memory. Execution of VISA instructions from external
memory is not affected by this anomaly.
WORKAROUND:
The only known workaround for this anomaly is to make sure that the VISA instruction and (or) the two 16 bit neighboring locations after
the VISA instruction are not forwarded by the write FIFO. This can be done in following different ways:
1. If a write has to be performed to the internal memory holding a valid VISA instruction or the two 16 bit neighboring locations after the
VISA, it should be followed by at least two writes to different memory locations in the same block of internal memory which do not
overlap with a VISA instruction or the two 16 bit neighboring locations after the VISA instruction. These writes can either be valid
NR003870K | Page 22 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
writes already present in the code or dummy writes. These two writes will push all the modified VISA instruction and(or) the
neighboring content to the memory array from the FIFO and thus the following fetch is guaranteed to get the instruction from the
array instead of the write FIFO. The above example code thus can be modified as mentioned below:
.section/sw seg_code_block0;
r0=0;
dm(0x124315)=r0; //Offending write instruction
dm(0x124300)=r0; //First Dummy write to a different "scratch" location
dm(0x124300)=r0; //Second Dummy write to a different "scratch" location
r1=0xABCDEF12: //Affected instruction at address "0x124314"
Sometimes, re-arranging the order of the writes may also be helpful to avoid this anomaly. For example, when booting the processor,
the issue can be avoided by making sure that at least two non-VISA instructions are initialized after VISA instructions. As explained
above, the default boot kernels already have the order of writes in this way and therefore this issue will not be seen with the default
boot kernel codes.
2. The content of the FIFO will automatically be pushed out of the FIFO and written to the corresponding memory location in the array as
soon as the corresponding memory block is free for at least two core clock cycles (not necessarily consecutive) before executing the
affected VISA instruction. This can be done by making sure that the corresponding memory block is not accessed by core, DMA, or
program sequencer for at least two core clock cycles. For example, the above example code can be modified as mentioned below:
.section/sw seg_code_block0;
r0=0;
dm(0x124315)=r0;
//Offending write instruction
call Dummy_block1_code; //Call dummy code from different block
r1=0xABCDEF12:
//Affected instruction at address "0x124314"
.section/sw seg_code_block1;
Dummy_block1_code: //Program sequencer executes dummy code from different block
nop; // The code before "rts;" must have at least two non-read instructions
nop; //to the offending block (block 0 in this example).
rts; //Return to the main code.
3. In case of C code, use the equivalent interrupt set-up functions that do not use self-modifying code such as interruptnsm(),
interruptcbnsm(), interruptfnsm(), interruptsnsm(), interruptssnsm().
Alternatively, copy the source file <<INSTALL_DIR>>Œxx\lib\src\libc_src\irptl.asm to the project and modify it so that there is a "nop"
immediately before 'modify_two_instrs'. In order to build the file, the following include path will need to be added to the assembly
options: <<INSTALL_DIR>>Œxx\lib\src\libc_src. The code snippet below shows the code with this workaround:
.GLOBAL modify_instr, modify_two_instrs;
nop; //This is the additional "nop" instruction
modify_two_instrs:
BIT SET IRPTL 0x00000000;
APPLIES TO REVISION(S):
0.0, 0.2
NR003870K | Page 23 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
20. 15000028 - Internal Memory write gets incorrect value in presence of external memory access in Type-1
instruction under certain conditions:
DESCRIPTION:
IF a Type 1a instruction (compute + dual data memory move) in which the compute operation is a multiplication is followed by a
conditional branch based on the result of the Type 1a multiplication and any of the following conditions are met:
1. The source register for an internal memory write is the same as the:
a. Result register of the compute
b. Result register of an external memory read
2. The source register for an internal memory write accessing long word space is the same as the:
a. Implicit/explicit result register of the compute instruction
b. Implicit/explicit result register of an external memory read
THEN the data value written to internal memory is the modified value of the source register. This anomaly applies regardless of whether
the condition in the second instruction is true or not. Note that the anomaly does NOT apply if the Type 1a instruction data operands are
both located in external or internal memory .
For this anomaly to occur, the Type 1a instruction can be any of the following fomats:
1.
2.
3.
4.
Rx = multiplier compute, internal memory write = Rx, external memory data access;
Multiplier compute, Rx = external memory data read, internal memory write = Rx;
Multiplier compute, Rx = ALU operation result, external memory data access, internal memory write = Rx;
Rx = multiplier compute, external memory data access, internal memory write to long word address space = Ry; where (Rx,Ry) are an
implicit/explicit register pair.
The following instructions are examples of these four formats of the Type 1a instruction in corresponding order to the above:
R8 = R1 * R2 (UUI), dm(Ix, Mx) = R8, R1 = pm(Iy,My); //
//
//
//
//
//
Where Ix points to internal memory
normal or short word address space
and Iy points to external memory.
In this case, the internal memory
will receive the result of the
multiplication.
R5 = R2 * R7 (UUI), R4 = dm(Iy,My), pm(Ix,Mx) = R4;
Where Ix points to internal memory
normal or short word address space
and Iy points to external memory.
In this case, the internal memory
will receive the data read from
external memory.
//
//
//
//
//
//
R5 = R2 * R7 (SSFR), R1 = R11 + R15, dm(Iy,My) = R4, PM(Ix,Mx) = R1;
// Where Ix points to internal memory
// normal or short word address space
// and Iy points to external memory.
// In this case, the internal memory
// receives the result of the register
// add.
R1 = R3 * R7 (SSFR), R2 = pm(Iy,My), dm(Iz,Mz) = R0; //
//
//
//
//
//
//
//
Where Iy points to external memory
and Iz points to internal memory
long word address space. In this
case, (R0,R1) are a register pair
modified by the multiplication
and the internal memory write
gets the result in R1 after the
multiplication.
NR003870K | Page 24 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
For this anomaly to occur, the Type 1a instruction must be followed by a multiplier conditional branch instruction. This instruction can be
any branch instruction (Jump, Call,RTS,RTI) with the condition based on multiplier status bits.
The following is an example of the conditional branch:
If not ms call label2;
Example which shows this behavior:
R8 = R1 * R2 (UUI), dm(Ix,Mx) = R8, R1 = pm(Iy,My);
If not ms call label2;
//
//
//
//
where Ix points to internal memory
and Iy points to external memory
internal memory gets updated with
the result of the multiplication
Failure is independent of :
1. Which data bus (DM,PM) is used for the internal/external memory access
2. Presence or absence of a PM bus conflict (cache hit or cache miss)
3. Whether the code runs in VISA or non-VISA mode
4. The source code is present in internal or external memory
5. Floating or Fixed point multifunction instructions are used.
WORKAROUND:
1. Place a "nop;" instruction between Instruction-1 and Instruction-2.
2. Do not use "multiplier conditional" branch immediately after Instruction-1.
APPLIES TO REVISION(S):
0.0, 0.2
21. 15000029 - UART stop bit width smaller than expected for UART divisor values of 3 or greater:
DESCRIPTION:
According to the EIA-404 standard specification, the UART stop bit width must be a minimun of 80% of full stop bit width. On SHARC
processors, for UART divisor values of 3 or greater, the stop bit width is 14 PCLK cycles smaller than the full stop bit width for both one
stop bit (UARTSTB = 0) and two stop bit (UARTSTB =1) settings. This causes the stop bit width to be less than the worst case standard
specification for certain UART divisor values.
For example, for any PCLK speed when one stop bit is configured, the following two divisor values cause the stop bit width to be less than
the worst case stop bit width specified.
1. UART0DLL = 3, Actual Stop bit width = 70.8% of the programmed bit width.
2. UART0DLL = 4, Actual Stop bit width = 78.125% of the programmed bit width.
Note: UART0DLH = 0 in the cases above.
WORKAROUND:
IF a shorter stop bit is an issue Then any one of the following workarounds can be used to increase the stop bit width:
1. Use two stop bit (UARTSTB =1) setting to ensure the stop bit width is greater than one bit.
2. Use UART divisor values of 1 and 2 or use higher UART divisor values to ensure the Stop bit width is close to hundred percent.
3. Use slow core driven mode transfers, as stop bit width will be larger if the data is not available to transfer between each of the core driven
transfers.
APPLIES TO REVISION(S):
0.0, 0.2
NR003870K | Page 25 of 26 | March 2014
Silicon Anomaly List
ADSP-21467/21469
22. 15000031 - Read access and Write access Breakpoint do not function reliably for external memory data
address ranges:
DESCRIPTION:
The Breakpoint set for external memory address does not work reliably for following condition:
Case1: Breakpoint is set for Write to address X.
a. If the DM/PM write to address X, is followed by any instruction without DM/PM write operation, then Write Breakpoint will not hit.
b. If the DM/PM write to address X, is followed by any instruction with DM/PM write operation to any address, then Write Breakpoint will hit.
Case2: Breakpoint is set for Read to address X.
a. If the DM/PM write to address X, is followed by any instruction without DM/PM write operation, then Read Breakpoint will hit. Here it is
not expected to hit.
b. If the DM/PM read to address X, is followed by any instruction with DM/PM write operation to any address, then Read Breakpoint will not
hit.
Note: Above ‘X' refers to external memory address.
This issue will not be seen if breakpoint address is in internal memory. Both DM and PM breakpoint on external memory address are
affected by this issue.
WORKAROUND:
Use the ‘Any Access' mode corresponding to ‘11' triggering mode for all external memory data address breakpoint.
APPLIES TO REVISION(S):
0.0, 0.2
©2014 Analog Devices, Inc. All rights reserved. Trademarks and
registered trademarks are the property of their respective owners.
a
NR003870K | Page 26 of 26 | March 2014
www.analog.com