cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
kakaroto
Observer
Observer
17,839 Views
Registered: ‎07-10-2013

Infinite interrupt from PCIe and how to disable the INTA#?

Jump to solution

Hi all,

    I have implemented xapp1052(v3.2) BMD design on ML605  .

Using ISE14.2,  EndpointBlock plus for PCIe IPcore V1.7,  Windows Xp pro 32bit.

 

I use Windriver generater the driver and everything is OK except the interrupt mode.

The BMD design is running as the legacy interrupt mode and when the windriver application receives the legacy interrupt from the PCIe, it continues to trigger the Interrupt Handler, so I think there must be a method to disable the INTA# interrupt in the BMD app and HOW? 

Thanks !

Tags (3)
0 Kudos
Reply
1 Solution

Accepted Solutions
kotir
Scholar
Scholar
27,697 Views
Registered: ‎02-03-2010

Hi

 

I would suggest you to check the user guide document of interuupt and probe the interrupt pins of the PCIe core and see if there is any wrong behaviour from BMD.

 

Regards,

KR

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------

View solution in original post

0 Kudos
Reply
11 Replies
kotir
Scholar
Scholar
27,698 Views
Registered: ‎02-03-2010

Hi

 

I would suggest you to check the user guide document of interuupt and probe the interrupt pins of the PCIe core and see if there is any wrong behaviour from BMD.

 

Regards,

KR

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------

View solution in original post

0 Kudos
Reply
dougst41
Contributor
Contributor
17,803 Views
Registered: ‎04-04-2011

Hi K,

 

I had a very similar experience to you, and it turned out that the LEGACYCLR bit on the xapp1052 wrapper needed to be set. There's a thread that covers the same issue here: http://forums.xilinx.com/t5/PCI-Express/BMD-XAPP1052-Can-t-enable-MSI-or-disable-raised-legacy-interrupt/m-p/182288 

 

One thing to watch out for (once you've set LEGACYCLR) is missing payloads as a result of the xapp1052 interrupt controller's state machine de-asserting the interrupt line before the device driver can execute it's ISR.

 

I ended up adding an acknowledge function to the state machine and device driver to stop the problem, but was never 100% certain if this was the correct approach. On a side note the "best" PCIe book (PCI Express System Architecture by Mindshare) was quite ambiguous on the interraction between SW and HW during legacy interrupts...

 

Hope this helps,

-Doug

0 Kudos
Reply
kakaroto
Observer
Observer
17,766 Views
Registered: ‎07-10-2013

Hi Kotir,

   Sorry for late and thank you for your reply

1.you mean which user guide of interrupt , xapp1052 or pcie ipcore ug517 guide?

2.

I capture the interrupt interface of the core, when the MWr DMA ended there goes an interrupt中断.jpg

 

The UG517 says that cfg_interrupt_assert_n assert low means using legacy interrupt. keep cfg_interrupt_n assert held low until cfg_interrupt_rdy_n is asserted means that a legacy interrupt has been successfully transmitted through the cfg_interrupt_di bus. It is the same as the picture above.

 

It seems that the Root Complex treats the 0x00 on the cfg_interrupt_di(INTA#) is always effective?

Thank you!

 

0 Kudos
Reply
kakaroto
Observer
Observer
17,764 Views
Registered: ‎07-10-2013

Hi dougst41,

    Thank you for your help!

I notice that there is a reg in the offset address 0x48 in the file "BMD_EP_MEM.v" ,but it can be never found in the xapp1052 guide.In the "BMD_INTR_CTRL.v " I know that it controls the legacy interrupt.

 

the original code is:

`BMD_INTR_RD_ACT2 : begin
if (cfg_interrupt_legacyclr) begin
rd_intr_n = 1'b0;
rd_intr_assert_n = 1'b1;

if (!cfg_interrupt_rdy_n_i)
next_rd_intr_state = `BMD_INTR_RD_DUN;
else
next_rd_intr_state = `BMD_INTR_RD_ACT2;

........

`BMD_INTR_WR_ACT2 : begin
if (cfg_interrupt_legacyclr) begin
wr_intr_n = 1'b0;
wr_intr_assert_n = 1'b1; //

if (!cfg_interrupt_rdy_n_i)
next_wr_intr_state = `BMD_INTR_WR_DUN;
else
next_wr_intr_state = `BMD_INTR_WR_ACT2;

 

So, int my driver program, when it enterrd the interrupt handler I program the 0x48 reg to set the LEGACYCLR bit as 1'b1, but it also continue to enter the handler.

by the way, how does your acknowledge function works?can you explain?many thanks!

0 Kudos
Reply
dougst41
Contributor
Contributor
17,746 Views
Registered: ‎04-04-2011

Hi K,

 

I'm not sure from your answer if the LEGACYCLR bit had an impact on the interrupt.

 

Did setting the LEGACYCKR bit fix the infinite interrupt issue?

 

I can't tell you that you absolutely need to implement a handshake between the Device Driver and interrupt controller but here's how I did it:

 

I added two signals to a control register that the Device Driver and write to, called "wr_irq_done_i" and "rd_irq_done_i".

 

These signals are then fed into the interrupt controller and are used to reset the read/write interrupt asserts:

        `BMD_INTR_WR_ACT : begin

          if (msi_on) begin

            wr_intr_n = 1'b1;
            wr_intr_assert_n = 1'b1;
            next_wr_intr_state = `BMD_INTR_WR_DUN;

          end else begin

            wr_intr_n = 1'b1;
            wr_intr_assert_n = 1'b0; //Changed by Doug
            next_wr_intr_state = `BMD_INTR_WR_ACT2;

          end

        end

        `BMD_INTR_WR_ACT2 : begin
          if (cfg_interrupt_legacyclr && wr_irq_done_i) begin //Changed by Doug
            wr_intr_n = 1'b0;
            wr_intr_assert_n = 1'b1;

            if (!cfg_interrupt_rdy_n_i)
               next_wr_intr_state = `BMD_INTR_WR_DUN;
            else
               next_wr_intr_state = `BMD_INTR_WR_ACT2;

          end else begin
            wr_intr_n = 1'b1;
            wr_intr_assert_n = 1'b1;
            next_wr_intr_state = `BMD_INTR_WR_ACT2;
          end
        end

 

When the interrupt service routine is called due to the interrupt line being asserted, I read if a read/write was responsible for calling the ISR, and write to my control register bits ("wr_irq_done_i" or "rd_irq_done_i").

 

This interaction means the ISR must run before the interrupt line can be deasserted by the interrupt controller.

 

Hope this helps.

 

On a side note, be aware that the xapp1052 driver and api need a lot of work, especially if you want x64 compatibility.

0 Kudos
Reply
kakaroto
Observer
Observer
17,737 Views
Registered: ‎07-10-2013

Hi d,

Thank you very much!

1.Did setting the LEGACYCKR bit fix the infinite interrupt issue?

No, it is the same.

 

2.you mean you add a reg in the EP_MEM module ,and the reg has two bits which controls the wr_irq_done_i and rd_irq_done_i,

so for example MWr, when you entered the ISR you program the reg with wr_irq_done_i=0, am I right?

 

I think it the same as I directly program the LEGACYCKR bit

in the EP_MEM module:

 

assign cfg_interrupt_legacyclr = LEGACYCLR;

// 48-4BH : Reg # 18
// INTDI (RW)
// INTDO
// MMEN
// MSIEN

7'b010010: begin
if (wr_en_i) begin
INTDI[7:0] <= wr_d_i[7:0]; 
LEGACYCLR <= wr_d_i[8];
end


rd_d_o <= {4'h0, 
cfg_interrupt_msienable,
cfg_interrupt_mmenable[2:0],
cfg_interrupt_do[7:0],
7'h0,
LEGACYCLR,
INTDI[7:0]};
end

 

3.but you have a change at :

wr_intr_assert_n = 1'b0; //Changed by Doug

and I will have a try!

4.so did your logic fix this problem?

0 Kudos
Reply
dougst41
Contributor
Contributor
17,722 Views
Registered: ‎04-04-2011

No worries, hope I'm helping.

 

1. I'm surprised setting LEGACYCLR didn't fix your issue of infinite interrupts. I have a vague memory that the state machine wasn't driving XX_intr_assert_n and wr_intr_n to spec, hence the change you have noticed in point 3.

 

2. Yup, you've got it, although I think I set wr_irq_done_I to '1' (via the device driver) for a single clock. You get the idea though!

 

3. As I said before, I have a vague memory that the state machine doesn't conform to the PCIe spec. It wasn't difficult to fix, and I don't remember having the same issues after I made my changes.

 

4. Yes, the changes I made have worked nicely. I don't get my ISR spinning endlessly and I haven't had a single crash in 1 year of uptime.

 

Hope this helps.

-Doug

0 Kudos
Reply
dougst41
Contributor
Contributor
17,716 Views
Registered: ‎04-04-2011

Just a note, have a look at UG654 page 106. There is a timing diagram and reasonable description of how the interrupt controller should drive the signals in question. I'd suggest you check your signals (via chipscope) against the spec.

 

Cheers,

-Doug

0 Kudos
Reply
kakaroto
Observer
Observer
17,712 Views
Registered: ‎07-10-2013
Hi, d I believe I found the reason! Yesterday, I look through the UG517 about the interrupt generation section. It is said that: The core then asserts cfg_interrupt_rdy_n to indicate the interrupt deassertion has been accepted. On the following clock cycle, the User A pplication deasserts cfg_interrupt_n and the core sends a deassert interrupt message (Deassert_INTA, Deassert_INTB, and so forth). But I paid no attention to the Deassert of the INTA timing diagram. and the original logic is right, I set the cfg_interrupt_legacyclr bit as 1'b1 when the driver enters the ISR, the driver doesn't receive interrupt any more! Thank you for your help!
0 Kudos
Reply
wdxxyj327519
Newbie
Newbie
1,442 Views
Registered: ‎09-26-2018

hi, I am new in PCIe, and I have the same question now, can you tell me how to set "the cfg_interrupt_legacyclr bit as 1'b1" ? Can I set the bit in windows drivers in win7, or must in the FPGA programs?

thank you for your help.

0 Kudos
Reply
venkata
Moderator
Moderator
1,417 Views
Registered: ‎02-16-2010
This thread is fairly old. If the discussion does not help to answer your query, please create a new thread.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Reply