doc: Added xlmodel 202510

[xzt777]

添加 xlmodel 202510 文档和图片

---

Important

Updates xlmodel documentation for version 2025.10, adding GDB debugging, flame graph support, new CPU and extension support, and configurable memory settings.

• New Features:
  • Adds GDB debugging and flame graph support in intro.rst.
  • Adds CIDU module and Nuclei systimer support in CLINT mode.
  • Supports SMP ECLIC and new CPUs (Nuclei n300e and 1000 series).
  • Adds extensions: zfinx, zhinx, zhinxmin, zdinx, zimop, zcmop, smaia, ssaia.
  • Configurable memory resource base address and size.
  • Supports setting CPU frequency.
• Documentation:
  • Updates intro.rst to reflect new features and capabilities.
  • Adds details on new command-line parameters and usage examples.
• Known Issues:
  • Does not support CACHE emulation or booting a Linux Kernel.
  • Some SMP cases for RT-Thread and Zephyr not running correctly.

^{This description was created by for acfb43a. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to acfb43a in 3 minutes and 22 seconds. Click for details.

• Reviewed 663 lines of code in 1 files
• Skipped 3 files when reviewing.
• Skipped posting 11 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. source/xlmodel/intro.rst:157

• Draft comment:
  Grammar: change 'xlmodel have been' to 'xlmodel has been' for singular subject.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and focuses on grammar correction. It does not provide a code suggestion or address a potential issue in the code. According to the rules, purely informative comments should be removed.

2. source/xlmodel/intro.rst:663

• Draft comment:
  Typo in the CMake command: 'Rlease' should be 'Release'.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

3. source/xlmodel/intro.rst:38

• Draft comment:
  Verify the image path '/asserts/images/...' is intentional; typically 'assets' is used.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

4. source/xlmodel/intro.rst:38

• Draft comment:
  Typo notice: The image path is currently specified as '/asserts/images/xlmodel/xlmodel_version.png'. If this is meant to refer to assets, please consider changing it to '/assets/images/xlmodel/xlmodel_version.png'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment assumes "asserts" is a typo for "assets", which is a common directory name. However, looking at the full file content, I see multiple other image references that all use "/asserts/" consistently (lines 332, 588, 648). This pattern strongly suggests that "asserts" is the intentional directory name in this project, not a typo. The comment appears to be incorrect because it's making an assumption based on common naming conventions rather than the actual codebase structure. This is speculative and not based on actual evidence of a problem. I might be wrong if this is a new file or section where the directory structure is being changed. Perhaps the other references to "/asserts/" are also typos that should be fixed. However, the consistency across multiple lines suggests this is intentional. The consistency of "/asserts/" across multiple image references throughout the entire file (lines 38, 332, 588, 648) strongly indicates this is the actual directory structure, not a typo. If it were a typo, it would be unlikely to appear consistently in multiple places. The comment is speculative and assumes a problem without evidence. This comment should be deleted. It speculates about a typo without evidence. The path "/asserts/" appears consistently throughout the file in multiple locations, indicating it's the actual directory name used in this project, not a typo for "assets".

5. source/xlmodel/intro.rst:54

• Draft comment:
  On line 54, please verify that 'flashxip' and 'iregion' are spelled as intended. If these terms refer to specific technical acronyms, they might need standardized capitalization (e.g., 'flashXIP' or similar) to maintain consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This comment is asking the author to "verify" spelling and "might need" standardized capitalization. This is speculative and asks the author to confirm their intention rather than pointing out a definite issue. The terms "flashxip" and "iregion" are used consistently throughout the document in lowercase, suggesting they are established technical terms in this codebase. The comment doesn't provide strong evidence that these are misspelled or incorrectly capitalized - it's just asking the author to double-check. According to the rules, comments should not ask the PR author to confirm their intention, verify, or ensure things. This comment violates that rule. Perhaps these terms are indeed non-standard and should be capitalized differently for clarity or consistency with external documentation. The comment might be trying to ensure consistency with industry standards or other parts of the codebase that I cannot see. Even if there might be a capitalization concern, the comment doesn't provide strong evidence or point to a specific standard that should be followed. It's purely asking the author to verify, which is explicitly against the rules. The consistent usage throughout the document suggests these are intentional technical terms. Without concrete evidence of an error, this is not actionable feedback. This comment should be deleted because it asks the author to verify/confirm their spelling choices rather than pointing out a definite issue. The terms are used consistently throughout the document, and the comment provides no strong evidence of an actual problem.

6. source/xlmodel/intro.rst:332

• Draft comment:
  Typo: The image path uses '/asserts/images/xlmodel/demotimer.png'. Did you mean '/assets/images/xlmodel/demotimer.png'?
• Reason this comment was not posted:
  Comment was on unchanged code.

7. source/xlmodel/intro.rst:334

• Draft comment:
  Typographical inconsistency: The text "different riscv extension" might be improved for consistency. Consider using "different RISC-V extensions" to match the later references (e.g. "RISC-V V Extension").
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a stylistic comment about capitalization and pluralization. The comment points out an inconsistency: the line uses "riscv extension" (lowercase, singular) but later references use "RISC-V V Extension" (properly capitalized). While this is technically a valid observation about consistency, I need to consider the rules: 1) Comments should only be kept if there's STRONG EVIDENCE they're correct and useful, 2) The comment is about a change that was made (line 334 is in the diff), 3) This is a very minor stylistic issue that doesn't affect functionality or clarity significantly, 4) The rules say not to comment on things that are "obvious or unimportant". This seems like a minor stylistic preference rather than a clear error. The current text is understandable even if not perfectly consistent. While the inconsistency is real, this is an extremely minor stylistic issue that doesn't impact understanding. The documentation is clear as written. This could be considered an "obvious or unimportant" comment that the rules say to avoid. Additionally, style preferences can be subjective - some documentation might intentionally use lowercase for parameter values. The comment is about a very minor stylistic inconsistency that doesn't affect the clarity or correctness of the documentation. While consistency is generally good, this falls into the category of "obvious or unimportant" changes that the rules explicitly say not to comment on. The documentation is perfectly understandable as written. This comment should be deleted. It's a minor stylistic suggestion about capitalization and pluralization that doesn't significantly impact the documentation's clarity or correctness. This falls under the category of "obvious or unimportant" comments that should not be made according to the review rules.

8. source/xlmodel/intro.rst:371

• Draft comment:
  Typo: There appears to be an extra space in the description. Consider changing "Zfinx Extension" to "Zfinx Extension" for consistency with other rows.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% This is a minor formatting/style comment about spacing in a table. Looking at the actual changes in the diff, lines 371-373 were added as new content (they show the zfinx and zdinx extensions). The comment is technically correct - there are two spaces instead of one. However, I need to check if this is actually about changed code. Looking at the diff markers, these lines with "| zfinx" and "| zdinx" appear to be new additions (they're in the + section of the diff). So this IS about changes made in the diff. The question is whether this is a useful comment - it's pointing out a very minor formatting inconsistency that doesn't affect functionality. According to the rules, I should not comment on things that are "obvious or unimportant." A spacing issue in documentation is quite minor and could be considered unimportant. While the comment is technically correct about the spacing inconsistency, this is an extremely minor formatting issue in documentation that has no functional impact. The rules explicitly state not to make comments that are "obvious or unimportant," and a single extra space in a table cell arguably falls into this category. However, consistency in documentation formatting is valuable for maintainability and professionalism. The comment is actionable, specific, and even provides a suggestion for the fix. It's about new content that was added in this PR, so it's relevant to review. This is a borderline case. The comment is about actual changes (new lines added), is technically correct, and provides an actionable fix. However, it's an extremely minor formatting issue. Given the instruction to err on the side of caution and that formatting consistency has some value, I'll give this a moderate-low score but lean toward deletion since it's quite trivial.

9. source/xlmodel/intro.rst:373

• Draft comment:
  Typo: The description "Zdinx Extension" contains an extra space. Please update it to "Zdinx Extension" for consistent formatting.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% Looking at the table more carefully, I see that lines 365, 367, 371, 373, and 441 all have "Extension" with double spaces before it. This appears to be consistent formatting within the table. In reStructuredText tables, spacing is often used for alignment. The comment assumes this is a typo, but it could be intentional. However, looking at other entries like line 369 "Zfhmin Extension" and line 357 "Zimop extension", these have single spaces. So there IS inconsistency in the table. Some entries have double spaces before "Extension" and others have single spaces. The comment is pointing out one instance of this inconsistency. The comment identifies a spacing inconsistency, but doesn't acknowledge that multiple other entries in the same table have the same issue (lines 365, 367, 371, 441). If this is truly a formatting problem, it affects multiple rows, not just line 373. Additionally, in reStructuredText tables, the actual spacing in the source doesn't always matter for rendering - the table structure is defined by the border characters. While the comment correctly identifies that line 373 has double spacing, this appears to be a pattern affecting multiple entries in the table. The comment singles out one line when it's a broader consistency issue. Moreover, for reStructuredText tables, the visual spacing in the source file may not affect the rendered output. Without seeing the rendered documentation, it's unclear if this is actually a problem. The comment is technically correct about the double space but may not be actionable as stated. The comment identifies a real spacing inconsistency in the table, but this is a minor formatting issue that affects multiple entries, not just the one highlighted. Since this is a documentation file and the spacing inconsistency exists across multiple rows, and since reStructuredText table rendering may not be affected by source spacing, this comment is of marginal value. It's not clearly wrong, but it's also not clearly actionable or important enough to warrant keeping.

10. source/xlmodel/intro.rst:441

• Draft comment:
  Typographical error: There appears to be double spacing in the 'Ssaia Extension' entry. Please change it to 'Ssaia Extension'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a straightforward typographical/formatting comment about double spacing. Looking at the rules: 1) It's clearly about a code change (the line was added in the diff). 2) It's not speculative or asking for confirmation. 3) It's a clear, actionable fix. 4) It's not about something that would be caught by the build. However, I need to check if this is actually an error or intentional formatting. Looking at the table structure, other entries like "Zfh Extension", "Zfa Extension", "Sstc Extension", "Sscofpmf Extension" also appear to have double spacing. This suggests it might be intentional table formatting to maintain column alignment in the RST table format. If the double spacing is consistent with other entries in the same table, then this comment would be incorrect. Looking at the full file context around line 441, I can see other entries in the same table like "Zfh Extension" (line 365), "Zfa Extension" (line 367), "Sstc Extension" (line 445), and "Sscofpmf Extension" (line 443) that also have double spacing. This suggests the double spacing is intentional for table formatting consistency in RST, not a typo. Upon closer inspection of the table, multiple entries have double spacing between the extension name and "Extension", which indicates this is likely intentional formatting for the RST table structure to maintain proper column alignment. The comment appears to be incorrect as it identifies consistent formatting as an error. This comment should be deleted because the double spacing appears to be intentional and consistent with other entries in the same table (e.g., "Zfh Extension", "Zfa Extension", "Sstc Extension"). The formatting is not a typo but rather part of the RST table structure.

11. source/xlmodel/intro.rst:564

• Draft comment:
  Typo: The sentence "You can debug applications running with xlmodel by adding pass the --gdbport=<port_num> parameter." should probably be "by passing the --gdbport=<port_num> parameter." to be grammatically correct.
• Reason this comment was not posted:
  Marked as duplicate.

Workflow ID: wflow_eFgl9aKEaUjGke3F

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}