mem read interface question

Post a reply

Confirmation code
Enter the code exactly as it appears. All letters are case insensitive.
Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:
BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON
Topic review
   

Expand view Topic review: mem read interface question

Re: mem read interface question

Post by andylgh » Fri May 22, 2020 10:46 pm

ok,thanks for your reply

Re: mem read interface question

Post by support » Fri May 22, 2020 10:00 am

Hello,

Yes, this is what I mentioned earlier: Because the FPGA side doesn't know if the addr_update is a preparation for a read or write, it must perform a read operation on the other bus to have the value prepared. One could get around this with some dirty trick maybe, but if this is an issue, I would suggest dropping the address interface altogether, and go for a command-data approach instead.

For example, say that you use a plain 32-bit Xillybus stream from the host to the FPGA to send commands. Bits [5:0] could be the address, and bit 31 could be the read/write flag: If it's 1, it's a write command, if it's 0, it's a read. And if it's a write command, set the value to write in bits [15:8], for example.

Then, if it's a read command, use a simple 8-bit FPGA to host stream to return the value when it's ready. You could put a FIFO inbetween and write the read data into the FIFO, or interface with the core directly, by manipulating the empty wire.

Plain, simple, and gives you full control over what's going on.

Regards,
Eli

Re: mem read interface question

Post by andylgh » Fri May 22, 2020 2:10 am

support wrote:Hello,

If the neither the empty signal nor the data input change as a result of the read cycle, the rd_en signal can indeed be ignored. So controlling the empty signal only based upon _addr_update will do the work, however you won't be able to read more than a single memory cell this way.

Regards,
Eli


in some applicaiton, if i want to use the the mem_intf bridge to axi4 lite to read and write reigister, is it possible?

host : lseek + write -> addr + wdata
host: lseek + read -> addr + rdata

write : i can use wren and the full to delay , if i capture wren i can active full to high ,only pull low when axi lite write done
read: i want to use addr_update,but when lseek + write in host also generate addr_update? is it any method to solve it?

Re: mem read interface question

Post by support » Thu May 21, 2020 3:22 pm

Hello,

If the neither the empty signal nor the data input change as a result of the read cycle, the rd_en signal can indeed be ignored. So controlling the empty signal only based upon _addr_update will do the work, however you won't be able to read more than a single memory cell this way.

Regards,
Eli

Re: mem read interface question

Post by andylgh » Thu May 21, 2020 1:05 pm

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

Re: mem read interface question

Post by support » Thu May 21, 2020 12:47 pm

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

Re: mem read interface question

Post by andylgh » Thu May 21, 2020 12:37 pm

support wrote: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?

Re: mem read interface question

Post by andylgh » Thu May 21, 2020 12:30 pm

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 ?

Re: mem read interface question

Post by support » Wed May 20, 2020 4:55 pm

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

Re: mem read interface question

Post by andylgh » Wed May 20, 2020 1:55 pm

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?

Top

cron