[Tutorial Update] Edited the Integration Test Getting Started Tutorial to add more detail and clarity

[A-Alosius]

No description provided.

[A-Alosius]

@shundroid. Sorry for the long delay on this.
Please let me know what you think. Your feedback is greatly appreciated

[shundroid]

Thank you for your work! I think the overall structure of this document is solid. However, I started to lose track of how this doc relates to UsingDynamatic.md. From what I can tell, most of the steps are the same, with differences mainly in the details:

• Use integration test
• Use fpga20 buffering algorithm
• Observe visualized results

I'd really appreciate a clearer explanation of the specific purpose of this document. For example, is the goal (1) to show how to use an integration test? (2) To demonstrate the fpga20 algorithm? (3) Or to explore the generated circuit in more depth?

Clarifying this will help determine the right focus for the document, and make it more meaningful and purposeful:

(1): What's the benefit of having users run integration tests instead of using the example from the tutorials folder? How different are they? Honestly, I'm not sure if this justifies a standalone document. If the only change is in the set-src file, maybe that content could just be appended to UsingDynamatic.md instead.
(2): Consider comparing the buffering results between the on-merge and fpga20 algorithms. (Though this might be a bit advanced.)
(3): Dive deeper into the generated circuit:
(a) In binary_search, the final if statement doesn't appear in the CFG. Why is that?
(b) What are the live-ins and live-outs for each basic block, and how are they represented in the circuit?
(c) For the generated kernel_name.png, you could explain what each unit represents. For example, the light green boxes like DV [1], R [1], and NONE [1] are buffers with different characteristics. Also, how does each part of the original source code map onto the circuit (e.g., i += 2, a[i] == search)?

Personally, I think (3) would be the most valuable part to highlight in a tutorial.

Also, I forgot to mention: right now, the Polygeist-based frontend generates weird CFG structures for for loops that contain break statements. You can see this in the cf_*.mlir files, where the early exit logic from the break is missing. This happens because Polygeist is designed for regular programs and tends to eliminate irregular control flow, which actually doesn't align well with our needs. PR #535 addresses this by replacing Polygeist with traditional Clang, but this change hasn't yet been integrated into the compile.sh workflow. So, if you're going to analyze the CFG in the doc, briefly noting this limitation would be helpful, as readers might otherwise be confused.

Diving into these deeper topics probably needs a bit more familiarity with Dynamatic, so feel free to reach out (email also works) if you have questions. That said, no pressure. This work isn't mandatory. If you're too busy to continue, it's totally fine to pause it.