Bug 513 - nmutil.extend.exts not being used in modsw
Summary: nmutil.extend.exts not being used in modsw
Status: RESOLVED FIXED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: PC Linux
: High enhancement
Assignee: Jacob Lifshay
URL:
Depends on:
Blocks: 383
  Show dependency treegraph
 
Reported: 2020-10-06 13:48 BST by Luke Kenneth Casson Leighton
Modified: 2020-10-06 13:57 BST (History)
1 user (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2020-10-06 13:48:37 BST
http://lists.libre-soc.org/pipermail/libre-soc-dev/2020-October/000721.html

reported that it is a nmigen bug that sign-extension is not being respected.
this is technically incorrect.  because nmigen does not have this capability
it is *our* reponsibility to call the utility function nmutil.extend.exts
until such time as nmigen adds the capability to do what nmutil.extend.exts
does.
Comment 1 Luke Kenneth Casson Leighton 2020-10-06 13:50:18 BST
putting the priority up a bit on this one as we're supposed to be under
a functionality code-freeze (bar optional icache/dcache)
Comment 2 Jacob Lifshay 2020-10-06 13:57:48 BST
nmigen totally can sign extend if the lhs of an assignment is a signed Signal, the workaround I previously added passes the tests:
https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=18a56dd9d9b2c1566b460aacb0d9679bac3e4ccf

nmigen's bug was using the lhs signedness instead of the rhs signedness to decide if it should sign or zero extend.