Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
7 years ago

[Cyclone V PCIe Hard IP]: Avalon to PCIe read issue

Dear all,

We are using Cyclone V PCIe Hard IP core with Quartus 16.1. We are using requester/completor mode so that we can perform PCIe read and write operations from Avalon master. In our design, we are using DMA controller which is connected to Txs component of PCIe and with onchip memory. And here is the problem and our observations so far.

  1. When we configure DMA to transfer data from offchip meory (via Txs of PCIe) to onchip memory, after some time strange issue happens. Txs slave accepts read requests generated by Avalon master (DMA) by de-asserting wait_request but does not generate read_data_valid. And hence our DMA hangs.

  2. Note that if I configure DMA to transfer only 4 bytes each time, it works well each time. But if I set DMA length to 8,16,32 or 64, it hangs.

  3. We are not facing issue with PCIe write. I mean if I configure DMA to read data from onchip memory and transfer it to offchip memory via Txs of PCIe, it works each time.

  4. We have checked this with Intel (Altera's) 32 bit DMA controller and with our own DMA controller.

If anybody could point us where we should be looking for to identify the root cause for this, we would appreciate.

Thank you,

Bhaumik

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    7 years ago

    Hello, Bhaumik

    I've had the same problem on completing read operations (move data from the offchip memory to an internal module) for the Arria 10 device using a similar PCIe Hard IP and External Memory Interface controller. The master interface generated a read request and slave accepted it by de-asserting wait_request but not generating the readdata_valid flag. It turned out that I have a problem with my burstcount values. The following changes solved the problem:

    1 - I had to make sure that master and stave burstcount ports had the same width;

    2 - Burstcount values, in my case, had to be 7 bits long but the max burst value should less than or equal to 2^6 = 64. Even so, I notice that internally the external memory interface splits bursts greater than 8 into several small 8 words bursts.

    Remember that bursts are counted in number of blocks, not words. I mean, if your emif readdata port is 512bits long (16 words), a burst value 8 will generate 512*8 bits answer (128 words). The readdata_valid signal will be up for 8 clock cycles, with each cycle bringing 512 consecutive bits from the external memory.

    I hope this information will help you.

    Regards
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    7 years ago

    Hello,

    Thank you very much for your response. I will check this and will come back to you.

    Apart from this, I would like to know whether it was happening during each read operation in your case or was happening sometimes. In our case, if we configure DMA to transfer 64 bytes, we are getting success in first few transfers and then we are facing such issue.

    Warm Regards,

    Bhaumik
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    7 years ago

    Hello, Bhaumik

    --- Quote Start ---

    Apart from this, I would like to know whether it was happening during each read operation in your case or was happening sometimes. In our case, if we configure DMA to transfer 64 bytes, we are getting success in first few transfers and then we are facing such issue.

    --- Quote End ---

    Exactly like that. Note that, in our case, 64 bytes (512 bits) were equivalent to burscount=1, or no burst at all, because our readdata port width was exactly 512bits wide. The problem seems to be that EMIF is not accepting burst transfers when burtscount port widths don't match. I don't know why this problem happens and, for me, it seems like a very strange behavior.

    Another point: this problem, for me, started when I updated from Quartus 17.0 to Quartus 18.0.

    I hope this will help you

    Regards
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    7 years ago

    Hello,

    Thank you.

    Burst doesn't seem an issue in our case. Because in our case, our master does not support burst operation and hence burst value provided by interconnect fabric to PCIe's TXS component is always 1 when we use our DMA master. If there is something else which you think we should be looking for, please let us know.

    We are going to install Quartus 17.1 to see whether it helps or not.

    Many thanks again,

    Bhaumik