sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<sb0>
whitequark, does your corelog step break release-2 builds further?
<sb0>
whitequark, if you suspect a vivado miscompilation, try building the gateware with ISE (--toolchain ise iirc)
<sb0>
whitequark, try hardcoding a sequence of DMA events after the slicer. then try hardcoding a sequence of SDRAM words before the slicer. that should help narrow down the bug.
<sb0>
bb-m-labs, force build --branch=release-2 artiq
<bb-m-labs>
build #1385 forced
<bb-m-labs>
I'll give a shout when the build finishes
<sb0>
whitequark, also the test should reflect what the users see. and the users won't, and shoiudn't, mess with the log level (unless they are debugging something). so i don't think this is a good solution.
<sb0>
whitequark, also the differences of 24 in rtio_counter look normal. the DMA core does take 3 system clock cycles to perform each transaction (see the FSM in CRIMaster), and 3*8 (fine timestamp) = 24. and by default on the KC705 the RTIO and system clocks are derived from the same oscillator, so it's always exactly 24.
<sb0>
so all those rtio_counter values look fine to me.
hedgeberg|away is now known as hedgeberg
AndChat|326081 has quit [Quit: Bye]
AndChat326081 has joined #m-labs
AndChat|326081 has joined #m-labs
AndChat326081 has quit [Read error: Connection reset by peer]
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep_ has joined #m-labs
AndChat326081 has joined #m-labs
AndChat|326081 has quit [Ping timeout: 260 seconds]
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep_ has joined #m-labs
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined #m-labs
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep_ has joined #m-labs
kuldeep_ has quit [Ping timeout: 260 seconds]
<whitequark>
bb-m-labs: force build artiq
<bb-m-labs>
build #1386 forced
<bb-m-labs>
I'll give a shout when the build finishes
<whitequark>
sb0: I don't see your point about "what the users see"
<sb0>
whitequark, users aren't going to change logging level. if the default logging level results in slow RPCs, then users experience slow RPCs.
<whitequark>
ERROR:HDLCompiler:636 - "/home/whitequark/miniconda/lib/python3.5/site-packages/misoc/cores/mor1kx/verilog/rtl/verilog/mor1kx_ctrl_cappuccino.v" Line 1528: Net <spr_access_ack[7]> is already driven by input port <spr_access_i>.
<sb0>
that's a regression from the mor1kx update
<sb0>
I built it about a month ago because there were weird things with drtio as well
<sb0>
and it was fine
<whitequark>
hm, of course it's related to perfcounters
<whitequark>
rjo: ^
hedgeberg is now known as hedgeberg|away
<sb0>
it looks like a clear bug in mor1kx and it's weird vivado doesn't complain
<sb0>
stekern, ^
<sb0>
I would guess this generate block at the end shouldn't be there
<whitequark>
why shouldn't it?
<whitequark>
ah, I see, it's duplicated with line 1078