So I had that problem with the polarity-protection MOSFET. It looked like it wasn't coming on and it was throttling the input supply voltage. But I couldn't reconcile the voltages I was seeing to the voltage/current curves of the DMP3098. There's no way the voltage could drop that much across the device with that small a current and a Vgs of almost four volts. Plus, I was bothered by the non-existent current drawn by the CAT Board.

So I went back and recreated the same setup. Sure enough, I saw the same voltages as before. But this time I measured the voltage on both the MOSFET drain (attached to the power supply) and the source (connected to the 5V plane on the PCB). And they were both 3.8V. (I had not measured the drain voltage before, just assuming it was 5V.)

So something was knocking-down the supply voltage before it even got to the board. The only thing between the supply and the board was the ... wait a minute! I had assumed the ammeter was showing a negligible current flowing into the board because it displayed this:

What my meter was actually trying to tell me was it had 0verFlowed the particular range I had selected. When I changed the dial from the microamp range to the milliamp range, the supply voltage on the drain and source of the MOSFET popped up to 5V and all the regulator outputs went to their expected values.

Some internal circuitry in the ammeter had impeded the supply voltage when the current exceeded the allowable range. What threw me off is that this effect goes away if the supply voltage is increased a volt or two, causing me to incorrectly blame the MOSFET threshold voltage.

Once the ammeter was setup correctly, I saw the board draws a quiescent current of 22mA. Here are the typical quiescent currents for the devices on the board:

That's pretty close to what I'm seeing. Now I can go forward with some belief that the power circuitry is correct.

The rest of my test plan was as follows:

1. Attach the CAT Board to the RPi and see if they blow up.
2. Install the yocto RPi image with the IceStorm tools and generate a blinking LED bitstream.
3. Download the bitstream to the CAT Board and see if it works.

I'm revising that. If the LED fails to blink, then the problem could be any one of these (or more):

1. The yocto image is corrupt.
2. I'm using the IceStorm tools incorrectly.
3. I bollixed-up the LED blinker design: doesn't run, wrong clock input, wrong LED outputs, etc.
4. The RPi GPIO pins that download the bitstream to the FPGA aren't configured as outputs.
5. The bitstream is corrupted, either when generated or during downloaded.

I'm too old and tired to fight the entire gang, but, yeah, I think I can take them one-on-one. So here's my revised test plan:

1. Download the iCEcube2 programming tools from Lattice and install them on my Windows 7 PC.
2. Create a simple, non-clocked circuit that displays a static pattern on the CAT Board LEDs.
3. Compile the circuit using the iCEcube2 tools to get a known-good bitstream. (Known-good in the sense the bitstream is valid for the iCE40HX8K FPGA, not that the design actually works.)
4. Mate the CAT Board with an RPi that uses my existing Raspian distribution which I know already works.
5. Transfer the bitstream from my PC to the RPi.
6. Use this technique to download the bitstream to the CAT Board.
7. If the correct pattern doesn't appear on the LEDs, then the problem is probably a corrupted bitstream caused by transferring from the PC to the RPi or by the downloading through the GPIO pins.
8. If the correct pattern does appear, then install the yocto image and repeat the download of the bitstream.
9. If the bitstream download still works, then recompile the design using the yosys + arachne-pnr tools and test the new bitstream.
10. If the bitstream compiled with the open-source tools works, then create a blinking LED circuit and try that.

Each step minimizes (as much as possible) the number of new elements introduced into the test. If a step fails, then there's only a few places to check for a problem.

So far, I've completed steps 1 through 4. Here's the VHDL for the initial design. I'm hoping I didn't screw that up. Guess I'll find out tomorrow.

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use ieee.math_real.all;

entity leds is
  port (
    led_o : out std_logic_vector(4 downto 1) := "0101"
  );
end entity;

architecture arch of leds is
  -- declare signals, components here...
begin
  led_o <= "1010";
end architecture;