Posting on behalf of Metron Inc. - Jeff
Need support with the Nios Simple Socket Server (RGMII) example. I’ve found no posts on the forum that describe what I’m seeing.
Here is what I see:
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 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 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.
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.
Regarding the signal_tap issue on RGMII interface
As for the debug plan that you suspected TX data transfer maybe failed on TX RGMII output
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.
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.