Well ... there's been a lot of literature about FPGA reliability, and I'd suggest you look at some of that just to get an idea of what the order of magnitude of the likelihood of random logic failure in FPGA is.

An FPGA is little more than an SRAM with feedback. That's the reason why unused LUT's in FPGA can be used as "distributed RAM."

Yes, FPGA logic, registered or combinational, can vary widely in its timing, for reasons of routing and placement within the IC. Registered structures can vary just as much, though, for the same reasons. You can allow the development software to compile your HDL or schematic, and subsequently assign the necessary resources. However, just as you might with an HLL compiler on your MCU, you can take the results from the automatic PAR and "fix/improve" it by applying brain power, wherever it's necessary. Placement and routing is often done by hand when it's necessary to preserve pinout, improve timing, or reduce FPGA size.

IIRC, there are 254 valid and distinct opcodes in the 805x instruction set. It's unlikely that the original designers of the core used a translation table or lookup table ROM to provide the signals to all the buffers, latches, and flip-flops that comprise the core, since they didn't have to match an existing opcode set, they would simply have done that lookup on paper, as there's no translation necessary.

In FPGA, there's no restriction on how many ALU's you can implement, nor is there any reason why you can't use synchronous presettable up/down counters, which I've suggested you can avoid by the methods I suggested. There's no reason you can't do that, though. Unless you can find a way to use the time interval during which the output from the ALU is being written to registers, SFR space, memory, or whatever, you might as well use it for doing the address arithmetic. The ALU is a big chunk of the logic in the core, and implementing those long presettable up/down counters (DPTR, SP,for example), of which which each contains quite a bit of combinational logic, will cost quite a bit both in routing resources and in LUT's. It's up to you, of course.

As for decoding the opcodes ... if you separate them into classes as I previously suggested, I think you'll find that there are bits that tell you what's expected in terms of steering and counting logic. If you think in terms of a derived mask and a "johnson counter" or "one-hot" register (e.g. CD4017) I think it will become apparent how you can generate the necessary state machines for timing and execution. It's probably the least interesting and most tedious part of the task.

RE