The Xillybus Forum

Sorry, that part had nothing to do with simulation. It was a general query to make sure that when the design is loaded on the hardware, the driver obtains the correct addresses for dma mapping.
With the simulation, it was observed that the tlps are transferred to the rootport if the payload size is 16 or 32DW. I am still not sure if this is only a testbench limitation.

This is a correct way to obtain the DMA address allocated in a real system. But it has nothing to do with the address to be used in a simulation, unless you happen to run the simulation against a simulated PC with a Linux system running on it.

Hi Eli,

Thanks for your suggestion, I am looking into the support docs. I have a doubt with the kernel driver for performing DMA. I use pci_alloc_consistent (pcie_dev, PAGE_SIZE * (1 << memorder), &dma_handle) function to get the cpu virtual address for viewing the data received. I sent the "dma_handle" to my PCIe device by writing to its register.
Is there a better way to get the memory dump to where the device sent the DMA writes to?

The root complex doesn't have a BAR interface. In a real-life scenario, the software driver allocates memory and tells the peripheral the physical address of that memory through an application-specific interface, usually by writing to the peripheral's registers.

So I suppose you should be looking in the simulation kit's documentation for the address range, that is allocated to the associated memory. Or try to find it in the sources.

Hi,
thanks for the reply.

Yes, I took the values from the specified cfg signals before but it did not work with that configuration either. i still get a fatal error detected. It also is possible that the address specified does not cause a BAR hit at the Rootport side. How can one find out which addresses have been allocated for the rootport itself? Or how can this be configured (self configuration writes?)

(The topics were merged, since it looks like the same person asked the question twice)

The endpoint should set the requester ID field according to the configuration which the root port has set for it. It's true that in most cases this happens to be 0x0100 if there's only one PCIe device in a typical PC, but the root complex is free to set this to anything it likes. This is not a simulation issue, but a misconception that may lead to a functional failure.

You should obtain the requester ID from the PCIe' block's cfg_bus_number[7:0], cfg_device_number[4:0], cfg_function_number[2:0] signals as described in the User Guide for 7 Series FPGAs Integrated Block for PCI Express.

Hi Eli,

I am using 7 series Endpoint Configuration for PCIe. I am unable to simulate DMA transactions from the endpoint to the rootport(dsport of Xilinx PIO design). The bits in the command register are set (0,1,2). I do not see my mem write tlp from the endpoint reaching the rootport(axi signals) at all. However a cfg_dev_status_fatal_error_detected is set on the rootport pcie ip core. What could be the reason? THe tlp looks fine to me (in terms of header and payload) except that I have a doubt regarding the requester id field(even though ts optional for MEMWRs). Could you suggest reasons for this?

Thank you!

Hi!

My IP core for 7series fpga is configured for an endpoint.I am trying to simulate DMA operations from the endpoint to the rootport using the RootPort Model Testbench from Xilinx(with the PIO design). However, the MEMWR request is not passed on to the rootport(dsport) and on a detailed look, cfg_dev_status_fatal_error_detected is set at the PCIe core of the rootport side. I have checked my tlp for payload size(128DW) and the header looks okay to me. My only doubt is the requester id. I have configured it with the requester id 0x0100 (as seen from lspci).

Also on loading the design on fpga, i see no data on the associated memory. There could also be a possibilty that the address is out of range for the rootport. How can one check that?

Thanks a ton!
Sati