Silicon Anomaly Support for the Blackfin processor

An anomaly is normally defined as any occurrence or object that is strange, unusual, or unique. In the case of Blackfin processor - it means a discrepancy or deviation from the published documentation.

These anomalies represent the currently known issues between various revisions of the Blackfin processor and the functionality specified in the datasheet(s) or the Hardware Reference book(s). The authoritative source for which processor and version the anomaly affects are listed on the Analog Devices Web site - at the Blackfin Anomaly page.

Silicon anomalies can lead to erratic behaviors and consequently lead to instability in a hardware system. This document outlines all the silicon anomaly workarounds relevant to any open source software, targeting the Blackfin processors. Silicon anomalies that cannot be worked around in software are highlighted so that the developer can be aware of them and take appropriate action to prevent them from occurring at a system level.

While anomaly workarounds exist in the toolchain, U-Boot and in the Linux Kernel - they only will work, if you use them properly. For example, the peripheral anomalies have workarounds in them in the peripheral device drivers. It is up to you to ensure that you use the existing device drivers. If you go changing the device driver, or write your own - it is your responsibility to ensure that you implement one of the suggested anomaly workaround methods from the silicon anomaly sheet.

All workarounds which can affect Linux userspace code - are all fixed in the toolchain - so no changes to userspace applications or libraries source is needed.

These are managed in the toolchain repository, for each anomaly sheet that is on the Analog Devices Web site.

If you are using a revision not included on this list - it is not going to work with any of the open source tools or kernels - If you want to understand why - please review all the issues below this list.

Since looking up pdfs isn't the easiest way to manage a complex application, there are anomaly header files which include define to allow you to work around these issues dynamically in your code. These look like:

/* line 24 to 28 */
/* Multi-Issue Instruction with dsp32shiftimm in slot1 and P-reg Store in slot2 Not Supported */
#define ANOMALY_05000074 (1)
/* DMA_RUN Bit Is Not Valid after a Peripheral Receive Channel DMA Stops */
#define ANOMALY_05000119 (1)

or ones that depend on the silicon version:

/* line 62 to 64 */
/* False Protection Exceptions when Speculative Fetch Is Cancelled */
#define ANOMALY_05000189 (__SILICON_REVISION__ < 4)

Where __SILICON_REVISION__ is a compiler set directive, based on the flag which you passed to the -mcpu= command line option. This allows you to use these either as a C preprocessor (with ifdefs) or in normal C/C++ code like:

/* line 912 to 920 */
	if ((ANOMALY_05000273 || ANOMALY_05000274) && (cclk >> 1) < sclk)
		panic("ANOMALY 05000273 or 05000274: CCLK must be >= 2*SCLK");
 
#ifdef BF561_FAMILY
	if (ANOMALY_05000266) {
		bfin_read_IMDMA_D0_IRQ_STATUS();
		bfin_read_IMDMA_D1_IRQ_STATUS();
	}

An example of the -mcpu= command line would be:

rgetz@imhotep:~/blackfin/trunk/uClinux-dist> bfin-uclinux-gcc -mcpu=bf537-0.2 -g -O2  hello.c

This will enable any toolchain workarounds for the 0.2 version of the ADSP-BF537 processor, and set the __SILICON_REVISION__ to 2.

If silicon version is specified to be none, then no errata workarounds are enabled. If silicon version is specified to any then this will enable all workarounds for the target processor. All developers should ensure the correct silicon part/revision is specified on the command line when invoking a particular tool.

Since many anomalies are fixed on early silicon, it is normally the plan of the team working on the GNU Toolchain, and the Linux kernel not to implement workarounds which are early (0.0) or no longer avalible (too old). This is that list: