[Hardware Basics] DDR chip data line disorder problem

Today I started to roughly learn arm+linux, using Wei Dongshan's IMX6ULL PRO development board. According to the usual practice, I will first study the hardware schematic diagram and the development board manual. When learning the circuit diagram of the core board, I found a situation that violated my common sense: the data lines of the DDR chip are out of order, as shown in the figure below: It can be found that the address line is exactly the same as that of the SOC,

but the data line is out of order. The order, but this is not necessarily a mistake, although I clearly knew that the address lines and data lines cannot be out of order when I was learning about the SRAM of STM32.
Let's talk about some ways to expand ram that I learned before.
[1] STM32 uses FSMC interface to connect SRAM to expand external ram (Gd32 is called EXMC).

Most beginners use this kind of SRAM that occupies many pins and has a small capacity. The address lines and data lines add up to more than 32 pins, but its advantage is that it is very fast, although it is not as fast as the access speed of internal RAM. In the study of this, I have never seen the data lines of such a large SRAM chip on any development board being connected out of order, so my experience is that they cannot be connected randomly. This is highly likely to be the same as the FSMC interface on the STM32. There is a relationship.
[2] PSRAM (pseudo-SRAM), this can be driven by the PSRAM part in FSMC/EXMC, or by SPI/QPI, but the biggest disadvantage of this thing is that it is slow, even in QPI/SQPI mode.
The only PSRAM models I have checked are the following: LY68L6400, VTI7064, and IPS6404; after using and comparing, I found that the protocols of PSRAM are almost the same, and some models may not support ID checking. There are two ways to use it: FSMC or traditional SPI.
But in fact, no matter what it is, it is based on the SPI protocol. Using the PSRAM QPI driver in FSMC only increases the speed of the clock line in the form of QPI interface, and it also needs to send read/write instructions, specify the mode, and so on. Because this article is not specifically written for this content, so here is just a mention. If someone needs an article later to clarify: the relationship between SPI/Dual SPI/SQPI/QPI and how to use FSMC PSRAM QPI to drive PSRAM, I'll figure it out on my own.

PSRAM is shown in the picture, do you think it is very similar to those flash chips of W28Q16, in fact, if you directly use SPI to drive it, there is no difference between it and flash chips, that is, the data will be lost when the power is turned off. Its advantages are: Compared with traditional SRAM, it takes up less IO, has a smaller bom area, and lower cost. It can have a space of 4Mb to 16Mb in such a small piece, and the price/performance ratio is still very high. But its problem, I personally think that if it is driven solely by SPI, it is limited by the SPI clock. Compared with the internal RAM, it is not a little bit slower. If you use FSMC PSRAM QPI to drive, you say it is fast, but it is actually fast, but it is still slower than internal RAM. When up master was working on a camera project, he used it as a data buffer area. The internal ram can complete VGA 60 frames of raw data, but using this PSRAM, theoretically, if it is as fast as the internal Ram, it can touch 1080P 10 frames , but the fact is that it can only support up to 2 frames. When
a VGA (640 x 480 size) is received in raw8 format, it needs to occupy 300Kb Ram. When a 1080P (1920 1080 size) is received in raw8 format, it needs to occupy 2025Kb Ram. The largest ram of the MCU is only 512Kb, so I can use VGA smoothly, but I can't use 1080P, so I expand the RAM.


If there is a camera that can process 1080P into JPEG format by itself, then the RAM usage can be greatly reduced. However, no such camera was found at that time. Even if it supports Jpeg format, the output size cannot reach 1080P.
--------------------------------------Dividing line---------- -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
_ out of order connection.
After learning, it is found that it is not completely out of order, but [bytes can be out of order], and the connection also needs to be done according to the reference given by the manufacturer. I heard that DQ[0:7] of DDR of some manufacturers needs to be connected. To the DQ[8:15] of the Soc, but generally the high byte is connected to the high byte, and the low byte is connected to the low byte.
Can it be in exactly the same order? sure. Can it be completely out of order? [The bytes can be out of order, but I don’t know why I read the schematic diagrams of several boards, it seems that DQ0 and DQ15 are not connected in out of order, maybe this is the pit that people stepped on before] The current conclusion is: DQ[
1 :7] can be connected in random order on the data lines in this byte, and DQ[8:14] can be connected in random order on the data lines in this byte. As for why it does not affect the function, it is because even if the order is inconsistent, the order of the data will be inconsistent when it is passed in, and it will also be inconsistent when it is read out. As long as the order of passing in and reading out is consistent, then no problem. The most basic principle for judging whether the sequence of data lines can be adjusted is to ensure that the read sequence is consistent with the write sequence, and the slave device does not have internal command parsing.