XiangShan – bộ xử lý RISC-V hiệu năng cao mã nguồn mở

 (github.com/OpenXiangShan)
2 điểm bởi GN⁺ 2025-01-04 | 1 bình luận | Chia sẻ qua WhatsApp
  • XiangShan là một dự án mã nguồn mở hướng tới bộ xử lý RISC-V hiệu năng cao, và phiên bản hiện tại Kunminghu đang được phát triển trên nhánh master
  • Tài liệu được công khai tại docs.xiangshan.cc, và tài liệu thiết kế Kunminghu V2R2 cùng hướng dẫn người dùng được cung cấp dưới dạng tài liệu riêng
  • Các vi kiến trúc ổn định gồm Yanqihu và Nanhu, trong đó Yanqihu là vi kiến trúc ổn định đầu tiên được phát triển từ tháng 6 năm 2020
  • Luồng phát triển gồm mã thiết kế Scala, chuyển đổi FIRRTL, hệ con cache, framework đồng mô phỏng difftest, và ảnh mô phỏng dựng sẵn
  • Dự án cung cấp đường chạy tạo Verilog, chạy trình mô phỏng dựa trên Verilator, và chạy xspdb để có thể thực hiện tạo thiết kế và mô phỏng chương trình ngay trong dự án

Tổng quan dự án

  • XiangShan là dự án bộ xử lý RISC-V hiệu năng cao mã nguồn mở
  • Phần mô tả bằng tiếng Trung được cung cấp trong một README riêng
  • Có thể xem tài liệu dự án tại docs.xiangshan.cc
  • Tài liệu thiết kế XiangShan cho Kunminghu V2R2 được công bố riêng tại docs.xiangshan.cc/projects/design
  • Hướng dẫn người dùng XiangShan được cung cấp tại docs.xiangshan.cc/projects/user-guide và XiangShan-User-Guide/releases
  • Việc dịch tài liệu sử dụng Weblate và nhận đóng góp dịch sang tiếng Anh cùng các ngôn ngữ khác
  • Tất cả tài liệu của XiangShan đều theo giấy phép CC-BY-4.0

Bài báo công bố và phương pháp phát triển

  • Bài báo MICRO 2022 “Towards Developing High Performance RISC-V Processors Using Agile Methodology” đề cập đến XiangShan và việc áp dụng phương pháp phát triển agile trong phát triển bộ xử lý RISC-V hiệu năng cao
  • Bài báo trình bày các công cụ được phát triển và sử dụng để tăng tốc quy trình phát triển chip
    • Thiết kế
    • Kiểm chứng chức năng
    • Gỡ lỗi
    • Kiểm chứng hiệu năng
  • Bài báo này đã nhận đủ ba huy hiệu Available, Functional, Reproduced trong đánh giá artifact
  • Liên kết tài liệu:

Các phiên bản vi kiến trúc

  • Vi kiến trúc ổn định đầu tiên là Yanqihu và có tại nhánh yanqihu
    • Được phát triển từ tháng 6 năm 2020
  • Vi kiến trúc ổn định thứ hai là Nanhu và có tại nhánh nanhu
  • Phiên bản hiện tại còn được gọi là Kunminghu và vẫn đang được phát triển trên nhánh master
  • README có kèm sơ đồ tổng quan vi kiến trúc Kunminghu

Cấu trúc kho lưu trữ

  • Các thư mục chính được chia thành mã thiết kế, script phát triển, submodule, cache, đồng mô phỏng và ảnh chạy sẵn
  • src/main/scala: vị trí các tệp thiết kế
    • device: thiết bị ảo dùng cho mô phỏng
    • system: wrapper SoC
    • top: mô-đun cấp cao nhất
    • utils: mã tiện ích
    • xiangshan: mã thiết kế chính
    • xiangshan/transforms: các phép biến đổi FIRRTL hữu ích
  • scripts: script phục vụ phát triển agile
  • yunsuan: submodule yunsuan của XiangShan
  • XSCache: hệ con cache của XiangShan
  • difftest: framework đồng mô phỏng difftest
  • ready-to-run: ảnh mô phỏng dựng sẵn

IDE và tạo Verilog

  • Thiết lập BSP được thực hiện bằng make bsp
  • Thiết lập IDEA được thực hiện bằng make idea
  • Mã Verilog được tạo bằng make verilog
    • Nhiều tệp .sv sẽ được tạo trong thư mục build/rtl/
    • Tệp ví dụ là build/rtl/XSTop.sv
    • Xem thêm thông tin trong Makefile

Chạy mô phỏng

  • Để chạy chương trình bằng mô phỏng, cần các biến môi trường và công cụ phụ thuộc
  • Bước chuẩn bị:
    • Đặt NEMU_HOME thành đường dẫn tuyệt đối của dự án NEMU
    • Đặt NOOP_HOME thành đường dẫn tuyệt đối của dự án XiangShan
    • Đặt AM_HOME thành đường dẫn tuyệt đối của dự án AM
    • Cài đặt mill
    • Sau khi clone dự án, khởi tạo submodule bằng make init
  • Trình mô phỏng dựa trên Verilator:
    • Cần cài đặt Verilator
    • Dùng make emu để build trình mô phỏng C++ dựa trên Verilator ./build/emu
    • Có thể xem tham số chạy tại ./build/emu --help
    • Xem thêm thông tin trong Makefile và verilator.mk
  • Ví dụ chạy:
    • make emu CONFIG=MinimalConfig EMU_THREADS=2 -j10
    • ./build/emu -b 0 -e 0 -i ./ready-to-run/coremark-2-iteration.bin --diff ./ready-to-run/riscv64-nemu-interpreter-so

Đường chạy xspdb

  • Có thể dùng xspdb theo hai cách
  • Bắt đầu nhanh bằng binary dựng sẵn:
    • Không cần biên dịch và có thể chạy chỉ với môi trường Python tiêu chuẩn
    • Cung cấp trải nghiệm XiangShan đầy đủ với mức dùng bộ nhớ thấp
    • Có thể tải XSPdb mới nhất từ phần tóm tắt chạy của workflow Actions trong kho lưu trữ
  • Build từ mã nguồn:
    • Cần cài công cụ kiểm chứng hỗ trợ ngôn ngữ bậc cao picker
    • Dùng make pdb để build binary Python của XiangShan
    • Dùng make pdb-run để chạy binary XiangShan
  • Ví dụ tương tác xspdb bao gồm nạp binary, đặt watchpoint tại commit PC, chạy từng bước theo lệnh, in thông tin PC và chạy đến điểm kết thúc của binary

Khắc phục sự cố, cộng đồng, giấy phép

  • Tài liệu khắc phục sự cố được cung cấp tại Troubleshooting Guide
  • Các kênh liên hệ:
  • Phần hiện thực lấy cảm hứng từ nhiều bài báo cốt lõi, và danh sách bài báo liên quan có trong mục Acknowledgements của tài liệu XiangShan
  • Ghi chú bản quyền bao gồm các tổ chức sau
    • 2020-2025 Institute of Computing Technology, Chinese Academy of Sciences
    • 2021-2025 Beijing Institute of Open Source Chip
    • 2020-2022 Peng Cheng Laboratory
  • XiangShan theo giấy phép Mulan PSL v2

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-01-04
Ý kiến trên Hacker News

  • Nếu muốn thử mô phỏng, có thể dùng Dockerfile tôi đang dùng để tạo môi trường dựa trên Ubuntu 24.04
    Nó clone OpenXiangShan/xs-env, cài công cụ, cài Verilator, khởi tạo XiangShan, build DRAMsim3, build emulator DefaultConfig, rồi build cả ví dụ nexus-am/apps/hello
    Cần 64GB RAM; trường hợp của tôi chạy được bằng cách thêm 48GB swap vào máy có 16GB RAM. Có thể có bước bị lặp, nhưng lần thử gần nhất thì cách này hoạt động

    • Không rõ vì sao nó dùng nhiều bộ nhớ đến vậy

  • Dự án này là dự án đầu tiên thực sự kích thích đầu óc tôi, vì nó tình cờ giao thoa khá lạ với những mối quan tâm gần đây của tôi
    Nhưng chỉ lướt qua rất nhanh thôi tôi cũng đã đồng cảm mạnh với người dùng không nói tiếng Anh. README đủ thân thiện với người nói tiếng Anh, nhưng khi đọc tôi có cảm giác phải liên tục đổi tên token trong đầu để theo kịp, và trong quá trình đó tôi nhận ra hai điều
    Thứ nhất, tôi nhớ ra vì sao mình không thể đọc hết văn học Nga cổ điển: ngay từ đầu đã có một loạt cái tên không thuộc tập tên quen thuộc, khiến tôi lạc đường như bị cache miss
    Thứ hai, có vẻ người nói tiếng Anh không cần đến loại “cơ bắp văn hóa” này nhiều lắm. Vì Trái Đất đã dùng tiếng Anh ở mức nào đó như một ngôn ngữ chung trong thời gian khá dài; tôi cũng nhớ đến câu đùa “gọi người chỉ biết một ngôn ngữ là gì? Người đơn ngữ… đùa thôi, là người Mỹ”
    Có vẻ “những người Mỹ như tôi” có thể duy trì một registry công khai xử lý trước các token trong tài liệu và mã nguồn. Nếu là một registry định nghĩa kiểu DefinitelyTyped thì sẽ rất ngách, nhưng có lẽ khá hữu ích

    • Có một bài viết cho rằng, khi bạn thấy khó chịu vì mình là người đơn ngữ, câu hỏi công bằng hơn không phải là “bạn biết mấy ngôn ngữ”, mà là “trong số các ngôn ngữ được hơn 5 triệu người sử dụng và nằm trong khoảng 1.000 dặm từ nơi bạn sống, bạn biết bao nhiêu phần trăm”
      https://structuredprocrastination.com/light/biling.php

  • https://github.com/OpenXiangShan/XiangShan-doc/blob/main/doc...
    Danh sách lệnh fusion hơi khác thường. Ngoài các mục tương ứng với SH{1,2,3,4}ADD thì phần còn lại tôi không dự đoán được
    Tôi đang xem bằng Google Translate, nhưng kiểu thực thi có điều kiện cho jump ngắn theo phong cách SiFive cũng không thấy ở đó

    • Tôi thắc mắc liệu tổ chức RISC-V có liệt kê hay tài liệu hóa ở đâu đó các chuỗi fusion lệnh được khuyến nghị không
      Wiki kỹ thuật mà họ dùng khá khó duyệt và tìm kiếm, còn các kho GitHub không chính thức cũng chẳng khá hơn mấy, nên thậm chí khó biết là có tồn tại hay không

  • Tôi cũng đã đăng liên kết tới dự án này vài tuần trước; xem những dự án học thuật như thế này thực sự rất thú vị
    Ai quan tâm thì blog hai tuần một lần được liên kết ở đây, và một số bài cũng có bản tiếng Anh: https://docs.xiangshan.cc/zh-cn/latest/blog/

  • Tôi thích việc tên các vi kiến trúc theo chủ đề hồ, như Yanqihu (Hồ Nhạn Thê), Nanhu (Nam Hồ), Kunminghu (Hồ Côn Minh)
    Coffee Lake? Skylake? Không, là Kunming Lake
    https://en.m.wikipedia.org/wiki/List_of_Intel_codenames

  • Cần ghi nhận rằng Trung Quốc đang đạt tiến bộ lớn trong AI, robot học và bộ xử lý, và việc họ công bố rất nhiều phần trong đó dưới dạng nguồn mở cũng rất ấn tượng
    Công việc tuyệt vời và truyền cảm hứng

    • Chẳng phải RISC-V ngay từ đầu đã là phần mềm tự do nguồn mở sao?
    • Bản thân việc nguồn mở hóa rất có thể cũng là một phần của các yếu tố thành công
      Văn hóa Trung Quốc được xây dựng quanh việc tái hiện liên tục và cải tiến dần dần, điều này có thể truy ngược ít nhất tới thời Khổng Tử. Một số người xem đó là sao chép vô tội vạ, nhưng thực ra nó gần với việc học sâu và đứng trên vai người khác hơn
      Thái độ “hãy fork đi” như vậy khá hợp với nguồn mở, nhưng tất nhiên có thể rất gây khó chịu trong chuyện giấy phép sở hữu trí tuệ hay bằng sáng chế
      Tuy nhiên, điều đó không có nghĩa là tính cởi mở này dễ dàng mở rộng ra ngoài Trung Quốc, đặc biệt là ra ngoài phạm vi văn hóa và ngôn ngữ Trung Quốc

  • Có một sản phẩm thương mại dùng kiến trúc Nanhu trước đây của XiangShan. Có vẻ vẫn chưa phát hành, nhưng dù sao cũng thú vị
    https://milkv.io/ja/ruyibook

  • Chiến lược khi công bố thứ này dưới dạng nguồn mở là gì?

    • Họ đã trình bày tại HotChips 2024: https://www.youtube.com/watch?v=4_R0S6piLA0&t=2114s
      Một trong những điều họ nói ở đó là họ muốn RISC-V nói chung, và đặc biệt là core của họ, trở thành nền tảng nghiên cứu học thuật. Khi đó các ý tưởng tiên tiến được chia sẻ công khai và ngành công nghiệp trên toàn cầu hưởng lợi
      Nhìn lạc quan thì đó là mong muốn về một tương lai tốt đẹp hơn cho mọi người; nhìn hoài nghi thì nguồn mở khó bị trừng phạt hay kiểm soát xuất khẩu hơn nhiều. Sự thật có lẽ nằm đâu đó ở giữa
    • Đại học vốn dĩ lúc nào cũng công bố nguồn mở. Tôi cũng công bố nguồn mở mọi thứ làm ở đại học
      Dù sao cũng khó kiếm tiền, và đại học thường cho phép, nên điều đó rất tốt cho CV
      Ở châu Âu cũng có rất nhiều nguồn mở, và nói thật thì chính phủ không âm mưu hủy diệt nước Mỹ. Tôi không xem Linux là kế hoạch của chính phủ Thụy Điển nhằm hủy diệt Mỹ
      Theo kinh nghiệm của tôi, phần lớn người Trung Quốc cũng không mấy bận tâm đến các nước ngoài Trung Quốc, trừ khi họ làm trong ngành thương mại. Trung Quốc quá lớn, ngay cả so với các nước như Mỹ, đến mức có cảm giác họ sống trong bong bóng riêng, và dường như họ cũng không nghĩ về những vấn đề như vậy hằng ngày, thậm chí hằng tháng cũng không
    • Một động cơ khác có thể là làm suy yếu sự thống trị của phương Tây trong thiết kế chip
      Đó là cách phát miễn phí một thứ “đủ tốt” để tấn công hào phòng thủ của đối thủ. Nếu khoảng cách không lớn, nó thậm chí có thể phá hỏng hoạt động kinh doanh của đối thủ
      Việc Apple và các công ty công nghệ lớn tài trợ OpenStreetMap để đối đầu Google Maps cũng có thể nhìn theo cách tương tự. Chỉ riêng việc làm giảm doanh thu của đối thủ đã có giá trị chiến lược
      Việc Satya Nadella nói trong một cuộc phỏng vấn rằng chỉ cần ChatGPT làm tăng chi phí tìm kiếm của Google cũng đã là thắng lợi lớn cho Microsoft cũng cùng mạch suy nghĩ đó
    • Thực tế hơn, nhiều khả năng là một nhóm nội bộ của Viện Hàn lâm Khoa học Trung Quốc muốn có chỉ số ảnh hưởng lớn hơn trong đánh giá, giống như các tổ chức nghiên cứu được nhà nước hỗ trợ ở những nước khác
    • Chiến lược có vẻ gần với quảng bá Trung Quốc, marketing để tăng mức độ chấp nhận, phá vỡ thế lưỡng cực trong chip, thu hút đóng góp, và biến công nghệ thành hàng hóa phổ dụng để miễn nhiễm trước lệnh trừng phạt

  • Thật vui khi thấy một dự án khác dùng Chisel. Tôi tò mò ngành này sẽ đi theo hướng nào
    Có vẻ đã đến lúc Verilog và VHDL bị thay thế. Tôi nhớ một trong hai thứ đó hồi đại học dùng rất khó chịu

    • Tôi thắc mắc điều gì đã thay đổi để giờ được cho là đã đến lúc Verilog và VHDL bị thay thế
      Giáo sư hướng dẫn luận văn cử nhân của tôi đang điều hành một công ty nhằm thay thế Verilog và VHDL, và đã làm việc này hơn 10 năm. Có vẻ vẫn chưa tạo được dấu ấn lớn, nhưng tôi cũng không theo dõi sát lĩnh vực này: https://github.com/clash-lang/clash-compiler
      Cũng có một triển khai RISC-V được viết bằng công cụ này
      Công cụ trong lĩnh vực này quá đắt để xây dựng lẫn kiểm chứng, còn thị trường thì quá nhỏ, nên gần như không thể có thứ gì đó xuất hiện trong một khoảng thời gian hợp lý để đe dọa hệ sinh thái hiện tại