mem read interface question

[andylgh]

i use python to test demo in win7，code show below：
if __name__ == '__main__':

f_src = open(r'\\.\xillybus_mem_8','wb')
#write 0x50 to mem_8
f_src.write('\x50'.encode())
f_src.close()

f_src = open(r'\\.\xillybus_mem_8','rb')
# read mem_8
rdata = f_src.read(1);
print (rdata.decode())
f_src.close()

the test reslut is success,but I use FPGA ILA to capture mem_8 interface signal
i find write mem_8_wren is only assert one bus_clk cycle，but mem_8_rden assert many bus_cycle，Repeat read address from 0~31 many times，is it normal？

[support]

Hello,

It might be that Python's implementation of read() does buffering. In other words, it seems like it reads ahead of the single byte you requested, and caches that data. I'm not very good with Python, but it seems like you need a more low-level function set for the I/O.

Regards,
Eli

[andylgh]

<<xillybus_getting_started_windows.pdf>> use
hexdump -C -v -n 32 \\.\xillybus_mem_8
to test，i find the same in fpga ila，it read many times，repeat read 0~31 many times
is any suggest，if i send read（）function，it only read one time

[andylgh]

the xillybus_core support PCIE MSI interrupt？

[andylgh]

user r {devfile} empty – This core input signal informs the core that no more
data can be read. When asserted properly, it temporarily assures no read cycles
occur. The ’empty’ signal may transition from ’0’ to ’1’ only on the clock cycle
following a read cycle. This is the way standard FIFOs behave, so this rule
needs attention only if the IP core is interfaced directly with application logic
(i.e. no mediating FIFO). The reason for this rule is that the Xillybus logic treats
an non-asserted ’empty’ signal as a green light to start a data transaction with
the host. Failing to observe this rule may cause sporadic reads overriding the
’empty’ condition.
A typical Verilog implementation of the ’empty’ signal should be something like
this:
always @(posedge bus_clk)
if (ready_to_give_more_data)
user_r_mydevice_empty <= 0; // Deassert any time
else if (user_r_mydevice_rden && { ... some condition ... } )
user_r_mydevice_empty <= 1; // Assert only with rden

user can assert empty to stop many times repeat read？

[support]

Hello,

First, regarding MSI. I can't see how it's related to this topic, but yes, Xillybus uses MSI interrupts for interfacing with the host. I don't see the meaning behind "supporting MSI", but it uses it, yes.

As I mentioned earlier, the reason for the multiple reads is most likely that Python uses buffering access to the device file. So it actually reads those extra bytes and holds that data in RAM. Trying to control it with the 'empty' signal is not likely to be a useful solution. You will still have that extra layer of buffering that may mess up things for you.

Please take a look on the C utilities in the Xillybus package for Windows (available at the main download page). The memread and memwrite utilities demonstrate how low-level I/O is done in C. With these, you won't see those extra read cycles. The problem should be solved on the host side.

As for Python, I'm not sure, but it looks like the issue is answered nicely on this page:

https://stackoverflow.com/questions/214 ... -in-python

Regards,
Eli

[andylgh]

i try the mothed low level func it work success

# coding: cp936
import os
import sys
if __name__ == '__main__':

f_dev = os.open(r'\\.\xillybus_mem_8',os.O_RDWR | os.O_BINARY)
print(f_dev)

if os.lseek(f_dev, 1, os.SEEK_SET) < 0:
print("lseek error")


ret_num = os.write(f_dev,'\x40'.encode())
print("ret_num = %0d"%(ret_num))


#os.fsync(f_dev)


if os.lseek(f_dev, 1, os.SEEK_SET) < 0:
print("lseek error")

ret_num = os.read(f_dev,1)
print(type(ret_num))
print(ret_num)

os.close(f_dev) # 关闭文件

now i have another question: in some bus for example axi4 lite when rd_en is valid but return rdata is delay some bus_clk（mean i want delay the rdata not following clk cycle），the xillycore mem interface can do this ？

[andylgh]

Hello,

First, regarding MSI. I can't see how it's related to this topic, but yes, Xillybus uses MSI interrupts for interfacing with the host. I don't see the meaning behind "supporting MSI", but it uses it, yes.

As I mentioned earlier, the reason for the multiple reads is most likely that Python uses buffering access to the device file. So it actually reads those extra bytes and holds that data in RAM. Trying to control it with the 'empty' signal is not likely to be a useful solution. You will still have that extra layer of buffering that may mess up things for you.

Please take a look on the C utilities in the Xillybus package for Windows (available at the main download page). The memread and memwrite utilities demonstrate how low-level I/O is done in C. With these, you won't see those extra read cycles. The problem should be solved on the host side.

As for Python, I'm not sure, but it looks like the issue is answered nicely on this page:

https://stackoverflow.com/questions/214 ... -in-python

Regards,
Eli

about MSI ， FPGA PCIE IP is support ，if i generate the msi to host ， host driver can notice it ？ user app how to kown fpga generate msi interrupt？

[support]

Hello,

It's possible to work with a slower memory device, as discussed in section 3.4 (regarding *_addr_update) of the Xillybus FPGA designer’s guide:

http://xillybus.com/downloads/doc/xillybus_fpga_api.pdf

It might however be better to implement a simple command / data protocol with regular, non-address streams instead for accessing such memory units, in particular if it's important to control which accesses are made. With the Xillybus mem interface, you will have to perform a read operation on the application memory unit every time a seek is done on the host, so that the "empty" signal can be deasserted. This will happen even if you had no intention to read the value, but rather as a preparation for a write.

As for generating an MSI interrupt: You can't generate a hardware interrupt from the FPGA side, because the core takes control of that signal, and you can't accept that interrupt on the host, because hardware interrupts are delivered only to kernel drivers. What you probably want is to have your user-space software notified when something happens, which is discussed in section 6.4 of the Xillybus host application programming guide for Windows ("Emulating hardware interrupts"):

http://xillybus.com/downloads/doc/xilly ... indows.pdf

Regards,
Eli

Regards,
Eli

[andylgh]

Can I ignore Rd_ EN signal, keep the empty signal high all the time. I read the data first according to the update signal and addr signal, and then pull down the empty and return the rdata