cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
1,550 Views
Registered: ‎07-17-2012

problem using dma_bridge_resetn in XDMA

Jump to solution

I have a full working system of the XDMA core using DMA RX direction with nice throughput results.

Nonetheless, I want to implement the internal reset signal since sometimes things are not working (I guess my user-logic controller messes things up when I'm not using it right). So, as written in the XDMA core manual, I want to reset the XDMA internal registers, without a reboot of the system.

I've implemented the dma_bridge_resetn signal in my design and no matter what I do, somethings get messy, meaning, my register interface, which is working on the DMA AXI_CLK output, stops working when I use it. I've now came to the point where 'Read' action is working - meaning, reading from a register to the application. 

Whenever I try to 'Write' something to a register, the whole system crashes, meaning I now cannot read or write to all registers. Reboot does not help and I need to re-flash the FPGA (and reboot, since it's PCI-E) . I've tried everything.

After reading the XDMA (4.1) core I've so far seems to understand the following:

Both the clk and the reset outputs from the XDMA core will be 'defected' somehow, after using this signal. 

image.png

image.png

I guess my register interface (which obviously is based on the XDMA core, since the communication is PCI-E based) will be defected.

Seems like it's cutting the branch I'm sitting on. Is that so??

P.S.

After alot of 'playing around', I'm passing to all components in my design the RST signal from the DDR MIG, and NOT the AXI XDMA core reset, with the XDMA AXI CLK. Even though it is not a correct method I guess, it is the best I could achieve (with the flaws written above).

0 Kudos
1 Solution

Accepted Solutions
Adventurer
Adventurer
1,467 Views
Registered: ‎07-17-2012

I've finally solved this issue. the bridge_resetn should be low for minimum of 50mS accodring to PG195, so I've designed a state machine that counts this time. The problem was as soon as the PCI-E transaction took place, bridge_resetn was set to low immediately and the state machine started counting. But, the PCI-E transaction has not yet finished, and it contradicts PG195 (bridge_resetn should be set low when no transactions occur).

So, what I did was to insert a small delay before setting bridge_resetn low and it solved this issue.

View solution in original post

0 Kudos
10 Replies
Highlighted
Xilinx Employee
Xilinx Employee
1,499 Views
Registered: ‎07-26-2012

Do you follow the following description in PG195?:

"When used, all PCIe traffic must be in quiesce state. The signal must be asserted for longer than the Completion Timeout value (typically 50ms)."

If you already do that, I recommend using the example design in the core first. If the design is already complicated, I think it should be tested from a simple state.

What I understand is the following situation:

1) PCIe-Link-up

2) Initial Setup for Bridge 

3) READ operation is successfully done

4) dma_bridge_resetn is asserted

5) Setup Bridge again

6) READ operation is successfully done

7) WRITE operation makes the whole design crashed

8) Need re-configuaration of FPGA

If the same thing does not occur in Example design, you will need to examine the differences with the current design. In order to solve an essential problem, please do narrow down.

 

 

4)

 

 

0 Kudos
Adventurer
Adventurer
1,468 Views
Registered: ‎07-17-2012

I've finally solved this issue. the bridge_resetn should be low for minimum of 50mS accodring to PG195, so I've designed a state machine that counts this time. The problem was as soon as the PCI-E transaction took place, bridge_resetn was set to low immediately and the state machine started counting. But, the PCI-E transaction has not yet finished, and it contradicts PG195 (bridge_resetn should be set low when no transactions occur).

So, what I did was to insert a small delay before setting bridge_resetn low and it solved this issue.

View solution in original post

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
1,457 Views
Registered: ‎07-26-2012

This reset is basically issued when the PCIe traffic is not occured:

"When used, all PCIe traffic must be in quiesce state. The signal must be asserted for longer than the Completion Timeout value (typically 50ms)." (( page 270, PG195))

Therefore, plase avoid resetting when traffic is ongoing.

 

0 Kudos
Highlighted
Contributor
Contributor
1,326 Views
Registered: ‎10-14-2018

Hi,

 

You wrote "Setup bridge agaiin" how do you do this?

my problem is after the reset is completed via the dma_bridge_resetn, the XDMA register space is zeroes out, and the only way to make the XDMA work again is either by a PC reset, or driver disable/enable via device manager.

 

How can you setup the XDMA register space after soft reset?

 

thanks!

0 Kudos
Highlighted
Adventurer
Adventurer
1,318 Views
Registered: ‎07-17-2012

Are you sure that the PCI-E transaction for this reset pin (calling the reset via register, or whatever other method you use) is finished before you actually use this reset pin?

Cause this issue can cause what you describe, I think...

0 Kudos
Highlighted
Contributor
Contributor
1,309 Views
Registered: ‎10-14-2018

Hi,

 

I init the reset from BAR0, by writing a register  into a user logic IP, after writing it, the user logic starts a counter, during this count time dma_bridge_resetn reset is asserted by user logic, once counter is done (> 50 ms), the user logic deasserts the reset.

 

so I do not interact directly with the reset pin from BAR0.

 

 

0 Kudos
Highlighted
Adventurer
Adventurer
1,299 Views
Registered: ‎07-17-2012

Seems this is exactly what I did which caused my problems. It maybe that your PCI transaction has not yet finished, but you reset the XDMA.

Try to add delay after writing to the user logic and BEFORE your counter delay (even the same delay, for ease of debug) and re-check.

0 Kudos
Highlighted
Contributor
Contributor
1,290 Views
Registered: ‎10-14-2018

Thanks, I will try to do it, but it seems my problem is more genral than that, because the reset pin was just a test to find a solution to a bigger problem:

 

after I reload my fpga (dual boot configuration), how do I also reload the XDMA register space without reloading the XDMA driver or resetting the PC. because right now, the only way to get XMDAS working after O reload FPGA from flash, is by disable/enable driver in device manager, or reset the PC. the problem is the register space, wichi gets reloaded only by these 2 methods.

0 Kudos
Highlighted
Adventurer
Adventurer
1,282 Views
Registered: ‎07-17-2012
How do you the XDMA register space is zeroed? Where do you see that?
0 Kudos
Highlighted
Contributor
Contributor
1,260 Views
Registered: ‎10-14-2018

I have access to XDMA IP stts/control registers through BAR_0

0 Kudos