cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Voyager
Voyager
174 Views
Registered: ‎08-02-2019

Interrupt inconsistency after changing SetTlbAttributes of AXI-Lite Slave Address

Jump to solution

Hi,

I'm using interrupts from FPGA to Bare Metal CPU1 for 10 months without any problem.

To Increase AXI-Lite Slave performance, I changed my AXI-Lite Slave address' table attribute like that:

/* shareable device: S=b0 TEX=b000 AP=b11, C=b0, B=b1 = 0xC06*/
MyXil_SetTlbAttributes(0X43C00000,0xC06);

It's performance 4x faster than before as I described in this post and it marked as solution to AXI slave performance problem.

I'm creating interrupts from FPGA to Bare Metal every 50kHz(20 micro seconds.)

Nowadays I noticed, this attribute changing causes somehow extra interrupts on Bare Metal. When I remove only this line, interrupts work properly.

I designed advanced trigger to catch this extra interrupts on FPGA, but it is not coming from FPGA, instead it is generated on Bare Metal CPU internally.

As you see in screenshot, normaly I'm calculating elapsed time between 2 interrupts, somehow comes an extra interrupt too early(instead of 20micro, 2-3 micro seconds later.) Then record after is also smaller than 20 micro. When I add this two elapsed time(2.3 + 18.7 = 21), it is almost same with normal 20 micro second.

As far as I understand this attribute changing causes randomly 2 interrupts, instead of one.

/**
 * Modified SetTlbAttributes to call MyXil_DCacheFlush in order
 * to prevelt L2 Cache controller accesses
 */
void MyXil_SetTlbAttributes(u32 addr, u32 attrib)
{
	u32 *ptr;
	u32 section;

	mtcp(XREG_CP15_INVAL_UTLB_UNLOCKED, 0);
	dsb();

	mtcp(XREG_CP15_INVAL_BRANCH_ARRAY, 0);
	dsb();
	MyXil_DCacheFlush();

	section = addr / 0x100000;
	ptr = &MMUTable + section;
	*ptr = (addr & 0xFFF00000) | attrib;
	dsb();
}

How can I solve this problem?

Saban

 

<--- If reply is helpful, please feel free to give Kudos, and close if it answers your question --->
IRQ_Extra_Abnormal_Lines.png
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Voyager
Voyager
108 Views
Registered: ‎08-02-2019

Hi again,

I solved the problem myself.

I'm using Vivado 2018.2 with ZC702 board.

I have two Ip core related that issue. 

  1. Custom ip core with AXI-Lite Slave and AXI Full Master. It located 0x43C0_0000 in FPGA.
  2. IRQ ip core(coming from Xapp1078). It located 0x43C1_0000 in FPGA.

When I change attribute of Custom Ip core to make it faster, I noticed IRQ ip core's attribute also changes, because it has next address in FPGA design.

That's why I gave IRQ ip core to different address and problem solved.

At the end, it is 4x time faster than before and IRQ works properly.

Saban

 

<--- If reply is helpful, please feel free to give Kudos, and close if it answers your question --->

View solution in original post

IRQ_Problem_Solved.png
1 Reply
Highlighted
Voyager
Voyager
109 Views
Registered: ‎08-02-2019

Hi again,

I solved the problem myself.

I'm using Vivado 2018.2 with ZC702 board.

I have two Ip core related that issue. 

  1. Custom ip core with AXI-Lite Slave and AXI Full Master. It located 0x43C0_0000 in FPGA.
  2. IRQ ip core(coming from Xapp1078). It located 0x43C1_0000 in FPGA.

When I change attribute of Custom Ip core to make it faster, I noticed IRQ ip core's attribute also changes, because it has next address in FPGA design.

That's why I gave IRQ ip core to different address and problem solved.

At the end, it is 4x time faster than before and IRQ works properly.

Saban

 

<--- If reply is helpful, please feel free to give Kudos, and close if it answers your question --->

View solution in original post

IRQ_Problem_Solved.png