Embedded projects are never about doing things as fast as computers: we have full scale computers (and routers, and firewalls, and switches) for that. Embedded

Embedded projects are never about doing things as fast as computers: we have full scale computers (and routers, and firewalls, and switches) for that. Embedded is about solving problems more physical in nature, as you are physically closer to reality in nearly all aspects. -------- An MCU + FPGA project could implement... say... the VFIR IrDA (Infrared) protocol at 16Mbit. Traditional IrDA is widely supported at SIR and MIR levels (upto 1.152MBit or so). Anything faster and the equipment has basically been lost to the 1990s (and never was very popular anyway). IrDA I'd explain as a remote-controller on steroids. Its infrared based (like TV Remote Controllers), so you need to line up both devices and have them looking at each other. Infrared can reliably travel about 3 meters over the open air in a variety of conditions. IrDA allows for bidirectional communications. Its a truly wireless protocol, albeit one that requires significant alignment to function correctly. But ~3 meters is good range and practical for many applications. Nominally, you could use an entire MCU to handle the encoding / decoding of these light-pulses. However, that's a bit redundant. Its far more cost efficient to dedicate a few LUTs in an FPGA to the task. Yes, the MCU is needed for the final application-level / OSI layer 4/5/6/7 aspects of IrDA protocol. But the lowest PHY and MAC levels of the protocol can and (probably) should be a small section of FPGA. Upgrading from standard MCU 1MBit to 16MBit would be a 1600% improvement to communications compared to what's readily available with commercial-off-the-shelf solutions. If you've determined that IR Communications is good for whatever purpose you're using, maybe the 1600% improvement is going to be useful. ------------ EDIT: The "physicality" of this is because photodiodes react very quickly to light pulses. And an expensive enough transistor can amplify that at the ~100MHz speeds needed to run VFIR (at least in theory. I've never done this). The FPGA (or MCU if you go that route...) just needs to clock at 100MHz or so, and interpret the start-of-frame and end-of-frame signals, while also interpreting a few other low-level details. Overall, this turns the sequence of light pulses into bits-and-bytes for higher-level processing (which code can and should handle).