In last month’s issue I discussed how DMA controllers can be used to troubleshoot data flow problems in and out of a block. Since DMA controllers are instantiated in many blocks, the DMA controller is a good place to put additional debugging tools.

One such debugging tool is a CRC generator that calculates the CRC of the data moving through the DMA controller. After the DMA controller transfer is completed, firmware can read the CRC value. Since data corruption problems are typically not noted until the end of the pipeline, looking at the DMA controller CRCs at the various steps within the pipeline may give clues to corruption problems.

Memory corruption can occur for a variety of reasons, such as a rogue process writing to that location, cache flush and invalidation problems, or – as happened to us once – a bug in the memory controller generating a bad address occasionally. Whatever the reason, CRCs can help narrow down where to look for the sources of data corruption. If the CRC from the DMA controller writing data to memory does not match the CRC from the DMA controller reading data from memory, then that is a clue that corruption happened to the data in that memory location.

Note that the CRC may not be the same throughout the data pipeline. A block processing the data is likely to be modifying the data. So the DMA controller CRC when the block reads the data may be different than the CRC when it writes the data. Adding the CRC generator in the DMA controller module that is instantiated throughout the chip will assure that the same CRC algorithm is used in all locations.

• Best Practice: Include a CRC generator in the DMA controller module instantiated throughout the chip.

Like data corruption, byte swapping issues are a common source of annoyance, confusion, and defects. Building a byte-swapping capability into the DMA controller provides another useful debugging tool.

In my own experience with LaserJet printer development, our team has dealt with endianness issues in processors, blocks in ASICs, communication channels, and print jobs. On one of our previous projects, the printer under development was experiencing a severe performance penalty. Our team discovered that the data was being byte-swapped 11 times; many of the swaps were redundant, and many were done via firmware. Several conditions lead to that situation:

• The firmware was leveraged from a previous product with different swapping needs.
• Engineers knew their little piece of the pipeline and did not know what byte swapping was done outside their little piece.
• Engineers invoked an additional byte swapping step when they should have disabled one before or after it.
• Engineers invoked a firmware-base routine, not knowing the hardware had the ability to do so.

After a thorough analysis of the whole pipe, we were able to reduce the number of byte swaps to 3 and to do most of them using the byte-swapping feature in our DMA controllers. Reducing the byte swaps and using the DMA controller byte-swapper improved the printer’s performance dramatically.

Even if you don’t think you will need byte swapping capability in your DMA controllers for a current platform, you just might when you develop a new platform.

• Best Practice: Include a byte-swapping capability in the DMA controller module instantiated throughout the chip.

Until the next swap…