VThreads: A novel VLIW chip multiprocessor with hardware-assisted PThreads

Abstract

performance increase on synthetic benchmarks, x5 on a parallel Mandelbrot implementation, 66% better on a threaded JPEG implementation, 79% better on an edge-detection benchmark and~13% improvement on DES compared to the Leon3MP CMP. In the range of 2 to 8 cores VThreads demonstrates a post-route (statistical) power reduction between 65% to 57% at an area increase of 1.2%-10% for 1-8 cores, compared to a similarly-configured Leon3MP CMP. This combination of micro-architectural features, scalability, extensibility, hardware support for low-latency PThreads, power efficiency and area make the processor an attractive proposition for low-power, deeply-embedded applications requiring minimum OS support.

An OpenCL software compilation framework targeting an SoC-FPGA VLIW chip multiprocessor

“…This is further compounded by targeting FPGAs which are less forgiving on mux-heavy designs such as a VLIW CMP. This key observation is elaborated in the companion paper [17] and will be mitigated in the next generation of the silicon using a further HDL parameter. as a ratio of the FPGA slice utilisation; with the single context configuration requiring 5% of the slices, whereas the 8C-8B requires 37.6%.…”

“…This is achieved through our core contributions which include the instantiation on the SoC-FPGA of the LE1 CMP and the subsequent on-line compilation of OpenCL kernels by our framework targeting the LE1 silicon. We also note that the LE1 is a capable MIMD accelerator, can easily accommodate shared-memory programming models such as OpenMP and POSIX Threads (PThreads) [17] and due to the proposed source transformation/compilation flow (Section IV), it does not suffer software-incurred performance inefficiencies due to thread divergence. The authors are unaware of any current heterogeneous systems that use fully configurable general-purpose, manycore, VLIW microprocessors as OpenCL accelerators on SoC-FPGAs.…”

“…We have chosen to the demonstrate the performance of the LE1 with no decoupling as this is the worst-possible case. A detailed description of an improved LE1 micro-architecture which fully alleviates this issue has been submitted [17] and is briefly discussed in Section VII. We also note that simple re-ordering of the produced binary by our back-end can eliminate practically all these stalls on the existing LE1 however this hasn't been included in the current OpenCL framework.…”