On second thought: 8-bit data/instruction bus makes for happier times. From a usage point of view, 16-bit is pretty silly in a microcontroller. Either you can get away with 8 bits (and use software for 16-bit operations), or you need 32 anyway.
So anyway:
Four 16-bit counters.
1) Preloadable, up only – for instruction counter – must be tri-state – its output feeds into the address bus of the 2^16B = 64KB SRAM. This counter is used to fetch the next instruction (or the next byte of a 2-byte instruction)
2,3) Preloadable, up/down – for data and return stack pointers, respectively. Can be re-written on the fly to switch between threads! These are also tri-state, and feed into the address bus of the SRAM.
4) Up only, maybe with prescaler? – used for system counter, to time things etc. Tri-state, connected to data bus.
Also: a boot loader consisting of an 8-bit parallel-output serial-input shift register, connected to a prescaler and a serial EEPROM on the serial side and the SRAM data bus on the parallel side, and a counter connected to the SRAM address bus. When the “chip” comes out of RESET, X bytes (hard-wired? DIP switch configurable? software configurable?) are read from the serial EEPROM and written into the first X bytes of the SRAM. After this is completed, execution starts from location 0 (the reset vector), which is where the boot code was loaded to.
The boot EEPROM would probably also be available to be written via another shift register, but this can sit on the I/O bus (which may or may not be the same as the memory bus).
Not entirely sure how one makes timing work in such a system… I mean, if a few different things are loading down the address bus, for example, and/or there are some things gated into memory, there must be quite some skew between the address bits. So how do you account for that when generating signal timings? I guess for gated things, the address lines are just fanned out and what’s actually gated are the chip enable/chip select signals, which can (and probably should) arrive later, anyway.
Target frequency for this whole mess is in the 10MHz range, btw – though I may take that down to 2-4MHz if I feel like it. (Obviously, real world applicability and performance are not huge concerns here.)
The only drawback with an 8-bit data bus is that a memory read will look like:
li
li [low byte]
la ; read data
and since the instruction size is only 8 bits, li would have to be a two-byte instruction, meaning it would take 5 cycles to load a byte of data. Maybe a 16-bit instruction size would be better? But that seems excessive, since it will be a pretty small instruction set, and there would be a lot of wasted space with 16 bits.
There COULD of course be an instruction that simply reads the next N bytes out of the program into the data stack. That way, program memory would look like
[read 2 bytes to dsp]
[byte 0]
[byte 1]
[load data]
[…]
Though that would lead to a almost micro-code like execution, which would be more difficult to implement in a LSI circuit.