It's not easy to isolate issue when your design is complex and combined both PCIe and Ethernet IP together.
My advice is perhaps you can try out new design with just Ethernet example design only. Make sure everything works first (both Quartus design and your board) then only add in PCIe design to it.
Thanks for your support.
We tested example design thrice. tx_ready is behaving in the same way what I mentioned in my previous post.
Can you please guide us on how to isolate this issue?
Thanks. I have reviewed your signal_tap result. Below is my comment.
- I can see that o_tx_ready is toggling but there is also no proper Avalon ST Tx data transaction in the signal_tap like what we had in user guide (page 102, figure 33). Are you driving data to Ethernet TX interface at all ?
- I also noticed the signal_tap result still contains PCIe signal bus. Can you share with me the signal_tap result for standalone Ethernet example design only.
As I mentioned before, there could be 3 possibility that maybe impacting the Ethernet IP behaviour and we can rule them out one by one
- Potential Quartus design issue
- May I know are you using below example design to verify the Ethernet application ? Else can you test example design and show me the signal_tap result
- based on user guide guideline, there are 2 factor that can affect o_tx_ready signal
- ready latency setting and also don't send tx data packet until assertion of o_tx_lanes_stable signal
- Potential S10 device itself issue or board design or power up issue
- There is nothing much we can do about the S10 device for now but you can verify your board design first
- Are you using your own board or Intel FPGA dev kit board ?
- Typically area that you want to watch out is FPGA power, clocking and reset. Ensure you connect and power up them properly as per S10 pin connection guideline
I don't hear back from you after my feedback suggestion.
Hopefully you are able to make good progress with your project development
For now, I am setting this case to closure.