Saturday, May 31, 2014

Beating the Interfaces

I read and heard a lot about interface incompatibilities and how different understanding of an interface could cause misunderstanding between teams working together. I ran into the same issue. To fix this, and understand the top level interfaces of HDMI2USB, i ran FPGA synthesis on it so i can view the RTL schematic. Here is a snapshot of schematic successful synthesis.



Figure 1: HDMI2USB at the top level

Once you have this schematic, you can click on wires and blocks to see which is connected with which.

My goal was to determine the interface of Image Buffer to RTP Packetizer (it is still under development). After spending sometime and bouncing back and forth with mentor, i was able to understand it. The interface looks like following




Figure 2 : RTP Interface with upstream Image Buffer (Red arrow shows Flow Control signals)


Here is a text and graphical snapshot of the simulation of the Image Buffer. The text shows 4 writes into the FIFO using Bus in (while reads are blocked on Bus out) and then the 4 writes are read  on Bus out while blocking writes on Bus in.

#Simulation time [w=write operation] --> write address ,  read address | input: enable status, fifo_full status bytes value , output: enable status, fifo_full status read value
#Simulation time [r=read operation] --> read address ,  write address | input: enable status, fifo_full status bytes value , output: enable status, fifo_full status read value

33:  [w]  -->   0,    0 --> | i:e1 f0 DE99C9, o:e0 f1 000000
39:  [w]  -->   1,    0 --> | i:e1 f0 E95B32, o:e1 f1 000000
45:  [w]  -->   2,    0 --> | i:e1 f0 0D2F9F, o:e1 f1 000000
51:  [w]  -->   3,    0 --> | i:e1 f0 6B6951, o:e1 f1 000000
57:  [w]  -->   4,    0 --> | i:e1 f0 549BB1, o:e1 f1 000000
63:  [r]  -->   0,    5 --> | i:e0 f0 549BB1, o:e1 f0 000000
69:  [r]  -->   1,    5 --> | i:e0 f0 549BB1, o:e1 f0 DE99C9
75:  [r]  -->   2,    5 --> | i:e0 f0 549BB1, o:e1 f0 E95B32
81:  [r]  -->   3,    5 --> | i:e0 f0 549BB1, o:e1 f0 0D2F9F

If the above looks gibberish to you, you can look at the waveform below or read the source code


Figure 3: Waveform of FIFO WRITE and then READ operations

Also added basic RTP packet processing functionality in the source code to receive raw data from Image Buffer and turn it into RTP packets.







Friday, May 30, 2014

Back in town and getting back to work

I worked half a day on Wednesday and was out of town on Thursday. On Friday, i was home the whole day as i was not feeling well. You can ask so what?

Now the plan is to work on the weekend to complete the 40 hours as well as next week during which i am suppose to be on vacation.

I had taken GSoC on my nerves. That is why my sleep and work cycle got unbalanced this week. I want to unwind myself and today (Friday) i focused on that. My goal is to complete the project and enjoy the experience rather than hosed.

Anyway, got MyHDL 0.9-dev working. Now i can pass interfaces. I was able to run the code passed to me by Chris. The code treats Image buffer FIFO as shown in Figure 2 of the Spec

https://docs.google.com/document/d/1PSjfm6eS0B3UUPJmPf7PH0tNsF7ZFKIKfPldmF3ucKY/edit

While, i am more inclined to use Figure 3. I have to resolve this with the mentor.

Tomorrow (Saturday May 31st), integration of simulation models of Image Buffer -> RTP -> UDP in MyHDL will be dealt with.


Tuesday, May 27, 2014

FPGA Hello World


Got the Stroby working!!!. Here is the demo.


The updated files can be found on my bitbucket



Now Working on models for simulation and verification of HDMI2Ethernet pipeline as shown in the Figure below. Blue blocks show simulation models. Yellow Blocks show hardware models


simulation_models.jpg
Figure 1: HDM2Ethernet Simulation and Verification flow

The idea is first create accurate golden model for hardware blocks. This is to make sure RTP packets are generated, encapsulated as UDP packets, UDP gets encapsulated as IP packets and IP packets are encapsulated as Ethernet packets.

The goal of this week is to create golden model for packetizer and test it together with upstream and downstream blocks.

Monday, May 26, 2014

Opening the Xilinx Atlys Board

Items that i want to cover today

  • Opening the FPGA Box
  • Python Scapy
  • HDMI2Ethernet Pipeline



I found that it has 100 MHz input clock from Xilinx Atlys Board Reference Manual

The above MyHDL tutorial is little bit hard to follow.So i ended up creating my own version. Once i got the led strobe working in Python. The next step was to convert it to Verilog and then go through the entire Xilinx Build Flow till bit file generation. I got the Verilog conversion correctly. Unfortunately, the provided compile_stroby.py does not work to generate bit file from Verilog. I will report it to the author of the tutorial.So, I took the other route. I manually created Xilinx ISE project for Atlys Spartan 6 board (XC6SLX45), imported Verilog file, manually created constraint file (my_stroby.ucf) and clicked the Implementation flow. As a result, i got the bit file generated. I was able to program the board successfully using Xilinx Impact. Unfortunately, the leds are not blinking, despite spending almost 2 hours (its 1:44 AM now :(  )

I will debug it in the morning.


The files can be found on my bitbucket




Today was the last holiday from long weekend but i thought to do something to keep going.

Friday, May 23, 2014

FIFO Downstream Interfacing using MyHDL

Today the objective was to define the FIFO downstream interface as defined in the HDMI2Ethernet Specification document that will interface with the RTP block. I also cleaned up the source code tree on Bitbucket. It should look more cleaner with README.txt and conversion directory that holds the Verilog and VHDL modules. Figure 1 shows the Simulation waveform


Figure 1: FIFO downstream interface capture waveform


The objective of yesterday's and today's exercise is to create simulation models (flexible models that can leverage full features of Python as these blocks don't need to be converted to Hardware (Verilog or VHDL) ) as many as necessary in HDMI2Ethernet Pipeline shown in Blue in Figure 2. The yellow Block such as Packetizer needs to be converted to Hardware and thus needs a strict HDL (Verilog or VHDL) modeling. This will become clear in the forthcoming weeks.




Figure 2: Design and Verification environment



Looking forward to Memorial day long weekend !!!





Thursday, May 22, 2014

Defining FIFO Upstream Interface using MyHDL Python library for Hardware Design

Today was learning MyHDL and putting into practice. My mentor created an exercise based on HDMI2Ethernet Specfication. Note that this specification is still in progress.The exercise objective is to mimic HDMI2USB' FIFO upstream interface. Once this interface is correctly implemented in hardware and and tested by testbench + waveform viewer, we can proceed downstream towards Blocks that need to be implemented for this project like RTP packet processing, UDP packet processing, IP packet processing, and Ethernet packet processing. All the Files are available to download from my bitbucket.
Here is the GTK waveform.





Wednesday, May 21, 2014

RTP packet crafting using dpkt-1.80 Python library

Installing dpkt-1.80.tar.gz was trickier than i thought. Python is not easy to master. I always learn something new when i start to work on it. The problem with dpkt is the poor documentation right from the start. Installation was quite an issue for me but later in the afternoon, i figured out the correct way to do it. Before that i was trying to import modules from the dpkt directory but something in the code would keep on breaking. Dpkt project suffers from poor documentation of the source code as well and lack of examples to use the library.I had to try out a couple of things before i was able to create the RTP packets. Part of this effort was googling looking for code samples using dpkt. Unfortunately, there were not many.
Anyway, here is the RTP code that i have coded


#trying to send rtp packet
#by Tariq B. Ahmad
# 5/21/2014

import dpkt
import socket

rtp_pkt = dpkt.rtp.RTP()
rtp_pkt.data = '''HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  HelloWorldHelloWorldHelloWorldHelloWorld
                  '''

udp_pkt = dpkt.udp.UDP(sport=11111,dport=11112)
udp_pkt.data = rtp_pkt.data
udp_pkt.ulen += len(udp_pkt.data)

ip_pkt = dpkt.ip.IP(id=0, src='\x01\x02\x03\x04', dst='\xc0\xa8\x7a\x01', p=17) # p=17 for udp
ip_pkt.data = udp_pkt.data
ip_pkt.len += len(ip_pkt.data)

s = socket.socket(socket.AF_INET, socket.SOCK_RAW, dpkt.ip.IP_PROTO_UDP)
s.connect(('192.168.122.1', 11112))
#print str(ip_pkt)
sent = s.send(str(ip_pkt))

print 'sent %d bytes' % sent



Here is the output when you run the script. You have to be the root user in Linux to use socket functionality.

sent 1554 bytes


I tried to capture this using Wireshark by listening to the interface on 192.168.122.1 but Wireshark could not capture this. I have googled this and other people have reported the same issue.

If i have some time tomorrow, i shall use Scapy library to see if i can do the same or better with Scapy.
Cheerz and tomorrow is MyHDL day



I also received my Xilinx Atlys board today !!!

Tuesday, May 20, 2014

Tools for RTP packet creation

The purpose of yesterday's and today's work was to find out tools which could create customized RTP packets. Unfortunately after trying almost dozen tools, no such tool exist. If you know any, please let me know by adding your comments. The original exercise that was in my mind was to create custom RTP packets (Where i can define payload type, sequence number etc), save them in a file and later play them back. This would later become testbench for RTP module that is going to be implemented in Verilog.

From the point of view of writing my own RTP traffic generation tool using available libraries, things are little difficult as the RTP payload format is different for every payload type. This makes no sense to me but this is how it is. For example RTP payload format for Vorbis (audio file) http://tools.ietf.org/rfc/rfc5215.txt is different than from MPEG (video file) http://tools.ietf.org/html/rfc2250.

Fortunately, there is RTP payload for uncompressed video,http://tools.ietf.org/html/rfc4175. I am going to write a small program in Python or C that will generate RTP packets with uncompressed video payload and save as file on a disk.

The tools i tried on the 2nd day are

1) LANForge
2) D-ITG Traffic Generator
3) Mausezahn

Time to look at HDMI2USB hardware ...


Monday, May 19, 2014

First Day of GSoC 2014

First day of GSoC 2014 was full of learning this and that. I am trying to create custom RTP packets and then play them back. Apparently all tools that i have tried today are either too old or broken. Dependencies in Linux are a big mess. Porting outdated source code to recent version of GCC was quite a challenge. Continuing to do the work. I tried the following tools on the first day

1) RTP Tools 1.20
2) FeFe RTP
3) CMU RTP  (from 1999)
4) Packeth
5) RTPSend and RTPSPY from Dirk (2003-2006)
6) DPKT (needs further investigation)

Monday, May 5, 2014

This is final week in the semester. Things are pretty hectic. I am working on improving introduction email text that i need to send to the TimVideos community to tell them about my project (HDMI2Ethernet). Your comments on these posts will be highly valued and appreciated. Help keep the blog active.