First problem: "an FPGA". Unless it is far behind the state of the art, your processor design won't fit on a single FPGA chip. You need to partition the design, and run it on many FPGAs, and do the partition in a way that is correct and doesn't drop the performance to almost nothing. This is what the EDA emulation vendors will sell you: the systems with FPGAs organized into boards and racks of boards, and the software to target those systems, because to fit a cutting edge processor into the system you're going to need hundreds or thousands of FPGA chips.

Once you do all that, you can try carrying out your program as described above. But it guaranteed that the first time you try it, it won't work, because your design will have bugs. Then what?

You need the ability to debug. This means you need to have probes, you need to be able to extract the data, and you need very high bandwidth. You need to have testbenches that are partly in software and partly on the FPGA hardware. Again, that's what the EDA industry will sell you: the hardware and software to do it, as well as the expert consultants to walk you through the process.

And your device needs to interact with the environment. Some of the hardest verification problems have to do with the timing of interrupts; if one comes when the processor is just at the right point, and that case isn't handled in the design, it could lock up. THose cases have to be covered.

Now, for your example of a small core, perhaps it's small enough that you could get it to synthesize and fit into one large FPGA chip and avoid some of these issues. Good luck doing something that can boot Android in that size.