[jleahy]

This is a very difficult project.

No FPGAs have anything to decode TMDS. What they have is transceivers that will take the multi-gigabit serial signal and give it to you 32-bits or 64-bits at a time. Then it's your job to handle things like bit alignment, 8b10b decoding, etc. You need 6MB of RAM to hold one frame at 1080p, and to do this you'll need to hold one for each input. That requires external RAM (there's no enough on the FPGA), which means you'd need something like 30Gbit/sec of RAM bandwidth, which means you need DDR2 RAM before you've even stored anything (DDR3 is really awkward, I'd stick to DDR2 or LPDDR2, DDR4 is going to be impossible).

I'm not even going to comment on the feasibility of implementing SATA.

[exikyut]

I see... ouch.

Another comment mentioned the HDMI2USB project, and the main FPGA target of that project uses DDR3 FWIW. I get the impression that managing RAM is just really really really _unbelievably_ hard; not impossible, just pɹɐɥ ʎllɐǝɹ ʎllɐǝɹ.

[DigitalJack]

I don't think it's that bad. Board design is, but if you are working with some standard board, say from Opal Kelly (no affiliation), then you don't have to worry about that.

But what about the DRM with HDMI? I have no idea how it works, but I assumed the signal was encrypted.

[exikyut]

My context would be recording desktop-level glitches, so HDCP wouldn't be an issue.

This device would be a recorder though, so I'd likely never legitimately get HDCP keys. I can't see myself needing any though.

[mikeash]

HDCP (the DRM tech for HDMI) was not very well designed, and the master keys were cracked some years ago.

[taneq]

Which is probably fine if you're just doing it as a hobby project, but could land you in a legal pickle if you try to do anything commercial with it.

[mikeash]

Yes, I imagine you'd run afoul of the DMCA or similar if you started trying to make money from such a thing.

[exikyut]

Ah, TIL. I thought HDCP was still a wall. Security by Committee™ FTW!