Per,

Please get a dictionary and look up the definition of concurrent, and then look up the definition of sequential. I've been advocating for concurrent execution of instructions. A pipeline is a sequential structure. Hence, a pipeline can't support anything operating concurrently. In fact, a pipeline can't and doesn't do anything. That's the reason it introduces delay. The pipeline produces the viewport of the execution unit into the code space. Using that as a concept, every processor has a pipeline, albeit a very short one. Some have a longer pipeline. 6502, for example, had a 2-byte pipeline, in that it fetched an instruction from memory while operating on the final byte of the previous one.

You're not wrong about what you're describing, but it's not in any way related to what I'm describing. A pipeline, a cache ... those are devices for matching a logic core with slower memory. In FPGA, the logic is nothing more than memory with feedback. The memory speed and logic speed are pretty closely matched, and, if anything, the logic is slower than the memory. There's no advantage in having cache if the code resides in the FPGA's block-RAM or distributed-RAM, and that occurs unless you use EXTERNAL code space. FPGA cells have very fast access times. External memory can be quite fast, too, but commercially available FLASH tends to "top out" at abot 55 ns access time. Clearly, some manufacturers have been able to manufacture faster FLASH, but it's not widely offered. MCU makers have used various mechanisms ranging from difficult and costly fast FLASH on-chip to automatic transfer from FLASH to on-chip SRAM code memory in order to improve code memory performance. Because interrupt response times are important, and pipelining increases interrupt response time, MCU makers have avoided pipelining as much as they could. This has not been true of CPU makers.

As I said before, you've been going on about one thing, and I about another. Neither of these belongs in this particular thread. If you want a discussion of whatever it is you've been advocating, then give it a name and start a thread, and we'll all kick it around. Please be sure to make a distinction, in your own mind, if nowhere else, between a parallel execution unit and a sequential one.

I'm not particularly interested in generating a new 805x core, as much as I'm interested in learning to "live with" the existing ones. The only interest I'd have in making my own core is to have it available for integration with custom logic that I can't readily implement in parallel with an existing commercially available MCU. This has, over time, become more attractive because FPGA have become larger at the small end, and, therefore, more costly at the low end, while becoming large enough to incorporate a processor core. It has come to the point at which using FPGA in combination with an MCU is sufficiently costly that one has to trade off incorporating a soft-core into the FPGA against using an external one. If I were to develop a soft-core, it would certainly have a different USART, and a different set of counter/timers. It also wouldn't have a RESET referenced to Vcc. If you want to invent a new core, well, you're welcome to do that. I'd recommend adding a few BYTE operations to the big, wide-word core you're likely to produce.

I, on the other hand, will probably stick with the 8-bitters.

RE