TDA4VH-Q1: Unexpected result in DMIPS test

Hello,

Yes we run dhrystone at the HLOS and bare metal levels.  Runs I have made match with values you cite from the introduction.

Runs at the SDK level are published with each release in benchmarking sections.  Here is a link for the A72.

https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j784s4/10_00_00_08/exports/docs/devices/J7_Family/linux/Release_Specific_Performance_Guide.html#dhrystone

The score you get will depend a lot of the compiler and options you.  It can also depend on the environment.  If for bare metal your process just used jtag scripts to clock a core and then to load code the values would likely be very slow if the caches were not enabled (or the PLL for the domain was not set to the max speed). 

You can find some background based on another public E2E for the SDK where a column was not uploaded properly for one release.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1392814/am67-linux-sdk-dhrystone-benchmark-results/5330498#5330498

If you want further review of what you measure more information about how it was run (target env, clock speed, cache setups, compiler used and its switches, ...).  Largely, dhrystone for an standard ARM core will not very from vendor to vendor. Dhry is a very small test and it fully fits in the L1 cache of a system, so it tells you if the clock speed, cache are setup and how good your compiler is for procedural code.

Hi,

Thank you for the explanation, I will check my system configuration for the test.

I'd also like to ask if you can provide any demos or examples of Dhrystone that you used in R5F DMIPS test? When I integrate the program into R5F I changed something like the way to get time. If it possible I want to try your Dhrystone program to see if I can get a better result.

Regards,

Hongyao

This Lauterbach JTAG script allowed bare metal launches of a simple compile.  It leverages the standard CMM/GEL startup to run.

Thank you for providing this. However I do not have a Lauterbach by my side right now. It will be great if you can provide something I can use on CCS. Of course a executable binary file will be even better.

Regards,

Hongyao Jin

Hello,

I did not build up a CCS project for this.  For bare metal LB ends up being a bit easier in this instance as its APIs in CMMs can force some CPU states which need to be hand coded in assembly and integrated into the binary with CCS.

Here is a quick video showing how to run it along with binary if you want to try.  I launch this after starting up the R5 core with the standard CMMs to set the clock at 1GHz.

/cfs-file/__key/communityserver-discussions-components-files/791/dhry2_5F00_cr5_5F00_O3.7z

Hi,

I borrowed LB and tried the cmm script and the binary file you provided and met some problems.

I tried to run the cmm script first and I can not find the file in this command:

So I tried this script with this line commented, and I noticed that it tried to load a binary file:

I believe this commend is to try to load the binary file you provided, so I changed the path in this line to load the binary file and run this script. It is OK when I run the script but when I try to run the CPU, the LB keeps reporting that the target is running, and when I check the CPU state at the bottom, it shows the CPU is still in a 'stopped' state.

So I tried use only the 'data.load.elf' to load the binary file, the LB also reported the target is running.

I would like to ask that whether there is any step I executed is wrong? If it is possible, can you provided the missing files mentioned in the cmm script (the files I mentioned in the two picture above)? And why I always get a 'target is running' when I try to run the binary file? (btw: I also tried to load the binary file by using CSS, after I load it to R5f, CSS also report 'running' and nothing happened)

looking forward to your reply,

Regards,

Hongyao Jin

Hi,

As I mentioned in the other reply 14 days ago, I still have no idea on how to use your script to get the ideal DMIPS of R5f. If it is possible, could you provide some suggestions on that?

Looking forward to your reply.

Regards,

Hongyao Jin

Hello,

Based on your comments you are not that familiar with TRACE32. It is necessary to specify a core and halt it before loading an elf file. It is possible to specify this in the GUI or use scripts. I'll attach the script to specify the core and the larger set I use with basic tests on the EVM.  If you init the system with bare metal CMMs, its best to start from a NOBOOT state (dip switches) on the EVM, but setting it for SD boot and not inserting a card is OK also. The scripts I am attaching do require some familiarity with TRACE32. It might be advisable to consult with one of your colleagues on this or Lauterbach support. I can discuss script aspects but that discussion might only make sense after a little bit of ramp up training on TRACE32.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/_5F00_J784S4_5F00_r5.cmm

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/3515.cmm_2D00_tda4vh_5F00_j784s4.7z