I am building a simple 16-bit CPU in Logisim and have the ALU ready and the opcodes that I want to have. Now I find it really hard to find the right coding for the commands so that the different subcircuits (e.g. logic, arithmetic) don't need all control wires (that build up the coding) as input, but as few as possible. Are there any strategies or methods that help with an efficient opcode design?
thx in advance
I think it is a good approach to study some other instruction sets.
A small one would be the MSP430 from TI it is a 16bit Processor with about 22 instructions.
http://www.physics.mcmaster.ca/phys3b06/MSP430/MSP430_Instruction_Set_Summary.pdf
You could also look into the Atmel AVRs they have also a quite small instruction set.
In a little project of mine I tried to develop a simple 32 bit processor in VHDL with a small instruction set (14 instructions):
Due to my current free time it is not fully finished. The instructions are implemented but two are not tested and maybe some status flags are missing.
Study (but don't replicate) the ARM approach to instruction coding. It's heavily prefix-orientated (like the Huffman tree approach recommended by Dzarda) and highly uniform in terms of where the register select part of the instruction is.
The unimaginative but reliable approach is to enumerate all the control signals you have, which will probably be more than 16 bits, and then attempt to do Karnaugh-map style logic minimisation on them.
Once I tried doing a 4-bit CPU with 8-bit instruction length core in Logisim. Ended up with a simple state machine, more than a CPU, really.
Random things to look for
Excellent video on Computerphile about Huffman trees:
The ISA I wrote for class once had a 4 bit op code like so:
1XXX ALU instructions
01XX jump, jump register, call etc
001X branch not equal, branch equal zero
000X 0 - load, 1 - store
Rather than being the most optimal, this is one of easier styles to construct/design gates for because the input signal of a single bit can control entirely what logic path is taken. Alternatively, you can Huffman Code your most used symbols and zero pad them to get a fixed length op code.
One thing you'll need to consider is whether to allow any form of multi-word instruction, or anything that can "act" like a multi-word instruction; if you do, you may then want to consider whether to use additional instruction words following the main instruction, or prefix words before it. Allowing prefixes and follow-on words can increase the complexity of interrupt handling, but it can avoid the need to fit rarely-used instructions in the same opcode space as commonly-used ones.
If instructions are fetched on the cycle before they execute, one could have a "conditional branch" instruction which either causes the next instruction word to be skipped or else have its contents transferred directly into the program counter; such a design might add some extra complexity to interrupt sequencing, but it could ease the need to use a big portion of the opcode space for "branch", "jump" and "call" instructions, while allowing a much wider range of branch conditions than would otherwise be possible. Since a branch which is taken will generally require a dead cycle following execution of the instruction itself regardless of where the address comes from, having the address come from the following word which has been fetched but won't be executed doesn't cost any extra time.
Even though moving the target address out of branch instructions will reduce how much of the opcode space they gobble up, a 16-bit opcode format is still pretty tight. Using prefix instructions can help with that. If, for example, one wants to have 32 registers, allowing any register to be independently specified as source1, source2, and destination would require 15 bits in the opcode, allowing a whopping total of two instructions. Not very useful. On the other hand, being able to use any of 32 registers for each of the three operands would be nice. One could balance the two goals by having any ALU operation which isn't preceded by a prefix use eight bits to make two one-of-sixteen register selections, but have an ALU operation which immediately follows a prefix use some bits in the prefix along with eight from the following instruction, so as to allow independent selection of both sources and the destination from the full set of 32. Instructions which use the upper registers would take two words/cycles rather than one, but in some cases such a tradeoff could be well worthwhile. The biggest difficulty with using prefixes is that one must either prevent an interrupt from occurring between a prefix and the next instruction or else ensure that if an interrupt does occur there the instruction after the prefix will still use the right registers [e.g. by having the program-counter save logic store the address of the last non-prefix instruction executed].
Using multi-word instructions will make some aspects of the design more difficult, but it may reduce the need to make other difficult decisions.
This guy has the best details on understanding hard wiring the hardcoded portion of a Decoder, which explains the control lines for a hardcoded CPU: http://minnie.tuhs.org/CompArch/Tutes/week03.html As you can see, your choice in Opcodes really impacts how complex the Decode logic is.
