You don't need to use a computer graphic tool to make a sketch.

However, your drawings look a bit disorganized. Many features represented in them, particularly the Block 2 drawing, look as though they were afterthoughts. One thing that should be apparent to anyone looking at the sketch is how the data objects flow through the core.

If I were making a '51, I'd start with a table of opcodes and what they do, which I believe you once presented, and I'd attempt to split up the opcodes into classes, execution of each of which has a shared number of cycles and number of byte fetches and/or stores. I'd try to figure out what can be shared between the members of a given class, and, having done that, I'd try to figure out what can be shared between the classes. Doing that will shed light on how the logic paths have to be concatenated for each instruction.

If you look at my pictures, you can see where the operands originate, and where they end up. It then also becomes apparent which operations can be overlapped to save time. All of the information you need to perform a given instruction is contained within its opcode. IIRC, there are 254 valid opcodes. The fact that it's a nearly dense set should make it easy to decode them. Until you know how the paths from source to destination are to be strung together for each opcode class, you'll have no luck determining what the opcode bits represent.

As for timing, see

http://www.8052.com/users/richard/clocksim1.JPG

This is a post-fit simulation in a 5-volt-tolerant CPLD with a 20 MHz input clock. If, for example, you use one clock for data objects, and the other for address objects, you can get the job done.

You don't have to do things this way, but it's simple enough.

RE