<div dir="ltr">Hi Hrishikesh,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If I rewired the crossover output from the secondary eth interface straight into my custom logic in the DUC chain then all broadcast and non-USRP destined MAC addresses will get routed into the DUC chain, correct? Say my custom logic then gated the traffic only with MAC addresses equal to X. Then I would manually add some IP address associated with MAC address X, to my host computer ARP table under the interface used to communicate with the secondary eth interface on the USRP. This would effectively create a ghost device that resides within the USRP.</blockquote><div><br></div><div>Yes, this would theoretically work.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hence I still use the ZPU to respond to the ARP requests but then I will address the ghost MAC in my application.</blockquote><div><br></div><div>Be aware that even if the secondary port is not being used, it will respond to ARP and ICMP requests based on the IP address and MAC address programmed for that port in the flash [1].</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">So my question is how does the flow control in the simple_gemac_wrapper work?</span></blockquote><div><br></div><div>We don't use Ethernet flow control in the X300. We use an end-to-end flow control scheme where the endpoints are the host and the radio module in the FPGA. With this scheme, it is guaranteed that no data will back up in the Eth interface. I won't rely on PAUSE frames working in that logic because we have never used or validated it.</div><div><br></div><div><br></div><div>What kind of data are you planning to send to the DUC chain? If its just low speed settings you want to send then I would recommend adding a setting register like the one in [2]. If the data is more high-speed and you have to use the secondary port then I would recommend tapping the VITA output of the eth_dispatch module in eth_interface. The advantage of doing that is you don't have to deal with a ghost MAC and IP address because the device inherently had both of them. The ZPU will just do that right thing when you address the port. Also, the VITA output has the Ethernet, IP and UDP headers stripped so all you have to work with is the payload. You do have to make sure that the packets that you send from software are proper "compressed VITA" packets and that all subsystems in the FPGA are properly programmed to route and handle them. Luckily all of that work has been done by us in UHD so you can use that code [3]. The format for compressed VITA herader (CHDR) is documented here: [4]. [5] is an example of a piece of code that formats a cVITA packet in UHD. In terms of flow control you may have to validate the pause frame yourself because they just might work or implement your own protocol one layer above.</div><div><br></div><div>[1] <a href="http://files.ettus.com/manual/page_usrp_x3x0.html">http://files.ettus.com/manual/page_usrp_x3x0.html</a> </div></div><div>[2] <a href="https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/top/x300/radio.v#L208">https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/top/x300/radio.v#L208</a></div><div>[3] <a href="https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_impl.cpp#L1109">https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_impl.cpp#L1109</a></div><div><div>[4] <a href="https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/vita_chdr.txt">https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/vita_chdr.txt</a></div><div>[5] <a href="https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_io_impl.cpp#L179">https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_io_impl.cpp#L179</a></div></div><div><br></div><div class="gmail_extra">Hope that helps.</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div style="color:rgb(136,136,136)"><b>Ashish Chaudhari</b> | Senior Software Engineer | High Frequency Measurements - RF</div><div style="color:rgb(136,136,136)">Ettus Research, <i>A National Instruments Company</i></div><div style="color:rgb(136,136,136)"><br></div></div></div><div class="gmail_quote">On Wed, Sep 17, 2014 at 1:04 PM, Hrishikesh Shelar via USRP-users <span dir="ltr"><<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hey all,<div><br></div><div>If I rewired the crossover output from the secondary eth interface straight into my custom logic in the DUC chain then all broadcast and non-USRP destined MAC addresses will get routed into the DUC chain, correct? </div><div><br></div><div>Say my custom logic then gated the traffic only with MAC addresses equal to X. Then I would manually add some IP address associated with MAC address X, to my host computer ARP table under the interface used to communicate with the secondary eth interface on the USRP. This would effectively create a ghost device that resides within the USRP. Hence I still use the ZPU to respond to the ARP requests but then I will address the ghost MAC in my application.</div><div><br></div><div>So my question is how does the flow control in the simple_gemac_wrapper work? Do you simply enable the logic then assign a value to rx_fifo_space and pause_tresh values? I plan to use this feature to throttle the IP packets that will be fed to the DUC chain.</div><div><br></div><div>Thanks,</div><div>Hrishikesh</div></div>
<br>_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
<br></blockquote></div><br></div></div>