HELP ! Data Pause Problem —— 6713 EMIF interfacing the parallel DAC

My guess would be that you're not fully utilizing the internal bus bandwidth and so the EMIF is being starved. That will cause gaps in the data.  Even though you have 8-bit data you should set your element size for the EDMA to be 32-bit (make the number of elements 1/4 as many to keep the total transfer size equivalent).  You want the EDMA to fully utilize the internal buses to keep the EMIF "fed".  Also, you should make sure that you use the highest priority TC for the EDMA.

You might still need to be careful about cache requests to SDRAM as that would also use the highest priority TC by default.  I am pretty sure that can be mapped to a different TC though I don't have the doc in front of me right now.  Check the element size first and let's see how it goes.

Brad

I recommend moving to the DAC908 as a replacement for the DAC you are using.

The EMIF is designed to interface gluelessly with an SBSRAM device. An actual SBSRAM device would use the CEx, EA[n], SSADSn, SSOEn, and SSWEn signals to qualify the EMIF bus operation. This would avoid any data disruption due to these pauses that you have experienced.

Is the EMIF configured for 8-bit wide bus operations?

The EMIF is not designed for raw, continuous output of data on every clock cycle. But if you were to connect an SBSRAM device to the EMIF and did continuous writes to it as fast as possible, you would get a "nearly continuous" stream of data being written. Activity in the DSP and in the internal EMIF module may limit the full speed of the data sent to the EMIF.

xiaoer han said:

I find every 16 dots, there is a pause(one ECLKOUT length ) in data[7]

What exactly do you mean by "dots"?

xiaoer han said:

I also observe the SSWE# and find the signal is exactly invalid at the pause.

By "invalid" do you mean that SSWE# goes high? Or does it go to an invalid or floating level?

My guess is that this pause is caused by either EDMA limitation or some internal DSP resource constraint. Some things to try to see if you can affect the rate of the pause:

1. Use the DSP memcpy() function to write the data. What different results do you get? It might be slower than the EDMA method, but it might not have the pauses.
2. Use different EDMA Queues or PRI settings. The different queues may have different default burst sizes and this could be the cause.

xiaoer han said:

there is another big pause ( 10 ECLKOUT Length) in the data[7]’s waveform

My best guess on this longer pause is that it may be related to the refresh rate of the SDRAM interface. Try writing 0 to the RFEN bit in the SDCTL register, even though you are not using SDRAM in any EMIF space.

xiaoer han said:

How can I interface the EMIF to parallel DAC ?   Is  The interface I ‘m using  correct?

Strictly speaking, the way you are using the EMIF is not correct for the DAC. The DAC will clock in the contents of the databus on every clock cycle, and there are clock cycles when you are not driving valid data. During the time between the end of one burst of 2000 "dots" and the beginning of the next burst, the DAC is still latching the databus values, which might not always retain the last value written.

Other users on the E2E forum have used the asynchronous mode of the EMIF and used the AWEn signal as the clock. This runs no better than 1/3 the rate that you get with the SBSRAM mode, but it is simple and clean and qualifies the data by using the AWEn signal as the clock.

To get the higher speed of the SBSRAM while avoiding latching the databus when there is no valid data being driven, you could add a small amount of logic to the board to gate the ECLKOUT signal with the SSWEn signal or a better method would be to synchronously gate the clock based on the value of SSWEn. Proper consideration of the propagation delays will be required to make sure you meet all of the timing requirements for the DSP and the DAC.

Since you seem to have a defined pause in the DAC data at the end of the 2000-sample burst, does your system require the removal of the short and long pauses you have described here? Or are you just curious as to why they are there?

hi，brad ,thank you very much for replying

In fact , I have set my element size for the EDMA to be 32-bit according to the doc spraa03 (TMS320C671x/TMS320C621x EDMA Performance Data) ,but the pause( one ELKCOUT) still exists.

Brad Griffis said:

Also, you should make sure that you use the highest priority TC for the EDMA.

 

what do you mean by " the highest priority TC for the EDMA" ?   to set  Priority levels for EDMA events ( OPT ) to be HIGH?

Brad Griffis said:

 I am pretty sure that can be mapped to a different TC though I don't have the doc in front of me right now.  

Also,I 'm not sure how to  "mapped to a different TC" ,  would you please explain it more ?

EDMA configuration I have used is as follows:

EDMA_Config cfgEdmaPing = { 
  EDMA_OPT_RMK(          /* Making Options parameter register - EDMA_OPT    */
 
   EDMA_OPT_PRI_HIGH,    /* Priority levels for EDMA events:-
                             EDMA_OPT_PRI_LOW  - Low priority EDMA transfer
                             EDMA_OPT_PRI_HIGH - High priority EDMA transfer*/
  
   EDMA_OPT_ESIZE_32BIT,/* Element size :-
                             EDMA_OPT_ESIZE_32BIT - 32 bit word
                             EDMA_OPT_ESIZE_16BIT - 16 bit word
                             EDMA_OPT_ESIZE_8BIT  -  8 bit word              */
  
   EDMA_OPT_2DS_NO,     /* Source dimension :-
                             EDMA_OPT_2DS_NO  - 1-dimensional source   
                             EDMA_OPT_2DS_YES - 2-dimensional source         */ 
  
   EDMA_OPT_SUM_INC,   /* Source address update mode :-          
                             EDMA_OPT_SUM_NONE - Fixed address mode
                             EDMA_OPT_SUM_INC  - Increment address mode
                             EDMA_OPT_SUM_DEC  - Decrement address mode
                             EDMA_OPT_SUM_IDX  - Address modified by element
                                                 index or frame Index        */
    EDMA_OPT_2DD_NO,     /* Destination dimension :- 
                             EDMA_OPT_2DD_NO   - 1-dimensional source           
                             EDMA_OPT_2DD_YES  - 2-dimensional source        */
  
    EDMA_OPT_DUM_NONE,    /* Destination address update mode :-                      
                             EDMA_OPT_DUM_NONE - Fixed address mode           
                             EDMA_OPT_DUM_INC  - Increment address mode       
                             EDMA_OPT_DUM_DEC  - Decrement address mode       
                             EDMA_OPT_DUM_IDX  - Address modified by element  
                                                 index or frame Index        */
   
    EDMA_OPT_TCINT_YES,  /* Transfer complete interrupt :-
                             EDMA_OPT_TCINT_NO  - Indication disabled     
                             EDMA_OPT_TCINT_YES - Indication enabled         */ 
   
    EDMA_OPT_TCC_OF(TCCINTNUM),/* Transfer complete code                     */
   
    EDMA_OPT_LINK_YES,   /* Linking of event parameters
                             EDMA_OPT_LINK_NO   -  Disabled
                             EDMA_OPT_LINK_YES  -  Enabled                   */   
   
    EDMA_OPT_FS_YES      /* Frame synchronization
                             EDMA_OPT_FS_NO  - Channel is element/array
                                                synchronized
                             EDMA_OPT_FS_YES -  Channel is frame synchronized*/
  ),
  EDMA_SRC_OF(ping),/* Source address register
                               &ping_data    - source address                */
 
  EDMA_CNT_OF(BUFF_SZ),   /* Transfer count parameter     
                                BUFF_SZ      - buffer sizes in # of ints     */      
  EDMA_DST_OF(SBSRAM_ADDRESS),      /* Destination address parameter
                                 ping - destination address                  */
 
  EDMA_IDX_OF(0x00000004),/* Index parameter                                 */
                          //Don't care here
  EDMA_RLD_OF(0x00000000) /* Count reload/link parameter                     */

};                          

xiaoer han

hi,RandyP. 

I really appreciate  your suggestions . Now , the big pause (10 ECLKOUT randomly) has disappeared since I disabled the the RFEN bit in the SDCTL register of EMIF as you say, but the little pause (1 ECLKOUT) still exists.

RandyP said:

I find every 16 dots, there is a pause(one ECLKOUT length ) in data[7]

What exactly do you mean by "dots"?[/quote]

well,  I mean "elements" actually,and also the element size for the EDMA  has been set to be 32-bit.

RandyP said:

I also observe the SSWE# and find the signal is exactly invalid at the pause.

By "invalid" do you mean that SSWE# goes high? Or does it go to an invalid or floating level?[/quote] 

I find  SSWE# goes high from the oscilloscope.

Now that the big pause problem has been settled , I 'm wondering how to remove the pause(1 ECLKOUT).

RandyP said:

My guess is that this pause is caused by either EDMA limitation or some internal DSP resource constraint. Some things to try to see if you can affect the rate of the pause:

1. Use the DSP memcpy() function to write the data. What different results do you get? It might be slower than the EDMA method, but it might not have the pauses.

 I use CPU to move the data from L2RAM to CE2 space directly ( without EDMA ), and this time there is no pause. However , it's too slow (I wish to send one element at the rate of 75MHZ,and it's only  about 8 MHZ for this method )

RandyP said:

Use different EDMA Queues or PRI settings. The different queues may have different default burst sizes and this could be the cause

2. what do you mean by " different EDMA Queues"  . I have set High priority EDMA transfer ,and it doesn't work .

Thank you  for any help : )

xiaoer han said:

I use CPU to move the data from L2RAM to CE2 space directly ( without EDMA )

Did you write your own for-loop for the copy, or did you use memcpy()? 8 MHz seems very slow for the library function, so I wanted to confirm this with you.

How wide have you configured the EMIF CE2 space?

What is the value of BUFF_SZ?

My mistake on the EDMA queues. You are already using the highest priority possible.

I still have the guess that this 1 cycle pause is either related to the way the SBSRAM interface is implemented in the DSP or the way the EDMA implements long transfers. This pause may be unavoidable, but we can still hope someone has an idea to help you.

RandyP said:

Did you write your own for-loop for the copy, or did you use memcpy()?

I use my own loop for the copy.

RandyP said:

How wide have you configured the EMIF CE2 space?

I config the CE2 space to be  SBSRAM32

RandyP said:

What is the value of BUFF_SZ?

BUFF_SZ is a constant value which is more than 16 .

RandyP said:

I still have the guess that this 1 cycle pause is either related to the way the SBSRAM interface is implemented in the DSP or the way the EDMA implements long transfers. This pause may be unavoidable, but we can still hope someone has an idea to help you.

 This pause are periodic .I'm wondering whether there is a method to  make the period (every 16 elements) larger  if this pause is unavoidable?

Please try memcpy() and let us know the results. Can you afford the CPU time if a version of memcpy() could meet your needs?

xiaoer han said:

 I am pretty sure that can be mapped to a different TC though I don't have the doc in front of me right now.