<div dir="auto">Thanks, I'll check it out. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 11 Jan, 2020, 4:33 AM Onur Atilla, <<a href="mailto:onurati@posteo.de">onurati@posteo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10.01.20 15:58, Muni Sekhar wrote:<br>
> On Fri, Jan 10, 2020 at 4:46 PM Primoz Beltram <<a href="mailto:primoz.beltram@kate.si" target="_blank" rel="noreferrer">primoz.beltram@kate.si</a>> wrote:<br>
>><br>
>> Hi,<br>
>> Have read also other replays to this topic.<br>
>> I have seen-debug such deadlock problems with FPGA based PCIe endpoint<br>
>> devices (Xilinx chips) and usually (if not signal integrity problems),<br>
>> the problem was in wrong AXI master/slave bus handling in FPGA design.<br>
>> I guess you have FPGA Xilinx PCIe endpoint IP core attached as AXI<br>
>> master to FPGA internal AXI bus (access to AXI slaves inside FPGA design).<br>
>> If FPGA code in your design does not handle correctly AXI master<br>
>> read/write requests, e.g. FPGA AXI slave does not generate bus ACK in<br>
>> correct way, the PCIe bus will stay locked (no PCIe completion sent<br>
>> back), resulting in complete system lock. Some PCIe root chips have<br>
>> diagnostic LEDs to help decode PCIe problems.<br>
>>  From your notice about doing two 32bit reads on 64bit CPU, I would<br>
>> guess the problem is in handling AXI transfer size signals in FPGA slave<br>
>> code.<br>
>> I would suggest you to check the code in FPGA design. You can use FPGA<br>
>> test bench simulation to check the behaviour of PCIe endpoint originated<br>
>> AXI read/write requests.<br>
>> Xilinx provides test bench simulation code for their PCIe IP's.<br>
>> They provide also PCIe root port model, so you can simulate AXI<br>
>> read/writes accesses as they would come from CPU I/O memory requests via<br>
>> PCIe TLPs.<br>
> Thank you so much for sharing valuable information, will work on this.<br>
> <br>
>> WBR Primoz<br>
<br>
Hi,<br>
<br>
you may also want to have a look at the AXI Timeout Block (ATB) to<br>
prevent system/core locks due to a missing ACK of a slave. If given by<br>
the HW, ATB generates an alternative response in case the slave fails to<br>
respond within a given time. It may also trigger an interrupt to help<br>
handle/debug the error.<br>
<br>
Regards,<br>
Onur<br>
<br>
</blockquote></div>