David Binette wrote:
> yes that is feasible for a small number of items and it my be 'plan-b' if no PCI bus solution is available to me.
> I like your suggestions, they are all reasonable and I'll take the best alternative I can get if I dont find a way to do this via PCIe
I'm still not sure on what exactly your requirement is. In one post you
write that you want to read from slow devices (like I2C). That would
mean the problem is this:
- you issue a PCIe read request
- this read request triggers something, e.g. a read from an I2C device,
which takes a certain time
- meanwhile, you cannot respond to the PCIe read request in time because
you haven't received the result yet
In that case, do what Lasse suggests: Have one register to trigger the
read and another one that can be polled via PCIe indicating when the
data is ready.
But in another post you write "the data is always 'ready' it is
continuously changing, on a faster clock domain", which is something
entirely different. Is it streaming data? Do you need to catch all the
data or do you want to read out only one single value occasionally? Is
it dependant on your read, meaning that your read requests initiates a
calculation or something that you want the result of, or is the data
totally independant and you only occasionally want to read the current
Since I don't understand what you really want to do, here's a few other
- You could just always transfer the data you have to the PCIe clock
domain whenever it changes. Each time there is a new value, always
transfer it to the PCIe clock domain immediately and put it e.g. into a
BAR register. So when you issue a PCIe read request, there's data
already there that you can put into your reply message immediately.
Worst case is you don't get the very latest value but the one before that.
- If you need to catch all the values, I'd put the data into a FIFO. You
could then e.g. issue an MSI (Message signaled interrupt) when the FIFO
is e.g. half-full (or keep polling prog_full or something) and then read
it out in a burst from the PCIe side. No need for clock-domain-crossing
for the read request, as you only read from the FIFO that has its read
port in the PCIe clock domain. No need for PCIe to wait for data too
long, since data from the FIFO is available one or two clock cycles
after the read request was issued (depending on how you configure the FIFO).
- If in your design the read request itself triggers something that
takes a while, do what Lasse suggests.