Klaus.Schleisiek AT freenet.de

Using an FPGA based simple and extensible processor core as the foundation of a system eventually frees the "core aided programmer" from the limitations of any static processor architecture, be it CISC, RISC, WISC, FRISC or otherwise. No more programming around known hardware bugs. A choice can be made as to whether a needed functionality should be implemented in hardware or software; simply, the least complex, most energy efficient solution can be realised while working on a specific application. Building on an FPGA, time critical and perhaps complex functions can be realised in hardware in exactly the way needed by the application offloading the processor from sub-optimal inner loops.

The FPGA approach also makes the user independent from product discontinuity problems that haunt the hi-rel industry since the dawn of the silicon age. Finally: putting the core into FPGAs puts an end to one of the high-level programming language paradigms, namely the aspect of (hoped-for) portability. Once I can realise my own instruction set, I am no longer confronted with the need to port the application to any different architecture and henceforth, the only reason to adhere to a conventional programming style is the need to find maintenance programmers. Remains the need for a vendor independent hardware description language to be portable w.r.t. any specific FPGA vendor and family. To date, MicroCore has been realised in VHDL, using the MTI simulator and the Synplify and Leonardo synthesisers targeting Xilinx and Altera FPGAs. For more and up-to-date information, please refer to "www.microcore.org".

A novel feature of MicroCore are its two different inputs to react to external events:

Interrupt: An event did happen that was NOT expected by the software.

Exception: An event did NOT happen that was expected by the software.

MicroCore is not confined to executing Forth programs but it is rooted in the Forth virtual machine. MicroCore has been designed to support Forth as its "Assembler". Support for local variables (relative return-stack addressing) is cheap and seems to be all that is needed to soup up MicroCore for C. Instructions for interpreting token threaded code have been included to support Java.

1. Lit/Op Bit

1: 7-bit Literal (signed)

0: 7-bit Opcode

The Lit/Op field is a semantic switch:

When set, the remaining 7 bits are interpreted as a literal nibble and transferred to the Top-of-Stack (TOS) register. When the previous instruction had been an opcode, the literal nibble is sign-extended and pushed on the stack. If its predecessor was a literal nibble as well, the 7 bits are shifted into TOS from the right. Therefore, the number of literal nibbles needed to represent a number depends on its absolute magnitude.

When not set, the remaining 7 bits are interpreted as an opcode. Opcodes are composed of three sub-fields whose semantics are almost orthogonal: Type, Stack, and Group. Not all possible bit combinations of these fields have a meaningful semantic easing instruction decoding complexity.

2. Type field

Code	Name	Action
00	BRA	Branches, Calls and Returns
01	ALU	Binary and Unary Operators
10	MEM	Data-Memory and Register access
11	USR	Not used by core, free for user extensionsUser instructions / immediate calls

BRAnches are conditioned on the group field and they consume the content of TOS, using either TOS or TOS+PC as destination address. Although elegant, the fact that each branch has to pop the stack to get rid of the destination address makes the implementation of Forth's IF, WHILE, and UNTIL cumbersome. Therefore, the DROP_FLAG instruction has been implemented to get rid of the flag prior to executing the branch. Calls push the content of the PC on the return-stack while branching. Returns pop the return-stack using it as the address of the next instruction.

ALU instructions use the stack as source and destination for arithmetic operations. Unary operations only use TOS, binary operations use TOS and Next-of-Stack (NOS) storing the result in TOS. Complex math step instructions use TOS, NOS and TOR.

MEMory instructions refer to the data memory when the most significant bit of TOS, which holds the address, is not set. When set, it refers to input/output operations with the external world. The return-stack occupies the upper end of data-memory and the Program Memory may be accessed at the I/O space if van Neumann addressing has been implemented. Eight internal registers can be accessed directly using the Group field.

32 USeR instructions are free for any application specific functions, which are needed to achieve total system throughput. The first four USeR instructions coincide with MicroCore's hardware vectors RESET, ISR (InterruptServiceRoutine), ESR (ExceptionServiceRoutine), and OSR (OverflowServiceRoutine). As a default, the remaining 28 instructions perform a call to 28 trap vector addresses that have room for a sequence of instructions to be used to e.g. emulate multi-cycle instructions.

3. Stack field

Code	Name	Action
00	NONE	Type dependent
01	POP	Stack->NOS->TOS
10	PUSH	TOS->NOS->Stack
11	BOTH	Type dependent

POP pops and PUSH pushes the data stack. The stack semantics of the remaining states NONE and BOTH depend on type and on external signals INTERRUPT and EXCEPTION. This is where the opcode fields are non-orthogonal creating instruction decoding complexity, which is gracefully hidden by the synthesiser.

4. Group field

Code	Binary-Ops ALU	Unary-Ops ALU BOTH	Complex-Math ALU NONE	Conditions BRA	Branches BRA PUSH	Registers MEM
000	ADD	NOT	MULTS	NEVER	DUP	STATUS
001	ADC	SL	0DIVS	ALWAYS	EXC	TOR
010	SUB	ASR	UDIVS	ZERO	QDUP	RSTACK
011	SSUB	LSR	not used	NZERO	QOVL	LOCAL
100	AND	ROR	LDIVS	SIGN	INT	RSP
101	OR	ROL	not used	NSIGN	IRET	DSP
110	XOR	ZEQU	not used	NOVL	THREAD	TASK
111	NOS	CC	SWAPS	NCARRY	TOKEN	IP

Instructions that are not available in the minimal implementation are set in italics.

The semantics of the group field depend on the type field and in the case of ALU and BRA also on the stack field.

Of the binary operators NOS is used to realise OVER and NIP.

Unary operations are detailed below.

Of the conditions, NEVER is used to realise NOP, DUP and DROP. NZERO supports the use of the Top-Of-Return-stack as a loop index. PAUSE and INT are conditions to aid in processing external events INTERRUPT and EXCEPTION.

Of the registers, TOR is used to implement R@, whereas RSTACK implements >R and R>.

1. BRA instructions

LIT	Stack	act	Operation	Forth operators / phrases
*	none	none	conditional return from subroutine When Cond=ZERO or NZERO Stack -> NOS -> TOS	EXIT NOP ?EXIT 0=EXIT
-	pop		conditional branch to Program[TOS] Stack -> NOS -> TOS	absolute_BRANCH
+	pop		conditional branch to Program[PC+TOS] Stack -> NOS -> TOS	relative_BRANCH
*	push		Complex branches, see below	DUP ?DUP INTERRUPT IRET EXCEPTION ?OVL
-	both	pop push	conditional call to Program[TOS] Stack -> NOS -> TOS	absolute_CALL DROP
+	both	pop push	conditional call to Program[PC+TOS] Stack -> NOS -> TOS	relative_CALL DROP

 

2. ALU instructions

Stack	act	Operation	Forth operators / phrases
none	none	Complex math instructions, see below	SWAP
pop		Stack -> NOS <op> TOS -> TOS	+ - AND OR XOR NIP
push		NOS <op> TOS -> TOS TOS -> NOS -> Stack	2DUP_+ OVER
both	none	TOS <uop> -> TOS Unary math instructions, see below	0= 2* ROR ROL 2/ u2/

 

3. MEM instructions

Stack	act	Operation	Forth operators / phrases
none	pop	Stack -> NOS -> TOS -> Register LOCAL := Stack -> NOS -> Data[RSP+TOS] TASK := Stack -> NOS -> Data[TASK+TOS]	>R, R! store into local variables store into task variables
pop		Stack -> NOS -> Data[TOS+<inc>] TOS + <inc> -> TOS	! pre-incrementing data memory or I/O store
push		Data[TOS+<inc>] -> NOS -> Stack TOS + <inc> -> TOS	@ pre-incrementing data memory or I/O fetch
both	push	Register -> TOS -> NOS -> Stack LOCAL := Data[RSP+TOS] -> NOS -> Stack TASK := Data[TASK+TOS] -> NOS -> Stack	R@, R> fetch from local variables fetch from task variables

 

4. USR instructions

By default, the USR instructions perform an immediate call to the following vector address:

vector_addr = instruction(4..0) * usr_vect_width

Therefore, each trap vector has room for usr_vect_width instructions.

Four trap vectors are used by MicroCore itself:

0: Reset

1: ISR: Interrupt Service Routine

2: ESR: Exception Service Routine

3: OSR: Overflow Service Routine

 

5. Complex Branches (BRA PUSH)

DUP	TOS -> TOS -> NOS -> Stack
QDUP	Performs a DUP when TOS is non-zero, otherwise does nothing
QOVL	Performs a call to the overflow service routine when the overflow status bit is set
IRET	Performs an EXIT and restores the status register from TOS
THREAD	Threaded code interpreter. IF Data[IP] < 0 THEN (most significant bit set) Program_Address <- Data[IP] IP <- IP+1 ELSE PC <- Program_Address - 1 IP <- Data[IP] Stack <- NOS <- TOS <- IP+1 END IF The two instruction sequence "THREAD >R" is a tag threaded code interpreter. When the most significant bit is set, the remaining bits are an address of the code to be executed. When the most significant bit is not set, it is the address of another threaded code definition. The sequence "THREAD >R" will be automatically repeated until an executable code sequence is located, pushing return addresses on the return stack appropriately.
TOKEN	Token threaded code interpreter. The two instruction sequence "THREAD TOKEN" is a token threaded code interpreter. IF IP = address within token table THEN Program_Address <- Data[IP] IP <- TOS <- NOS <- Stack ELSE >R END IF

 

6. Unary Math Instructions (ALU BOTH)

SL	Shift Left	0 -> LSB, MSB -> C
ASR	Arithmetic Shift Right	MSB -> MSB-1, LSB -> C
LSR	Logical Shift Right	0 -> MSB, LSB -> C
ROR	ROtate Rigth	C -> MSB, LSB -> C
ROL	ROtate Left	C -> LSB, MSB -> C
ZEQU	Zero EQUals	When TOS=0, true -> TOS, otherwise false -> TOS
CC	Complement Carry	not Carry -> Carry

 

7. Complex Math (ALU NONE)

When both NOS and TOR are implemented, complex math step instructions are available.

MULTS is a step instruction for an unsigned multiply of two numbers producing a double precision product. The multiplicand must be in NOS, the multiplier must be in TOR and the product builds up in TOS || TOR.

Macro: umultiply ( mult1 mult2 -- prod_l prod_h )

>r 0 #data_width 0 ?DO mults LOOP nip r> ;

generates code for a multi cycle U* instruction, which is independent of the data word width. U* may be interrupted at any time.

0DIVS, UDIVS, LDIVS are step instructions for an unsigned divide of a double precision dividend by a divisor, producing a single precision quotient and the remainder. When the result does not fit into the quotient, the overflow status bit will be set.

Macro: udivide ( div_l div_h divisor -- rem quot )

0divs #data_width 0 ?DO udivs LOOP ldivs nip r> ;

generates code for a multi cycle UM/MOD instruction, which is independent of the data word width. In order to execute the UDIVS instruction, the divisor must be in NOS, div_l must be in TOR and div_h must be in TOS. 0DIVS takes care of this parameter set up clearing the overflow bit as well. Each division step must take into account the most significant bit of the previous step and therefore, a final step LDIVS is needed to produce a valid quotient and to check for overflow. UM/MOD may be interrupted at any time.

 

8. Instruction Mnemonics

\ Conditional exits

1. STATUS

Bit	Name	Access	Description
0	C	R/W	The Carry-Flag reflects the result of the most recent ADD, ADC, SUB, SSUB, SL, ASR, LSR, ROR, and ROL instructions. When subtracting, it is the complement of the borrow bit.
1	OVL	R/W	The Overflow-Flag reflects the result of the most recent ADD, ADC, SUB, SSUB, UDIVS, and LDIVS instructions.
2	IE	R/W	Interrupt-Enable-Flag
3	IIS	R/W	The Interrupt-In-Service-Flag is set at the beginning of an interrupt-acknowledge cycle. It is reset by the IRET (Interrupt-RETurn) instruction. When IIS is set, interrupts are disabled. When the Status-register is read, IIS always reads as '0'.
4	LIT	R	The LITeral-Status-Flag reflects the most significant bit of the previous instruction.
5	N	R	The Negative-Flag reflects the content of the most-significant-bit of TOS or of NOS when LIT=1
6	Z	R	The Zero-Flag reflects the content of TOS or of NOS when LIT=1

Z and N reflect the actual state of the top "number" on the stack. This may be in TOS (when LIT=0) or in NOS (when LIT=1) because e.g. a target address may be in TOS.

For the ordering of the bits it has been taken into consideration that "masks" for masking off flags can be loaded with only one literal nibble. This is important for the C- and IE-flags, see below.

2. TOR

Top-Of-Return-stack. This allows access to the return-stack without pushing or popping it.

3. RSTACK

Return-STACK. When RSTACK is used as a destination, a return-stack push is performed. When it is used as a source, a return-stack pop is performed.

4. LOCAL

This register-addressing mode (MEM NONE LOCAL and MEM BOTH LOCAL) is included in order to support C and its local variable mentality. These can be placed in a return-stack frame. The actual data memory address is the sum of RSP+TOS. After the memory access, the absolute memory address will remain in TOS.

5. RSP

Return-Stack-Pointer. It is used to implement the return-stack that is located at the upper end of the data memory and it can be read and written to support multi-tasking and stack-frame linkage. The return stack pointer width is defined on the VHDL level. For multi-tasking support, multiple return stacks can be instantiated extending the address to the left of the return-stack-pointer itself.

6. DSP

Data-Stack-Pointer. It is used to implement the data-stack and it can be read and written to support multi-tasking. The data stack pointer width is defined on the VHDL level. For multi-tasking support, multiple data stacks can be instantiated extending the address to the left of the data-stack-pointer itself.

7. TASK

The TASK register itself can be read and written via memory mapped I/O (address = -2). In a multi-tasking environment it would hold an address pointing at the Task Description Block (TDB) of the active task. The implementation of the multitasking mechanism is operating system dependent. Variables that are local to a task can be accessed via the MEM NONE TASK (store) and MEM BOTH TASK (fetch) instructions. The data memory address is the sum of TASK+TOS and after the memory access the absolute memory address remains in TOS.

If the TASK register is not used for multitasking support, it constitutes a general base register for a pre-incrementing base-offset addressing mode.

8. IP

The IP register is used to support tag and token threaded code. See: THREAD and TOKEN in the complex branches group.

1. FLAGS (read) / IE (write) (-1)

This is a pair of registers – FLAGS for reading, IE (Interrupt Enable) for writing.

An interrupt condition exists as long as any bit in FLAGS is set whose corresponding bit in IE has been set previously. Interrupt processing will be performed when the processor is not already executing an interrupt (IIS-status-bit not set) and interrupts are enabled (IE-status-bit set).

Typically at the beginning of interrupt processing (after calling the hard-wired interrupt handler address ISR) the FLAGS-register will be read. One specific bit is associated with each potential interrupt source. When a certain interrupt has been asserted, its associated bit will be set. All interrupts are static and therefore, it is the responsibility of the interrupt service routine (ISR) of a specific interrupt to reset the interrupt signal of the external hardware before the end of the ISR.

IE (Interrupt Enable) is a register, which can only be written, and it holds one enable bit for each interrupt source. Setting or resetting interrupt enable bits is done in a peculiar way, which could be called "bit-wise writing":

When IE is written, the least significant bit determines whether individual IE-bits will be set ('1') or reset ('0'). All other bits written to IE select those enable bits, which will be affected by the write operation. Those bits that are set ('1') will be written to, those bits that are not set ('0') will not be changed at all. This way individual interrupt enable bits may be changed in a single cycle without affecting other IE-bits and without the need to use a "shadow variable".

2. TASK register (-2)

The TASK register itself can be read and written at address -2. The TASK register sets the base address for the MEM NONE TASK and the MEM BOTH TASK data memory access instructions.

1. The Interrupt Mechanism

At first, interrupt requests are synchronised.

In the succeeding cycle(s) the following mechanism will unfold by hardware design:

1^st cycle:

The current program memory address will be loaded into the PC un-incremented.

The instruction BRA PUSH INT will be loaded into the INST register instead of the output of the program memory.

2^nd cycle:

Now, BRA PUSH INT will be executed that performs a CALL to the ISR-address, which is a constant address, selected by the program address multiplexer and STATUS is pushed on the data stack at the same time.

Therefore, only the first INT-cycle must be performed by special hardware. The second cycle (INT-instruction) is executed by an instruction that is forced into the INST register during the first Interrupt acknowledge cycle.

2. Handling Multiple Interrupt Sources

Whenever an interrupt source whose corresponding interrupt enable bit is set in the IE-register is asserted its associated bit in the FLAGS-register will be set and an interrupt condition exists. An interrupt acknowledge cycle will be executed when the processor is not currently executing an interrupt (IIS-bit not set) and interrupts are globally enabled (IE-bit of the STATUS-register set).

Please note that neither the call to the ISR-address nor reading the FLAGS-register will clear the FLAGS register. It is the responsibility of each single interrupt server to reset its interrupt signal in the external hardware as part of its interrupt service routine.

1. EXCEPTION Signal

An additional external control input has been added: EXCEPTION. When the processor intends to access a resource, the resource may not be ready yet. In such an event, it can assert the EXCEPTION signal before the end of the current execution cycle (before the rising CLK edge). This disables latching of the next processor state in all registers but the INST register that loads BRA PUSH EXC instead of the next instruction from program memory.

In the next processor cycle, BRA PUSH EXC will be executed calling the ESR-address (Exception Service Routine).

The ESR-address will typically hold a branch to code, which will perform a task switch depending on the operating system. This may be used to emulate the Transputer. Please note that the return address pushed on the return-stack is the address of the instruction following the one that caused the Exception. Therefore, before re-activating the excepted task again, the return address on the return-stack must be decremented by one prior to executing the EXIT instruction (BRA NONE ALWAYS) in order to re-execute the instruction, which caused the exception previously. Please note that no other parameter reconstruction operation prior to re-execution is needed because the EXCEPTION cycle fully preserves all registers but the INST register.

The EXCEPTION mechanism is independent from the interrupt mechanism. It adds one cycle of delay to an interrupt acknowledge when both an interrupt request and an EXCEPTION signal coincide.

In essence, the EXCEPTION mechanism allows to access external resources without having to query status bits to ascertain the availability/readiness of a resource. This greatly simplifies the software needed for e.g. serial channels for communicating with external devices or processes.

1. Memory Map

Addresses are shown for a 16 bit data path width by way of example.

1. Semantic Switches

CONSTANT syn_stackram : STD_LOGIC := '1';

When set to '1', the stack_ram will be relised as synchronous blockRAM. Otherwise, it will be realised as asynchronous RAM, which may be internal or external of the the FPGA.

CONSTANT with_locals : STD_LOGIC := '1';

When set to '1', the Instantiates the LOCAL addressing mode relative to the return stack pointer (RSP+TOS).

CONSTANT with_tasks : STD_LOGIC := '1';

When set to '1', the TASK addressing mode relative to the TASK register (TASK+TOS) will be instantiated. For multi-tasking, tasks_addr_width (see below) has to be set appropriately as well.

CONSTANT with_nos : STD_LOGIC := '1';

When set to '1', the NOS (Next-Of-Stack) register will be instantiated. This is needed for the single cycle SWAP instruction and the complex math step instructions.

CONSTANT with_tor : STD_LOGIC := '1';

When set to '1', the TOR (Top-Of-Return_stack) register will be instantiated. This is needed for the decrement_and_branch instruction NEXT and the complex math step instructions.

CONSTANT with_ip : STD_LOGIC := '1';

When set to '1', the IP (Instruction Pointer) register will be instantiated. This is needed for the THREAD and TOKEN instructions for interpreting threaded code.

CONSTANT with_tokens : STD_LOGIC := '1';

When set to '1', the TOKEN instruction will be instantiated, which allows rapid token threaded code interpretation.

2. Vector Widths

CONSTANT data_width : NATURAL := 32;

This defines the data path width and therefore, the magnitude of the numbers that may be processed. Please note that the object code will not change as long as the magnitude of the largest number to be processed fits the data path width.

CONSTANT data_addr_width : NATURAL := 21;

This sets the address range of the data memory, which can at most be data_width-1 wide because the "upper" half of the address range is used for external memory mapped I/O.

CONSTANT dcache_addr_width : NATURAL := 0;

Number of address bits of the data memory space that is realised as block-RAM inside the FPGA.

CONSTANT prog_addr_width : NATURAL := 19;

Program memory address width sets the size of the program memory. It can be at most data_width wide because all program addresses have to fit on the return stack.

CONSTANT pcache_addr_width : NATURAL := 0;

Number of address bits of the program memory space that is realised as block-RAM inside the FPGA. When pcache_addr_width=0, no internal RAM is used; when pcache_addr_width=prog_addr_width, no external RAM is used at all.

CONSTANT prog_ram_width : NATURAL := 16;

Number of address bits that may be used to modify the program memory van Neumann style. If set to zero, the program memory operates as a pure ROM of a Harvard Architecture.

CONSTANT ds_addr_width : NATURAL := 6;

Number of address bits for the data stack memory.

CONSTANT rs_addr_width : NATURAL := 8;

Number of address bits for the return stack memory.

CONSTANT tasks_addr_width : NATURAL := 3;

Number of address bits for the task address. 2**tasks_addr_width copies of the data and the return stack will be allocated. The task address is added to the left of both the ds_address and the rs_address.

CONSTANT usr_vect_width : NATURAL := 3;

The implicit call destination addresses for two adjacent USR instructions will be 2**usr_vect_width apart from each other.

CONSTANT reg_addr_width : NATURAL := 3;

Number of address bits reserved for internal memory mapped registers that reside at the upper end of the address space.

CONSTANT interrupts : NATURAL := 2;

Number of interrupt inputs and their associated FLAGS and Interrupt-Enable bits.

CONSTANT token_width : NATURAL := 8;

Number of bits for a token address of a token threaded system.

1. Forth Cross-Compiler

It loads on top of Win32Forth (Windows) or gforth (Linux) because these are free 32-bit system. It produces a binary image for the program memory as well as a VHDL file, which behaves as the program memory in a VHDL simulation. Because the Forth systems are 32 bit systems, the cross-compiler only supports numbers up to 32 bits signed magnitude. For even larger data path widths, the cross compiler has to be adapted accordingly if larger numbers need to be compiled.

It is a short but rather complex piece of code and my 4^th iteration on implementing a Forth cross-compiler in Forth.

The most challenging aspect was compiling MicroCore's branches, which, as relative branches, are preceded by a variable number of literal nibbles. The cross-compiler at first tries to get away with one literal nibble for the branch offset. If it turns out that this is not sufficient space for the branch offset at the closing ELSE, THEN, UNTIL, REPEAT, NEXT, or LOOP the source code is re-interpreted again, leaving space for the required number of literal nibbles in front of the branch opcode.

2. C Cross-Compiler

A first implementation has been realised for an earlier version of MicroCore at the technical university of Brugg/Windisch, Switzerland. The compiler is based on the LCC compiler, and a MicroCore back-end was created that takes the syntax tree as input.

It turned out that the LOCAL addressing mode is all that is needed to support C's local variable mentality.

1. Revision History