• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 101 subscribers
  • Views 282 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.

AM623: BCDMA / GPMC fragmentation

John Booth64
Prodigy 170 points

Part Number: AM623

We are attempting to leverage a BCDMA to transfer data between memory and a FPGA connected via a synchronous GPMC bus.  The transfers are occurring, but there is some strange size dependent fragmentation of GPMC accesses that doesn't make sense.  For example with a 16 bit data bus and the GPMC configured for an ATTACHEDDEVICEPAGE LENGTH of 32, I would expect to see only a single GPMC burst access for reads and writes less than or equal to 64 bytes.  Instead I see the behavior shown in the below table.  This behavior is the same for a read or write.

Bytes GPMC transactions
2 1
8 1
10 2
12 2
14 1
16 1
18 2
24 2
26 3
28 3
30 1
32 1
34 2
40 2
42 3
44 3
46 2
48 2
50 3
56 3
58 4
60 4
62 1
64 1

What is causing this fragmentation and is there anything can be done to prevent it?  The logic in the FPGA is trying to keep track of what is read, but the unpredictable behavior is making it difficult to design the logic to do so.

Thanks,

John

  • 0
    Prodigy 170 points

    After further study of the TRM I found this:

    12.4.3.4.9.5 System Burst vs External Device Burst Support
    The device system can issue the following requests to the GPMC:
    • Byte, 16-bit word, 32-bit word requests (byte-enable-controlled). This is always a single request from the
    interconnect point of view.
    • Incrementing fixed-length bursts of two, four, and eight words
    • Wrapped (critical word access first) fixed-length burst of two, four, or eight words

    This would mean the following would apply:

    Word Burst
    Sequence    		 Words Bytes GPMC transactions
    2 1 2 1
    4 4 8 1
    4+2 5 10 2
    4+2 6 12 2
    8 7 14 1
    8 8 16 1
    8+2 9 18 2
    8+2 12 24 2
    8+4+2 13 26 3
    8+4+2 14 28 3
    16 15 30 1
    16 16 32 1
    16+2 17 34 2
    16+2 20 40 2
    16+4+2 21 42 3
    16+4+2 22 44 3
    16+8 23 46 2
    16+8 24 48 2
    16+8+2 25 50 3
    16+8+2 28 56 3
    16+8+4+2 29 58 4
    16+8+4+2 30 60 4
    32 31 62 1
    32 32 64 1

    Please confirm this is indeed the case.  Are there any settings that can change this behavior?

    Thanks,

    John

  • 0 in reply to John Booth64
    TI__Guru 53568 points

    Hello John ,

    Problem Summary :

    When using BCDMA to transfer data to/from an FPGA via GPMC, the AM64x system interconnect decomposes transfers into fixed burst sizes (1, 2, 4, 8, 16, or 32 words). This causes unpredictable fragmentation of GPMC transactions, making FPGA-side tracking difficult.

    Root Cause :

    The AM64x interconnect (CBASS) can only issue specific burst sizes to GPMC. Transfer sizes that don't match these burst sizes are automatically split into multiple GPMC transactions. This is a hardware characteristic and cannot be changed through software configuration.

    Recommended Solution : 

    Use only transfer sizes that result in single GPMC transactions.

    Allowed Transfer Sizes (16-bit GPMC Data Bus)



    Sizes to Avoid:

    Any size not in the above table will result in multiple GPMC transactions. For example:
    - 10 bytes → 2 transactions
    - 24 bytes → 2 transactions
    - 50 bytes → 3 transactions

    Regards,

    Anil.

  • +1 in reply to Swargam Anil
    Prodigy 170 points

    Ok, so you have confirmed my chart is correct and there is no way around it.  While avoiding a certain size may be nice theoretically, it is not always possible.  Now that I know the behavior I can design the FPGA logic to account for it.  Since it's a power of 2 breakdown the design is relatively straight forward.

    Regards,

    John