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.

Linux hexdump behavior

Posted by Peter Sullivan

There were reports that the software was not working on Python 2.6 with Linux.  I confirmed that the data being sent to the device is correct and that there should not be any issue with running the software under Linux.  The –save option will store the correct binary representation of what is sent over the network as well, however, it should be noted that at least under Ubuntu the default setting of hexdump is 2-byte hex, running hexdump -C or hd instead should give the desired 1-byte hex representation.

Clock Programming

Posted by Jeff Booth

Overview

One of the components of the pulse sequencer is a clock source.  The source must generate an 800 MHz clock signal for a sine wave generator, and a 100 MHz signal for the processing unit.  Originally, this clock source was provided by an external signal generator, which was both expensive and bulky.  As an alternative, Paul bought a clock source evaluation board, which can be programmed via a serial interface to generate a 1600 MHz clock signal.  Unfortunately, this board must be programmed every time it is powered on, requiring a computer and a serial cable.  Jeff’s project is to program the clock from the processing unit when the system powers on, and then convert the 1600 MHz signal to 800 MHz and 100 MHz signals.

The Clock Source

For the clock source, Paul bought an ADF-4360-2 chip on an EB1 Rev. D3 evaluation board.  This board has a connector for a 9V battery; since the battery died, we connected it to a 12V power source (since the on-board voltage regulator can handle it).  It has a clock output labeled “RF” and a DB9 female connector for communications.  The pin mappings are:

3. CLK – Clock
5. Data
7. LE – Latch Enable
8. GND – Ground

Every time CLK transitions from low to high, the bit on Data is read into the least-significant bit of a shift register.  Once 20 data bits are read, followed by 2 address bits, LE should be raised high.  This will cause the data in the shift register to be transferred to the register indicated by the address bits.  There are three registers that must be programmed in this order: R, Control, then N.  Here are the 22-bit values to shift in for each register, which Jeff found by clicking the “Registers” button in the clock source’s control program on an attached desktop computer:

R: 0000 0000 0000 0000 1100 1001
Control: 1000 1111 1111 0001 0000 1100
N: 0000 0000 1111 1010 0000 0010

Clock Divider

The AD9513 clock divider is programmed by 11 pins, each having one of 4 different voltage levels.  Our desired configuration produces CMOS voltage levels on two ports.  Port OUT0, on the connector labeled J1, divides the clock input frequency by 16.  Port OUT1, on connector J3, divides the clock input frequency by 2

Jumper configuration on the clock divider board

DB-9 female connector from the computer; plugs into the clock source.

google610888f721ab7e8a

new year’s progress

Posted by Paul Pham

A brief post before bedtime, since we had a good night of pulse programming, and it has given me a high that I can normally only get by running.

New sequencer boards have finally arrived, let me know if you want one! They got here on Christmas Eve, here is a picture of them arranged decoratively in a wreath on my apartment floor. The tenth one arrived a few days later.

A wreath of sequencer boards

I’ve tested one so far and it works great. Screaming Circuits did a very professional job, and for cheap, I highly recommend them.

Also, school is now back in session here at UW for the winter quarter. Jeff Booth has taken a bunch of cool photos of our lab and the undergrads who labor on your behalf. I definitely approve of all the dignified poses, which befits the gravity and seriousness of our mission.

Rob McClure

Rob is debugging the firmware to work with the latest version of Quartus, the first new compile in over two years. This is a necessary step to testing our new icnt instruction, as well as keeping our firmware up-to-date and efficient.

John Williams

John is working on the branch-on-trigger instruction to enable masking certain inputs as well as triggering on both high and low logic levels. He discovered that we could achieve a wait-on-trigger event by calling halt and then placing a branch-on-trigger instruction in the delay slots afterward.

Jeff Booth

Jeff is working on the programmable 2.0 GHz clock source and the divider that produces an 800 MHz clock for DDS and a 100 MHz clock for the sequencer board. He made great progress just tonight configuring the clock source via its serial interface using the I2C lines on the breakout board. This is awesome because we can use a tiny Analog Devices eval board instead of a gigantic synthesizer that costs hundreds or even thousands of dollars. Moreover, we can configure it on power-up using a simple Python script, instead of requiring the clunky Windows control software and a parallel port. I’ll let Jeff brag about his achievement in his own blog post.

David Nufer

David is working on adding support for the new icnt instruction to the Python compiler, which is the most complicated instruction to date. It has five subopcodes, requires two new register files, and an address accumulator for writing data to memory. We won’t be able to test or even use the new icnt instruction in firmware without this software feature.

Peter Sullivan

Also, we are proud to introduce a new cast member, Peter Sullivan, who was an undergrad with me in Boston. Tired of the stuffy pulse programming scene on the East Coast, he is now out here to see how we modulate our frequencies on the Left Coast. He is currently working on some software compatibility problems between Python versions 2.5 and 2.6 across Windows and Linux.

You can see the other photos in this new Flickr set.

Happy New Year! As you can see from the first few days of 2010, we are on track for another year of ruthless, inexorable progress.