There is such a lack of good dialog here at this site now that it is in slow die more.

Maybe this can get a good discussion going....

I would like to veer off the direct topic of your question and ask why you feel it productive to put energy into placing an 8051 core into an FPGA?

I have found it rare to be the case that such usage model makes a lot of sense. My experience has shown that it can make a lot more sense to use a well validated commercial part in a design to contain the code and then have this MCU interface to an FPGA for that special high performance circuitry that must be done there for either performance or density requirements.

Even though FPGA costs per glob of gates are continuing to come down in price it is still more expensive in terms of silicon cost to embed a microcontroller core into an FPGA as opposed to using an external commercial chip. The wide range of available commercial chips, both in terms of cost and capabilities, lets you easily select the appropriate part to connect to the FPGA. You can interface via slower serial links (SPI, I2C etc) or via an actual bus structure. For example many of the higher end SiLabs parts support an optional external BUS interface that can map your XRAM data space directly into the FPGA in a glueless manner.

With the use of the commercial MCU parts you get to retain the best selection of development tools, debugger capabilities and choice of free/commercial compiler/tool sets. You completely eliminate the pain in the a$$ issue that you are dealing with right now.

One argument often put forth for putting the MCU core into an FPGA is that the eventual goal is to advance to a custom made chip. That is all well and good but might I suggest that it may be a good idea to develop a separate firmware development platform using a well supported MCU mated with an FPGA where you can retain the best of the tools needed to develop good code. Once code is validated in such environment it can be moved over in object form to the custom chip environment where it can be tested and validated. For this mode of testing you rarely need to have the ability to look at MCU registers and step code after breakpoints!

If the custom chip environment needs validation visibility then design that into the firmware and its supporting hardware as a validation specific tool/interface. This is much simpler than trying to go through the pain of what you are asking about here.