To be exact, the LED meanings in the "standard icarus" bitstreams (such as makomk's current 190oc release for example) are:
0 - Found a Share (flashes, then fades out)
1 - RX (FPGA received data on the serial port)
2 - TX (FPGA sending data on serial port)
3 - Idle (this lights when the FPGA has no current work to do)
The colors in order are:
0 - Green
1 - Red
2 - Blue
3 - Amber
Those functions are static (ie: they don't change depending on what "mode" the fpga is in).
For the HashVoodoo bitstream (Still not working right as of yet) the LED meanings are:
0 - Found a Share (flashes, then fades out)
1 - Clock Heartbeat (flashes on a heavily divided clock signal to indicate the FPGA is getting a good clock signal and hasn't locked up)
2 - Serial Activity (blinks on transmit or receive on the serial port)
3 - Idle (lights when the FPGA has no current work to do.
It should be noted that on both bitstreams currently the serial rx/tx LEDs light so fast typically you hardly notice them (if at all). I intend to add a (faster) version of the "fader" code from the share found LED code to the serial activity LED, to stretch out the blink duration some, to allow it to be more obvious when the FPGA is communicating.
To answer your question about multiple bitstreams:
In theory that should work fine. The comm clock, and hashing clock are different clock domains, so the communications code should keep on working just fine, while the hash clock can be at different rates. It may end up resulting in the entire nonce range being missed sometimes though (ie the 190 is in "front" and 180 in "back" the 190 starts the job, and forwards half it's nonce range to the 180 bitstream, but the 190 will finish before the 180 has finished, resulting in a small percentage of the second half of the nonce range being "skipped"). I don't think that will hurt overall hashrate, but it might skew some of the other stats slightly. Ultimately the impact should be nearly nothing.
Hope that helps
Also a quick status update on HashVoodoo development:
The first test bitstream using LVDS clock signalling was completed, but we're still having communications issues. So I'm now doing some debugging of the comms stuff.
The good news is that the LVDS clocks seem to be stable in all 4 slots, even on my 0001 serial number board! So I think if we can solve the comms issues, we're really onto something with this one!
Please note, I don't reccomend installing this bitstream just yet, (the .bit isn't released) because it's not quite working right. Once I get it hashing on my end, I'll release the full binary bitstream for you all to test out. I don't want to cause more headaches by releasing a malfunctioning bitstream (and I've encountered some wierdness on the jtag lines now, so I want to rule out the bitstream as a cause. The last thing I want to do is release an update that breaks your usb updating ability).
I'll post more when I have it.