It is a compact 16-bit processor implemented in Verilog HDL.
The project focuses on developing a complete RTL processor while maintaining a strong verification baseline throughout the development process.
The current implementation contains a 16-bit datapath, 16-bit instruction format, 16 registers, ALU operations, control-flow instructions, RESET handling, STALL handling, and HALT support.
The current verified processor configuration is:
Processor width : 16-bit
Instruction width : 16-bit
Register count : 16
Register width : 16-bit
Register address : 4-bit
Program Counter : 4-bit
Instruction memory : 16 × 16-bit
ALU : 16-bit
Status flags : CF, ZF, NF, VF
Implemented opcodes : 14
Reserved opcodes : 2
The current instruction set contains:
ADD
SUB
AND
OR
XOR
NOT
SHL
SHR
SLT
EQ
MOV
NOP
JMP
HALT
Two opcode values remain reserved:
1011
1100
The project follows a verification-first development approach.
The basic development cycle is:
flowchart TB
DEFINE["Define Feature"]
RTL["Implement RTL"]
TB["Write / Update Testbench"]
REG["Run Regression"]
PASS{"PASS?"}
FREEZE["Freeze Baseline"]
DEBUG["Debug RTL"]
DEFINE --> RTL
RTL --> TB
TB --> REG
REG --> PASS
PASS -->|YES| FREEZE
PASS -->|NO| DEBUG
DEBUG --> RTL
The existing verified regression should be preserved when new functionality is introduced.
The current processor has a comprehensive self-checking regression.
Directed tests : 41
Random ALU tests : 10,000
Random program tests : 500
Total checks : 1,087,551
Passed : 1,087,551
Failed : 0
Instruction coverage : 14 / 14 = 100%
Functional coverage : 112 / 112 = 100%
X/Z scans : 51,966
X/Z failures : 0
Assertion failures : 0
The current regression is therefore the functional baseline for future development.
The processor currently operates with a 16-bit datapath.
Major 16-bit elements include:
ALU
Registers
Instruction
ALU result
Operands
The register organization contains:
16 registers
16 bits per register
The verification environment covers all register addresses and source-register combinations.
The ALU supports:
ADD
SUB
AND
OR
XOR
NOT
SHL
SHR
SLT
EQ
MOV
Arithmetic status flags are also verified.
The processor supports:
NOP
JMP
HALT
The verification environment tests multiple control-flow scenarios including jump chains, backward jumps, self-loops, and HALT behavior.
RESET behavior has been tested from multiple processor states.
Verified cases include:
RESET during normal execution
RESET after multiple instructions
RESET while HALTed
RESET held for multiple cycles
RESET with execution disabled
RESET blocking write-back
The processor supports execution stalling through its enable control.
The verification environment confirms that processor state is preserved while execution is disabled.
The two currently unused opcode values have been explicitly tested.
1011
1100
The reserved instructions do not cause unintended architectural writes.
The repository is being organized without unnecessarily changing the existing RTL interfaces.
The intended structure is:
Simple-Microprocessor-Verilog/
│
├── rtl/
├── tb/
├── programs/
├── docs/
├── diagrams/
├── scripts/
├── results/
└── constraints/
The existing source and testbench names should remain unchanged unless a future refactoring step explicitly requires otherwise.
This approach separates:
RTL
Verification
Documentation
Generated Results
Automation
Design Artifacts
while maintaining compatibility with the existing implementation.
The docs/ directory contains the technical description of the processor.
Current documentation:
docs/
├── architecture.md
├── instruction-set.md
├── datapath.md
├── memory-architecture.md
├── verification.md
└── development-notes.md
Each document has a specific purpose:
| Document | Purpose |
|---|---|
architecture.md |
Overall CPU architecture |
instruction-set.md |
ISA and instruction encoding |
datapath.md |
Data movement and execution |
memory-architecture.md |
Current memory organization |
verification.md |
Verification methodology/results |
development-notes.md |
Development history and roadmap |
The current processor is intentionally compact.
Current limitations include:
- 4-bit Program Counter
- 16 instruction locations
- No verified LOAD instruction
- No verified STORE instruction
- No separate general-purpose data-memory interface
- No pipeline
- No hazard detection
- No forwarding
- No interrupts
- No exception mechanism
- No cache
- No memory-mapped peripheral interface
These limitations describe the current implementation and are not deficiencies that have already been addressed.
The next development stage should focus on repository quality and implementation stability before introducing major architectural changes.
Recommended sequence:
1. Freeze current RTL baseline
2. Add documentation
3. Add verification artifacts
4. Organize repository
5. Add simulation scripts
6. Verify clean checkout
7. Improve module structure if required
8. Add new architectural functionality
Every functional change should be followed by regression testing.
Future ISA features may include:
Immediate arithmetic
Immediate logical operations
Conditional branches
Unconditional branches with expanded addressing
LOAD
STORE
CALL
RET
Stack operations
System/control instructions
Any new instruction should define:
- Opcode allocation
- Instruction encoding
- Operand behavior
- Register write behavior
- Flag behavior
- PC behavior
- Reset behavior
- Verification requirements
The current instruction memory contains only 16 locations.
A future implementation could expand the address space.
Possible progression:
Current:
4-bit PC
16 instruction locations
↓
Future:
8-bit PC
256 instruction locations
↓
Future:
16-bit PC
65,536 instruction locations
The actual width should be selected based on the target implementation and memory architecture.
A future data-memory interface could also support:
LOAD
STORE
operations.
A future version could evolve from the current simple execution model toward a pipelined processor.
A possible conceptual pipeline is:
IF
|
v
ID
|
v
EX
|
v
MEM
|
v
WB
Where:
IF = Instruction Fetch
ID = Instruction Decode
EX = Execute
MEM = Memory Access
WB = Write Back
Before introducing pipelining, the existing single-cycle/non-pipelined behavior should remain available as a verified reference.
If pipelining is introduced, additional verification will be required for:
Data hazards
Control hazards
Structural hazards
Potential mechanisms include:
Forwarding
Stalling
Pipeline flushing
Hazard detection
These should be introduced incrementally.
The current testbench uses simulation-based assertions and randomized testing.
A future verification phase can add formal properties.
Potential formal properties include:
RESET always returns PC to zero
STALL preserves architectural state
HALT preserves PC
JMP loads the correct target
ALU writes only the selected destination
Reserved instructions do not modify state
Formal verification can complement, rather than replace, the existing simulation regression.