PCB design for RT1020, "Length Tuning"

[luiHS]

 

The RT1020 will soon be available, according to representatives of NXP in its forums, on the 26th of this month. I am already preparing the design of the PCB for my own design, and although the Datasheet has not yet been published, nor the diagrams on the evaluation board, probably the external memory start system QSPI, Hyperflash or the SD card will be the same as in the RT1050.

I have the RT1050 evaluation board and the schematic of that board. It is the first time that I am going to design a PCB for such a fast microcotroller, until now I made designs with Cortex M4 at 168Mhz and 180Mhz and with Flash inside the microcontroller. The RT1020, is a Cortex M7 at 500Mhz, and has no flash, you have to put an external flash to boot, or use an SD card.

The issue in the design of the PCB, are the considerations of the tracks that go from the microcontroller to the Hyperflash memory and perhaps also to the QSPI memory. One user suggested that for the QSPI memory it would probably not need the "Lenght Tuning", in Eagle the "meander" function, to give the same length to the tracks of a bus.

As I'm not sure, I took some photos, from the evaluation board of the RT1050, this is somewhat faster, it goes to 600Mhz, and both the Hyperflash and the QSPI seem to have tracks tuned in length. I also took some pictures of the tracks of the SDRAM that it has, and the same, although this I will not put it in my design.

Any suggestions or advice to apply the "Lenght Tuning"? It is the first time I do it,I think it's not complicated, I will route everything by hand. I suppose that these tracks should go directly from the memory chips to the microcontroller, without using vías.


Here the Hyperflash memory on the TOP side.




The QSPI, on the TOP side, do not see any track with the length tuned.




The QSPI, for the BOTTON side, here there are some tuned tracks to same length




The board has an SDRAM, also with tuned tracks, on the TOP side.




The SDRAM, for the BOTTOM side.

[funkathustra]

You typically route all the tracks straight, define your length matching rules, and then tune the shorter lengths. Altium and most other pro packages have tools to do this. In Altium, there's an Interactive Length Tuning command.

As someone who designs high speed PCBs for a living, here's a little secret: length tuning is far less critical than you may think. If you squeeze the RAM right next to the CPU, it is likely all the tracks will be so short that their length differences won't matter that much. Remember that for SDRAM routing, you can swap pins in each byte group, and you can swap byte groups.

Most dev boards have less-than-great component placement because they have to fan out the entire processor. Because modern devices have far more pins than are often required in an application, you can often have tighter component placement with your custom design.

One thing that *cannot* be overlooked is power distribution: these devices need a tremendous amount of dynamic power, which means lots of external bypass and bulk capacitors --- plus huge power planes. I recently had an i.MX6-based design give me fits all because I cheated a bit with the power delivery routing.

Also, while length tuning is often overrated, impedance matching is not. You need to be on a 4-layer process with a sensible stack-up (core between L2 and L3, with very thin prepreg between L1 and L2, and L3 and L4) to try to get your impedances down. Otherwise your memory traces will ring uncontrollably.

Good luck! Post your layouts here and we can take a look!

[Rerouter]

For length tuning. There will be a sample window spec for the protocol. Use it to work out your timing margins. If your inside it. Job done.

I generally do a bit of tuning to improve my margin. But dont fight to the last 0.1mm

[luiHS]

Thank you so much for all your advices.

One question I have, is about SD cards and SDIO connection to the microcontroller. I have a design with Kinetis MK66, and also another with STM32, both with SDIO parallel 4bit, the problem is that only works with SD cards of some brands, such as Kingston and some more, but fails with others like Sandisk.

Some time ago I gave up trying to find out what the problem was, I just use them with brand-name SD cards that I know work for me. Now I wonder if the problem could come from not having adjusted the length of the tracks of the bus of 4 bits, so that they have the same length, may even that the control lines should have the same length.

What do you think, can SDIO access to SD cards fail, because they do not have the same length of tracks in all their lines?.  I do not know exactly what the access speed is for SDIO, I think the clock signal is 50Mhz for SDHC.

When it fails, when reading, the board is locked (it is a screen with LED panels) and when it can not write it, it creates a file with corrupted data or even a file of 0 bytes.

[Siwastaja]

What do you think, can SDIO access to SD cards fail, because they do not have the same length of tracks in all their lines?.  I do not know exactly what the access speed is for SDIO, I think the clock signal is 50Mhz for SDHC.

Most likely not. I'm not a signal integrity expert, but I think the length matching requirement for a bus at this speed is measured in several centimeters, if not more!

If it's even remotely sanely laid out, probably not an issue.

Signal integrity issue is well possible, though. Return currents must have a route right next to the trace, always. This is orders of magnitude more critical than length matching. If you have any loop there, ringing, overshoot, and EMI hell ensues.

This means an uninterrupted ground plane a few hundred micrometers down below, and good stitching every time there is a layer change or gap in the plane.

Lately I've been working with a 40MHz single ended parallel bus. I've been length matching to about +/- 3mm but I've been wondering if that's overdoing it, and maybe the time would be better spend otherwise.

[luiHS]

 
Ok thanks.
It will check the PCB design, or it may be that the problem is the FATFS library.

This works perfectly with SD by SPI for all SD card manufacturers, but for SDIO it fails with some manufacturers like Sandisk and Transcend. I must use Kingston and some Chinese SD cards that work well with my SDIO designs (with STM32 and Kinetis).

[Rerouter]

Do you have sufficient grounds for your signals? equally for SDIO mode, you need to have pullups on certain signals.

[funkathustra]

Do you have pull-ups on the CMD pin? It's usually good practice to put them on the DAT lines, too. Internal pull-ups are often too large.

The MMC spec allows the card to interrupt the host, but this requires pull-ups (since the card does this with an open-drain CMD pin configuration, I believe). In SPI mode, none of this happens, which would explain why your cards work in SPI mode but not SDIO mode. Some brands may have weak internal pull-ups inside the card.

Also, most people look at a MicroSD card's diminutive size and slap a 0.1 uF decoupling cap on it and call it good. In my experience, 22-47 uF bulk caps are not optional when running the card at SDIO-class speeds. Also, your power distribution has to be adequate. If you use a comically-low SDIO data rate (5 MHz?) and the interface starts working, I'd look at your power supply.

[luiHS]

 
For Kinetis, I applied the same scheme as the NXP evaluation board FRDM-K66F. There are no resistors in the data lines, only two capacitors in VDD. I have only seen some pull-up resistors, when SD is used by SPI (with STM32), but never by SDIO.

I already tried to modify the SDIO clock frequency, and it also failed with the same SD cards. Also no pull-up resistors in Teensy 3.6 with SDIO, this is a Kinetis MK66 180Mhz.

[luiHS]

 
Today I received my RT1020 evaluation board, this board install a LQFP144. It seems that there is no hyperflash, only QSPI and SDRAM. I assume can only boot from SD or QSPI.

The SDK is now available from the RT1020 for MCUXpresso. I downloaded it and installed it, although the Peripheral Tools and graphic settings of the Clock are not available. A lot of examples of source code and documentation, seem good.

The board only provides a micro USB cable, that's all. There is no software, there is no CD or DVD, there is a document of the Packing List, where it puts the link to the website nxp.com/MIMXRT1020EVKQSG, but it does not work, so at this moment there is no documentation on this board. I hope that on the 26th the Data Sheet, the Reference Manual and the User Manual of the evaluation board will be available.

I wans start as soon as possible, to migrate all my developments with Kinetis and STM32, to RT1020.

By the way, in the last photo, there is a chip on the board that I can not identify, with the reference that has been printed I do not get anything from Google, I can only see that it is manufactured by NXP.

[luiHS]

 
Just today, I received the 10 x RT1020 LQFP100 that I ordered from Digikey, very fast. I am ready to design my PCB for this powerful microcontroller, something easy with QSPI, SDIO, some leds for testing purposes and some additional chips and connectors for my LED screen application.

I hope that NXP will soon release a new version of the SDK with the Peripheral Tools for MCUXpresso, for me it is essential. Also I wait for the LQFP144, need it for some designs. Time to migrate all my designs with Kinetis to RT1020.

[mac.6]

MCUXpresso Config Tool v4.1 has support for i.MXRT1021, you don't need new SDK (SDK and config tools are two separate things).

[luiHS]

MCUXpresso Config Tool v4.1 has support for i.MXRT1021, you don't need new SDK (SDK and config tools are two separate things).

The current MCUXpresso IDE 10.2.0 needs the SDKs for each microcontroller that you want to add, except for the LPCs that are already integrated into MCUXpresso. The problem is that the SDK for RT1020 and RT1050, does not yet support the Peripheral Tools to configure DMA, SPI, interrupts, etc.

I work with MCUXpresso IDE 10.2, not with tools outside the IDE, since from version 10.2 MCUXpresso IDE already includes the Configuration Tools (Pins, Clock, Peripherals) within the editor. The pre-installed MCUs are only LPC, for Kinetis and i.MX you need to add the SDK for each microcontroller.

[JPortici]

By the way, in the last photo, there is a chip on the board that I can not identify, with the reference that has been printed I do not get anything from Google, I can only see that it is manufactured by NXP.

don't you have the shematic? anyway looking at the surrounding components (common mode choke, not populated.. 62ohm split termination resistors, differential pair traces, ..) i think it's TJA1057 can transceiver

[luiHS]

By the way, in the last photo, there is a chip on the board that I can not identify, with the reference that has been printed I do not get anything from Google, I can only see that it is manufactured by NXP.

don't you have the shematic? anyway looking at the surrounding components (common mode choke, not populated.. 62ohm split termination resistors, differential pair traces, ..) i think it's TJA1057 can transceiver

Yes, its a CAN bus transceiver chip.