cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #amaranth-lang
jjsuperpower has quit [Remote host closed the connection]
nates93[m] has joined #amaranth-lang
<nates93[m]>
Curious if there's a way to automatically generate documentation (e.g. bit mapped tables) for composed layouts? Something like what's found in the data structures std lib docs:
<whitequark[cis]>
it looks at the stacktrace and reads the source file
<cr1901>
Also, it looks like I have to put it at the top of every single file where I end up with an UnusedElaboratable, not just the relevant test_*.py modules
<cr1901>
(Sorry don't have code to share, right now)
<cr1901>
Just to confirm, this is the intended use- put "# amaranth: UnusedElaboratable=no" in _every_ file that triggers the UnusedElaboratable warning, not just the test_*.py files which trigger the warning?
<cr1901>
OTOH, I only put the msg in my test files, and I still get UnusedElaboratable warnings from pytest (for the modules I import that _don't_ have the annotation). I wonder if it's a pytest vs unittest thing
<whitequark[cis]>
<cr1901> "Just to confirm, this is the..." <- no, in the test file
<cr1901>
Yea, when I do it in the test-file only, I still get UnusedElaboratable warnings. Using pytest. I'll see if I can make a MCVE
<whitequark[cis]>
yeah
<cr1901>
Yea, when I do it in the test-file only, I still get UnusedElaboratable warnings. Using pytest. I'll see if I can make a MCVE
<cr1901>
ignore msg, clicked wrong window
<cr1901>
Cannot duplicate anymore unfortunately. When I checked in all my test files w/ "amaranth: UnusedElaboratable=no" and commited, the warnings were still there. Then I did "git rm" on all but one test file in an attempt to find the bad files. Warnings went away, even after git restore --staged
<cr1901>
must've been a caching problem
<cr1901>
anyways since I can't duplicate, I can't make MCVE, so disregard
<cr1901>
Oooor "git restore --staged" doesn't actually restore the files, and I didn't realize that none of the other test files were put back
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #amaranth-lang
alinaqvi has joined #amaranth-lang
alinaqvi has quit [Client Quit]
<zyp[m]>
Catherine: is there a generic convenient way to make a view on a const? should there be? i.e. `const()` and `__call__()` on a shape castable rolled into one
<whitequark[cis]>
how would that look like?
<zyp[m]>
to take e.g. the RGBLayout example from amaranth.lib.data, picture I want to do something like RGBLayout(5, 6, 5)(RGBLayout(5, 6, 5).const({'green': 4}))
<whitequark[cis]>
it's possible .const should return a View
<zyp[m]>
that's what I did in the code above that does Q(1, self.muln).const(1.8), but I see data.Layout.const() just returns an actual Const
<_whitenotifier-f>
[amaranth] cr1901 opened issue #924: `UnusedElaboratable` message still appearing in `pytest` tests when `xfail(run=False)` marker is used in conjunction with Simulator - https://github.com/amaranth-lang/amaranth/issues/924
<whitequark[cis]>
zyp: is your code still working fine with `Signal`?
<whitequark[cis]>
like Signal(Q(8,8), reset=1.5)
<zyp[m]>
yes
<whitequark[cis]>
sounds like a small RFC clarification is in order, and a change to data.Layout
<whitequark[cis]>
want to do these?
<zyp[m]>
I could
<whitequark[cis]>
thanks!
<zyp[m]>
that'd be a PR directly against RFC 4?
<whitequark[cis]>
yep
<zyp[m]>
no, wait, wrong RFC
mkal has joined #amaranth-lang
<zyp[m]>
RFC 9 is the one that speced .const()
<whitequark[cis]>
yeah
<whitequark[cis]>
sorry
<mkal>
hi all,
<mkal>
I am looking for a jtag (or qspi) to AXI bridge IP to inspect the internals of a test chip. It should have robust tck to axi_clk CDC management. Any suggestions?
<cr1901>
My MCVE w/ xfail might not be the only place the UnusedElaboratable msg still rears it's ugly head, but I need to move onto other things today.
<whitequark[cis]>
mkal: written in Amaranth specifically?
<mkal>
whitequark, not necessarily. I'd take a SV implementation which might be preferable at this point as I haven't started using amaranth fully yet.
<mkal>
If there is a good one in amaranth, I can always netlist to SV and use the result
<whitequark[cis]>
not that I know of--but I wanted to clarify
<zyp[m]>
hmm, I wonder if it's safe to expect the synthesis to simplify a multiplication if I truncate the output, e.g. if I multiply 10 bits by 53 and then truncate it back to 12 bits by discarding the lower 51 bits
<whitequark[cis]>
usually yeas
<zyp[m]>
because I could then implicitly convert a float constant to a perfect fixedpoint representation, do the math, and then just have the subsequent .eq() truncate the result to the required precision without the user having to explicitly state the precision of the constant
<mkal>
synthesis tools trim logic which doesn't get used but make sure that you set expectations right as the cone of logic in a multiplier goes quite a bit deep so you won't save a lot of area after the truncation.
alinaqvi has joined #amaranth-lang
<zyp[m]>
for add/sub, that should certainly be safe to do, and it's always possible to state precision explicitly through Q().const()
<Wanda[cis]>
if you need the top bits, there isn't much to simplify in the first place
<Wanda[cis]>
given how carry chains work on FPGAs, the savings would be proabably exactly 0
alinaqvi has quit [Ping timeout: 245 seconds]
sporniket has joined #amaranth-lang
<cr1901>
I'm trying to create a Gasket class to connect two unlike Interfaces. Because the two interfaces aren't alike, not all signals on both sides will be connected to each other. However, I may add signals to one or both Interfaces being connected. I can see myself very easily forgetting to connect new signals in the gasket via d.comb as I try to converge on a final Layout on both sides. 1/2
<cr1901>
Actually 1/1*. I had a complete thought but lost it :/
<sporniket>
Hello, about silencing UnusedElaboratable warnings, I set _MustUse__silence to True the instance that will not be used (in other word, on a case by case basis, if I understand correctly), like there : https://github.com/sporniket/amaranth-stuff/blob/main/tests/testing/test_Logger.py#L44 because I do not want global silencing in a test suite.
<cr1901>
Hyrum's Law and all that, but I assume that vars with leading underscore by convention are not part of the public API
<whitequark[cis]>
this is basically fine
<whitequark[cis]>
we might eventually just document that or something
<whitequark[cis]>
or add a method to set the private variable
<whitequark[cis]>
I'm not going to break that usage for no reason
<zyp[m]>
<Wanda[cis]> "if you need the top bits..." <- I worked through it, if I need the N top bits of the output, I only need to consider the N top bits of either input, so a 10x53=>top12 multiplication is effectively equivalent to a 10x12=>top12 multiplication
<galibert[m]>
You sure? No lost carry bits coming from the low bits?
<Wanda[cis]>
uh... no?
<Wanda[cis]>
like that's just plain not true
<sporniket>
whitequark[cis] ok :)
sporniket has quit [Quit: Client closed]
<cr1901>
At what point in elaboration does the code run that prints e.g. the UnusedElaboratable warnings? Is it possible for a user to add their own hook or something that will print out User warnings like "hey, you didn't connect these signals in an Interface inside a Gasket, and you didn't specify that you wanted to exclude them". (Basically, a different take on the old Record.connect's exclude parameter)
<zyp[m]>
consider `(0b00001111 * 0x1111) >> 8)`, this is effectively a 8x4=>top4 operation
<zyp[m]>
it's equivalent to `(0b0000 * 0x1111) >> 4)`, which is the equivalent 4x4=>top4
<whitequark[cis]>
cr1901: what are you building this for?
<zyp[m]>
s/0x1111/0b1111/
<zyp[m]>
s/0x1111/0b1111/
<Wanda[cis]>
zyp[m]: cool, now try `(0b11101111 * 0b1110) >> 8`
<zyp[m]>
ah, thanks
<cr1901>
whitequark[cis]: CPU core. Gotta connect ALU to Decoder to Control Unit to Datapath to... etc. 1/2
<whitequark[cis]>
why do you want a gasket with exclude?
<cr1901>
Because I don't need to route the entirity of the Control Unit to the ALU. But I want to still take advantage of connect() and Gasket modules to "hide" the plumbing from the top-level module (so that the top-level is basically "all connects")
<cr1901>
of the Control Unit to the ALU, for instance
<cr1901>
The code isn't public yet, so I can't really give examples
<whitequark[cis]>
why not route the entirety of it?
<whitequark[cis]>
it's not like unused wires cost anything
<whitequark[cis]>
then if something is unused in the ALU it is ... unused in the ALU
<zyp[m]>
by the way, quick bikeshedding question, I'll put this under bikeshedding in the RFC as well, but I want some input on what I'll be using for the draft: which of the two Q notation definitions should we use? ref. https://en.wikipedia.org/wiki/Q_(number_format)
<cr1901>
B/c the ALU doesn't need the entirity of it, and I wanted the Interfaces to reflect the signal subsets which are actually used (also, those signals will show up in "amaranth generate")
<zyp[m]>
TL;DR: is Q(4, 8) 12 or 13 bits total?
<cr1901>
I'm testing size usage of ALU, Decoder, Control, etc via the "amaranth generate" branch. It doesn't actually matter, but I don't want a dozen+ unused port signals
GenTooMan has quit [Ping timeout: 258 seconds]
<galibert[m]>
I’d classify arm as less surprising than ti
<mkal>
Wanda: did you actually code the two options and verify the correctness of the 10x12 multiplication against 10x53 truncated?
<zyp[m]>
I'm inclined to agree, it feels more consistent with everything else
<Wanda[cis]>
mkal: no? it just was the obvious conclusion from how a multiplier is *built*
<galibert[m]>
Also having UQ(8,8) and Q(8,8) be different sizes would be quite error-prone
<cr1901>
>it's not like unused wires cost anything <-- in the synthesized core, no. But me reading the code, I can't tell at a glance which wires in the Control unit interface are used in e.g. the ALU if I route the entire Control Interface into the ALU. Such info being in the Interface is valuable to me when (re)reading code. We might not see the same way on this.
<cr1901>
Anyways, I plan to route subsets, and I'll live w/o exclude. If/when this core is complete and I publish it, you can yell at me then :P.
nelgau has quit [Ping timeout: 255 seconds]
<whitequark[cis]>
cr1901: it might also make sense th split the control interface into several ones
<whitequark[cis]>
e.g. connect(self.control.alu, alu) or something like that
<zyp[m]>
Wanda: however, given that the large operand will be a constant, the particular value might optimize better than the generic case, will synthesis consider that?
nelgau has joined #amaranth-lang
<Wanda[cis]>
ah, now that's an interesting case
<Wanda[cis]>
yosys will definitely shave off bottom 0 bits; other than that, no
<mkal>
Wanda my mistake. I thought you were the one arguing 10x12 == 10x53 truncated
<Wanda[cis]>
actually I wonder if someone researched that
<Wanda[cis]>
probably yes, seems like a common DSP thing?
<Wanda[cis]>
I had my own ideas for some mult-by constant optimizations but they were ... fairly crude and required very particular constants (and I never got around to actually writing that code either)
<zyp[m]>
I figure I'll be constructing the fixedpoint from float.as_integer_ratio() so bottom 0 bits are already gonna be shaved off
<cr1901>
whitequark[cis]: I started that approach. I'll try more splitting and see what happens.
<cr1901>
connect(m, self.alu.ctrl, self.control.alu) <-- My naming uhhh... needs some work ._.
GenTooMan has joined #amaranth-lang
GenTooMan has quit [Ping timeout: 272 seconds]
<adamgreig[m]>
<zyp[m]> "TL;DR: is Q(4, 8) 12 or 13..." <- Aw, I would definitely say 13, I see that usage overwhelmingly
<adamgreig[m]>
like Q15 for a 16-bit signed fraction
<adamgreig[m]>
I guess I agree it's in some sense "surprising" but it's also all I've ever seen or used
<zyp[m]>
yeah, there's definitely gonna be some bikeshedding on that
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
<adamgreig[m]>
I would want Q(15) to make Q(0, 15) too I suppose :p but less fussed about that
cyrozap has joined #amaranth-lang
<adamgreig[m]>
Have you ever seen the arm variant used in the wild?
<zyp[m]>
already implemented
<adamgreig[m]>
These days afaik even arm use the ti version
<adamgreig[m]>
Wikipedia links some arm doc from 2001 as their source for including the sign bit so I'm sure it was indeed once used but I don't think I've ever seen it. Or maybe I have seen it and misunderstood whoever was using it 💀
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #amaranth-lang
Lord_Nightmare has joined #amaranth-lang
mkal has quit [Ping timeout: 245 seconds]
lf has quit [Ping timeout: 240 seconds]
lf has joined #amaranth-lang
<cr1901>
(The following is a bit of a minddump, I'll try my best to make sure it makes sense)
<cr1901>
whitequark[cis]: Splitting signatures into smaller ones _when I can_ is working.
<cr1901>
However, most of my Signatures in this codebase are "all but one member is a port member, and the last one is an interface member.
<cr1901>
E.g. the datapath has adr_r, adr_w, dat_r, dat_w, ctrl. First four are port members, last one is an interface member. This is a logical signature for (part of) a datapath.
<cr1901>
But since, adr_r, adr_w, dat_r, and dat_w all go to different places (dat_w is fed by a mux taking in data from lots of place, dat_r _goes_ to a bunch of muxes all over the place), it's difficult for me to combine them all into an aggregrate interface member that I can connect() anywhere
<cr1901>
In short, _I feel like I'm underutilizing interfaces because I can't readily use connect in a lot of cases. _
<cr1901>
^Finally figured out why it was bothering me