Progress

This week I continued working on the Python firmware logic. A few changes occurred with our protocol while I was writing it that slowed down my progress.

We realized that technically tiles do not need a clock line. Originally, we planned that a tile’s top and left clocks would be driven by their top and left neighbors through two clock lines. Doing so would indicate to the tile when to read from the data line of its sides. But instead, we could have the neighbor tiles’ data lines be always high by default, and then go low for a clock cycle when it’s ready to send data. The main tile would then determine when to read from its neighbors through its internal clock. For example, let’s say that a clock cycle is 1 second. If a tile’s top neighbor goes from low to high, and the tile detects this internally at timestamp 15s, the tile will be prepared to read from the tile at timestamps 16.5s, 17.5s, etc.

We also realized that we needed to change the order of bits sent in a word. Originally, this order was:

• Bit 0 – Live bit (high to indicate that the tile is alive)
• Bit 1 – Sending bit (low to indicate that the tile is about to send a message)
• Bits 2-7 – Message
• Bit 8 – Parity bit (for error checking)

But we decided to switch the live and sending bits. The reason we did so was that the sending bit’s job was to indicate to the neighbor that it should expect a message to be sent via the next 8 clock cycles. When the sending bit is high, the neighbor knows that whatever series of messages the tile was sending is now complete.

It’s important that the sending bit be in the beginning of the word, so that for the neighbor’s perspective, if the tile is not in the middle of a message, and suddenly the data line goes low (after being high), it knows that a new message is starting.

This method is useful for the case that a child is sending a parent the current topology from the child’s perspective in a series of messages. If the parent realizes that one of the messages was corrupted (through checking the parity bit), the parent would need to send a “resend” request message to the child. The child is then expected to start over from the beginning of the series of messages. While the child is processing the resend request, it might still be sending data to the parent in parallel. How would the parent know that the child processed the resend request and has started sending the data from the beginning? If the child sends a high after it finishes a word, the parent knows that the child completed (or interrupted) sending the series of messages. Then when the child is low again, the parent knows that the child has begun resending the series of messages.

Current progress can be found under “tileFirmware.py” and “tileFirmwareSimulator.py” of our repository: https://github.com/melodeeli98/codeblox-capstone

Schedule

Right now, I am scheduled to complete the code by next Monday (2/24). Because of these protocol changes, I am a little behind schedule. I plan to spend extra time this weekend catching up, and will have the code complete and tested by Monday night.

According to the Gantt chart, I am scheduled to start working on the C simulator of tiles next week. I hope to be able to start this on time.

Goals for next week:

• Complete and test the Python firmware code.
• Begin working on C simulator of tiles.