<account[m]>
not strictly legal, they didn't pass that
<account[m]>
but they are in practice overlooking almost everything now
<account[m]>
Rezonit are fucktards
<account[m]>
expensive, long, quality is mid at best
<account[m]>
they outsource half their shit to China because lmao what's a HDI
<account[m]>
s/a/an/
<account[m]>
s/long/slow/
<account[m]>
so if you can find a shop in China that still accepts payment and still ship, order there
<account[m]>
s/ship/ships/
<account[m]>
and, long term advice, ditch Russia
<account[m]>
everyone I know who works electronics either did that, or works in MIC
<account[m]>
sanctions are real, and almost any other country right now is better for developing electronics that Russia is
skipwich_ has joined #glasgow
skipwich has quit [Ping timeout: 252 seconds]
skipwich_ is now known as skipwich
jstein has joined #glasgow
skipwich_ has joined #glasgow
skipwich has quit [Ping timeout: 276 seconds]
skipwich_ is now known as skipwich
skipwich has quit [Remote host closed the connection]
skipwich has joined #glasgow
skipwich has quit [Remote host closed the connection]
skipwich has joined #glasgow
skipwich has quit [Remote host closed the connection]
skipwich has joined #glasgow
andymandias_ has joined #glasgow
andymandias__ has joined #glasgow
andymandias has quit [Ping timeout: 245 seconds]
andymandias__ is now known as andymandias
andymandias_ has quit [Ping timeout: 276 seconds]
q3k[cis] has quit [Quit: Idle timeout reached: 172800s]
andymandias has quit [Read error: Connection reset by peer]
andymandias has joined #glasgow
cr1901_ is now known as cr1901
altracer[m] has quit [Quit: Idle timeout reached: 172800s]
whitequark[m] has quit [Quit: Idle timeout reached: 172800s]
jstein has quit [Ping timeout: 246 seconds]
ali_as7 has joined #glasgow
uartist9 has joined #glasgow
m42uko has joined #glasgow
Lord_Nightmare2 has joined #glasgow
uartist has quit [Quit: Ping timeout (120 seconds)]
ali_as has quit [Quit: Ping timeout (120 seconds)]
m42uko_ has quit [Quit: Leaving.]
Lord_Nightmare has quit [Read error: Connection reset by peer]
ali_as7 is now known as ali_as
uartist9 is now known as uartist
Lord_Nightmare2 is now known as Lord_Nightmare
purdeaandrei[m] has joined #glasgow
<purdeaandrei[m]>
whitequark (@_discord_182174208896401419:catircservices.org) I'm looking at IOStreamer and it seems wrong? I think the latency for FFBuffer should be 1, not 2. According to the docstring the contract is "data captured at the same time as the outputs were updated". But this seems to capture 1 cycle after that.
whitequark[m] has joined #glasgow
<whitequark[m]>
1 cycle for output, 1 cycle for input
<whitequark[m]>
there are tests also
<purdeaandrei[m]>
yeah, the tests seem wrong too. I mean yes, 1 cycle for output and 1 for input, but those happen at the same time
<whitequark[m]>
what?
<purdeaandrei[m]>
For example, if I want to generate a clock signal, and I want to sample a different signal at exactly the same time when the outside view sees the clock edge
<whitequark[m]>
yes, that's how it's used for QSPI
<purdeaandrei[m]>
the internal fpga clock edge that generates the qspi clock edge is the same as the one that causes the input flipflop to sample the signal
<purdeaandrei[m]>
i.e. you don't have to wait for the high clock to be externally visible to sample the input
<whitequark[m]>
sure
<whitequark[m]>
I'm pretty sure I test exactly that case so I'd like to see a reproducer and a vcd
<purdeaandrei[m]>
this is the vcd from the testcase:
<purdeaandrei[m]>
I mean it's changing on the same clock edge, but we want to sample the old value
<purdeaandrei[m]>
cause in real hardware there is an output delay
<whitequark[m]>
I don't follow
<whitequark[m]>
the simulated FFBuffer should act the same as the hardware would
<purdeaandrei[m]>
yes, it does, except the real hardware delays are never actually zero.
<whitequark[m]>
(and I guess if you're right, then either there is another bug, or the simulated flash tests should fail)
<purdeaandrei[m]>
if it only samples 1 cycle later then maybe it is not enough to violate timing
<purdeaandrei[m]>
1 cycle here refer's to the internal FPGA clock
<whitequark[m]>
that doesn't make sense to me
<whitequark[m]>
if you test with a back to back clock pulse train, timings aren't relevant when considering an off by one in the pipeline
<whitequark[m]>
since the relation between the output point and the sample point is the same regardless
<whitequark[m]>
like, if it violates setup or hold timings in one case it does the same in the other
<purdeaandrei[m]>
apologies, I don't actually know what the QSPI test looks like, so maybe I said something that doesn't apply to the theory as to why the qspi test doesn't fail, but I still think iostreamer is wrong
<whitequark[m]>
try fixing it and then reading a QSPI flash
<whitequark[m]>
if it succeeds, good, if it fails, there must be another issue somewhere, or your theory is wrong
<whitequark[m]>
no idea which
<whitequark[m]>
IOStreamer is new so in principle it's possible there is a serious bug in it
<purdeaandrei[m]>
I was assuming the QSPI frequency is slower than the FPGA's 48MHz. So I expected the sample point to be 1000/48 = 20ns later than the ideal, which I expect to not fail
<whitequark[m]>
I tried reading QSPI at 48 MHz
<whitequark[m]>
and at 24 as well
<whitequark[m]>
and also at up to 60, with a PLL
<whitequark[m]>
however the 48 and 60 MHz tests were done in DDR mode
<whitequark[m]>
which has a different latency, with a really weird calculation that I do actually have some questions for
<purdeaandrei[m]>
I haven't thought through DDR mode yet, I mostly ignored it, so I don't know
<whitequark[m]>
it's possible you're right and the 24M clock works by accident
<whitequark[m]>
but the tests for QSPI flash use a sim model for FFBuffer
<whitequark[m]>
if you fix non DDR latency, do they fail?
<whitequark[m]>
should be an easy check if you have the code on hand
<purdeaandrei[m]>
pdm run test tests.gateware.test_qspi right?
<whitequark[m]>
something like that, I usually do -k test_qspu
<purdeaandrei[m]>
those 3 tests pass with a latency of 1 too
<whitequark[m]>
s/-/`-/, s/test_qspu/test_qspi`/
<whitequark[m]>
aha
<whitequark[m]>
okay, now I am leaning towards "there is a bug"
<whitequark[m]>
let me wake up a bit and I'll look at it in depth; thank you for such a careful review!
<purdeaandrei[m]>
now test_iostream fails, but I think the test is wrong
<whitequark[m]>
yeah, that test could be wrong
<whitequark[m]>
I suspect the issue is that the metadata needs to have o+i latency, but the captures only i latency
<whitequark[m]>
and I've implemented them to be the same for both
<whitequark[m]>
that'd actually be miserable to fix if it's that
<purdeaandrei[m]>
in my opinion both should have a latency of 1
<whitequark[m]>
is it because you latch in metadata at the same time as you sample the input?
<purdeaandrei[m]>
yeah, everything happens on the same cycle on which the stream transfer happens
<whitequark[m]>
ok, that sounds sensible
<purdeaandrei[m]>
on the same edge
<purdeaandrei[m]>
the output changes, and the signal is sampled
<whitequark[m]>
yeah, I think you're right
<purdeaandrei[m]>
on the same edge as on which the o_stream transfer happens
<whitequark[m]>
can you prepare a PR with a fix please?
<whitequark[m]>
I'll test SDR mode with a flash to be sure, other than that you've convinced me
<purdeaandrei[m]>
sure, although I don't know about DDR mode
<purdeaandrei[m]>
need to have a think about it
<whitequark[m]>
that can be handled separately
<whitequark[m]>
I found the DDR mode difficult to reason about
<whitequark[m]>
there is a diagram in Amaranth docs that could be helpful
<whitequark[m]>
the problem is that i0 and i1 in effect have different latency
<whitequark[m]>
and this might actually need to be fixed in Amaranth instead
<whitequark[m]>
in Xilinx terms, this is SAME_EDGE vs SAME_EDGE_PIPELINED, iirc
<purdeaandrei[m]>
umm I have no idea what that means 🙂
<whitequark[m]>
oh, I assumed you worked with Xilinx devices before
<purdeaandrei[m]>
I have a spartan devkit somewhere I played around with in the past, but I never got deep enough to know about its ddr buffers
<whitequark[m]>
these are the parameters for ODDR* primitives
<whitequark[m]>
I see
<purdeaandrei[m]>
I'll try to do a testbench to demonstrate the problem