• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 2260 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

A Question on C64x EMIF to SDRAM Interface on Custom Board, regarding EMIF Byte Enable Pin Assignments !

Bilal_BumbleBee
Intellectual 335 points

Hi,

I have a question regarding C64x EMIF interconnection with SDRAM.

Infact we had been using EVMDM642 for long time, when we finalized our algorithms of video compression, our company decided to make a custom board.

However I have mistakenly connected the Byte-Enable Pins BE[7:0] of EMIF with DQM[7:0] of SDRAM in wring order in my PCB.

The correct order of assignment is

BE[0]# of DSP ====> DQM[0]  of SDRAM for Data[7:0] 

BE[1]# of DSP ====> DQM[1] of SDRAM for Data[15:8]

BE[2]# of DSP ====> DQM[2] of SDRAM for Data[23:16]

BE[3]# of DSP ====> DQM[3] of SDRAM for Data[31:24]

BE[4]# of DSP ====> DQM[4] of SDRAM for Data[39:32]

BE[5]# of DSP ====> DQM[5] of SDRAM for Data[47:40]

BE[6]# of DSP ====> DQM[6] of SDRAM for Data[55:48]

BE[7]# of DSP ====> DQM[7] of SDRAM for Data[63:56]

It has been shown in the figure below

 

 

However I mistakenly connected it that way, i.e in incorrect sequence.

BE[0] of DSP =====> DQM[2] of SDRAM 

BE[1] of DSP =====> DQM[3] of SDRAM

BE[2] of DSP =====> DQM[1] of SDRAM

BE[3] of DSP =====> DQM[0] of SDRAM

BE[4] of DSP =====> DQM[7] of SDRAM

BE[5] of DSP =====> DQM[6] of SDRAM

BE[6] of DSP =====> DQM[5] of SDRAM

BE[7] of DSP =====> DQM[4] of SDRAM

it has been shown below.

 

Now I have received my custom boards and started using it, I used the seetings for 64 Bit EMIF in EMIF registers and related GEL settings.

I noticed that when I write data in 8-Bit (unsigned char), or 16-Bit (short), or 32-Bit (int) arrays, and simultaneously read it back, I get the correct data, i.e. no anomoly.

morever my small software test applications are correctly loading in the SDRAM and executing, even debug mode break points are correctly working.

Can anyone tell me why is it happening, shouldn't it be getting crashed ?

Is there any hidden (horrible) aspect that I had to face with this incorrect assignment scheme later on, or is it all fine with it ?

I want it to know coz my actual software and future software upgrades would be using extensive video processing with Cache Enabled.

Actually I put a lot of concentration on Signal Integrity Aspects of PCB Design, but forgot to take care of this pin assignment, my Bad Luck :-(

I will be very thankful for any reply, otherwise I will be getting fired from the company with "great" honour :-(

...

 Looking for any positive response,

Regards

 

 

  • 0
    TI__Guru* 84110 points

    The datasheet and EMIF User's Guide will provide specific details on the use of the BE[7:0] signals.

    As I recall, the BE[7:0] signals are only used during write operations. During reads, all of them would be active and the DSP would handle the byte separations internally.

    For writes, if you do any operation that writes 32-bit words or 64-bit double words, you will be safe because all of the four or eight BE signals would be active together and you would be lucky enough for them to work.

    For the byte and half-word writes, you made reference to the reason the problem is currently masked from causing problems for you: Cache Enabled. The cache controller will read long lines of data into a cache line and will then work with that internal copy until it needs to be flushed to SDRAM. Cache-based writes will being full words and not bytes or half-words.

    But if a byte or half-word write does not go through the cache controller, it will be more likely to cause a problem.

    It would not be practical for us to try to list out every possible scenario that could result in failures for your system. The easiest way to confirm that a failure can happen would be to turn off the cache and try your same tests. You could also try writing a single byte using DMA and see a similar failure.

    Please let us know if this explanation is clear, or if we need to word it better.

    Regards,
    RandyP

     

    If this does not answer your question, please tell us more. If it does, please click  Verify Answer  , below.

  • 0 in reply to RandyP
    Intellectual 335 points

    Thanks Randy for kind reply,

    Infact I tried it a couple of ways, here are some results

    1) I used a small Non-DSP BIOS based application (Cache Disabled), running from Internal RAM, it wrote data into the SDRAM (Full 32 Mega Bytes) and read back, all was correct.

    2) Then I changed the linker command file and made this small application(Cache Disabled) to run from SDRAM, and write some data in Internal RAM, again all was fine, no problem.

    3) Then I used a DSP-BIOS based application with Cache Enabled, to display an NTSC Frame from video port, that application had to run from SDRAM. The application did run but used to crash somewhere in between DMA Transfer, Cache Flush or some unknown place that I couldnot trace back. Some times it did display 3, or 4 frames on the video display screen while running in a while(1) loop, some times it displayed about 20 frames, however it got crashed after that. I was running this aplication in Debug Mode with No Optimization Selected. One important thing is that I accessed and updated each pixel of video frame as unsigned char type, just for checking purpose, would it be causing a problem ?, since I am performing byte wide access ! One important thing is that when application crashes, the emulator (XDS560 PCI) also used to get disconnected from the target, i.e. DSP, then I used to reconnect and reload the software into it.

     Secondly I can not disable cache at all coz my processing is very bulky, disabling the cache would simply kill the performance completely, anyway can u tell me how can I make the DSP always write full 4 bytes or 8 bytes, for example by using 4-Byte wide data types ?, and what about the instructions that DSP would be fetching from the SDRAM ?, would it always be fetching 4-Bytes or 8-Bytes ?

     Thank u so much for kind reply,

    So nice of you Randy,

    Regads, Bilal

  • 0 in reply to Bilal_BumbleBee
    TI__Guru* 84110 points

    Bilal,

    This is certainly obvious to you, but I want to make it clear as a design philosophy, I guess. If you can fully operate your application and verify everything works without crashing, then you have a good chance that you can leave the board mis-wired. Since you have found cases where it crashes, unless you can determine that those crashes are related to something else that can be fixed, you will have to fix the board.

    The only position I can offer from TI is that you need to fix the board layout.

    You should definitely fix one board, then when one of the others crashes you can try the same thing on the fixed board to see if it makes a difference.

    Bilal_BumbleBee said:
    can u tell me how can I make the DSP always write full 4 bytes or 8 bytes, for example by using 4-Byte wide data types ?

    If you never use any char or short data types, and if the library functions you access never use any char or short data types (which TI likely will not be able to guarantee for our libraries in general), then you would never do accesses other than 4- and 8-bytes. This seems impractical, and costly in the long run for you since it may turn out you have to fix the board later, anyway.

    Bilal_BumbleBee said:
    what about the instructions that DSP would be fetching from the SDRAM ?, would it always be fetching 4-Bytes or 8-Bytes ?

    Program fetches will always be multiples of 4 bytes.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Intellectual 335 points

    Thanks RandyP,

    You are absolutely right, infact it has to be the problem fixing on the PCB, I have located the positions on PCB where I can perform the rework, which seems possible, since the SDRAM I have use is in SMD Package, instead of BGA.

    I hope I will solve this problem, I will try this in a couple of days, thanks for helping me in giving more insight to the problem.

    One last and final question, is there any need to pull up or down the TDI, TDO, TMS, TCK, TRST# pins of JTAG Interface of DSP ?, since they are not internally pulled up or down as mentioned in the DM642 data sheet, what if I pull them up or down ?, Actually I have routed the JTAG signals of the DSP to external header very neatly, taking care of signal integrity in view, I took EVMDM642 JTAG circuitry as a reference, however I am getting failures sometimes while getting connected to my board through emulator in code composer studio. I hope I could be getting some hint about it.

    Thanks again for kind respose,

    Regards,

    Bilal

  • 0 in reply to Bilal_BumbleBee
    TI__Guru* 84110 points

    Bilal,

    Please keep us posted on this thread about your board progress and testing with the re-wiring.

    For you JTAG question, I would like to ask that you start a new thread so the title will match your question. This way, other knowledgeable people will recognize the need to respond to your question, and other users with similar questions will be more likely to read your new question and the answers you get.

    When you start the new thread, please let me know here since I might miss it otherwise. I can say now that there are several Hardware Design Guides and JTAG Design Guides that offer information on how to handle the JTAG signals. And I am surprised by your comments about the lack of internal pull-ups and pull-downs. We can pursue these questions and your connection problems on the new thread.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Intellectual 335 points

    Hi RandyP,

    Yes u r right, infact they had pull ups with TDI, TDO, TMS, TCK, and Pull Down with TRST#, I found this detail in SPRA584C (TMS320C6000 Board Design for JTAG (Rev. C) ), Infact I redisgned an existing board that our company had designed sometime ago having a virtex2 FPGA for parallel co-processing, I updated that design with some advanced functionality by keeping most of the part the same, including JTAG, however focused alot on signal integrity aspects and altered the SDRAM routing because of board space constraints, including adding more layers in PCB, the initial design of previous board was all working, 100% verified, and perfect, however I was getting some issues with my new design.

    Actually I am going to get another PCB of new design stuffed in a couple of days and will veirify if this happens in that PCB also, because I verified the JTAG circuitry and it was the same and routed neately, that made me download the code thousand of times, I will start with a new thread if I found it necessary and will also mention this to you,

    Thanks,

    Regards, Bilal