The following revision history lists the anomaly list revisions and major changes for each anomaly list revision.

Transcription

1 a SHARC Processor 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 "-." 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# * b#0000 * - See anomaly 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 01/30/2012 G 0 Added anomaly /20/2011 F 0 Modified anomaly , Added anomaly /26/2010 E PrA Added anomaly /20/2010 D PrA Modified anomaly /30/2010 C PrA Added anomaly , 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. NR004008G 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.Bo 9106, Norwood, MA U.S.A. Tel: Fa: Analog Devices, Inc. All rights reserved.

2 ADSP-21483/21486/21487/21488/21489 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 Incorrect Popping of stacks possible when eiting IRQ/Timer Interrupts with DB modifier IOP Register access immediately following an Eternal Memory access may not work Effect latency of some System Registers may be 2 cycles instead of 1 for Eternal data accesses Writes to LCNTR, CURLCNTR and LADDR from Internal Memory may fail if there is a DMA block conflict Incorrect value when the results of Enhanced Modify/BITREV Instruction are used in the very net Instruction Latency with eternal FLAG-based Conditional instructions involving DAG register post-modify operation Special PLL Initialization Sequence required if MediaLB interface is used in DMA-driven transfer mode When PM accesses are used, some Instructions may get corrupted under specific conditions Incorrect Silicon revision number in REVPID register SPORT DMA may not work as epected, when SPORTs from the same DMA group access both the eternal memory and internal memory for data and/or TCB and other peripheral DMAs (including SPORT DMAs in other groups) are also enabled in parallel PLL Programming may not take effect under specific conditions After an emulator halt at the instruction before idle' instruction, the Core Timer stops decrementing even after code eecution restarts A three column data access over DM bus immediately following an indirect delayed branch (db) may not work as epected in VISA mode Key: = anomaly eists in revision. = Not applicable NR004008G Page 2 of 18 January 2012

3 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 Incorrect Popping of stacks possible when eiting IRQ/Timer Interrupts with DB modifier: If a delayed branch modifier (DB) is used to return from the interrupt service routines of any of IRQ (hardware) or timer interrupts, the automatic popping of ASTAT/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 IRQ 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 eternal memory eecution. Do not use (DB) modifiers in instructions eiting 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 IOP Register access immediately following an Eternal Memory access may not work: If an instruction making an access to an IOP register immediately follows another instruction that performs an access to eternal memory, the IOP register access may not occur correctly. Separate the two instructions by inserting another instruction in between them, such as a NOP. NR004008G Page 3 of 18 January 2012

4 ADSP-21483/21486/21487/21488/ Effect latency of some System Registers may be 2 cycles instead of 1 for Eternal data accesses: The following registers that have an effect latency of 1 (the maimum 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 eternal data access: MODE1, MODE2, MMASK, SYSCTL, BRKCTL, ASTAT, ASTATy, STKY, and STKYy. For eample, consider the following sequence of instructions: bit set MODE1 BR8; //Sufficient if not immediately followed by eternal memory access instruction //Etra NOP needed if following instruction accesses eternal memory pm(i8,m12)=f9; //i8 is pointing to an address in eternal memory Registers other than the ones listed above are not affected by this anomaly. Note that the anomaly is independent of whether the instruction itself resides in internal or eternal memory. Rather, the anomaly is encountered if there are eternal memory data accesses within the two instructions immediately following the register modification. If any of the above registers with an effect latency of 1 is modified, it is recommended that no accesses involving eternal 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 Writes to LCNTR, CURLCNTR and LADDR from Internal Memory may fail if there is a DMA block conflict: 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 eample, 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. Also note that the anomaly also occurs if (i0+m0) points to a memory-mapped I/O register. 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; NR004008G Page 4 of 18 January 2012

5 ADSP-21483/21486/21487/21488/ Incorrect value when the results of Enhanced Modify/BITREV Instruction are used in the very net Instruction: 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 that this anomaly is only applicable in the case where Ia and Ib are unique and different. The user must avoid the above eact 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 Latency with eternal FLAG-based Conditional instructions involving DAG register postmodify operation: Eternal FLAG-based Conditional instructions involving DAG register post-modify operation must not be followed immediately by an instruction that uses the same inde register. For eample, 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 inde register in INSTR2 will either be Ia or (Ia+Mb) depending on whether INSTR1 was aborted or eecuted. In the unique case where COND is an eternal FLAG condition (for eample, say FLAG2_IN) which is set asynchronously by an eternal source or event, the necessary internal stalls which would result in the DAG inde register getting the correct value do not take effect, and consequently the value of the DAG inde register in INSTR2 may not contain the correct and epected value. Separate the instructions in the above sequence by at least two NOPs. NR004008G Page 5 of 18 January 2012

6 ADSP-21483/21486/21487/21488/ Special PLL Initialization Sequence required if MediaLB interface is used in DMA-driven transfer mode: 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. 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: bit clr ustat1 PLLBP; ustat4 = dm(pmctl1); bit clr ustat4 MLBOFF; dm(pmctl1) = ustat4; Ensure that the above instruction sequence is eecuted from within internal memory, is not interrupted, and that there is no background DMA activity. Note that 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 epected to operate only with core-driven data transfers. NR004008G Page 6 of 18 January 2012

7 ADSP-21483/21486/21487/21488/ When PM accesses are used, some Instructions may get corrupted under specific conditions: 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 eternal 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 epected. 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. Eample1: lcntr=, do (pc,1) until lce; // > 4 dm(i0,m0)=r10, pm(i12,m10)=r10; //PM access meets one of the conditions described Eample2: lcntr=, do (pc,1) until lce; // > 4 R10 = pm(i12,m10); //PM access meets one of the conditions described Eample3: 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 epected. 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. Eample1: pm(i12,m10)= <imm_data>; //PM access 1, <imm_data> - can be 16-bit/32-bit immediate value compressed or uncompressed dm(i0,m0)=r10, pm(i12,m10)=r10; //PM access 2 compressed, meets one of the conditions described Instruction(s) following this sequence may get corrupted. Eample2: pm(i12,m10)= <imm_data>; //PM access 1, <imm_data> - can be 16-bit/32-bit immediate value R10 = pm(i12,m10); //PM access 2, meets one of the conditions described Instruction(s) following this sequence may get corrupted. Note that this anomaly is seen especially at low operating temperatures, but it is not limited to any particular operating temperature range. Applicable for CASE 1: NR004008G Page 7 of 18 January 2012

8 ADSP-21483/21486/21487/21488/ 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; lcntr=, do (pc,1) until lce; // > 4 dm(i0,m0)=r10, pm(i12,m10)=r10; // PM access meets one of the conditions described BIT CLR MODE2 CADIS; Note that 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>; //PM access 1, <imm_data> - can be 16-bit/32-bit //immediate value.nocompress; //Disable compression dm(i0,m0)=r10, pm(i12,m10)=r10; //PM access 2, meets one of the condition described.compress; //Enable compression 4. Replace the pm access with the dm access. 5. Disable the cache for the problematic PM accesses. BIT SET MODE2 CADIS; pm(i12,m10)= <imm_data>; //PM access 1, <imm_data> - can be 16-bit/32-bit //immediate value dm(i0,m0)=r10, pm(i12,m10)=r10; //PM access 2, DM access points to the same //memory block resulting in a block conflict BIT CLR MODE2 CADIS; 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. 0.1 NR004008G Page 8 of 18 January 2012

9 ADSP-21483/21486/21487/21488/ Incorrect Silicon revision number in REVPID register: The REVPID register bits 4-7 do not contain the correct silicon revision information. None SPORT DMA may not work as epected, when SPORTs from the same DMA group access both the eternal memory and internal memory for data and/or TCB and other peripheral DMAs (including SPORT DMAs in other groups) are also enabled in parallel: The SPORT DMA channels for the SHARC processors are arranged in 4 groups as follows: a. Group 1 : DMA channels for the SPORTs 0 and 1 (SP0A,SP0B, SP1A and SP1B) b. Group 2 : DMA channels for the SPORTs 2 and 3 (SP2A,SP2B, SP3A and SP3B) c. Group 3 : DMA channels for the SPORTs 4 and 5 (SP4A,SP4B, SP5A and SP5B) d. Group 4 : DMA channels for the SPORTs 6 and 7 (SP6A,SP6B, SP7A and SP7B) The SPORT DMA may not work as epected, when the SPORTs from the same group are enabled in DMA mode with read/write transactions to both internal and eternal 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. 1. For normal DMA mode, place all the SPORT DMA buffers belong to the same group either in internal memory or in eternal 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 eternal memory, but not on both. NR004008G Page 9 of 18 January 2012

10 ADSP-21483/21486/21487/21488/ PLL Programming may not take effect under specific conditions: The PLL programming in software may not work as epected 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 eample 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 eternally). Since the offending internal alignment is not visible eternally, 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 eternally), 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-2146 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 eternal port accesses (AMI/SD/DDR2DRAM). ii. Some of the peripherals (e.g. SPORT, UART etc.) may run at an unepected 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 bit clr ustat1 PLLM63; bit set ustat1 PLLM16 PLLBP; lcntr=4096, do delay1 until lce; delay1: //Clear the PLLBP bit to come out of the bypass mode bit clr ustat1 PLLBP; lcntr=16, do delay2 until lce; delay2: //Change the SDCKR ratio from 4 to only applicable for the second case bit clr ustat1 SDCKR3_5 SDCKR4; NR004008G Page 10 of 18 January 2012

11 ADSP-21483/21486/21487/21488/21489 bit set ustat1 SDCKR2_5 DIVEN; 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 (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 epected value i.e. 400 MHz and consequently the SDCLK may also be changed to the epected value (160 MHz). 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 register- If 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 register- clear 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 register- clear the PLLBP bit. PLL comes out of the bypass mode. 6. Wait for at least 16 CCLK cycles. 7. 4th write to the PMCTL register- set 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 register- clear the PLLBP bit. PLL comes out of the bypass mode. 10. Wait for at least 16 CCLK cycles th write to the PMCTL register-set the new PLLD, SDCKR/DDR2CKR, and LPCKR (only for 2146) 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. The 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. The steps 3 to 6 take care of the issue 1 by setting INDIV and bringing down the VCO frequency below fvcoma/2 (please refer to the corresponding data sheet for the fvco epression and the fvcoma specification). This implies that: a. These steps are not needed if the VCO is already running at a speed less than fvcoma/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 fvcoma/ 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 fvcoma/2 if the INDIV bit is set. If the VCO speed more than or equal to fvcoma/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). NR004008G Page 11 of 18 January 2012

12 ADSP-21483/21486/21487/21488/ The steps 7 to 10 is the normal PLL programming sequence to program the new PLLM and (or) INDIV values. 4. The 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 (2146 only) change is required. Eample assembly code sequence: #include <def21489.h> // for ADSP-2148 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 bit clr USTAT1 PLLD16 ; bit set USTAT1 PLLD8 DIVEN ; #else //If!(the final/ required values of PLLD=4 and SDCKR/DDR2CKR=4) bit clr USTAT1 PLLD16 ; bit set USTAT1 PLLD4 DIVEN ; #endif //Step 2 lcntr=16, do first_div_delay until lce; first_div_delay: //Step 3 bit clr ustat1 DIVEN; bit set ustat1 INDIV PLLBP; //Step 4 lcntr=4096, do first_bypass_delay until lce; first_bypass_delay: //Step 5 bit clr ustat1 PLLBP; //Step 6 lcntr=16, do second_div_delay until lce; second_div_delay: //Step 7 bit clr ustat1 INDIV PLLM63; //Set the new values of PLLM and INDIV here: PLLM18, INDIV=0 in this eample bit set ustat1 PLLM18 PLLBP; //Step 8 lcntr=4096, do second_bypass_delay until lce; second_bypass_delay: //Step 9 bit clr ustat1 PLLBP; NR004008G Page 12 of 18 January 2012

13 ADSP-21483/21486/21487/21488/21489 //Step 10 lcntr=16, do third_div_delay until lce; third_div_delay: //Step 11 //01C0000 is mask for the SDCKR bit field bit clr ustat1 PLLD16 01C0000; //Set the new values of PLLD and SDCKR here: bit set ustat1 SDCKR2 PLLD2 DIVEN; //Step 12 lcntr=16, do fourth_div_delay until lce; fourth_div_delay: Eample C Code sequence: #include <def21489.h> // for ADSP-2148 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 eample temp = (PLLM18 PLLBP); *ppmctl = temp; NR004008G Page 13 of 18 January 2012

14 ADSP-21483/21486/21487/21488/21489 //Step 8 for(i=0;i<4096;i++); //Step 9 temp = *ppmctl; temp&=~pllbp; *ppmctl=temp; //Step 10 for(i=0;i<16;i++); //Step 11 temp=*ppmctl; //01C0000 is mask for the SDCKR bit field temp&=~(plld16 01C0000 ); //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 register- set 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 register- set 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. Eample assembly code sequence: #include <def21489.h> // for ADSP-2148 processors //Step 1 bit clr USTAT1 PLLD16 ; //Eample: set PLLD8 if the original value is PLLD4 bit set USTAT1 PLLD8 DIVEN ; //Step 2 lcntr=16, do div_delay1 until lce; div_delay1: //Step 3 //01C0000 is mask for the SDCKR bitfield bit clr USTAT1 PLLD16 01C0000 ; //Eample: set the original value (PLLD4) back and set SDCKR4 bit set USTAT1 PLLD4 DIVEN SDCKR4 ; //Step 4 lcntr=16, do div_delay2 until lce; div_delay2: Eample C code sequence: #include <def21489.h> // for ADSP-2148 processors #include <cdef21489.h> NR004008G Page 14 of 18 January 2012

15 ADSP-21483/21486/21487/21488/21489 int temp, i; //Step 1 temp=*ppmctl; temp&=~plld16 ; //Eample: 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; //01C0000 is mask for the SDCKR bitfield temp&=~(plld16 01C0000 ); //Eample: 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-2147: It is possible that while eecuting 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 eecution of the workaround code as long as the VCO speed is not less than 150MHz. However, after the eecution 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 NR004008G Page 15 of 18 January 2012

16 ADSP-21483/21486/21487/21488/ After an emulator halt at the instruction before idle' instruction, the Core Timer stops decrementing even after code eecution restarts: When the processor is halted at a breakpoint in an emulator session, the core timer correctly stops decrementing and restarts when code eecution 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 eecution is resumed. In the eample code below, the core timer remains halted after code eecution is resumed following the core halt at Instruction1. The same behavior is seen if Instruction1 is eecuted 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. None NR004008G Page 16 of 18 January 2012

17 ADSP-21483/21486/21487/21488/ A three column data access over DM bus immediately following an indirect delayed branch (db) may not work as epected in VISA mode: A three column data access (e.g. 40 bit etended precision access or a 48 bit PX registers access) over DM bus may not work as epected 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 eternal memory data accesses. Following are few eample 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 IMDW 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 Scenario 2: 48 bit data access using PX register - The following code may show the failure irrespective of whether the corresponding IMDW bit is set or not: call(m8,i8) (db); //Indirect delayed branch instruction dm(i1,m1)=p; //This 48 bit write access may fail 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 IMDW 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)" 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 eamples) and the address of the three column data access. 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 eample, 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 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 eecute 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 5. Use NON-VISA mode for such data accesses. 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. NR004008G Page 17 of 18 January 2012

18 ADSP-21483/21486/21487/21488/ Analog Devices, Inc. All rights reserved. Trademarks and registered trademarks are the property of their respective owners. a w w w. a n a l o g. c o m NR004008G Page 18 of 18 January 2012