<cr1901>
Well I ported probably the most complex module of my design to Amaranth. Aside from messing up the direction of two signals in the Verilog interface, it worked the first (second) try.
<whitequark[cis]>
these things should probably be signature objects? like SequencerSignature = Signature({ ... })
<whitequark[cis]>
there's no reason to inherit from Signature if you're not adding methods
<cr1901>
Ahhh
<cr1901>
And ot was originally Enum/EnumWithShape. I needed EnumWithShape b/c I needed a zero constant of 16-bits. But when I added my lone test for now, I needed to compare an enum to a signal.
<whitequark[cis]>
there is a downside however
<cr1901>
(So I did a bulk replace Enum => IntEnum)
* cr1901
is listening
<whitequark[cis]>
if you inherit from Signature then your signature becomes incompatible to someone else's signature (unless they special case yours)
<whitequark[cis]>
if you do FooSignature = Signature({ ... }) they are compared structurally
<whitequark[cis]>
re EnumWithShape, can you explain what are you achieving by using from enum import IntEnum at all?
<whitequark[cis]>
i.e. what is the reason you're not using from amaranth.lib.enum import IntEnum in all cases?
<whitequark[cis]>
for code unrelated to Amaranth it works exactly the same as a normal enum
<whitequark[cis]>
or at least intended to; if it doesn't it's a bug
<cr1901>
Ooooh, I didn't realize the shape was optional
<whitequark[cis]>
it is!
<whitequark[cis]>
okay, the doc needs to be improved
<cr1901>
Fixed locally
<cr1901>
>they are compared structurally <-- yea, structural typing (correct term?) instead of nominal seems good to have here
<cr1901>
Yea, it's best to correct this now; I just realized that b/c of Python scoping, I have to change the order of signatures in my source file to avoid undefined names.
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 997370d - Deploying to main from @ amaranth-lang/amaranth@cfd4f9c84e6e7f89f4748434d21551f112704e73 🚀
<cr1901>
Would appreciate comments when you get the chance and I'll get back to them tomorrow night
<whitequark[cis]>
.cmd.cmd?
<cr1901>
In retrospect it should be cmd.name, I didn't change the name yet.
<whitequark[cis]>
I feel like next_state_if_asserted doesn't pull its weight. everyone knows what m.If(): m.next does
<cr1901>
Fair, it was a Verilog task I copied verbatim
<whitequark[cis]>
same for assert_if_just_entered
<whitequark[cis]>
ah right
<whitequark[cis]>
clever use of ** at the beginning
<whitequark[cis]>
I think your Amaranth has improved a lot in the last few months
<cr1901>
Appreciated :). I think it helps that this is a project I enjoy a lot.
<whitequark[cis]>
^^ I'm glad
<cr1901>
And that a working Verilog code already existed (so I can focus on rewriting in Amaranth, and not so much "how does the logic work?")
<cr1901>
Lattice doesn't make it exactly easy to use the MachXO2 internal IP. This started out a Diamond project just to get a feel for how to interface to the EFB, but my intent was always to port it to Amaranth (it lives in the amaranth dir on my machine :P).
<whitequark[cis]>
I see!
<cr1901>
When it's working completely in Amaranth, next plan is to parameterize PageBuffer; it should be useable as a small cache for designs which read from SPI Flashes or anything w/ a page-at-a-time interface.
<cr1901>
So like how AT2XT is my pet project for Rust/something I enjoy, EFButils will be my pet project for Amaranth; it'll evolve as the language evolves :)
<whitequark[cis]>
nice!
<whitequark[cis]>
we will eventually want to have that in, probably, stdio
<galibert[m]>
Do we have examples of dynamically generated interfaces handy? In my case I have the width coming in as a constructor parameter
<whitequark[cis]>
you could inherit from Signature but there are downsides, namely it does not compare equal to any other instance of itself
<whitequark[cis]>
so unless you need to inherit (to define methods) it's better to define a constant or a function
<whitequark[cis]>
that also makes it clear to downstream code that nothing weird is happening in the class
<crzwdjk>
Got it, I'll add that to my todo list of cleanups
<whitequark[cis]>
looks fine to me otherwise!
<crzwdjk>
It needs some tweaks because it barely passes timing now, but otherwise interfaces have really made things much easier
<crzwdjk>
The first time around I tried to make this, there were several times I spent a couple hours wondering why it doesn't work until I found the typo where I wired things up the wrong way around or forgot to connect some signal
<crzwdjk>
I also have an ANSI escape code parser I need to port over. Which btw has something like cr1901's next_state_if_asserted helper except it does a bit more, pulling an item of data from a stream.
<whitequark[cis]>
<crzwdjk> "It needs some tweaks because..." <- I'm really glad to hear it did!
<whitequark[cis]>
I'm also happy to see that people are largely (except for the one thing I highlighted) using interfaces as I intended
<_whitenotifier>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 47c7cf1 - Deploying to main from @ amaranth-lang/amaranth@88cbf3012898e1c42041eefa0ea4bba0d81942e9 🚀
<whitequark[cis]>
so it turns out the logic for flattening a Signature into a list of ports is actually quite not trivial]
<whitequark[cis]>
especially once dimensions get involved