This allows simple development of applications which might need to read sensor data from one device, output control to another device, and perhaps also implement some simple user I/O.
Each 'slot' can run j1a code (currently at 1/4 speed), and are started by writing an XT into one of $0100, $0200 or $0400 with io!.
Each slot then runs completely isolated from the others, so: no interrupts, task switching, thread deadlocks or changes of timing behaviour in other threads as the last one to be developed grows longer/slower.
A tasksel word on boot fetches the XT from $8000 io@, and if it isn't zero, executes it, then loops. The XT fetched from that address is automatically multiplexed so that code can be easily moved from one slot to another.
slot 0 is special in that, like a j1a, $8000 io@ always returns 0, and this is used at boot so that tasks 1:3 never try to run the user interface. Code tested on slot 0 will only run with a slight phase difference in timing when assigned to a slot.
There is an interface to reboot individual tasks, so that hung tasks can be stopped without interfering with others, but it is currently buggy.
When timing analysis tools are available, it should be possible to retime the j4a to allow it to run perhaps 4x as fast as the j1a, which would allow each task to have identical timing to code running on a j1a. This may be possible because the j4a is effectively a four-context, four-stage pipelined processor, and the ice40's RAM primitives are capable of running >4x the j1a's clock speed.
The design currently does not use half of the SRAM's on the hx8k, and may be able to fit into a hx4k chip, when such is supported by the toolchain.
This allows simple development of applications which might need to read sensor data from one device, output control to another device, and perhaps also implement some simple user I/O.
Each 'slot' can run j1a code (currently at 1/4 speed), and are started by writing an XT into one of $0100, $0200 or $0400 with io!.
Each slot then runs completely isolated from the others, so: no interrupts, task switching, thread deadlocks or changes of timing behaviour in other threads as the last one to be developed grows longer/slower.
A tasksel word on boot fetches the XT from $8000 io@, and if it isn't zero, executes it, then loops. The XT fetched from that address is automatically multiplexed so that code can be easily moved from one slot to another.
slot 0 is special in that, like a j1a, $8000 io@ always returns 0, and this is used at boot so that tasks 1:3 never try to run the user interface. Code tested on slot 0 will only run with a slight phase difference in timing when assigned to a slot.
There is an interface to reboot individual tasks, so that hung tasks can be stopped without interfering with others, but it is currently buggy.
When timing analysis tools are available, it should be possible to retime the j4a to allow it to run perhaps 4x as fast as the j1a, which would allow each task to have identical timing to code running on a j1a. This may be possible because the j4a is effectively a four-context, four-stage pipelined processor, and the ice40's RAM primitives are capable of running >4x the j1a's clock speed.
The design currently does not use half of the SRAM's on the hx8k, and may be able to fit into a hx4k chip, when such is supported by the toolchain.
Merry Xmas!