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.