Yes, the memory-map-sensitive timing that you suggest would, indeed, be a nice feature, and not just in this MCU family.

Back in the '70's, I occasionally used memory map decoding to determine, not the number of wait states, but the actual clock rate at which my 65xx CPU's executed their code. That was because I sometimes equipped those CPU's with very fast (for the time) SRAM in one region, typically 4 KB at the bottom of RAM, where "zero page" and stack, among other things, lived, while operating the rest of the map at another clock rate. Those were easier to manipulate than the much more highly integrated MCU's we like today, however, and changing their clock rate didn't foul up the serial I/O as it would in an 805x.

There are numerous "free" IP's available for use with various FPGA families. These often require a bit of work to get them "just right" for a given application or a given level of performance, and I've found that most of them have been created, not with an eye to the actual architecture that would make the operate the fastest, but simply with an eye to getting them to work at all. I recently ran into one that was proven to run as a one-clocker at 16 MHz in relatively low-cost XILINX Spartan-II FPGA's. It was just a "standard" 805x, but could easily have features added.

Few applications actually demand the performance of the "ultra-high-speed" products offered by Maxim, but there aren't many that wouldn't benefit from a relatively fast (and that's what a single-clocker at 16 MHz is) MCU to which you could add additional UARTs, Timers, parallel ports, or custom hardware. Maybe your application would benefit from Manchester-encoded output or a digital PLL. Maybe you want to implement a special protocol that requires resources you don't find in a commercially available product. It's not going to be cheap, since roll-yer-own is not a cheap way to create the first one, but if you need a custom solution and don't want to hire a consultant and pay out millions, including the foundry fees licenses, etc, for an ASIC, it's an option.

I've found that few MCU IP's faithfully follow the architecture of the emulated core. Most of them execute the code properly, albeit with timing variations. Adding features is often a benefit. How often have you wanted to know whether you were executing an interrupt? Not all cores provide the means to tell you that. If you're using a Z80 core, how much would it help you to know which register set you're using? How'd you like to add another DPTR to your 805x? What about auto-increment/decrement? ... you get my meaning ...

There's lots of information contained in the data sheet if you really study it. That will tell you how much pipelining is used in order to achieve the proclaimed level of performance. Sometimes it's not as much as you think. Flushing the pipeline was mentioned in a prior post. I'm not sure that's a major hindrance to fast operation. If the implementation is kept simple, multilevel, beyond two levels, pipelining is, I believe, unnecessary.

For those who feel competent as coders but have trepidation about hardware design, tools such as VHDL should make you feel right at home whittling your own version of an 805x core. It's much like ADA, and certainly no harder to learn or use than 'C'.

Take a look. Maybe we'll all end up with something we like better than what's currently available.

RE