Triple Speed Ethernet not working

Hi Leon,

It seems like you are trying to bring up TSE IP by referencing to certain example design but it's not working.

May I know which FPGA that you are using and which example design that you refer to ?

Just to confirm you are running simulation and not hardware testing right ?

Have you tried to verify the example design instead of your own design ? Then you can compare the difference and it may lead to the actual root cause.

Thanks.

Regards,

dlim

Hi Dlim,

Sorry I was not explaining clearly. I am using Altera Cyclone V and Quartus 15.1.

I generated the TSE IP and generated the example design at the last step of the IP.

I ran the simulation for the example in Modelsim and everything worked fine.

Then I created my design and tested it on hardware.

I set the all the configurations as the example in my design. But I got the problem I described earlier.

Hope you can help!

Leon

Hi Leon,

The other thing is are you using Intel FPGA CV dev kit board or your own board for hardware testing ?

• If you are using your own board then have you cross check to ensure all the clock, reset and FPGA power connection is stable and correct ?

I dig some search and found out we do have application note doc providing CV TSE RGMII reference design (page 16) and guideline on how to perform internal MAC loopback test (page 17)

• https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an647.pdf

This will be a good start to try bring up TSE IP using golden reference design first then only slowly port over to test your own design.

Thanks.

Regards,

dlim

Hi dlim,

I am using my own board for hardware testing. I used the board for other projects and I am sure the reset and clock signals works fine.

Thank you for your reference design provided I will check with that.

One concern is I checked the modelsim test bench. The data sending to the TSE only has a Ethernet header and then then the data 0x0102030405.... There is no 3 or 4th layer header(IPv4 or UDP/TCP something) for the data. Do you think that's a problem (I am thinking maybe the TSE detects the packet is not a valid IP data, and drops it)?

In my hardware test, the empty signal of the TSE fifo goes low (indicating data received), and then goes high after several clocks. I assume it dropped the packet since it is not a valid one?

Thank you!

Leon

Hi Leon,

I presume you are using signal_tap to probe on RGMII interface. I dig further and found out this is not possible due to this is hard circuitry path in silicon where signal probing is not possible. Refer to KDB link below.

• https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/solutions/rd03122014_936.html

TSE MAC won’t analyze or process 3th or 4th layer info as those are info required by upper layer analysis only. If you refer to AN647, Ethernet packet generator is just generating PRBS data pattern to TSE MAC only.

I suspect below are the 3 reasons causing TSE MAC loopback to fail on your hardware board assuming clock and reset are fine as per your feedback earlier.

1. Design timing closure issue

• I forgot to ask you what data rate/speed that you test on hardware ?
  • If 10M/100M is working but 1G is failing then it could be due to design timing closure issue as 1G design timing closure is tighter

1. TSE IP register is not configured or initialized correctly

• I am not sure how you configure the register in hardware, TCL script or NIOS ?
  • Anyway, you can cross check it with AN647 reference design TCL script

1. Ethernet data packet is not sent correctly to TSE MAC

• You mentioned simulation is working. So, byright you can monitor the data transaction on ff_tx_* interface and compare the result between sim waveform vs hardware signal_tap
  • Again, pls try out AN647 reference design as well

Thanks.

Regards,

dlim

Hi Dlim,

Thank you again for your information. It really helped a lot!

After checking everything as you suggested. I found where the problems were:

1. the ff_rx_rdy signal should be asserted from application side. (this was stupid)
2. Previously I thought if I ran the MAC loopback, I won't need the rx_clk from the external PHY chip. But it was actually needed. I assigned the 125MHz clock source to the signal and it worked! I think my PHY chip needs some configuration to provide the 125M clock.

Next I think I need to config the PHY correctly and everything should be fine.

Thanks!

Leon

I am glad things work out on your side ! :)