Reviews for paper FPGAs for Data Processing: Current State, original submission.

Overall Rating: Minor Revision

Cover Letter

Dear Dr. Teubner,

Reviewers have now commented on your paper. You will see that they are suggesting minor revisions of your manuscript. I encourage you to consider these comments and revise your manuscript accordingly.

For your guidance, the reviewers' comments are appended below. Please submit a list of changes or a rebuttal against each point which is being raised when you submit the revised manuscript.

Please submit the final version via the Editorial Manager. We expect to receive your revision until 31 Jan 2017.

To submit a revision, go to itit.edmgr.com and log in as an Author. You will see a menu item called Submission Needing Revision. You will find your submission record there.


Yours sincerely

Prof. Dr. Paul Molitor
Guest Editor
Information Technology

Handling Editor

Reviewers' comments:
Dear Authors - please consider the comments and provide a revised version. Please also consider the comment provided by one of the reviewers:

Only the selection of topics and their resp. depth confuses me a bit.
The title says "data processing",
but the two chapters that make up the core of the paper
(after introduction to FPGAs and challenges in general)
are only XML Filtering and Abstractions.
There is no doubt that they are important,
but they do not cover the whole field of data processing.

... should the title adopted with respect to this comment?

Regards,
Wolfgang

Reviewer 1

Reviewer #1: A well-written paper by a top expert in the field.
Lots of information, coverage of many topics on just 6 pages.
Definitely worth being published.

So only some suggestions to improve it even further:

Introduction to FPGA technology in chapter 2 is very elementary,
but that is fine for the community addressed.
To be consistent, SRAM should also be introduced,
in particular "SRAM cell".
In Figure 1, the interconnect lines are not visually connected with the logic blocks.
What is the "D" in the flip-flop of Figure 2? Data?

page 3, paragraph "Communication":
"Increased parallelism naturally goes with communication between the parallel units" -
Really? Not always! SIMD.
Maybe you have some special kind of parallelism in mind.

Chapter 4 comes a bit as a surprise.
Why this subject?
Given the rather general level of discussion before,
it is not easy to see why this very special area (of limited relevance)
deserves such attention.
A few more words of motivation would be helpful.
The sections actually address much broader topics:
General data paths in 4.1 and database query processing in 4.2.
Maybe the title of the chapter should be changed to more general terms?

The "minutes or hours of compilation time" are only mentioned in section 4.2.
Shouldn't it be treated as one of the challenges in chapter 3?

Chapter 5 introduces shifter lists as an abstraction.
If you have not seen them before, it is a bit hard to get the idea from the description.
The example of the skyline problem might help, but it is not elaborated.
In particular, the following questions remain:
Do the working-set shares in the nodes overlap or are they disjoint?
How do you find the proper number of nodes and the right partitioning of the working set?
Does the shift function consist of a sending and a receiving part?
eval can update the working set, so can shift - what about conflicting updates?
Of course, all of this has long been solved in a consistent way,
but one would like to read about it.
If space is a problem, Figure 10 can be dropped, since reference to the original article is already given.

Typos:
2nd paragr. of ch. 1, second last line: double "to"
last paragr. of section 2.1, line 13: no comma after "left"

Ref. [18]: First names not abbreviated.
Ref. [21]: "Fpga-based" -> FPGA-based

Reviewer 2

Reviewer #2: The article presents a very good and comprehensible overview on FPGA technology, underlying core principles, basic building blocks, and a clear motivation why the use of these co-processors might be worthwhile. It clearly outlines challenges that arise when algorithms are implemented for this platform.
With skeleton automata and shifter lists, useful abstraction layers are presented for modeling algorithms and data structures for FPGA hardware. Based on latter, some higher-level applications are implemented and convincing performance evaluations are presented.
The paper will be particularly useful for engineers that are new to the domain. It perfectly fits the scope of the journal issue. Therefore, I strongly recommend to accept it.

Some suggestions that might improve the article further - if space allows this:
- Maybe a good reference to FPGA basics would be useful in the background section to have a pointer for getting started with the fundamentals of the technology.
- The abstraction challenge is clearly handled by skeleton automata. Also tradeoffs were discussed that need to be made. However, from the text in this paper it is not clear how these automata facilitate the parallelism challenge. Maybe a sentence or two (just for the key ideas) on that would be helpful to render the paper even more self-contained.
- Communication and abstraction is also clearly covered by the shifter lists as generalized pattern from the handshake join algorithm. To some extend, I can also see parallelism here, mainly pipeline parallelism that is leveraged when items flow through the chain of nodes/cores. Maybe this could be emphasized in the text, also whether there are other sources of parallelism that can be exploited by these patterns. Latter would help readers to recognize patterns from their own application domain to identify whether using FPGAs might fit their problems, too.
- The connection between skeleton automata and shifter lists is not mentioned explicitly in the text. From Fig. 8, I would assume that skeleton automata are used to model the eval() phase. Is this right? If so, a sentence about that in 5.1.2 would be helpful.