FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6424 Discussions

Incorrect values from TX-Fifo in Avalon PCIe Example

Zarquin
New Contributor II
1,491 Views

The endpoint TX-Fifo from the Avalon-ST Chaining DMA PCIe example outputs an incorrect tx_st_eop signal.


During a signal tap II analysis of the Chaining DMA example, I noticed that the tx_st_eop remains  high after one clock cycle instead of going low.
The error could be traced back to the TX-Fifo in the aaltpcierd_cdma_ast_tx_64.v module: The tx_st_eop signal is written correctly into the fifo and read incorrectly from the fifo.

See signal tap screenshot
data[131] = tx_st_sop at the Fifo input (yellow frame)
data[128] = tx_st_eop at the fifo input (yellow frame)
q[131] = tx_st_sop at fifo output (grey frame)
q[128] = tx_st_eop at the fifo output (grey frame)

The tx_st_eop at the FIFO output should actually follow the green line and go back to low (like the input). However, it remains high (red line = wrong).
The code comes from the Altera example and should actually be correct. But obviously something is wrong here.

Does anyone have an idea what could be causing this?

 

(The endpoint side of the example runs on a Cyclone V GT Dev Kit.
The Cyclone V GT Dev Kit is plugged into the PCIe slot of a Cyclone V SoC Dev Kit on which the root port sample code is running.)

 

---

Screenshot:

Screenshot: TX-Fifo-SignalsScreenshot: TX-Fifo-Signals

 

TX-Fifo instantiation from altpcierd_cdma_ast_tx_64.v :


scfifo # (
  .add_ram_output_register ("ON") //=speed ,
  .intended_device_family (INTENDED_DEVICE_FAMILY),
  .lpm_numwords (TXFIFO_DEPTH),
  .lpm_showahead ("OFF") ,
  .lpm_type ("scfifo") ,
  .lpm_width (TXFIFO_WIDTH) ,
  .lpm_widthu (TXFIFO_WIDTHU),
  .overflow_checking ("ON") ,
  .underflow_checking ("ON") ,
  .use_eab ("ON")
)
tx_data_fifo_128 (
    .clock (clk_in),
    .sclr (srst ),

    // RX push TAGs into TAG_FIFO
    .data (txfifo_d),
    .wrreq (txfifo_wrreq),

    // TX pop TAGs from TAG_FIFO
    .rdreq (txfifo_rdreq),
    .q (txfifo_q),

    .empty (txfifo_empty),
    .full (txfifo_full ),
    .usedw (txfifo_usedw)
    // synopsys translate_off
    ,
    .aclr (),
    .almost_empty (),
    .almost_full ()
    // synopsys translate_on
);

 

 

0 Kudos
1 Solution
FvM
Valued Contributor III
1,377 Views

Hi,
still think that it's a misinterpretation of  tx_st interface data. st_data and st_sop and st_eop are only valid while st_valid is active. I know that in typical Avalon ST examples, sop and eop are reset together with valid, but as far as I understand, it's not required by the specification. See this explanation of valid signal:


Asserted by the source to qualify all other source to sink signals. On ready cycles where valid is asserted, the data bus and other source to sink signals are sampled by the sink, and on other cycles are ignored.

Regards,
Frank

View solution in original post

9 Replies
FvM
Valued Contributor III
1,471 Views

Hi,
do you observe an actual misbehavior of the PCIe IP? The shown screenshot shows expectabable FIFO behavior, the last read result is kept til next read. If there's an issue at all, it's not the FIFOs responsibility.

 

Expected processing on the sink side:

- perform a read if empty==0

- evaluate the fifo output once in next clock cycle

0 Kudos
Zarquin
New Contributor II
1,449 Views

Hello FvM,

 

well, the problem is that the TX-Tranfers don't look correct as I mentioned above:
I noticed that the tx_st_eop remains  high after one clock cycle instead of going low.

 

It looks like this:

Wrong tx_st_eop SignalWrong tx_st_eop Signal

and further like this

 

More wrong tx_st_eof signalsMore wrong tx_st_eof signals

 

0 Kudos
wchiah
Employee
1,405 Views

Hi,


I suggest that a counter can be used to count the tx_st_ready signal as low. When the tx_st_ready signal is high, the counter is cleared to 0. When the tx_st_ready signal is '0', the counter is incremented by 1.


  • Add the tx_st interface and count value to the signal list in Signaltap, and change the trigger mode to pre-tirgger.
  • Set the trigger condition to the count value reaching 300 or 500, so that the TLP packets sent by the user logic before tx_st_ready is '0' can be sampled. We can check whether there is a problem with these TLP packets.


Regards,

Wincent_Intel


0 Kudos
Zarquin
New Contributor II
1,391 Views

Hello Wincent,

 

I don't quite understand the idea? Could you explain it?
The tx_st_ready signal is high all the time. This can also be seen in the signal tap screenshots above.

To be sure, I triggered for the state tx_st_ready = 0 in Signaltap. Result: : The state was never triggered.

 

Regards

Zarquin

0 Kudos
FvM
Valued Contributor III
1,378 Views

Hi,
still think that it's a misinterpretation of  tx_st interface data. st_data and st_sop and st_eop are only valid while st_valid is active. I know that in typical Avalon ST examples, sop and eop are reset together with valid, but as far as I understand, it's not required by the specification. See this explanation of valid signal:


Asserted by the source to qualify all other source to sink signals. On ready cycles where valid is asserted, the data bus and other source to sink signals are sampled by the sink, and on other cycles are ignored.

Regards,
Frank

Zarquin
New Contributor II
1,201 Views

Hello FvM,

 

"I know that in typical Avalon ST examples, sop and eop are reset together with valid, but as far as I understand, it's not required by the specification. See this explanation of valid signal"

After further observations, I think your explanation is correct.

 

Thank you very much

Zarquin

0 Kudos
wchiah
Employee
1,342 Views

Hi,


According to your case about tx_st_ready not triggering.

First, Tx_st_ready deasserted indicates that the Transaction Layer is not ready to accept data for transmission.

In this case PCIe core will deasserts st_ready to throttle the data stream.

There are many possible causes for deassertion of tx_st_ready, there were documented in Chapter 18 (Table 18-2) of Cyclone V PCIe User Guide:

See section 'Debugging Link Failure in L0 Due To Deassertion of tx_st_ready'

https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_c5_pcie_avst.pdf

- Avalon-ST signaling violates Avalon-ST protocol

- Incorrect payload size

- Flow control credit overflows

- Malformed TLP is transmitted

- Insufficient Posted credits released by Root Port

- Missing completion packets or dropped packets

Kindly review the above possibilities, such as all previous transactions had started with a proper SOP and terminated by an EOP.


Regards,

Wincent_Intel


0 Kudos
wchiah
Employee
1,308 Views

Hi,

 

I wish to follow up with you about this case.

Do you have any further questions on this matter ?

​​​​​​​Else I would like to have your permission to close this forum ticket

 

Regards,

Wincent_Intel


0 Kudos
wchiah
Employee
1,289 Views

Hi

 

We have not hear from you and this Case is idling. It is not recommended to idle for too long.

Therefore following our support policy, I have to put this case in close status. My apologies if any inconvenience cause

Hence, This thread will be transitioned to community support.

If you have a new question, feel free to open a new thread to get support from Intel experts.

Otherwise, the community users will continue to help you on this thread. Thank you

If your support experience falls below a 9 out of 10, I kindly request the opportunity to rectify it before concluding our interaction. If the issue cannot be resolved, please inform me of the cause so that I can learn from it and strive to enhance the quality of future service experiences. 

 

Regards,

Wincent_Intel


0 Kudos
Reply