Firmware Release v0.33

About a week ago, the latest version of the firmware was released. An overview of the main changes can be found in the release notes here. Included in the release was support for the branch-on-trigger and branch-wait features discussed in John’s post. Additionally, some of the DHCP work done by Jeff was included.

icnt instruction

A major feature of the new firmware release is that it includes a working implementation of the icnt instruction, which can be read about in David’s post. The basics of the implementation were already in place, but a few tweaks were necessary to get the features fully working. Specifically, the following changes were made:

The signal for branching based on a comparison between a counter register and another value had some delay issues, which were fixed.

The signal for writing data for the icnt write instruction was unnecessarily delayed, which was fixed.

The counter registers were experiencing some non-deterministic behavior due to being affected by two clocks (the board clock and the input triggers), causing them to sometimes reset erroneously. This was fixed by just using the board clock and watching for edges in the input trigger.

The data output from the processor wasn’t hooked up to the SRAM controller, so data from the icnt write instruction never made it to the SRAM. These signals were hooked up, enabling the processor to write to SRAM.

Tests

A few tests were run to make sure the instructions worked correctly, including a test that counted the number of times a button was pushed, and a test that used a feedback loop that fed output signals from the board into the input triggers, which let us test that the inputs were counted correctly and were written to memory correctly.

All of the tests worked when run on the board in the CSE lab. However, it currently looks like there are some timing issues on a different board, which causes this firmware (and v0.32) to not work. This problem is being investigated.

A Few Firmware Fixes

Posted by Rob McClure

Arbiter Fix

As mentioned in a few previous posts, the latest firmware would compile but would not run correctly. The board would shoot off 3-5 malformed ARP packets and the boot LEDs would not cycle through their display. Various things were considered as possible problems: perhaps the power-on-reset wasn’t working, perhaps the switch to a new compiler (Quartus 9.1 from Quartus 5.0) messed something up, or the asynchronous FIFOs were malfunctioning. Turns out that none of these were the problem (although the power-on-reset actually wasn’t working. More on that later in the post). The problem was actually the arbiter, which lets two or more masters control the same slave. The arbiter has a timeout so that it isn’t stuck waiting on a master that doesn’t actually have data. For easier debugging purposes, the timeout was set to 10 clock cycles, which in the time frame of the things the arbiter controls is really, really fast. The timeout in the previous firmware was 500,000 cycles, and reverting the timeout to that value solved the problem. The network controller had a couple of arbiters in it, and the I2C controller also had a few arbiters (and other places that probably had errors we didn’t see). Such a simple problem caused so many pieces to malfunction.

Power-on-reset Fix

As was mentioned, the power-on-reset still didn’t work. So, for the firmware to work, it had to be manually reset (with the switches on the board). While not a pain, it would still be more convenient for the board to reset itself. As shown here, the reset is just two T flip-flops linked together. By using SignalTap to examine the signals in the module, we gathered the following data:

What is shows is that the second flip-flop starts up in the finished state, instead of doing the one toggle it is supposed to to generate the reset pulse. It is possible that the compiler does some optimization that eliminates the important time-component of the flip-flop function. By inserting a third flip-flop into the module, the reset pulse was generated correctly, as shown by the updated SignalTap data:

As a result, the board now boots up and resets itself correctly, so it functions without any extra work by the user.

sequencer v0.32

These fixes mean that a new version of the firmware has been released. v0.32 is available from the Sourceforge page. Currently, it does not include the power-on-reset fix, but that may change in the future. The version with the fix can be found in the Git repository.