UPP: Universal Predicate Pushdown to Smart Storage

Persona 1: The Guardian (Adversarial Skeptic)

Review Form

Summary

This paper introduces Universal Predicate Pushdown (UPP), a framework for offloading database filter operations to an in-storage FPGA. The core idea is to compile user-defined functions (UDFs) and filter predicates, written in high-level languages like C++, into WebAssembly (WASM). This WASM module is then translated into a hardware circuit description (Verilog) that is programmed onto an FPGA inside a "smart" storage device. By compiling arbitrary predicates to hardware, the authors claim to provide a general-purpose in-storage processing solution, reporting significant speedups over a CPU-based baseline.

Strengths

The paper correctly identifies a well-known and important performance bottleneck.

• Valid Problem Identification: The central premise is sound: for data-intensive analytics, the cost of moving data from storage to the host CPU is a first-order bottleneck (Section 1, Page 1). The goal of pushing computation (in this case, predicate evaluation) to the data is a valid and important research direction.

Weaknesses

The paper's conclusions are built upon a fundamentally flawed and inequitable baseline, a questionable compilation pipeline, and a complete failure to address the most critical challenges of real-world in-storage processing.

• Fundamentally Unsound Baseline Comparison: The headline performance claims are invalid and grossly misleading. The paper compares a custom, application-specific FPGA accelerator against a general-purpose CPU running a database (e.g., MonetDB) (Figure 6, Page 9). An FPGA will almost always outperform a CPU on a highly-parallelizable, data-streaming task like filtering. This is a classic apples-to-oranges fallacy. A rigorous and fair comparison would require evaluating UPP against a state-of-the-art, multi-threaded CPU implementation that uses SIMD instructions, or against a GPU-based filtering solution. The reported speedups are an artifact of an unfair comparison, not a demonstrated architectural superiority.
• Compilation and Reconfiguration Overheads are Ignored: The entire UPP flow depends on a complex, multi-stage compilation process: C++ to WASM, WASM to Verilog, and finally, synthesis and place-and-route to generate an FPGA bitstream (Figure 2, Page 4). This end-to-end compilation, especially the hardware synthesis step, is an extremely slow process that can take minutes or even hours for non-trivial predicates. The paper completely ignores this overhead in its performance analysis. The claim of supporting "ad-hoc queries" is absurd when the reconfiguration time for each new query predicate would be orders of magnitude larger than the data transfer time it is trying to save.
• "Universality" is a Gross Overstatement: The paper claims to support "universal" predicate pushdown, but the evaluation is limited to a handful of simple filter predicates from the TPC-H benchmark (Table 1, Page 8). There is no evidence that the framework can handle the full complexity of modern SQL, including complex UDFs with state, non-trivial control flow, or dependencies on external libraries. The WASM-to-Verilog translator is likely to be extremely brittle and support only a small, simple subset of the WASM specification. The claim of universality is unsubstantiated.
• Practical System-Level Issues are Ignored: The paper provides a cartoonish, high-level view of a smart storage device and ignores numerous real-world engineering challenges. How is the FPGA managed, programmed, and secured? How does the UPP framework handle complex data types, variable-length strings, and different file formats (e.g., Parquet, ORC)? How are errors and exceptions from the hardware-accelerated UDF propagated back to the host database? The work presents a toy system, not a practical one.

Questions to Address In Rebuttal

1. To provide a fair comparison, please evaluate UPP against a state-of-the-art, multi-threaded, SIMD-optimized CPU implementation and a GPU-based implementation of the same TPC-H filter predicates.
2. Please report the end-to-end time for a new, ad-hoc query, including the full C++-to-WASM-to-bitstream compilation and FPGA reconfiguration time. How does this "query compilation time" compare to the query execution time?
3. To substantiate your claim of "universality," please demonstrate that your framework can successfully compile and accelerate a complex, stateful User-Defined Function from a real-world analytics workload, not just a simple, stateless TPC-H predicate.
4. Please provide a detailed description of the runtime system required to manage the UPP FPGA. How does the host OS discover, program, and manage the lifecycle of the hardware-accelerated predicates, and how are runtime errors handled?

Persona 2: The Synthesizer (Contextual Analyst)

Review Form

Summary

This paper introduces Universal Predicate Pushdown (UPP), a novel, end-to-end framework for enabling general-purpose, in-storage processing. The core contribution is a complete, vertically-integrated toolchain that allows developers to write arbitrary filter predicates in a high-level language (like C++), compiles them to a universal and portable intermediate representation (WebAssembly), and then automatically synthesizes a custom hardware accelerator for that predicate on an FPGA embedded in a smart storage device. By providing a seamless path from a high-level software abstraction to a low-level hardware implementation, UPP aims to make computational storage truly programmable and accessible, breaking the bottleneck of the host-storage interconnect for a wide range of database and analytics workloads.

Strengths

This paper is a significant and forward-looking contribution that elegantly synthesizes ideas from database systems, compiler theory, and reconfigurable hardware to create a powerful and practical vision for the future of computational storage.

• A Pragmatic and General Approach to Programmable Storage: The most significant contribution of this work is its creation of a complete and plausible end-to-end toolchain for programmable storage. While the idea of computational storage has been around for decades, its adoption has been crippled by the lack of a viable programming model. UPP provides a brilliant solution to this problem by leveraging WebAssembly (WASM) as a universal, hardware-agnostic intermediate representation (Section 3, Page 4). This is a massive conceptual leap forward. It connects the world of smart storage to the vast and mature ecosystem of modern software compilers (e.g., LLVM), which is a critical step for making computational storage truly usable by everyday developers. 🚀
• Elegant Synthesis of the Full System Stack: UPP is a beautiful example of a true full-stack co-design. It doesn't just propose a piece of hardware; it presents a complete, coherent vision that includes the programmer-facing language, the compiler and IR, the hardware synthesis flow, and the runtime system. This holistic approach, which considers the problem from the application all the way down to the FPGA bitstream, is a hallmark of mature and impactful systems research.
• Enabling the Future of Data-Centric Computing: The work is brilliantly motivated by the "data gravity" problem—the fact that it is becoming easier to move compute to the data than to move massive datasets to the compute. UPP provides a concrete and compelling architectural blueprint for this data-centric future. By making storage devices active, programmable participants in the computation, UPP helps to blur the lines between storage and compute, which is a key trend in the evolution of modern data centers and high-performance computing systems.

Weaknesses

While the core vision is powerful, the paper could be strengthened by broadening its focus to the long-term challenges of deploying and managing such a flexible system.

• The Reconfiguration Bottleneck: The paper focuses on the performance of the final, accelerated query but spends less time discussing the significant latency of the FPGA compilation and reconfiguration process. For a truly interactive, ad-hoc query environment, this "time-to-first-result" is critical. A discussion of how this compilation overhead could be mitigated—perhaps through a library of pre-compiled common functions or a JIT-like compilation flow—would provide a more complete picture of a production-ready system.
• Security and Resource Management: A fully programmable storage device introduces significant new security and resource management challenges. How do you prevent a malicious or buggy user-defined predicate from compromising the integrity of the storage device? How do you manage and schedule the limited FPGA resources in a multi-tenant environment where many different users are trying to offload predicates? A discussion of the required OS and runtime support for managing this new class of device would be a valuable addition.
• Beyond Filtering: The paper focuses on the canonical computational storage workload: predicate pushdown (filtering). However, a programmable engine like UPP could potentially accelerate other important in-storage tasks, such as data transformation, compression, or even simple aggregations. An exploration of how the UPP framework could be extended to support a broader class of in-situ data processing would be a fascinating direction for future work.

Questions to Address In Rebuttal

1. Your use of WASM as a hardware-agnostic IR is a brilliant idea. Looking forward, how do you see this approach evolving? Could a future version of UPP use a JIT (Just-In-Time) compilation flow to dramatically reduce the reconfiguration latency for new queries?
2. A programmable storage device is a powerful tool, but also a potential security risk. What new hardware and software mechanisms do you think are needed to create a secure, multi-tenant execution environment on the UPP FPGA? 🤔
3. How could the UPP framework be extended to support more complex, "near-data" computations beyond simple filtering, such as data aggregation or format transcoding, all within the storage device?
4. What do you see as the biggest non-technical barrier to the widespread adoption of a programmable storage framework like UPP? Is it the need for new programming models, the lack of standardized APIs, or something else entirely?

Persona 3: The Innovator (Novelty Specialist)

Summary

This paper introduces Universal Predicate Pushdown (UPP), an end-to-end framework for in-storage processing. The core novel claim is the synthesis of a complete, language-agnostic toolchain that automatically translates high-level filter predicates into custom hardware accelerators on a smart storage device. This is achieved through a novel two-stage compilation process: 1) The use of WebAssembly (WASM) as a universal, hardware-agnostic intermediate representation (IR) for the predicate logic (Section 3, Page 4), a first for the computational storage domain. 2) A new WASM-to-Verilog compiler that automatically synthesizes a hardware datapath from the WASM representation (Section 4, Page 6). The creation of this seamless, fully-automated software-to-hardware pipeline for a storage device is presented as the primary novel contribution.

Strengths

From a novelty standpoint, this paper is a significant contribution because it proposes a fundamentally new, practical, and general-purpose programming model for a problem that has previously been addressed only with specific, fixed-function, or difficult-to-program solutions.

• A Novel Programming Abstraction for Computational Storage: The most significant "delta" in this work is its use of WebAssembly as the hardware/software interface. While computational storage is a known concept, prior work has required developers to use low-level, non-portable hardware description languages (like Verilog or HLS C++) to program the device. UPP is the first work to propose a high-level, language-agnostic, and portable programming model for a smart storage device. This is a massive leap forward in usability and is a truly novel approach that could finally make programmable storage practical. 🧠
• A New Compiler-for-Hardware-Synthesis Flow: The creation of a compiler that directly translates a software IR (WASM) into a hardware description (Verilog) for this domain is a novel and significant engineering contribution. While HLS tools exist, they are complex and require specialized programming expertise. The UPP compiler, which automatically generates a datapath from a restricted but universal software format, represents a new and more accessible path from software to custom hardware.
• A New Level of Generality: The synthesis of these ideas creates a new level of generality. Prior work focused on accelerating specific, hard-coded predicates. UPP is the first framework to propose a credible path to accelerating arbitrary, user-defined predicates, thanks to its novel compilation flow. The novelty is in the leap from a fixed-function device to a truly universal and programmable one.

Weaknesses

While the overall framework is highly novel, it is important to contextualize its novelty. The work cleverly synthesizes many ideas from the compiler and hardware communities, but the underlying technologies are adaptations of existing concepts.

• Component Concepts are Inspired by Prior Art: The novelty is primarily in the synthesis and the application to a new domain.
  • WASM: WebAssembly is a well-established, standardized IR from the software world. The novelty is being the first to recognize its potential as an IR for hardware synthesis in the storage domain.
  • High-Level Synthesis (HLS): The WASM-to-Verilog compiler is, in essence, a form of HLS. The novelty is in the choice of the source language (WASM) and the specific, data-flow architecture it targets, not in the general idea of compiling a high-level language to hardware.
  • FPGA-based Accelerators: Using FPGAs as reconfigurable accelerators in storage devices is a known concept.
• The "First" Claim is Specific: The claim to be the "first" universal framework is a strong one, but it is specific. It does not invent the idea of in-storage processing or HLS, but it is the first to combine them in this specific, powerful, and accessible way.

Questions to Address In Rebuttal

1. The core of your novelty is the use of WASM as an IR for hardware synthesis. Can you contrast your approach with prior work in the HLS community that has used other software-based IRs (like LLVM-IR) as a starting point for hardware generation? What is the key "delta" that makes WASM a fundamentally better or more novel choice for this specific domain?
2. The WASM-to-Verilog compiler is a key enabling technology. What is the most non-obvious or surprising challenge you faced when trying to map the semantics of a software-oriented ISA like WASM onto the parallel, spatial semantics of a hardware datapath?
3. If a competitor were to propose an alternative in-storage solution based on embedding a small, general-purpose RISC-V core that could interpret the WASM code directly (a "JIT-to-FPGA" vs. a "JIT-to-CPU" approach), what is the fundamental, enduring novelty of your ahead-of-time, full-synthesis approach that would make it superior?
4. What is the most complex or unexpected software predicate that your novel framework can compile and accelerate, which would have been difficult or impossible to implement using prior, more rigid HLS-based or fixed-function approaches to computational storage?