09-10-2019 06:41 AM
I am currently working on the ZCU102 Evaluation board. My design has an AXI Stream of data in PL that I am looking to transmit using the RGMII Ethernet port. I am trying to use the GEM 3 FIFO interface, but it is not behaving as expected. I have a custom state machine to create the tx_r_data_rdy, tx_r_valid, tx_r_sop, and tx_r_eop signals needed for this interface, and then I have been using the System ILA to see how the signals are behaving. Below is the picture from the TRM for how the signals should be behaving.
The problem I am having is that when I assert tx_r_data_rdy, tx_r_rd does not assert for just one tx_clk cycle. Currently tx_r_rd gets asserted and then stays asserted forever.
I have the GEM Module resgisters set as follows:
network_control set to 0000001C
network_config set to 00100002
external_fifo_interface set to 00000001
spec_add1_bottom and spec_add1_top are also set with the value of the destination MAC address
09-12-2019 08:03 AM
If I have the external FIFO enabled wouldn't I want bits 22:21 to be 00 for External FIFO mode? If I understand the TRM(ug1085) correctly, shouldn't I be able to transmit data without using the DMA controller?
09-12-2019 10:01 AM - edited 09-12-2019 10:02 AM
09-12-2019 10:05 AM
Yes. The ILA screenshot isn't that exciting because my state machine is waiting for tx_r_rd to deassert before it asserts axis_tready and tx_r_valid to start tramsiting data. In this screenshot I have both my System ILA and state machine clocked using fmio_gem3_fifo_tx_clk_to_pl_bufg which I am assuming is what ug1085 is refering to as tx_clk.
After sample 502 all the signals stay the same until the end of the capture (sample 1024). Thanks
09-12-2019 10:54 AM - edited 09-12-2019 10:55 AM
I'm pretty sure I've used this interface in the past, but I'm having a hard time tracking down a project.
Have you looked at the ILA traces, using the link in my post above? Those correspond more with my memory of how that interface works: there can be a clock latency between VALID from READY, but READY doesn't necessarily toggle as shown in Figure 34-3.
In order to sustain operation using the Figure 34-3 method, above, tx_r_clk would have to be at least 250 MHz--to allow 8 data bits transferred every other clock--in order to keep a 1-Gbps pipe full. What's the frequency of the tx_r_clk in your design?
P.S. Where's your SOP?
09-19-2019 10:26 AM
I ended up modifying my custom state machine to match up more closely with the waveforms in Article 69490. Here is what my ILA capture looks like now. In this capture the ILA is getting clocked by the fmio_gem3_fifo_tx_clk_to_pl_bufg. If I understand the interface correctly this clock is the tx_r_clk that Figure 34-5 refers to? This clock should be operating at 125MHz.
Although the waveform looks like I expect it to, the PC that the board is connected to is still not receiving any packets through that Ethernet connection.
09-19-2019 01:24 PM
Does the tx_r_status FIFO output get updated after packet 'transmission'?
What are you doing with tx_r_control? Are you appending a CRC yourself, or asking the MAC to do it?
I would set the DA of the outgoing packet to all-F's, and send a full, 64-byte packet. Do you have a packet sniffer running on the receiving PC? Does it report anything coming in?
09-26-2019 10:20 AM
So I hooked up the System ILA to monitor the tx_r_status signal. This signal remains 0 during the entire tx process.
I currently have the tx_r_control input set to 0. I expected the MAC to append the CRC for me.
I also tried changing my DA to all F's, and I am also now sending a full 64-byte packet.
After sending all the data into the External FIFO Interface, I read the value of the gem.network_status (0xff0e0008) register to be 0x00000006 and the gem.transmit_status (0xff0e0014) register to be 0x00000028. This means that the 'Transmit Complete' bit is getting set.
On the PC connected to the board, I have tried going to Control Panel -> Network and Internet -> Network and Sharing Center, and then clicking on the ethernet connection to see the status of if it recieved any packets. So far it has always shown 0 packets recieved. I also tried using Wireshark, but this also didn't have luck detecting any recieved packets. Any thoughts?
09-26-2019 04:18 PM
There are a lot of steps between the FIFO interface and the UTP cable. I can only assume everything else is configured correctly by the software you're running.
If the packet is arriving at the PC with an incorrect CRC/FCS, it's possible the packet is being discarded before Wireshark could see it. It really depends on the equipment you're using.
Have you tried putting the MAC or the PHY into loopback, to see if your packet comes back?
P.S. Long shot here: Are you sure you're looking at the correct PC ethernet port? Does its status change to no-connection if you unplug the wire? If you haven't already done so, plug a known-good connection into it, and confirm that the stats you're monitoring increase over time.