Skip to content

HDL logging wrappers#156

Merged
tilk merged 7 commits intokuznia-rdzeni:masterfrom
awariac:hdl-logs
May 1, 2026
Merged

HDL logging wrappers#156
tilk merged 7 commits intokuznia-rdzeni:masterfrom
awariac:hdl-logs

Conversation

@awariac
Copy link
Copy Markdown
Member

@awariac awariac commented Apr 30, 2026

Module wrappers (similar to Transacti?Component) to enable HDL logging backend, e.g. synthesized to Verilog code (very useful!).

Conversion to Framgent is performed first, because it needs to force elaboration and add all log records to LogKey first.

@tilk
Copy link
Copy Markdown
Member

tilk commented Apr 30, 2026

This is for use with other toolchains when integrating Coreblocks into larger systems?

@tilk
Copy link
Copy Markdown
Member

tilk commented Apr 30, 2026

Are you aware of any way to test this? I'm reluctant to include code not covered by any tests.

@tilk tilk added the enhancement New feature or request label Apr 30, 2026
@awariac
Copy link
Copy Markdown
Member Author

awariac commented Apr 30, 2026

ok, found a way

@awariac
Copy link
Copy Markdown
Member Author

awariac commented Apr 30, 2026

This is for use with other toolchains when integrating Coreblocks into larger systems?

yes, it was useful when debugging Linux boot on Litex, using external Verilator simulation run

@awariac
Copy link
Copy Markdown
Member Author

awariac commented Apr 30, 2026

requires kuznia-rdzeni/amaranth-stubs#14

Comment thread transactron/testing/logging.py Outdated
@tilk
Copy link
Copy Markdown
Member

tilk commented May 1, 2026

requires kuznia-rdzeni/amaranth-stubs#14

Merged and made a new release.

@awariac
Copy link
Copy Markdown
Member Author

awariac commented May 1, 2026

@tilk should stubs be updated to >= requirement instead of ~=?
Repository won't type check otherwise 0.1.3, but it will work. Maybe we should have a strong requirement only in [dev]?

@tilk
Copy link
Copy Markdown
Member

tilk commented May 1, 2026

Why? ~= is the compatible release operator, which is exactly what is needed for semantic versioning to work.

Actually the problem is your changes in amaranth-stubs were not backwards-compatible and I used a wrong version number. Thought you checked that the changes don't break Transactron and Coreblocks, but looks like I was wrong. Please do the checks next time.

@tilk
Copy link
Copy Markdown
Member

tilk commented May 1, 2026

Re-published the new stubs as 0.2.0 and yanked 0.1.3.

Also, I'm thinking of changing the versioning to follow amaranth itself, and add another two numbers for the stubs (so that incompatible stub releases can still be done for a given Amaranth version). I.e. A.A.A.S.S, where A is from Amaranth, and S is from stubs.

@awariac
Copy link
Copy Markdown
Member Author

awariac commented May 1, 2026

would A.A.S.S be enough? Amaranth doesn't do removals on 0.x.{1+} versions.

@tilk
Copy link
Copy Markdown
Member

tilk commented May 1, 2026

would A.A.S.S be enough? Amaranth doesn't do removals on 0.x.{1+} versions.

Right, A.A.S.S should be enough.

@tilk
Copy link
Copy Markdown
Member

tilk commented May 1, 2026

@awariac: I have made two other changes to amaranth-stubs, which make both this code and Coreblocks typecheck correctly again. If you confirm, I will release amaranth-stubs version 0.5.0.0, to match the agreed versioning scheme.

@awariac
Copy link
Copy Markdown
Member Author

awariac commented May 1, 2026

looks like it works

Comment thread pyproject.toml Outdated
@tilk tilk merged commit cdea4c4 into kuznia-rdzeni:master May 1, 2026
4 of 7 checks passed
github-actions Bot pushed a commit that referenced this pull request May 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants