cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
892 Views
Registered: ‎06-24-2019

GEM External FIFO Interface

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.

TRM_FIFO_Timing.PNG

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

 

 

0 Kudos
Reply
10 Replies
Scholar
Scholar
862 Views
Registered: ‎02-01-2013

 

I think you missed by one bit...

-Joe G.

2019-09-11_14-58-35.jpg

0 Kudos
Reply
842 Views
Registered: ‎06-24-2019

Hi Joe, 

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?

GEM_BD.PNG

 

Thanks

0 Kudos
Reply
Scholar
Scholar
833 Views
Registered: ‎02-01-2013

 

Dang. You're right! *I* missed by one bit. I mistook bit 20 (which is a "1") to be bit 21.

Do you have an ILA trace to share?

-Joe G.

 

0 Kudos
Reply
Scholar
Scholar
824 Views
Registered: ‎02-01-2013

BTW: Is the behavior you're seening very different from this?

https://www.xilinx.com/support/answers/69490.html

(You'll need to zoom-in a LOT, to make out the waveforms.)

-Joe G.

 

0 Kudos
Reply
822 Views
Registered: ‎06-24-2019

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.

FIFO timing.PNG

After sample 502 all the signals stay the same until the end of the capture (sample 1024). Thanks

0 Kudos
Reply
Scholar
Scholar
808 Views
Registered: ‎02-01-2013

 

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?

-Joe G.

P.S. Where's your SOP?

 

0 Kudos
Reply
741 Views
Registered: ‎06-24-2019

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.

Capture3.PNG
0 Kudos
Reply
Scholar
Scholar
726 Views
Registered: ‎02-01-2013

 

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?

-Joe G.

 

0 Kudos
Reply
693 Views
Registered: ‎06-24-2019

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? 

 

-Thanks

0 Kudos
Reply
Scholar
Scholar
672 Views
Registered: ‎02-01-2013

 

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?

-Joe G.

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.

0 Kudos
Reply