Bye World!

You might have heard Hello World! in almost all programming languages when the language is introduced. Today is the time to say Bye World! as it is the last official day of Google Summer of Code 2014. This is by no means to say that this blog is dead. This blog will continue to survive and i will continue to contribute after today. It was a good learning exercise and learning should not stop.

Thanks to TimVideos, Google and all those who shaped, mentored and gave feedback about the project.

Looking back, the proposal went through several iterations of proposal before being accepted. Right from the beginning, the expectations were high and that was a good motivation to work. The start of the project was very broad : looking this, evaluating that etc etc. After a while, things started to converge. As the time went by, i started to become more independent: i only had one VC with my mentor after midterm. Being independent is a good thing and i want to thank my mentor that he enforced this. Overall more time was spent debugging as big portion of the project was integration and testing on the host PC.

If you have comments or questions, please keep posting. Besides me, you are going to make this blog alive !

Final Report and Documentation

Today was spent making final report and finishing Documentation. Bits and pieces of Documentation are still left which i will get to later. They don't need to be addressed right away.

Please review these and share your comments. I might not be able to address your comments immediately as i am feeling unwell.

Documentation Continues towards finishing

Today was spent updating the bitbucket repository and Documentation. The Documentation refers to bitbucket quite a bit. Besides that i uploaded the static image Demo (see yesterday's post as well).

Now I hope to get sometime to work on DDR2 as that is in good progress. I hope to finish this bonus step by Friday.

Documentation and adding test images continues

Today, i added a test image generated from VTC_DEMO (see yesterday's post). What this means is that besides RGB loop, now this test image can be seen. You need to select this test image by turning switch sw7 up on the Atlys FPGA. Previously, the ideas was to use switches sw7 and sw6 for future purposes. But today i ended up using sw7 for test image.  Here is a Demo of the test image.

This also brings us closer to DDR2 integration. Right now, we are confident that HDMI traffic from VTC_DEMO is correctly captured in a file which is then read by packetizer using $readmemb. $readmemb is synthesized into BRAM or LUTs. That is how test image is read by packetizer, which eventually sends it to downstream MAC and off to the destination PC.

 Documentation has been updated as well. It will continue this week.

Please share your comments directly on the Documentation or here.

Thanks

Spending sometime working on DDR2 interface and resuming Documentation

If you recall, i had started Specification document for the project. Now is the time to put more writing into it and complete it by the end of this week by Sunday. I also spent sometime working on DDR2 interface today. From now on, more time (or perhaps most of the time) will be spent on the documentation and less on DDR2 integration. If documentation is complete and there is time left, DDR2 integration will continue. For DDR2 integration, we are going to use VTC_DEMO from Xilinx Application Note 495 as HDMI source. So HDMI traffic (720p) from VTC_DEMO will be written to DDR2 which will then be read by RTP packetizer and sent as RTP packets across 1 Gbps link to the host PC. Host PC will decode these packets using Gstreamer and play them back. I hope that was a good summary.

Please look at the Specification document for some new sections on HDMI. The ideas is to put the following sections so anyone (beginner with no knowledge or an expert) can understand the project and be able to reuse it. Following sections are going to be added to the rest of the documentation. This is not a complete list and things may be added or subtracted as needed.

1) HDMI basic explanation (what is a 720p frame, what are the relevant signals and how to know when a line (row) starts and when it is finished and when a frame starts and when it is finished?
2) Gigabit Ethernet MAC
3) RTP Packetizer
4) Frame Calculation
5) Testing on the Host PC using Gstreamer (how to configure the host PC, how to increase or decrease the frame rate using switches on Atlys FPGA)
6) Future Directions


Documentation is to be continued ...

Successful transmission of packets and recovery

Hi,
Good to see you after a break. I was at a Conference last week and after the end of each day, i dedicated some time to figuring out why packets were getting dropped and how to correct that. Finally, i got it working after lot of debugging using simulation, Chipscope pro and Googling. Anyway, i tried a couple of options. Some worked and some didn't. These were:

1) Adding latency (number of milliseconds before a packet is declared dropped) to the Gstreamer command

time 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)720" ! rtpbin latency=1 ! rtpvrawdepay  ! videoconvert !  autovideosink

I also tried with latency of 0 and it worked. Now the inter-packet delay is configurable using Atlys Switches sw0 to sw5. The default delay is 3000 clock cycles which corresponds to approximately 30 fps. Here is the configuration.

sw5 sw4 sw3 sw2 sw1 sw0   Delay in clock cycles
0      0       0    0       0     0            3000
0      0       0    0       0     1            2625
0      0       0    0       1     0            2250
0      0       0    0       1     1            1875
0      0       0    1      0     0             1500
0      0       0    1       0     1            1125
0      0       0    1       1     0              750
0      0       0    1       1     1              375

0      0       1    0       0     0            5500
0      1       0    0       0     0            8000
0      1       1    0       0     0           10500
1      0       0    0       0     0           13000
1      0       1    0       0     0           15500
1      1       0    0       0     0           18000
1      1       1    0       0     0           20500

sw6 is reserved for jumbo frame size and sw7 is reserved for 1080p (for future tweaks)

2) By Tcp tuning in Linux and Windows 7

I  tried without tuning and it worked. The tuning was done to see how much of inter-packet delay can be decreased. It turned out that as you approach to 0 inter-packet delay, Tcp tuning does not work

3) Going from Cat 5 to Cat 6 cable and it didn't make a difference.

4) Going from Linux to Windows 7 as my laptop had Windows 7 and i was stuck with this last week. It was not different going from Linux to Windows 7 except that Gstreamer didn't work in Window 7 for some reason.

Here is a quick demo. You will see frame rate going up (faster RGB pattern) and then going down (slow RGB pattern)


Now i shall work on DDR2 integration and documentation this week.

Please give your valuable feedback

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.

Adding HSYNC and VSYNC signals to the RTP packet interface

Before, we were streaming raw RGB values that were either randomly generated or monotonically increasing sequence. But as the purpose is to stream HDMI traffic, it makes sense to capture some real HDMI traffic and stream it through the packetizer. The last blog was an effort in this direction. We also have added HSYNC and VSYNC signals to the interface. See Figure 6 of the Specification.

Now we can't just stream RGB values through the packetizer interface. Now we need to conform to HDMI protocol, which means we either assert HSYNC and VSYNC according to the protocol or somehow capture the traffic that already has this information. This is where the last blog comes into the picture. I was successfully able to generate HDMI traffic and dump it into a file. Packetizer then reads this file and sends the data downstream accordingly. The files are here.

More later!!!

Implementing XAPP 495 on Spartan 6

Today, i decided to do hardware testing and chose to implement the VTC reference design given in http://bit.ly/1lluJn1 on Atlys board. I was able to implement the design successfully on Atlys board.

Here are a few snapshots of the 720p frame

Not only that, i was able to capture this HDMI traffic for the purpose of using it as RTP payload. I shall add the Verilog files that capture the HDMI to the bitbucket tomorrow. Here is a snapshot of the captured HDMI traffic going from FPGA to the monitor.

                 720p resolution chosen

                 512: en=1,hsync=1,vsync=1,red= 0,green= 0,blue= 0

                 525: en=1,hsync=0,vsync=0,red= 0,green= 0,blue= 0

                 539: en=1,hsync=0,vsync=0,red= 0,green= 0,blue= 0

                 553: en=1,hsync=0,vsync=0,red= 0,green= 0,blue= 0

                 566: en=1,hsync=0,vsync=0,red= 0,green= 0,blue= 0

                 580: en=1,hsync=0,vsync=0,red= 0,green= 0,blue= 0

                 593: en=1,hsync=0,vsync=0,red= 0,green= 0,blue= 0

                 607: en=1,hsync=0,vsync=0,red= 0,green= 0,blue= 0

                 620: en=1,hsync=0,vsync=0,red= 0,green= 0,blue= 0

                 634: en=1,hsync=0,vsync=0,red= 0,green= 0,blue= 0

                 647: en=1,hsync=0,vsync=0,red= 0,green= 0,blue= 0

                 661: en=1,hsync=0,vsync=0,red= 0,green= 0,blue= 0

                                .

                                .

                                .

HSync and VSync signals shall also be added to the packetizer upstream interface.

Downstream interface of RTP Verilog core

Today, i wanted to finish downstream interface of the RTP Verilog core. See Figure 6  of the Spec to see how the downstream interface looks like. The downstream block is the MAC (Media Access Controller). At the moment, the idea is to send RTP packets to the MAC. Once this is working, we can then insert UDP/IP/Ethernet headers and send it to the downstream interface as a realistic packet.

I got the downstream interface working but it is lagging. What this means is that packet arrival is faster than packet departure. There are two ways to deal with this. One is to back-pressure the upstream interface until the packet is sent downstream. This means you cannot get new data from upstream interface until all the previous data has drained downstream. The other approach is to use a reasonably sized FIFO and let the arrived data fill up the FIFO. While new data arrives at the FIFO, downstream block consumes data from FIFO.

Initially, i am going to try the first approach. Later, i can deal with the second approach.

What i first encountered during synthesis was of course

Synthesis Errors !!!!

ERROR:HDLCompiler:1401 - "/home/user/gsoc14/python_code/myhdl_code/sim_models/rtp_xilinx/rtl/packetizer.v" Line 148: Signal nxt_fifo_full in unit packetizer is connected to following multiple drivers:
Driver 0: output signal nxt_fifo_full of instance Latch (nxt_fifo_full).
Driver 1: output signal nxt_fifo_full of instance Multiplexer (fifo_full_fifo_full_MUX_20689).
ERROR:HDLCompiler:1401 - "/home/user/gsoc14/python_code/myhdl_code/sim_models/rtp_xilinx/rtl/packetizer.v" Line 220: Signal nxt_send_buffer[10399] in unit packetizer is connected to following multiple drivers:

So i had to rewrite RTL to make these Errors go away. I was able to do rewrite RTL as well as synthesize correctly. Here is the synthesis log file. Here is the synthesized netlist and testbench

Please run the code and help me find bugs that you come across.

Here is the output for a few clock cycles. The format is timestamp : 4bytes of RTP Data

                4356:80180000
                4376:00000000
                4416:00000501
                4436:001a0000
                4456:00010000
                4476:02000003
                4496:00000400
                4516:00050000
                4536:06000007
                4556:00000800
                4576:00090000
                4596:0a00000b

                   .

                   .

                   .

I will do more testing next week.

Testing and expansion of RTP Verilog model continues ...

The RTP Verilog RTL is complete and now it sends full 1280 pixel line (1280 x 3 bytes) as three packets of size 1281 bytes, 1281 bytes and 1278 bytes. See the revised Specification (in particular page 2). The difference from yesterday is the amount of data and testing. Yesterday it was tested with toy data. Today it is tested with data that is close to real life i.e., full 1280 pixel lines

The RTP Verilog RTL is uploaded to bitbucket. The design has also gone through synthesis and post-synthesis simulation Link. If you run post-synthesis simulation, you may not observe anything at the output. The reason is that pkt_data is no longer an output port. This is because

1) It was added for observability and debugging purposes. It is not part of upstream or      downstream interfaces
2) Its size is huge i.e., 1300 bytes i.e., reg [1300*8-1:0] pkt_data . Xilinx Spartan6 FPGA does not have these many pins to allocate.

For above reasons, pkt_data is kept as an internal signal for synthesis. But this is not the case in RTL, where pkt_data signal is available as an output port so you may see full pkt_data as shown below. I am showing one packet (i.e. first 1281 bytes of the first pixel line). 4136 is the time stamp in nanoseconds

 4316: 80180000000000000000000000000501001a0000000000000100000200000300000400000500000600000700000800000900000a00000b00000c00000d00000e00000f00001000001100001200001300001400001500001600001700001800001900001a00001b00001c00001d00001e00001f00002000002100002200002300002400002500002600002700002800002900002a00002b00002c00002d00002e00002f00003000003100003200003300003400003500003600003700003800003900003a00003b00003c00003d00003e00003f00004000004100004200004300004400004500004600004700004800004900004a00004b00004c00004d00004e00004f00005000005100005200005300005400005500005600005700005800005900005a00005b00005c00005d00005e00005f00006000006100006200006300006400006500006600006700006800006900006a00006b00006c00006d00006e00006f00007000007100007200007300007400007500007600007700007800007900007a00007b00007c00007d00007e00007f00008000008100008200008300008400008500008600008700008800008900008a00008b00008c00008d00008e00008f00009000009100009200009300009400009500009600009700009800009900009a00009b00009c00009d00009e00009f0000a00000a10000a20000a30000a40000a50000a60000a70000a80000a90000aa0000ab0000ac0000ad0000ae0000af0000b00000b10000b20000b30000b40000b50000b60000b70000b80000b90000ba0000bb0000bc0000bd0000be0000bf0000c00000c10000c20000c30000c40000c50000c60000c70000c80000c90000ca0000cb0000cc0000cd0000ce0000cf0000d00000d10000d20000d30000d40000d50000d60000d70000d80000d90000da0000db0000dc0000dd0000de0000df0000e00000e10000e20000e30000e40000e50000e60000e70000e80000e90000ea0000eb0000ec0000ed0000ee0000ef0000f00000f10000f20000f30000f40000f50000f60000f70000f80000f90000fa0000fb0000fc0000fd0000fe0000ff00010000010100010200010300010400010500010600010700010800010900010a00010b00010c00010d00010e00010f00011000011100011200011300011400011500011600011700011800011900011a00011b00011c00011d00011e00011f00012000012100012200012300012400012500012600012700012800012900012a00012b00012c00012d00012e00012f00013000013100013200013300013400013500013600013700013800013900013a00013b00013c00013d00013e00013f00014000014100014200014300014400014500014600014700014800014900014a00014b00014c00014d00014e00014f00015000015100015200015300015400015500015600015700015800015900015a00015b00015c00015d00015e00015f00016000016100016200016300016400016500016600016700016800016900016a00016b00016c00016d00016e00016f00017000017100017200017300017400017500017600017700017800017900017a00017b00017c00017d00017e00017f00018000018100018200018300018400018500018600018700018800018900018a00018b00018c00018d00018e00018f00019000019100019200019300019400019500019600019700019800019900019a00019b00019c00019d00019e00019f0001a00001a10001a20001a30001a40001a50001a60001a70001a80001a90001aa

The last RGB value is 0x01aa which translates to 426. Since the payload started from 0, there are 427 pixel values (427x3 = 1281 bytes) have been packetized as RTP payload. I kept the RGB data as monotonically increasing integers starting from 0 to simplify testing and debugging. The design does not drop a single RGB data across packet boundaries. I have myself verified this. If you can find bugs in this code, please bring them to my attention by submitting a pull request or commenting below.


Time permitting, i will look at MyHDL stuff as Chris has put a lot of stuff. See yaa

RTP Verilog Code and Synthesis

Today was getting hands dirty writing Verilog code. The interface of the RTP core is shown in Figure 6 of Specification. Note that RTP core will add UDP/IP and Ethernet Headers as well in the near future. The code correctly generates RTP packet i.e., header and payload (chosen to be small enough to debug).The design has also gone through synthesis Xilinx Synthesis flow and successfully post-synthesis simulation. The code is available on bitbucket. The RTL file for RTP is packetizer.v, the testbench is tb_packetizer.v. The post-synthesis netlist is packetizer_synthesis.v. You need Xilinx unisims, simprims, uni9000 and unimacro libraries to run the post-synthesis simulation.

Here is a brief log of the RTL Run. If you have read the Specification (in particular pages 3-4), this should make sense

                  0: 0000000000000000000000000000000000000000000000000000000000

                 145: 80180000000000000000000000000500001a0000000007000008000009

                 195: 80180001000000000000000000000500001a050000000a00000b00000c

                 245: 80180002000000000000000000000500001a0a0000000d00000e00000f

                 295: 80180003000000000000000000000500001b0000000010000011000012

                 345: 80180004000000000000000000000500001b0500000013000014000015

                 395: 80180005000000000000000000000500001b0a00000016000017000018

                 445: 80180006000000000000000000000500001c000000001900001a00001b

                 495: 80180007000000000000000000000500001c050000001c00001d00001e

  Here is a snapshot of the RTL simulation

Here is a brief log of the post-synthesis simulation

                   0: 0000000000000000000000000000000000000000000000000000000000

                 145: 80180000000000000000000000000500001a0000000007000008000009

                 195: 80180001000000000000000000000500001a050000000a00000b00000c

                 245: 80180002000000000000000000000500001a0a0000000d00000e00000f

                 295: 80180003000000000000000000000500001b0000000010000011000012

                 345: 80180004000000000000000000000500001b0500000013000014000015

                 395: 80180005000000000000000000000500001b0a00000016000017000018

                 445: 80180006000000000000000000000500001c000000001900001a00001b

                 495: 80180007000000000000000000000500001c050000001c00001d00001e

                 545: 80180008000000000000000000000500001c0a0000001f000020000021

                 595: 80180009000000000000000000000500001d0000000022000023000024

Here is a snapshot of the post-synthesis simulation

The Synthesis summary report is packetizer.syr

As the code is uploaded to bitbucket, please help test it. Thanks in advance

Documentation and Looking at UDP core

Part of good working habit is to document every thing. I have seen it and i believe it is extremely useful. So read the Spec


 As i am done with RTP golden model, i am about to write RTP Verilog model. I was figuring out myself as well as with my mentor what would the interface to UDP core look like.There are two possibilities

1)Assume there is downstream UDP core to begin with that accepts data.In this case, interface is easy as you can see how UDP accepts data.

2) If no UDP core or UDP core does not have interface to accept data, then you can add UDP header on the same spot where you are inserting RTP header. Not only that, you can also insert IP header as well. That means now you have to interface RTP with the MAC core.

The two cores i looked at are

http://www.joelw.id.au/FPGA/DigilentAtlysResources

This falls in the 2nd category

and

http://opencores.org/project,udp_ip_stack

which is sadly down throughout today and i could n't figure out if it belongs to 1st of 2nd category. I will try again tomorrow.

RTP packetizer golden model

A working RTP packetizer has been developed to deal with uncompressed RTP payload. It is working after some basic testing. Here is the code.You need modified rtp.py which is also included in the code. Tomorrow i shall add the documentation to tell you how i did all this and why i did it that way?

RTP packet creation in Python from raw video stream

OK finally got the basic RTP packet creation done in Python using MyHDL and Dpkt libraries
Please look at the source code here. Note that you need to have MyHDL and Dpkt libraries installed to get this code to run.

Figure 1: Write into Image Buffer by raw HDMI stream

Figure 2: Read from Image Buffer by RTP block

Here is the RTP packet of length 1086 bytes. Only the RTP payload is shown.

raw_bytes=ACE19577A2EB3665189599C2644D56420366CE5D386E802AFD79E54852C9C2AAB8C6DE15974BCEC18F7B7D3D0C8D50ED37D7808D498F4D773FF5D29278EC24BE1572F68F56BC2AF94E544148563E9493F585E2E9C3FBE7DA38D520656158D794D8F06D926B8B7B3B49B60974B7A0E1DC3496B1DAD4F110220366C35AD6217AC0EFC15FB2734DBD0D1D60B27E3FFAF13A2344BA3E8B2CF7276BFB1C94E2F86A9C503DF79F2882C948A8EE8572D7B09CE197D1F95E62285FB918009F25C41B4CA405AC51A28B3C71A6D28F450E64CD7A6DD7BB6CD48FE2035FE5BF30A16C3E67287C2BF9A1213FBE5EF98CA58BA22DA618B716AC98E4618EE450CB62CF57C0D4C626A652B9D47A539CF568641A7EBB750899DB81CBD3D09CC121ED2E48A8429FF72C214F88C028ABB2BE8FD6DFB79E36D0E8A42EA09B472AA3B82177DABD182B9938010688782C6663B9B515DEF5072A518640D7486723297E017A4C2C94F3E781E510B95BD0A74B51584AC39F477585BA4F70ED625F2D6477C5B1357D3C36EFAD68165D97AC3E1216A8E6B96EB6F2FB30562D24CEF996E1C675DEA2E5D977F3C0A1C3103ED7E2774CE69C1F136D5043CC9E4AA6E78A05D3113798AA0439C131EC4CCD509375EBC9942A67B44E8DC1DC992AEE7D56E0733716327E16831D8DE0453740C5A250B6352F4F74C411911DE4714D3ACCC6C71D4D614B68ACA6B676A97533604A491AE262D1AAC6AF55A45BEC0AEA382262F6036A8CBE0471FE3AB7AD7ACE1ED565D715E9B6CE0308FB019B7661E68FBB13512F6413AC5EC5456D83863BEEC1A53D9DDF857FC36D1EB732D07FECE2430B10FE253A60953AFCB38790899C775844F422DB83B5AB2A12443711BF46BA5C35E1C2BAD4BCC464ED59A4D924993A295006B34B63693E7B6A414D5894F91985E58AEEAAA08C430F7C354CBDCF43BD3D5458DC1856458919E001CFCA45BD12536F2B9D6855622741C58D7359C17F8AA943A147E36E634BA89E9EDD92188F3CE4E72DA2AF8D2B267248A9FCAA5C30D141DF2548FCE7531414D106AE4EEA84887984700F09C3A8D9E67B614CB7A1B417233D1D97EFC13F30011BE67EEE5CDACCD933816046E7919E2D22C568614756AE3E26323FCBE892968F2D99B655A18A4961A3C0F0DFE4FC56442071FD9516765998287E507CA9C58FDB2E8281CBF1B11942C919B36102A2B55AC9544094A6B78A931687552AC48BD9D4C0D580271A9FE19D37787959428DF04C886E38A39F2C601B9A299D70C4F6B4E82D7A02C8DD72B5F7A73596A29E13E4D6BE0F183C86E2CCDB6A95FC06AAF58754A21F6ABC3EC8237CACDCB55DE06D9651EF2E6A230E12C1BBB378B23CD785668DEEEDF06E8A2F71A0D6166B1BD281D729CDF2AC9763F0FDD390DB7025637EF68C6AD40AF1B01CB52A5BA289782B299C35550D6B5F0A4B6931F42226F455448403A77A29FA746C5CC27CFC81808E77A5DBCCC6D9BE5CB5E892A1CF2429FFC5EE8DE98BC06923B208E
byte_cnt= 1086
raw_cnt = 362


RTP header is not shown. It can be printed by calling pack_hdr( ) function on RTP object. Other functions that can be called on RTP object are

cc
csrc
data
m
p
pack
pack_hdr
pt
seq
ssrc
ts
unpack
version
x

This Python implementation of RTP will be used to test actual RTL implementation of RTP as shown below

Figure 3: Use of RTP Python Model to Verify RTP Verilog RTL

Well i thought i am on vacations but not officially i guess !!!!!