Forums

Based on the Wiki article regarding the interrupt latency checker you may want to try 'C64x+ CPU Cycle Accurate Simulator, Little Endian' instead, which brings in the 'simc64plus_cpu.cfg'. I have not had a chance to use this tool myself but hopefully the minor simulator configuration change will help it to work for you.

As to measuring the interrupt latency once the code is in Codec Engine, I am not sure such a tool exists, the SoC Analyser collects a lot of trace information but I believe interrupt latency is beyond the scope of SoC Analyzer.

Thanks for the response.

But, I cannot find the ILC feature in 'simc64plus_cpu.cfg' also. I do have CCS v3.3.38.2. Is there a different version of the drivers that I should use?

Regards,

Akshatha

I looked through my config files and none of them seem to have that with the exception of some of the simtci64xx configuration files. I believe you are supposed to add in the text into the configuration files by hand, as my .cfg files should be relatively up to date since I just recently went to the latest CCS service pack so if mine does not have them chances are none of the current production CCS releases have them. For an example, based on where it is placed in the simtci6486.cfg file, I would guess that you want to place it just before the END C64xplus; line in simc64plus_cpu.cfg. I will check on this internally to see if this is really the right way to go and let you know if there is a better way.

Thank you.
I will try adding it myself and let you know the results.
Please do inform me if this is the right way to do it.
Regards,
Akshatha

It looks like there is now an easier way to do this, in particular if you load C:\CCStudio_v3.3\cc\gel\interruptlatencydetector.gel it will give you GEL commands to start and stop the interrupt latency detector. The wiki page has been updated with this, and if you look inside that GEL file it provides some additional insight on how to use it.

Thanks a lot for the information.
I will try it out.

Regards,
Akshatha

Hi,

I was able to use the ILC feature and measure the interrupt latency of my code.
Thanks for your help.
I have another doubt. The interrupt latency is determined between the points of usage of DINT and RINT instructions. But not by monitoring the GIE bit of CSR register. Is this right?

Regards,
Akshatha

I am glad to hear that it worked for you.

Based on what processors the ILC supports and the Wiki page description I believe it is actually monitoring directly the capability of the processor to execute interrupts through monitoring GIE writes, branch delay slots, and NMI writes. It must not be just watching DINT and RINT instructions because these are specific C64x+, and the ILC supports C64x devices.

Hi,
I have experimented with the following code:

function1()
{
 ..
 DINT; // mark1
 ..
 function2();
 ..
 RINT; // mark4
}
function2()
{
 ..
 DINT; // mark2
 ..
 ..
 RINT; // mark3
 ..
}

GIE was set to 1 before 'mark1'. The interrupt latency was equal to number of cycles between 'mark1' and 'mark3'.
Hence, we did not get the right value for interrupt latency. Can you please comment on this?

Regards,

Akshatha

This is an interesting situation, as a set of nested pair or DINT/RINT like will happen in this pair of function calls means that the RINT will not set the GIE bit since the GIE=1 is pushed off of the SGIE bit with the second DINT. So as you say just looking at this code it would seem to me that interrupts could be disabled indefinitely, so it seems this may be a flaw in the utility... I will have to check with the software folks on this to see if this is a situation that the tool recognizes.

Yes, that is true.
In the normal cases (no nesting of DINTs), the tool worked fine. But, it did not seem to handle the nested case.
Hence, I raised my doubt earlier that it must be just monitoring the instructions, not the GIE bit actually.
Please let me know if the tool can support this.

Regards,
Akshatha

It looks like this is officially a defect in the ILC tool, the simulator team verified that it is interpreting RINT as a enable by default as shown by your testing. This should be fixed in a future service release of CCS 3.3 (likely SR12), and is referenced internally by defect# SDSCM00027632.

Thanks a lot for the information.
Hoping to get the service release soon.

Regards,
Akshatha

Hi,

While using the ILC feature on CCS 3.3, we noticed that the change in the 'SET_INT_THRESHOLD' value other than 500 in the GEL file is not taking effect.
hotmenu SetThreshold(){
    GEL_DriverString("SET_INT_THRESHOLD::500");
}

Please let me know if I have to change this value in any other place ?

We followed the following steps:
  1. Edit the GEL file
    * Open the GEL file in a test editor
    * Look for "hotmenu SetThreshold"
    * You would notice a statement
      GEL_DriverString("SET_INT_THRESHOLD::500");
    * Change the value "500" to a latency
      threshold  to a desired value
    * Save the GEL file
  2. Reload the GEL file
 

Regards,
Akshatha

Hi,

While using the ILC feature on CCS 3.3, we noticed that the cycle counts were negative (as below)
(we ran the profile for a long duration)
<cycle_start>-1720899472</cycle_start>
<cycle_end>-1720810930</cycle_end>

So, is this data valid?
Why is the cycle count negative?

Regards,
Akshatha