frgo has quit [Read error: Connection reset by peer]
OwenAnderson[m] has joined #amaranth-lang
<OwenAnderson[m]>
I have a scenario where I want something like a Value-sliceable Array. I have a large, fixed sized bit string and want to pull out a fixed-width window at a dynamic offset from it. For my specific case, I want to pull out a 128 bit slice from a 256 bit string, with offsets at byte boundaries. Any advice on a better way to write this?
<whitequark[cis]>
.word_select()
<whitequark[cis]>
ah hold on, at byte boundaries
<whitequark[cis]>
that would be .bit_select with an offset<<3
<OwenAnderson[m]>
Thank you!
<OwenAnderson[m]>
Hah, Amaranth outsmarted me.
<OwenAnderson[m]>
I'm trying to left-shift a 128b vector by bytes, and was worried that writing the obvious left shift by 8*sh would lead to poor synthesis. So I tried to rewrite it as padding with zeros to a 256b vector and extracting... and Amaranth turned it back into a left shift
<cr1901>
Fails with this error message: "TypeError: mul_tb.<locals>.testbench() missing 1 required positional argument: 's'"
<cr1901>
the iscoroutine check before the simulator starts running fails because of the (accidental!) yield
<cr1901>
So the simulator treats it as a generator function (it is an async generator), and doesn't pass the required sim argument that async testbenches are supposed to have
<whitequark[cis]>
oh
<whitequark[cis]>
please open a bug; we should outright reject async generators
<_whitenotifier-9>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 0fdf254 - Deploying to main from @ amaranth-lang/amaranth@324c37f9faa630fe4efbffd1a9a787f888b3c12c 🚀
<cr1901_>
The diagram looks very nice. W/o having played much w/ DDR buffers: why does e.g. "output A" on o[0] end up on i[1] (i.e. all the outputs end up on the opposite input)? Is that just "how DDR buffers work"?
<whitequark[cis]>
consider this: since you're updating and capturing at the exact same time the capture will always get the previous updated value
<whitequark[cis]>
this creates a shift by ½ cycle
<Wanda[cis]>
<cr1901_> "The diagram looks very nice. W/o..." <- this... is how DDR buffers work unfortunately
<Wanda[cis]>
<del>9 out of 10 vendors agree</del>
<Wanda[cis]>
yeah it tripped me up when I was testing DDRBuffer impls with a logic analyzer and first saw the weird waveforms, but that's an inherent property of that thing
<Wanda[cis]>
if you output something on posedge, you'll capture it on negedge
<Wanda[cis]>
we made this timing diagram specifically to illustrate this fact.
antoinevg[m] has joined #amaranth-lang
<antoinevg[m]>
❤️
balrog has quit [Quit: Bye]
balrog has joined #amaranth-lang
<cr1901_>
Makes sense, unfortunately. So if:
<cr1901_>
1. You're attaching one DDR Output to another DDR input
<cr1901_>
2. You want to send "n" bits, and are using an "output valid" signal clocked on positive edge to the input
<cr1901_>
Your input needs to be n+2 FFs wide to accommodate the garbage beginning and end bit, based on the diagram in the docs?
<cr1901_>
your input shift register/backing store/whatever*
Lord_Nightmare has quit [Ping timeout: 246 seconds]
<cr1901_>
http://gopher.wdj-consulting.com:70/paste/c4e32f60-a95d-4a37-931e-ef223588d388.txt I am trying to wrap an amaranth elaboratable inside another module that adds registers to all input and output ports. With my code as-is, I get a "TypeError: Object None is not an Amaranth statement" error, which doesn't tell me much. What am I doing wrong, and how do I correct this code to late-wrap an Amaranth Elaboratable inside another
<cr1901_>
module?
<cr1901_>
(Answer: I forgot that connect doesn't do the "m.d.sync" part. Still not working, but at least I'm unstuck)
<cr1901_>
which of course also means connect can't do what I want, so I'll have to go the signature.flatten() route. But the path part of the tuple returned by .flatten() iterator is not suitable for getattr
<cr1901_>
so Idk how to programmatically create registers wrapping a component
<tpw_rules>
i should think you also need to add m as a submdoule of w
<tpw_rules>
also m doens't have to be just an Elaboratable, it has to be a wiring.Component
<tpw_rules>
wow typo city
<tpw_rules>
it's kind of unclear what you actually want here and what is going wrong
<cr1901_>
m is a Component, but m.signature.flatten() returns a tuple (path, flow, value). The path is in tuple form. I can't use that with getattr to a wrapper
<tpw_rules>
also usually you want to flipped the self
<cr1901_>
I want to wrap a component m in Registers on the inputs and outputs, so I can pass it to nextpnr to get its max frequency
<tpw_rules>
is connect even defined in a synchronous domain?
<cr1901_>
Check 17:47:35
<cr1901_>
and 17:49:03
<tpw_rules>
i don't follow
<tpw_rules>
in any case there are still other suggestions
<cr1901_>
>is connect even defined in a synchronous domain? <-- No it's not, I forgot that it's not.
<cr1901_>
So connect() won't work
<tpw_rules>
you could use getattr but it would have to be your own recursive resolver. idk if there's anything exposed to chase things down like that
<cr1901_>
I want to programmatically wrap an arbitrary component. It feels like this should be possible with Amaranth as-is today
<cr1901_>
Yea, that's what I was afraid of...
<tpw_rules>
why not just flatten both and zip
<cr1901_>
Is flatten guaranteed to always return in the same order for two different objects with the same signature?
<tpw_rules>
i guess you still need a function to resolve the concrete attribute
<tpw_rules>
otoh you could just create your own two sided interface and do whatever you want in the middle. the names don't have to mean anything. then use connect twice
<tpw_rules>
and let it sort that out
<cr1901_>
I don't follow
<tpw_rules>
never mind, i don't think that actually solves the problem
frgo has joined #amaranth-lang
frgo_ has quit [Read error: Connection reset by peer]
<tpw_rules>
amaranth looks like it uses a private function called _traverse_path
<tpw_rules>
it's not actually recursive, just a loop
<tpw_rules>
but it's only a few lines
<cr1901_>
Looks like flatten takes care of flipping the flow, thankfully