Hi,
As you've surely noticed, Xillybus is a complicated beast, so I won't be able to cover general "how does it work" questions. But I'll try.
1. In XPS, the xillybus IP core is instantiated in the PL. In ISE, there is another module called xillybus_core. I assume the xillybus IP in XPS is a PCIe IP with AXI interface while the xillybus_core in ISE packs and depacks the TLPs. Is my understanding correct?
xillybus_core is the actual IP core. xillybus.v or xillybus.vhd is just a wrapper, which is there to present a more convenient interface.
There is no PCIe logic at all in Xillybus for Zynq, and accordingly no TLP to pack or unpack. The core talks directly with the AXI bus.
2. I am not much into DMA. But at least, there should be a DMA controller for DMA. In XPS, the DMA controller( the green block named after "DMA8 Channel") seems not enabled (none of its interfaces are enabled). Where is the actual DMA controller for xiilybus loacted?
The DMA controllers in XPS relate to the processor's own controllers, which can be programmed for copying chunks of data. But this is by far not the most common way to perform DMA operations on an AXI bus. Xillybus, like most other peripherals, requests DMA cycles directly from the AXI bus by attaching to it through a master port.
3. Is there any documentation specifying how the host driver works? I tried to read the driver source code xillybus.c. But it is too hard for me to understand such a complicated project. I am eager to know how the driver switches on/off the DMA transfer.
Unfortunately, there is no such documentation. Anyhow, the driver doesn't switch DMA transfers on and off -- it's merely tells the hardware where the buffers are, and gives it permission to access them. It's the hardware that initiates the actual transfers.
4. There is an interrupt from Xillybus to the host. When will the XIllybus trigger the interrupt? Is the interrupt handler included in the host driver?
The interrupt handler in the driver is xillybus_isr(). The hardware triggers this interrupt, well, when it has something to tell the driver. As the mechanism is rather complex, I won't dive into the details.
5. Also there is another interrupt from the host to the Xillybus? When will the host trigger this interrupt? How does Xillybus respond?
No, there's no hardware from the host. The host writes to the hardware's registers when it needs to notify it about something.
6. I use plain read()/write() to send/receive data. My code follows the template of the C code example from
http://xillybus.com/tutorials/vivado-hls-c-fpga-howto-2. A typical loop used in the C code is like the following :
[...]
We keep doing read()/write() in a loop until the desired number of bytes is transferred. I am curious about when a single read()/write() returns? Take write() for instance, does it return when the DMA buffers are full?
Assuming that you're using the demo bundle's IP core, write() just copies the data into a DMA buffer and returns immediately. The only reason it has not to return right away is if there's no space in any DMA buffer, in which case it waits (sleeps or "blocks") until such space is available. The actual data transfer takes place "in the background".
Please refer to the "Xillybus host application programming guide for Linux" guide, which deals with these issues in depth.
7. When read() is called and the FPGA cannot send any data in response (the FIFO is empty), it seems that the current thread pauses until the arrivals of the data. Why could such a pause happen?
Indeed, read() waits for data to arrive by blocking. I assume that you had one thread writing and one thread reading data. As your application logic handles its data at a certain pace, and the thread reading data just tries to slurp as much as it can, it's quite natural that it will finish up all data momentarily.
I hoped this covered most of what you wanted to know.
Regards,
Eli