SDRAM interfaced to EMIFB interface

Hi,

I have a question. Is there a possible way to interface two 2MB sdram to a single emifb interface ?

Yes, EMIFB will support 2 SDRAM devices in 16 bit mode.

Please refer chapter 5.12.2  in OMAPL137 data manual.

http://www.ti.com.cn/general/cn/docs/lit/getliterature.tsp?genericPartNumber=omap-l137&fileType=pdf

Sorry, I forgot to mention that i am using omapl137-ht. The emifb bus is 16-bit only. 

NOW ??

Hi.

The emifb bus is 16-bit only.

In my understanding,

It support 32 bit too

I'm not able to see any difference in EMIFB peripheral other than package difference.

http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=omapl137-ht&fileType=pdf

For HT devices,

Better to post your queries to the below forum.

http://e2e.ti.com/support/applications/high_reliability/default.aspx

Oh, the EMIFB on that chip only supports 16bit data bus. You can see that on pg7 here 

http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=omapl137-ht&fileType=pdf

But the Figure 5-23 on page 85 is misleading. Please throw some light here if i am wrong. 

Also the HT forums are almost dead forums. I don't get replies for weeks. 

Thanks, 

AQ

Hi,

Yes, You are correct,

Some of the pages (block diagram, interface block ) are need to get update.

Okay, I will discuss with our experts & come back to you soon.

Hi,

Let me move this post to High reliability forum to be better addressed for high temperature products.

Thanks & regards,

Sivaraj K

The OMAPL137 PTP device has reduced pinout, and EMIFB is only 16bit.

Some of the EMIF chapter covers features of full 32 bit EMIFB, but are not available for reduced pinout.

Regards,

Wade

Hi Wade, 

Thanks for the reply but, did you just say "we made a mistake, we will correct it" ????

I think no harm in accepting the fact that the datasheet has incorrect information which should be removed in later revisions. 

And apart from that fact, can you reply to my actual question ? The question here was, 

"Is it possible in any way to connect two 16bit sdram to this 16bit emifb interface ?" 

Thanks, 

AQ

Sorry for delay.

I do not consider this as necessarily an error.  We may introduce additional full pinout package, that would require this information.

I am not certain there is solution for multiple memories.

What memories are you considering?   Are you using all address pins?

Regards,

Wade

Hi Wade, 

I think you are not very much familiar with TI offerings. There is already OMAPL137 offering 32bit wide emifb bus. This portion is essentially taken from the datasheet and tailored to 16-bit bus width.

If you don't consider it an error then it proves my point that TI is really lethargic when it comes to documentation. Can you explain to me why you need a 32bit bus figures in datasheet of 16bit bus processor ? (Mind that i am not talking about Technical reference manual but datasheet. You guys very actively use the phrase "refer to datasheet" in TRF. If datasheets are not tailored to the processor, then what's the point ?? )

Anyways, I am sure you won't accept that, so coming to my problem. I need to interface two IS42S16100E to omapl137-ht. Is that possible ??

Thanks,

AQ 

Understood there is a 32bit offering.  This is for commercial product, not HT.

I am referring to potential future HT offering in the HT datasheet.

I am going to check with some of the product experts on suggestions for connecting 2 sdrams to the reduced pinout emifb.

Regards,

Wade

Hi Wade, 

I had been waiting for a while for a reply. Anything on this one yet ??

I was thinking, can i configure my emifb for a 4 bank operation and interface the two chips on the same control and datalines. This should make it work, right ??

Would appreciate a quick reply. 

Thanks, 

AQ

I am awaiting additional feedback on using with shared lines.  So far there is some concern on signal integrity.  I do not have feedback saying this has been done and proven before.

If I get additional feedback I will provide it.

Regards,

Wade

Thanks Wade for the reply. 

Please treat it with a sense of urgency. Designs cannot wait for months to be resolved. Apart from signal integrity, i am more worried on the emifb controller. These controllers can be configured in certain ways only. I am looking to configure it to work with 4 banks instead of 2. This to me would mean that BA0 and BA1 lines would be able to select between two external SDRAM while CS, CLK and all the control lines would be simultaneously routed to both ICs. 

Do you foresee any issues like in reading, writing, refresh cycle etc ??

Thanks,

AQ 

AQ,

I am searching for any experience and history doing this.  So far, I have not found any.

My initial thought was to use A12 to logically select each CS.  Unfortunately this has same questions as your method.  Ie, will refresh be impacted or other concerns.

I will update if I can get firm answers on any of the above.   Unfortunately this is a little obscure and design teams that had the most experience with this device/controller are not available.

Regards,

Wade

Wade, 

I am thinking that BA0, BA1 and CS should pass through some glue logic. Separate control lines (BA0, BA1 and CS) would be routed from fpga to both individual chips.

We would then configure emifb to 4-bank operation. Based on signals on BA0 and BA1, we would issue the BA and CS signals to the IC. 

Would this solve the problem ?

When 

AQ, this is a non-standard configuration.

I have requested feedback from those familiar with EMIFB, but as of this time no one has replied with information indicating this is feasible.

Does SDRAM chosen have desirable high temp properties?  Datasheet does not imply this.

Otherwise, it would be beneficial to choose different SDRAM that would not require this non-standard configuration.

If I do get feedback with ideas on how to make this work with sharing banks (or other solution), I will let you know.

Regards,

Wade

AQ,

I was able to get some inputs from some of the support team that worked directly with the L137.

Unfortunately, there is no experience doing what you are trying to validate.  

That is not saying it will not work, just that we do have not history or experience to validate this.

Regards,

Wade

So then what's your suggestion here ?