Debugging the decode board rev. 1.2

Some quick notes on debugging the new revision of the decode card:

• plugging card in prevents reset from making any progress. With the logic analyser it's clear that rst_trig is being triggered every clock cycle. This is because there's a bug in the logic for controlling the control memory daughter board 0. This is different from the others because its output-enable line is not ctrl_drv, but just clk, since otherwise there's a chicken and egg problem, as ctrl_drv is derived from the outputs of this memory. Unfortunately, on startup the RAM has random values for rst_trig, and every time the clock goes low we write whatever the value at address 0 is, with a 50% chance that we get stuck in a permanent reset loop.
• the output-enable line to the first memory board is currently just clk. This is incorrect: it should be held low during reset. I think this is OK as-is, since none of the outputs of that RAM chip should break anything during initialisation (apart from the rst_trig issue above)
• the control lines for the shift register in the memory board are wrong. We're passing the rst_state_data line in directly. The oe line for the shift register is active-high, so if we want it enabled when rst_state_data is low (during the reset stage) then we need to pass the inverse of the line. This is already present, in the ram_oe line, so we can just use the same line for both (since we want exactly one active at a time, and one is active-low, the other active-high, we only need one control line).
• the ALU control lines are reversed on the decode card: aluop0 should be the top line, down to aluflgout1 at the bottom. Instead, they run the other way around. This is why I'm seeing the data line being driven by both the memory unit and the ALU. It's easy to work around by reversing the bits in the μcode ROM, though I'll need to add support for reversing the bits in a single entry.