• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 719 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.

TMS320C6748/46 EMIFA half word access order

st56139
Prodigy 180 points 
Is order of the two half word accesses on the16 bit wide asynchronous EMIFA interface defined when doing word (32 bit) reads and writes?
If so, what is it and where is it documented? 
An example of a 32 bit read or write would be a LDW or STW instruction, but I need to know if the order is consistent for all word accesses regardless of the source.

  • 0
    TI__Genius 14545 points

    st, 

    Are you trying to program the C674x in Assembly? I would recommend writting the program in C first, then use the output of the compiler to see which instructions the compilers uses for formatting. You can then reference the C674x DSP Instruction Set Reference Guide for exact information about both the ISA as well as the architecture.

    The Instruction Set Reference Guide also provides bit formatting for all the instructions as well as examples.

  • 0
    TI__Mastermind 41665 points

    st said:
    Is order of the two half word accesses on the16 bit wide asynchronous EMIFA interface defined when doing word (32 bit) reads and writes?

    I believe the access order will be consistent, though I have not seen this defined specifically anywhere in public documentation, in general this is not something I have seen to be an issue since most asynchronous devices respect the address signals and so the timing order does not matter.

    When doing a 32 bit access to the EMIFA it works just like accessing any other memory, assuming that the EMIFA is configured correctly for the memory connected to it. The EMIFA itself will take care of the address translation, so a 32 bit access from the CPU would become two 16 bit accesses on the EMIFA, in other words, to the CPU the EMIFA appears as a generic byte addressable memory. Since an instruction like LDW or STW requires the address being accessed to be on a 32bit word boundary (2 LSBs of address are 0), the access should happen in the same way every time.

    st said:
    If so, what is it and where is it documented?

    From what I have seen on prior EMIF implementations, you should see the addresses accessed in incrementing order. Though this does not cover the timing order you are looking for, the addressing of asynchronous memories to EMIFA is described in section 2.5.1 of the EMIFA manual.

  • 0 in reply to dabuan
    Prodigy 180 points

    Drew,

    I am trying to read a 32 bit value from the 16 bit emifa.  The read may be generated by c code or assembly code or DMA.  I expect to find statements like the following from spru266e made for the C671x on page 71:


    "The EMIF automatically performs packing and unpacking for word accesses to external memories of less
    than 32 bits. For a 32-bit write to an 8-bit memory, The EMIF automatically unpacks the data into bytes
    such that the bytes are written to byte address N, N + 1, N + 2, then N + 3. Likewise, for 32-bit reads from
    a 16-bit memory, the EMIF takes the data from halfword address N, then N + 1, packed into a 32-bit word,
    then written to its destination. The byte lane used depends on the endianness of the system as shown in
    Figure 3-3, Figure 3-4, and Figure 3-5."

    I really want to read values from a 32 bit register in an FPGA attached to EMIFA.  Imagine the register is a counter.  On an initial read I need to latch all 32 bits from the same FPGA clock cycle, and return 16 bits on the initial EMIFA read and the latched 16 bits on a subsequent EMIFA read.  For this the EMIF needs to automatically do the packing and unpacking, and I need to know the order of the addresses that will appear on EMIFA.  Will the order of byte addresses always be n*4, (n*4)+2 where n is an integer, or will it be (n*4)+2, n*4, or will it be unpredictable?

  • 0 in reply to st56139
    TI__Guru* 84110 points

    st,

    Bernie's answer and your response to Drew were sent at just about the same time. Bernie does address some of your concerns and you may be satisfied with that. If so, please come back and click Verify Answer on his post so we will know.

    Just in case you want to hear some more comments, I will add some opinions. If you verify any of this on your EVM or your own board, please reply back with what your results are.

    It is unfortunate that the C674x EMIFA User's Guide does not still have the detail that you are looking for. Many applications would find this to be helpful.

    Since I do not have immediate access to the test equipment that would prove this out, I will tell you what I strongly believe to be true.

    Addresses for multi-cycle accesses will always increment.

    The EMIF controller will take care of packing small EMIF-width accesses into large DSP-width accesses for reads or unpack large DSP-width accesses into small EMIF-width accesses for writes. The packing and unpacking will be done correctly for the endianess of the DSP, so the first byte or halfword may be the most-significant for big endian or the least-significant for little endian.

    One indirect source of evidence for this is the way the SDRAM bursts are done for synchronous mode. An SDRAM will always provide or accept data in a burst by incrementing the associated address internally. So this has to be the way that the EMIF packs and unpacks larger widths. This is not proof, for a variety of reasons, but it provides a logical and consistent pattern that might help your confidence in this answer.

    Accesses will always be predictable and consistent. If you do a 32-bit read or write to a 16-bit EMIFA, no other EMIFA access will slip in between the two 16-bit accesses.

    Here are some suggestions how you can protect yourself to make sure your application will work:

    1. If you are as conservative in your designs as I am, you will want to look at the bus cycles on a scope to see for yourself exactly how they do perform. If you do, please reply back to tell us what you saw. Scope pictures are always nice to see on the forum.

    2. Your FPGA's 32-bit counter location is a special case where a read operation causes something to happen, which is usually only done with a write operation. Anytime a read causes an action, special consideration is required, which is why you are concerned here. One way to make sure the 16-bit reads happen the way you want them to happen is to use 16-bit reads. You could write an assembly subroutine that uses LDH instructions or you could make a C struct or union that uses "volatile short" data types and then you do the reads in the order you want them to happen.

    Please let us know what progress you have made on this and what your results have been.

    Regards,
    RandyP