• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 143 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.

MSPM0G1518: HW CRC accelerator performance difference between MSPM0G3507 and MSPM0G1518

Pavlo Soltys
Prodigy 30 points

Part Number: MSPM0G1518
Other Parts Discussed in Thread: MSPM0G3507,

Greetings,

During migration from MSPM0G3507 to MSPM0G1518 we noted that the CRC32 computation time in our application increased twofold(from 2.2ms that we expected to 4.2ms). The computation is done by HW CRC unit in CRC32 mode that goes over the range of our application data. At the moment of CRC computation, the device is configured as follows:

  • MCLK frequency(clocks the core and PD1 peripherals amongst which is HW CRC): 80 MHz sourced from SYSPLL
  • HW CRC unit in CRC32 mode with CRC32-ISO3309(default) polynomial with direct input bit order and endianness set to BIG
  • Data is fed to the CRC unit in 32-bit chunks
  • The size of the data range over which CRC is calculated didn't change much during migration

On our side we checked that CRC input is 4-byte aligned and additionally verified the MCLK frequency by using FCC, and it confirmed that the PD1 was indeed running at full 80 MHz at the time of computation.

Also it was noted that G1518 uses a more advanced CRC-P accelerator while the G3507 uses a regular CRC unit, and after checking the TRM(CRC and CRC-P unit comparison table in chapter 14.1. "CRC Overview"), it seems that some performance differences are to be expected between these two types of accelerators as CRC-P units don't allow for wait-state-free computation.

We would like to get a confirmation that the performance degradation that we observed in our use case is actually expected between CRC and CRC-P units.

BR,

Pavlo

  • 0
    TI__Expert 8465 points

    Hi Pavlo,

    Yes, the performance reduction is expected.

    The MSPM0G3507 CRC peripheral calculates a new CRC result in a single cycle for each input write. The MSPM0G1518 uses CRC-P, which requires additional internal calculation cycles. CRC-P adds programmable CRC32 polynomial support, but it is not as fast as the standard CRC peripheral.

    Therefore, an increase from approximately 2.2 ms to 4.2 ms is plausible, although TI does not specify a fixed 2× performance ratio. Total execution time also depends on flash wait states, compiler optimization, loop overhead, and source-memory access.

    To confirm the comparison:

    • Use identical optimization settings and CRC feeding code.
      Measure only the CRC input loop.
      Test the input buffer and loop from SRAM.
      Consider DMA to feed CRCIN if lower CPU overhead is required.

    Since MCLK was verified at 80 MHz and the input is 32-bit aligned, the observed difference is most likely due to the CRC-P architecture rather than the clock configuration. Hope this helps!

    -Brian