How do I get my first FPGA internship without any real projects?

Nobody applying to those internships has a tapeout. Those postings are written by listing everything the senior engineers wish they had, and the actual bar is much lower. A small CPU on a Basys board plus one or two well-documented projects puts you right in the normal range for a second-year applicant.

That said, a UART core alone won't do much, since it's one of the first things anyone writes and interviewers know it. A small RISC-style processor is a better pick, but what actually makes it count is how you present it. A README that explains your design decisions, why you chose that pipeline structure, what broke and how you fixed it, is worth more than the code itself. Hiring managers skim for evidence you can reason about tradeoffs, not that you can copy a textbook module. Here's the part most students get backwards: the verification side is what makes a hobby project look profesional. Write real testbenches for your processor, drive it with constrained-random stimulus if you can, and check results automatically instead of eyeballing waveforms. Learning SystemVerilog for that purpose is absolutely the right call. UVM can wait, it's heavy machinery that doesn't make sense until you've felt the pain it solves, and most internship interviews won't expect it anyway. Cheap dev boards are fine. Everyone in the industry started on one, and the skills transfer directly. If you want the project to feel less toy-like, target something with a concrete spec, like getting your core to run a small program from BRAM and print over UART, so you can show a working end-to-end demo. One meaty project with clean git history, honest documentation, and a testbench beats five half-finished repos. Pick the processor, spend a couple of months on it properly, and stop second-guessing.

This is reassuring to read as someone coming at it from the other side. I did a physics degree first and only touched FPGAs in a lab course, so I have even less than you and somehow landed a placement anyway. What got me the interview was honestly a half-finished project where my writeup admitted what didn't work. One question though, when you say document the design decisions, do people actually read those or is it more that having them makes you sound clued up in the interview?

Following this closely because I'm in a similar boat but on the software side of things, poking at my dev board maybe an hour a week. The bit about writing your own test code instead of just staring at the blinking output clicked for me, I've been doing it wrong the whole time. Quick one though, when you say constrained-random testing, does that mean the computer throws random inputs at it, and you just tell it wich ranges are allowed? Sounds wierd that random stuff finds more bugs than trying things on purpose.