• State TI Thinks Resolved
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 71 views
  • Users 0 members are here
Support feedback
Options
Options
Related

DRA78XEVM: Hardware trace reports MFENCE taking thousands of cycles

Salvatore Lionetti
Prodigy 100 points
Part Number: DRA78XEVM
Other Parts Discussed in Thread: SYSBIOS

Tool/software:

Hi,

I'm on DSP1 collecting hardware trace flow, with PC and Cycle time.

What's the reason of these multiples wait?

Why there are tracing instructions left in?

I'm using:

SYSBIOS bios_6_83_00_18

xdctools_3_61_02_27_core

ccs1040

Thanks

  • 0
    TI__Expert 4190 points

    Hi,

    MFENCE (memory fence) : This instruction will stall until the completion of all the CPU-triggered memory transactions (i.e, write/read, DMA and cache ops).

    In https://www.ti.com/lit/ug/sprugh7/sprugh7.pdf?, section 3.8.12.1 you can see more details on MFENCE instructions.

    And In bios package , see the code located at "bios_6_83_00_18\packages\ti\sysbios\family\c66\Cache.c"

    The link to silicon errata document "Advisory 27 Single MFENCE Issue" --> https://www.ti.com/lit/er/sprz335h/sprz335h.pdf? is attached here for your reference.

    Salvatore Lionetti said:
    What's the reason of these multiples wait?

    You see multiple waits because the SYS/BIOS Cache_wait() function is a loop that repeatedly calls MFENCE until the cache write-back/invalidate is really done. (Please refer the above code snippet.)

    Regards,

    Betsy Varughese

  • 0 in reply to Betsy Varughese
    Prodigy 100 points

    Hi Varughese,

    Thanks for the points you highlighted.

    For the MFENCE multiple wait times, I see 4 or more calls but I cannot see any loop. The disassembly just show two consecutive calls. I was thinking to a different situation, where a transaction is finished and another one just  started. This condition seems to be traced by the counter "busy_on_resp_link" in hardware trace, but this is pure speculation.

    Still the MARK0 question remains.

    Just in case these words will be indexed, the MARK0 left in the code is probably the reason why in the system hardware tracing you find a so called "MFENCE Workaround" entry by default: it's nothing magical, just filter out Mark0 because otherwise would flood the small ETB. (see below)

    Thanks

  • 0 in reply to Salvatore Lionetti
    TI__Expert 4190 points

    Hi Salvatore Lionetti,

    Yes, The MFENCE is basically blocking until the memory subsystem finishes what’s pending. for example, If there are any pending cache write-backs, L2/L3 memory transactions queued, all these case the MFENCE will stall until all complete. 

    Salvatore Lionetti said:

    Why there are tracing instructions left in?

    They’re used for debugging/traceability and the “MFENCE workaround” you see in trace tools is really just a MARK0 filter. (sorry I missed the second question in the previous reply)

    Regards,

    Betsy Varughese