<sb0>
actually a bit less since we use 9914. but the behavior is still mysterious.
<sb0>
TTL output FIFOs are 64 entries deep, one signal transition = one entry
<sb0>
the TTL PulseRate test uses 20k transitions
<sb0>
if you start with an empty DDS FIFO (e.g. right after a board boot), can you sustain programming at 260us without underflow?
<sb0>
s/empty DDS fifo/a system free of whatever corruption the test could cause
<whitequark>
with DDSPulseRate or my test?
<whitequark>
my test returns 260us regardless of basically anything else
<sb0>
the DDSPulseRate logic obviously, since it's the one acting up
<whitequark>
I have never seen it return other values
<whitequark>
mh
<sb0>
reboot the board, and program the DDS some thousand times at 300us intervals
<sb0>
see if you get any underflow
<whitequark>
ok...
<whitequark>
incidentally is it hard to enable ipv6 on the board?
<sb0>
theoretically no, but months of lwip fuckups and annoying debuggings (the last one being ppp) makes me think otherwise
<whitequark>
sb0: ok, you are right
<whitequark>
when ran on a freshly rebooted device the PulseRateDDS test returns about 364us
<GitHub53>
[artiq] whitequark pushed 1 new commit to master: https://git.io/vVfDY
<GitHub53>
artiq/master 42609d0 whitequark: test_pulse_rate_dds: tighten upper bound to 400us.
<whitequark>
sb0: what do we do about slowness?
rohitksingh has quit [Ping timeout: 276 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 252 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 248 seconds]
rohitksingh has joined #m-labs
<sb0>
whitequark, I'd focus on the bug first.
<whitequark>
I have no idea where to even start
<sb0>
I don't really know either.
<whitequark>
wonderful
<whitequark>
is there any API to get the state of FIFOs?
<sb0>
so you just ran the same unittest on a freshly rebooted device, and it gives a reasonable result, whereas if other tests have been run before it, it gives 4.6ms?
<sb0>
I don't know, get more data...
<sb0>
getting the state of an asynchronous FIFO is nontrivial
<whitequark>
is it in its own clock domain or something?
<sb0>
the two ends are in different clock domains
<whitequark>
I see
<sb0>
and anyway - underflow detection happens in the CPU core domain
<whitequark>
hm
<whitequark>
that's actually very weird, I just ran it twice and it doesn't exhibit that behavior
<whitequark>
let's do it another time
<sb0>
there are a number of details there, but all it essentially does is compare the timestamp of the event with the counter
<sb0>
and check if it is sufficiently in the future to make it through the FIFO
<whitequark>
ok. I cannot reproduce the bug.
<whitequark>
after rebooting, I did the exact same sequence as before (as far as I remember, at least) and I get a reasonable value back
<sb0>
did the gateware meet timing?
<whitequark>
always the exact same value, even, down to ns
<whitequark>
hm
<whitequark>
right, so it was reflashed in the meantime