AN00170 "Using the SDRAM library"

If you have a simple question and just want an answer.
User avatar
aneves
Experienced Member
Posts: 93
Joined: Wed Sep 16, 2015 2:38 pm

Post by aneves »

OK, I figured it out.

Like I've eluded to before, my test bed reads USB data in bytes and writes to SDRAM. Later, a request to read that data from SDRAM is received via USB and so the firmware reads the data in iterations and ships it off to the host in USB transfers.

I have helper functions which deal with converting the data buffer in bytes to a data buffer of words which the SDRAM API wants. However, I was not following suite with the address. I was merely adding the last address accessed with the size of the next USB buffer. But this is wrong because the USB buffer size is the size in bytes and not words. So what I was really doing was filling the SDRAM sparsely hitting the capacity of the chip earlier than expected which cause it to wrap around (as it should).

I've modified my code to calculate the address properly and now things are working as they should!!

Many thanks for your help and patience!


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

Post by infiniteimprobability »

I've modified my code to calculate the address properly and now things are working as they should!!
Cool - glad it's identified. I must admit, If I were to write this IP I'd probably use a byte address which is more normal and what people would expect. I think the docs could be clearer about it being long word addressed.
Many thanks for your help and patience!
That's OK - there was definitely an issue with inconsistent docs and code causing the bank addressing issue. I know how it is - a single bug can make you lose confidence in piece of 3rd party code.

Anyhow, sounds like it's ended well and good luck with the rest of your app!
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

It's an old thread but for anyone landing here I wanted to make you aware that there is an updated lib_sdram version (3.2.0) with a lot of fixes.

* Automatic setting of port delays for a given clock divider
* Fixes to initialization
* Improved read and write latency
* Documentaion and API fixes
* Support for new xCORE-200 Slice Kit in examples

https://www.xmos.com/support/libraries/lib_sdram

It means that I/O timing now has much more margin and the documentation is very much clearer about the addressing using long words rather than bytes.
We have tested it (in addition to ISSI) against more recent SDRAMs like Alliance AS4C16M16SA 256Mbit which should offer lower cost and better long term supply option.
User avatar
aneves
Experienced Member
Posts: 93
Joined: Wed Sep 16, 2015 2:38 pm

Post by aneves »

Cool!

Some quick questions:

1.) Is lib_sdram still maxed out at 256Mb?
2.) I noticed that after updating that I still had to change line 224 from this:

Code: Select all

#define BANK_SHIFT          (13)
to this:

Code: Select all

#define BANK_SHIFT          (14)
Is that just because of our specific application?
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

1.) Is lib_sdram still maxed out at 256Mb?
It is but it's a very easy change to support 512Mb - https://github.com/xmos/lib_sdram/issues/20
2.) I noticed that after updating that I still had to change line 224 from this:
Code: Select all
#define BANK_SHIFT (13)

to this:
Code: Select all
#define BANK_SHIFT (14)


Is that just because of our specific application?
It must be - all of the SDRAMs we looked at need a BANK_SHIFT of 13.

Thanks by the way for your feedback. You may see some of your comments reflected in the closed issue list - https://github.com/xmos/lib_sdram/issue ... s%3Aclosed
Post Reply