AN00170 "Using the SDRAM library"

If you have a simple question and just want an answer.
User avatar
PlayingWithWires
Member
Posts: 12
Joined: Thu Apr 14, 2016 8:14 pm

AN00170 "Using the SDRAM library"

Post by PlayingWithWires »

Hi! Any news on the availability of application note AN00170 "Using the SDRAM library" mentioned in the SDRAM library user guide?

Thanks!

- Tony


robertxmos
XCore Addict
Posts: 169
Joined: Fri Oct 23, 2015 10:23 am

Post by robertxmos »

Hi PlayingWithWires,

The publishing of AN00170 is indeed on the to do list - it may take a little time to bubble to the top.
Whilst you wait, have you taken a look at the example code found at:
https://github.com/xmos/lib_sdram/tree/master/examples

robert
User avatar
PlayingWithWires
Member
Posts: 12
Joined: Thu Apr 14, 2016 8:14 pm

Post by PlayingWithWires »

Thanks Robert! I'll definitely look at the examples. Is there anything I should know about applying the examples to a XU216-512-TQ128 processor with one Micron MT48LC16M16A2P 256Mb SDRAM?

- Tony
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Is there anything I should know about applying the examples to a XU216-512-TQ128 processor with one Micron MT48LC16M16A2P 256Mb SDRAM?
The latest library (3.1.0) supports 256Mb SDRAMs OK (xCORE 200 only - so OK for XU216), so from a software perspective, that should be fine.

Hardware-wise, it's going to be important that you follow good SI rules. We don't have a specific published guidelines for this but all of the normal stuff (avoid stubs, length matching, avoid noise sources, reduce crosstalk/ensure good spacing, short trace lengths, controlled impedance) is key. There are buckets of app notes online to help with this.

Regarding port selection, there is more skew on tile 1 port 16B (some pins on that port have higher strength drivers because they can also do RGMII), so if you wish to use Tile 1 go with the following I/O, you should be OK:

Code: Select all

            <!-- SDRAM ports -->
            <Port Location="XS1_PORT_1A"  Name="PORT_SD_CAS_N"/>
            <Port Location="XS1_PORT_1B"  Name="PORT_SD_RAS_N"/>
            <Port Location="XS1_PORT_1C"  Name="PORT_SD_CLK"/>
            <Port Location="XS1_PORT_1D"  Name="PORT_SD_WE_N"/>
            <Port Location="XS1_PORT_16A"  Name="PORT_SD_ADQ_DQ_BA"/>
You can also use ports 1E - 1H if those 1b ports don't work for you.

If choosing tile 0, the same port allocations will be fine. We have a board based on the above and, despite being rated to 66MHz, we had it running solidly at 83MHz on the bench.

Tile 0 for SDRAM makes more sense in USB apps anyhow as you loose less 1b ports putting USB on Tile 1..

Oh, and don't forget the NOR gate (SN74LVC1G02) to drive the DQM signal - you can see the schematic here https://www.xmos.com/support/boards?pro ... nent=16077
User avatar
PlayingWithWires
Member
Posts: 12
Joined: Thu Apr 14, 2016 8:14 pm

Post by PlayingWithWires »

Hi Infiniteimprobability - Apologies in advance for the length of this post! I was looking for info about coding with the 3.1.0 library, but the hardware info you shared is much appreciated. It indicates that there may be a problem with our new PCB (just received yesterday), and I hope you can help us determine how significant the problem is.

Four months ago, we had an unsuccessful attempt at using the xCORE-200 USB sliceKIT to test out the latest SDRAM library ( see post http://www.xcore.com/forum/viewtopic.ph ... AM&start=0 ). For this and other project related reasons, we decided to design a prototype PCB of our own.

Our PCB has the XU216, 256Mb Micron SDRAM, and other project relevant peripherals on it. A 6-layer layout was used with much attention paid to SDRAM signal lengths and consideration of transmission line effects for the rise times involved. Series terminators were used on the ADQ bus signals, the DQM NOR gate is present, and we are using P1A0-D0 on tile 1 for SDRAM control.

This is where things get messy. I selected port 16B on tile 1 for the ADQ bus. Here’s how the decision was made since some of my assumptions (and possibly those of other users) may be incorrect:

On tile 0, port 16A could not be used since we have a flash RAM connected to the QSPI interface. Port 16B on tile 0 could have been used, but the pins are brought out on three sides of the chip and that adds layout difficulty due to the length and matching constraints. On Tile 1, port 16A has the same issue - the pins are spread out over three sides of the chip. However, pins for port 16B on tile 1 are brought out very close together on one corner of the chip, making it easier to keep ADQ bus lengths as short and even as practical.

Several documents were checked prior to PCB layout to see if there is any reason to chose one port over another in this particular case. The lib_SDRAM user guide does not directly indicate which port to use or not use. It actually references port 16A in the sample code but does not indicate that it is on tile 0. After reading your post today, I returned to the XU216 data sheet and XS1 Port I/O Timing documents to see what I have overlooked. Searching for ‘skew’, ‘delay’, ‘RGMII’, and other related words did not return anything that would preclude selecting 16B on tile 1.

This is just history - none of it is intended to contradict your good advice - just trying to understand how to find similar information in the future when sifting through the many pages of XMOS documentation and how to keep this project on track with the prototype board being what it is now.

An objective of our prototype PCB is to evaluate the SDRAM library with the xCORE-200. Our plan is to create fake data in firmware to emulate converters that will eventually be part of the system, use the SDRAM as a buffer, ship the data to our host over USB for analysis (did our fake data arrive intact?) and then repeat the data integrity testing in the reverse direction.

We will have the opportunity to make changes to the PCB on the next iteration, however, passing these tests are essential to qualifying XMOS as a vendor for this product.

Questions:

- Is skew the only parameter we need to be concerned about, or do the RGMII drivers also introduce jitter or affect rise/fall times?
- The xCORE-200 port map spreadsheet infers that P16B8-11 (mapped to SD_AQ08-11) do not have RGMII drivers on them. Will all other signals on that port arrive behind P16B8-11? Is there any data for much skew will we encounter?
- Can the RGMII drivers be bypassed/disabled?
- In this situation, how fast do you think the SDRAM can be operated when trying to meet our testing objectives?
- Other than the previously mentioned documents, are there any other XMOS documents that would be helpful to review at this time?
- Will AN00170 contain information about port selection, suggested component placements, and/or Gerbers?
- Do you think we can move forward with above mentioned tests with the board as it is or are we wasting our time?
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

After reading your post today, I returned to the XU216 data sheet and XS1 Port I/O Timing documents to see what I have overlooked. Searching for ‘skew’, ‘delay’, ‘RGMII’, and other related words did not return anything that would preclude selecting 16B on tile 1.
Yes - appolgies. This is new information from a currently unreleased (it is still being verified) document. the objective was to give you advance information to help guide you. Anyhow, I understand you are already there with hardware so let's work with what we have for now.
This is just history - none of it is intended to contradict your good advice - just trying to understand how to find similar information in the future when sifting through the many pages of XMOS documentation and how to keep this project on track with the prototype board being what it is now.
Understood! It's good that we are in dialogue so can try to asses what needs to be done now.
Questions:

- Is skew the only parameter we need to be concerned about, or do the RGMII drivers also introduce jitter or affect rise/fall times?
Inherently, resampling to a different clock domain will introduce jitter. All XMOS I/O are resampled into the core clock domain (nominally 500MHz). This is something you can ignore for slow signals, but needs thining about for faster signals like SDRAM. The RGMII drivers are just stronger CMOS drivers with the ability to run at 2.5V on a separate I/O bank.
- The xCORE-200 port map spreadsheet infers that P16B8-11 (mapped to SD_AQ08-11) do not have RGMII drivers on them. Will all other signals on that port arrive behind P16B8-11? Is there any data for much skew will we encounter?
Let me see if I can get some preliminary data..
- Can the RGMII drivers be bypassed/disabled?
No - the stronger drive strength is fixed in the I/O pad - the tx pads have an 8mA driver instead of 4mA
- In this situation, how fast do you think the SDRAM can be operated when trying to meet our testing objectives?
Am working on this...
- Other than the previously mentioned documents, are there any other XMOS documents that would be helpful to review at this time?
Not yet - we are working on an extended I/O timing document currently - I'm afraid that's weeks away.
- Will AN00170 contain information about port selection, suggested component placements, and/or Gerbers?
Yes, but it's not on the near term to-do list currently.
- Do you think we can move forward with above mentioned tests with the board as it is or are we wasting our time?
Let me check..
User avatar
PlayingWithWires
Member
Posts: 12
Joined: Thu Apr 14, 2016 8:14 pm

Post by PlayingWithWires »

Hi Infiniteimprobability,

Thanks for the fast response. Let me know if there is any other information you need from me while researching answers.

- Tony
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Hi Tony,

In the absence of the I/O documentation (which we will prioritise getting verified and published), I have done some sums..

Using some preliminary worst case (PVT) figures derived from STA using a 2pF assumed load, here’s a quick timing analysis assuming a IS45S16160D-7. I have not accounted for PCB delays and clock jitter, thresholds etc. but these should be small.

For the output case (sending commands/address and data write), where the SDRAM sees source synchronous data, the max skew of data relative to clock across all banks on the chip (including RGMII capable banks) is +-2.7ns. Given the xcore outputs on the falling edge and the SDRAM inputs on the rising, and the SDRAM needs 1.5ns setup and 0.8ns hold, we could manage as little as a 7ns (142MHz) clock period before running into timing issues, so no need to consider this part further - it's all good.

Input (read) case is more complex. The xcore clock and command outputs are re-synchrnonised on the way out and so is the input data on the way in, adding 2 extra sets of delay resynchronisation flops on the round trip. The xcore outputs the clock on the falling edge and nominally samples on the rising. It means that the xcore is sampling very early compared to the signals at the pins, let alone the signals arriving back at the read logic. This is fine for <20MHz but for SDRAM (or QSPI) speeds we need to take care.

The worst case required data valid window on the whole chip is around 21.3ns setup to -11ns hold. The required valid window is 21.3-11 = 10.3ns

Looking at the IS45S16160D, it has an access time of 5.5ns and hold time of 2.7ns. So in a 16ns cycle, it’s data is valid for 10.5+2.7ns = 13.2s, so it looks like there is enough window, if we can get the delays right.

The hold time is negative for the xcore because it captures too early for fast cycle times because of the round trip delay). So we need to add some read delays.

That is why the read cycle is delayed by one clock (see #define N (1)) in io.S which sets whole clock cycle delays and set_port_sample_delay(dq_ah) in server.xc. which adds half a cycle delay. In addition, we can add up to 5 lots of core clock (500MHz) input delays using set_pad_delay(dq_ah, n); in server.xc, which is 0..10ns. So there is some reasonable granularity to play with in the capture settings.

It gets a bit complex here because we are shifting our read window back in time, so I put together a spreadsheet. From that, I can see three settings that should be OK, although 62.5MHz is a bit close... I would probably opt for 50MHz which has bags of margin. See excel attachment.. Yellow boxes = input data.

Summary:

Clock | Divider | Delay-whole-cyc | Delay half-cyc | Delay-pad-n | Setup margin | Hold margin
62.5MHz 4 | 1 | 1 | 2 | 0.2ns | 1.7ns
50MHZ 5 | 1 | 1 | 0 | 2.2ns | 3.7ns
41.67MHz 6 | 1 | 0 | 4 | 4.2ns | 5.7ns

I gave them a quick try (as well as shifting the window back and forward a bit for sanity) on the bench and they seemed to be fine.. However, please check these timings yourself to satisfy they work.

Out of interest, I looked at what the skews would be like for a more tightly matched bank, and it only gives us about 1.8ns extra margin, so doesn't look like the end of the world choosing the RGMII bank, as long as you are careful about signal integrity on the 8mA drivers which are present on the RGMII tx pins (X1D26, X1D27, X1D40, X1D41, X1D42, X1D43). They drive pretty hard... All other drivers are 4mA
Attachments
xcore sdram timing.xlsx
(334.81 KiB) Downloaded 373 times
xcore sdram timing.xlsx
(334.81 KiB) Downloaded 373 times
User avatar
PlayingWithWires
Member
Posts: 12
Joined: Thu Apr 14, 2016 8:14 pm

Post by PlayingWithWires »

Hi Infiniteimprobability,

Thank you for the thorough explanation, analysis, and bench verification. It's very useful.

I entered the access time (5.4ns max) and hold time (3ns min) values for the Micron SDRAM we are using into the spreadsheet you provided to verify that the margins are still good. It's a slightly faster part than the ISSI part you mentioned, so the margins are a little better at 50MHz. There may even be enough margin to test at 62.5MHz with the understanding that the system will be closer to 'flying off the rails'.

Based on this information, I think we can reach our test objectives with our PCB as it is. We are going to move ahead with SDRAM testing, focusing on 50MHz to start, which is close to our estimated worst case bandwidth requirement. We may experiment with the 62.5MHz rate if we get good results at 50MHz. It sounds like we may want to choose one of the other 16-bit ports for the production version if 62.5MHz operation is required. We have a way to go before we make that decision however.

The rest of our board (supplies, power-on-reset, boot ROM, etc.) all check out OK. We'll be able to start our lib_SDRAM testing next week and can report back in mid to late August to let folks know how it's going.

Thanks again for your expert advice and fast support!

- Tony
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

The rest of our board (supplies, power-on-reset, boot ROM, etc.) all check out OK. We'll be able to start our lib_SDRAM testing next week and can report back in mid to late August to let folks know how it's going.
That's good. Yes, please do share how you get on.
Thanks again for your expert advice and fast support!
You're welcome. I am aware that docs are sparse on timing, so we will focus on getting that I/O timing document out. I will raise the AN00170 issue again too.
Post Reply