Log#02: More flexibility and options for YASEP

A project log for YASEP News archives

A backup of the blog before the host erases it. A good opportunity to review the development, twists and turns of this ISA !

Yann Guidon / YGDESYann Guidon / YGDES 04/06/2020 at 18:390 Comments

By whygee on Tuesday 5 August 2008, 21:34 - Architecture

After some concertation with me, myself and my other instances, we came to the conclusion that it would be almost costless to make a 16-bit version of the YASEP architecture. In fact, only a few modifications are necessary to adapt the current 32-bit core for 16-bit operation. I can even foresee a 16-bit "compatibility mode" where a 16-bit program/thread can execute in a 32-bit core.

What is the difference ? Essentially, beside the smaller registers (smaller numbers can be computed), the memory access method needs to be adapted. There will be a limitation to 16-bit pointers, so instead of "segments", I'll use 4KB pages (protected memory will be logically available as a logical extension). The 64KB addressable range is split into 16 pages, each page can be configured for base address (on 4KB boundaries). A 16-bit core can then access up to 256MB of RAM (the limit of YASEP).

Such a small YASEP is suitable for smaller FPGAs and when horsepower is even less necessary. For "efficient" implementations, the pipeline remains the same and several threads will be interleaved as before. The speed and code density will be similar. Remove the pipeline gates and you get a slower but smaller core for typical microcontroller applications.

The structures and the instruction set remain untouched. The SHH instruction will be useless (or not) but it's apparently the only exception. The same tools will be used to generate the executable bytestream, the same source code could be used for 16-bit or 32-bit targets (to some extent).

The physical addresses and registers are the same too, so 16-bit and 32-bit "threads" can coexist/coexecute. The byte addressability works with the same principles (it's just implemented a bit differently).

It all looks promising and i'm updating my VHDL code now.

Another big modification will be the support for "short" immediate fields (Imm4) in the place of the SRC (register number) field. So i'll see later.


Going to a bi-size architecture was easy and an amazing evolution of that core. It made total sense and greatly increases the applications range.

The links to the online docs (the SHH link above) are broken... Rebuilding the docs will be a huge undertaking...