Bhuvan’s status report (Mar 2, 2019)
This week I worked on porting a pre-existing Verilog implementation of Pong. The existing application was meant to run on the Altera DE2-115 board while we are using the DE0-CV boards. This process involved looking through the DE0-CV documentation and ensuring that the interfaces matched.
After much trial and error, I was finally able to get the project to compile and program a board. Here is a first look at the game in action:
Here is a link to my Github repo which has the changes I forked from the original implementation. My next steps involve writing wrapper modules so are able to send and receive the ball and paddle position over the network.
Dhruva’s Status Report (Mar 2, 2019)
This week, I worked on testing the circuit we built last week. The circuit we built last week was that of an IR LED feeding a square wave into a transimpedance amplifier circuit connected to a photodiode. I had three key goals this week. Firstly, to ensure that the physical component of our data-transfer is foundationally sound i.e the data can be transferred from one FPGA to the other through the LEDs and that the data was discernable when being fed from the output of our circuit to the FPGA. Secondly, I planned to redesign the circuit as so that it is condensed and we can solder the receiver and transmitter components to attach them to our FPGAs in a convienent and portable manner. Lastly, I was responsible for looking at our new circuit design and selecting parts for the final circuit so that we can order it next week and have them in time when we get back from spring break which is when the first iteration of our circuit is to be built and integrated with the FPGAs.
This week, I spent a significant time in the lab and ensured that circuit was able to send the data accurately through the LEDs and that the receiver FPGA when attached to the receiver circuit would read a 0 bit as a 0 and a 1 bit as a 1. In other words, I was trying to ensure that the output from our circuit was high enough to be registered by the FPGA as a 1 when necessary. This involved tweaking parameters for logic levels within the FPGA as well as resistor values and op-amp rail values in the circuit. In order to determine this, a 1kHz square wave was generated using the transmitting FPGA and connected to the IR LED circuit. Connected to that we had our circuit from last week which had the photodiode and amplifier. Next, the receiving FPGA was connected to the output of the receiving side of the circuit and saw the waveform digitally as well as through an oscilloscope. The idea was to replicate the input 1kHz square wave we were sending as accurately as possible. Attached below are some oscilloscope screenshots which show successful transmission and the accuracy.
The yellow wave represents the input wave to the IR LED and the green represents the wave seen at the receiving FPGA. As the graphs suggest, we were quite accurate in the transmission. The difference between the high and low voltages was enough to make them discernable to the FPGA.
On zooming in, we measured the skew of the transmission (measured to the 90% high mark). We have a skew of about 30us which is very small and expected. This does not affect our design because we had planned for the skew to be slightly larger. Additionally, since we have multiple FPGAs, we know that there is going to be a difference in their clocks which is orders of magnitude higher than this skew. Our design works such that the modulation algorithm and access protocols on the FPGA take care of this skew.
With regard to the second goal of redesigning the circuit, I tweaked some component values so that we get the same output without the inverting amplifier which we had included in last weeks circuit design. This was a significant reduction in circuit components making our circuit more compact than before. This update will be reflected in our design document which is due this Monday.
Finally, we need to order parts for the circuit next week. I have finalized the LEDs for the circuit however, I still have to select the correct op-amp. The key aspect is that the op-amp has to have a high gain-bandwidth product and a high slew rate so that at the frequencies we plan to operate on, the transimpedance amplifier works properly and the skew in amplification does not affect our access protocols. The op-amp still needs to be selected before the parts are ordered sometime next week.
Raziq’s Status Report (Mar 2, 2019)
This past week was the Design Presentation, which I was responsible for. The presentation forced us to condense our thoughts and ideas into concrete specifications and plans, and the feedback received has helped refine our designs in time for the Design Report.
The modulation/demodulation techniques have continued to be a challenge, mostly because there is a wealth of theoretical papers on the subject but a dearth of reliable and affordable implementation details. For our Design Presentation, we had to present the scheme which we had the most concrete information on – Overlapping Pulse Position Modulation, from the DarkLight paper. In short, OPPM is a modified PPM technique where data in encoded in the rise time of pulses within symbol frames.
The number of time slots per symbol frame directly correlates to the number of bits per symbol. The DarkLight authors were limited to a minimum of 800ns as the pulse width, and through experimentation they arrived at a 3.2us slot width and 11 bits per symbol, which leads to a ~6.55ms symbol frame width and 1.6Kbps data rate. We are not beholden to a 0.007% duty cycle limitation, so I’ve still kept options such as OOK in the back of my mind.
In terms of EDC, I have found Verilog implementations of encoder/decoders for codes such as Reed Solomon. I haven’t yet tested with them due to the immediate focus on modulation/demodulation, but I don’t anticipate this taking very long.
Upcoming work
Select the correct Op-Amps.
Order photodiodes, LEDs and OpAmps
Test rise time, gain, bandwidth, etc. for purchased components
Figure out how to use FPGA power for the Op-Amp rails.
Test out modulation/demodulation techniques
Implement clock/data recovery and error detection/correction modules
Implement wrapper modules for Pong to be networked
Team Status Report
As a team we are working on completing the Design Report. We have been incorporating feedback and suggestions from the Design Presentation. We are also identifying parts to purchase for our MVP. We aim to order them before spring break, so that we have sufficient building and debugging time.