Technology Primer
Silicon Hive Technology Primer
Reconfigurable accelerators that bring computational efficiency (MOPS/W)
and programmability together, to displace ASIC and DSP co-processors in
Systems-on-Chips
Abstract
Standards and market uncertainties, non-recurring
engineering costs, and price pressures will require
the next generation of embedded computing
platforms to be fully programmable and low-cost.
Key enablers to such platforms are reconfigurable
accelerators that replace currently-used ASIC co-
processors. Silicon Hive currently provides two types
of reconfigurable accelerators that address these
market needs. Our block accelerators are
reconfigurable cores with very high computational
efficiency (MOPS/W) and small silicon footprint,
targeting the acceleration of critical digital signal
processing kernels. Silicon Hive’s streaming
accelerators are also reconfigurable cores targeting
very high and/or dynamic data-rate functions like the
IF front-end of wireless devices. The key
differentiators of our approach are: the robustness
and reliability of our technology, our ability to
customise our solutions to specific customer needs,
the high-level programmability of our cores (ANSI
C), and the fact that they can operate either as
standard DSPs or coarse-grained FPGAs.
Value proposition
Lower cost than ASICs, and fully-programmable
Many of today’s Systems-on-Chips (SoCs) deploy
multiple ASIC cores to support different applications
or standards in the system. A single Silicon Hive
reconfigurable core can replace a set of ASICs at
similar computational efficiency (MOPS/W), allowing
for a simpler solution that remains programmable
after device fabrication. Since the same hardware is
time-shared to implement functionality previously
mapped onto multiple ASICs, the solution is also
smaller in silicon footprint.
Superior performance and lower power
Other SoC design teams prefer to map most, if not
all, functionality onto programmable solutions.
However, the markets they can address are limited
by the lower computational efficiency (MOPS/W)
achievable with traditional processors and DSPs.
For these, a Silicon Hive reconfigurable core can
enable the SoC to support more and higher
performance applications, standards, and features.
1  Philips Electronics N.V. 2003
Why programmability?
There are several reasons why programmability has
become a priority in today’s SoCs and systems in
general.
Application IP protection
Application and/or service providers usually have
proprietary algorithms, the secrecy of which they
need to defend. They will not disclose
implementation information to chip-makers. Although
IC design is not at all their core capability, these
companies are often forced into it, delivering solely
an encrypted net-list to a chip-maker.
Reconfigurability offers application and service
providers the more cost-effective option of mapping
their algorithms themselves onto a pre-fabricated
part.
Uncertainties
Uncertainty related to multiple or immature
standards makes it harder to fix the functionality of a
device at design-time. Sometimes, sheer lack of in-
house understanding of a standard may render an
ASIC implementation impossible. In addition, today’s
market realities make it unclear what functionality a
device should support. Which applications will catch
up and which will soon become obsolete?
Reconfigurability substantially reduces the risk of
making an early choice.
Time-to-Market
This is another growing concern in markets with
increasingly short windows of opportunity for product
introduction. Often, one cannot afford the long
design and fabrication cycles for ASICs, but would
rather program a pre-designed, pre-fabricated,
reconfigurable part.
Non-Recurring Engineering (NRE)
NRE costs have been a lot talked about recently,
mainly in relation to the increasing costs of mask-
sets. However, mask-sets are only a small part of a
total chip design project cost. Still, the NRE cost of
ever larger VLSI design teams and associated infra-
structure is a bigger issue in itself. This can be
controlled with the use of a reconfigurable part, as
long as this part is straight-forward to program, and

the recurring silicon area penalty implied is reduced
(in both cases, unlike FPGAs).
Logistics and inventory
The costs of managing a large variety of slightly
different products can translate into expensive
inefficiencies. That can be solved when product
variations are implemented in software.
Deploying reconfigurable accelerators
We enable the replacement of all ASIC accelerators
in SoCs with reconfigurable cores, rendering the
SoC fully programmable after fabrication. This way,
flexibility is maintained throughout the product life-
cycle. At the same time, our cores will preserve a
computational efficiency (MOPS/W) and a silicon
foot-print comparable to that achievable with ASIC
cores.
Figure 1. SoCs with Silicon Hive cores.
Figure 2. Silicon Hive’s architecture design space overview.
2  Philips Electronics N.V. 2003
Technology Primer
Our vision is illustrated in Figure 1. The Silicon
Hive reconfigurable cores replace both the ASICs
and the DSP accelerators.
Since all accelerators are now reconfigurable,
their resources can be time-multiplexed. This allows
for a more optimal utilisation of the available
hardware, reducing redundancies. Depending on the
case, it can lead to a smaller silicon foot-print than
can be achieved with ASICs.
Our reconfigurable architectures
The basic component of the architecture of Silicon
Hive’s accelerators is the Processing and Storage
Element (PSE). See Figure 2. A PSE is a VLIW-like
data-path consisting of several interconnect
networks (IN), one or more operation-issue slots (IS)
with associated function units (FU), distributed
register files (RF) and, optionally, local memory
storage (MEM). PSEs are designed according to a
template that ensures all PSEs are easy and clean
data-paths for a compiler to handle, guaranteeing
high-level of programmability by construction.
A matrix of one or more PSEs, together with a
VLIW-like controller (CTRL) and configuration
memory (CONFIG. MEM), make up a cell. A cell is a
fully-operational processor capable of computing
complete algorithms. PSEs within a cell can
communicate with each other via data
communication lines (CL). Typically, one application
function at a time is mapped onto the matrix of
PSEs. The more PSEs are present, the more the
function can be mapped in space, in a data-flow
manner.
 Technology Primer

An array of one or more cells, connected together across the streaming array, occupying different sub-
via a data-driven communication mechanism, forms sets of cells, so to implement complete sub-systems.
a streaming array. The communication across cells
takes place through blocking FIFOs accessed from
load/store (LD/ST) units within the cells. Multiple
functions can be concurrently mapped onto the
streaming array, each one occupying a non-
overlapping sub-set of the cells.
Many different trade-offs between the number of
cells, and the number of PSEs per cell, can be
made. In general, the closer the data-rate of a given
function is to the clock rate of the processor, the
more cells should be used. This is because the cycle
budget for what a single cell can do is, in this case,
very small, so the computation must be spread
across potentially smaller cells. For applications with
data-rates far lower than the processor’s clock rate,
the cycle budget is higher, and a small number of
cells with a relatively high number of PSEs may lead Figure 3. Diagram of Silicon Hive’s block accelerators.
to more optimal exploitation of instruction-level
parallelism, higher modularisation, and ease of
programming.
Silicon Hive’s internal design methodology and
tools allow for the very quick design of different PSE
architectures, cells with different numbers of PSEs
interconnected in different ways, and streaming
arrays with different numbers of cells interconnected
in a variety of patterns. This way, Silicon Hive can
timely create a virtually unlimited variety of
application-domain-specific cores, as market
evolution dictates. Each core is reconfigurable after
fabrication, and flexible enough to tackle all
application needs within its target domain.

Reconfigurable accelerator products

Silicon Hive makes and licenses synthesisable cores
that are to be integrated into third-party Systems-on-
Chips (SoCs). The cores are reconfigurable
accelerators that are designed to run alongside a
host processor (e.g. an ARM), within a standard
system-level infrastructure (buses, memories, I/O
modules, etc.). Currently, we offer two types of
products: stream accelerators and block
accelerators.
Block accelerators typically consist of a single
cell, containing from one to several PSEs in a matrix
organisation. See Figure 3. They target functions
with a data-rate substantially lower than the
accelerator’s clock speed. They are made to process
framed data in memory (e.g. MPEG blocks, or
OFDM symbols). Typically, they will process one
application function at a time, time-multiplexing their
data-path resources across different functions.
Stream Accelerators consist of multiple, small
cells with typically one PSE each. See Figure 4.
They target functions with extremely high and/or
dynamic data-rates, approximating the accelerator’s
own clock speed (e.g. IF front-end filtering, or time-
domain equalisers). Stream accelerators are made
to process streaming data. Typically, several
different functions are cascaded simultaneously
Figure 4. Diagram of Silicon Hive’s stream
accelerators.
Programming flow
Silicon Hive provides high-level programmability for
all its cores. Our strategy is to abstract details of the
architecture and low-level scheduling and resource
allocation away from programmers, so they can
focus on optimising applications in C. We offer three
different tools to tackle all stages of programming
our cores.
The Partitioning Compiler
The partitioning compiler is a powerful profiler and
code transformation tool that helps programmers
partition code between accelerator(s) and host
processor(s), without the need for prior application
knowledge. It also helps partitioning a kernel across
different cells of a streaming array. The parameters
used by the tool for proper isolation of kernels
include: the identification of functions and loops with
high cycle count, the minimisation of communication

3  Philips Electronics N.V. 2003


and synchronisation overheads with a host
processor and system memory, and the identification
of functions with high amounts of intrinsic
parallelism.
The tool reads in ANSI C, and produces ANSI C
at the end, so it can be seamlessly integrated into
virtually any existing programming flow.
The partitioning compiler is an optional tool to aid
system-level partitioning, and is not required to
program any of Silicon Hive's cores.
The Spatial Compiler
The spatial compiler will read in a kernel program
written in a sub-set of ANSI C and use powerful,
innovative constraint-analysis and scheduling
techniques to extract the intrinsic Instruction-Level
Parallelism (ILP). The constraint analysis module
basically turns the partial-connectivity of the
accelerator data-path into an advantage, as opposed
to a hindrance. It prunes infeasible schedules (due
to the lack of full connectivity) from the scheduling
space, therefore helping the scheduler converge to
the optimal solution. The scheduling techniques
utilised are deterministic, therefore considerably
more reliable than traditional scheduling heuristics,
like list scheduling. Given sufficient time (typically in
the order of a few minutes), the compiler will find the
optimal solution.
The compiler automatically schedules all
operations in time, in a temporal assignment task
that is classical in compiler technology. However, the
spatial compiler also allocates all resources of the
architecture (function units, registers, and
interconnect lines) in space, with an aim to maximise
locality of reference. This is analogous to what
hardware synthesis tools do. Therefore, it is fair to
say that Silicon Hive’s spatial compiler blurs the
borders between compilers and hardware synthesis
tools, while preserving a sequential ANSI C input
format.
The spatial compiler is the only tool needed to
program Silicon Hive's block accelerators.
SHAPE
The Silicon Hive Array Programming Environment
(SHAPE) maps pre-compiled cell configurations onto
physical cells in a streaming array. See Figure 5.
SHAPE automatically assigns programs to cells in
the 2D-grid. The process is analogous to placement
& routing in FPGAs, and aims at fitting as many
tasks as possible within the physical limits of the
accelerator at hand, maximising Task-Level
Parallelism (TLP).
In addition to program placement, SHAPE is also
a debugging and simulation environment that
provides full visibility to the internal state of the cells
as a cycle-true simulation is carried out.
Computational efficiency
How can Silicon Hive cores achieve a computational
efficiency (MOPS/W) comparable to that of ASICs?
4  Philips Electronics N.V. 2003
Technology Primer
This is like an ASIC data-path…
A typical ASIC data-path will consist of a number
registers and function units geographically
distributed in the architecture at the locations where
they are needed. This locality of reference allows for
higher performance (short operand delays) and
lower power dissipation (low capacitive load on
interconnect lines). Just like an ASIC, a Silicon Hive
core contains a number of function units and small,
distributed register files. The register files are
geographically positioned close to the function units
that produce the operands they need to store,
therefore exploiting locality of reference the same
way ASICs do.
Figure 5. Placing pre-compiled cell configurations
onto a streaming array (tool snapshot).
Moving pipeline control to the compiler
The pipeline control and forwarding logic of
traditional processors and DSPs make the work of
programmers and compilers easier, by creating the
illusion that each instruction is executed in a single
cycle. However, this comes at a high silicon and
efficiency cost, due mainly to the large multiplexers
necessary. Silicon Hive cores have no pipeline
control overhead. All pipeline management and
operand forwarding issues are moved to the
compiler, which explicitly schedules all pipeline
stages. This pushes the computational efficiency of
our cores beyond that of traditional processors and
DSPs.
No centralised resources
The use of centralised resources in traditional
processors and DSPs, like a single register file fully-
connected to all function units in the architecture,
again makes the work of the compiler a lot easier.
However, this has highly detrimental effects to the
cost and efficiency of the processor due to the
massive operand networks implied. These
architectures cannot scale. Silicon Hive processors
use distributed resources, with focus on local
interconnect. This implies very little operand network

overheads. When a direct interconnect line is not
available between two resources, Silicon Hive’s
spatial compiler spatially schedules the
communication with a minimal number of local hops.
Silicon efficiency
How can Silicon Hive cores achieve a silicon
footprint smaller than the equivalent ASIC solution?
Higher arithmetic density
Unlike traditional processors and DSPs, Silicon Hive
cores have no hardware dedicated to pipeline
management and operand forwarding logic. Instead,
these tasks are statically performed by the spatial
compiler. In addition, because all data-path
resources in a Silicon Hive core are distributed, the
complexity of the operand networks is much
reduced. This way, most silicon in a Silicon Hive
core is dedicated to actually crunching data. This
substantially increases their silicon efficiency when
compared to traditional processors or DSPs.
Hardware re-use
The feature of our reconfigurable cores that allow
them to often surpass the silicon efficiency of ASICs
is data-path time-sharing. The same functional units,
registers, and interconnect networks that are used to
compute a certain function at a certain point in time,
are then re-used to compute an entirely different
function moments later. This hardware re-use, unlike
in an ASIC, is automatically accomplished by the
spatial compiler. Silicon Hive has made and
delivered reconfigurable cores that beat an
equivalent ASIC in silicon footprint, even when only
one single application is used as the basis for the
comparison.
Key technology differentiators
In this section, we elaborate upon the key
characteristics of Silicon Hive’s approach that
distinguish us from other players in the field of
reconfigurable computing.
Robust building blocks
Advanced, new computing technologies and
paradigms carry the promise of tremendous value.
Higher performances can be achieved, enabling new
and exciting applications, and opening new market
opportunities. However, this value is often offset by
the unreliability of immature technologies, yet to be
pipe-cleaned by the realities of commercial SoC
design and manufacturing.
Unlike many of its competitors, Silicon Hive’s
reconfigurable computing technology is based on
building blocks that have been steadily used and
improved in a commercial environment for several
years. The architecture template of Silicon Hive’s
cores is fundamentally simple and robust, leveraging
on pragmatic, well-understood concepts derived
from fields like traditional VLIW processors and
compilers. Our synthesisable IP cores will often
5  Philips Electronics N.V. 2003
Technology Primer
require the least amount of attention from chip
designers during SoC integration and validation.
Cost-effective, customized solutions
Another distinguishing characteristic of Silicon Hive’s
solutions is their domain-specific nature. Many
reconfigurable or reprogrammable processors in the
market today are catch-all solutions, made for
general-purpose use. As a consequence, the
architectures carry considerable overhead in cost
and efficiency for any specific application domain.
Because of its internal design methodology, which
allows for the generation of new cores and compilers
within days, Silicon Hive can tune its processors to
the needs of particular application domains and/or
customers. This enhances the ease and speed with
which a customer can integrate and use our solution,
and dramatically reduces the silicon overheads
implied. Making cost-effective solutions for very cost-
sensitive consumer markets is an inherited part of
our culture and history within Philips.
High-level programmability
Unlike FPGAs and most other reconfigurable
processors available today, Silicon Hive’s cores are
built with high-level programmability in mind. In fact,
our internal design methodology enforces that each
of our cores be programmable-by-construction. The
cores are supported by the revolutionary spatial
compiler, which automatically extracts the intrinsic
application parallelism from a sequential ANSI C
specification. There is no need for hardware
expertise to program our cores. Silicon Hive itself
employs application developers with a pure software
background to build its application libraries.
The best of FPGAs and DSPs
Data-intensive circuits mapped spatially across an
FPGA have a flow-through computational model that
enables very high throughput. However, the control
of these circuits has typically to be crafted as
complex state machines in an HDL, and is difficult to
validate. On the other hand, DSPs are more
sequential in nature, and more limited in throughput.
However, state machines can be easily implemented
on them as sequential software, often generated by
a compiler.
Silicon Hive cores operate in two modes. The first
is a flow-through mode, wherein the configuration
remains fixed and data ripples through the
architecture as it is clocked. In a second mode, the
same core operates as a normal VLIW DSP
processor, executing one instruction per cycle and
running arbitrary control code like conditional
branches. In both modes, the code is automatically
generated by the spatial compiler. The compiler also
automatically makes the choice of mode for different
code segments. This way, our cores can switch
seamlessly from a mode wherein they operate in a
way analogous to an FPGA, to another wherein they
behave just like a classical VLIW DSP. Sounds
 Technology Primer

complex? You would be surprised how simple and

robust it actually is.

Conclusions
A key enabler to truly programmable and cost-
effective SoCs are reconfigurable accelerators that
can replace currently-used ASIC co-processors with
a comparable computational efficiency (MOPS/W)
and lower silicon overhead. Silicon Hive currently
provides two types of reconfigurable accelerators
that address these market needs. The key
differentiators of our approach are: the robustness
and reliability of our technology, our ability to
customise our solutions to specific customer needs,
the high-level programmability of our cores (ANSI
C), and the fact that they can operate either as
standard DSPs or coarse-grained FPGAs.

6  Philips Electronics N.V. 2003