HW_Design_Checking_List_for_i.MX6DQP6DQ6SDL

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

HW_Design_Checking_List_for_i.MX6DQP6DQ6SDL

HW_Design_Checking_List_for_i.MX6DQP6DQ6SDL


This is a HW design checklist for customer's reference.

Please read and fill it in carefully before requesting a schematic review.

Rev3.1 @2016.10.19 --

1. Add i.MX6DQP related contents.

Attachments
Comments

You should use the officially posted H/W Developers Guide on te Freescale website - you will find the IMX6DQ6SDLHDG under the "User Guides" subdirectory at

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp=1&tab=Documentation_Tab

This is a summary based on IMX6DQ6SDLHDG and our supporting experience.

It is convenient for customer using!

I'm trying to use this check list for my design and the data bus in the "MX6 DRAM Bus Length Check" tab fails because of the L0 values for DRAM_D48 to DRAM_D63 are filled with values over 300.  That seems a lot, considering that all the other pins are set to 0.   Are the L0 values set up correctly in the spreadsheet? Our layout is almost identical to the Freescale reference platform.

Hi Rowlan,

Thanks for your comments!

It is a bug, I had fixed it and updated.

All L0 should be zero in the excel.

Thanks Lin!

The other problem we have is CKE0, on the Freescale reference platform CKE0 is shorter than the other nets in its group and does not seem to be tuned.  Any ideas why?

Hi Rowland,

I think CKE0 related timing requirement are not tight, so It is not critical for layout.

Do you agree?

Yes, I looked at the memory datasheet and I think you are right.

Thanks for your help.

We have a custom IMX6Q board.  We boot from SD3/4-bit, using BOOT_CFG1[7:0]= 0100 0000; and BOOT_CFG2[7:0]= 0011 0000.  Our board doesn't boot up consistently from SD3- if we reset it (POR_B=0) repeatedly, it may or may not boot up.  When it doesn't boot up, we can run the DDR stress test over USB so the IMX6Q is still functional.

This problem can't be the ERR006282 errata because it's too frequent.

This spreadsheet mentions a "MMC/SD boot failure", and I think it refers to setting BOOT_CFG2[2] high to do a DLL override?  Is this new errata?  Anyone have more details?

Thanks.

The item in spreadsheet is related with actual SD bus layout and the failure may happen during bad SI design and very long bus is applied.

Please create a separate question in community with related info showed(0x450[10] status and chip version).

Hi Wang Lin, regarding the added comment - Please keep i.Mx6 "SDx_RESET" pin connecting properly with device reset pin  when eMMC/SD fast boot is used in a design (Latest silicon version had fixed this issue, don't need consider this item.), do you know exactly from which silicon version onwards has this issue been fixed?

After checking, this fix was applied on i.MX6DQ AC and i.MX6SDL AB.

Normally i.MX6SDL will be 1 version lower than its i.MX6DQ equivalent, i.e. normally i.MX6DQ "C” version corresponds to the i.MX6SDL "B” version.  Thanks for checking.

Sorry, my mistake, it should be "AB" for i.MX6SDL.

Thanks!

The DRAM lenght tab is interresting but why keep all L0 to 0 ?

I got the internal wiring length for both PBGA and FCBGA and they do vary, I think we should take this inyo account and have a tab for each package and maybe increase tolerance to match Hardware Development Guide.

Thanks, Philippe.

Yes,you catch the point.

That's the reason why we define a very strict equal length rules.

Based on simulation analysis and real test result, the rules are robust to meet the requirement using PBGA and FCBGA on same PCB design.

We believe most of our customer don't care L0 but only the stability and performance.

LinWang    I preferred the previous spreadsheet for customer to select Yes, No, Not Sure instead of the newer Clear, Not Sure.

Having the No as default forced customer to change to Yes therefore I knew they actually read the checkpoint.

Can you see if this can be changed back?

Regards,

Brett Phagan

Hi,

  I refer to "HW Design Checking List for i.Mx6DQSDL Rev2.7" for DRAM Bus length Check of my layout, but I found control group should only have CKE/CS/ODT, cannot include RAS/CAS/WE, I also refer to Intel and "IMX6DQ6SDLHDG_Hardware Development Guide" that the documents also describe Control signals only have CS/CKE/ODT, why does control group include RAS/CAS/WE in the "HW Design Checking List for i.Mx6DQSDL Rev2.7" and compare the trace length<=25mil?

Best regards,

Jasper Chen.

Hi Jasper,

Please check checking list and HDG carefully, we list RAS/CAS/WE in another row of table.

trace length rules are defined for timing control.

Hi LinWang:

I check it carefully, that's why I can find the different between HDG and HW design checking list of Freescale documents, so Freescale any recommend for the different? follow HDG or checking list?

Thanks and best regards,

Jasper.

Hi Jasper,

Sorry, would you please capture a picture and show the different to me?

I believe it is same between checking list and HDG on this part.

Thanks!

Hi LinWang:

     Please see "Hardware Develop Guide for i.MX6Dual/6Quad and i.MX 6Solo/6DualLite Applications Precessors, Rev. 1" page3-8 Table3-3. DDR3 routing by byte group as below Pic1/2.

Pic1.

Snap5.jpg

Pic2.

Snap4.jpg

Pic3. from HW Design Checking List for i.Mx6DQSDL Rev2.7: MX6 DRAM Bus Length Check.

Snap6.jpg

Best regards,

Jasper.

Hi Jasper,

If you mean CS1/ODT1/CKE1, the reason is most application only use one CS, so the self checking table didn't include another CS related signals.

If you will use two CS, all signals should follow the rule.


if you mean Address and BA, you can find them in the top side of table.

2.png

Hi LinWang:

I mean RAS/CAS/WE should compare with Address signals and not compare with control group whatever CS[0:1]/ODT[0:1]/CKE[0:1] from Intel and Freescale HDG.

But why RAS/CAS/WE signal compare with control group in the checking list?

Best regards,

Jasper.

Hi Jasper,

All address and control signals should compare with clock length.

it is aligned in table and excel.

Please check.

Hi LinWang,

     I know all address and control signals must compare with clock length, but why RAS/CAS/WE also compare with CKE/CS/ODT in the checking list, not compare with address?

Please confirm~

Hi Jasper,

After checking,

Both RAS/CAS/WE and CKE/CS/ODT in the checking list are compare with clock, not others.

Hi LinWang,

     But HDG describe RAS/CAS/WE should compare with clock and address signals, not control signal(CKE/CS/ODT).

Why?

Please confirm again~

I can't understand why you say HDG " describe RAS/CAS/WE should compare with clock and address signals".

all signals are compare with clock in HDG and checking list.

Hi LinWang,

  Please just focus on command and control signals.

The HDG recommend command signals compare with clock and address signals.

But the checking list recommend command signals compare with control and clock signals, not compare with address and clock signals.

The two documents description is different, please check~

Please help to capture picture here.

Thanks!

Please see above reply from me, Pic1/2/3.

chen jasper   2014/10/14 下午 9:11  (回應 LinWang)

LinWang,

I think the wording of the question is not clear.

In the HDG, you have Address, RAS,CAS,SDBA and SDWE listed together. They have a min max related to clock. But they also have a +/- 25 mils to each other. See last column.

CS, SDCKE and SDODT are grouped together with min max to clock. They also have a +/- 50 mils dependency to each other.

Are there any dependencies between the 2 groups?

Is the to groups of signals completely independent of each other?

One can be near max clock and the other group near min clock?

Regards,

Brett

Hi LinWang,

My question is

In the HDG define: Command signals(RAS/CAS/WE) compare with "address signals" and clock signals.

In the MX6 DRAM Bus Length Check sheet of HW Design checking list define: Command signals(RAS/CAS/WE) compare with "control signals" and clock signals.

Which one is correct?

Hi Brett,

Are there any dependencies between the 2 groups?

[WL] no, don't need.

Is the to groups of signals completely independent of each other?

[WL] yes for board level timing control.

One can be near max clock and the other group near min clock?

[WL] clock only have +/-5mil different. so That will not bring and big different.

Please check table header define.

"control signals" is group name.

I should have been clearer on the third question:

Can one group be close to Clock-200 and the other group be close to Clock since each group has those listed as min max?

Yes,

For CS/ODT/CKE group isn't involved into read write high speed operation, so we don't need consider them so tight.

hi LinWang

Similar Hw Design Checking list document for the SoloLite Processors is available as well ?

--Pankaj Rana

Hi Pankaj Rana,

Sorry, we don't have a excel version checking list.

Please refer to i.MX6SL HDG.

There is checking list table in it.

Hi LinWang,

I have a question about Ref7 of the design checking list.

It says as below.

<Ref7>

To minimize current drain, the Freescale BSP (board-support package) disables the EMI I/O during DSM (deep-sleep mode). A pull-down resistor ensures that the DRAM is in the proper state during DSM.

• For LPDDR2: SDCKE[1:0] must be pulled down to meet the JEDEC sequence until the controller is

configured and starts driving.

• For DDR3: SDCKE[1:0] pull-down is not required to meet JEDEC.

According to this description, I understood a external pull-down resistor is not required for DDR3 because i.MX6 output low signal to SDCKE properly when DDR3 SDCKE has to be low (e.g. when deep sleep, reset, etc..) even though there is no external pull-down.

Is my understanding correct?

Best Regards,

Satoshi Shimoda

Hi Satoshi,

Sorry for late response due to holiday.

The key point is if JEDEC require low during power on, for DDR3 RESET pin is required and for LPDDR2 CKE pin is required.

i.MX6 IO internal pull down resistor can't guarantee low during power up, that's why need external pull down resistor.

Hope above explanation can help you. 

Hi LinWang,

Thank you for your reply.

OK, I understood a external resistor is needed for DDR3 RESET, but not needed for DDR3 SDCKE to meet JEDEC.

For DDR3 RESET, Hardware Development Guide official revision (Rev.1) says "Connect DRAM_RESET to a 10 kΩ 5% pulldown resistor to GND.", so it is no problem.

http://cache.freescale.com/files/32bit/doc/user_guide/IMX6DQ6SDLHDG.pdf?fasp=1&WT_TYPE=Users%20Guide...

Best Regards,

Satoshi Shimoda

Hi LingWang,

Sorry, one more question.

> i.MX6 IO internal pull down resistor can't guarantee low during power up,

According to JEDEC, CKE should to be "low" min 10ns before negate DRAM_REST_B.

Can i.MX6 pull down CKE to low even though during power up?

Best Regards,

Satoshi Shimoda

Sure, DRAM_RESET_B is also controlled by  i.MX6, so we can guarantee the timing.

Hi Lin,

Does any max layout length in those pin ?

USDHC
SD/MMC USDHC-2
SD3 USDHC-3

PCIE
CLK1_N
CLK1_P
PCIE_RXM
PCIE_RXP
PCIE_TXM
PCIE_TXP

RGMII for Ethernet
RGMII_TXC
RGMII_RD1
RGMII_RD2
RGMII_RD3
RGMII_RX_CTL
RGMII_RXC
RGMII_TD0
RGMII_TD1
RGMII_TD2
RGMII_TD3
RGMII_TX_CTL

USB
USB_H1_DP
USB_H1_DN
USB_OTG_DN
USB_OTG_DP

MIPI
DSI
CSI
CSI0

Apollo Chang

Hi Apollo,

It is hard to define a max rule for these ports.

Because they are depended on real working speed and actual PCB design, SI performance should be considered case by case.

Please refer to FSL reference design for your consideration and suggest to do post simulation with SI simulation tool.

Hope above info can help you.

Hi WangLin,

Any H/W checking lsit for i.MX6SoloX??

Best regards,

Carl

Hi Carl,

Sorry, currently it is not available.

Please refer to other 6 series checking list first.

Hi Lin,

Can you add

"Freescale i.MX6 "Fly by" DRAM PCB Layout Trace Length Calculation  "

into excel file ?

Hi Apollo,

Except clock length have no upper limit, all rules are same with T topology.

Fly-by is a common design in PC system, we can get general design rules through internet.

No ratings
Version history
Last update:
‎11-21-2012 10:39 PM
Updated by: