Skip to content

Add support for signed/fixed-point fields#55

Draft
darsor wants to merge 3 commits into
SystemRDL:mainfrom
darsor:dev/signed-fixedpoint
Draft

Add support for signed/fixed-point fields#55
darsor wants to merge 3 commits into
SystemRDL:mainfrom
darsor:dev/signed-fixedpoint

Conversation

@darsor
Copy link
Copy Markdown
Member

@darsor darsor commented May 17, 2025

Description of change

Add support for the is_signed, intwidth, and fracwidth properties as discussed in SystemRDL/#188.

Example interactive fixedpoint/signed fields

This is an initial implementation. I don't claim that all the edge cases are handled (though I'm not aware of any that aren't) or that the output looks great. I also don't know any javascript so Copilot helped out quite a bit.

List of changes:

  • Added is_signed, fracwidth, and intwidth UDPs (implementation copied from PeakRDL-regblock)
  • Added "R" (Real) radix for fixed-point fields
  • The "D" radix field values are parsed/displayed as signed for signed fields
  • The "D" radix is the default radix for signed fields
  • The "R" radix is the default radix for fixed-point fields
  • Out-of-bounds parsed field values for all radices are clamped to the nearest valid field value for the register value
    • This behavior makes sense for numeric fields, but may not be what you want for everything
  • Added field value display below the entry box for signed/fixedpoint fields

TODO (but need feedback/discussion before implementing):

  • Find an appealing way to include signed/fixedpoint information in the table of fields. Where's the most appropriate place?
  • Documentation. Likely all in the turbo encabulator example regfile?
  • Discuss if the new saturation behavior is appropriate for all fields
  • Look at arbitrary-precision real-number libraries. Currently using Javascript's 64-bit floats, which are good up to at least 53-bit fixed-point numbers
  • Test more edge cases

Basically I'm looking for feedback to make sure this is a good approach before polishing it all up. I could also use some direction on the aesthetic choices (does the current implementation look OK? How can we add more information to the table without cluttering it up?).

@darsor darsor marked this pull request as draft May 17, 2025 03:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant