MLIR จะเป็นอนาคตของ HLS ได้หรือไม่? การปฏิบัติเชิงลึกของคอมไพเลอร์ Dynamatic เผยให้เห็นข้อจำกัดและโอกาสหลัก 4 ประการ

คำสำคัญ: MLIR, HLS, การสังเคราะห์ระดับสูง, Dynamatic, โครงสร้างพื้นฐานคอมไพเลอร์, วงจรการไหลของข้อมูล

ปัจจุบัน LLVM เป็นเฟรมเวิร์กพื้นฐานหลักสำหรับเครื่องมือการสังเคราะห์ระดับสูง (HLS) อย่างไรก็ตาม การแสดงระดับกลาง (IR) ที่มีอยู่เดิมนั้นยากต่อการปรับแต่งเพื่อแสดงความหมายของวงจร MLIR สัญญาว่าจะแก้ไขปัญหานี้ผ่านกลไกภาษาถิ่นที่กำหนดเอง

• เอกสารวิชาการ: Is It a Good Idea to Build an HLS Tool on Top of MLIR? Experience from Building the Dynamatic HLS Compiler
• ลิงก์: https://arxiv.org/pdf/2603.19856
• ที่เก็บโค้ด: github.com/EPFL-LAP/dynamatic
• เอกสารโครงการ: https://epfl-lap.github.io/dynamatic/

บทความนี้ประเมินความเป็นไปได้ของการสร้างเครื่องมือ HLS บน MLIR อย่างเป็นระบบ โดยอิงจากประสบการณ์การพัฒนาระยะยาวของคอมไพเลอร์ HLS ที่มีการจัดตารางเวลาแบบไดนามิก Dynamatic

การศึกษาพบว่า MLIR ด้วยสถาปัตยกรรมแบบโมดูลาร์ การลดต้นทุนการพัฒนา IR ที่กำหนดเอง และการปรับให้เข้ากับกระบวนการพัฒนาของทีมวิชาการ สามารถสนับสนุนการแสดงและการปรับแต่งวงจรการไหลของข้อมูลได้อย่างมีประสิทธิภาพ อย่างไรก็ตาม ทีมงานพบข้อจำกัดหลักสี่ประการของ MLIR ในการปฏิบัติงานทางวิศวกรรม:

1. ค่า MLIR ไม่สามารถเพิ่มคุณสมบัติให้กับขอบของกราฟได้ ทำให้ยากต่อการสร้างแบบจำลองการพึ่งพาหน่วยความจำและข้อมูลขอบการควบคุมการไหล
2. การออกแบบที่ใช้พารามิเตอร์บล็อกแทนโหนดที่ชัดเจน เพิ่มความยากในการนำมัลติเพล็กเซอร์ไปใช้เมื่อแปลงจากซอฟต์แวร์เป็นฮาร์ดแวร์
3. โครงการ MLIR-HLS ของบุคคลที่สามมีปัญหาการแตกแยกของการบูรณาการอย่างรุนแรง เนื่องจากความไม่เข้ากันของเวอร์ชัน LLVM
4. ความสามารถในการปรับแต่งส่วนหน้า C ที่มีอยู่นั้นไม่เพียงพอ ทำให้โครงการยังต้องพึ่งพา LLVM และใช้วิธีแก้ปัญหาชั่วคราวที่ซับซ้อน

ปัญหาเหล่านี้ไม่ได้มีเฉพาะในสาขา HLS เท่านั้น แต่ยังมีคุณค่าอ้างอิงสำหรับการพัฒนาคอมไพเลอร์ MLIR ทั่วไปอีกด้วย บทความนี้มีวัตถุประสงค์เพื่อสรุปประสบการณ์การปฏิบัติทางวิศวกรรม เพื่อเป็นพื้นฐานสำคัญสำหรับการปรับปรุงชุมชน MLIR และการเลือกโครงสร้างพื้นฐานเครื่องมือ HLS ในอนาคต

Processor Architecture Laboratory

สารบัญบทความ

• 1. บทนำ
• 2. พื้นหลัง
• 3. การสร้างคอมไพเลอร์ HLS แบบ MLIR ในสภาพแวดล้อมทางวิชาการ
• 4. ข้อจำกัดของ MLIR ต่อโครงการ HLS แบบโอเพนซอร์ส และกรณีศึกษาใน Dynamatic
  • 4.1 ค่า MLIR ไม่เหมาะสำหรับการสร้างแบบจำลองขอบกราฟ
  • 4.2 พารามิเตอร์บล็อกสะดวกสำหรับการแปลง HLS หรือไม่?
  • 4.3 เราแก้ไขปัญหาการแตกแยกของซอฟต์แวร์แล้วหรือยัง?
  • 4.4 มีส่วนหน้า C สำหรับ HLS ที่มีคุณภาพช่วยในการพัฒนาเครื่องมือ HLS รูปแบบใหม่หรือไม่?
• 5. ความเป็นสากลที่เหนือกว่า HLS
• สรุป
• เอกสารอ้างอิง

1. บทนำ

โครงการ LLVM [1] เป็นพื้นฐานของเครื่องมือการสังเคราะห์ระดับสูง (HLS) แบบโอเพนซอร์สและเชิงพาณิชย์จำนวนมาก [2-7] ซึ่งเครื่องมือเหล่านี้รับผิดชอบในการคอมไพล์โค้ดซอฟต์แวร์ระดับสูงเป็นวงจรระดับถ่ายโอนรีจิสเตอร์ (RTL)

อย่างไรก็ตาม LLVM ไม่ใช่ตัวเลือกที่เหมาะสำหรับเครื่องมือ HLS [8]: IR ของมันไม่สามารถแสดงโครงสร้างวงจรได้อย่างปรับแต่งได้ บังคับให้เครื่องมือ HLS ต้องพัฒนา IR วงจรที่กำหนดเองซึ่งนำกลับมาใช้ใหม่ได้ยาก

MLIR [8,9] สัญญาว่าจะแก้ไขปัญหานี้: มันให้วิธีมาตรฐานในการกำหนด สร้าง วิเคราะห์ และแปลง IR ที่กำหนดเอง (เรียกว่าภาษาถิ่น) ด้วย MLIR นักพัฒนา HLS สามารถก้าวข้ามข้อจำกัดที่แข็งกระด้างของ LLVM IR ได้ ทั้งกำหนด IR ระดับสูงที่สนับสนุนการแปลงระดับสูง และกำหนด IR ระดับต่ำที่มีความหมายวงจรที่แม่นยำ สำหรับ IR ที่กำหนดเอง MLIR ให้อินเทอร์เฟซ C++ เริ่มต้นสำหรับการสร้าง จัดการวัตถุ IR แปลงเป็นข้อความและแยกวิเคราะห์ ซึ่งลดต้นทุนการนำไปใช้อย่างมาก และส่งเสริมการทำงานร่วมกันระหว่างเครื่องมือที่ใช้ MLIR

ในฐานะนักพัฒนาหลักของ Dynamatic [4,5] – เครื่องมือ HLS แบบ MLIR – เรายอมรับและใช้ประโยชน์จากข้อดีข้างต้นของ MLIR อย่างเต็มที่ แต่ในขณะเดียวกัน เราก็พบว่าลักษณะบางอย่างของ MLIR ก่อให้เกิดอุปสรรคในการพัฒนา

บทความนี้มีวัตถุประสงค์เพื่อแบ่งปันปัญหาที่เราพบในการปฏิบัติการพัฒนา MLIR (เวอร์ชัน d8eb4ac) ครอบคลุมการกำหนด IR การวิเคราะห์ การแปลง และการบูรณาการระหว่างโครงการ HLS ที่ใช้ MLIR ที่แตกต่างกัน เราคิดว่าการสังเกตเหล่านี้เป็นสากล ไม่ได้จำกัดเฉพาะโครงการ HLS ที่ใช้ MLIR เท่านั้น เราหวังว่าการค้นพบเหล่านี้จะนำมาซึ่งการคิดและอภิปรายใหม่ให้กับชุมชน MLIR และช่วยให้นักพัฒนาตัดสินใจอย่างสมเหตุสมผลมากขึ้นสำหรับเครื่องมือ HLS ในอนาคต

2. พื้นหลัง

ส่วนนี้แนะนำความรู้พื้นฐานที่เกี่ยวข้องเกี่ยวกับ MLIR และ Dynamatic อย่างสั้นๆ

MLIR [9] เป็นโครงสร้างพื้นฐานคอมไพเลอร์ชุดหนึ่งที่สนับสนุนการกำหนด IR ที่กำหนดเอง (ภาษาถิ่น) และการแปลง Pass IR ประกอบด้วยการดำเนินการ (Operation) ซึ่งจะบริโภคและสร้างค่า (Value)

Dynamatic ใช้สร้างวงจรการไหลของข้อมูล (Dataflow Circuits) [10,11] ซึ่งวงจรเหล่านี้ประกอบด้วยหน่วยการไหลของข้อมูลระดับคำสั่งที่เชื่อมต่อกันผ่านช่องสัญญาณแบบจับมือ; ข้อมูลถูกห่อหุ้มในโทเค็น (Token) และส่งผ่านช่องสัญญาณแบบจับมือ ในวงจรการไหลของข้อมูล การดำเนินการจะดำเนินการทันทีที่อินพุตใช้ได้ ดังนั้น วงจรการจัดตารางเวลาแบบไดนามิกที่สร้างโดย Dynamatic จึงมีข้อได้เปรียบด้านประสิทธิภาพในสถานการณ์ที่รูปแบบการควบคุมการไหลหรือการเข้าถึงหน่วยความจำไม่สามารถคาดเดาได้ [12-14] Dynamatic เป็นคอมไพเลอร์ที่ใช้ MLIR: ในภาษาถิ่นโปรโตคอลจับมือ (Handshake Dialect) เฉพาะ มันแสดงหน่วยการไหลของข้อมูลและช่องสัญญาณเป็นการดำเนินการและค่าของ MLIR ตามลำดับ

Dynamatic ได้พัฒนาจากต้นแบบการวิจัยไปสู่ความสมบูรณ์: มันกลายเป็นพื้นฐานการนำไปใช้สำหรับเอกสารวิชาการจำนวนมาก [11-37] ซึ่งผลงานส่วนใหญ่ได้รวมเข้ากับกระบวนการ HLS หลักแล้ว [11-13,15-16,21-25,28,32] เราได้จัดทำบทช่วยสอนและการแบ่งปันทางเทคนิคที่เกี่ยวข้องในหลายการประชุมทางเทคนิค [5,38] สาขาหลักของ Dynamatic รวมคำขอแบบดึง (PR) ประมาณ 30 รายการต่อเดือน แต่ละ PR จะถูกตรวจสอบผ่านไปป์ไลน์ CI/CD อัตโนมัติ เพื่อหลีกเลี่ยงการแนะนำข้อผิดพลาดในการคอมไพล์หรือการลดลงของประสิทธิภาพ การมีส่วนร่วมของโค้ดจากนักพัฒนาที่มีประสบการณ์น้อยจะได้รับการตรวจสอบและข้อเสนอแนะอย่างละเอียด

3. การสร้างคอมไพเลอร์ HLS แบบ MLIR ในสภาพแวดล้อมทางวิชาการ

เรายอมรับว่าในสถานการณ์ทางวิชาการ การพัฒนาโครงการ HLS บนพื้นฐานของ MLIR มีข้อได้เปรียบอย่างมาก Dynamatic พัฒนาโดยนักพัฒนาที่เป็นนักเรียนเป็นหลัก สมาชิกในทีมส่วนใหญ่มีพื้นหลังด้านวิศวกรรมไฟฟ้า ไม่ใช่นักพัฒนาซอฟต์แวร์มืออาชีพ และโดยปกติไม่คุ้นเคยกับแนวปฏิบัติที่ดีที่สุดทางวิศวกรรมซอฟต์แวร์

MLIR ช่วยเราเอาชนะความท้าทายนี้: มันแสดงให้เห็นอย่างชัดเจนถึงวิธีการทำงานจริงของสถาปัตยกรรมการเขียนโปรแกรมเชิงวัตถุที่ซับซ้อน การออกแบบแบบโมดูลาร์ของมันเป็นแรงบันดาลใจให้เราสร้างเครื่องมือที่เข้าใจง่ายและมีโครงสร้างชัดเจน ข้อได้เปรียบเหล่านี้ทำให้เราสามารถทุ่มเทความพยายามในการพัฒนามากขึ้นให้กับการนำฟังก์ชันการทำงานเฉพาะ HLS ไปใช้

อย่างไรก็ตาม เราก็พบว่าลักษณะบางอย่างของ MLIR ก่อให้เกิดอุปสรรคในการพัฒนาเครื่องมือ HLS ซึ่งจะอธิบายโดยละเอียดด้านล่าง

4. ข้อจำกัดของ MLIR ต่อโครงการ HLS แบบโอเพนซอร์ส และกรณีศึกษาใน Dynamatic

ส่วนนี้กล่าวถึงปัญหาที่เฉพาะเจาะจงที่พบเมื่อสร้างเครื่องมือ HLS Dynamatic บน MLIR

4.1 ค่า MLIR ไม่เหมาะสำหรับการสร้างแบบจำลองขอบกราฟ

การสร้างแบบจำลองการแสดงระดับกลางของซอฟต์แวร์หรือวงจรเป็นกราฟเป็นแนวปฏิบัติทั่วไปในอุตสาหกรรม ในโมเดลดังกล่าว ข้อมูลบางส่วนเป็นของโหนดโดยธรรมชาติ ในขณะที่อีกส่วนเป็นของขอบ MLIR อนุญาตให้เพิ่มคุณสมบัติในการดำเนินการ (โหนด) แต่ไม่สามารถเพิ่มคุณสมบัติใดๆ ให้กับค่า MLIR (Value) ที่แสดงการพึ่งพาการไหลของข้อมูลระหว่างการดำเนินการได้ สิ่งนี้สร้างความท้าทายสำหรับการสังเคราะห์ระดับสูงของฮาร์ดแวร์ที่ต้องการใส่ข้อมูลบนขอบ

กรณีศึกษา 1: การพึ่งพาหน่วยความจำ

มีการพึ่งพาเขียนแล้วอ่าน (RAW) ที่อาจเกิดขึ้นระหว่าง store3 และ load2 ในการวนซ้ำครั้งถัดไป การพึ่งพาประเภทนี้มักได้มาจากการวิเคราะห์ IR ของซอฟต์แวร์ และจำเป็นต้องใส่ระยะการพึ่งพาบนขอบการพึ่งพาระหว่างการดำเนินการจัดเก็บและการโหลด และใช้เป็นข้อจำกัดการจัดตารางเวลา HLS เพื่อให้แน่ใจว่าลำดับการดำเนินการถูกต้อง เนื่องจาก MLIR ไม่อนุญาตให้เพิ่มคำอธิบายประกอบให้กับขอบหรือคู่การดำเนินการ ข้อมูลดังกล่าวสามารถแสดงได้เฉพาะในรูปแบบที่ไม่เป็นมาตรฐานและไม่ชัดเจนเท่านั้น

Dynamatic กำหนดคู่การพึ่งพาการเข้าถึงหน่วยความจำผ่านการวิเคราะห์นามแฝงและการวิเคราะห์แบบโพลีโทป เพื่อรักษาข้อมูลนี้ในกระบวนการ HLS Dynamatic กำหนดชื่อเฉพาะให้กับการดำเนินการแต่ละครั้ง รักษาชื่อนั้นตลอดไปป์ไลน์ HLS และแสดงความสัมพันธ์การพึ่งพาในรูปแบบที่อ่านได้ยาก เพื่อให้แน่ใจในความถูกต้อง จำเป็นต้องตรวจสอบให้แน่ใจว่าการแปลงทั้งหมดไม่ทำลายความถูกต้องของชื่อคู่การดำเนินการ ซึ่งเพิ่มความซับซ้อนและความเสี่ยงต่อข้อผิดพลาดในการนำไปใช้

รูปที่ 1 แสดงส่วนของโปรแกรม C และโค้ด MLIR ที่สอดคล้องกัน ซึ่งแสดงให้เห็นอย่างชัดเจนถึงความยุ่งยากในการใส่ข้อมูลขอบใน MLIR

กรณีศึกษา 2: บันทึกการสร้างโปรไฟล์ประสิทธิภาพซอฟต์แวร์

การสร้างโปรไฟล์ประสิทธิภาพซอฟต์แวร์มักใช้ใน HLS เพื่อกำหนดจำนวนครั้งและลำดับการดำเนินการ (เช่น สำหรับการประเมินประสิทธิภาพเบื้องต้นหรือการปรับแต่งโค้ดที่ดำเนินการบ่อยเป็นพิเศษ) แม้ว่าข้อมูลประเภทนี้จะเป็นของขอบการควบคุมการไหลระหว่างบล็อกพื้นฐานโดยธรรมชาติ แต่ไม่มีวิธีมาตรฐานใน MLIR ในการเพิ่มคำอธิบายประกอบให้กับขอบการควบคุมการไหล

Dynamatic อาศัยการสร้างโปรไฟล์ประสิทธิภาพซอฟต์แวร์เพื่อระบุลูปที่ดำเนินการบ่อยซึ่งจำเป็นต้องได้รับการปรับแต่งเป็นลำดับแรก ข้อมูลนี้สามารถบันทึกบนขอบเอาต์พุตของหน่วยสาขาได้ แต่เนื่องจาก MLIR ไม่สนับสนุนคำอธิบายประกอบค่า Dynamatic จึงสามารถเก็บข้อมูลนี้ได้ผ่านไฟล์ CSV ภายนอกเท่านั้น

หาก MLIR ปรับปรุงการสนับสนุนคำอธิบายประกอบขอบ จะแก้ไขปัญหาประเภทนี้ได้อย่างมีประสิทธิภาพ

4.2 พารามิเตอร์บล็อกสะดวกสำหรับการแปลง HLS หรือไม่?

ในกระบวนการ HLS จำเป็นต้องแปลงการแสดงซอฟต์แวร์เป็นวงจร โดยเฉพาะต้องแปลงโหนด φ ของการกำหนดค่าเดียวแบบคงที่ (SSA) (ซึ่งแสดงการกำหนดค่าตามเงื่อนไข) เป็นมัลติเพล็กเซอร์ ใน MLIR การแปลงนี้เป็นไปตามสัญชาตญาณหรือไม่?

กรณีศึกษา 3: การแปลงพารามิเตอร์บล็อกเป็นมัลติเพล็กเซอร์

รูปที่ 2a แสดงบล็อกพื้นฐานในภาษาถิ่น ControlFlow (ภาษาถิ่นในตัวของ MLIR สำหรับแสดงโปรแกรมแบบอนุกรม): มันเริ่มต้นด้วยตัวระบุ bb1 พร้อมพารามิเตอร์บล็อก (%3, %4) และสิ้นสุดด้วยการแตกแขนงตามเงื่อนไข MLIR ใช้พารามิเตอร์บล็อกประเภทนี้เพื่อแสดงโหนด φ การแสดงนี้มีปัญหาดังต่อไปนี้ในกระบวนการแปลงซอฟต์แวร์เป็นวงจร:
(ก) พารามิเตอร์บล็อกเป็นค่าที่ไม่มีผู้ผลิต
(ข) คำสั่งแตกแขนงรวบรวมค่าเอาต์พุต แต่ค่าเหล่านี้ไม่เกี่ยวข้องโดยตรงกับบล็อกพื้นฐานที่ตามมา

ปัญหาที่หนึ่งทำให้การเขียนใหม่รูปแบบ ยากต่อการปรับให้เข้ากับการแปลงนี้ – เนื่องจากไม่มีดำเนินการที่ตรงกัน ปัญหาที่สองทำให้การระบุตำแหน่งอินพุตของมัลติเพล็กเซอร์ซับซ้อนโดยไม่จำเป็น: ต่างจากโหนด φ ของ LLVM (ซึ่งสามารถรับค่าอินพุตจากบล็อกพื้นฐานอื่นได้โดยตรง) ใน MLIR จำเป็นต้องระบุตำแหน่งบล็อกพื้นฐานหลัก คำสั่งแตกแขนงก่อน แล้วจึงรับค่าอินพุตของการแตกแขนง

Dynamatic ใช้การเขียนใหม่รูปแบบของ MLIR เพื่อทำการแปลงนี้ แต่โซลูชันนี้ไม่ใช่ที่สุด – เนื่องจากการเขียนใหม่จำเป็นต้องทำงานบนฟังก์ชันทั้งหมด ซึ่งขัดกับจุดประสงค์การออกแบบของกฎการเขียนใหม่เฉพาะที่

4.3 เราแก้ไขปัญหาการแตกแยกของซอฟต์แวร์แล้วหรือยัง?

MLIR สัญญาว่าจะแก้ไขปัญหาการแตกแ

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

SCAN TO PAY WITH ANY BANK