bslathi19
  • Joined on 2025-11-07
bslathi19 commented on issue bslathi19/alibaba_pcie#1 2025-11-11 22:52:52 -08:00
PCIe DMA

Interesting, in the example they enable client tag, should we try that?

bslathi19 commented on issue bslathi19/alibaba_pcie#1 2025-11-11 22:18:10 -08:00
PCIe DMA

ok the only thing of note here that I can think of is that the sequence number is the same: 0. Do we need to change it so that we send different sequence numbers?

bslathi19 commented on issue bslathi19/alibaba_pcie#1 2025-11-11 21:57:50 -08:00
PCIe DMA

Here are the RC and RQ busses for the FIRST transfer, this is the one that is successful.

bslathi19 commented on issue bslathi19/alibaba_pcie#1 2025-11-11 21:15:54 -08:00
PCIe DMA

So the problem is that we are not writing to the memory again. We are seeing wr_cmd_valid for the first write, but not the second one. But read is still happening, so we are reading the nonsense data.

bslathi19 commented on issue bslathi19/alibaba_pcie#1 2025-11-10 22:40:32 -08:00
PCIe DMA

Huh, It looks like even though we read the second data, the data that we are writing back is still the old data. So its coming from the FPGA, not from the PC.

bslathi19 commented on issue bslathi19/alibaba_pcie#1 2025-11-10 22:39:05 -08:00
PCIe DMA

so for the RQ and RC streams, they are both 256 bit with 8 bits of keep only, RQ is 62 bits and RC has 75 bits of user.

So we can do a 75 bit tuser,

data: 256 keep: 8 user: 75 last:…

bslathi19 commented on issue bslathi19/alibaba_pcie#1 2025-11-09 22:34:49 -08:00
PCIe DMA

Hmm supposedly the core is still incrementing the tag when we send the request. I think we will need to look at the actual axi streams. they are like 256 bits wide though so it will be a pretty…

bslathi19 pushed to master at bslathi19/alibaba_pcie 2025-11-09 22:26:30 -08:00
df377dda5d Add ILA for debugging dma requests
bslathi19 commented on issue bslathi19/alibaba_pcie#1 2025-11-09 22:21:38 -08:00
PCIe DMA

Maybe we need to look at the RQ and RC interfaces? It might be that we are not getting a response from the cpu again? Maybe the CPU needs to see a second tag or something?

bslathi19 commented on issue bslathi19/alibaba_pcie#1 2025-11-09 22:19:04 -08:00
PCIe DMA

However, when we try the second read we do not see a status valid for the read.

bslathi19 commented on issue bslathi19/alibaba_pcie#1 2025-11-09 22:17:44 -08:00
PCIe DMA

Here are the original read request and the write request, right after a reboot. You can see that the read request is ack'd, then the status is valid. So is the write request.

bslathi19 commented on issue bslathi19/alibaba_pcie#1 2025-11-09 18:34:30 -08:00
PCIe DMA

We added this and it seems to be working, except that if we try to run it multiple times in a row, it doesn't end up overwriting the data. We may need to test this in sim and or get a trace on it…

bslathi19 pushed to master at bslathi19/alibaba_pcie 2025-11-09 18:33:50 -08:00
ce729f9008 Print out bytes after we read them
bslathi19 pushed to master at bslathi19/alibaba_pcie 2025-11-09 17:56:18 -08:00
32d18845e5 Add pcie test
bslathi19 pushed to master at bslathi19/alibaba_pcie 2025-11-09 17:33:57 -08:00
1a33af4ddf Add some dumb test code
bslathi19 pushed to master at bslathi19/alibaba_pcie 2025-11-09 16:02:58 -08:00
abc6ea65c5 Add write dma
bslathi19 pushed to master at bslathi19/alibaba_pcie 2025-11-09 14:13:05 -08:00
50275dc581 Add basic read dma functionality and test
bslathi19 pushed to master at bslathi19/fpga-sim 2025-11-09 14:10:25 -08:00
6cfa6ba36a Bump verison
bslathi19 pushed to master at bslathi19/fpga-sim 2025-11-09 14:09:58 -08:00
7e8e15932a Merge pull request 'dev/trace_fst' (#1) from dev/trace_fst into master
2d3d02eee9 Try 2
de3205bda7 Trace FST
Compare 3 commits »
bslathi19 merged pull request bslathi19/fpga-sim#1 2025-11-09 14:09:57 -08:00
dev/trace_fst