• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 376 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.

HTU Access Time to SRAM

Anthony F. Seely
Guru 68950 points


How many cycles does it take from HTU request being triggered from the NHET, to data being available in NHET memory.

Specifically, I need to know this for N 32-bit elements, N=1,2,6,12.

Would expect to see this information in the datasheet or TRM of the TMS570 device, but can't find it.  

 

  • 0
    TI__Mastermind 49120 points

    Anthony,

    The actual number of cycles it takes for the HTU to move data between the NHET RAM and the CPU RAM is dependent on the overall activity in the interconnect. We will get the number of cycles it takes for this transfer when the HTU is the only master on the interconnect. We will get back to you as soon as this information is available and also include it in the next update to the TRM.

  • 0 in reply to Sunil Oak
    Intellectual 600 points

    Any updates on this? As far as I can see, it has not appeared in the TRM as of yet.

  • 0 in reply to Tim Mulder
    TI__Guru 68950 points
    Tim,

    No data on this as far as I'm aware. There isn't a signal from HTU back to the HET saying that the transfer is complete, so I'm not sure how we'd measure it. By design it should be in the low tens of VCLK2 cycles, so on the order of 100-200ns (to CPU RAM). But you could create a pathological case where the CPU is using it's TCM RAM heavily blocking out the external DMAs (not totally, but I think the CPU gets 15/16ths of the bandwidth by design of the Cortex R4.. We'd need to check this fact .. but it's something on that scale. So if you take the worst case like this times 12 transfers then the # could get big. And of course if you target a different memory with the HTU (like async EMIF) then it would be a much larger # as well.

    Since the HET really doesn't get a handshake from the HTU saying data has been updated, you probably need to embed a sequence counter along with your data as part of what the HET transfers. So let's say the data consists of 3 words, you'd add a 4th word that is incremented by the CPU for each new data-set and the HET would need to check this 4th word for 'increment' during each loop. The HET program would normally only check this data once per loop and so the result of a bench test that triggered an HTU transfer every loop and toggled a pin when the transfer was detected complete would *probably* be that the pin toggles once per loop ... assuming a loop resolution period of 500ns or 1us.