Today it came to light that complete simulation environment cannot be built as parts of the code actually probe PHY status registers. So the idea of top level design testbench did n't work. So i am back to unit testing and making sure that there is nothing in the code that is responsible for generating conditions that make a packet drop from MAC. After that i shall send traffic from FPGA to PC and see if the receiver PC's MAC is able to catch up or not by doing ifconfig or other utilities that can help detect packet loss. It seems likely that receiver MAC is not able to keep up.
This whole saga should end tomorrow. I am pretty hopeful.
Other than that we celebrated our holy Eid today. So spending some time with the family is good. It is good to take a break from GSoC.
Couple of things to note;
ReplyDelete* Ubuntu uses Network Manager by default to do networking. Network Manager automatically brings interfaces up/down based on the connection status, this could be interfering with things. I'd recommend disabling Network Manager and manually configuring with ifconfig and friends while testing.
* You might want to give ChipScope a go. I haven't used it much myself (just learning about it now) but Joelw on IRC is a big fan. That might give you a better idea of the actual I/O going to the chip and if anything strange is going on there.
* Do you have access to a high end oscilloscope through your university? You might need to sweet talk someone but I'd be surprised if they didn't have one. These often have inbuilt decoding for things like Ethernet.
As Tariq indicated in his previous updates, he his leaning towards utilizing chipscope. Chipscope should be easier to use than trying to probe the PHY signals (GMII or the diff pairs) with a scope. From my experience many scopes don't have the Ethernet parsing (although many do http://www.tek.com/oscilloscope/mso4000-dpo4000) but even with the ones that do the buffers are limited. It might be difficult to capture enough packets to determine if a packet was on the line but not at the application. Network protocol analyzers, although not as common at Universities, would have deep packet buffers and the protocol parsing.
DeleteI would first try and narrow down the issue, once you dive in and look at a specific interface (e.g. GMII) you loose the larger context and you are focusing more on timing and logic (this signal should only be valid when ...). I would do the slow to fast packet experiment and try to determine if it is a limitation of the PC (maybe use another PC with gigabit)
That depends on your definition of a complete simulation environment, as mentioned before I have a complete verification simulation/environment of the MAC you are using. It is possible and from my perspective desired (required). Obviously this doesn't debug physical / hardware issues or PHY configuration issues but it gives you unprecedented visibility to the logic design and will help narrow the scope of possibilities.
ReplyDeleteI agree, it is possible that the PC MAC cannot keep up but you should be able to setup an experiment to verify you max throughput. At this point in time, your frame rate is meaningless, you can send frames at 1 fps and still verify if packets are being received or not. It should be straightforward to vary the packet rate (one packet per ms, etc). You could even tie this to an IO to easily increase the rate and see where packets are being dropped.
What I would try:
* Instrument the variable packet rate, add the ability to send packets very slowly. Embedded a counter in the payload (could be the first N bits in the image data). Setup a script (or manually view with wireshark) that each packet is received at the slow rate. If successful receiving a collections (say 100) packets at a very slow rate, then increase the rate till it fails.
* Use the complete simulation environment (I sent you link previous) to determine where / how / if the MAC is dropping packets. If you need help with this let me know.
Hope that helps,
Chris