<agg>
urgh, heads up that jinja2, which amaranth requires as >=2.11,<3.0 has decided 2.11 is EOL, but it depends on markupsafe >=0.23, which a couple days ago released 2.1, which removes a deprecated function that jinja2 2.11 still uses, breaking an up-to-date and in principle semver-compatible amaranth install
<agg>
it seems like the only option is to pin markupsafe ^2.0 or update amaranth to depend on jinja ^3.0 or >=3,<4 or something
bl0x_ has joined #amaranth-lang
<agg>
python packaging (:
<cr1901>
amaranth uses markupsafe?
<agg>
amaranth uses jinja2
<agg>
to template build scripts
<cr1901>
> but it depends on markupsafe >=0.23, which a couple days ago released 2.1
<cr1901>
I don't understand this line
<agg>
and jinja2 uses markupsafe's soft_unicode method which markupsafe has now removed
<agg>
jinja2 2.11 depends on markupsafe >=0.23
<cr1901>
So, download the last version before 1.0?
<agg>
which is a bad sort of dependency because markupsafe 2.1 is quite a different library and crucially doesn't have soft_unicode any more (which originally lived in jinja2 itself anyway!!!)
<agg>
the last version of markupsafe that works is 2.0, though it gives a deprecation notice
<agg>
this is a bug in jinja2 2.11's dependency specification, because it says it will work with any markupsafe >=0.23, and dependency resolvers like poetry/pip believe it and install markupsafe 2.1
<agg>
but because jinja2 2.11 is EOL they won't fix it
SpaceCoaster has quit [Quit: Bye]
<cr1901>
Oh, 2.1 is "semver-compat" upgrade of 0.23 in pip land
SpaceCoaster has joined #amaranth-lang
<agg>
it's compatible because it's specified as ">=0.23", cargo and I guess anything would treat 2.1 as compatible with that
<agg>
if jinja2 wrote "0.23" or "^0.23" or "<1" or ">=0.23,<2.1" etc they'd all be fine and it wouldn't pick 2.1
<agg>
there's a second trick which is that markupsafe 2.1 bumps to requiring python 2.7 so if your project says it needs to support python 2.6 then the resolver will only select markupsafe 2.0 and everything still works, heh
<agg>
that github issue is a fun gallery of all the projects broken by this in the last 3 days, heh
<cr1901>
cargo patch would save ppl as long as they use all caret deps :P?
<cr1901>
as long as all their downstream deps* use all caret deps* :P?
<agg>
oh, well, amaranth main branch already bumped jinja2 to >=2.11,<4.0, the <3 is just on amaranth 0.3 release
<agg>
so I guess this will stop being an issue on amaranth 0.4 anyway
<cr1901>
Oh dear, I have jinja-2.11 installed
<cr1901>
it seems that pacman -Syu isn't picking up the new package
<cr1901>
I have to supply it explicitly on the command line to get jinja 3.0... wonder why
urja has quit [Read error: Connection reset by peer]
Vonter has joined #amaranth-lang
urja has joined #amaranth-lang
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #amaranth-lang
<d1b2>
<dragonmux> cr1901: did you forbid pacman (in /etc/pacman.conf) from upgrading python-jinja? That's probably the issue
<stevenjl>
I've hit this whilst implementing some fixed point wrapper classes. As an aside, has anyone already implemented some fixed point tools for Amaranth?
emeb_mac has joined #amaranth-lang
<stevenjl>
Actually, it's the same for multiplication etc, so I guess this is just a known unoptimized case? Does anyone have opinions on how easy it would be to change? Operator.operands looks like it could be tested for if something is constant?
<stevenjl>
(Signal(8) * C(2)).shape()
<stevenjl>
Out[26]: unsigned(10)
<stevenjl>
In [27]: (Signal(8) * C(3)).shape()
<stevenjl>
Out[27]: unsigned(10)
<miek>
you can use Signal(x).shift_left(y) for a constant shift
<stevenjl>
ah, I see, thanks!
<stevenjl>
I thought one was an alias for the other. Is there a reason they're different?
<stevenjl>
and is there an equivalent for multiplication by a constant - I don't see one, only bit manipulations
<stevenjl>
adamgreig[m] ah, thanks! Sorry I didn't notice this before spamming the chat! Looks like behavior for multiplication by a constant is the only bit that isn't really documented there.
Vonter has quit [Ping timeout: 240 seconds]
<whitequark>
stevenjl: the behavior of shifts/multiplications by an Amaranth value is intentional; it means that the shape of the result only depends on the shape of the operands, and not their actual values
<whitequark>
the reason shift_left and shift_right exist is because Python doesn't let you shift by a negative amount
Vonter has joined #amaranth-lang
<stevenjl>
whitequark You mean that the design goal is consistency for variable types and constant types? shift_left and shift_right are examples that do take the value into account since they are optimized for constant values. I guess I was wondering if that means there should be a whole set of operations against constant types if you're trying to minimize
<stevenjl>
digit extensions
<Sarayan>
whether one actually *needs* a constant shift operation in a hdl is a question though
<Sarayan>
but it can make things more readable
Vonter has quit [Ping timeout: 256 seconds]
<whitequark>
stevenjl: Const(...) and Signal(...) have the same type: Value
<whitequark>
.shift_left cannot be used with a Const() (or any other Value) argument; only an int
<whitequark>
as for minimizing value extensions: it's typically not an issue that needs solving in the designs I've seen
<whitequark>
what would be the value of e.g. a multiply-by-constant operation?
<stevenjl>
Well, right now I'm implementing some fixed-point logic so I can have an internal representation of an RC decay within the FPGA
<whitequark>
Sarayan: constant shifts and rotates can all be replaced with slice and concat operations
<whitequark>
Sarayan: however, it's more error-prone to do so
<stevenjl>
the RC time constant is known at compile time, as is the time delta
<stevenjl>
so I essentially have a multiplication by a constant at each step
<stevenjl>
I guess I imagined that multiplication by a constant would be significantly cheaper when synthesized, but perhaps that isn't the case
<whitequark>
there's no difference between the cost of `v.shift_left(n)` and `v << n` where `n: int`
<stevenjl>
I'm not talking about shifts
<stevenjl>
and even for shifts, there is no cost to the shift but if you then use that result in a multiplication, you may end up multiplying more bits
<whitequark>
what is a multiplication if not a sum of shifts?
<whitequark>
what I mean is: even if you had a `v.multiply(n)` operation that takes a constant `n`, the cost would be the same as `v * n`
<stevenjl>
let me make an example to prove myself wrong or offer for discussion. One sec!
<whitequark>
both cases would emit very similar RTL, with only the widths of intermediates being different; and would synthesize similarly in the end
<lofty>
At least for Yosys, ISTR multiplies are implemented as shift-and-add anyway
<lofty>
So where there's a 0 bit in the constant, that particular add is pruned
<stevenjl>
I wouldn't imagine yosys can prune the consequences of these bit extensions can it? Such as:
<stevenjl>
In [21]: (Signal(8) * (Signal(8).shift_left(16))).shape()
<stevenjl>
Out[21]: unsigned(32)
<stevenjl>
In [22]: (Signal(8) * (Signal(8) << C(16))).shape()
<stevenjl>
Out[22]: unsigned(47)
<lofty>
(tbh I think Yosys needs to map multiplies differently for ASICs; I can't imagine shift and add compares to like a Dadda tree)
<lofty>
I'm pretty sure it could.
<whitequark>
I would be surprised if these two snippets do not translate to the same RTL on any supported platform, not just with Yosys
<lofty>
Well, Yosys is the one I know
<lofty>
But me too, honestly
<stevenjl>
interesting - so it would basically be like the upper bits of that 47 bit signal being constant 0's or something?
<lofty>
Quite likely.
<stevenjl>
I'm pretty new to FPGA and am still learning here, thanks for humoring me!
<lofty>
I think it's important to note that while Amaranth semantics are never wrong (to my knowledge), they can overestimate the actual width of a signal sometimes.
<lofty>
e.g. The example of `(Signal(8) << C(31, 32)).shape()`
<lofty>
(yes, I know Amaranth would warn here)
<modwizcode>
Does it actually warn? At what stage?
<whitequark>
it warns about a shift by a 32-bit value
<lofty>
Output to RTLIL, IIRC
<modwizcode>
Right that will be a warning.
bvernoux has quit [Read error: Connection reset by peer]
<whitequark>
it's actually an error: `OverflowError: Wire created at <stdin>:1 is 4294967303 bits wide, which is unlikely to synthesize correctly`
<d1b2>
<Lofty> I need to update my IRC bouncer cert. Since I'm on my desktop, I'll use the 1b2 bridge