Averon Research — sample report

This thesis will be scrutinized primarily on the validity of the co-design 'loop' and the generalizability of the SECDA methodology across disparate frameworks like TFLite and MLIR. I will focus heavily on whether the reported speedups (e.g., 84x for TCONV) are achieved through genuine architectural innovation or are simply a comparison against sub-optimal software baselines on extremely resource-constrained hardware like the Zynq 7020.

Where To Focus Your Preparation

Examiners most often decide the outcome of a viva on the questions that probe gaps, limitations, and the significance of your contribution — not the background or methodology questions. Based on this thesis, these are the 8 questions most worth rehearsing first. Full guidance for each is further down, under its category.

Understanding Your Thesis

This thesis addresses the 'design gap' in the development of Deep Neural Network (DNN) accelerators for resource-constrained edge FPGAs. You argue that the traditional, siloed approach to hardware and software development is too slow and inefficient for the rapidly evolving DNN landscape. To solve this, you propose the SECDA (SystemC Enabled Co-design of DNN Accelerator) methodology, which utilizes SystemC to enable an iterative, high-level design loop where hardware architecture and host-side driver code are developed in tandem. You demonstrate the versatility of this approach by extending it into specialized toolkits for industry-standard frameworks: SECDA-TFLite for TensorFlow Lite and SECDA-LLM for llama.cpp. Your work moves beyond simple GEMM acceleration to tackle more complex operations, specifically the Transposed Convolution (TCONV) used in Generative Adversarial Networks (GANs), through your MM2IM architecture. Finally, you address the 'last mile' of integration—the host-accelerator communication—by co-developing AXI4MLIR, an extension to the MLIR compiler framework that automates the generation of efficient, architecture-aware driver code. Ultimately, your research demonstrates that by providing a unified methodology from high-level simulation to automated compiler integration, one can achieve significant performance gains (up to 84x speedup for TCONV) on hardware as modest as a Zynq-7020 SoC.

Strengths — And How to Talk About Them

End-to-End System Perspective

Most hardware research focuses solely on the accelerator core (the 'IP'). By including the host CPU, memory mapping, and framework integration (TFLite, llama.cpp), you address the actual bottlenecks of edge inference.

How to articulate this: Emphasize that an accelerator's theoretical peak performance is irrelevant if the software stack cannot feed it data; focus on your contribution to 'system-level' efficiency rather than just 'cycle-accurate' compute.

Integration with Modern Software Ecosystems

The use of TFLite, llama.cpp, and MLIR makes this work immediately relevant to current industry practices. It moves the thesis away from 'academic toy problems' and into real-world utility.

How to articulate this: Highlight the 'delegate' system in Chapter 5. Explain how your methodology allows a developer to drop in an FPGA accelerator without rewriting the entire application.

Novelty in GAN Acceleration (MM2IM)

While CNN acceleration is a crowded field, Transposed Convolution (TCONV) for GANs is less explored. Your 84x speedup against an ARM Neon baseline is a powerful empirical result.

How to articulate this: Point to the complexity of the MM2IM mapper in Chapter 7. Explain how the dataflow specifically addresses the 'zero-padding' inefficiency of traditional TCONV implementations.

Methodological Rigor via SECDA

You don't just present an accelerator; you present a way to *build* accelerators. This 'meta-contribution' is what makes the thesis a doctoral-level work.

How to articulate this: Focus on the 'Design Loop' in Figure 4.1. Be prepared to explain how SystemC simulation specifically reduced your hardware/software debugging time compared to RTL-only flows.

Compiler-Level Contribution (AXI4MLIR)

The collaboration on MLIR shows you understand the future of hardware-software co-design, which is moving toward automated code generation and lowering through dialects.

How to articulate this: Discuss the 'accel[extract from the author’s document removed]s ability to manage data movement better than manual coding.

Weaknesses — And How to Defend Them

Reliance on the Zynq-7020 (Z-7020) Platform

The Z-7020 is a relatively old and resource-constrained device. Critics might argue your findings don't scale to modern Ultrascale+ or Versal FPGAs.

How to defend this: Acknowledge the platform's age but frame it as a deliberate choice for 'extreme' edge scenarios. Argue that if your methodology can find efficiency on a device with only 220 DSPs, it is inherently robust enough for larger platforms.

Co-authorship and Contribution Clarity in AXI4MLIR

Chapter 8 explicitly mentions co-first authorship with Nicolas Bohm Agostini. An examiner will probe to find exactly which parts are *yours*.

How to defend this: Be extremely precise. Refer to the 'Declaration' and the specific section at the start of Chapter 8. Clearly delineate your work on the AXI DMA library and driver generation versus the MLIR lowering transformations.

Absence of Dynamic Power Management Analysis

In Section 1.1.2, you state you do not adjust for DVFS or power management. For a thesis on 'edge' devices, power is as critical as latency.

How to defend this: Explain that the primary goal was architectural efficiency and throughput-per-watt at a fixed frequency. Frame it as a baseline study upon which DVFS and power-gating could be layered as future work.

The 'Manual' nature of MLIR Traits

The AXI4MLIR work still requires the user to define 'traits' for the accelerator. This isn't 'fully automatic' in the sense of a black-box compiler.

How to defend this: Argue that 'user-driven' automation is the current state-of-the-art. Total automation is a 'holy grail' that often yields suboptimal hardware; your approach provides the necessary 'hints' to the compiler to ensure performance.

Baseline Comparison Limitations

In many evaluations, you compare against an ARM Neon CPU. While standard, some might want to see comparisons against other FPGA HLS tools (like Vitis AI) or low-power NPUs.

How to defend this: Explain that the ARM Neon baseline represents the 'status quo' for edge developers using TFLite. Your goal was to prove the 'value-add' of adding an FPGA to that specific existing ecosystem.

Overall Defence Strategy

You should carry yourself as a systems architect, not just a hardware designer. Your strength lies in the 'glue[extract from the author’s document removed]s shared nature.

Examination Questions

Examiner Challenges

1. In your 'Self-Critique' (Section 9.3.3), you mention the lack of power measurements for some experiments. Considering this is a thesis on 'Edge Inference'—where power is often the primary constraint—isn't the absence of power/thermal analysis a significant gap in your evaluation of the MM2IM accelerator?

Challenging a critical omission in an edge-computing context.

How to approach thisDo not be defensive. Acknowledge the limitation. Argue that since the Zynq 7020 is a fixed-envelope device, performance-per-watt is largely driven by speedup (reducing the time the FPGA is active). Provide anecdotal evidence of power consumption from other Zynq-based works to contextualize your 200MHz designs.

2. The MM2IM accelerator achieves speedup partly by using a 'Mapper' to handle the 'col2IM' transformation. However, your Figure 7.5 shows a high percentage of 'cropped outputs.' Why did you choose to perform cropping in hardware rather than simply zero-padding the input in software to avoid irregular memory access patterns?

Challenging a specific architectural decision in Chapter 7.

How to approach thisCompare the memory bandwidth costs. Argue that zero-padding in software increases the data volume transferred over the DMA, whereas hardware cropping allows the accelerator to process the 'raw' shape and only write back valid pixels, thus saving DDR bandwidth.

3. Your AXI4MLIR results (Chapter 8) show speedups of up to 1.65x over manual code. However, many of your baselines are compared against 'ARM Neon-optimized CPU' code. If you had compared against a state-of-the-art NPU or a mobile GPU on the same edge budget, would your FPGA-based accelerators still be competitive?

Challenging the competitive positioning of the work.

How to approach thisDiscuss the 'flexibility[extract from the author’s document removed]non-standard' operations like the TCONV in GANs or the BFP in LLMs, the FPGA's reconfigurability is the only way to achieve acceleration.

4. You mention in Section 1.1.2 that you do not adjust for DVFS (Dynamic Voltage and Frequency Scaling). How would the relative performance of your accelerators change if the ARM host was throttled due to thermal constraints, as is common in real edge devices?

Probing the robustness of results under realistic environmental conditions.

How to approach thisArgue that the FPGA's performance is deterministic (fixed clock), whereas the CPU's is not. Thermal throttling on the ARM core would actually increase the 'speedup' ratio of the accelerator, making the FPGA even more attractive as a stable compute offload.

5. Your SECDA-LLM case study (Chapter 6) focuses on Matrix Multiplication. Since the primary bottleneck in LLM inference on the edge is typically DDR bandwidth (weight loading) rather than computation (MACs), how does your BFP accelerator solve the 'memory wall' problem better than just using a standard CPU with 4-bit weight decompression?

Challenging the efficacy of the LLM acceleration strategy.

How to approach thisFocus on the data format. Explain that BFP allows for smaller bit-widths (3-bit super-blocks) while maintaining higher precision than standard INT4. The FPGA allows for custom bit-level decoding of these formats in the Data Loader (Figure 6.4) which is much slower to do in software on an ARM core.

6. In Table 5.1, you report FPGA resource utilization. For the FC-GEMM design, you use only 33% of the LUTs but 95% of the BRAMs. Why did you not use the remaining LUTs to implement logic-based memory or more parallelism to balance the resource usage?

Critiquing the resource balance and optimization of the designs.

How to approach thisExplain the 'bottleneck' hierarchy. More LUT-based parallelism would require even more BRAM to feed the PEs, and since you were already at 95% BRAM, adding more logic would have likely led to stalling. This highlights the memory-constrained nature of the Z-7020.

7. You used the PYNQ Z1 for hardware evaluation. PYNQ is known to have a significant Python-side overhead. Did you measure the latency of the Python 'overlay' loading and the 'mmio' calls, and did you exclude these from your comparison with C-based ARM baselines?

Ensuring the experimental fairness of the benchmarking process.

How to approach thisClarify that while the PYNQ framework was used for deployment, the timing measurements were taken using high-resolution hardware timers within the C++ driver/delegate code, excluding the Python setup time, to ensure a fair 'apples-to-apples' comparison with the ARM Neon code.

8. Regarding SECDA-TFLite: If a model has 50 layers but your FPGA can only fit one layer's accelerator at a time, the reconfiguration overhead for the FPGA bitstream would be massive. How does your methodology address multi-layer models where layers differ significantly (e.g., CONV vs. Depthwise-CONV)?

Testing the methodology against realistic, multi-operator models.

How to approach thisDiscuss 'multi-purpose[extract from the author’s document removed]unified' accelerator rather than reconfiguring the bitstream mid-inference.

9. In Section 8.3.3, you discuss 'Matrix-Multiplication with flexible sizes.' If the size is truly flexible, how do you manage the AXI DMA's maximum transfer length constraints, which are usually hardware-defined (e.g., 23 bits for the length register)?

Probing the low-level hardware knowledge and driver implementation.

How to approach thisDescribe the 'tiling' and 'chunking[extract from the author’s document removed]s hardware limits.

10. You claim SECDA-LLM is for 'Edge Devices,[extract from the author’s document removed]killer app' or scenario where a 200MHz FPGA is actually the better choice for an LLM?

Pushing on the practical utility and target market of the work.

How to approach thisFocus on 'deterministic latency' and 'low-power persistence.' Argue that in industrial or aerospace edge settings, you cannot use an Apple M3 chip due to power or reliability requirements, and a small FPGA performing BFP-quantized inference provides the best performance-per-watt at that specific power tier (5-10W).

11. Why did you choose to implement the MM2IM Mapper in the Processing Module rather than as a standalone pre-processing IP block (Figure 7.3)?

Investigating architectural modularity decisions.

How to approach thisDiscuss the benefits of fusion. Integrating the mapper into the PM allows for direct 'streaming' of data from the compute units to the output crossbar, avoiding the intermediate write-back to BRAM that a standalone block would require.

12. In your evaluation of TinyBERT (Section 8.3.5), the speedup is only 1.08x. Is this marginal gain enough to justify the complexity of the AXI4MLIR toolchain and the specialized FPGA hardware?

Critiquing the value proposition of the findings.

How to approach thisArgue that TinyBERT was the 'stress test' for the framework. Explain that even a marginal gain in a highly optimized model like TinyBERT proves the framework's ability to extract performance where manual optimization has already peaked.

13. You mention 'Instruction Decoder' in Section 7.3.1. How much area (LUTs/FFs) does this programmable control logic consume compared to a simple fixed-function FSM?

Assessing the 'flexibility vs. area' trade-off.

How to approach thisReference your resource tables. Argue that the 'Micro-ISA' approach consumes negligible resources (<5% of LUTs) but provides the flexibility to handle the 261 different configurations you tested, which a fixed FSM could not do efficiently.

14. In the comparison with state-of-the-art accelerators (Section 4.5.3), you note that SECDA-based designs are 'competitive.' However, you don't mention the 'latency-per-inference.' Is your throughput-focused evaluation masking high tail-latencies?

Probing the choice of evaluation metrics.

How to approach thisDefend the focus on throughput for batch tasks but discuss how SECDA's profiler (Figure 5.4) actually allows for deep-diving into per-layer latency to identify and fix tail-latency bottlenecks during the design loop.

15. The AXI4MLIR chapter highlights 'automatic host code generation.' How does your system handle 'DMA errors' or 'hardware timeouts'? Is the generated code robust enough for production use, or is it strictly for benchmarking?

Evaluating the maturity and robustness of the software contribution.

How to approach thisAcknowledge that current generation focuses on performance and correct-path execution. Suggest that error handling is a 'Future Work' extension (as noted in Chapter 9) but explain the basic status-register polling currently implemented to ensure data integrity.

16. You chose to use 16-bit weights for the initial SECDA case study (Section 4.4). Why not move straight to INT8, which is the industry standard for edge inference?

Questioning the choice of data precision in early experiments.

How to approach thisExplain that 16-bit was a baseline to prove the methodology[extract from the author’s document removed]s flexibility.

17. How does the 'Output Crossbar' in MM2IM (Section 7.3.4) handle the 'race condition' when multiple PEs try to write to the same output pixel simultaneously during the TCONV accumulation?

Testing technical depth on the hardware architecture.

How to approach thisExplain the scheduler logic (Section 7.3.2). The scheduler ensures that the workload is partitioned such that no two PEs are working on the same output overlap at the same time, or that the crossbar includes an 'accumulate-on-write' path to handle overlaps.

18. Your bibliography includes works up to 2024. How has the recent release of 'BitNet' (1-bit LLMs) changed the validity of your SECDA-LLM approach, which focuses on BFP?

Testing awareness of very recent field developments.

How to approach thisArgue that SECDA is an 'enablement' methodology. While the case study used BFP, the SECDA-LLM toolkit could easily be used to design a 1-bit 'BitNet' accelerator, and the design loop would be just as relevant for exploring the 1-bit design space.

19. In Figure 2.10, you illustrate the IM2COL transformation. Since this transformation increases the memory footprint of the input activations, how do you handle the potential 'memory blow-up' on the Zynq 7020's limited 512MB RAM?

Probing memory management strategies for large layers.

How to approach thisReference your 'Tiled' approach (Algorithm 2). You don't perform the whole IM2COL at once; the driver performs it 'on-the-fly' for small tiles that fit into the DMA-space, thus keeping the memory footprint under control.

20. You mention 'Data-coalescing optimization' in Appendix A.1.1. How did you verify that this optimization didn't lead to 'misaligned' memory accesses that cause AXI bus errors?

Probing the correctness of low-level data transfer optimizations.

How to approach thisExplain the constraints in the MLIR pass. The pass is aware of the AXI alignment requirements (e.g., 4-byte or 8-byte boundaries) and ensures that coalescing only occurs within these bounds, or inserts padding where necessary.

21. Why is the ARM NEON code your chosen baseline (Section 7.4)? If you had used the 'ARM Compute Library' (ACL), would your speedup factors have been significantly lower?

Questioning the strength of the software baseline.

How to approach thisJustify the use of the TFLite built-in NEON kernels as the 'standard' deployment path for edge users. Acknowledge ACL's potential but argue that SECDA's goal is to improve upon the most commonly used developer tools.

22. How does the SECDA methodology handle 'Multi-tenancy'—where two different applications want to use the FPGA accelerator at the same time?

Probing the system-level limitations of the framework.

How to approach thisAdmit that the current methodology assumes a single-tenant 'locked' access to the IP. Discuss how the driver/DMA management would need a 'scheduler' or 'context-switching' logic to support multi-tenancy, which is outside the current thesis scope.

23. The 'Profile Visualization Tool[extract from the author’s document removed]instrumented' with extra logic, and if so, what is the resource cost of that instrumentation?

Investigating the transparency and cost of the profiling method.

How to approach thisExplain that for SystemC, it is zero-cost software tracing. For hardware, you use AXI performance monitors or simple timestamp registers in the accelerator, which consume <1% of resources.

24. Your MM2IM mapper handles 'strided' convolutions (Section 7.3.6). Does the mapper logic introduce 'pipeline bubbles' when the stride doesn't align with the PE array width?

Probing the efficiency of the specialized hardware logic.

How to approach thisDiscuss the 'Scheduler' in Section 7.3.2. Explain how it re-orders the input loading to minimize bubbles by ensuring that PEs are fed with non-zero pixels as much as possible, even in strided configurations.

25. You discuss 'Quantization' in Section 2.4.4. Did you explore 'Weight-only' quantization, and how would SECDA's dataflow change if the activations remained as FP16?

Exploring different points in the design space.

How to approach thisExplain that SECDA can handle mixed-precision. You would need to update the Processing Module (PEs) to support FP16 MACs while keeping the weight load path as INT8/INT4. The design loop would allow you to quickly profile the resulting area increase.

26. In the comparison Table 4.1, you mark 'Gemmini' as lacking 'Continuous Evaluation.' However, Gemmini uses a cycle-accurate simulator (Spike). Why do you claim SECDA is superior in this regard?

Challenging the comparative positioning against major frameworks.

How to approach thisArgue that SECDA's integration is 'tighter.[extract from the author’s document removed]s evaluation is often more isolated to the accelerator's standalone performance.

27. Why is the clock frequency of the FPGA limited to 200 MHz throughout the thesis? Did you try to push the Zynq 7020 to 250 or 300 MHz, and what was the 'bottleneck' in your HLS-generated logic?

Investigating the physical limits of the implementation.

How to approach thisIdentify the 'BRAM-to-PE' routing congestion as the primary bottleneck. At 200 MHz, the designs are stable; pushing higher often leads to timing violations in the AXI interconnect or the crossbar logic, which SECDA helped identify.

28. Regarding the 56% reduction in cache references for AXI4MLIR: If the CPU is not doing any computation (since the FPGA is), why do 'cache references' matter for overall system performance?

Questioning the relevance of a specific performance metric.

How to approach thisExplain that in a SoC, the CPU and FPGA share the same memory controller. Reduced cache references/bus traffic from the CPU side reduces contention for the DDR, allowing the FPGA's DMA to achieve higher effective throughput.

29. How did you ensure the 'moral rights' and 'copyright' mentioned in the preamble were respected during your collaboration on AXI4MLIR?

A standard procedural question about ethics and attribution.

How to approach thisRefer to the joint-first-authorship agreement. Explain that the work is used in both theses with full disclosure and that the core intellectual property was developed synchronously and attributed accordingly.

30. If you had to redesign the SECDA methodology from scratch today, what is the one 'feature' you would add to make it more useful for the next generation of 'Transformer-only' hardware?

Testing visionary thinking and self-reflection.

How to approach thisSuggest adding 'Attention-Aware Memory Hierarchies' or 'Sparse-Matrix Support.' Discuss how the current design focuses on dense GEMM, but LLMs would benefit from specialized SECDA modules for FlashAttention-style optimizations.

31. In Figure 8.11, the 'Manual' driver performs better than the 'AXI4MLIR' in one specific small-problem case. Why did the automatic tool fail to optimize that specific instance?

Identifying the 'lower bound' or edge cases of the tool's effectiveness.

How to approach thisExplain the 'fixed overhead' of the MLIR runtime calls. For very small matrices, the setup cost of the MLIR abstractions can outweigh the data-transfer gains that only become significant as the problem size scales.

32. How does the 'Instruction Decoder' in MM2IM handle 'Control Flow'? Can it do loops and branches, or is it a simple linear command stream?

Probing the complexity of the custom Micro-ISA.

How to approach thisClarify that it is a 'Micro-ISA' for configuration (kernel size, stride, etc.), not a general-purpose processor. The 'looping' is handled by the hardware Scheduler, which repeats operations based on the configuration registers.

33. Your 'Performance Model' for TCONV (Section 7.2.3) seems to assume linear scaling. How do you account for 'DDR bank conflicts' when multiple DMAs are active?

Testing depth in computer architecture and memory systems.

How to approach thisAcknowledge the simplicity of the model. Explain that for the Z-7020, you typically only have one active DMA stream for weights and one for activations, which minimizes bank conflicts compared to many-core systems.

34. Finally, you mention 'Lessons Learned' in Section 9.3.2. What was the most 'surprising' failure you encountered during the SECDA design process that actually led to a better final design?

A traditional viva closing question to gauge the candidate's journey and insight.

How to approach thisShare a specific anecdote. For example, perhaps an early VM design that looked great in SystemC but failed synthesis timing, which led to the insight of using the 'Output Crossbar' to decouple the compute from the write-back logic.

35. In your analysis of the MatMul accelerator, you observed that the compute cores achieve less than 10% utilization on average — doesn't this suggest that the architectural overheads of your driver code and data transfer mechanisms are the actual bottleneck, rather than the hardware design itself?

The data in Figure A.1 shows extremely low utilization, indicating that the 'solution' to efficiency might be overshadowed by the system-level overhead.

How to approach thisConcede that the utilization is low and explain that this realization led to the AXI4MLIR work. Defend the research by explaining that the thesis identifies and characterizes these bottlenecks (like heap-to-DMA copying) to provide a path toward automation that eventually bridges the gap between peak hardware performance and system-level reality.

36. You propose DMA-based data allocation and data coalescing as 'future work' to mitigate significant host-side bottlenecks — why were these fundamental optimizations not implemented and evaluated as a core part of your AXI4MLIR contribution, given their critical impact on the end-to-end performance you claim to optimize?

The candidate identifies critical performance flaws (extra staging transfers) but relegates the solutions to an appendix or future work rather than including them in the primary results.

How to approach thisExplain that the primary contribution was the creation of the MLIR 'accel' dialect and the automated generation framework. Argue that establishing the compiler infrastructure was the necessary first step, and while the optimizations are vital, the initial results demonstrate the feasibility of the toolchain even before fine-tuning the data movement.

37. Your research avoids the exploration of multi-layer hardware acceleration, requiring data to return to the host between every layer — how does this design choice impact the viability of your accelerators for real-time edge inference, where the cumulative latency of host-accelerator communication for an entire deep network could easily exceed the compute time?

The thesis acknowledges this limitation but justifies it through 'resource constraints,' which might not be a valid trade-off for end-to-end edge applications.

How to approach thisJustify the choice by emphasizing the focus on individual kernels for resource-constrained edge FPGAs where BRAM is limited. Argue that while multi-layer fusion is an important next step, the foundational work of this thesis—optimizing the heavy-hitting operations like Transposed Convolution—provides the necessary building blocks for future fused-layer architectures.

38. You note that your research was constrained by the deprecation of SystemC High Level Synthesis in newer toolchains and that you purposefully did not focus on HLS pragmas — how can you ensure that the performance improvements you claim for your accelerators are a result of your architectural design rather than simply a lack of low-level optimization in the baseline implementations you compared against?

The candidate admits to ignoring the 'difficulties and complexities of HLS,' which are often where the most significant performance gains are found in FPGA design.

How to approach thisClarify that the research focus is on high-level hardware-software co-design and productivity (reducing development time), not on peak single-kernel optimization. Defend the findings by stating that the systematic methodology provided by SECDA allows for a broader exploration of the design space than manual pragma-tuning alone could provide in the same development window.

39. You applied the SECDA methodology across CNNs, LLMs, and GANs, yet the MM2IM design in your research is presented as a highly specialized solution for Transposed Convolutions. To what extent is SECDA a truly unified, repeatable framework rather than a series of bespoke, manual adaptations for different operator types?

The candidate presents SECDA as a general methodology, but the divergence in accelerator architectures (VM, SA, MM2IM) suggests the 'methodology' may lack a consistent, automated path from model to hardware.

How to approach thisThe candidate should acknowledge that while the high-level steps of SECDA (profile, design, evaluate) are consistent, the architectural primitives must evolve for different workloads. They should argue that the value of SECDA lies in providing a structured co-design loop rather than a 'one-size-fits-all' hardware template, citing how the methodology helped identify specific bottlenecks in TCONV that led to the MM2IM design.

40. In your work on SECDA-LLM, you utilize Block Floating Point (BFP) quantization to fit LLMs onto resource-constrained edge FPGAs. Given the massive parameter counts of LLMs compared to the extremely limited on-chip memory of edge devices, how do you justify focusing on compute-side BFP optimization when off-chip memory bandwidth remains the primary performance bottleneck for inference?

The thesis targets edge FPGAs for LLMs, which are notoriously memory-bound, yet focuses heavily on the compute/quantization aspect (BFP) which may not solve the underlying hardware limitation.

How to approach thisThe candidate should admit that memory bandwidth is the 'memory wall' for LLMs on edge devices. They should defend their focus on BFP by explaining how it reduces the volume of data moved from external memory (not just compute precision), thereby directly addressing the bandwidth bottleneck, and explain that without efficient compute to match, memory savings would be wasted.

41. Your thesis introduces AXI4MLIR for automatic host code generation in its final chapter, yet the earlier designs for the VM, SA, and FC-GEMM accelerators appear to rely on manual driver development. Does the introduction of AXI4MLIR imply that the performance results and design cycles you reported in your earlier case studies were suboptimal because they lacked this automated host-accelerator communication layer?

The late introduction of AXI4MLIR creates a discrepancy between the 'automated' ideal of the thesis and the 'manual' reality of the primary case studies.

How to approach thisThe candidate should clarify that AXI4MLIR was a result of the 'lessons learned' during the manual phase of the earlier chapters. They should argue that the earlier results were not suboptimal in performance—as the drivers were hand-tuned—but that the design *productivity* was lower, which AXI4MLIR was specifically designed to solve in the final iteration of the research.

42. Your MM2IM accelerator is specifically optimized for the Transposed Convolution operation to support GANs; however, many modern generative architectures have shifted toward using interpolation followed by standard convolutions to avoid checkerboard artifacts. By hardware-optimizing for the TCONV operator, have you developed a specialized solution for an operation that is becoming less relevant in the field of deep learning?

The focus on a specific operator (TCONV) in the MM2IM design may be a niche optimization if the ML community is moving toward different algorithmic approaches for upsampling.

How to approach thisThe candidate should acknowledge the trend toward interpolation-based upsampling but argue that TCONV remains a fundamental primitive in many production-grade GANs and legacy models. They should also discuss how the MM2IM's approach to data movement (col2IM) might be adaptable to other operations that involve irregular memory access patterns common in generative tasks.

43. By choosing to integrate the SECDA methodology with the TFLite delegate system, you inherit the fixed operator set and runtime overheads of the TFLite framework. Did this choice of a high-level delegate system prevent you from exploring lower-level hardware optimizations—such as custom bit-width precision or non-standard memory layouts—that would be possible if you had targeted a more flexible compiler backend like MLIR from the start?

The reliance on TFLite's delegate system as the primary vehicle for hardware-software co-design limits the search space to what TFLite supports, potentially missing higher performance gains.

How to approach thisThe candidate should explain the trade-off between absolute performance and real-world deployment. They should argue that TFLite was chosen to ensure the accelerators are usable by application developers today, while also pointing to Chapter 8 (AXI4MLIR) as their pivot toward a more flexible, lower-level MLIR-based infrastructure that addresses the very limitations TFLite imposed.

44. You chose to utilize SystemC for cycle-approximate, loosely-timed simulation rather than cycle-accurate RTL simulation; how do you justify the risk that unmodeled micro-architectural stalls or AXI bus contention might have led to significant discrepancies between your simulated performance metrics and the actual behavior on physical hardware?

The candidate relies on loosely-timed models which, by definition, ignore fine-grained timing events that are often critical in edge-device resource bottlenecks.

How to approach thisAcknowledge that loosely-timed models prioritize simulation speed and architectural exploration over bit-perfect timing. Defend this by explaining any validation steps taken against real hardware and argue that the high-level transaction modeling was sufficient to capture the dominant latency bottlenecks of the DNN workloads.

45. You highlight that standard Input-Oriented Mapping implementations for transposed convolutions suffer from up to 28% ineffectual computation due to cropped outputs; given this inherent algorithmic waste, why did you decide to specialize in optimizing IOM rather than developing a hardware-specific variant of Transforming Deconvolution to Convolution, which inherently avoids the overlapping sum problem?

The candidate chooses to optimize a method (IOM) that they admit has significant waste, creating a vulnerability regarding the fundamental choice of algorithm.

How to approach thisExplain that while TDC avoids overlapping sums, it introduces hardware complexity in handling sparse sub-filters and weight replication. Defend the choice by showing that the specific 'specialized accelerator' mentioned in the research effectively mitigates the 28% waste through smart output mapping or index control, yielding better overall efficiency than a TDC implementation.

46. In your system model, the host CPU is responsible for managing DMA transfers and executing tile-based data functions for every layer; for a resource-constrained SoC like the Zynq-7020, how did you ensure that the driver execution and tiling overhead on the ARM core does not become the primary performance bottleneck, effectively masking the speedup achieved by your FPGA accelerator?

The dependency on host-side driver software (Algorithm 3 and 4) often creates a 'host-bottleneck' in edge systems that is frequently overlooked in hardware-centric research.

How to approach thisDescribe the balance of the HW-SW co-design, perhaps by detailing the use of interrupts or double-buffering. Provide data or reasoning to show that the accelerator's execution time for a tile is significantly larger than the CPU's management time, ensuring the accelerator remains the primary driver of performance.

47. Your methodology employs asymmetrical INT8 quantisation for inputs while forcing symmetry on weights to retain precision; given the limited logic resources on edge FPGAs, how do you defend the additional hardware area and latency overhead required to handle zero-point offset logic compared to a purely symmetric quantisation scheme?

Asymmetric quantisation requires extra arithmetic (additions/offsets) in the inner loop of the MAC units, which is costly on small FPGAs.

How to approach thisAcknowledge the hardware cost of zero-point arithmetic. Argue that the accuracy loss from forcing symmetric quantisation on activations—which often have skewed distributions (like ReLU)—would be unacceptable for edge applications, thus justifying the small logic overhead as a necessary trade-off for model fidelity.

48. You argue that partitioning FPGA resources into multiple specialized processing elements for different layer types increases utilization, but does this architectural rigidity not contradict your stated goal of flexibility, specifically when attempting to run emerging DNN models that utilize layer configurations not anticipated during your partitioning phase?

The candidate advocates for specialized partitioning, which can lead to hardware that is too over-fit to specific 'popular' models like Inception or ResNet to be truly useful in a fast-moving field.

How to approach thisDefend the partitioning as a 'soft' or 'reconfigurable[extract from the author’s document removed]general-purpose' within the domain of tensor operations to handle unseen layer types.

49. For the LLM inference portion of your study, you utilize llama.cpp to facilitate 1.5-bit to 8-bit BFP quantization — given the notoriously memory-bound nature of these models, did your hardware-software co-design actually alleviate the off-chip memory bandwidth bottleneck of the Zynq-7000, or did the acceleration simply result in the processing units stalling more frequently for data?

Large Language Models often bottleneck at the memory interface rather than the compute unit, making the benefits of custom FPGA compute logic questionable on low-bandwidth edge devices.

How to approach thisDiscuss the specific metrics observed regarding memory stall cycles versus compute cycles. Argue that while the I/O remains a challenge, the reduction in weight bit-width via BFP was essential to making the workload feasible on the FPGA at all, and explain how your design optimizes data reuse to mitigate the bandwidth limit.

50. Your methodology employs a fragmented software stack, using TFLite delegates for CNNs, llama.cpp for LLMs, and MLIR for the AXI4MLIR work — how do you justify this lack of a unified toolchain, and does this fragmentation prevent the designer from performing cross-layer optimizations that a single, end-to-end compiler infrastructure might have enabled?

The use of disparate frameworks for different model types suggests a lack of a cohesive, unified methodology for hardware-software co-design.

How to approach thisExplain that the choice of frameworks was driven by the practical need to support state-of-the-art implementations for diverse model types (CNNs vs. LLMs). Acknowledge that while a unified IR like MLIR is the ideal end-goal, your research demonstrates how co-design principles can be successfully applied to the current reality of the heterogeneous ML software ecosystem.

51. In your study of generative models, you developed specialized accelerators for transposed convolution operations — considering that these operations often involve irregular memory strides and zero-padding, how did your hardware design maintain high processing element utilization compared to standard GEMM-based convolutional accelerators?

Transposed convolutions (common in GANs) often lead to hardware underutilization due to the 'checkerboard' data patterns they create.

How to approach thisDetail the specific architectural adjustments made to the PUs or the memory scheduling to handle upscaling. Defend the design by showing comparative utilization data or explaining how the hardware-software co-design specifically optimized the dataflow to skip redundant zero-weight calculations.

52. Your thesis proposes both systolic array and vectorized dataflows for DNN acceleration — given the extreme resource constraints of the edge FPGAs you targeted, what specific criteria or automated heuristics does your methodology provide to help a designer choose between these two paradigms for a specific workload before committing to the time-consuming logic synthesis process?

The thesis describes both architectures but lacks a clear, quantified decision-making framework for selecting one over the other under specific resource limits.

How to approach thisAcknowledge that the choice often depends on the ratio of available DSP blocks to BRAM. Provide a retrospective framework based on your results, explaining how model-specific factors (like layer depth vs. width) and hardware-specific factors (like routing congestion) should inform this choice within the SECDA design loop.

Contribution and Significance

53. A key claim in your thesis is that SECDA reduces 'development time.' How do you quantify this claim? Did you conduct any user studies, or is this based on your own experience compared to traditional RTL workflows?

Challenging the 'soft' claim of productivity improvement.

How to approach thisAcknowledge the lack of a formal user study but provide a comparative 'timeline' based on your design iterations. Contrast the time spent in the SystemC design loop (hours) vs. full synthesis/implementation in Vivado (days) for the VM and SA designs.

54. How does your AXI4MLIR extension contribute to the 'portability' of DNN accelerators? If I have a custom accelerator not using the AXI protocol, is your compiler framework still applicable?

Evaluating the breadth of the contribution in the compiler space.

How to approach thisExplain that while the current implementation targets AXI (due to its prevalence in the Xilinx ecosystem), the 'accel' dialect and the lowering logic are designed to be protocol-agnostic. Discuss how one would extend the library for other interconnects like TileLink or Avalon.

55. You have released SECDA-TFLite and SECDA-LLM as open-source toolkits. What is the most significant 'barrier to entry' for another researcher trying to use these tools for a non-Xilinx FPGA, such as an Intel Arria or a Lattice CrossLink?

Probing the generalizability and impact of the software artifacts.

How to approach thisIdentify the dependency on Xilinx HLS and the PYNQ driver stack. Suggest that while the methodology is general, the toolkit's 'backend' would require porting the DMA management and IP generation scripts for the target vendor's ecosystem.

56. In the context of 'Edge AI,' your work focuses on inference. Given the move toward 'On-device Learning,' how could the SECDA methodology be extended to support the backpropagation/gradient descent operations required for training?

Exploring the future significance and expansion of the work.

How to approach thisDiscuss the additional hardware complexity for training (e.g., transposed data access, gradient storage). Argue that the co-design loop of SECDA would be even more valuable here due to the increased complexity of managing data movement for the backward pass.

Methodology and Methods

57. In Section 2.5.1, you advocate for SystemC. Since SystemC simulation is typically untimed or loosely timed at high levels of abstraction, how did you ensure the simulation cycles reported in SECDA accurately reflected the actual clock cycles of the synthesized RTL on the FPGA?

Probing the timing fidelity of the simulation-based methodology.

How to approach thisExplain the use of 'cycle-accurate' modeling within SystemC for the compute units and DMA. Mention the validation steps where simulation results were compared against PYNQ Z1 hardware measurements to establish the correlation.

58. You integrated SECDA with TensorFlow Lite using a custom delegate system. Why did you choose the delegate approach over the more direct 'TFLite Micro' path, which is often preferred for resource-constrained edge devices?

Understanding the choice of software integration layer.

How to approach thisHighlight the need for Linux-based DMA management and the flexibility of the TFLite delegate system for partitioning models between the ARM core and the FPGA fabric, which TFLite Micro handles differently for bare-metal systems.

59. Regarding the AXI4MLIR project (Chapter 8), you mention a collaboration with Nicolas Bohm Agostini. Can you clearly delineate which parts of the MLIR 'accel' dialect and the host-code generation logic were your specific contributions?

Clarifying authorship and individual contribution in a collaborative chapter.

How to approach thisRefer to the declaration at the start of Chapter 8. Specify your work on the AXI DMA library, the experimental validation using specialized accelerators (MatMul, Conv), and the development of the data-transfer optimization passes.

60. In the SECDA design loop (Figure 4.1), you include 'Hardware Synthesis' as a step. Did you find that the HLS (High-Level Synthesis) directives like #pragma HLS PIPELINE or UNROLL were sufficient, or did you have to resort to manual RTL to meet the 200 MHz clock frequency on the Zynq fabric?

Probing the limitations of HLS within the SECDA methodology.

How to approach thisDiscuss the iterative process of applying HLS pragmas. Acknowledge any challenges with timing closure on the Z-7020 and how the SECDA methodology allowed you to identify bottlenecks early in SystemC before committing to long synthesis runs.

61. Your SECDA-LLM toolkit (Chapter 6) targets llama.cpp. How do you handle the dynamic memory management requirements of LLMs (like KV caching) within your fixed-buffer FPGA DMA-space?

Testing the methodology's adaptability to complex memory patterns in LLMs.

How to approach thisExplain how the llama.cpp integration manages the memory pool. Discuss how the accelerator driver handles the transfer of only the required blocks for the current operation (Matrix-Vector multiplication) to the DMA-space to avoid exceeding the 512MB DDR3 limit.

62. You utilize AXI4-Stream for the data path. Given the resource constraints, did you consider using AXI4-Lite for data transfer, or would the overhead of register-based transfer have invalidated your speedup claims?

Probing the choice of interconnect protocol.

How to approach thisDismiss AXI4-Lite for bulk data as too slow. Argue that AXI4-Stream is essential for saturating the bandwidth between DDR and the FPGA's BRAM buffers, which is a core part of the system model in Chapter 1.

Findings and Analysis

63. For the MM2IM accelerator (Chapter 7), you report an 84x average speedup across 261 TCONV configurations. How many of those configurations were 'compute-bound' versus 'memory-bound,' and did the speedup hold for smaller kernel sizes (e.g., 2x2)?

Deconstructing a high-level speedup claim to understand its limits.

How to approach thisBreak down the benchmarks. Reference Figure 7.4. Explain that larger configurations benefit more from the dataflow, while smaller kernels may be bottlenecked by the overhead of the MM2IM Mapper and memory-mapped IO setup.

64. In Figure 8.8, you compare AXI4MLIR-generated code against manual implementations. Why does the 'Manual' driver show significantly higher cache references (up to 56% more)? Is this a reflection of poor manual coding or a specific optimization within the MLIR pass?

Questioning the validity of the software baseline in the MLIR chapter.

How to approach thisExplain that the MLIR pass performs more aggressive data-coalescing and pipelining than a typical hand-written driver. Discuss how 'accel' operations in MLIR allow for a more holistic view of the memory layout compared to standard C-based DMA drivers.

65. You found that the Systolic Array (SA) accelerator outperformed the Vector MAC (VM) in specific CNN layers. Based on your results in Table 5.3, what is the 'threshold' of layer dimensions where the SA's overhead for filling/draining the array makes it less efficient than the VM?

Probing the comparative analysis of the two main architectures.

How to approach thisReference the specific layer shapes in the CNN results. Discuss the trade-offs in utilization: SA requires high 'parallelism' in the input/output channels to keep the PEs busy, whereas VM is more efficient for narrow or highly irregular channel sizes.

66. For the SECDA-LLM case study (Chapter 6), you used Block Floating Point (BFP) quantization. How did the 'zero-point' and 'scale' calculations in BFP impact the FPGA resource usage, particularly the DSP count compared to standard INT8 quantization?

Analyzing the cost of specialized quantization in hardware.

How to approach thisDiscuss the logic required for BFP scaling in the compute units (Figure 6.4). Contrast the DSP usage for the BFP multipliers versus standard INT8, and explain why the trade-off was worth it for LLM accuracy on the Zynq 7020.

67. Your results show that the FC-GEMM accelerator achieved a 1.08x speedup on TinyBERT but struggled with larger BERT models (Section 5.5.3). Why does the scaling fail as the model size increases, and is this a limitation of the DMA bandwidth or the BRAM capacity?

Probing the limits of scaling in transformer acceleration.

How to approach thisIdentify the 'memory wall.' Argue that for larger BERT models, the weights must be swapped in/out of BRAM more frequently, causing the system to become memory-bound by the DDR3 bandwidth of the Zynq platform.

68. Your thesis proposes the MatMul to col2IM (MM2IM) design as an efficient solution for Transposed Convolutions in GANs; why did you determine that mapping this operation to a Matrix Multiplication to col2IM workflow was superior to alternative hardware implementations, such as direct convolution or zero-padding approaches, for resource-constrained edge FPGAs?

The examiner is probing the candidate's justification for their specific architectural choice and their understanding of the trade-offs involved in TCONV implementations.

How to approach thisThe candidate should explain the computational complexity of Transposed Convolution and how MM2IM leverages existing matrix multiplication efficiencies while managing the spatial expansion of data. They should highlight the benefits of data reuse or reduced padding overhead compared to the alternatives mentioned.

69. You focus specifically on resource-constrained edge FPGAs for your MM2IM accelerator; how does your design manage the high memory bandwidth and storage requirements of the col2IM process without exceeding the limited logic and BRAM resources of these devices?

This question tests the candidate's ability to reconcile high-performance algorithmic requirements with the strict physical limitations of edge hardware.

How to approach thisThe candidate should discuss specific hardware-level optimizations, such as tiling strategies, buffer management, or data streaming techniques used to keep the footprint small. They should explain how the design balances throughput against resource consumption.

70. Your thesis utilizes the SECDA design methodology across several accelerators; could you explain how the iterative design space exploration inherent in SECDA specifically led to the architectural decisions found in your MM2IM design for GANs?

The examiner wants to see evidence of the methodology being applied practically to influence the final design outcome.

How to approach thisThe candidate should describe a specific instance during the design of MM2IM where a simulation or early prototype led to a change in the architecture. They should link the SECDA feedback loop directly to a performance gain or resource reduction in the final MM2IM implementation.

71. Given your development of AXI4MLIR for automatic host code generation, how did you ensure that the host-accelerator communication for the MM2IM design remained efficient enough to not become a bottleneck during the TCONV operation?

The examiner is looking for an understanding of system-level performance where the driver and communication overhead can negate hardware gains.

How to approach thisThe candidate should explain how AXI4MLIR optimizes data transfer and driver calls specifically for the MM2IM's data patterns. They should mention the importance of minimizing CPU-side overhead to maintain the high throughput achieved by the hardware accelerator.

72. Your research highlights the Transposed Convolution as a key operation in GANs; how does your MM2IM architecture address the unique data flow patterns of GANs compared to the Vector MAC and Systolic Array accelerators you designed for standard convolutional layers?

This question assesses the candidate's ability to differentiate between various neural network layers and justify specialized hardware for each.

How to approach thisThe candidate should compare the data access patterns of standard convolution versus transposed convolution. They should explain why a general-purpose systolic array might be sub-optimal for the 'up-sampling' nature of GAN layers and how MM2IM is tailored for this specific data expansion.

73. Your work on SECDA-LLM explores Block Floating Point (BFP) quantization; what considerations did you make regarding quantization or precision in the MM2IM accelerator to ensure that GAN output quality is maintained while maximizing efficiency on edge hardware?

The examiner is probing the candidate's awareness of how low-precision arithmetic—common in edge acceleration—impacts the sensitive generative tasks of GANs.

How to approach thisThe candidate should discuss the numerical stability requirements of GANs and whether they applied similar quantization techniques as seen in their LLM work. They should justify the chosen bit-width or data format based on its impact on the final image or data generation quality.

74. Your thesis integrates the SECDA methodology with the TFLite delegate system; what were the primary challenges in making the MM2IM accelerator compatible with this delegate system, and how does this integration facilitate the deployment of GAN models on edge devices?

This question explores the software-side of the co-design and the practicalities of deploying the custom hardware within existing AI frameworks.

How to approach thisThe candidate should describe the process of mapping the TCONV operation in a TFLite model to the MM2IM hardware via the delegate. They should explain how this abstraction allows for seamless model execution while hiding the underlying hardware complexity from the end user.

75. Your thesis proposes the SECDA methodology for hardware-software co-design; how do you defend the necessity of this new methodology against existing High-Level Synthesis (HLS) flows that already claim to bridge the gap between algorithmic C/C++ and RTL?

The examiner is probing the candidate's understanding of the unique value proposition of their methodology compared to industry-standard tools like Vivado HLS.

How to approach thisExplain the specific limitations of standard HLS in the context of edge DNN inference—such as the difficulty of managing hardware-software interfaces—and show how SECDA provides a more integrated or automated approach to co-designing the driver and the accelerator simultaneously.

76. In your analysis of FPGA resources, you identify the DSP48E blocks and BRAM as critical constraints on the Zynq-7000 SoC. How did you determine the optimal ratio between processing unit parallelism and on-chip memory allocation for your specific accelerators?

This question tests the candidate's ability to justify design decisions based on physical hardware limitations, which is central to experimental design research.

How to approach thisDiscuss the trade-offs between compute-bound and memory-bound layers. Reference the specific memory hierarchy you implemented to hide latency and how the number of PUs was limited by the available DSP slices versus the need for BRAM to store weights and activations.

77. Your research utilizes MLIR and the AXI4MLIR runtime to facilitate hardware-software co-design. How do you justify the complexity of using a multi-level compiler infrastructure over more traditional, direct hardware-driver implementations for resource-constrained devices?

The examiner wants to see if the candidate understands the scalability and productivity benefits of compiler-based abstractions versus potential performance overheads.

How to approach thisHighlight the benefits of 'progressive lowering' and the reuse of compiler passes. Argue that MLIR allows for better domain-specific optimizations (like tiling in the Linalg dialect) that are harder to maintain in hand-tuned drivers as DNN models evolve.

78. When accelerating CNNs, you opted for GEMM-based convolutions via the IM2COL algorithm. Given that IM2COL involves data replication that can strain the limited memory bandwidth of edge FPGAs, why did you choose this over direct convolution or Winograd transformations?

This probes the candidate's mastery of algorithmic trade-offs specifically related to memory and compute efficiency.

How to approach thisAcknowledge the memory overhead of IM2COL but explain how it enables higher compute utilization through highly optimized matrix multiplication kernels. Compare this to the irregular memory access of direct convolution or the mathematical complexity/bit-width requirements of Winograd.

79. Your thesis addresses the acceleration of Large Language Models (LLMs) using llama.cpp and BFP quantization as low as 1.5 bits. How did your hardware design specifically accommodate the unique bit-level manipulation required for these sub-byte formats on an FPGA architecture?

This explores the intersection of aggressive software quantization and hardware implementation, a key challenge in edge AI.

How to approach thisDiscuss how the reconfigurability of FPGAs (CLBs and LUTs) allowed you to implement custom logic for non-standard bit-widths that general-purpose CPUs or GPUs cannot handle efficiently. Explain any custom PEs designed for BFP arithmetic.

80. You compare systolic array and vectorized (SIMD) processing unit dataflows. Based on your experimental results, what are the definitive conditions under which your thesis would recommend a systolic array over a vectorized design for edge-based inference?

The examiner is looking for a generalized architectural insight derived from the candidate's experimental data.

How to approach thisDifferentiate based on workload characteristics like kernel size and data reuse. Explain how systolic arrays excel in high-reuse scenarios (minimizing global memory traffic) while vectorized designs might offer more flexibility for varied layer types with less regular data movement.

81. You leverage the TensorFlow Lite delegate system for FPGA integration. How does your research address the potential latency bottlenecks introduced by the communication overhead between the ARM host and the FPGA when offloading delegated kernels?

This targets the 'system' aspect of hardware-software co-design, ensuring the candidate considered the end-to-end performance rather than just the isolated accelerator speed.

How to approach thisDetail the use of High-Performance AXI ports and DMA transfers mentioned in your thesis. Explain how your SECDA methodology or AXI4MLIR runtime minimizes driver-level overhead and context-switching between the TFLite runtime and the hardware.

82. You claim that the SECDA methodology matured from a tool for your own learning into a generalized design process. How do you defend the claim that this methodology is truly application-agnostic, particularly when transitioning from TFLite workloads to the significantly more complex memory and compute patterns inherent in Large Language Models?

The examiner is probing the generalizability and robustness of the candidate's primary methodological contribution.

How to approach thisAddress how the high-level iterative loop of SECDA abstracts hardware complexities. Explain how the core principles—simplifying the design loop and providing a high-level application bridge—remain consistent even as the underlying DNN architecture changes from convolutional to transformer-based structures.

83. In your analysis of AXI4MLIR, you observed that the accelerator's compute cores were achieving less than 10% utilization due to CPU-side bottlenecks. Why did you prioritize compiler-driven data transfer optimizations over hardware-centric solutions like dedicated pre-fetching logic or on-chip buffer management?

This probes the candidate’s rationale for choosing a software/compiler solution for what is traditionally seen as a hardware utilization problem.

How to approach thisJustify the use of the MLIR framework to tackle the host-accelerator communication bottleneck. Argue that hardware resources on edge FPGAs are too limited for complex pre-fetchers, making 'CPU-aware' host driver code a more resource-efficient way to hide latency through techniques like software pipelining.

84. You encountered the deprecation of SystemC High Level Synthesis (HLS) in newer versions of the Xilinx toolchain. Given your focus on co-design, how did you ensure that your high-level architectural contributions remained resilient to the volatility of vendor-specific EDA tools?

The examiner is testing the candidate's understanding of research portability and the risks of vendor lock-in within the hardware domain.

How to approach thisExplain that while the implementation used Xilinx-specific tools, the SECDA methodology and AXI4MLIR dialects are defined at a level of abstraction that can be mapped to other FPGA vendors or RTL-based workflows. Emphasize the modular nature of your designs.

85. Your experimental evaluation relies heavily on the PYNQ-Z1 platform. How do you justify the generalizability of your performance results for 'resource-constrained edge devices' as a category, given that different FPGA architectures might have significantly different interconnect latencies or BRAM densities?

This is a critique of the empirical scope, questioning if the results are artifacts of a specific piece of hardware.

How to approach thisAcknowledge the limitation but argue that the PYNQ-Z1 represents a 'worst-case' or baseline scenario for edge deployment. Discuss how the scalability of the MM2IM architecture and the flexibility of the SECDA-TFLite toolkit would allow these methods to adapt to larger or smaller FPGAs by tuning tiling parameters.

86. You reflect on the lack of exploration into multi-layer hardware acceleration due to resource constraints. Given the high data transfer overheads you identified, how would moving toward heterogeneous multi-layer designs have fundamentally challenged your argument for the effectiveness of the 'accel' dialect in AXI4MLIR?

The examiner is looking for a critical analysis of how a different design scope might have altered the thesis's conclusions regarding communication overhead.

How to approach thisAnalyze the trade-off: multi-layer acceleration reduces host-accelerator traffic but increases hardware complexity. Suggest that while it might reduce the need for some AXI4MLIR optimizations, it would make the 'tiling and dataflow strategy' generation even more vital for managing on-chip data movement.

87. You make a distinction between architectural ideals designed on paper and the practical 'lesson learned' regarding HLS pragmas and synthesisable code. Does your SECDA methodology effectively bridge this gap, or does the need for manual HLS tuning suggest that automated hardware-software co-design still requires deep low-level expertise?

This probes the 'ease of use' claim of the candidate's methodology, questioning if it truly simplifies the design process for non-experts.

How to approach thisCritically evaluate the maturity of SECDA. Argue that while it provides the framework and automation for the 'iteration loop' (which is the main time-sink), expert knowledge of HLS pragmas remains a necessary 'fine-tuning' step that your methodology encapsulates rather than replaces.

88. You chose SystemC for Transaction Level Modelling (TLM) and adopted a cycle-approximate rather than a cycle-accurate approach for your simulations. Given the sensitivity of DNN inference to latency, how do you defend the validity of your performance results against the potential timing discrepancies inherent in loosely-timed models?

The examiner is questioning the methodological rigor of the simulation phase and the candidate's understanding of the limitations of SystemC TLM.

How to approach thisAcknowledge the speed-accuracy trade-off in SystemC. Describe how you validated your cycle-approximate results against physical hardware (like the Zynq-7020) and why event-driven simulation was sufficient for capturing the primary bottlenecks in the DMA and AXI-Stream communication paths.

89. Your thesis utilizes AXI-MM for the FC-GEMM accelerator but shifts to AXI-Stream and AXI-Lite for all other designs. What specific characteristics of the Fully-Connected layer workload led you to favor memory-mapped access over the lower latency and higher throughput typically offered by streaming interfaces?

This probes the candidate's understanding of host-accelerator communication protocols and their relationship to specific neural network layer behaviors.

How to approach thisCompare the random access patterns or data reuse characteristics of FC layers versus the sequential streaming nature of convolutions. Explain how the overhead of AXI-MM mapping was managed and why the simpler AXI-Stream wasn't ideal for the specific memory access patterns of the FC-GEMM module.

90. You position your work against the VTA accelerator and the TVM framework, noting VTA's use of a micro-ISA. How do you argue that your specialized, co-designed approach provides a more efficient solution for edge FPGAs than the highly programmable, instruction-set-based architecture of VTA?

The examiner is looking for a critical comparison between 'fixed-function' specialized accelerators and 'programmable' domain-specific architectures (DSAs).

How to approach thisHighlight the overhead of instruction fetching and decoding in VTA. Argue that for specific edge applications (like the GANs or CNNs you tested), your design achieves better throughput-per-watt or a smaller resource footprint by baking the dataflow logic directly into the hardware state machines.

91. When discussing tiling and pipelining, you mention that the host CPU and accelerator can be pipelined to hide pre-processing latency. In your experiments on the ARM-based SoC, how did you ensure that the host-side 'accelerator driver' didn't become a bottleneck, particularly when managing complex tiled data transfers for large tensors?

The examiner is investigating the 'software' half of the hardware-software co-design, specifically the management overhead of the CPU driver.

How to approach thisDetail the multi-threading or asynchronous DMA management implemented in your driver code. Refer to your Algorithm 4 and explain how you balanced the CPU's task of tile preparation with the FPGA's execution time to achieve maximum hardware utilization.

92. Your analysis of Transposed Convolution identifies the 'overlapping sum problem' as a major hurdle. How does your Input-Oriented Mapping (IOM) implementation specifically handle the spatial locality of these partial sums to avoid stalling the pipeline during accumulation in the local buffers?

This probes the candidate's deep technical knowledge of the hardware datapath and its ability to handle non-trivial memory-write dependencies.

How to approach thisDescribe the architecture of your accumulation buffers. Explain how you managed concurrent reads and writes for overlapping regions and how the buffer depth or banking strategy was tuned to prevent pipeline stalls when kernel strides create frequent overlaps.

Research Design and Conceptual Framework

93. In Section 1.1.3, you categorize FPGA acceleration into 'DNN-to-FPGA-Dataflow' and 'DNN-to-FPGA-Accelerator' paradigms. Why did you decide that the dataflow approach is 'infeasible' for resource-constrained devices, given that tools like HLS4ML can employ aggressive pruning and weight-clustering to fit models into BRAM?

Testing the candidate's justification for choosing the accelerator-centric paradigm over dataflow architectures.

How to approach thisDefend the choice by highlighting the memory/resource constraints of the Zynq 7020 (140 BRAMs). Reference your argument that 20MB weights cannot fit on-chip, and explain how the accelerator paradigm offers better flexibility for the diverse layer types you target (CONV, FC, TCONV).

94. Your host-accelerator system model (Figure 1.1) relies on an Ubuntu 18.04 environment on an ARMv7-A processor. How do the overheads of a full Linux OS kernel influence your measurements of 'end-to-end' latency, particularly for small-batch inference where driver context-switching might dominate?

Probing the impact of OS overhead on edge performance claims.

How to approach thisDiscuss the trade-offs between 'user-space' drivers and real-time performance. Acknowledge the context-switching latency but emphasize that for DNN inference, the compute time usually outweighs kernel overhead, and SECDA-TFLite aims to manage these interactions efficiently via DMA-space mapping.

95. You define your target as 'resource-constrained' edge FPGAs. Given the emergence of much larger SoCs like the Versal series, why is the Zynq 7020 still a relevant baseline for a 2025 PhD thesis?

Challenging the currency and relevance of the chosen hardware platform.

How to approach thisJustify the Z-7020 as a 'worst-case' constraint scenario that forces efficient design. Argue that solutions that work on the 7020 are highly portable to larger devices, whereas the inverse is not true, and highlight the cost/power profile of 7020-class devices in real-world IoT deployments.

96. How did you arrive at the specific set of 'Five Key Features' for DNN accelerator design methodologies in Table 4.1, and why is 'Continuous Evaluation' prioritized over 'Formal Verification' in your SECDA framework?

Evaluating the criteria used to compare the SECDA methodology against existing ones.

How to approach thisExplain the practical engineering focus of SECDA. Reference the 'Design Loop' and argue that in the fast-moving DNN field, iterative prototyping and profiling are more critical for performance tuning than the formal logic verification typically associated with traditional RTL design.

97. Your work emphasizes 'Hardware-Software Co-Design.' Can you point to a specific instance in your design of the MM2IM accelerator where a software-side decision directly dictated a hardware change, or vice versa?

Testing the 'co' in co-design to ensure it isn't just sequential design.

How to approach thisFocus on Chapter 7 and the MM2IM Mapper. Discuss how the need for efficient cropping (software) led to the specific micro-ISA instruction set and the output crossbar architecture in the hardware to handle non-contiguous memory writes.

Viva Preparation Pack