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.

C64x - EMIF-B - overhead

Hello,

I make measurements of the time necessary to access (write mode) (by CPU) to an asynchronous memory mapped on a C6414T and the results I obtain are not consistent with theorical results ( my results are three time longer).

The used configuration is as follows :
-    CPU frequency=300MHz, EMIF-B ECLKOUT1=75MHz
-    EMIF-B space CE0 configured as asynchronous (16 bits wide)
-    WRSETUP+WRSTRB+WRHLD = 3 cycles (at BECLKOUT1 clock rate)
-    TA = 0
-    The test program is in internal DSP memory
-    All maskable interrupts are masked (GIE=0) during the test
-    Compiler options : -O2 -mv6400


The used test program is as follows :


  UWord16 i;

  for(i=0;i<1000;i++)
  {
      *((volatile UWord16*)0x60000000) = i;
  }


The measured time to perform 1000 write accesses is : 120us. I expected a necessary time of : 40us.

Do you have any explanation for these results?
Is there internal latencies (from CPU to EMIF) in addition of hardware programed latencies (WRSETUP+WRSTRB+WRHLD) ?


Thanks for your help.

Corentin LE HUBY

  • Here are additional informations about the previous post : a screenshot of the CE0/ - EMIFB signal.

    I get a screenshot of the CE0/-EMIFB signal. This screenshot shows that between each write access (CE0/ signal active : 40ns), CE0/ becomes inactive during 80ns.

     

    I don't understand the reason of these 80ns of inactivity between each 16 bits Write access. Do you have any explanation for this?

     Thank you in advance for your help.

     

    Corentin LE HUBY

  • Hi Corentin,

    Asynchronous memories usually have a 'Write Cycle Time' parameter in the datasheet which is the turnaround time between two consecutive writes. If the memory is not ready to accept the next write, it holds off the controller from sending it the data - which in turns stalls the CPU from sending it the next data value (The system interconnect bridge has FIFOs where CPU writes may be queued temporarily).

    Most probably you are seeing this delay between two consecutive writes - you can verify this by checking the memory datasheet.

    Regards,

    Sunil Kamath