2015 IEEE 23rd Annual International Symposium on Field-Programmable Custom Computing Machines
Fast and Flexible Conversion of Geohash Codes to and from Latitude/Longitude
Coordinates
Roger Moussalli, Mudhakar Srivatsa, Sameh Asaad
IBM T.J. Watson Research Center
Yorktown Heights, USA
{rmoussal, msrivats, asaad}@us.ibm.com
AbstractInsights extracted from spatial queries in geo-
database systems introduce signicant opportunities for busi-
ness intelligence. However, geodatabases are unable to keep
up with the required performance due to the massive (and
sky-rocketing) amounts of data generated from embedded
location-enabled devices. In this paper, we focus on geographic
information systems that make use of geohash; specically, we
tackle the kernel of converting geohash codes to and from
longitude/latitude pairs. We present the rst hardware imple-
mentation of a geohash conversion engine operating at wire
speed. The presented geohash converter is further enhanced
with runtime exibility with respect to characteristics of the
data it can process; furthermore, the architecture allows the
user to compromise on performance when limited by hardware
resources (design time exibility). Experimental results of the
geohash conversion engine on a Xilinx XC7K325T FPGA show
>13X (end-to-end) speedup compared to optimized industry-
grade software running on 16 CPU hardware threads.
Keywords-geospatial analysis; spatial databases; data con-
version; geohash; FPGA; recongurable architectures; logic
design; accelerator architectures; parallel architectures
I. I NTRODUCTION
The ubiquitous availability of location sensing devices
embedded in smartphones, cars, taxis, and other devices,
combined with the ability to collect data at scale, enables the
ne grained monitoring and modeling of human movement,
both at the individual level and at the group level. Using
trajectory data harvested by GPS, RFID and mobile devices,
complex pattern queries can be posed against objects moving
in both time and space. Answering these queries introduces
opportunities for business intelligence, where prediction
regarding future patterns can be used to solve challenging
problems such as trafc congestion prediction, crime pattern
analysis and prediction, epidemic spread characterization
and alerting, insurance pricing, and targeted advertising. This
work focuses on the spatial aspect of spatiotemporal queries.
One of the most signicant challenges posed by pro-
cessing spatial queries is the sheer amount of available
spatial data; the volume of such data is increasing at an
unprecedented rate, especially thanks to the widespread
use of GPS-enabled smart-phones. In this context, high-
performance techniques are needed to process spatial queries
in a reasonable amount of time.
Geohash is a hierarchical geocoding system that is often
used for spatial indexing. Geohash presents several ad-
vantages over the traditional latitude/longitude geographic
coordinate system, such as efcient indexing, support for
978-1-4799-9969-9/15 $31.00 2015 IEEE
DOI 10.1109/FCCM.2015.18
hierarchical regions, arbitrary precision, and simple proxim-
ity estimation. However, geohashes do not replace lat./long.
coordinates, primarily due to the format of disseminated
data, as well as the dependency of several spatial algorithms
on lat./long coordinates.
This work tackles the (bit-serial) conversion of geohash
codes to/from lat./long. coordinate pairs, a frequent problem
in geohash-based spatial querying frameworks. Handling
geohash codes can be computationally demanding, and en-
tails bit-granular operations, a class of computations where
general purpose processors are not known to shine.
We present a novel and parallel hardware bi-directional
geohash conversion engine, converting geohash codes at
wire speed (no stalls), at the constant throughput rate of
one geohash code per hardware cycle. The novel geohash
converter is enhanced through the incorporation of runtime
exibility, where the length of the geohash codes can
be varying, whilst minimizing misspent input/output band-
width. Furthermore, if lower performance can be tolerated,
the geohash conversion engine can be made to consume
fewer hardware resources. The proposed hardware converter
is shown to outperform optimized industry-grade software,
demonstrating end-to-end throughput of 100 million conver-
sions per second, while occupying 30% of a Xilinx Kintex
7 XC7K325T, a mid- to small-sized FPGA.
The contributions of this work can be summarized as
follows:
The rst hardware geohash converter engine (to the
best of our knowledge), exploiting hardware pipelining
techniques to maximize conversion throughput.
A user-controlled exible compute-based bi-directional
converter architecture that operates on any size geo-
hashes (with architected max), whilst minimizing
wasted bandwidth.
A memory-bound lookup-based converter architecture
for converting geohash codes to lat./long. pairs.
An extensive design space exploration studying the
resulting resource utilization and end-to-end throughput
of the hardware converter on a Xilinx XC7K325T
FPGA.
A performance study comparing state-of-the-art CPU-
based conversion to the proposed novel hardware con-
version engine.
The rest of the paper is organized as follows: the geohash
hierarchical geocoding system is reviewed in Section II.
The proposed hardware geohash conversion engine is then
179

(a) (b)
Figure 1. (a) Intuition behind the geohash coordinate system, where
space is hierarchically divided into grid-shaped buckets. A string denotes a
rectangular region (bounding box) in the space. The point of interest (red
dot) can be represented by either of 241, 24 or 2 (using the depicted
illustrative region naming scheme), depending on the required precision. (b)
A sample binary geohash code (representing the red dot in (a)), where the
bits respective to the longitude and latitude space divisions are interleaved
(read from left to right).
detailed in Section III. The performance of the FPGA-based
geohash conversion engine is evaluated in Section IV. Prior
art is outlined in Section V, while conclusions are presented
in Section VI.
II. G EOHASH C ODING OVERVIEW
In this section, an overview of the geohash system is pro-
vided, followed by a description of the conversion process
to and from latitude/longitude.
A. Geohash Intuition
Geohash is a geographic coordinate system that hierar-
chically divides space into grid-shaped buckets (see Figure
1(a)). A geohash code, represented as a string, denotes
a rectangle (bounding box) on the earth. It provides a
spatial hierarchy with arbitrary precision: the precision can
be reduced (i.e. represent a bigger rectangle) by removing
characters from the end of the string. In other words,
the longer the geohash code is, the smaller the bounding
box represented by the code is. For example, the point
of interest in Figure 1(a) (red dot) can be represented by
either of 241, 24 or 2 (using the depicted illustrative
region naming scheme), depending on the required precision
(tolerated error).
Another property of geohash is that two locations with a
long common geohash prex are close each other. Similarly,
nearby locations usually share a similar prex. However, it
is not always guaranteed that two close locations share a
long common prex (when they are located near the border
of two bounding boxes).
B. Algorithm for Converting Geohash Codes to and from
Latitude/Longitude
Concretely, a geohash code can be represented as a binary
string, where the bits respective to the longitude and latitude
space divisions are interleaved (see Figure 1(b)).
1) Converting From Lat./Long. to Geohash Code: The
longitude space is bounded by the initial interval {-180, 0,
+180} being the min, mid, and max. If the longitude of
the point of interest is greater than the mid of the interval
(i.e. if the point resides in the upper subinterval), then a
180
geohash bit of 1 is produced, and the new interval becomes
{mid, mid+max
2 , max}. On the other hand, if the longitude
of the point of interest is smaller or equal to the mid of
the interval, then a geohash bit of 0 is produced, and the
new interval becomes {min, min+mid 2 , mid}. This process
is repeated up to the desired precision (number of geohash
bits), in a bit-serial fashion. The same method is applied
to the latitude, where the initial interval is {-90, 0, +90}.
Finally, the longitude and latitude bits are interleaved in the
geohash code. Figure 1(b) lists the actual binary geohash
code of the red dot depicted in Figure 1(a).
2) Converting From Geohash Code to Lat./Long.: Given
a set of lat./long. bits, the respective intervals are updated
using the same serial process described above, with no
geohash bits generated at each step; instead, one geohash bit
is consumed at each step. Each input geohash bit is examined
to update the interval at hand, starting from the initial {-90,
0, +90} and {-180, 0, +180} for lat./long. respectively. The
resulting lat./long. values are the respective mid values of
the nal lat./long. intervals.
III. H IGH P ERFORMANCE H ARDWARE G EOHASH C ODEC
In this section, an in-depth description of the proposed
hardware geohash codec is provided, starting from the basic
serial unit for conversion, scaling up to a parallel codec. A
mechanism for lookup-based (in contrast to compute-based)
conversion is further detailed.
A. Basic Conversion Block
We dene a single step in the conversion process as
either of:
The act of producing one geohash bit, when converting
from latitude (or longitude) to geohash code.
The act of updating the latitude (or longitude) value
(i.e. interval mid) by processing one geohash bit, when
converting from geohash code to latitude (or longi-
tude) .
As described in Section II-B, conversion consists of
iterating over the single step as many times as dictated by
the required precision (number of input/output geohash code
bits).
Figure 2 depicts the logic circuit implementing a single
step, being designed with simplicity in mind, where the input
interface matches the output interface. Data ows from top
to bottom, as the input values are (potentially) updated and
passed to the output.
The logic circuit is also exible, as it provides conversion
in either direction, using the mode bit: mode 0 indicates
conversion from geohash code to lat. (or long.), whereas
mode 1 enables conversion from a lat. (or long.) value to
a geohash code bit. In the remainder of this paper, modes
0 and 1 will also be referred to as geo-to-ll and ll-to-geo,
respectively.
The input interface of the logic block consists of the
following signals:
Num bits remaining: the number of bits remaining
to be processed (produced or consumed based on the
Figure 2. Basic conversion block for carrying out a single step: producing one geohash bit when converting from latitude (or longitude), or updating the
latitude (or longitude) value (i.e. interval mid) by processing one geohash bit when converting from geohash code to latitude (or longitude).
direction/mode). The use of this eld will be made
clearer when deploying the logic block in a wider
context (see Section III-B). If a value of 0 is specied
at the input, then no change is applied to any of the
input signals (see red dashed lines in Figure 2).
Mask: when converting from lat. (or long.) to geohash
code (i.e. mode = 1), the mask is used to update the
appropriate geohash code bit (the latter being a multi-
bit signal). As geohash codes are read from left to right
(Figure 1(a)), the mask is shifted right by 1 when a
conversion step takes place. The initial value of the
mask is 1000. . . 0.
Geohash code: when operating in mode 0 (geo-to-ll),
only the most signicant geohash code bit is used to
update the input interval. The geohash code is also
shifted left by 1 to omit the processed bit. When
operating in mode 1 (ll-to-geo), only the one bit of the
geohash code indicated by the input mask is updated.
The value of the updated bit is 1 when the lat. (or long.)
value falls in the upper subinterval, and is otherwise 0
(see Section II-B for more detail).
Lat. (or long.) value: this is the value that is being
converted to (the respective lat./long. portion of) a
geohash code. This signal is only used in mode 1 (ll-to-
geo) when locating the value within the two portions of
the input interval. The value of this signal is unchanged
at the output.
Mode: as described earlier, this signal sets the conver-
sion direction, where 0 indicates geo-to-ll, and 1 indi-
cates ll-to-geo. The value of this signal is unchanged
at the output.
Interval {min, mid, max}: when operating in mode
0 (geo-to-ll), the interval is updated based on the
most signicant geohash bit, whereas in mode 1 (ll-to-
geo), the interval is updated based on the comparison
between the lat. (or long.) value and the input intervals
mid.
181
Figure 3. A geohash conversion engine that parallelizes the processing
of the lat. and long. portions of a geohash code, while also parallelizing
conversion across independent geohash codes. Loopback can be used when
the number of deployed stages does not match the maximum geohash code
bit size; here, processing a geohash code may require several passes through
the pipeline.
Some implementation notes: a full-edged divider is not
deployed in hardware, as the division by the constant 2 can
be achieved with a simple subtract by 1 to the exponent or
a mantissa shift in the case of oating point. Also, pipelin-
ing is applied within the conversion step, for performance
purposes. Details are omitted for simplicity.
B. Parallel Conversion Through Pipelining
Converting an N-bit geohash code (from or to lat./long.)
requires N passes through the single step described in Sec-
tion III-A. Parallelism can be achieved at the level of con-
verting a single geohash code by simultaneously processing
the latitude and longitude portions; this entails deploying two
single step function blocks. Further parallelism in conversion
can be attained when converting several geohash codes in
parallel, through additional replication of the single step
function block.
Figure 3 illustrates a geohash conversion engine that
processes the lat./long. portions of a geohash code in paral-
lel, while providing parallelism across independent geohash
codes. Powered by the exibility of the single step conver-
sion block, the input and output streams can consist of both
lat./long. values and geohash codes. Metadata would indicate
the conversion mode, as well as the number of bits to process
(i.e. geohash precision). In the case of geo-to-ll conversion,
bits of the input geohash code are de-interleaved and passed
to the latitude and longitude pipelines respectively. Similarly,
in the case of ll-to-geo conversion, the geohash codes at
the respective output interfaces of the latitude and longitude
pipelines are interleaved before being pushed to the output
stream.
In order to increase efciency in transferring data to the
geohash conversion engine, the input and output controllers
support batch transfers, where a batch header species char-
acteristics (metadata) of the data following it. Information
enclosed in the header includes (1) the batch size (number
of conversions to be performed), (2) the conversion mode
(geo-to-ll, ll-to-geo), (3) the number of bits to process per
conversion, and (4) the size of the geohash on the wire,
i.e. during transfer to/from the converter (this eld will be
described below).
A geohash converter engine has the following design-time
architectural attributes:
Max geohash size: this eld affects the size of the
geohash code passed across single step blocks (Section
III-A), as well as the size of the mask and num bits re-
maining signals. The max geohash size is an architected
maximum geohash code that can be processed (in either
mode). Hence, an N-bit geohash converter pipeline can
support geohashes of size N or any smaller size.
Number of deployed stages: this eld refers to the total
number of single step blocks deployed. If the number
of stages is smaller than the max geohash size, then a
loopback connection should be made from the last stage
back to the rst (see Figure 3). The number of stages
determines the number of passes through the pipeline
for a given conversion to complete, hence affecting
performance. When limited by hardware resources, the
converter designer may decide to deploy fewer stages
rather than matching the max geohash size, if the
performance hit is deemed tolerable.
The supported transfer-side geohash sizes: given an
architected max geohash size N, any geohash of smaller
size can be processed through the converter. However,
when transferring geohashes of size G to and from
the converter pipeline (where G is specied in the
metadata using the num bits remaining eld, Section
III-A), there are two available options: (1) transfer each
geohash using N bits; this option wastes N G bits
for each conversion performed, hence is bandwidth
wasteful, especially for small geohashes. (2) transfer
geohashes contiguously using G bits each. While (2) is
more bandwidth-efcient, it requires the I/O interface
controllers to implement order of N shifters, which is
generally not feasible. A middle-ground between the
aforementioned 2 options is supporting a subset of N,
such as all powers of two up to N. Here, geohashes
of size G would be transferred on the wire using
geohashes of the next closest power of two, which may
still waste bandwidth, though much less than option
182
Figure 4. Subset of the pre-meditated lookup table respective to the
longitude conversion.
(1). For example, a geohash of size 56 bits can be
transferred using 64 bits, essentially wasting 8 bits,
while a geohash of size 30 bits can be transferred
using 32 bits, essentially wasting 2 bits. Furthermore,
only log2 (N ) shifters are deployed. In our implemented
converter pipelines, geohashes transferred are of size
any power of two less than or equal to the max geohash
size.
Once the above three attributes are set, the geohash con-
verter pipeline can be developed. We implemented a (C++)
utility to generate the HDL of the converter pipeline, using
certain parameter inputs. These include the max geohash
size, the number of deployed stages, the supported transfer-
side geohash sizes, the bit-width of the I/O interfaces, as
well as other lower-level options such as extra buffering to
meet timing.
C. Lookup-Based Conversion
In this section a method is presented to perform the
geohash code to lat./long. conversion using a lookup into
a table of conversions pre-computed ofine. This approach
is in contrast to the online compute method described earlier.
Note that converting from lat./long. to a geohash code using
lookup is not feasible, except for the caching of common
values. The lookup method is practical when faced with
limited hardware resources for compute and compromising
on performance is not an option.
Figure 4 encapsulates a subset of the pre-computed lookup
table with respect to the longitude conversion. Given a longi-
tude geohash code of length L, the address for the conversion
is computed as: longitude geohash code + of f set, where
L1
the offset is 0 when L is 1, otherwise of f set = i=1 2i .
The offset need not be computed at runtime, rather it can
be hard-wired in the address computation logic for different
values of L (L is generally kept small to limit memory size).
The lookup conversion method can be combined with the
compute method in order to eliminate some hardware stages,
as depicted by Figure 5. For generality, geohash codes of

Figure 5. Combining the lookup method with the compute method.
Geohash codes of length 2N bits as drawn, alongside two pre-computed
geo-to-ll lookup tables that convert at most X bits each (one for each of the
latitude and longitude conversions). If N is less than X, then the conversion
can be achieved fully by lookup. Otherwise, X bits are rst converted by
lookup, and the remaining N-X bits are converted by compute, using the
output of the lookup table as a starting interval.
length 2N bits as drawn, alongside two pre-computed geo-
to-ll lookup tables that convert at most X bits each (one
for each of the latitude and longitude conversions). The
remainder of this discussion applies to either of the latitude
or longitude portions of a geohash code. If N is less than
X, then the conversion can be achieved fully by lookup (no
need to compute). Otherwise, X bits are rst converted by
lookup, providing an output interval. Then, the remaining
N-X bits are converted by compute, using the output of the
lookup table as a starting interval. Note that loopback can
be applied from the last to rst compute stages (omitted for
simplicity in Figure 5).
Implementation results regarding the lookup method are
not offered in Section IV, as the end-to-end performance
of the lookup method is the same as that of the compute-
based conversion method, and the memory requirements of
the lookup method can be trivially derived. Furthermore,
a thorough design space exploration regarding resource
utilization is provided for the compute method, which helps
determine whether the lookup method should be used given
specic platform constraints.
IV. E XPERIMENTS AND A NALYSIS
This section presents an extensive experimental evaluation
of the proposed geohash conversion engine.
183
A. Experimental Framework
1) Hardware Framework: Several versions of the pro-
posed hardware geohash conversion engine were imple-
mented on a Pico M-505 board connected to an Intel Xeon
processor via 8 lanes of PCI-e Gen. 2 [1]. The M-505 board
includes a Xilinx Kintex 7 XC7K325T FPGA [2], a mid-
to small-size FPGA by todays standards. Xilinx Vivado
2014.2 is used for synthesis and implementation, with de-
fault settings. The PCIe hardware interface and software
drivers are provided as part of the Pico framework. The
hardware engines communicate with the I/O PCIe interfaces
through one stream each way, with dual-clock BRAM FIFOs
in between the converter logic and the PCI-e interfaces. The
RAM on the FPGA board does not reside in the same virtual
address space as the CPU RAM, and data is streamed from
the CPU RAM to the FPGA. Since the proposed solution
does not require memory ofoading, RAM on the FPGA
board is not used. All performance numbers are reported
end-to-end, including streaming the data from the host CPU
RAM to the FPGA and back to the host CPU RAM.
2) Software Framework: We compare our hardware con-
verter engine to the software converter engine developed in
[3]. The highly optimized software converter is distributed
as part of the IBM Streams [4] and SPSS [5] products, as
a component of the spatiotemporal toolkit. While we did
not gain access to the source code, the authors provided
us with performance measurements. Software experiments
were run on a single socket 8-core x2 Hyper-Threads Intel
Xeon Processor running at 2.5GHz, with 20MB L3 cache
and 32GB RAM.
3) Datasets Description: Synthetic datasets were gen-
erated for varying geohash sizes, namely geo 8, geo 16,
geo 32, geo 64 and geo 128. Each geohash code le is
associated with a lat./long. le represented with double
precision oating point. Note that for a given geohash code
size, modifying the geohash codes typically has no effect
on the performance of either of the software and hardware
converters.
B. FPGA Resource Utilization
We rst perform a design space exploration regarding the
resource utilization of the proposed converter. To that end,
several 128-bit converters were developed, while varying the
number of deployed stages (single step blocks) from 8 to
128. Each of these converters can process geohash codes
of any size up to 128 bits (with varying performance), and
run at 250MHz. Figure 6 summarizes the various resources
consumed by all converters. Generally, resource utilization
increases linearly with the number of hardware stages.
Furthermore, the converters are LUT-dominated, and the
largest (128-stage) converter consumes slightly less than
50% of available hard-wired DSPs (3 per stage for the
double precision adder), as well as 71% of available LUTs.
The 64-stage converter is relatively light-weight and oc-
cupies around 33% of the FPGA; it is able to process 64-bit
geohashes through a single pass. Note that 64-bit geohashes
are most common as they achieve cm precision on the
surface of the earth, and higher precision is rarely required.

Figure 6. Various resources consumed by several 128-bit converters. The
number of deployed stages is varied. Note that all converters can process
any geohash size up to 128 bits (with varying performance).
C. Hardware Converter Performance Evaluation
End-to-end (CPU RAM to FPGA and back to CPU RAM)
performance is measured by processing batches of data (of
varying sizes). A batch either consists of geohash codes,
or lat./long. pairs. The reported metric is throughput as
measured by the number of sustained (millions of) con-
versions per second. All experiments in Figure 7 were run
on a single hardware converter (single FPGA image), with
no compromises on (end-to-end and core converter) perfor-
mance for any of the test cases. This approach showcases
the exibility of the proposed converter, a critical asset as
the performance hit incurred by FPGA reconguration time
cannot be tolerated.
Figures 7(a) and 7(b) show the throughput achieved by the
hardware converter (running at 250MHz) in modes geo-to-
ll and ll-to-geo, respectively. As expected, performance for
small batches is very low, due to PCI-e transfer overhead.
As the batch size increases, the performance exhibits an
exponential increase, followed by a slow linear increase and
eventual saturation.
The performance of the converter core on the FPGA is
one geohash code per hardware cycle, regardless of the
geohash code size (and the conversion mode). End-to-end
conversion will, however, vary due to PCIe side-effects. As
shown in Figure 7(b), the sustained end-to-end conversion
rate is higher for smaller geohash sizes which incur less
trafc on the PCI-e bus. Furthermore, while the performance
with respect to 128-bit geohashes does not vary depending
on the mode (geo-to-ll and ll-to-geo), performance is higher
in the ll-to-geo mode for all other geohash sizes. This is
likely due to the Pico rmware, and occurs as a side effect
of the converter consuming input data more rapidly in the
ll-to-geo mode (recall that a lat./long. pair is represented in
128 bits). Generally, performance is in the tens of millions
of conversions per second, and up to 160 MConversions/s
for 8-bit geohashes.
We show in Figure 8 the performance impact of deploying
fewer stages in hardware, using 128-bit converters (running
at 250MHz) and a batch of 100M conversions for 64-
bit geohashes. The red line represents the deterministic
throughput of the isolated converter core on the FPGA,
184
Figure 8. Performance impact of deploying fewer stages in hardware.
Results are shown for 128-bit converters (running at 250MHz) and a
batch of 100M conversions of 64-bit geohashes. The red line represents
the deterministic throughput of the isolated converter core on the FPGA,
without taking into consideration the PCI-e transfers. In the case of less
than 64 stages, several passes are required through the deployed stages for
each conversion.
without taking into consideration the PCI-e transfers. Recall
that in the case of less than 64 stages, several passes are
required through the deployed stages for each conversion.
Initially, the end-to-end performance is limited by the
converter throughput (4 and 8 stages). However, the per-
formance of the 32-stage and 64-stage converters is com-
parable, and limited by the available PCI-e bandwidth.
Hence, a 32-stage converter can be deployed in place of
the full 64 stages, with minimal impact on performance, but
considerable savings in resources (16% vs 33%, see Figure
6). Furthermore, note that the end-to-end performance of
the converter can be increased (more than doubled) simply
by providing higher PCI-e bandwidth (Gen.3 and/or more
lanes), with no changes to the developed converter core.
D. Hardware Converter vs. Single-Threaded Software
In this section, the performance of the proposed hardware
converter is compared to that of a single-threaded version of
the optimized software converter. Note that the remainder of
this study makes use of a single hardware converter (single
FPGA image), being a 128-bit 128-stage converter running
at 250MHz.
Figures 9(a) and 9(c) show the speedup of the hardware
converter versus the single-threaded software converter, for
conversions modes geo-to-ll and ll-to-geo respectively.
Some notes on the performance of the software converter
(data omitted for brevity): (1) performance does not vary
greatly across batch sizes, as there is no data transfer
overhead to pay; that is with the exception of batch size
10, where the overall performance is lower than for other
batches, since the conversion of the small batch is affected
by software environment overhead. (2) unlike the hardware
converter, the performance of the software converter is lin-
early affected by the geohash code bit size; processing a 32-
bit geohash code requires twice the time needed to process a
16-bit geohash code. (3) similar to the hardware converter,
the performance of the software converter is higher when
converting from lat./long. to geohash codes.
The hardware converter generally performs better than
its software counterpart. This improved performance arises
mainly because the hardware converter performs bit-level
 (a) (b)

Figure 7. Throughput achieved by a 128-bit 128-stage hardware converter (running at 250MHz) with respective modes (a) geo-to-ll and (b) ll-to-geo.

operations very efciently (de-interleaving and reconstruct-

ing the geohash code), and also because it includes double
precision oating point units operating in parallel in a very
deep pipeline. While the hardware converter provides higher
throughput when converting 8-bit geohashes than with 128-
bit geohashes, speedup is higher in the case of the latter
(see (2) above). When reaching steady-state, the hardware
converter achieves up to 250X and 170X speedup for 128-
bit geohashes (geo-to-ll and ll-to-geo respectively), as well
as 160X and 120X speedup for 64-bit geohashes. (a) (b)
Figures 9(b) and 9(d) provide a zoomed in view of Figures
9(a) and 9(c) respectively, for batches of size 10, 100 and
1K. Slowdown is represented below the red (horizontal) line,
where speedup < 1. The red line denotes the threshold at
which hardware acceleration should be used. We can see
that generally, for any geohash size, batches larger than 600
should be sent to the hardware converter; when considering
large geohash codes (64 and 128), batches of size 100 (down
to 30) can be accelerated. Also, note that speedup increases
sharply above the red line, and the benets of hardware
acceleration will be directly visible. (c) (d)

E. Hardware Converter vs. Multi-Threaded Software: a Figure 9. Speedup of the hardware converter versus the single-threaded
software converter, for conversions modes (a) geo-to-ll and (c) ll-to-geo.
Socket-to-Socket Comparison Figures (b) and (d) provide a zoomed in view of Figure (a) and (c)
By assigning separate subsets of a batch to different respectively, for batches of size 10, 100 and 1K. Slowdown is represented
below the red (horizontal) line, where speedup < 1.
threads, software conversion can be accelerated (data-level
parallelism). The next set of experiments we describe show-
cases the speedup of the hardware decoder against a multi-
threaded version of the software decoder. We limit the CPU
to a single socket for a fair (CPU)socket-to-(FPGA)socket
comparison. The available CPU socket comprises of 8 cores
with 2-way Hyper-Threading, a total of 16 hardware threads.
Figure 10 depicts the speedup of the hardware converter
against the software converter, while doubling the number
of software threads. Geohashes of size 64-bits are used with
batches containing 100 Million conversions. As expected,
the comparative speedup is halved as the number of threads
is doubled, up to the number of available cores (8). When Figure 10. Speedup of the hardware converter against the software
Hyper-Threading is used (at 16 threads), we see a 30% converter, while doubling the number of software threads. Geohashes of
reduction in speedup instead of the previous 50%. Increasing size 64-bits are used with batches containing 100 Million conversions.
the number of software threads beyond the number of
hardware threads results in a slight deterioration of software
performance. In summary, the hardware converter achieves 16.1X (geo-to-ll) and 13X (ll-to-geo) speedup versus the

185
best run of the software converter on the CPU socket.
As noted in Section IV-C, the speedup shown here can
be potentially more than doubled simply by attaching the
hardware converter to a higher bandwidth PCI-e platform
(no modications to the converter core required).
V. P RIOR A RT
The geohash geocode system [6] has been introduced
fairly recently (2008) and is witnessing a rapidly increas-
ing adoption. Several database management systems and
geographic information systems make use of geohash for
indexing and efcient querying. These include MongoDB
[7], MySQL [8], IBM Streams and SPSS [3][4][5], as well
as Apache Accumulo (through third-party research) [9].
MongoDB uses geohash for indexing where conversion is
a frequent problem, as input queries process spatial data in
a lat./long. format. The work in [3] proposes a lightweight
scalable spatial index based on geohash, and extends their
approach for graph data structures.
There exists an extensive body of work pertaining to
the FPGA acceleration of certain spatial queries (a small
subset is referenced here). Acceleration of point-in-polygon
algorithms is demonstrated in [10][11][12], while speeding
up k-Nearest Neighbors queries is tackled in [13][14].
The works in [15] [16][17] describe the hardware accel-
eration of spatio-temporal analytics, where queries in the
form of regular-expressions are posed on moving objects.
The spatial history of the moving objects is represented
as regions. Region information is derived from lat./long.
coordinates through methods such as point-in-polygon.
To the best of our knowledge, this paper is the rst
to describe a hardware architecture for the conversion of
geohash codes to/from lat./long. coordinates.
VI. C ONCLUSIONS
We present, to the best of our knowledge, the rst
hardware implementation of a geohash conversion engine
operating at wire speed. The proposed geohash converter
is enhanced with runtime exibility with respect to char-
acteristics of the data it can process (no restrictions on
geohash sizes, bi-directional conversion, etc). Moreover, the
architecture allows the user to compromise on performance
when limited by hardware resources (design time exibility).
A thorough experimental evaluation of the geohash con-
version engine on a Xilinx XC7K325 FPGA shows >13X
(end-to-end) speedup compared to optimized industry-grade
software running on 16 CPU hardware threads. We show
that higher (more than double) speedup can be attained
with no changes to the converter engine, using higher PCI-e
bandwidth (Gen. 3 and/or more lanes).
Future work will focus on the acceleration of more
complex spatial queries in the geohash domain, using the
proposed converter as a constituent.
R EFERENCES
[1] M-505-K325T Embedded, http://picocompu-
ting.com/products/embedded-modules/m-505-k325t-
embedded-2/.
186
[2] KINTEX-7 FPGAS, http://www.xilinx.com.
[3] K. Lee, R. K. Ganti, M. Srivatsa, and L. Liu, Efcient Spatial
Query Processing for Big Data, SIGSPATIAL, vol. 7, no. 11,
pp. 412, 2014.
[4] IBM InfoSphere Streams, http://www-
03.ibm.com/software/products/en/infosphere-streams.
[5] IBM SPSS: Predictive Analysis Software and Solutions,
http://www-01.ibm.com/software/analytics/spss/.
[6] Geohash, http://www.geohash.org.
[7] MongoDB Manual 2.6: Geospatial Indexes and Queries,
http://docs.mongodb.org/manual/core/geospatial-indexes/.
[8] MySQL 5.7 Reference Manual: Spatial Geohash Functions,
http://dev.mysql.com/doc/refman/5.7/en/spatial-geohash-
functions.html.
[9] A. Fox, C. Eichelberger, J. Hughes, and S. Lyon, Spatio-
Temporal Indexing in Non-Relational Distributed Databases,
in Big Data, 2013 IEEE International Conference on. IEEE,
2013, pp. 291299.
[10] J. Fender and J. Rose, A High-Speed Ray Tracing En-
gine Built on a Field-Programmable System, in Field-
Programmable Technology (FPT), 2003. Proceedings. 2003
IEEE International Conference on. IEEE, 2003, pp. 188
195.
[11] J. Schmittler, S. Woop, D. Wagner, W. J. Paul, and
P. Slusallek, Realtime Ray Tracing of Dynamic Scenes
on an FPGA Chip, in Proceedings of the ACM SIG-
GRAPH/EUROGRAPHICS conference on Graphics hard-
ware. ACM, 2004, pp. 95106.
[12] M. Woulfe, M. MANZKE, and J. L. DINGLIANA, Hard-
ware Accelerated Broad Phase Collision Detection for Real-
time Simulations, 2007.
[13] H. Hussain, K. Benkrid, C. Hong, and H. Seker, An adaptive
FPGA Implementation of Multi-Core K-Nearest Neighbour
Ensemble Classier Using Dynamic Partial Reconguration,
in Field Programmable Logic and Applications (FPL), 2012
22nd International Conference on. IEEE, 2012, pp. 627630.
[14] E. S. Manolakos and I. Stamoulias, Flexible IP Cores for the
k-NN Classication Problem and Their FPGA Implementa-
tion, in Parallel & Distributed Processing, Workshops and
Phd Forum (IPDPSW), 2010 IEEE International Symposium
on. IEEE, 2010, pp. 14.
[15] L. Woods, J. Teubner, and G. Alonso, Complex Event
Detection at Wire Speed With FPGAs, Proceedings of the
VLDB Endowment, vol. 3, no. 1-2, pp. 660669, 2010.
[16] R. Moussalli, M. R. Vieira, W. Najjar, and V. J. Tsotras,
Stream-Mode FPGA Acceleration of Complex Pattern Tra-
jectory Querying, in Advances in Spatial and Temporal
Databases. Springer, 2013, pp. 201222.
[17] R. Moussalli, I. Absalyamov, M. R. Vieira, W. Najjar, and
V. J. Tsotras, High Performance FPGA and GPU Complex
Pattern Matching Over Spatio-Temporal Streams, GeoInfor-
matica, pp. 130, 2014.