- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I am using the PCIe IP (9.0). I recieve posted and non-posted TLPs from the host (PC) and send completion TLPs back and everything works great. However, when I initiate an MRd from the target (IP core) to the PC, I see the tlp transmitted then a few clocks later, the PC root complex responds with the correct rx_desc and rx_data. However, the rx_req never gets asserted. Is there something special I need to do the enable completions from the host to assert the rx_req? I will provide any info on my setup if needed. Thank youLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sounds like a bug that Altera needs to fix. If you can receive requests and send completions, then overall the core is setup correctly. Figures 5-40 and 5-41 show received completions with rx_req behaving correctly, so clearly the megafunction and user guides do not match. Hopefully, for now, you can design your logic to detect the completion and data without use of the req. Do the dfr and dv nets work correctly? You could attempt to alter the receive performance settings, or maybe switch to a legacy interface if possible, but I am very skeptical that these would fix anything.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
fuzzyRobb, I will play with the performance settings and see what happens. Right now, I have them set to the default values. Here is more info:
The dfr and dv nets work perfectly when I am receiving tlps and sending completions. While I do see the correct data coming back from the host, it is not the whole data - I am requesting 4 dwords and I only get one. I believe I need to get the rx_req so that I can assert the rx_ack and hopefully more data will come after that. I think the host is waiting for my rx_ack. I will try your suggestion and just assert rx_ack and see if I get a dfr and/or df assertion. One thing I do see on the rx_desc from the host is that [135..128] is 8'b00000001 indicating that bar0 was hit. According to the documentation, when a completion is received from the host, none of those bits should be set. I have tried to change all kinds of fields on my tx_desc thinking there is something I am missing but with no luck.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think acking will help too, although if your address is QW aligned you should see all 64 bits on the data bus, so it may be a deeper problem still. A warning pops up in 9.0 and 7.2 when I compile (mysteriously not in 8.0 and 8.1 though) that warns the ip is still preliminary, so I guess the best thing to do is watch altera's website for patches and updates.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I opened a ticket with Altera. They want me to check my design and run it in a testbench. I think I will do that and see. It is weird though since everything else works. Even MRw TLPs from the target to the host work fine. What I am wondering is if the logic that is responsible for asserting the rx_req is different depending on whether the rx_desc from the host is a completion rather than a new TLP. If that is the case, then there could be a possibility that something is getting optimized out...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I created a module to simulate the signals that the pcie core is supposed to be asserting when the completion comes back and everything works as it is supposed to. But, back to the real thing, I am suspecting the completion logic is being optimized -- specifically, the optimization report includes this highly suspicious line:
pcie_handler:u_pcie_handler|mypcie:u_pcie|mypcie_core:wrapper|altpcie_64b_x4_pipen1b:altpcie_64b_x4_pipen1b_inst|pciexp4x125_pipe:core_inst|pciexp64_trans:trans|pciexp64_rxtl:rxtl|mem_cpl Could this mean the memory completion logic is being optimized, and hence no rx_req? The reason it was optimized was "Stuck at GND due to stuck port data_in" Has anyone seen this before?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Found it! In assembling the MRd TLP, I reversed the byte order of the requester ID because of different byte numbering between the TLP documentation I had and the tx_desc. Now, it works fine.
This is interesting though since it explains why only the MRd's did not work and also says that the root complex couldn't care less about where the requests are coming from.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello ,
After sucessfully work with BFM for my Cyclone IV GX I am seeking to implement a very simple MRd and WRd Transaction mit VHDL for a better Understanding of all the process within the core. Please can anybody give me any help for that? Regards,- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page