Please read this page from the main YASEP interface
The YASEP datapath sizes
The YASEP architecture defines one instruction set with two overlapping and similar subfamilies,
or flavors, with a 16-bit or 32-bit wide datapath (YASEP16 and YASEP32 respectively).
They share about 95% of the behaviour and we try to keep as much features in common as possible.
We'll mainly speak about the differences here.
The first obvious difference is the word size :
The second obvious difference is the silicon footprint : YASEP16
uses roughly half the logic gates of YASEP32. If a compact CPU core
is needed (for a small FPGA), YASEP16 will leave more room for
peripheral circuits. And YASEP16 runs maybe 15% faster thanks
to shorter logic critical datapaths and shorter wires (because of the smaller size).
A third difference deals with memory. The program memory footprint
is not much affected because the instructions are the same. However
the memory access is substantially different:
requires more instructions than YASEP32 to process 32-bit values, so it's adapted
for classic microcontroller uses, for example, when data are mainly bytes or half-words.
- YASEP32 is more
fluent when fast datastreams must be processed (the datapaths are larger
and the memory bandwidth is increased), it can handle some graphics or more sophisticated
protocols (like TCP/IP).
The fourth difference is in the instruction set.
Some instructions that deal specifically with words or half-word
make no sense with the YASEP16, which uses the half-word (16-bit)
for everything. The following instructions
are specific to the YASEP32 and may trap (or hang the core, or even do nothing) when executed with the YASEP16 :
YASEP16 can only access 64K bytes, it is more
adapted to short programs. An address extension mechanism (with a page
table) can be used to extend the total addressable memory,
and different threads can access different memory areas
(as well as share some) but a pointer is still limited to 64K.
YASEP32 can access a theoretic 4GB area per thread
and is more suitable for serious applications.
It is not planned to support or implement as much yet
because it goes outside of the "embedded" domain.
And these instructions are YASEP16-only:
To help prevent coding mistakes, the YASEP32
and YASEP16 pseudo-instructions have
been defined. They indicate to the assembler which YASEP "flavor" is targeted,
so it can issue warnings when an assembled instruction is invalid for the selected core.
The similarity of the flavors makes it easy to create "dual-mode code", share
code between projects, perform platform detection etc. as long as no assumption
is made about data sizes and flavor-specific instructions are not used.
The other internal mechanisms are unchanged. For example, the Special Registers
have the same addresses (in the lower 64K range), so code can be easily ported.
The trap&interrupt mechanism (which is also accessed through the Special Registers)
has the same structure too.
In the YASEP32, the sign condition is read at bit #31 of the registers, and bit #15 for the YASEP16.
We can check the datapath width by writing on the bit #15 of a temporary register and check
if the sign condition is affected. This is easily performed by using the IMM20 form
of the MOV instruction :
MOV 8000h R1 ; R1=8000h in YASEP16 or 00008000h in YASEP32
ADD R2 R3 R4 MSB1 R1 ; Do something if YASEP16
This value can also be stored in a Special Register, along with other configuration informations.