TDA4VL-Q1: peak DDR bandwidth calculation

Hi experts,
Can you help me take a look at this issue?

Hi Rain,

We are checking to see who can help with this issue.

Regards,
Kevin

Hi, Rain,

First, the theoretical maximum DDR BW calculation is what you mentioned in the ticket. The actual BW can get heavily depends on the DDR data access pattern.

Rain said:

Is 1x32b 4266(17GB/s) or 1x32bx3200(13GB/s) ?

Second, need your help to feedback the HW board you used for the test? Is it TDA4VL EVM board? If yes, then want to know whether you did customization to configure it to TDA4VL according to below FAQ? The reason is TDA4VL EVM is using TDA4VE in the design and this silicon has 2 DDR IF, then the theoretical maximum DDR BW is 3x32bx4266= 34GBps. If this is the case, then your observation seems more reasonable, even the total PEAK is 37219MB/s.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1227640/faq-tda4vm-tda4vl-tda4al-tda4vh-dra821-how-can-we-make-the-jacinto-sdk-compatible-for-device-variants-yxz 

Br, Tommy

Hi experts,
               The soc we use is TDA4VL, connected to a 4G DDR, and VL can only connect to one instance. I now configure DDR to 3200MT/s in sbl. Theoretically, the maximum bandwidth should be 18GB/s, but the demo test shows that the PEAK is 37219 MB/s, which is very strange. Please give a reasonable explanation. Thanks

Hi Gaston,

If you are only using a single DDRSS and the bandwidth measurement is exceeding the max theoretical possible bandwidth, then it seems there must be an issue with the tool being used to calculate the bandwidth. 

Can you please comment on how you are measuring the bandwidth?

Regards,
Kevin

Hi Gaston,

Have you reduced the number of DDR instances to 1 here in vision_apps/utils/perf_stats/src/app_perf_stats_freertos.c ?

#elif defined (SOC_J721S2)
-#define APP_PERF_NUM_DDR_INSTANCES (2u)
+#define APP_PERF_NUM_DDR_INSTANCES (1u)

Regards,

Nikhil Dasan

Hi Nikhil Dasan:

                       Have you reduced the number of DDR instances to 1 here in vision_apps/utils/perf_stats/src/app_perf_stats_freertos.c ?

                       yes

Hi Kevin S

Added a demo to loop through the appPerfStatus series of functions, as shown in the figure

Hi Rain,

Could you please try adding the below in appLogGetGlobalTimeInUsec() in vision_apps/utils/console_io/src/app_log_linux.c

cur_ts = GET_GTC_VALUE64 / mhzFreq;

Please note that the API would already consist of this above line, but please add this again below the same.

Here we will be reading the GTC register two times and take this value as the timestamp.

Please let me know if this fixes the issue.

Regards,

Nikhil

Hi, Nikhil 

The IPC of mcu21 has been disabled and DDR cannot be viewed now. I am trying to use mcu20 to view DDR.

Hi Rain,

Rain said:

The IPC of mcu21 has been disabled and DDR cannot be viewed now. I am trying to use mcu20 to view DDR.

Sorry, did not get the context here.

Nikhil Dasan said:

Could you please try adding the below in appLogGetGlobalTimeInUsec() in vision_apps/utils/console_io/src/app_log_linux.c

cur_ts = GET_GTC_VALUE64 / mhzFreq;

Please note that the API would already consist of this above line, but please add this again below the same.

Here we will be reading the GTC register two times and take this value as the timestamp.

Could you let me know if this works?

Regards,

Nikhil

Because the colleague responsible for this part of the code closed the IPC of mcu2_1, we are unable to view the usage rate of DDR at this time. I tried using mcu2_0 to view DDR, but all I got were 0.

Hi Nikhil,

1. I can now view DDR through mcu2_0.
2. I also added cur_ts=Get_GTP_VALUE64/mhzFreq;  but it has no effect.

What files do I need to replace,  libtivision_apps.so.8.6.0  and vx_app_rtos_linux_mcu2_0.out?

Or where to add printf() and confirm that the file has been effectively replaced.

Regards,

Rain

Hi Rain,

You could build vision_apps and use the script "make linux_fs_install_sd" to copy all the necessary binaries to the SD Card.

Regards,

Nikhil

Hi Nikhil,

I have verified that the above method is not effectiv, and it will not enter this condition.

As shown in the figure below, the printing information I added. Only displayed "linux 2", not displayed "linux 1".

Regards,

Rain

Hi Rain,

Is GET_GTC_FREQUENCY returning 0 in your case?

Regards,

Nikhil

Hi  Nikhil,

Although I did not print this value, from the result it appears to be 0.

Regards,

Rain

Hi,

Are you using SBL boot flow here?

Regards,

Nikhil

Hi Nikhil,

My colleague is responsible for SBL Boot related work and will answer your question.

Regards,

Rain

Sure. Meanwhile during boot do you see any logs saying "Assuming GTC freq as 200Mhz" in the beginning?

If yes, Can you write 200000000 (i.e. 200 Mhz) in the sbl_main.c to the register 0xA90020H (CSL_GTC0_GTC_CFG1_BASE + 20h) after enabling the GTC in the below line

Regards,

Nikhil

Hi Nikhil,

Followed your modification method and replaced the new SBL, mhzFreq no longer 0, but ddr is still incorrect.

Regards,

Rain

Hi Rain,

Could you try this implementation suggested here, to read the GTC?

(+) PROCESSOR-SDK-J721S2: The GTC read is abnormal - Processors forum - Processors - TI E2E support forums

Regards,

Nikhil

Hi Nikhil,

Based on the above method, do I have two questions?

Question 1: Where should I make the modifications? I tried to add Get_Gtc() under vision.apps/utils/console_io/src/app_log_Linux. c, but there was an error during compilation.

Question 2: Is the Get_Gtc() function used instead of appLogGetGlobalTimeInUsec()?

Regards,

Rain

Does the result obtained from Get_Gtc() replace Get_GTC_VALUE64?

Hi,

This is a reference of the implementation. i.e. instead of reading Get_GTC_VALUE64 directly (i.e. 64 bits at a time), please use the above way of reading with a while loop in appLogGetGlobalTimeInUsec()

Regards,

Nikhil

Hi Nikhil:

          Hi, I found through debugging that the DDR bandwidth calculation API scheduling cycle is about 1ms, and the number of cycles scheduled each time is not exactly 1ms. In addition, this is 1ms DDR data. If you capture 1ms DDR data for calculation, there will definitely be data with more than 13GB/s theoretical bandwidth. The data captured per second is stable, that is, the time period of 1s and above is stable, so I think this data itself is not a problem. We connected 4-way surround view, using mcu10, mcu11 running autosar os, mcu20 camera driver, mcu21 running uss, and 2 A72 running applications and algorithms. Our DDR monitoring data is as follows. Please help me see if the DDR bandwidth data is reasonable.
root@j721s2-evm:~# ./app_status_monitor.out |grep PEAK
DDR: READ BW: AVG = 2965 MB/s, PEAK = 7184 MB/s
DDR: WRITE BW: AVG = 2641 MB/s, PEAK = 7835 MB/s
DDR: TOTAL BW: AVG = 5606 MB/s, PEAK = 15019 MB/s
DDR: READ BW: AVG = 2984 MB/s, PEAK = 12713 MB/s
DDR: WRITE BW: AVG = 2663 MB/s, PEAK = 8031 ​​MB/s
DDR: TOTAL BW: AVG = 5647 MB/s, PEAK = 20744 MB/s
DDR: READ BW: AVG = 2989 MB/s, PEAK = 12513 MB/s
DDR: WRITE BW: AVG = 2658 MB/s, PEAK = 7420 MB/s
DDR: TOTAL BW: AVG = 5647 MB/s, PEAK = 19933 MB/s
DDR: READ BW: AVG = 2983 MB/s, PEAK = 5312 MB/s
DDR: WRITE BW: AVG = 2649 MB/s, PEAK = 5680 MB/s
DDR: TOTAL BW: AVG = 5632 MB/s, PEAK = 10992 MB/s

Hi,

Is the above with the changes suggested for the GTC timer calculation?

Regards,

Nikhil

Hi Nikhil Dasan:

                       Is the above with the changes suggested for the GTC timer calculation?

                        Does not affect the test results