a
SHARC Processor
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
ABOUT ADSP-21483/21486/21487/21488/21489 SILICON ANOMALIES
These anomalies represent the currently known differences between revisions of the SHARC®ADSP-21483/21486/21487/21488/21489
product(s) and the functionality specified in the ADSP-21483/21486/21487/21488/21489 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 and ROMID registers either via JTAG or DSP code.
The following DSP code can be used to read the register:
UREG = dm(REVPID);
UREG = dm(ROMID);
Silicon REVISION
REVPID[7:4]
ROMID[4:0]
Applicable Product
0.3
b#0010
b#00001
ADSP-21486/21487
0.2
b#0010
b#00000
ADSP-21483/21486/21487/21488/21489
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
B
Added anomaly 15000031
08/21/2013
J
B
Added anomaly 15000029 and 15000030
05/17/2013
I
B
Added anomaly 15000028, Modified Anomaly 15000014
07/09/2012
H
A
Added anomaly 15000024
01/30/2012
G
0
Added anomaly 15000023
09/20/2011
F
0
Modified anomaly 15000020, Added anomaly 15000021
10/26/2010
E
PrA
Added anomaly 15000020
07/20/2010
D
PrA
Modified anomaly 15000016
06/30/2010
C
PrA
Added anomaly 15000018, Included information about 0.2 silicon
03/17/2010
B
PrA
Title of the document is updated to reflect correct part numbers
02/24/2010
A
PrA
Initial release
SHARC and the SHARC logo are registered trademarks of Analog Devices, Inc.
NR004008K
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.
ADSP-21483/21486/21487/21488/21489
Silicon Anomaly List
SUMMARY OF SILICON ANOMALIES
The following table provides a summary of ADSP-21483/21486/21487/21488/21489 anomalies and the applicable silicon revision(s) for
each anomaly.
No.
ID
Description
0.2
0.3
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
x
5
15000010
Incorrect value when the results of Enhanced Modify/BITREV Instruction are used in the very next
Instruction
x
x
6
15000012
Latency with external FLAG-based Conditional instructions involving DAG register post-modify
operation
x
x
7
15000014
Special PLL Initialization Sequence required if MediaLB interface is used in DMA-driven transfer mode
x
x
8
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
9
15000020
PLL Programming may not take effect under specific conditions
x
x
10
15000021
After an emulator halt at the instruction before ‘idle' instruction, the Core Timer stops decrementing
even after code execution restarts
x
x
11
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
12
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
13
15000028
Internal Memory write gets incorrect value in presence of external memory access in Type-1 instruction
under certain conditions
x
x
14
15000029
UART stop bit width smaller than expected for UART divisor values of 3 or greater
x
x
15
15000030
Initial state of /WDTRSTO signal can be High or Low until WDT_CLKIN starts switching.
x
x
16
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
NR004008K | Page 2 of 21 | March 2014
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
DETAILED LIST OF SILICON ANOMALIES
The following list details all known silicon anomalies for the ADSP-21483/21486/21487/21488/21489 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.2, 0.3
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.2, 0.3
NR004008K | Page 3 of 21 | March 2014
ADSP-21483/21486/21487/21488/21489
Silicon Anomaly List
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.2, 0.3
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.2, 0.3
NR004008K | Page 4 of 21 | March 2014
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
5. 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.2, 0.3
6. 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.2, 0.3
NR004008K | Page 5 of 21 | March 2014
ADSP-21483/21486/21487/21488/21489
Silicon Anomaly List
7. 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.2, 0.3
NR004008K | Page 6 of 21 | March 2014
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
8. 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.2, 0.3
NR004008K | Page 7 of 21 | March 2014
ADSP-21483/21486/21487/21488/21489
Silicon Anomaly List
9. 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
NR004008K | Page 8 of 21 | March 2014
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
(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.
NR004008K | Page 9 of 21 | March 2014
ADSP-21483/21486/21487/21488/21489
Silicon Anomaly List
Example assembly code sequence:
#include <def21489.h> // for ADSP-2148x 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);
NR004008K | Page 10 of 21 | March 2014
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
//0x1C0000 is mask for the SDCKR bit field
bit clr ustat1 PLLD16|0x1C0000;
//Set the new values of PLLD and SDCKR here:
bit set ustat1 SDCKR2 | PLLD2 | DIVEN;
dm(PMCTL) = ustat1;
//Step 12
lcntr=16, do fourth_div_delay until lce;
fourth_div_delay: nop;
Example C Code sequence:
#include <def21489.h> // for ADSP-2148x processors
#include <cdef21489.h>
// #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;
NR004008K | Page 11 of 21 | March 2014
ADSP-21483/21486/21487/21488/21489
Silicon Anomaly List
*pPMCTL=temp;
//Step 10
for(i=0;i<16;i++);
//Step 11
temp=*pPMCTL;
//0x1C0000 is mask for the SDCKR bit field
temp&=~(PLLD16 | 0x1C0000 );
//Set the new values of PLLD and SDCKR here:
temp|= (SDCKR2 | 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 <def21489.h> // for ADSP-2148x 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 SDCKR bitfield
bit clr USTAT1 PLLD16|0x1C0000 ;
//Example: set the original value (PLLD4) back and set SDCKR4
bit set USTAT1 PLLD4 | DIVEN|SDCKR4 ;
dm(PMCTL) = ustat1;
//Step 4
lcntr=16, do div_delay2 until lce;
div_delay2: nop;
Example C code sequence:
#include <def21489.h> // for ADSP-2148x processors
#include <cdef21489.h>
int temp, i;
//Step 1
temp=*pPMCTL;
NR004008K | Page 12 of 21 | March 2014
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
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 SDCKR bitfield
temp&=~(PLLD16 | 0x1C0000 );
//Example: set the original value (PLLD4) back and set SDCKR4
temp|= (SDCKR4 | 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.2, 0.3
NR004008K | Page 13 of 21 | March 2014
ADSP-21483/21486/21487/21488/21489
Silicon Anomaly List
10. 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.2, 0.3
NR004008K | Page 14 of 21 | March 2014
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
11. 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.
NR004008K | Page 15 of 21 | March 2014
ADSP-21483/21486/21487/21488/21489
Silicon Anomaly List
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.2, 0.3
NR004008K | Page 16 of 21 | March 2014
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
12. 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
NR004008K | Page 17 of 21 | March 2014
ADSP-21483/21486/21487/21488/21489
Silicon Anomaly List
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.2, 0.3
NR004008K | Page 18 of 21 | March 2014
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
13. 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.
NR004008K | Page 19 of 21 | March 2014
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
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.2, 0.3
14. 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.2, 0.3
NR004008K | Page 20 of 21 | March 2014
Silicon Anomaly List
ADSP-21483/21486/21487/21488/21489
15. 15000030 - Initial state of /WDTRSTO signal can be High or Low until WDT_CLKIN starts switching.:
DESCRIPTION:
The /WDTRSTO signal should be in a known state when /RESETOUT signal is de-asserted. But the state of /WDTRSTO signal can be high or
low until WDT_CLKIN starts switching. There is a possibility that if the startup time of the WDT_CLKIN clock source is more, the
WDTCLK_IN signal may not be available by the time /RESETOUT of the chip gets de-asserted. Hence for some duration, the state of the /
WDTRSTO signal is not known even after the /RESETOUT of the chip is de-asserted.
In some parts where /WDTRSTO signal remains asserted even after the /RESETOUT signal goes high , if the /WDTRSTO signal is given to
any external device as an input, the external device will wrongly interpret the assertion of the /WDTRSTO signal as a watchdog timer
expiry. This may lead to unexpected behavior.
Hence the /WDTRSTO signal should be used only after the WDT_CLKIN starts switching.
WORKAROUND:
None
APPLIES TO REVISION(S):
0.2, 0.3
16. 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.2, 0.3
©2014 Analog Devices, Inc. All rights reserved. Trademarks and
registered trademarks are the property of their respective owners.
a
NR004008K | Page 21 of 21 | March 2014
www.analog.com