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.

question about the normal and abnormal EMIF_nWE signals when accessing CS2 and CS3 external memory space

Other Parts Discussed in Thread: HALCOGEN, TMS570LS3137

    there are some dissusions about the abnormal EMIF_nWE signal when access the external asynchronous memeory space,there are three EMIF_nWE pulse,when write once.the way to solve the problem is adding the _MPU_init and _MPU_enable funtions call.
   in fact i solve part of my problem by this way, in my design cs2 and CS3 parts of memory space are used as two enthernet controllers with fifo memory structure, in the halcogen, MPU part of memory region configuration is:size 64Mb start address 0X60000000 and end address 0x6FFFFFFF, the type is stronglyordered_shareable, when access the CS2 part whose start address is 0X60000000, by the above way that TI expert suggested the EMIF_nWE signal becomes normal, while when access the CS3 part memory whose start address is 0x64000000, the EMIF_nWE signal is still abnormal. if change the MPU part of memory region configuration to:size 64Mb start address 0X64000000 and end address 0x6FFFFFFF,the type is stronglyordered_shareable, when access the CS2 part whose start address is 0X60000000, the EMIF_nWE signal becomes abnormal, while when access the CS3 part whose start address is 0x64000000, the EMIF_nWE signal becomes normal.
so how can i use the total 48Mb memory of cs2 cs3 cs4 part, not one part?

  • Hello:

    I'll direct your question to one of our experts. We'll get back to you soon.

    Regards.

  • Hello,

    Please check your Cortex-R4 MPU setting for the EMIF region. Make sure that the region size is 64 MB as expected.


    Thanks and regards,

    Zhaohong
  • thanks for reply。

    I am sure the  region size is set as 64 MB,while the end address is set as 0x63FFFFFF or 0x6FFFFFFF there is no differece in the MPU.c file generated by Halcogen. 

    is this related to my problem?

     

     

  • Do you mean the "sys_mpu.asm" file? It is the source file Halcogen creates to MPU configuration. If it does not change with change in region size as you said, there must be a bug in Halcogen. Would you please confirm?

    Thanks and regards,

    Zhaohong
  • when i  change the  end address (0x63FFFFFF  or 0x6FFFFFFF)there is no difference in the "sys_mpu.asm" file?  when the region siz e changed  there is difference in "sys_mpu.asm" file.

    the problem is solved by  xiang zhang ,  ti FAE in bejing office. change the size from 64MB to 256MB.

    another issue i want to trouble is that the write cycle of EMIF, i set the EMIF in the holcogen shown below. when i do the continue write (16bit),the write cycle is 400ns, the low level part is 80ns as is set , while the high level part is 320ns,is it normal, thanks very much!

  • What you observed is normal,
    For each LDR on a periperal, there will be a 12 VCLK cycles internal delay. CPU will take the EMIF bus time plus 12VCLK to complete a LDR on EMIF.
    If the periperal space is configured as "strongly ordered", CPU will wait for the writes to complete at peripheral. There will also be a a 12 VCLK cycles internal delay. This is what you observed.
    If the If the periperal space is configured as "device", CPU write to an internal store buffer and move on to the next instruction. Then the the data will be drained to EMIF. If you are doing consecutive writes, you should not see the long delay between each WE pulses.

    Thanks and regards,

    Zhaohong
  • thanks for your kind explanation。in tms570LS3137 datasheet the shortest EMIF asynchronous write cycles can be less than 100ns。i try to set the periperal space as "device-shareable", the consecutive writes cycles is still 400ns,what should i do to make the write cycle down to about 150ns?

     another issue i wonder if it related to the above problem, i do a test of het port  (the code show below),the level transition cycle is 200ns, is it normal?

    hetREG1->DOUT=(uint32)((uint32)1U << 19U) ;

    hetREG1->DOUT=(uint32)((uint32)0U << 19U) ;

    hetREG1->DOUT=(uint32)((uint32)1U << 19U) ;

    hetREG1->DOUT=(uint32)((uint32)0U << 19U) ;

    i am waiting for your suggestion, because the fist issue is much more important for me,if the second problem is not related to the first, give me some suggestion about the EMIF write cycle problem is ok. waiting for your reply.

  • Please first change your MPU setting to "device-nonsharable". For most apllications, people are more concerned about the CPU time spent in writing to EMIF. You can use RTI or PMU to measure it.

    For the HET register writes, you need to take a look at the disassembly window to see what assembly instruction is actually used. Are you sure that the HET register space is configured as device?

    Thanks and regards,

    Zhaohong
  • thanks zhaohong for timely reply and kind explanation. i will try it now.

  • thanks zhaohong for reply.
    as you suggested i set the mpu as "device-nonsharable". when is do the consenive writes(16bit),i watch the EMIF_nWE signal in oscilloscope, the delay between each WE plus is also 320ns, the WE cycle is 400ns(2.5MHZ). because the EMIF is so slow, the bandpass of the ENthernet controller connecting the EMIF is much limited( about only 10Mbps).
    while the SPNS162B –APRIL 2012–REVISED JULY 2013 (TMS570ls3137 datasheet) page 84, the Table 4-29. EMIF Asynchronous Memory Switching Characteristics(1)(2)(3) (continued),EMIF read cycle time (EW = 0) max is (RS+RST+RH)*E+3 ns. if it is true , the EMIF_nOE cycle (the EMIF_nWE) is less than 150ns as set in holcogen.
    the measured WE cycle signal in oscilloscope includes the CPU instructions process time and the EMIF related peripheral process time. the consenive writes by C code shown below:
    for (idx = 0; idx < len; idx+=2)
    (*((vuint16*)Sn_TX_FIFOR(s))) = *((uint16*)(buf+idx));
    the Disassemble code is shown below:
    343 for (idx = 0; idx < len; idx+=2)
    00006018: E15C0000 CMP R12, R0
    0000601c: 9A00000D BLS $C$L34
    344 (*((vuint16*)Sn_TX_FIFOR(s))) = *((uint16*)(buf+idx));
    $C$L33:
    00006020: E59DC004 LDR R12, [R13, #4]
    00006024: E59D0018 LDR R0, [R13, #24]
    00006028: E5DD1000 LDRB R1, [R13]
    0000602c: E59F23B8 LDR R2, $C$CON9
    00006030: E1A01301 MOV R1, R1, LSL #6
    00006034: E190C0BC LDRH R12, [R0, R12]
    00006038: E182C0B1 STRH R12, [R2, R1]
    the TMS570ls3137 of 180MHZ is about 280MIPS,the CPU instructions process time is much less than 320ns,so much of the time cost is the EMIF related peripheral process time. if the EMIF read cycle time (EW = 0) max is (RS+RST+RH)*E+3 ns is right, where is wrong in my test ? or how can i decrease the EMIF read cycle time, because the low level(effective level)is the smallest, while the high leve time(idle time) is as much as 320ns,how can i make this time shorter? waiting for your suggestion, thanks very much!
  • I have explained to you earlier that a EMIF read cycle is the EMIF bus time ((RS+RST+RH)*E+3 ) plus 12 VCLK cycles internal delay.

    Thanks and regards,

    Zhaohong
  • thanks zhaohong. youdid give me this suggestion earlier, but it can not explain my problem totally, i will show the caculation detail below.  
    the EMIF read cycle measured in the oscilloscope is 400ns,low level 80ns,high level 320ns.
    E(EMIF clk for CS2 90Mhz) is 11ns, RS is set as 1, RST is set as 6, RH is set as 0, so the low level should be 77ns, the same as measured, the high level should be 12*11(VCLK 90Mhz) ,132ns, so the EMIF read cycle should be 210ns, not 400ns. besides the cpu instruction process should  be much less than 190ns, what costs the 190ns,could you please help me the find it and giveme some suggestion to kill this time cost, thanks very much, waiting for your suggetion.
    jianlei

  • To accurately measure EMIF access time alone , I would suggest using consecutive LDRs or STRs in assembly code.  LDR is a 32 bit read and you should see 2 reads on a 16 bit EMIF. The timing will be different from two LDRH reads.  I am attaching some assembly code we used in the past for your reference.

    5775.cpu_rw.asm

    Thanks and regards,

    Zhaohong

  • thanks zhaohong for reply.

    the Enthernet contrlller connectting the EMIF CS2 has a FIFO memory structure, and its data with is 16 bit, which limits the use of  LDR process of 32 bit.

    if i use the 16bit write and read, what can i do to decrease the read and write cycle, thanks very much,waiting for your suggestion. 

  • I guess that we need to confirm the EMIF access time first. You can use STM and LDM instructions for faster access if you have a lot of data to transfer.

    Thanks and regards,

    Zhaohong