1
\$\begingroup\$

I need the Xilinx System ILA IP core to debug the AXI bus of a design. So I´ve created a more simplier design to playing around with the ILA core and to understand how it works.

enter image description here

With the following software

#include "xgpio.h"
#include "xparameters.h"

int main()
{
    XGpio Gpio;

    u32 Status = XGpio_Initialize(&Gpio, XPAR_LED_GPIO_DEVICE_ID);
    if(Status != XST_SUCCESS)
    {
        xil_printf("Gpio Initialization failed!\r\n");
        return XST_FAILURE;
    }

    while(1)
    {
        u32 Input = XGpio_DiscreteRead(&Gpio, 2);
        XGpio_DiscreteWrite(&Gpio, 1, Input);
        for(u32 Delay = 0; Delay < 0x10000; Delay++);
    }

    return 0;
}

I also enable the cross trigger interface from the processing system to the ILA in the debug configuration.

enter image description here

I set the my breakpoint to the line XGpio_DiscreteWrite(&Gpio, 1, Input); to capture the AXI communication from the processing system to the gpio core. Now I run the debug configuration and open the ILA with the following settings (default settings):

enter image description here

After continuing my application the ILA sample the communication with the gpio core.

enter image description here

But the core doesn´t sample the second transmission (the transmission for the XGpio_DiscreteWrite(&Gpio, 1, Input) line).

enter image description here

I´m quite sure that I´m using the ILA wrong. So how can I improve the usage of the ILA? What is the meaning of Number of windows in the ILA configuration?

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

The ILA grabs a single window of data for each trigger that it sees. So once the first one has happened, it will not collect any more data after the end of that window. If the second transaction does not come along within that window then you will not see it.

If you set the number of windows to '2' (or more), you will see both transactions as connected to separate triggers. However, now you have no idea how big the time difference between the two triggers was. And you get less data in each window :(

Another way to use the tool which is sometimes handy is to set the window length to a single sample and have (for example) 1024 windows of 1 sample each. Then set the trigger to be on any interesting signal change. You will then see all the changes in these signals. You lose all the timing information, but you have the ability to see lots of transactions, which is sometimes the more useful thing to see.

\$\endgroup\$
2
  • \$\begingroup\$ So the problem was simply that the time difference between the trigger in the SDK and the transmission of the message was too big? So a better way would be to use the trigger conditions and to trigger on a signal level instead of the cross trigger with a breakpoint? \$\endgroup\$
    – Kampi
    Commented Jul 30, 2019 at 5:23
  • \$\begingroup\$ Using the signal conditions with changes rather tha levels is the method I usually use. You might also be able to use the state machine trigger to wait for a breakpoint and then wait for the signal changes you are interested in. \$\endgroup\$ Commented Jul 30, 2019 at 6:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.