Accelerating Transposed Convolutions on FPGA-based Edge Devices

Jos\'e Cano; Jude Haris

REVIEW 4 major objections 4 minor 23 references

Accelerating Transposed Convolutions on FPGA-based Edge Devices

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read An FPGA accelerator that combines matrix multiplication with on-the-fly col2IM mapping runs transposed convolutions 1.9x faster on average than an optimized edge CPU, and up to 4.2x on generative-model layers.

desk verdict A real, implemented TCONV accelerator with a genuine architectural idea, but a load-bearing arithmetic error in Table III makes the headline '2x better than prior work' claim unsupported as printed. read the letter →

arxiv 2507.07683 v1 pith:MVMW2X3C submitted 2025-07-10 cs.AR cs.DCcs.LG

Jude Haris , José Cano This is my paper · ORCID

classification cs.ARcs.DCcs.LG

keywords transposedconvolutionFPGAacceleratorgenerativeAIedgeinferenceinput-orientedmappingcol2IMmatrixmultiplicationGANacceleration

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Generative AI models upscale images through transposed convolutions (TCONV), which are slow on resource-constrained edge devices. The authors claim that a new hardware-software accelerator, MM2IM, can execute TCONV layers efficiently by combining matrix multiplication with a column-to-image mapping (col2IM) and by generating compute and output maps on the fly, so that useless cropped outputs are never computed and partial sums are accumulated directly into final outputs. If true, this would give edge devices a practical way to run generative models faster: an average 1.9x speedup over an optimized dual-thread CPU baseline across 261 TCONV configurations, up to 4.2x on common generative-model layers, and better throughput per DSP than comparable edge-FPGA accelerators. The same design is also reported to speed up full GAN models by up to 3x while using less energy.

What carries the argument

The load-bearing mechanism is the MM2IM Mapper, a hardware module that generates the compute map (cmap) and output map (omap) on the fly for each MatMul output row, parameterized by row id and problem dimensions. cmap marks which filter columns are actually needed in a row, skipping cropped and ineffectual outputs, while omap maps each partial dot product to its final output index. The processing modules consume these maps: cmap-check logic skips useless dot products inside the processing-element array, and an output muxer accumulates each partial sum directly into the correct output-buffer location. This removes mapping-data transfers and lets the accelerator process a TCONV layer tile-by-tile without ever materializing the padded MatMul output matrix.

What would settle it

Run the 261-configuration benchmark on the same FPGA board against a well-tuned dual-thread vectorized CPU baseline and recompile the prior accelerators on the same board at the same precision; then check whether the average speedup reaches 1.9x and the GOPs/DSP ratio reaches 2x. Separately, recomputing energy from Table IV's own J/pic numbers gives a maximum reduction of about 1.8x, not the claimed 2.4x, so a direct power measurement with a consistent baseline would settle which figure is right.

Watch

Extended reading notes

Core claim

The paper's central claim is that input-oriented mapping for transposed convolution can be turned from an inefficient, storage-heavy operation into an efficient, output-stationary one. The MM2IM architecture merges MatMul with col2IM and adds a hardware mapper that computes, for each row of the MatMul output, a compute map (cmap) telling which dot products are actually needed and an output map (omap) telling where each partial sum belongs. Processing modules skip the cmap-marked ineffectual computations, which are the ones that would be cropped away by col2IM, and use omap to accumulate partial sums directly in the final output buffers, eliminating separate partial-sum storage and the overlapping-sum pass. A tiled dataflow keeps filters and outputs stationary, and a performance model guided the design. The paper evaluates the result on 261 synthetic TCONV configurations, reporting an average 1.9x speedup against a dual-thread CPU baseline, on layers from DCGAN and related generative models, reporting up to 4.2x speedup, and on full DCGAN and pix2pix inference, reporting up to 3x speedup in the TCONV portions.

Load-bearing premise

The headline speedups and efficiency comparisons assume the CPU baseline and the other accelerators are measured under fair, comparable conditions—same threading, same precision, and same workload—so the gains are real rather than artifacts of a weaker reference point.

Editorial extensions

If this is right

TCONV layers can be processed without ever materializing the full MatMul output matrix; the output-streaming design keeps only final output rows on chip.
The on-chip mapper eliminates the need to send compute and output maps from main memory; the paper's performance model says those transfers would otherwise account for up to 35% of end-to-end latency.
Larger input-channel dimensions give the largest gains because the whole channel depth is processed in one pass without off-chip access.
Smaller strides leave more cropped outputs to skip, which is where the speedup is largest; stride-2 problems run on average 54% slower relative to baseline than stride-1 problems.
Full-model speedups on GANs are bounded by the fraction of TCONV work in the model, so the reported end-to-end speedups are lower than the TCONV-only speedups.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The on-the-fly cmap and omap idea is not tied to this particular FPGA; the same maps could be precomputed at compile time for CPU or GPU kernels, letting any edge device skip cropped outputs and accumulate in place.
Because the speedup increases with input-channel count and kernel size, the design is likely to matter most for large generative generators; the paper's FCN layer shows roughly 1.0x speedup, suggesting very small TCONV layers may not amortize accelerator overhead.
A cross-platform comparison that re-synthesized prior accelerators at the same precision on the same board would test how much of the reported 2x GOPs/DSP edge comes from the mapping technique rather than from board or bit-width differences.
The energy claim could be sharpened by reporting the power baseline explicitly, since the table's listed J/pic values show a smaller maximum reduction than the abstract's stated 2.4x figure.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Jude and José have built an actual accelerator for transposed convolutions on a PYNQ-Z1, and the core architectural idea is solid. The on-the-fly generation of compute and output maps to skip the cropped outputs that standard IOM wastes is a real contribution, and the tiled weight/output-stationary dataflow is a sensible way to keep partial sums on-chip for small FPGAs. The measured 1.9x average speedup over a dual-thread ARM Cortex-A9 Neon baseline across 261 configurations is a real, reproducible result, and the performance model being within 10% of hardware is a plus.

That said, the paper has a serious internal inconsistency that undermines its headline comparison. Table III lists 23.0 GOPS, 49 DSP, and 3.51 GOPS/DSP for Ours. But 23.0/49 = 0.469. The paper gives no formula that turns this into 3.51, and frequency or precision normalization only makes it worse. Since the abstract and conclusion both claim 'at least 2x higher GOPs/DSP than the next best accelerator,' and Table III is the sole evidence, this is load-bearing. Either the DSP number is wrong (perhaps 49 is a percentage or a count of something else) or the GOPS figure is miscomputed. The authors need to correct the table and re-derive the comparison, or drop the claim.

There are also smaller reporting issues. The abstract says '2.4x energy reduction' but Table IV shows at most 1.8x, and the conclusion says 1.7x. The synthetic benchmark says dual-thread CPU baseline while Table II says single-threaded; Table IV has both, so that's probably just inconsistent labeling, but it should be cleaned up. The cross-FPGA comparison to [8] and others inherently mixes precisions and platforms, but the GOPs/DSP metric itself is fair enough; the problem is the arithmetic, not the metric.

The CPU baseline is an old embedded Cortex-A9, so the speedups are relative to a weak baseline, but for an edge-FPGA paper that's acceptable as long as it's stated clearly. The work is a solid engineering contribution with a real hardware implementation, and the mistakes look fixable rather than fundamental.

Who should read this: anyone building FPGA accelerators for generative model layers, especially TCONV-specific designs. It deserves a serious referee, but the authors must fix the table and reconcile the abstract numbers before the comparative claims are acceptable. I'd send it out, but with the expectation of a major revision.

Referee Report

4 major / 4 minor

Summary. The paper presents MM2IM, a hardware-software co-designed accelerator for transposed convolutions (TCONV) on resource-constrained edge FPGAs. The design combines matrix multiplication with a col2im-style output mapping, uses on-the-fly compute/output maps to skip ineffectual computations, and employs a tiled dataflow to reduce off-chip memory traffic. The authors integrate MM2IM into TFLite via the SECDA-TFLite toolkit and evaluate it on a PYNQ-Z1 board. The reported headline results are an average 1.9x speedup over a dual-thread ARM Neon CPU baseline across 261 TCONV configurations, up to 4.2x speedup on individual generative-model TCONV layers, up to 3x end-to-end speedup and 2.4x energy reduction on DCGAN and pix2pix, and at least 2x higher GOPs/DSP compared to previous edge-FPGA TCONV accelerators.

Significance. If the claims are accurate, this is a useful contribution to edge-FPGA acceleration of TCONV layers. The strengths are concrete: the accelerator is actually implemented and measured on an FPGA; the synthetic evaluation spans 261 configurations; end-to-end GAN inference is evaluated; and a performance model is validated against measured hardware within 10%. The paper also addresses a real problem (cropped-output ineffectual computations in IOM-based TCONV) and provides a plausible architectural solution. However, the comparative GOPs/DSP claim and several headline numbers must be corrected before the contribution can be fully assessed.

major comments (4)

[Table III, Section V-D] The Ours row in Table III is arithmetically inconsistent: it lists Perf. (GOPS) = 23.0, DSP Usage = 49, and Perf. (GOPS/DSP) = 3.51, but 23.0/49 = 0.469, not 3.51. The row for [8] is internally consistent (2691/1512 = 1.78), so the discrepancy is not a general column definition. The abstract and conclusion claim 'at least 2x' higher GOPs/DSP over comparable accelerators, and this claim rests entirely on this table. As printed, the table implies MM2IM is below [8] on the stated metric. Please provide corrected measurements or an explicit normalization that reproduces 3.51, or remove the comparative claim.
[Section V-B vs. Table II, Section V-C] The baseline used for speedup is described inconsistently. Section V-B says the synthetic benchmarks use a 'dual-thread CPU 8-bit baseline (with NEON-vector instructions enabled)', while Table II and Section V-C describe the CPU comparison as 'single-threaded execution'. The 1.9x average speedup across 261 configurations and the up-to-4.2x layer speedups therefore appear to mix two different baselines. Please state explicitly which baseline is used for each reported speedup and ensure the text and tables agree.
[Abstract vs. Table IV, Section VII] The abstract states 'achieving up to 3x speedup and 2.4x energy reduction against the CPU baseline', but Table IV shows maximum energy reductions of about 1.8x (DCGAN ACC+CPU 2T: 4.3 J vs 7.9 J) and Section VII correctly says '1.7x energy reduction on average'. The 2.4x figure in Table IV is a latency speedup, not an energy reduction. The abstract should be corrected to avoid presenting a latency number as an energy number.
[Table III, Section V-D] Aside from the arithmetic error, the GOPs/DSP comparison in Table III is not controlled: the rows use different FPGAs, precisions (8-16 bits), and likely different TCONV workloads and layer sizes. The paper states that GOPs/DSP is 'more relevant' than GOPs, but it does not describe the workloads behind each row or any normalization that accounts for precision and problem size. Even with corrected arithmetic, the 'at least 2x' comparative claim needs a clearly specified and fair comparison.

minor comments (4)

[Section III-C] The phrase 'TCONV decoder optimization' appears in the performance-model validation (Section V-F) but is not defined earlier; clarify what this optimization is and how it relates to the MM2IM Mapper.
[Algorithm 2] Algorithm 2 contains typos and inconsistent variable names: 'P M scmap' and 'P M somap' appear to be formatting artifacts, and 'imdex' is used while 'index' is the standard term. Also, the condition for bounds checking could be explained more precisely.
[Figure 6] The synthetic-benchmark speedup plot in Figure 6 would be clearer with an explanation of how the configurations are grouped and whether the reported speedups are arithmetic means over each group.
[Table IV] The 'Model Configuration' column in Table IV interleaves CPU-only and ACC+CPU rows, but the row labels such as 'CPU 1T' and 'ACC + CPU 1T' might be misread as both being configurations of the accelerator; consider renaming to 'Baseline CPU 1T' and 'MM2IM + CPU 1T' for clarity.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: MM2IM's speedup and efficiency claims rest on measured hardware execution and a validated performance model; the only self-citations are tooling (SECDA-TFLite/SECDA) and are not load-bearing.

full rationale

The paper's central claims are empirical: an average 1.9x speedup over a dual-thread ARM Neon CPU baseline across 261 TCONV configurations, up to 4.2x on generative-model layers, and a GOPs/DSP comparison against prior FPGA accelerators. These are measured results, not derived from the paper's own definitions. The performance model in Section III-C (Eqs. 3-4) is validated in Section V-F against actual hardware within 10%, and the 35% output-mapping overhead 'prediction' is checked against the implemented MM2IM Mapper within 1% deviation; it is not used to generate the headline speedups. The compute/output maps (Algorithm 2) are generated from the TCONV dimensions and stride, independent of measured performance, so no self-definitional loop is present. The only self-citations are [14] (SECDA-TFLite) and [16] (SECDA methodology), used to describe implementation tooling; these are not invoked to justify the accelerator's performance or to forbid alternative designs. I considered the Table III arithmetic inconsistency (Ours: 23.0 GOPS / 49 DSP = 0.469, not the listed 3.51 GOPS/DSP) and the synthetic-benchmark dual-thread baseline vs. Table II single-thread description; both are correctness/reporting concerns, not circularity, because they do not make any predicted quantity equal to a fitted input or reduce a derivation to its own assumptions. Hence no circular step can be exhibited, and the appropriate score is low.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The central performance claims rest on the IOM formulation, the correctness of the mapping hardware, and the choice of CPU baseline. No new physical entities are introduced; the hardware modules are standard accelerator components. The main free choices are the parallelism parameters X and UF.

free parameters (2)

Number of processing modules X = 8
Hardware parallelism parameter chosen for the PYNQ-Z1 instantiation. Determines filterstep tiling in Algorithm 1 and caps parallelism in the Oc dimension; reported speedups depend on this choice.
Unrolling factor UF = 16
Number of MACs per cycle per Compute Unit; tiles the Ic dimension. Chosen to fit FPGA resources; direct tradeoff between parallelism and resource usage.

assumptions (3)

domain assumption TCONV can be expressed as out = col2im(mm(I, W^T), ...) with the IOM method.
Standard formulation from GNA [9] and MATLAB's col2im [13]; the paper builds on this without re-deriving it. Invoked in Section II-B, Equation 2.
domain assumption The MM2IM Mapper's compute/output maps correctly encode all non-cropped partial outputs for any TCONV configuration, including arbitrary padding and strides.
Algorithm 2 is stated to support 'any shape of TCONV layers', but correctness is only empirically validated by matching CPU output on the tested GAN models, not proven for all parameter combinations.
domain assumption The ARM CPU with NEON instructions is a fair and strong baseline for edge CPU performance.
The speedup ratios depend entirely on this baseline. The paper reports dual-threaded baselines in synthetic experiments (Section V-B) but single-threaded in Table II, so the baseline strength is inconsistently defined.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Accelerating Transposed Convolutions on FPGA-based Edge Devices." pith.science (2026). https://pith.science/paper/MVMW2X3C

@misc{pith2026250707683,
  author       = {Pith},
  title        = {Pith review of: Accelerating Transposed Convolutions on FPGA-based Edge Devices},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MVMW2X3C}},
  note         = {Machine review of arXiv:2507.07683}
}

read the original abstract

Transposed Convolutions (TCONV) enable the up-scaling mechanism within generative Artificial Intelligence (AI) models. However, the predominant Input-Oriented Mapping (IOM) method for implementing TCONV has complex output mapping, overlapping sums, and ineffectual computations. These inefficiencies further exacerbate the performance bottleneck of TCONV and generative models on resource-constrained edge devices. To address this problem, in this paper we propose MM2IM, a hardware-software co-designed accelerator that combines Matrix Multiplication (MatMul) with col2IM to process TCONV layers on resource-constrained edge devices efficiently. Using the SECDA-TFLite design toolkit, we implement MM2IM and evaluate its performance across 261 TCONV problem configurations, achieving an average speedup of 1.9x against a dual-thread ARM Neon optimized CPU baseline. We then evaluate the performance of MM2IM on a range of TCONV layers from well-known generative models achieving up to 4.2x speedup, and compare it against similar resource-constrained TCONV accelerators, outperforming them by at least 2x GOPs/DSP. Finally, we evaluate MM2IM on the DCGAN and pix2pix GAN models, achieving up to 3x speedup and 2.4x energy reduction against the CPU baseline.

Figures

Figures reproduced from arXiv: 2507.07683 by the authors.

**Figure 2.** Example of TCONV with MatMul + col2IM. III. EFFICIENT TRANSPOSED CONVOLUTION A. Optimizing Input-Oriented Mapping To optimize TCONV using the IOM method we first elaborate on its main inefficiencies in detail and then discuss optimizations for better performance on resource-constrained edge devices. 1) IOM Inefficient Computation The baseline IOM method has two inefficiencies: ineffectual computations and the storag… view at source ↗

**Figure 3.** MM2IM Accelerator Architecture. The accelerator is [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (4 more)

**Figure 4.** Figure 4: Processing Module architecture with a detailed view of [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]

**Figure 5.** Figure 5: Computational flow within each PM in terms of MM2IM computations. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

**Figure 6.** Figure 6: MM2IM speedup normalised to CPU execution time [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]

**Figure 7.** Figure 7: Percentage of cropped outputs for the various TCONV [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 21 canonical work pages

[8]

An Energy-Efficient FPGA- Based Deconvolutional Neural Networks Accelerator for Single Image Super-Resolution,

J.-W. Chang, K.-W. Kang, and S.-J. Kang, “An Energy-Efficient FPGA- Based Deconvolutional Neural Networks Accelerator for Single Image Super-Resolution,” IEEE Transactions on Circuits and Systems for Video Technology, pp. 281–295, 2020

work page 2020
[1]

Accelerating the Super-Resolution Convolutional Neural Network,

C. Dong, C. C. Loy, and X. Tang, “Accelerating the Super-Resolution Convolutional Neural Network,” in European Conference on Computer Vision (ECCV), 2016, pp. 391–407

work page 2016
[2]

Perceptual Losses for Real- Time Style Transfer and Super-Resolution,

J. Johnson, A. Alahi, and L. Fei-Fei, “Perceptual Losses for Real- Time Style Transfer and Super-Resolution,” in European Conference on Computer Vision (ECCV) , 2016, pp. 694–711

work page 2016
[3]

Generative Modeling for Small-Data Object Detection,

L. Liu, M. Muelly, J. Deng, T. Pfister, and L.-J. Li, “Generative Modeling for Small-Data Object Detection,” in 2019 IEEE/CVF International Conference on Computer Vision (ICCV) , 2019, pp. 6072–6080

work page 2019
[4]

DLAS: A Conceptual Model for Across-Stack Deep Learning Acceleration,

P. Gibson, J. Cano, E. J. Crowley, A. Storkey, and M. O’Boyle, “DLAS: A Conceptual Model for Across-Stack Deep Learning Acceleration,” in ACM Transactions on Architecture and Code Optimization , 2024

work page 2024
[5]

A survey of FPGA-based accelerators for convolutional neural networks,

S. Mittal, “A survey of FPGA-based accelerators for convolutional neural networks,” vol. 32, no. 4, pp. 1109–1139. [Online]. Available: https://doi.org/10.1007/s00521-018-3761-1

work page doi:10.1007/s00521-018-3761-1
[6]

A Design Methodology for Efficient Implementation of Deconvolutional Neural Networks on an FPGA

X. Zhang, S. Das, O. Neopane, and K. Kreutz-Delgado, “A Design Methodology for Efficient Implementation of Deconvolutional Neural Networks on an FPGA,” in arXiv:1705.02583, 2017

work page Pith review arXiv 2017
[7]

Uni-OPU: An FPGA- Based Uniform Accelerator for Convolutional and Transposed Convo- lutional Networks,

Y . Yu, T. Zhao, M. Wang, K. Wang, and L. He, “Uni-OPU: An FPGA- Based Uniform Accelerator for Convolutional and Transposed Convo- lutional Networks,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems, pp. 1545–1556, 2020

work page 2020

Show all 23 references

[9]

GNA: Reconfigurable and Efficient Architecture for Generative Network Acceleration,

J. Yan, S. Yin, F. Tu, L. Liu, and S. Wei, “GNA: Reconfigurable and Efficient Architecture for Generative Network Acceleration,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, pp. 2519–2529, 2018

2018
[10]

An Intermediate-Centric Dataflow for Transposed Convolution Acceleration on FPGA,

Z. Ma, T. Dai, X. Wei, and G. Luo, “An Intermediate-Centric Dataflow for Transposed Convolution Acceleration on FPGA,” ACM Transactions on Embedded Computing Systems , 2022

2022
[11]

FCN-Engine: Accelerating Deconvolutional Layers in Classic CNN Processors,

D. Xu, K. Tu, Y . Wang, C. Liu, B. He, and H. Li, “FCN-Engine: Accelerating Deconvolutional Layers in Classic CNN Processors,” in 2018 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), 2018, pp. 1–6

2018
[12]

FPGA Design of Transposed Convolutions for Deep Learning Using High-Level Synthesis,

C. Sestito, S. Perri, and R. Stewart, “FPGA Design of Transposed Convolutions for Deep Learning Using High-Level Synthesis,” Journal of Signal Processing Systems , 2023. [Online]. Available: https://doi.org/10.1007/s11265-023-01883-7

2023 doi
[13]

M. Devs. Col2im - Rearrange matrix columns into blocks - MATLAB. [Online]. Available: https://uk.mathworks.com/help/images/ref/col2im. html
[14]

SECDA- TFLite: A toolkit for efficient development of FPGA-based DNN accelerators for edge inference,

J. Haris, P. Gibson, J. Cano, N. Bohm Agostini, and D. Kaeli, “SECDA- TFLite: A toolkit for efficient development of FPGA-based DNN accelerators for edge inference,” Journal of Parallel and Distributed Computing, pp. 140–151, 2023

2023
[15]

Unsupervised Representation Learning with Deep Convolutional Generative Adversarial Networks,

A. Radford, L. Metz, and S. Chintala, “Unsupervised Representation Learning with Deep Convolutional Generative Adversarial Networks,” in 4th International Conference on Learning Representations (ICLR) , 2016

2016
[16]

SECDA: Efficient Hardware/Software Co-Design of FPGA-based DNN Accelera- tors for Edge Inference,

J. Haris, P. Gibson, J. Cano, N. B. Agostini, and D. Kaeli, “SECDA: Efficient Hardware/Software Co-Design of FPGA-based DNN Accelera- tors for Edge Inference,” in 2021 IEEE 33rd International Symposium on Computer Architecture and High Performance Computing (SBAC-PAD), 2021, pp. 33–43

2021
[17]

J. Long, E. Shelhamer, and T. Darrell. Fully Convolutional Networks for Semantic Segmentation. [Online]. Available: http://arxiv.org/abs/ 1411.4038

arXiv
[18]

Optimizing CNN-based Segmentation with Deeply Customized Convolutional and Deconvolutional Architectures on FPGA,

S. Liu, H. Fan, X. Niu, H.-c. Ng, Y . Chu, and W. Luk, “Optimizing CNN-based Segmentation with Deeply Customized Convolutional and Deconvolutional Architectures on FPGA,” ACM Transactions on Recon- figurable Technology and Systems , pp. 1–22, 2018

2018
[19]

Exploring Effi- cient Acceleration Architecture for Winograd-Transformed Transposed Convolution of GANs on FPGAs,

X. Di, H.-G. Yang, Y . Jia, Z. Huang, and N. Mao, “Exploring Effi- cient Acceleration Architecture for Winograd-Transformed Transposed Convolution of GANs on FPGAs,” Electronics, p. 286, 2020

2020
[20]

Image-to-Image Trans- lation with Conditional Adversarial Networks,

P. Isola, J.-Y . Zhu, T. Zhou, and A. A. Efros, “Image-to-Image Trans- lation with Conditional Adversarial Networks,” in arXiv:1611.07004

arXiv
[21]

Towards Design Methodology of Efficient Fast Algorithms for Accelerating Generative Adversarial Networks on FPGAs,

J.-W. Chang, S. Ahn, K.-W. Kang, and S.-J. Kang, “Towards Design Methodology of Efficient Fast Algorithms for Accelerating Generative Adversarial Networks on FPGAs,” in 2020 25th Asia and South Pacific Design Automation Conference (ASP-DAC) , 2020, pp. 283–288

2020
[22]

High-Level Synthesis of Hardware Accelerators for Deconvolution Engines,

C. Sestito, R. Stewart, and S. Perri, “High-Level Synthesis of Hardware Accelerators for Deconvolution Engines,” pp. 1–4
[23]

An Efficient FPGA-Based Dilated and Transposed Convolutional Neural Network Accelerator,

T.-H. Wu, C. Shu, and T.-T. Liu, “An Efficient FPGA-Based Dilated and Transposed Convolutional Neural Network Accelerator,” vol. 71, no. 11, pp. 5178–5186

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [8]

An Energy-Efficient FPGA- Based Deconvolutional Neural Networks Accelerator for Single Image Super-Resolution,

J.-W. Chang, K.-W. Kang, and S.-J. Kang, “An Energy-Efficient FPGA- Based Deconvolutional Neural Networks Accelerator for Single Image Super-Resolution,” IEEE Transactions on Circuits and Systems for Video Technology, pp. 281–295, 2020

work page 2020

[2] [1]

Accelerating the Super-Resolution Convolutional Neural Network,

C. Dong, C. C. Loy, and X. Tang, “Accelerating the Super-Resolution Convolutional Neural Network,” in European Conference on Computer Vision (ECCV), 2016, pp. 391–407

work page 2016

[3] [2]

Perceptual Losses for Real- Time Style Transfer and Super-Resolution,

J. Johnson, A. Alahi, and L. Fei-Fei, “Perceptual Losses for Real- Time Style Transfer and Super-Resolution,” in European Conference on Computer Vision (ECCV) , 2016, pp. 694–711

work page 2016

[4] [3]

Generative Modeling for Small-Data Object Detection,

L. Liu, M. Muelly, J. Deng, T. Pfister, and L.-J. Li, “Generative Modeling for Small-Data Object Detection,” in 2019 IEEE/CVF International Conference on Computer Vision (ICCV) , 2019, pp. 6072–6080

work page 2019

[5] [4]

DLAS: A Conceptual Model for Across-Stack Deep Learning Acceleration,

P. Gibson, J. Cano, E. J. Crowley, A. Storkey, and M. O’Boyle, “DLAS: A Conceptual Model for Across-Stack Deep Learning Acceleration,” in ACM Transactions on Architecture and Code Optimization , 2024

work page 2024

[6] [5]

A survey of FPGA-based accelerators for convolutional neural networks,

S. Mittal, “A survey of FPGA-based accelerators for convolutional neural networks,” vol. 32, no. 4, pp. 1109–1139. [Online]. Available: https://doi.org/10.1007/s00521-018-3761-1

work page doi:10.1007/s00521-018-3761-1

[7] [6]

A Design Methodology for Efficient Implementation of Deconvolutional Neural Networks on an FPGA

X. Zhang, S. Das, O. Neopane, and K. Kreutz-Delgado, “A Design Methodology for Efficient Implementation of Deconvolutional Neural Networks on an FPGA,” in arXiv:1705.02583, 2017

work page Pith review arXiv 2017

[8] [7]

Uni-OPU: An FPGA- Based Uniform Accelerator for Convolutional and Transposed Convo- lutional Networks,

Y . Yu, T. Zhao, M. Wang, K. Wang, and L. He, “Uni-OPU: An FPGA- Based Uniform Accelerator for Convolutional and Transposed Convo- lutional Networks,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems, pp. 1545–1556, 2020

work page 2020