Arria V Starter kit - Simple Socket Server (RGMII) how to address DHCP failures?

HI,

May I know which Intel FPGA Ethernet IP that face the problem here ?

Did you managed to isolate the issue further to Ethernet IP block ? Like is this high level software application issue ? board connectivity or setup issue ?

Have you tried with Ethernet IP internal loopback feature to isolate potential failure point from external factor ?

Can you duplicate the issue to Ethernet MAC and PHY layer only to check is the Eternet IP behaving correctly ? To isolate is it Ethernet IP bug, setting or other user design issue ?

Thanks.

Regards,

dlim

Thanks for responding dlim.

The Ethernet IP is altera_eth_tse version 18.1 configured with RGMII, 2k x 32 internal FIFO, half duplex support, statistics counters, align packet headers, and MDIO. The design is based on cvgt_simple_socket_server except with internal memory consisting of 512KB instruction, 768KB data, and 8KB descriptor DPRAM. I also replaced the Scatter-Gather DMA controllers with Modular Scatter-Gather DMA Controllers. The network stack is the iniche stack generated using the Simple Socket Server (RGMII) project template from the Nios II Application and BSP from Template wizard. I had to increase the os_max_events parameter under Settings/Advanced/ucosii,miscellaneous parameter group from 60 to 68 in order to get the RTOS booted (I'm surprised no one is complaining about this).

I have made some small narrowing of the problem root cause, but it still looks like no TX packets make it to the PHY.

• I discovered that the RGMII TX interface was largely unconnected to the signal tap analyzer so I no longer trust the waveform display. Critical errors were generated during synthesis that said most of the connections were illegal. Is there a workaround for this?
• I got the statistics counters to work by enabling them in the settings/advanced/altera_iniche parameter group. Now I see that packets are being transmitted.
• I reconfigured the Marvel 88e1111 PHY to show only TX packets on the TX LED (the default configuration has TX and RX LEDS linked). Now I see no indication on the TX LED that packets are being transmitted, but normal indication on the RX LED. So even though the TX frame counter is incrementing, the PHY does not indicate any TX packets.

I haven't tried a loopback test since the statistic counters are indicting both TX and RX packets, but the PHY is indicating only RX packets. I suspect that the problem must be in the RGMII interface. Do you still think there is anything useful to be learned from a loop back test?

I don't understand the last question. Perhaps you could rephrase it.

Here is the critical warning that I receive when I try to connect rgmii clock "gtx_clk" and data "tx_control" to my signal tap instance "tx_rgmii"

Critical Warning (35025): Partially connected in-system debug instance "tx_rgmii" to 32 of its 35 required data inputs, trigger inputs, acquisition clocks, and dynamic pins. There were 3 illegal, 0 inaccessible, and 0 missing sources or connections.

Here is the critical warning that I receive when I try the same thing only connecting to the equivalent ports on the TSE IP

Critical Warning (35025): Partially connected in-system debug instance "tx_rgmii" to 33 of its 35 required data inputs, trigger inputs, acquisition clocks, and dynamic pins. There were 2 illegal, 0 inaccessible, and 0 missing sources or connections.

One more piece of information determined today: the same problem exists at both 1Gbps and 100Mbps

HI,

The reason I asked for simplified debug design is due to your system is quite complex with a lot of design blocks that interact with TSE IP on both software and hardware level.

• Unfortunately I am not familiar with the overall system level design but I do can try to help out on TSE IP debug. That's why I asked earlier whether can you duplicate this issue using simpler design that maybe just contains a RTL design logic driver that interact with TSE IP only.

Regarding the signal_tap issue on RGMII interface

• You can't probe RGMII interface due to it's hard design block inside FPGA. Signal_tap which is is soft logic design can't access and probe on the the hard block. Detail in KDB link below
• https://www.intel.com/content/altera-www/global/en_us/index/support/support-resources/knowledge-base/solutions/rd03122014_936.html
• However, you do can probe on TSE MAC another side avalon ST port to ensure the data packet arrived TSE MAC successfully

As for the debug plan that you suspected TX data transfer maybe failed on TX RGMII output

• The reason I suggested for the MAC RGMII loopback test is basically to confirm on your finding where does the TX packet disappear exactly ? Is it insides FPGA or outside FPGA ?
• Alternate way will be to probe on the board txd[3:0] bus to observe is there any data transaction or not since you mentioned external PHY component didn't received the data packet.
• Also, have you double check to ensure your Quartus design is timing clean by studying the Quartus timequest report ?

Thanks.

Regards,

dlim

I diagnosed the problem and have the simple socket server example (with uCOSII, niche stack, and TSE) running on the Arria V GX Starter kit. The problem is due to the following instantiation of the ALTDDIO_OUT primitive in top.v of the cvgt_simple_socket_server.par design example:

// Ethernet interface assignments

enet_gtx_clk_ddio_buffer enet_gtx_clk_ddio_buffer_inst (

.aclr ( !cpu_resetn ), // <-- this should be .aclr ( cpu_resetn )

.datain_h ( 1'b1 ),

.datain_l ( 1'b0 ),

.outclock ( tx_clk_to_the_tse_mac ),

.dataout ( enet_gtx_clk )

);

When using an Arria V GX with Quartus 18.1.0 tools, cpu_resetn must not be inverted. The aclr input to the ALTDDIO_OUT primitive is true low as is cpu_resetn. Apparently, either the Cyclone V GT has a high true aclr input to the ALTDDIO_OUT primitive or the primitive changed somewhere between the 16.0.0 and 18.1.0 tools versions.

it's hard to believe that I'm the only one tripped up by this. It was very costly in terms of project schedule. Perhaps Intel should release a simple socket server design example for Arria V with the cpu_resetn polarity fixed. That would have saved me weeks of schedule delay.

At any rate, thanks for responding dlim.

Hi,

It's great to learn that you have resolved the issue and sorry for the additional delay caused at your project.

Sometime, the IP design may have changes from one Quartus version to another Quartus version.

One thing to share with you is design coding using primitive or WYSIWYG style is no longer recommended. As it's down to atom level design functionality modeling which is mainly used by the Intel FPGA IP design developer only but somehow got exposed to customer in the past.

Right now the recommended design practice is to use the IP core generated from IP catalog which has clear user guide documentation to explain on the port functionality from one Quartus version to another Quartus version.

Thanks.

Regards,

dlim