DDR3L rules and constrains confirmations

[Mihai]

Hi,

This is just to confirm that I understand correctly the design guides for DDR3. I am designing a project which will use a 256x16 DDR3 chip with the 16-bit DQ bus configuration. I have read a lot of design guides even from both the controller vendor and the memory vendor. Since my configuration is point-to-point one, with a controller and one DDR3 chip, I have set the following design rules:

1- All the DQ, DM and DQS need to be length matched together, which include the following signals: DQ [0:15], LDM, UDM, UDQS, UDQS#, LDQS and LDQS#;
2- All the ADDR/CMD/CLK signal need to be length matched together, which include the following signals: ADR [0:14], BA[0:2],CLK,CLK#,CLKE, WE#,CAS#,RAS#,CS#,ODT and RST;

Please let me know if the rules which I have applied are correct, or if I missed something.

Cheers,
Mihai

[Paul van Avesaath]

Yes you are correct!

[Mihai]

Hi Paul,

Thank you!
Also, just to clarify something, even if its a 16-bit interface, the data maching has to be done within a byte lane, and not on the whole 16-bit data as described by me at 1. Right?

Cheers,
Mihai

[Paul van Avesaath]

You stated in your question that you would match all 16 dq and dqs pairs and dm so I would go with 16 and match those. Or change controller type to go to 8x then you are safe by doing dq0.. 7 dqs and dm of that set togehtor.. I am not sure what happens in the controller if you would route it with 8x and use it as 16x.. Normally the dqs and dm would manage read and write of the bytegroup so as long as it is matched it should work.. Again not 100% sure about it.. Maybe robert can tell..

[Mihai]

Hi Paul van Avesaath, that's what I though too, when using 16-bit interface. However, I haven't seen it explicit said in any design guide which I read. All design guides says only about the byte lane, not both. Maybe robertferanec can clarify this.

Cheers,
Mihai

[Paul van Avesaath]

I think it should be fine.. But if Robert or anyone else can confirm you should be good to go!

[robertferanec]

Mihai, some time ago we created a nice picture, maybe it will help you (T branch length matching picture attached below).

For data, you length match the signals withing groups - and the groups are created based on STROBE (DQS) signals. To make the answer short - usually you have 8 bits + Mask + Strobe ... so these are the signals what you need to length match (there are other cases e.g. when you use 4 bit memories, but I do not want you to confuse you). Strobe signal is basically used to tell when to read / write corresponding bits which are related to the STROBE ... so if you have STROBE for 8 bits, then you length match 8 bits data bus + mask and strobe for them.

From length matching point of view, 16 bit memories are 2 banks in one package ... they are still like two 8 bit data banks with MASK and STROBE, ... so you still work with them as individual banks (from length matching point of view, they are independent 2 groups of signals which can be length matched independently)

ADDR/ CMD/ CTL length matching depends on topology you use.

Google for "imx6 design guide", it can help you: http://cache.freescale.com/files/32b...6DQ6SDLHDG.pdf

Here is the picture (this is specific for iMX6, for other processors it may be different):

[Mihai]

Hi Robert,

Many thanks for your clarification, now it is clear for me.

Cheers.
Mihai

[Mihai]

I have started the routing, while now I am thinking for a better placement to keep the tracks smaller than 5 cm. What do you think about this kind of placement? This is just a basic routing, to have an idea how the tracks will be arranged. After I am decided with the placement, I will start with the routing and the length matching,


Cheers,
Mihai

[Paul van Avesaath]

Try to keep all signals on the same layer. I think your dqs pair now has an extra transition that the others don't.. You may swap the dq0 - dq7 in any order you want to make that happen....

[robertferanec]

What do you think about this kind of placement? This is just a basic routing, to have an idea how the tracks will be arranged.

- check how they did placement and layout on the reference board, that may help.

[Mihai]

Its hard to find a reference design, due to the fact that they dont have it (Xilinx), or at least I didnt find it, However, I know some custom commercial boards which have DDR3, and I have look on their placement in order to ensure a clean and easy routing.Thank you robertferanec and Paul van Avesaath.

Cheers,
Mihai

[Mihai]

And preliminary this is how it looks, I may do some later improvements, but this is it.

Cheers,
Mihai

[Paul van Avesaath]

That looks excellent..

i usually do the address and command lines first because they are not interchangable like the DQ's so keep that in mind.. also address and cmd lines are slower than the rest.. so can have more tolerances and are not that critical in choosing different layers to route on.. (but always try and do as much of these on a single layer just dont go overboard becasue if you can make it fit much better on two layers.. then do that instead of introducing a lot of length ..)

[Mihai]

Hi Paul van Avesaath,

You are right, the address and commands should go first as right now I am routing them and also I had to make some adjustments in one of the data bank to have more space, however in my FPGA I can swap also the address and command lines. Also, the FPGA vendor has a tool for memory interface were I can put the final pinouts to validate the design, and if something is wrong with the pinouts this tool should tell me, but just to be sure I check them also manually.

Cheers,
Mihai