Kavrous Technologies

Open Architecture Simplified Instruction Set

OASIS architecture

OASIS (Open Architecture Simplified Instruction Set) is a small, implementation-friendly instruction set architecture (ISA) for learning, FPGA soft cores, microcontrollers, and custom chip experiments. OASIS defines what a processor must do; each implementation chooses how to build it.

The architecture

A clear contract between software and hardware

What is OASIS?

OASIS stands for Open Architecture Simplified Instruction Set. Its specification defines instruction behavior, registers, control flow, and memory access so software and processor implementations can share a versioned contract.

Is OASIS tied to a particular bit width?

The architectural overview is independent of data width. Individual profiles define concrete register widths, instruction encodings, address ranges, and access sizes. Moving between profiles can require different software and encodings; a shared architectural model does not imply binary compatibility.

What does “simplified” mean?

The project emphasizes straightforward instruction decode, explicit operations, documented behavior, and hardware that is approachable to implement and study. Versioned specifications, machine-readable tables, and compliance tests make that behavior reviewable.

Architectural model

From instructions to state changes

These diagrams show functional relationships in the current model. They omit widths, capacities, and clock timing; they do not prescribe a pipeline or a physical bus layout.

OASIS core functional block diagram The program counter addresses instruction memory, which feeds decode and control. Decode selects register operands. Registers supply the ALU and the memory access path separately. ALU results and comparison decisions, and loaded memory values, feed writeback and next-PC selection. Writeback updates registers and the program counter. Program counterInstruction memory Decode & controlRegister file ALU / comparisonMemory access Data / MMIOWriteback &next-PC selection Address / store data Result / decision Load result Functional data flow; decode also selects execution and writeback
Core view: registers supply operands to execution and memory access. ALU results and branch decisions feed writeback and next-PC selection directly; memory loads have a separate result path. Writeback updates the register file, and next-PC selection updates the program counter. Control signals are summarized rather than drawn individually.

Explicit spaces for code, data, and peripherals (MMIO)

OASIS instruction, ordinary-memory, and MMIO spaces The processor fetches code through the instruction-memory path. Data accesses explicitly select ordinary memory or MMIO. A peripheral interface connects MMIO to platform devices such as GPIO, PWM, UART, and I2C. Device choices are implementation-specific. Instruction fetchData accessInstruction memory / codeOrdinary memory / dataMMIO / peripheral interfaceGPIO · PWM · UART · I2C* Space selection
System view: ordinary memory and memory-mapped input/output (MMIO) are distinct architectural spaces. *Peripheral examples come from DungV; they are platform choices, not requirements of every OASIS processor.

Profiles specify the details of addressing and access size. An implementation determines the physical memory, peripheral connections, and access timing. DungV can wait for a peripheral operation to complete before retiring the instruction.

Common questions

Architecture and implementation

How does DungV relate to OASIS?

DungV is an FPGA-oriented Verilog implementation of OASIS. It consumes a pinned OASIS baseline and documents its compatibility separately. The ISA contract belongs in OASIS; core timing, FPGA resources, programming interfaces, and board peripherals belong in the implementation.

Explore DungV on GitHub ↗
Read the compatibility report ↗

What is available today?

The OASIS repository contains specifications, instruction references, encoding tables, an assembler, compliance material, and toolchain work. DungV provides an FPGA implementation and board examples. Profile maturity varies; the wider-profile architecture work remains experimental. Consult the repositories for current support rather than assuming every profile is implemented.

Does the architecture require a particular pipeline or board?

No. The ISA describes visible behavior, while an implementation chooses its execution structure and target hardware. The block diagrams here explain the functional model without prescribing cycle counts, pipeline stages, or an FPGA family.

Where can I find the specification and licensing terms?

The OASIS repository is the starting point for versioned specifications and project files. Review the applicable licensing terms for each repository and artifact before using or redistributing it; the architecture name alone does not define those terms.

Open the OASIS repository ↗
Browse the architecture specification ↗

Further reading

OASIS white paper

A white paper is in preparation. When published, it will be linked here alongside the architecture specifications and implementation resources.