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.

Measuring DDR memory throughput on ADAS Vision High

First of all sorry for posting this here but didn't find a fitting forum.

I'm looking for a way to measure the amount of data read/written from/to DDR memory on an ADAS Vision High SoC. In the document "ADAS_Superset28_ES1.1_NDA_TRM_vO.pdf" (SPRUHK5O) I found the 2 performance counters in the EMIF. These counters only count events which allows only a rough estimation of the size transferred between a master and memory.

There is another issue with the performance counters. I cannot filter the EVE_1 accesses. Using the MConnID of EVE_1 (0x10 << 2 = 0x40) the counter is not increasing. I've tried all ConnIDs from the TRM (even those don't making sense), but the sum of all individual masters is much less than the unfiltered result. Is there a ConnID missing in the TRM?

Is there a better way to monitor memory accesses? (maybe at L3 Interconnect or on a specific core such as C66xx and CortexA15)


Thanks in advance,

Roland

  • Hello Yanko,

    thanks for the information - I'll have a further look at it.

    However, I'm looking for a solution that works without a system trace emulator. So could you please answer the following questions?

    1. What is the MConnID for filtering out EVE related data access using the EMIF Performance Counter?
    2. Is there another on-chip solution on Vision High for monitoring memory accesses?

    Thanks in advance,

    Roland

  • Hello Roland,

    About your questions:

    At first I suggest you to see in detail section 14.3.4.16.1 Performance Counters General Examples in TDA2xx TRM.

    Q1: What is the MConnID for filtering out EVE related data access using the EMIF Performance Counter?
    MConnID = ConnID means Master Connection ID. Any transaction in the system interconnect is tagged by an in-band qualifier ConnID, which uniquely identifies the initiator at a given interconnect point. A ConnID is transmitted in band with the request and is used for firewall and error-logging mechanism. You can see Table 13-10. ConnID Values.
    Used to determine the permission of the master NIU

    For Performance Counter 1:

    EMIF_PERFORMANCE_COUNTER_MASTER_REGION_SELECT[15:8] MCONNID1

    Performance Counter Master Region Select Register
    The values programmed into the MCONNIDx fields are those in the ConnID Values table in Chapter 13,
    Interconnect, left-shifted by 2 bits.

    For example, to monitor accesses from EVE1 (ConnID = 0x5), the value 0x60 is programmed into the MCONNIDx field.

    Q2: Is there another on-chip solution on Vision High for monitoring memory accesses?

    - Yes. Following subsystems in TDA2xx have options for performance monitoring:

    MPU Subsystem Performance Monitoring
    IPU Subsystem Performance Monitoring
    DSP Subsystem Performance Monitoring
    EVE Subsystem Performance Monitoring

    See sections 27.7 Performance Monitoring and 27.10 System Instrumentation in TRM.

    Best regards,
    Yanko

  • Hi Yanko,


    first of all thanks for your answers. Of course, I've checked the TRM and the chapters you mentioned. However ...

    Q1: your answer increases my confusion.

    1. From TI I got the document "TDA2x_SR1.1_NDA_TRM_vU.pdf" (Literature Number: SPRUHK5U, 20 Oct 2014). This document contains the following MConnID list : 7181.mconnid_list.txt
      In this list there is "EVE1 P1 = 0x10" (<< 2 = 0x40) and "EVE1 P2 = 0x34" (<< 2 = 0xD0). A MConnID "EVE = 0x5" is not in the list.
    2. 0x5 << 2 is not 0x60 (the correct result would be 0x14).
      Test results:
      0x14: not events counted => ID not correct
      0x60: some events counted, but less than expected (this ID is related to IPU_1 in the ConnID list)
      => Could you please tell me how to receive a correct list of MConnIDs?

    Q2: Looks like that what I was looking for. This question is answered.

    Thank you again!

    Kind regards, Roland

  • Hello Roland,

    Yes, you are right. I was wrong, my example is incorrect.

    I had in mind something as:  For example, to monitor accesses from IPU1 (ConnID = 0x18), the value 0x60 is programmed into the MCONNIDx field.

    1. From TI I got the document "TDA2x_SR1.1_NDA_TRM_vU.pdf" (Literature Number: SPRUHK5O, 20 Oct 2014). This document contains the following MConnID list : 7181.mconnid_list.txt
      In this list there is "EVE1 P1 = 0x10" (<< 2 = 0x40) and "EVE1 P2 = 0x34" (<< 2 = 0xD0). A MConnID "EVE = 0x5" is not in the list. - Yes, you are right. 
    2. 0x5 << 2 is not 0x60 (the correct result would be 0x14). I'll check this because that's one ID I didn't check cause it's not in the list.
      => Could you please tell me how to receive a correct list of MConnIDs?

    - The correct list of MConnIDs is in Table 13-10. ConnID Values in TDA2x TRM. I compared this table with MConnIDs in your file. There are no differences.

    I also suggest you to see following sections in TRM:

    27.10.10.1 Software Masters   - Table 27-66. STM Message Software Masters

    27.10.10.2 Hardware Masters - Table 27-67. STM Message Hardware Masters


    Best regards,

    Yanko

  • Hello Yanko,

    so I did nothing wrong, but have a look at my investigations.

    CNTR1_MCONNID_EN = 0: ~162,000 events

    CNTR{1|2}_MCONNID_EN = 1:
    MCONNID1 = 0x60 (IPU_1 0x18): ~44,000 events
    MCONNID2 = 0x20 (DSP1_MDMA 0x08): ~20,000 events

    I've tried ALL ConnIDs from the list - all others measure zero counts!

    162,000 - 44,000 - 20,000 = 98,000 missing counts

    These missing counts are nearly all produced by the eve, but cannot be filtered out by any of the ConnIDs in the list.

    => So it looks to me like either the performance counters have bug or the list is incomplete or wrong. Could you please clarify that?

    The measurements were made on the same data and are 100% reproducible for every cycle.

    Kind regards,

    Roland

  • Hello Roland,


    Did you set/use EVE pipeline?

    If you do not set a correct pipeline it is possible not to see all initiators in performance counters.

    Best regards,

    Yanko

  • Hi Yanko,


    I'm not completely sure. I think the EVE setup is done from TI gel files (I've just configured the MMU).

    If you are talking about the bus configuration...
    EVE_BUS_CONFIG = 0x00003314

    If not, which registers do I have to configure/check?

    Does this mean that (if the pipeline was not set up) I can see the counts when switching of master filter, but not if filtered by any of the ConnIDs?

    Kind regards, Roland

  • Hello Roland,

    Do you use Vision_SDK release for TDA2xx?

    #Q: Does this mean that (if the pipeline was not set up) I can see the counts when switching of master filter, but not if filtered by any of the ConnIDs?

    - Yes, you are right.

    I notice you following:

    On CortexA15_0, run the GEL “Scripts -> EVE MMU Config -> EVE_MMU_Config”. IMPORTANT NOTE: If this step is not done you will not be able to load executables on the EVE cores

     building for only the cores of interest can be done. Controll ing this is present in file \vision_sdk\Rules.make, Ex: If DSP1 is not used, PROC_DSP1_INCLUDE can be set equal to no.
    If EVE1 is used, PROC_EVE1_INCLUDE is set equal to yes.

    Do “gmake –s” after making the changes and to regenerate the binaries. Load and run only the required binaries via CCS.

    I suggest you to see section 3.2 Building the application in VisionSDK_UserGuide_TDA2xx.pdf.

    This document can be found in docs folder in your VisionSDK.

    To check if your EVE module is functional see its PRCM configuration by registers:

    CM_CLKSEL_EVE_CLK
    CM_CLKSEL_EVE_GFCLK_CLKOUTMUX
    CM_EVE1_CLKSTCTRL
    CM_EVE1_EVE1_CLKCTRL

    Best regards,

    Yanko

  •  

    Hello Roland,

    Vision SDK has the feature to print the DDR BW usage of each initiator.

    please run the use case of interest and then press 'p'. towards the end of the log you will get the DDR BW access data by each initiators

    regards, Shiju

  • Hi Shiju,


    thank you for the information. My task is to measure the ddr events / throughput over a time period in an existing multi core application. So is there a code snippet in Vision SDK? Does it use the EMIF performance counters on hardware level?

    For your information: from TI I got Vision SDK 02.02.00.00

    Regards, Roland

  •  

    Roland

    yes, we directly read the  hardware EMIF performance counters, note that you do not need to connect CCS to get this info when SDK is used.

    Use the latest vision SDK 02.05.00.00 - please contact your TI Field application Engineer for the release

    here is the snapshot of DDR BW log that SDK provides

    [IPU1-0]    922.379322 s:  Statistics Collector,

    [IPU1-0]    922.379444 s:

    [IPU1-0]    922.379536 s:        STATISTIC          Avg Data        Peak Data

    [IPU1-0]    922.379780 s:        COLLECTOR          MB/s            MB/s

    [IPU1-0]    922.379994 s:  --------------------------------------------------

    [IPU1-0]    922.380238 s:  SCI_EMIF1 RD+WR      |    407.743325    987.208801

    [IPU1-0]    922.380512 s:  SCI_EMIF2 RD+WR      |   2251.959819   3039.406840

    [IPU1-0]    922.380756 s:  SCI_EMIF1 RD ONLY    |    365.242734    986.826118

    [IPU1-0]    922.381001 s:  SCI_EMIF1 WR ONLY    |     42.591847    103.898161

    [IPU1-0]    922.381245 s:  SCI_EMIF2 RD ONLY    |   1609.852405   2315.432913

    [IPU1-0]    922.381489 s:  SCI_EMIF2 WR ONLY    |    642.951802   1625.188118

    [IPU1-0]    922.381733 s:  SCI_MA_MPU_P1        |      0.484804      4.051486

    [IPU1-0]    922.381977 s:  SCI_MA_MPU_P2        |      0.704170      8.380952

    [IPU1-0]    922.382343 s:  SCI_DSS              |    835.342746    912.215211

    [IPU1-0]    922.382588 s:  SCI_IPU1             |      3.017053     21.978154

    [IPU1-0]    922.382832 s:  SCI_VIP1_P1          |     38.805650     51.643790

    [IPU1-0]    922.383076 s:  SCI_VIP1_P2          |     85.298401     72.690240

    [IPU1-0]    922.383320 s:  SCI_VPE_P1           |      0.000000      0.000000

    [IPU1-0]    922.383564 s:  SCI_VPE_P2           |      0.000000      0.000000

    [IPU1-0]    922.383778 s:  SCI_DSP1_MDMA        |      2.704606     24.558227

    [IPU1-0]    922.384052 s:  SCI_DSP1_EDMA        |     69.373318    775.339031

    [IPU1-0]    922.384297 s:  SCI_DSP2_MDMA        |      3.182637     37.511503

    [IPU1-0]    922.384510 s:  SCI_DSP2_EDMA        |      0.000000      0.000000

    [IPU1-0]    922.384754 s:  SCI_EVE1_TC0         |      0.000000      0.000000

    [IPU1-0]    922.384998 s:  SCI_EVE1_TC1         |      0.000000      0.000000

    [IPU1-0]    922.385243 s:  SCI_EVE2_TC0         |      0.000000      0.000000

    [IPU1-0]    922.385456 s:  SCI_EVE2_TC1         |      0.000000      0.000000

    [IPU1-0]    922.385700 s:  SCI_EDMA_TC0_RD      |      0.000000      0.000000

    [IPU1-0]    922.386189 s:  SCI_EDMA_TC0_WR      |      0.000000      0.000000

    [IPU1-0]    922.386616 s:  SCI_EDMA_TC1_RD      |      0.000000      0.000000

    [IPU1-0]    922.386860 s:  SCI_EDMA_TC1_WR      |      0.000000      0.000000

    [IPU1-0]    922.387074 s:  SCI_VIP2_P1          |      6.205135     15.751060

    [IPU1-0]    922.387348 s:  SCI_VIP2_P2          |     14.473864     36.450730

    [IPU1-0]    922.387592 s:  SCI_VIP3_P1          |      6.208754     15.751060

    [IPU1-0]    922.387837 s:  SCI_VIP3_P2          |     14.483318     36.420556

    [IPU1-0]    922.388081 s:  SCI_EVE3_TC0         |      0.000000      0.000000

    [IPU1-0]    922.388325 s:  SCI_EVE3_TC1         |      0.000000      0.000000

    [IPU1-0]    922.388538 s:  SCI_EVE4_TC0         |      0.000000      0.000000

    [IPU1-0]    922.388783 s:  SCI_EVE4_TC1         |      0.000000      0.000000

    [IPU1-0]    922.389027 s:  SCI_IVA              |      0.000000      0.000000

    [IPU1-0]    922.389271 s:  SCI_GPU_P1           |    831.830991   1334.246110

    [IPU1-0]    922.389515 s:  SCI_GPU_P2           |    824.302467   1324.565783

    [IPU1-0]    922.389759 s:  SCI_GMAC_SW          |      0.030189      0.196629

    [HOST  ]    922.490193 s:

  • Hello Yanko,

    maybe there is a misunderstanding (my problem is not to get the EVE started).

    There is already an application running on EVE1 - so the EVE should be functional and setup correctly. This application does a lot of memory transfers (using the EVE EDMA) which I couldn't filter out on the EMIF performance counters.

    Does the EVE EDMA act as a separate bus master that is not included in the ConnID list?

    I could not find something to switch the EVE pipeline on/off. With "pipeline" did you mean the PRCM setup? (If so this setup is ok and running).

    Best regards,
    Roland

  • Hi Shiju,

    that is what I have already implemented in my application.

    When I look at the log I can see SCI_EVE1_TC0 and SCI_EVE1_TC1 which is not included in the ConnID list and that is what I need. Could you please tell me the file inside SDK where the performance counter setup is done for EVE1 - that I can check the master filter ID?

    Meanwhile, I try to purchase the latest SDK.

    Thanks, Roland

  • Hi Shiju, hi Yanko,


    I think I've found the problem => looks like a documentation issue to me.

    Register description of EMIF_PERFORMANCE_COUNTER_MASTER_REGION_SELECT: "The values programmed into the MCONNIDx fields are those in the ConnID Values table in Chapter 13, Interconnect, left-shifted by 2 bits."

    EVE1_P1 (0x10) << 2 = 0x40

    In File "vision_sdk\src\utils_common\src\stat_collector_utils\sci_dra7xx.h" there is defined:
    SCI_MSTID_EVE1_P1 = 0x42

    So there is an offset of 2 that is not documented!

    Anyhow, thanks for all the answers .. I will synchronize my master list versus the source file in VisionSDK.

    Best regards,
    Roland

  • Cool!

    regards, shiju