I believe this may indicate a fundamental flaw in the design methodology. You should, probably, start with a top-down image. That would focus entirely on what you have to do and ignore, completely, how it's to be done until all the what blocks are filled. In this particular case, the instruction set is well defined, as are the operations it represents. The only variables seem to be the timing and the physical architecture that produces it.

AFAIK, there's been no decision about whether there's to be any physical xDATA or xCODE space, nor is it particularly important from the top-level, whether there is. All the bits in SFR space are physical flipflops, so they can be read/written as desired. How to make that stuff faster or slower should be of no concern until the entire architecture is in place. The path lengths will indicate how long things will take, and where effort to speed things up will be of use.

When you move to the phase in which you begin determining how do implement various functions, you will by then have found that many operations can share the same facilities. Keep in mind that logical features don't always map into the same physical features.

Now, I freely admit I've had limited experience fabricating MCU cores in FPGA. I've had considerable mileage with standard-cell, sea-of-gates, and discrete TTL/ECL circuit designs, though. IMHO, if you pursue this in the way in which software is typically generated, you're unlikely to finish it. If you set yourself a target date, and strive to get it "running" by then, irrespective of performance, you may actually get there. In my experience, if performance goals are not met, the mistake that led to the disappointment usually was made on the first day or two. Size and cost goals are usually missed later on.



RE