Hardware Acceleration of Identifying Barcodes in Multiplexed Nanopore Sequencing
Round 1
Reviewer 1 Report
You have compared your results with different barcode lengths. Can you compare your results with other similar methods?
Author Response
Please see the attachment.
Author Response File: 
Author Response.pdf
Reviewer 2 Report
A comparison of the author's approach to other hardware (FPGA) implementations of the barcode identification algorithm would be interesting (if any exist).
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Reviewer 3 Report
In this paper, the authors present a hardware accelerator for barcode identification. The manuscript has some good points but has many serious deficiencies. I strongly suggest the following be made if this paper is to be published.
1) @L31 "It will fail to meet the high throughput requirements". The authors have to give metrics of that requirement. This is not a real-time problem (like video decoding, which has a 30FPS requirement). I cannot see the failure in decoding because it is a not real-time process.
2) Figure 1 presents the identification scheme, but the processing flow is not clear. For example, there is no START or END and some lines go right some lines go left. This is difficult to comprehend.
3) The authors should discuss better what is the input (e.g. a file with multiple strings?) and what is the output ( another file?). Not everyone knows DNA sequencing and identification, especially in this journal.
4) @L72. 'corrupted sequencing'. The authors should discuss what corrupts the sequence and in reality how often this is corrupted.
5) The authors do not give a strong motivation why we need this. Does corruption happen often? Is it a major problem? Is current sequencing unable to handle this? A lack of strong motivation is evident in the paper.
6) Section 2.2 The authors present some equations, but first, they should give the overall picture and then analyze each (from the general to the specific).
7) Again in section 3 the authors give the architecture, but they do not give the full picture. Figure 2 presents the accelerator but it has inputs like p r and c which are not described here in detail. Also, is a register at the output required? Where is the clock signal? Any other control signal?
8) Is this architecture only specific for the VIRTEX? Does it require something specific? Can it be used for other FPGAs? Again lack of details.
9) @Section 4.1 The verification process by trying the same noisy channel on hardware and software, is not sufficient. How many values were tested?
Can a formal verification be done?
10) @Section 4.2 The hardware implementation is not sufficient. For example, how the design was described? In VHDL by hand or by a tool? what Software version was used? How many files? The authors should give all the necessary information if someone wants to repeat the experiments.
11) @L307. "quickly exhaust the FPGA resources". In Table 1 we see that for 31nt the slices used are only 21%. How did the authors reach this conclusion?
12) The authors did not give any information about the software identification, even though they are used both for verification and comparison. Does it utilize OpenMP and parallelization? who wrote it? At what level is the parallelization performed? If the code was written hastily then it will not be optimized.
13) there are no results to compare this work with other authors, even though this is an important problem.
14) The algorithm is not well described and there seems to be a lack of cohesion. After reading this, I am still, not able to reproduce this in VHDL. The authors should also give more architectural figures of how this is used. For example, how the input was transferred to the board? using PCI Express? How the time was measured then? Including I/O? If the authors want a fair comparison, they should also include Input / Output time. If they have the data on the block RAM of FPGA and perform computation then this is not fair compared to a software implementation.
Generally, the paper lacks many important details. Let us not forget, that publishing is done so other researchers can learn from our research and progress the science. If the paper lacks every major detail, then this is not possible.
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Round 2
Reviewer 3 Report
In this revised version the manuscript has been improved, but serious ommissions are still present.
1) In the manuscript no details of the software simulations are disclosed. CPU/RAM/software and this is a serial execution, that includes I/O are mandatory, while at the same time the hardware implementation does not include I/O because the samples are already on the Block Ram. This is an unfair comparison. On the FPGA slide, you have the hardware parallelization of multiple concurrent slices, while on the software side you have only one thread that also performs I/O and all the computations. This is not a fair comparison and Figure 9 gives wrong impressions.
2) Comparisons are required with other authors to publish in good quality Journals. The authors must find a related work to compare. For example I google it and found the first couple results:
Aaron Pomerantz, Nicolás Peñafiel, Alejandro Arteaga, Lucas Bustamante, Frank Pichardo, Luis A Coloma, César L Barrio-Amorós, David Salazar-Valenzuela, Stefan Prost, Real-time DNA barcoding in a rainforest using nanopore sequencing: opportunities for rapid biodiversity assessments and local capacity building, GigaScience, Volume 7, Issue 4, April 2018, giy033, https://doi.org/10.1093/gigascience/giy033
or
Reddy, S., Hung, LH., Sala-Torra, O. et al. A graphical, interactive and GPU-enabled workflow to process long-read sequencing data. BMC Genomics 22, 626 (2021). https://doi.org/10.1186/s12864-021-07927-1
Author Response
Please see the attachment
Author Response File: Author Response.pdf
Round 3
Reviewer 3 Report
After 2 revisions, the paper has reached a good quality and can be published. The authors were very cooperative and presented a good manuscript.
