Occasional ContributorIncorrect values from TX-Fifo in Avalon PCIe Example
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-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
);
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
