Well, the title kind of says it all. So far, there's been no success getting the FPGA to configure.

I attached the CAT Board to the RPi, transferred the FPGA bitstream to the RPi, and installed the shell script for downloading the bitstream to the FPGA. Then I executed the command `config_ice leds_bitmap.bin` and ...

Nothing.

OK, I really didn't think it was going to work the first time. So I used the oscilloscope to check various signals:

• The RESET signal to the FPGA was going up and down, so it wasn't stuck at zero and holding the FPGA in a reset state.
• The BCM25 signal was going low to set the FPGA in the slave serial configuration mode.
• The SPI clock signal that clocks the bitstream into the FPGA was toggling.
• The SDI data signal that carries the bitstream was toggling, but it was spending a lot of its time at 2V instead of being at 0V or 3.3V.

The SDI signal looked like it was butting heads with another output trying to drive the FPGA's SDI input. My first thought was that the serial flash chip used to store the FPGA bitstream was being enabled and trying to send its contents at the same time the RPi was. Looking at the shell script, I could see it kept BCM25 pin pulled low during the entire configuration sequence and this would have enabled the serial flash. I revised the script by pulling BCM25 high after the FPGA reset went high because the FPGA would have entered the slave mode by then. Then I executed the script again and ...

Nothing.

OK, I wasn't really expecting it to work the second time. I looked at the SDI signal and it still showed contention. Possibly the RESET signal wasn't enough to put the FPGA in the slave serial configuration mode. Maybe it had to have its power cycled to do that.

So I removed the CAT Board from the RPi and restarted the script. When the script asked me to toggle the power to the FPGA, I just re-attached the CAT Board. (Previously, I had just toggled the RESET.) Then the script finished and ...

Nothing. Jesus!

OK, nothing good happens without some effort. Maybe I should check the RPi to make sure it's operating like I think. So I removed the CAT Board and re-ran the script while looking at the GPIO pins (which were now driving empty space). All the signals, including the SDI, were transitioning cleanly between 0V and 3.3V.

So it wasn't the RPi. Was the serial flash was still misbehaving? To test that, I desoldered that chip and re-ran the script ...

Nothing. Dammit!!

When I looked at the SDI with the serial flash removed, the SDI signal was still showing contention. That seemed to indicate the SDI pin on the FPGA was acting as an output instead of an input, which would happen if the FPGA was acting as a master instead of a slave.

So I went back to the Lattice appnote on configuring the iCE40 FPGA. One statement struck me: "An SPI slave mode configuration image must not use the Cold Boot or Warm Boot options." I was (and am) certainly no expert at using the iCEcube2 IDE, so maybe I had enabled one of these options.

I looked at my simple LED project and, sure enough, I had enabled warm boot in the bitstream options. I disabled that and rebuilt the bitstream. (I couldn't find the cold boot option. Hopefully it's off.) Then I ran the bitstream downloading script. Surely this has to work now ...

Nothing. Nothing from you, you goddamn, motherfucking, piece of SHIT!

So at this point it's time to reassess the situation and list some possible causes for failure:

• The design was incorrectly compiled so the bitstream won't work.
• The bitstream was compiled correctly, but it got corrupted when transferring it from the PC to the RPi.
• The bitstream is OK, but the FPGA isn't getting into the slave mode.
• I've criss-crossed the FPGA's SDI and SDO pins so I'm trying to inject the bitstream into an output pin. (There is some contradiction between the iCE40HX datasheet and the configuration appnote as to the operation of these pins in master versus slave mode.)
• One or more pins of the FPGA weren't soldered when I mounted the FPGA's BGA using the heat gun.

There's probably more, but those are the first things that spring to mind. So here's my current plan of action:

1. I ordered an iCEstick from Mouser. That will give me a known-good board I can use to test the generated bitstream and the RPi interface.
2. If the iCEstick works with my bitstreams and RPi, then I'll start cutting-up the board and try swapping the SDI and SDO pins.
3. If the SDI/SDO swap doesn't work, I'll try reheating the BGA to see if I can close any potential opens between the balls and the PCB.
4. If reflowing doesn't work, I'll remove the BGA completely and probe the pads to make sure the PCB traces are not broken.
5. If the traces are OK, I'll mount another FPGA and try again.

I'm not discouraged by this. As the little kid said when presented with a roomful of dung on Christmas morning: "All right! There's got to be a pony in there somewhere!"