I'm routing an eMMC 5.1 device to a iMX6 microprocessor. When routing the DDR RAM, I've swapped several data lines to ease routing, following widely available documentation on the subject.

There isn't so much documentation regarding eMMC. The JEDEC standard makes no mention of swapping, but states:

DAT0-DAT7: These are bidirectional data channels. The DAT signals operate in push-pull mode. Only the card or the host is driving these signals at a time. By default, after power up or reset, only DAT0 is used for data transfer. A wider data bus can be configured for data transfer, using either DAT0-DAT3 or DAT0-DAT7, by the MultiMediaCard controller.

So presumably, DAT0 cannot be swapped, and the DAT1-DAT3 and DAT4-DAT7 lines can be swapped between themselves without mixing the two groups together. And since eMMC has a CMD line for commands, I don't think there are any register writes taking place on the data bus, so there's no concern with swapping there.

Is this correct?


1 Answer 1


Updated again: it's a very interesting idea, but I'd checked carefully the CRC and ECC functionality of the card in all its various modes; might be considered weak against future versions of the standard. Confirmed in comments (thanks @jpa) that CRCs are bitwise per databus line, which makes it sound promising.

I believe there will could might be a difficulty because of the CRC values transmitted over the data bus. The CRC over data is CCITT16 (x16 + x12 + x5 + 1)

Further reading the JESD84-A43 standard, it appears that one CRC is calculated per data line, in which case the argument against is invalid, see below.

10.2: For data blocks one CRC per transferred block, per data line, is generated
in 4 bit and 8 bit bus configurations, the CRC16 is calculated for each line separately.

If the CRC on data bus D n is calculated on the data bits n, then the data bus bits are effectively independent columns, and the shuffle should be undetectable.

My reading of the 8-bit and 4-bit modes says that if you never wanted to use 4-bit mode, you could shuffle any of bits 1-7 with any other.

Argument against

If anything calculates across the byte it would fail:

Suppose you swap bits 2 and 1 in hardware

rot(x) := swap bits 2 and 1
crc16(0x32) = 0x1611
crc16(rot(0x32)) = crc16(0x34) == 0x76d7
rot(0x16) != 0x76
so the CRC would fail if it's done across the byte

Calculated with crccalc.com and pycrc16, xmodem variant.

If the eMMC device doesn't do anything except calculate and transmit the CRC, it might be possible to calculate and send something which reverses the effects of the data bus shuffle. It might also be possible to ignore the CRC, such as in stream mode.

The same kind of issue might affect the BCH (542,512) error correcting code, if used.

Here's the portion of the JEDEC doc saying the CRC is transmitted on the data lines. The drawing makes it look like the CRC is 16 bits / 4 bits / 2 bit according to the bus width of 1 / 4 / 8 bits. But closer reading suggests it is always 16 bits long.

JESD84-A43 standard (link at NXP)

enter image description here

Digression The firm I worked at in the 1980s built an error-correcting circuit. In order to shuffle the bits around to minimise noise hitting bits from the same error-correction block, we put in an area of RAM which was connected to the CPU through two sets of address and data latches; one normal, one bit-reversed so A0:A15 mapped to A15:A0 and D0:D11 mapped to D11:D0. Thankfully all ROMs were connected the ordinary way around.

  • \$\begingroup\$ Having implemented the 4-bit mode CRC in one system myself, I can confirm that it is per-line and swapping lines should not affect it. \$\endgroup\$
    – jpa
    Commented Oct 11, 2022 at 11:46
  • \$\begingroup\$ @jpa many thanks for your comment, updated answer \$\endgroup\$
    – jonathanjo
    Commented Oct 11, 2022 at 12:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.