frgo has quit [Read error: Connection reset by peer]
frgo has joined #amaranth-lang
frgo has quit [Read error: Connection reset by peer]
frgo_ has joined #amaranth-lang
<whitequark[cis]>
so, i've written a lot of versions of something like divisor: In(8) in many places and... I'm not really happy with it
<whitequark[cis]>
you could make it configurable and now you have to drag two values (one constant, one variable with its width dependent on the former) through half your SoC. or, you could make it fixed-width and now if someone isn't served well by one particular width they get to suffer instead of you
<whitequark[cis]>
I'm wondering if we should standardize on passing around strobe signals in amaranth-soc
<whitequark[cis]>
unlike divisors, strobe signals don't have issues like the one above, the "when does this apply in relation to the transactions?" issue, the "is it safe to change it while the core is running?" issue, and the "what if I don't necessarily know my CPU frequency to properly calculate divisor values at this point in the RTL?" issue
<whitequark[cis]>
(the last one is sidestepped; the strobe-based design more or less forces you to add a timer somewhere, and the hope is that that location will be a better fit for that timer than the peripheral)
<whitequark[cis]>
I suppose it also means you could manually clock the peripheral with a register or something, which seems useful, especially for debugging
zyp[m] has joined #amaranth-lang
<zyp[m]>
the idea is not bad, but not universally applicable; you'd be providing not only a frequency, but also a phase, and you often want to only specify the former and let the consumer control the latter
<zyp[m]>
consider e.g. a UART; a strobe would work fine for the transmitting half, but for the receiving half you want to realign the phase each time you see an edge
<whitequark[cis]>
ah yes
<whitequark[cis]>
so anything that has a phase locked loop inside (which an UART, despite its apparent simplicity, actually does?) would need a divisor
<whitequark[cis]>
and anything that merely needs to pace a stream would be fine with a strobe pulse stream
<zyp[m]>
speaking of streams, the valid signal is effectively a strobe, so one approach would be having a generic pacing block that you can pass a stream of arbitrary shape through
<zyp[m]>
and then downstream of that, just rely on ordinary stream flow control
<whitequark[cis]>
that's the idea
<whitequark[cis]>
there are some subtleties in where you are pacing the stream
<whitequark[cis]>
this has interactions with the way I want to do streams to/from IO pins with the IOStreamer block I'm trialing in Glasgow
<zyp[m]>
I usually do the opposite, where the downstream end of the pipeline do the pacing and the rest rely on backpressure
<whitequark[cis]>
I've tried a few different approaches, and settled on the idea that if you want more than 1 per cycle throughput, you should generate DDR waveforms directly, and then have them down-sampled if you decide to pace the stream
<whitequark[cis]>
but this still has a number of edge cases that are difficult to all cover correctly
<zyp[m]>
I've been meaning to write something that's probably similar to IOStreamer for handling SWD/JTAG in orbtrace
<whitequark[cis]>
would you like to collaborate on having an upstream high-performance JTAG/SWD probe?
<whitequark[cis]>
glasgow and orbtrace could reuse one that would live in amaranth-soc
<whitequark[cis]>
I'm very interested in this
<whitequark[cis]>
err, amaranth-stdio
<whitequark[cis]>
and by "probe" I mean "connects to pins on one side and provides a pair of streams on another"
<zyp[m]>
I want a block that just takes a stream of output bits and provides a stream of captured input bits and takes care of having them shifted out/in at a configured rate so that everything else can just rely on stream flow control
<whitequark[cis]>
right
<whitequark[cis]>
in IOStreamer, pacing is done by the input stream
<whitequark[cis]>
(although you could do this by the output stream, this would have a few cycles of latency)
<whitequark[cis]>
I think we really should have something like IOStreamer be a standard block people can rely on, since reinventing this pattern over and over is going to cause so many error
<whitequark[cis]>
s/error/errors/
<zyp[m]>
my idea was to have the configurable divisor be effectively the max rate, and still allow stream flow control to slow it down
<whitequark[cis]>
yes, that is what I would want as well
<whitequark[cis]>
(it's how IOClocker operates, though IOClocker is a bad design)
<zyp[m]>
I also thought about using DDR registers for improved frequency granularity
<whitequark[cis]>
oh, that's interesting
frgo_ has quit [Read error: Connection reset by peer]