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.