Forum Discussion
Occasional ContributorIncorrect values from TX-Fifo in Avalon PCIe Example
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
Regular ContributorHi,
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
ZarquinHello 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
