Capturing Ethernet header, adjusting packetizer speed and moving between OS

 I was asked about what is the inter-packet gap (IPG) and can this be varied. I checked and it turns out that IPG is inserted by PHY and not MAC. So MAC has no control over it. Since we are using Marvell 88E1111 PHY, the PHY inserts preamble, start of frame delimiter, CRC and inter-packet gap. The following wikipedia post is really useful

http://en.wikipedia.org/wiki/Ethernet_frame

Then  i was after capturing Ethernet Header ( preamble, start of frame delimiter, CRC and inter-packet gap) but this is not possible given the hardware (NIC + Ubuntu) that i have.

This stackexchnage  post is useful.

http://serverfault.com/questions/521443/can-wireshark-capture-an-entire-ethernet-frame-including-preamble-crc-and-inter

I came across the following raw Ethernet Capture tool.

https://gist.github.com/austinmarton/2862515

I Compiled its C source code to capture raw packets but for some reason, NIC + Ubuntu are stripping this information (preamble, start of frame delimiter, crc and ipg) and packets start from MAC header  (dst mac address, src MAC address ...)

http://pastebin.com/gMPnzy0g

Then i did calculation based on the transmitter packetizer to see how fast its throughput is. It turns out that it is actually 3x faster than 1 Gbps. As mentioned earlier, either the transmitter should slow down or the receiver should catch up. I am sticking to the first approach of slowing down the transmitter. Below is how and by how much?

I calculated the time to send one packet given 30 fps and then found out the delay to insert between packets (3000 clock cycles, where one cycle = 1/125 Mhz). I shall post these calculations tomorrow.


After configuring 3000 cycles delay between packets, i sent 102 packets (0 to 101 ) (see the last to last blog) from FPGA to PC (Ubuntu 13.10 machine). It turned out that Gstreamer got stuck at packet # 97 and never got to receive packet 98 till 101. Wireshark behaved differently from Gstreamer. It showed a couple of missing packets but those packets were successfully captured by Gstreamer AND Wireshark showed couple of packets that Gstreamer could not capture (e.g., packet # 98, 99, 100 and 101).

 It seemed that the transmitter needed to slow down further.So i increased the inter-packet delay  to 5000 clock cycles but still Gstreamer would get stuck at packet # 97. I knew that if i increase the delay to 20,000 clock cycles, it would work but that is not ideal as it would mean < 10 fps.

So i moved to my laptop that has 1 Gbps NIC but different Operating System (Windows 7) and used a newe Cat 6 cable. I configured the FPGA to send 102 packets to the laptop where the inter-packet delay is configured to be 3000 clock cycles. I was running Wireshark in Windows 7. It turned out that ALL the packets got captured and Wireshark did n't drop even a single packet.  I could not get Gstreamer to work on Windows 7 for some reason. Gstreamer runs but does not produce any output.

Here is the successful 102 packets captured by Wireshark in Windows 7 with inter-packet delay of 3000 clock cycles.

http://pastebin.com/Rw7FXKQd

You may want to look at the older blog post to decipher the above packets.

The point is that successful capture depends upon the NIC, cable and OS. I shall see if can get a recent NIC to reproduce the same behavior with Ubuntu 13.10 machine. Ethtool provides the following information about NIC

http://pastebin.com/VRLUJwLL

The fact that there is no mention of GMII is intriguing. What do you think?


I am on un-official vacation from tomorrow till next Friday. I shall work on this as i get time. The blogs might not be updated regularly. The remaining goal is further testing and documentation.

Today's post will be merged with tomorrow's post

I had to go out of town for most of the day so will update the blog tomorrow (Thursday). Please stay tuned.

Thanks


Has anyone tried reproducing some of this work. Please share your success or failure story.

Last day of debugging 1 Gbps transmitter's MAC

Today the first thing was testing the packetizer via simulation and the last thing that was emulation using Xilinx Chipscope, which took majority of the time as it is tricky and needs lot of debugging. The goal of the today's activity was to make sure that sender (which in this case is FPGA) does not miss packets or drop packets. For example, if FPGA is configured to send 102 packets ( which is sending 34 lines of 720p frame where each line is 1280 pixels and each line is sent as 3 packets ), it sends all the packets in a sequence starting from 0 to 101 without missing any packet from 0 to 101. The reason 102 packets were chosen because receiver PC randomly misses a few of the packets from 102 packets. This was confirmed by Wireshark. Every time, FPGA sends 102 packets, the receiver PC randomly drops 4 to 6 packets from 102 packets. If the number of packets sent from the transmitter FPGA are increased, then receiver drops more packets and these are random every time transmitter sends packets.

So before blaming the receiver for packet drop, it is good to check the transmitter. As mentioned above, i went through the chain of simulation. Please refer to the original proposal where i highlighted the importance of simulation on Pages 10 and 11. Simulation is done after each step of Xilinx Build flow as show in the Figure below.

 

Here are the snapshots that show RTL, post-synthesis, post-translate, post-map and post-pnr simulations. Post-pnr simulation is actually done with SDF delay annotation. All these simulations show that packets went from sequence number 0 to 101

Then after this came the step of verifying with Xilinx Chipscope, which took the whole day. Here are sequence of shots that show sequence number going from 0 to 101. 

After verifying through simulation chain and emulation using Chipscope, we are confident that transmitter is not dropping or missing packets.

Now we either need to slow down the transmitter or make sure receiver is fast enough to capture the transmitter. This is the aim for the rest of the week.

Please share your feedback

Thanks! 

The 2nd last day of 1 Gbps debugging

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.

1 Gbps MAC debugging continues on the weekend

Today, it turned out that 1 Gbps MAC was actually dropping packets. I tried to debug this by

1) Creating simulation environment for the entire design (packetizer + MAC)
2) Changing transmit fifo depth in gigmac from 6 to 12 and up
3) Creating internal reset for packetizer as the actual design gets reset externally from FPGA. Look at lines 148-155
http://pastebin.com/HXmiiGU0

Right now, simulation is not working as gemac_ready signal (see above pastebin) which is reset for packetizer is still not toggling. I shall look at it tomorrow Monday, although Monday is a special day.

If this doesn't really work, then  Chipscope is the next step. There is a possibility that 1 Gbps MAC cannot handle such high HDMI throughput but that is what i am after to confirm.

Happy Debugging.

1 Gbps MAC Debugging continues

I tried to debug the MAC. I found something weird and that was Wireshark was capturing all the packets while Gstreamer was not capturing the same packets and still waiting for some packets. I am trying to debug this further for more packets (for a complete 720p frame and back to back frames). I suspect from debugging today that MAC is fine. I'll confirm this soon.

Happy Debugging.

1 Gbps MAC debugging

If you recall, last week, packets sent by Packetizer were getting dropped or were missing. It turned out that 1 Gbps MAC that is integrated with Packetizer was overflowing despite making sure all flow control protocols were followed while interfacing with the MAC. To deal with this, delay was inserted between each RTP packet so MAC never overruns. It fixed everything and you could see entire RED frame, RGB flag and RGB loop. The only thing that got hurt is the frame per second.

So i am trying to figure out how to debug this MAC and get the fps up. I shall see if i could post some calculations of the current implementation.

Happy Debugging.

Time for a visual treat !

Last time, i said a picture is worth a thousand words. How about video? Video is frames per second x 1000.

Please see the following RGB Video

                                                 RGB Video

Debugging pays off fully

Picture is worth a thousand words. I am going write less and put two images. You can tell which one is better. I was able to create both using Gstreamer. Again a big thanks to Gstreamer community

Jittery Image

and

Clean Image


Here is a log file if you are really interested in seeing the underlying nitty gritty

Debugging pays off a bit

First, note that the yesterday's blog is marked by Google as today's (Monday blog). Please treat it as Sunday's blog. Today, the day was spent debugging why packets were missing? It finally came to light that the 1 Gbps MAC was overflowing. I adjusted the delay to make it not overflow.

Here is what i get when i send the 720p frame (all RED color) as 6 rows, 44 rows, 100 rows, 200 rows and all the 720 rows. The full image has some artifacts. I am going to see if these can be resolved or not.

Debugging frame sending in Packetizer RTL

I have been debugging why Packetizer is missing some packets randomly by Chipscope pro as well as simulation. Lets pray to hear the good news soon :)

I am trying to setup trigger conditions. It seems i need to work more on that. It should be done by Monday or latest by Tuesday.

Keep looking at the blog.

Debugging Verilog RTP Packetizer frame generation

Packetizer Verilog RTL is somehow missing some packets when i . This was reported in the day before yesterday's blog. I am still trying to debug it. I might go with simulation or chipscope approach. Right now i am making changes and testing in the hardware.

I also posted the instructions on how to reproduce yesterday's blog results of sending one row of 1280 pixels by FPGA and reconstruction in Gstreamer. Please look at the README.md

Debugging will continue on the weekend or next week as i have some commitment on Friday July 18th. See you after a short break !

Gstreamer finally works !

What a day today that ended up with falling in love with Gstreamer ! What an amazing tool !

Mos of today was dominated by the following loop

 Googling, talking to Gstreamer community, going back fixing the RTL code, running hardware, look at Gstreamer output

I must appreciate the community that really helped me with Gstreamer debugging. The problem was "Specification" that i mentioned a while ago that two people can never understand exactly the same specification. This happened today when i got a chance to compare my version of RFC 4175 implementation and Gstreamer's implementation. Other than three things, the implementations were identical. It took a while to figure that out. The three things were

1) Gstreamer counts scan lines from 0 while my implementation started counting lines from 26 and up (See section 3 of the above RFC)

2) My implementation was offsetting pixels by bytes while Gstreamer was offsetting pixels by number of pixels (which is the correct way). So i corrected my implementation

3) Even if one sends one line i.e., 1280 pixels (as three packets of 424,424 and 432 pixels), that last packet of 432 pixels must have marker bit set to 1. My implementation assumed marker bit would be set to 1 for the last packet in the frame (line # 720).

Once these were resolved, FPGA was able to send one line of 1280 pixels (all RED Color i.e., FF_00_00) that was correctly captured by Gstreamer as well as Wireshark. Please take a look at the following snapshots.

Following is the command that is used to launch Gstreamer

$GST_DEBUG=rtp*:9 gst-launch-1.0 -v udpsrc uri=udp://192.168.1.1:5004  caps="

application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)RAW, sampling=(string)RGB, depth=(string)8, width=(string)1280, height=(string)1" !  rtpvrawdepay  ! videoconvert ! videoscale ! "video/x-raw,height=720" ! autovideosink

OK. Now is the time to send full frame and capture it via Gstreamer. That is the goal for tomorrow.

Thanks for visiting my blog. Please give your precious feedback by commenting.

Debugging Gstreamer and testing packetizer

It was a hectic day trying to get RTP to work using Gstreamer. The receiver is not working yet. I am experimenting with Gstreamer. It is an excellent tool. I really liked it. After reading documentation and bouncing back and forth on #gstreamer, i tried the following and its variation

$gst-launch-1.0 -v GST_DEBUG=udpsrc:5 udpsrc uri=udp://192.168.1.1:1234 ! rtpbin ! rtpvrawdepay ! videoconvert ! autovideosink

but it does not work. It seems that "caps" is missing.It documentation is little hard to digest. I am trying to debug that.


On the other hand, Packetizer is missing some packets. For example, when i am trying to send an entire frame (720x3 packets) via RTP, it misses some packets e.g., packets with sequence number 16-28 are missing. I am trying to debug that as well.

I am hopeful i will be able to debug the Packetizer by tomorrow. I am hopeful to get to some point on Gstreamer by Thursday. If not, i will deal with image reconstruction in Pythonic way.

Working on GStreamer

Today i restarted with GStreamer after around 2 months. I started using GStreamer to generate RTP traffic, capture it via Wireshark and save it as ASCII file. My first two blogs talk about these. Since we are dealing with uncompressed video, using GStreamer to generate RTP traffic didn't work.

Now the goal is to use GStreamer to reconstruct video frame from RTP/UDP traffic coming at the Ethernet interface. From some discussion at IRC channel #gstreamer, it seems it is more than creating a simple Gstreamer pipeline. I have been advised to read up GStreamer Application Development manual, which i am doing right now. From reading a few chapters, it seems i have to write a C program to get the job done. But here and there i see Gstreamer one-liners as well. I am going to check it tomorrow on #gstreamer. If you can suggest something, please do. I am learning the ropes when it comes to Gstreamer.

Image streaming issues with VLC media player

Today i dedicated a good chunk of time learning how to stream raw video using VLC media player. The idea is to work backwards. That is, i want to generate UDP stream from a local image and capture it via Wireshark. Once this is done, i can move towards capturing RTP/UDP stream coming from FPGA. So in a way, it is getting more acquainted with sending video stream and capturing it.

 Here is the relevant post that i tried

http://stackoverflow.com/questions/2738228/how-to-stream-your-images-files-with-vlc

after learning the command line of VLC.  Here is what i am inputting at the command line

vlc -I dummy fake:// --fake-file checkboard.jpg --fake-duration 5000 --fake-width 300 --fake-height 300 --fake-caching 40 -vvv --sout "#std{access=udp,mux=ts,dst=127.0.0.1:1234}" --loop

Unfortunately, i am constantly getting the following ERROR


vlc: unknown option or missing mandatory argument `--fake-file=checkboard.jpg'


If you have any experience with VLC or you want to suggest some other tools like Gstreamer or ffmpeg might be better for this, please explain

Working on DDR2/Receiver logic and attending a conference in Tampa Florida

Now we need to push real HMDI traffic through Packetizer and Ethernet. I am reading up and learning about DDR2 in my time that i have from attending ISVLSI conference in Tampa, Florida. The other thing that can be done before this and perhaps should be done before DDR2 integration is regenerate the image on the receiver side using VLC or may be GStreamer. This will be done prior to integrating DDR2.

This will be continue on the weekend and next week until get done. Since i am traveling back home, you may not see Friday's blog.

Please tolerate that :)

Testing RTP packetizer with multiple (2 and 3 packets)

As one packet was correctly sent and it has been verified as well, now its time to send multiple packets to see if it works. It worked with 2 packets and 3 packets (which is equal to sending an entire row of 1280 pixels). Remember first two packets contains 424 pixels or 1272 bytes and third packet contains 432 pixels or 1296 bytes. Here is the hex dump of the three packets from Wireshark.

I am copying the entire Ethernet frames and color coding it for ease of visualization purpose.

Orange highlight shows Ethernet header
Green highlight shows IP header
Yellow highlight shows UDP header
Blue highlight show RTP header
Pink highlight shows RTP payload
Red highlight shows trailer and frame check sequence bytes


782bcb87cc6700183e0153d5080045000528aabb0000401147b6c0a80102c0a801011234123405140000801800000000000000000000000004f8001a000000000000000100000200000300000400000500000600000700000800000900000a00000b00000c00000d00000e00000f00001000001100001200001300001400001500001600001700001800001900001a00001b00001c00001d00001e00001f00002000002100002200002300002400002500002600002700002800002900002a00002b00002c00002d00002e00002f00003000003100003200003300003400003500003600003700003800003900003a00003b00003c00003d00003e00003f00004000004100004200004300004400004500004600004700004800004900004a00004b00004c00004d00004e00004f00005000005100005200005300005400005500005600005700005800005900005a00005b00005c00005d00005e00005f00006000006100006200006300006400006500006600006700006800006900006a00006b00006c00006d00006e00006f00007000007100007200007300007400007500007600007700007800007900007a00007b00007c00007d00007e00007f00008000008100008200008300008400008500008600008700008800008900008a00008b00008c00008d00008e00008f00009000009100009200009300009400009500009600009700009800009900009a00009b00009c00009d00009e00009f0000a00000a10000a20000a30000a40000a50000a60000a70000a80000a90000aa0000ab0000ac0000ad0000ae0000af0000b00000b10000b20000b30000b40000b50000b60000b70000b80000b90000ba0000bb0000bc0000bd0000be0000bf0000c00000c10000c20000c30000c40000c50000c60000c70000c80000c90000ca0000cb0000cc0000cd0000ce0000cf0000d00000d10000d20000d30000d40000d50000d60000d70000d80000d90000da0000db0000dc0000dd0000de0000df0000e00000e10000e20000e30000e40000e50000e60000e70000e80000e90000ea0000eb0000ec0000ed0000ee0000ef0000f00000f10000f20000f30000f40000f50000f60000f70000f80000f90000fa0000fb0000fc0000fd0000fe0000ff00010000010100010200010300010400010500010600010700010800010900010a00010b00010c00010d00010e00010f00011000011100011200011300011400011500011600011700011800011900011a00011b00011c00011d00011e00011f00012000012100012200012300012400012500012600012700012800012900012a00012b00012c00012d00012e00012f00013000013100013200013300013400013500013600013700013800013900013a00013b00013c00013d00013e00013f00014000014100014200014300014400014500014600014700014800014900014a00014b00014c00014d00014e00014f00015000015100015200015300015400015500015600015700015800015900015a00015b00015c00015d00015e00015f00016000016100016200016300016400016500016600016700016800016900016a00016b00016c00016d00016e00016f00017000017100017200017300017400017500017600017700017800017900017a00017b00017c00017d00017e00017f00018000018100018200018300018400018500018600018700018800018900018a00018b00018c00018d00018e00018f00019000019100019200019300019400019500019600019700019800019900019a00019b00019c00019d00019e00019f0001a00001a10001a20001a30001a40001a50001a60001a70001a80001a90001aa0001ab0001ac0001ad0001ae0001af0001b00001b1


782bcb87cc6700183e0153d5080045000528aabb0000401147b6c0a80102c0a801011234123405140000801800010000000000000000000004f8001a04f80001b00001b10001b20001b30001b40001b50001b60001b70001b80001b90001ba0001bb0001bc0001bd0001be0001bf0001c00001c10001c20001c30001c40001c50001c60001c70001c80001c90001ca0001cb0001cc0001cd0001ce0001cf0001d00001d10001d20001d30001d40001d50001d60001d70001d80001d90001da0001db0001dc0001dd0001de0001df0001e00001e10001e20001e30001e40001e50001e60001e70001e80001e90001ea0001eb0001ec0001ed0001ee0001ef0001f00001f10001f20001f30001f40001f50001f60001f70001f80001f90001fa0001fb0001fc0001fd0001fe0001ff00020000020100020200020300020400020500020600020700020800020900020a00020b00020c00020d00020e00020f00021000021100021200021300021400021500021600021700021800021900021a00021b00021c00021d00021e00021f00022000022100022200022300022400022500022600022700022800022900022a00022b00022c00022d00022e00022f00023000023100023200023300023400023500023600023700023800023900023a00023b00023c00023d00023e00023f00024000024100024200024300024400024500024600024700024800024900024a00024b00024c00024d00024e00024f00025000025100025200025300025400025500025600025700025800025900025a00025b00025c00025d00025e00025f00026000026100026200026300026400026500026600026700026800026900026a00026b00026c00026d00026e00026f00027000027100027200027300027400027500027600027700027800027900027a00027b00027c00027d00027e00027f00028000028100028200028300028400028500028600028700028800028900028a00028b00028c00028d00028e00028f00029000029100029200029300029400029500029600029700029800029900029a00029b00029c00029d00029e00029f0002a00002a10002a20002a30002a40002a50002a60002a70002a80002a90002aa0002ab0002ac0002ad0002ae0002af0002b00002b10002b20002b30002b40002b50002b60002b70002b80002b90002ba0002bb0002bc0002bd0002be0002bf0002c00002c10002c20002c30002c40002c50002c60002c70002c80002c90002ca0002cb0002cc0002cd0002ce0002cf0002d00002d10002d20002d30002d40002d50002d60002d70002d80002d90002da0002db0002dc0002dd0002de0002df0002e00002e10002e20002e30002e40002e50002e60002e70002e80002e90002ea0002eb0002ec0002ed0002ee0002ef0002f00002f10002f20002f30002f40002f50002f60002f70002f80002f90002fa0002fb0002fc0002fd0002fe0002ff00030000030100030200030300030400030500030600030700030800030900030a00030b00030c00030d00030e00030f00031000031100031200031300031400031500031600031700031800031900031a00031b00031c00031d00031e00031f00032000032100032200032300032400032500032600032700032800032900032a00032b00032c00032d00032e00032f00033000033100033200033300033400033500033600033700033800033900033a00033b00033c00033d00033e00033f00034000034100034200034300034400034500034600034700034800034900034a00034b00034c00034d00034e00034f00035000035100035200035300035400035500035600035700035800035900035a00035b00035c00035d00035e00035f000360000361


782bcb87cc6700183e0153d5080045000540aabb00004011479ec0a80102c0a8010112341234052c000080180002000000000000000000000510001a09f000036000036100036200036300036400036500036600036700036800036900036a00036b00036c00036d00036e00036f00037000037100037200037300037400037500037600037700037800037900037a00037b00037c00037d00037e00037f00038000038100038200038300038400038500038600038700038800038900038a00038b00038c00038d00038e00038f00039000039100039200039300039400039500039600039700039800039900039a00039b00039c00039d00039e00039f0003a00003a10003a20003a30003a40003a50003a60003a70003a80003a90003aa0003ab0003ac0003ad0003ae0003af0003b00003b10003b20003b30003b40003b50003b60003b70003b80003b90003ba0003bb0003bc0003bd0003be0003bf0003c00003c10003c20003c30003c40003c50003c60003c70003c80003c90003ca0003cb0003cc0003cd0003ce0003cf0003d00003d10003d20003d30003d40003d50003d60003d70003d80003d90003da0003db0003dc0003dd0003de0003df0003e00003e10003e20003e30003e40003e50003e60003e70003e80003e90003ea0003eb0003ec0003ed0003ee0003ef0003f00003f10003f20003f30003f40003f50003f60003f70003f80003f90003fa0003fb0003fc0003fd0003fe0003ff00040000040100040200040300040400040500040600040700040800040900040a00040b00040c00040d00040e00040f00041000041100041200041300041400041500041600041700041800041900041a00041b00041c00041d00041e00041f00042000042100042200042300042400042500042600042700042800042900042a00042b00042c00042d00042e00042f00043000043100043200043300043400043500043600043700043800043900043a00043b00043c00043d00043e00043f00044000044100044200044300044400044500044600044700044800044900044a00044b00044c00044d00044e00044f00045000045100045200045300045400045500045600045700045800045900045a00045b00045c00045d00045e00045f00046000046100046200046300046400046500046600046700046800046900046a00046b00046c00046d00046e00046f00047000047100047200047300047400047500047600047700047800047900047a00047b00047c00047d00047e00047f00048000048100048200048300048400048500048600048700048800048900048a00048b00048c00048d00048e00048f00049000049100049200049300049400049500049600049700049800049900049a00049b00049c00049d00049e00049f0004a00004a10004a20004a30004a40004a50004a60004a70004a80004a90004aa0004ab0004ac0004ad0004ae0004af0004b00004b10004b20004b30004b40004b50004b60004b70004b80004b90004ba0004bb0004bc0004bd0004be0004bf0004c00004c10004c20004c30004c40004c50004c60004c70004c80004c90004ca0004cb0004cc0004cd0004ce0004cf0004d00004d10004d20004d30004d40004d50004d60004d70004d80004d90004da0004db0004dc0004dd0004de0004df0004e00004e10004e20004e30004e40004e50004e60004e70004e80004e90004ea0004eb0004ec0004ed0004ee0004ef0004f00004f10004f20004f30004f40004f50004f60004f70004f80004f90004fa0004fb0004fc0004fd0004fe0004ff00040000040100040200040300040400040500040600040700040800040900040a00040b00040c00040d00040e00040f00041000041100041200041300041400041500041600041700041800041900041a00041b0004

Sending more RTP packets continues

As i am a traveling today, i will update this blog later tomorrow as well. The goal is to send more RTP packets given the first one has been successfully sent.

Here is the hex dump of the first packet taken from Wireshark. A entire row of 1280 pixels in a 720p frame is sent as three packets of 1272 bytes (424 pixels) , 1272 bytes (424 pixels) and 1296 bytes (432 pixels). I have annotated for the sake of clarity. The payload is monotonically increasing numbers from 0 to 423.


Orange highlight shows Ethernet header
Green highlight shows IP header
Yellow highlight shows UDP header
Blue highlight show RTP header
Pink highlight shows RTP payload


782bcb87cc67(DST MAC Address)
00183e0153d5(SRC MAC Address)
0800 (IPV4)
45 ({IP version, IHL})
00 ESCP, ECN (ignore these)
0528 (length of the entire packet including header,which = 1320 bytes since 1272 bytes of rtp payload + 20 bytes of rtp header + 8 bytes of udp header + 20 bytes of ip header)
aabb (Identification)
0000 (Flags,fragmentoffset)
4011 (TTL=64,protocol = 17 which is udp)
47b6 (Header Checksum)
c0a80102 (src ip address)
c0a80101 (dst ip address)
1234 (src port)
1234 (dst port)
0514 (length of udp packet = 1300 bytes)
0000 (udp hdr checksum)
801800000000000000000000000004f8001a0000 (20 byte RTP header)
//following is RTP payload (424 pixels)
00000000000100000200000300000400000500000600000700000800000900000a00000b00000c00000d00000e00000f00001000001100001200001300001400001500001600001700001800001900001a00001b00001c00001d00001e00001f00002000002100002200002300002400002500002600002700002800002900002a00002b00002c00002d00002e00002f00003000003100003200003300003400003500003600003700003800003900003a00003b00003c00003d00003e00003f00004000004100004200004300004400004500004600004700004800004900004a00004b00004c00004d00004e00004f00005000005100005200005300005400005500005600005700005800005900005a00005b00005c00005d00005e00005f00006000006100006200006300006400006500006600006700006800006900006a00006b00006c00006d00006e00006f00007000007100007200007300007400007500007600007700007800007900007a00007b00007c00007d00007e00007f00008000008100008200008300008400008500008600008700008800008900008a00008b00008c00008d00008e00008f00009000009100009200009300009400009500009600009700009800009900009a00009b00009c00009d00009e00009f0000a00000a10000a20000a30000a40000a50000a60000a70000a80000a90000aa0000ab0000ac0000ad0000ae0000af0000b00000b10000b20000b30000b40000b50000b60000b70000b80000b90000ba0000bb0000bc0000bd0000be0000bf0000c00000c10000c20000c30000c40000c50000c60000c70000c80000c90000ca0000cb0000cc0000cd0000ce0000cf0000d00000d10000d20000d30000d40000d50000d60000d70000d80000d90000da0000db0000dc0000dd0000de0000df0000e00000e10000e20000e30000e40000e50000e60000e70000e80000e90000ea0000eb0000ec0000ed0000ee0000ef0000f00000f10000f20000f30000f40000f50000f60000f70000f80000f90000fa0000fb0000fc0000fd0000fe0000ff00010000010100010200010300010400010500010600010700010800010900010a00010b00010c00010d00010e00010f00011000011100011200011300011400011500011600011700011800011900011a00011b00011c00011d00011e00011f00012000012100012200012300012400012500012600012700012800012900012a00012b00012c00012d00012e00012f00013000013100013200013300013400013500013600013700013800013900013a00013b00013c00013d00013e00013f00014000014100014200014300014400014500014600014700014800014900014a00014b00014c00014d00014e00014f00015000015100015200015300015400015500015600015700015800015900015a00015b00015c00015d00015e00015f00016000016100016200016300016400016500016600016700016800016900016a00016b00016c00016d00016e00016f00017000017100017200017300017400017500017600017700017800017900017a00017b00017c00017d00017e00017f00018000018100018200018300018400018500018600018700018800018900018a00018b00018c00018d00018e00018f00019000019100019200019300019400019500019600019700019800019900019a00019b00019c00019d00019e00019f0001a00001a10001a20001a30001a40001a50001a60001a7

Dealing with byte aligning was a tricky thing. It took a few builds to get that straight.

Debugging continues and eventually pays off: One RTP packet swims across the wire

All the timing violations are corrected. The build flow works great. But wireshark is not capturing anything. The whole day was dedicated to debugging why packets are not coming out of FPGA.
This will continue until problem solved. I am going to upload the design and log files later so you may suggest.

I am thinking of putting a testbench and check the simulation after each of the synthesis, translation, mapping and p&r phases.

The other would be to use Chipscope.

Debug mode continues.

And finally the good news, one RTP packet made it across the English channel ( i mean the Ethernet wire).

Here is the snapshot. Note that RTP is sent as UDP packet. Only Look at the first packet.

Now i will send more RTP packets and work backwards towards putting a DDR2 or similar and connecting that with VTC_DEMO colorbar.

Sending RTP packets via FPGA

Today, i generated montonically incrementing RGB values as part of the packetizer and send that to the MAC after adding all the headers like RTP, UDP, IP and Ethernet. The simulation worked just fine. After that it was time to do the Xilinx build flow to make the RTP go across the 1 Gbps network. It took more than an hour to get the build flow finish. And lo and behold, i was struck by timing violations. Time to fix this by re-coding.

Debug mode continues

RTP Integration

Now that UDP is working on Atlys FGPA and i can send UDP packets from Atlys FGPA to PC, i am working on adding RTP on top of UDP. Since i already have the RTP packetizer that interfaces with MAC, the only thing that is left is replacing the input simulation model to RTP packetizer (that provides it with pixels) with actual synthesizable model. I have HDMI pixel data dumped in a file, which is being read by RTP packetizer to create RTP packets. But now, i need something like DDR2 or RAM that holds this data. This stackoverflow post may be good enough as well. Let me try that and update the blog.

Its 4th of July holiday in US. Time to take a break as my family is coming to visit me for the day. I will keep it going on the weekend.

UDP working on Atlys

Today was working on hardware (Atlys board) trying to get FPGA to send UDP packets to the PC.
The first attempt failed as the PC didn't have the 1G Ethernet card. The 2nd attempt took a while as the cable drivers were not installed. Its a big pain to get drivers installed on linux (Ubuntu 13.04 in particular). Finally i got that done and now UDP packets are being captured by Wireshark on the PC. Here is the snapshot.

FPGA IP address = 192.168.1.2 (It is acting as source of UDP)
PC IP address      = 192.168.1.1 (It is acting as destination of UDP)

Time to send RTP packets piggybacked on UDP!!

HDMI correctly captured and on its way to MAC

The synchronization issue is solved. The proper RGB values are being captured. RTP packetizer is already complete and today we can generate correct stimulus for the packetizer. The correct stimulus comes from VTC_Demo. Take a look  at the log file and the waveform

http://i58.tinypic.com/i5b407.png



Now we have all the data to send to the MAC to send it across. That will the next step which should be going significantly ahead by the end of the week.

Fixing timing issue in capturing HDMI

The HDMI traffic that is generated is not being properly captured. At the moment, this is being debugged. Simulation is an integral part of this project which is missing in its sister project. The goal is to send real traffic so that at the destination we know what we are receiving. Right now RGB values get out of synchronization. Synchronization is so important. I have the necessary blocks to send HDMI data as Ethernet frames but the goal is to send right HDMI values which are with respect HSYNC and VSYNC.

Here is one snapshot which shows HCOUNT and VCOUNT not consistent with sys_clk.

HDMI Frame 1st row of pixels

It will be debugged by tomorrow hopefully.

The Spec will be updated tomorrow with what constitutes the right RGB values i.e., which RGB values need to be sent and which ones to be ignored.

The immediate plan is

1) to send the synchronized RGB as RTP packets via Ethernet and test it if they are being received correctly at the hardware level.