Finding Interrupt Latency

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

For the interrupt threshold to take effect you have to run the gel command from the gel menu, clicking Set_threshold on the gel menu should make the threshold take effect.

A negative cycle count like this sounds like something overflowed in the ILC tool, if interrupts are actually disabled for too long I would not be suprised to see results like this, as it would mean that you probably have a major interrupt latency problem. I am curious of the kind of issues you are running into with your application that led you to the ILC tool, as this could be an artifact of them.

Hi,

> For the interrupt threshold to take effect you have to run the gel command from the gel menu, clicking.
> Set_threshold on the gel menu should make the threshold take effect.

Clicking Set_threshold on the gel menu, did not bring up any further configurable option (no response!)
As said earlier, modifying and reloading the GEL file did not help.

With respect to the negative cycle count:

The difference between the negative values is of the same range as that obtained when run for small duration.
The outputs obtained in both the cases are as follows:

<cycle_start>-1720899472</cycle_start>
<cycle_end>-1720810930</cycle_end>
<start_pc>0x80f2d5f0</start_pc>
<end_pc>0x80f2d638</end_pc>

<cycle_start>42539608</cycle_start>
<cycle_end>42617311</cycle_end>
<start_pc>0x80f2d5f0</start_pc>
<end_pc>0x80f2d638</end_pc>

Note that the program counter addresses are at the same locations.
So, doesn't this imply that the count has overflown and there is no latency issue?

Regards,
Akshatha

My understanding is that you have to modify the GEL file, reload it, and than run the set_threshold function from the GEL menu to enact the new value, you do not actually change the value from the GEL menu, you just enact what you set in the GEL file.

As to the negative values you may be right, this could be a flaw in the ILC. I have not seen this happen myself, but if you could provide a .out file and the .xml file generated by the ILC when this happens I could try to reproduce the issue and pass it back to the developers. If you want to do this PM me and I can get you an address to send in the files.

Hi,

Thanks. The procedure for set_threshold worked fine.

Regarding the negative count in ILC, we will not be able to share the .outs.
It would be really helpful if you could test / reproduce the issue on your side.

Regards,
Akshatha

I am glad to hear that the thresholding works for you.

I understand not being able to share your binaries, that is a common situation. We will be on the look out for the negative counts from the ILC, but until it is seen in an environment we can reproduce here there is little we could do to move forward on it.