10-23-2019 09:15 PM
(Please help me out, I had earlier posted a detailed query but it was marked as spam without any notification)
I am trying to Soft Reset QDMA IP instantiated in design. Properly Asserting and De-Asserting Active Low Reset Signal, have captured it in ILA. Instead of getting Reset the QDMA IP is getting hang.
(Board Used: Alveo U200 Accelerator Card)
10-26-2019 01:31 PM
A soft reset of an AXI bus can only do so much to reset the bus. If you are interacting with something that misbehaves, the software reset won't help--the design will be locked anyway.
One option is to use Xilinx's firewall core. This core will detect any failures in downstream cores to follow the AXI standard, and guarantee that such failures will not propagate upstreram. You can then use the failure indication output as a trigger for an ILA capture to find out what's going on.
There's also an open source Bus Fault Isolator which you can use. This is similar to Xilinx's firewall, save that it also supports an option of resetting the downstream core automatically on any failure to adhere to the AXI protocol.
10-29-2019 12:53 AM
@dgisselqThanks for your response.
Incorporating Xilinx's firewall core IP in my design and checking w.r.t AXI Protocol mis-match.
But, I am doubting QDMA IP internal Configuration Space Register Update after Soft Reset. Following is the sequence I am following which results in hang.
1. Initial Powering up of board. (QDMA IP with AXI-MM is used in my design)
2. From Host add H2C and C2H Queues with queue ID 0 and 1.
3. Carry out dma_to_device and dma_from_device number of times. (Everything is working fine)
4. Delete H2C and C2H queues.
5. Write Register Address 0x00000000 of Bar 2 with 0x00000001 so that Soft Reset is initiated inside hardware logic.
6. Hardware logic asserts active low reset of QDMA IP for 100 cycles and then de-asserts.
7. Carry Out Step 2
8. While Carrying out Step 3, I get following errors:
/dev/<device_id> , W off 0x0, 0x40 failed -1.
write file: Input/output error
/dev/<device_id> , read off 0x0 + 0x2 failed -1.
read file: Input/output error
11-03-2019 08:32 PM
One more observation. Even in Example Design Provided by Xilinx with QDMA IP for QDMA_AXI_MM_COMPLETION there is a control register named DMA_CONTROL (0x0A0) and  bit of the Register is used to assert Soft Reset.
I have even tried to Soft Reset Example design. The Soft Reset signal is getting asserted for about 100 cycles and then getting de-asserted. But again QDMA IP is going in hang state and no further DMA transfer can be carried out.
Have a bit file generated and scopeshot of the ILA with me of Reset Assertion. Please have a look in this issue as it seems to be something related to internal logic of QDMA IP.
11-03-2019 10:27 PM
Also one more question,
After reset of QDMA IP DMA section, are their any Bar 0 Configuration Registers to be updated ?
Answer to this question may help in finding solution.
01-26-2020 11:59 PM
Please help resolve this issue. I have been kept stranded for more than 2 months. Currently I am not Resetting QDMA IP in my design because of the hang state.
01-28-2020 04:08 PM
Why are you resetting the QDMA core itself? If you actually need to reset the QDMA core, you might as well reset the whole design, including the PCIe interface as well. It is usually possible to trigger an in-band "hot reset" that will reset the entire design. If you do that, you'll also have to reload the driver on the host. Alternatively, be more selective about what is getting reset. Don't reset the QDMA core, only reset the required downstream logic, and make sure things are properly configured so that the logic can be partially reset without causing other problems (for example, you'll have to ensure in-flight AXI operations don't get lost during a reset).
01-28-2020 07:45 PM
Thanks for your inputs @aforencich
Don't reset the QDMA core, only reset the required downstream logic, and make sure things are properly configured so that the logic can be partially reset without causing other problems (for example, you'll have to ensure in-flight AXI operations don't get lost during a reset).
Yes indeed, in my design I am resetting All the sub-modules except QDMA IP Core. And everything is working fine.
Why are you resetting the QDMA core itself?
Actually this came as a requirement that all the sub-modules (including QDMA IP core) have to be reset. Now that it is clear,
If you actually need to reset the QDMA core, you might as well reset the whole design, including the PCIe interface as well. It is usually possible to trigger an in-band "hot reset" that will reset the entire design. If you do that, you'll also have to reload the driver on the host.
Will discuss this implications w.r.t host driver reload and accordingly take a decision.
01-30-2020 06:57 AM
I would agree: only reset those portions of your design that actually need to be reset.
An AXI master is difficult to reset without needing to reset everything downstream of it. Since this would include the AXI interconnect, that typically turns into a reset requirement of the entire design. This would be worth explaining to any customer that has given such a requirement.
There are ways to just reset particular AXI slaves without needing to reset the entire design that we could discuss, if you had a different requirement.
02-09-2021 11:05 PM
So Xilinx folks didn't responded to it. They have provided Soft Reset Pin with QDMA IP, but if try asserting Reset via this pin than QDMA IP does not work after that and Machine needs to be Reboot. Currently I am simply using a script to load-unload Drivers whenever I want to Reset QDMA IP and not using soft reset pin provided with QDMA IP.
The script is provided by @aforencich in a stackoverflow post.
04-09-2021 07:59 AM
Hi @irage_sd ,
I post a question about the correlation between soft reset and axi reset:
Infact, in case of XDMA, the first one (called dma_bridge_reset) implies the second one.
@aforencich, I'm thinking that on driver unloading the DMA part of the QDMA should be reset with all the related custom logic with the IP which drive the soft reset able to automatically de-assert it after 100 cycles in order to be controllable by the driver.
This will guarantee a clean state through all the design on driver re-loading (no axi transaction or packets in flight along the way).
What do you think?
Thank you, best regards.