VC707 IPbus - Working for some time and then it stops

Question

VC707 IPbus - Working for some time and then it stops

Closed this issue 5 years ago · 11 comments

Hi Everybody,

this is a follow up question on the thread I did some time ago about importing the IPbus to the VC707 board. After the discussion we had at that time, I modified the KCU105 baseX example design to operate in SGMII mode with AN on. This makes the connection to work and through the software I am able to ping to the VC707 board and read/write the registers I create. The issue is that after some time (around 5 mins) the ping freezes and then it goes to host unreachable. This behavior happens exactly at the same time from the moment you implement the firmware. I tried to debug it by looking at the status_vector of the sgmii core from the beginning and I saw that everything looks fine except bit number 4 which says that it's receiving only Idle words. The problem is that even when it's working the that is the same behavior. So from the working state to the non working state I don't see any difference on the signals I am debugging. Another test that I did is to compare the ports with the KC705 example design with GMII where there the clocking module which takes care also about the resets foresees a reset signals for the PHY chip. I tried to connect the rsto_eth reset from the KCU105 design to the reset PHY pin in order to make the design look the same, but this produced the same behavior (operating for some time and then it stops, no change in the status_vector and only Idle words in the gmii signals). Another difference I figured out is that in KC705 design there is an AXI4 FiFo for clock domain crossing for the RX signals in TEMAC. I configured this FiFo also in my design and implemented the firmware. Now there is a difference, the IPbus LEDs blink normally, the status_vector shows the right information, AN was performed but when I try to ping the host says that it is unreachable. Are there any ideas about the issue I am facing?? Thanks a lot in advance

Kind Regards
--ixiotidi

Answer 1 · 2018-07-18T19:10:42.000Z

You shouldn't need a FIFO with SGMII, the clock domain bridging is done inside the code.

My guess is this is a problem with routing on your computer. Can you spy on the interface (e.g. with wireshark) to see if any packets are moving in or out of the interface?

Answer 2 · 2018-07-18T19:39:22.000Z

Hi,

thanks a lot for the immediate response.
I will try to spy the data with wireshark, and let you know asap I have access to the board again. But, I would like to mention also that when I tried with the same PC with the KC705 board and the example design with the GMII interface the connection never dies. Unless, there is something I am missing I cannot understand why there should be a difference.
Also, what about the PHY reset, I remember in the previous thread I started about this you told me that I need to take into account the reset of the PHY which may produce a problem. In the example design of the KCU105 this is not taken into account since for the BaseX interface there is not PHY chip.
Finally, maybe I should mention also that when the connection is lost on the board side I can still see that the RX LED on the Ethernet cable is blinking which means that packages are being received from the cable.
Thanks again for the response.

Kind Regards
--ixiotidi

Answer 3 · 2018-07-18T21:42:54.000Z

The important thing is to work out which is broken, the transmit or receive path. The symptoms you describe are consistent with the transmit path out of the FPGA not working, but you should test this with wireshark, and then take a look inside the logic with chipscope to see if it's attempt to send a packet which doesn't arrive.

At that point, you may need to check the registers inside the PHY to see what it thinks the problem is.

Answer 4 · 2018-07-19T08:32:27.000Z

Hi,

I just finished the test with wireshark, regarding the data in the cable + chipscope on my PC to monitor the data. From this test I could see two different things:

In wireshark I see the ping packages moving normally, as long as the connection works (request->reply, sequence), but when the connection stops then the only thing I see is requests and no replies. Which, I think tells me that the packages are being transmitted from the software side and received normally.
When I look on the chipscope side, there is where things get confused. I attached my chipscope on the gmii_rxd and gmii_txd signals from the sgmii core to the temac. There I see that the gmii_rxd(7:0) signal always gives a sequence of <05><05>... no matter if I send any requests or not. And from the other side the gmii_txd(7:0) is always <00> even if the ping is on going. But on the software side I see that the ping is working fine (until the point it dies).
Any ideas regarding this ??
Thanks again in advance !!

Kind Regards
--ixiotidi

Answer 5 · 2018-08-07T15:24:11.000Z

Hi Everybody,

I found the solution to the problem I had. In order to have IPBus working you need to generate the Tri-Speed Ethernet MAC with configuration only 1000Mbs and not as Xilinx proposes with Tri-Speed functionality and the clock enable signal from the gigabit-ethernet pcs/pma core connected to the TEMAC. In this configuration it works fine.

On the top of that I could provide the example design for VC707 if you want to be added in the repo.

Cheers
--ixiotidi

Answer 6 · 2018-08-07T17:32:21.000Z

Aha! Nice work! Yes, please can you contribute an example ethernet block - this would be very useful. ixiotidi wrote on 07/08/2018 16:24:

…

Hi Everybody, I found the solution to the problem I had. In order to have IPBus working you need to generate the Tri-Speed Ethernet MAC with configuration only 1000Mbs and not as Xilinx proposes with Tri-Speed functionality and the clock enable signal from the gigabit-ethernet pcs/pma core connected to the TEMAC. In this configuration it works fine. On the top of that I could provide the example design for VC707 if you want to be added in the repo. Cheers --ixiotidi — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUMaSM10D_83DM-Y-rZM-_dQnpy36Ynlks5uObEcgaJpZM4VU4JQ>.

-- Professor Dave Newbold University of Bristol / Rutherford Appleton Laboratory http://www.bris.ac.uk/physics/people/david-m-newbold

Answer 7 · 2018-08-10T11:51:51.000Z

I would be very happy to submit, could you please send me some instructions how to do it?

Thanks in advance
--ixiotidi

Answer 8 · 2018-08-10T13:44:57.000Z

Hi ixiotidi,

I suggest you make a fork of the repository, include your changes and submit a pull request.

Thank you
Alessandro

Answer 9 · 2018-08-10T15:47:15.000Z

Hi Alessandro,

I will do it during the weekend when I am gonna have some time. Do you want just the ethernet block or also the whole example design ? Because I changed some parts (for instance I started from the KCU example but added the clock wizard of the 7 series). Thanks for the instructions.

Thanks
--Ioannis

Answer 10 · 2018-09-04T17:48:57.000Z

Hi Ioannis,

Sorry, didn't spot the question in your last post. I think (at least for now) it would be great to just have the Ethernet block.

So, if you have the time, could you create a fork of this repo, add the Ethernet block to your fork, then submit a pull request?

Thanks,
Tom

Answer 11 · 2020-01-16T15:13:25.000Z

Hi,

I'm closing this ticket since there have not been any comments for a while. @ixiotidi : If you still have the Ethernet block discussed above, and would still like to contribute it to this repo, please feel free to reopen this ticket.

Cheers,
Tom