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
futarisIRCcloud has joined #m-labs
kyak has quit [Ping timeout: 268 seconds]
kyak has joined #m-labs
kyak has joined #m-labs
sb000 has joined #m-labs
<sb000>
they are unportable (just like the rest of the clock generator) but I disagree with the other points
<sb000>
why would the fpga be more prone to failure when things are placed by LOC and not by the heuristic placer, assuming static timing analysis passes?
<sb000>
the ethernet loc doesn't interfere with uart, and the rest is under STA
sb000 has quit [Ping timeout: 260 seconds]
kaolpr has quit [Ping timeout: 260 seconds]
kaolpr has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh_work has joined #m-labs
hjr3 has joined #m-labs
hartytp has joined #m-labs
<hartytp>
sb0, rjo: how do we debug the lockups on Sayma?
<hartytp>
in any case, I found that building with _florent_'s latest comit worked fine for me. So, shall we use that to debug the sawg issues? Maybe attach microscope probes to sawg to confirm what the issue is?
<hartytp>
if you give me some advice about how to do that, I can probably have a look at it today...
<rjo>
hartytp: i'll base my work on that ccommit as well.
<rjo>
hartytp: looking at the a1 amplitude would be one useful check. you'll only need one channel (both sawg and probe). that will speed up compilation.
<hartytp>
well, is it useful for me to hook microscope probes up to the sawg amplitudes
<hartytp>
ack
<hartytp>
rjo: is this a helpful thing for me to do?
<hartytp>
if not, I'm more than happy to leave it to you guys!
<rjo>
hartytp: it is useful for someone to do that. if you can spare the time, that would be great. meanwhile i'll review code and do some other checks. with on the sayma in hk.
<hartytp>
okay, will do
<rjo>
too bad that nobody fixed that one to have working ethernet.
<hartytp>
okay, after a few small fixes, that's building
<hartytp>
I'll have a play with it once it's ready
<rjo>
hartytp: the microscope dependency in artiq-dev is un-versioned. you'll need to reinstall the microscope package. i didn't bother increasing its version.
<hartytp>
that's fine, I scrapped the conda version and pulled the latests from git
<rjo>
because they don't form part of the module's interface. i wanted to prevent accidental driving of them.
<hartytp_>
ack
<hartytp_>
will comment that out and then probe
<rjo>
hartytp_: good. add directly the probe in that code. and leave it.
<rjo>
s/ add/ instead don't comment it out and add/
<rjo>
as microscope probes are supposed to be free when not used.
<rjo>
can i log to the uart from kernels?
<hartytp_>
"free when not used"?
<hartytp_>
what determines use?
<hartytp_>
if I add them directly to dsp.sawg, how do I determine a name for them?
<rjo>
used == Microscope submodule exists
<rjo>
i think microscope should figure that out. but this is uncharted territory for me. and microscope is not really documented or has seen a lot of testing in corner cases.
<hartytp_>
right
<hartytp_>
well, I think I'll comment the dels out and hack it
<rjo>
_florent_: before you touch the sayma, please check whether it's is locked by me.
hartytp has quit [Quit: Page closed]
<rjo>
i am narrowing in on the hbf. bypassing it now.
<hartytp_>
good. well, you may have this figured out before I've finished building saym a:(
<rjo>
nope.
<hartytp_>
flashing
<hartytp_>
cool, microscope intersts live
<hartytp_>
now need to flash startup kernel after lunch
<rjo>
hartytp_: you also don't have working ethernet?
<hartytp_>
who do i need it?
<hartytp_>
i don't
<rjo>
it is easier than flashing startup kernels.
<hartytp_>
yes
<hartytp_>
but I don't have it
<hartytp_>
:(
<rjo>
well. i think i have narrowed the issue down to the limiting/saturating adder before the hbf. but i have no idea yeat how that breaks.
<rjo>
and especially not in the weird way it does.
<hartytp_>
okay, so are the microscope tests still useful?
<bb-m-labs>
build #2435 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2435 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<rjo>
hartytp_: yes. if you are about to get them. the exact numbers are.
<hartytp_>
just need to flash a kernel, but lunch first
<rjo>
hartytp_: sure.
rohitksingh_work has quit [Read error: Connection reset by peer]
<bb-m-labs>
build #2436 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2436 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
hartytp has joined #m-labs
<hartytp>
_florent_: looking at [ 0.003881s] INFO(runtime): software version 4.0.dev+1128.g53e9e475 [ 0.010232s] INFO(runtime): gateware version 4.0.dev+1128.g53e9e475
<hartytp>
6 inits, 3 lots of getting stuck in a AMC/RTM serwb init loop
<hartytp>
:(
<_florent_>
hartytp: ah, you regenerated both AMC/RTM?
<hartytp>
so, it seems like it's just serwb on the bugs list for Sayma
<hartytp>
well, that and the fact that and the inexplicable UART silence for some builds
<hartytp>
sb0, re LOCs: I'm not saying that they're responsible for any particular issue we have/have had with Sayma
<hartytp>
but, they do make Vivado complain
<hartytp>
and removing them gets Sayma to pass timing on other Vivado versions
<hartytp>
so, I was just interested to ask if there might be another way of doing this, which might be better?
<hartytp>
I'm curious
<hartytp>
also, how did you choose where to LOC them? Did you just look at where Vivado happened to place them for one particular build and fix them there
<hartytp>
which would be quite fragile
<hartytp>
or is there a good reason for their locations?
<bb-m-labs>
build #2437 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2437 blamelist: Robert J?rdens <rj@m-labs.hk>, Robert J?rdens <rj@quartiq.de>
<GitHub-m-labs>
[artiq] jordens commented on issue #1063: Maybe we don't always exit cleanly on `KeyboardInterrupt`. But even in that case I feel that the harm done by not printing the traceback would be smaller than the annoyance caused by printing it (all the time).... https://github.com/m-labs/artiq/issues/1063#issuecomment-395816730
<GitHub1>
[smoltcp] barskern commented on issue #225: @whitequark @pothos I have now implemented a suggestion which I think will resolve #224 and also improve the detection of duplicate ACKs. Now it should reset the counter when it encounters an ACK which contains data or that changes the send window. Further I implemented more tests to vertify this. https://github.com/m-labs/smoltcp/pull/225#issuecomment-395921670