<GitHub104>
[smoltcp] whitequark commented on pull request #167 ee77812: Why not just `ndisc`? It doesn't matter that it's an option, the protocol is called Neighbor Discovery. Also, you're already dropping `Option` in type names like `NdiscPrefixInfoFlags`. https://github.com/m-labs/smoltcp/pull/167#discussion_r169863783
<GitHub196>
[smoltcp] whitequark commented on pull request #167 ee77812: This seems fine to me, except that returning `Truncated` when the packet is *longer* than expected (i.e. `data_range.end > 32`) is really confusing. https://github.com/m-labs/smoltcp/pull/167#discussion_r169863970
<GitHub128>
[smoltcp] whitequark closed pull request #140: Use separate metadata and payload buffers for UDP sockets (master...socket_buffer) https://github.com/m-labs/smoltcp/pull/140
<GitHub186>
[smoltcp] whitequark commented on issue #166: On top of that, I think you're doing too much at once. I'd like to see the split of EthernetInterface into multiple layers separately from adding routing; either of these is complex enough for many weeks of work, trying to tackle them together is absurd! https://github.com/m-labs/smoltcp/issues/166#issuecomment-367585075
<GitHub71>
[smoltcp] whitequark commented on issue #154: ~~@dlrobertson I think you had an implementation for EthernetRepr, if @canndrew hasn't written one yet, I can probably merge that one.~~ Nevermind, I forgot there's an open PR. https://github.com/m-labs/smoltcp/issues/154#issuecomment-367585306
ohsix has joined #m-labs
<travis-ci>
m-labs/smoltcp#767 (auto - dbaabd7 : Herman J. Radtke III): The build has errored.
<GitHub153>
[artiq] enjoy-digital commented on issue #908: Before suspecting hardware issues, let's make sure the algo is robust enough to select the same values we would choose manually when looking at the scan. I changed the scan deadzone from 16 to 32, it should help. https://github.com/m-labs/artiq/issues/908#issuecomment-367592380
<whitequark>
oh ffs
<whitequark>
of course this comes with a load of annoying conda issues
<sb0>
whitequark, I actually had tried to write the exact same code as you, and was puzzled at how you had solved those problems :)
<travis-ci>
m-labs/smoltcp#769 (master - e114c46 : Herman J. Radtke III): The build passed.
<bb-m-labs>
build #1250 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1250 blamelist: whitequark <whitequark@whitequark.org>, Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs>
build #2088 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2088 blamelist: whitequark <whitequark@whitequark.org>, Sebastien Bourdeauducq <sb@m-labs.hk>
<whitequark>
sb0: well I found a solution now
<sb0>
cjbe, also I reconnected ethernet on kasli
<whitequark>
astounding
<whitequark>
conda automatically builds a missing artiq package, but ONLY if it has already been built
<whitequark>
so it manages to have behavior that is useless *both ways*
rohitksingh has joined #m-labs
<whitequark>
sb0: like I mentioned, I don't think we can or should rewrite conda
<whitequark>
however, I'm gradually warming up to rewriting conda-build
<whitequark>
it's just extremely bad
<sb0>
whitequark, okay, can you open an issue and give detailed enough arguments?
<whitequark>
I've managed to make it work for now
<whitequark>
I'll do that next time it has some inexplicable set of bugs
rohitksingh has quit [Client Quit]
<sb0>
whitequark, also the arguments should target end users
<whitequark>
there's exactly one argument targeting end users: we don't waste any more time fighting conda-build
<whitequark>
since all builds happen on our infrastructure (buildbot) they're isolated from the rest
<whitequark>
sb0: unrelated: did anyone ever try to e.g. take a charged atom, drop it, and catch?
<whitequark>
as a confirmation that the equivalence principle works even if we're talking about single atoms
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
<GitHub191>
[artiq] hartytp commented on issue #908: > Before suspecting hardware issues, let's make sure the algo is robust enough to select the same values we would choose manually when looking at the scan. I changed the scan deadzone from 16 to 32, it should help.... https://github.com/m-labs/artiq/issues/908#issuecomment-367626732
<GitHub95>
[smoltcp] whitequark commented on issue #140: On reflection, I'm really not happy about this code. It's still too complex (there should have been a `dequeue` function as well), too coupled to the UDP socket (this is especially visible in the tests), and there is a bug where enqueueing a packet that's smaller than the window but larger than contiguous window will enqueue padding before bailing out, thus wasting space.
<GitHub36>
artiq/master d4a10dc Robert Jordens: urukul: fix example
<GitHub36>
artiq/master e8d4db1 Robert Jordens: coreanalyzer: add spi2 support...
<sb0>
what, the rj45 sfp doesn't crap out with kc705 on one end and sayma on the other?
<sb0>
surprising
<sb0>
whitequark, rjo are you guys going to use the kc705 or can I leave it connected to the sayma?
<sb0>
note that you can use the kasli for many things
<whitequark>
sb0: I'm using kc705 because that's about the only thing that actually works and is stable
<rjo>
sb0: have it
<whitequark>
also, what about buildbot?
<whitequark>
should we switch that to kasli too?
<sb0>
the kasli is also stable IME
<sb0>
eventually the buildbot should flash and run unittests on both the kc705 and the kasli
<sb0>
whitequark, if you find kasli bugs i'd be interested to know about them
<whitequark>
ok
<whitequark>
there's a problem though
<bb-m-labs>
build #1253 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1253 blamelist: Robert Jordens <rj@m-labs.hk>, Robert Jordens <jordens@gmail.com>
<whitequark>
buildbot runs are already extremely slwow. we can runte tests in parallel but not build gateware.
<bb-m-labs>
build #2091 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2091 blamelist: Robert Jordens <rj@m-labs.hk>, Robert Jordens <jordens@gmail.com>
<sb0>
we can use a second computer to build gateware, buy one and/or use the quartiq one
<marmelada>
rjo: i flashed artiq on our kasli: misoc fails too boot (only first line of logo is shown, with some random characters) and fpga_done led is off
<rjo>
sb0: what's the maximum rate of RTIO output (stb)?
<rjo>
marmelada: what's "our kasli"?
<marmelada>
I checked that openocd properly writes bitstream from my computer
<marmelada>
rjo: last v1.0 board that we have in wut
<rjo>
marmelada: post an issue and attach all pertinent information.
<marmelada>
hmm, so you haven't encountered this...
<rjo>
no.
<marmelada>
perhaps I'm missing something in my setup, is clock on sma required?
<rjo>
no.
<rjo>
build everything, flash everything, and it works has been the experience so far.
<rjo>
i can give you binaries.
hartytp has joined #m-labs
<hartytp>
_florent_ did you have a chance to look at the serwb issues that sb0 raised?
<hartytp>
sb0/rjo: when do you think you'll have Sayma RTM moved to the new SPI core? I'd like to look at the HMC830 again and the new core sounds like a good idea for that
<marmelada>
ok, fpga_done isn't high even when flashed with platform cable
<marmelada>
on the other hand when I try my bitstreams it works
<marmelada>
rjo: i'll try to pull latest code and try again, then I'll post an issue if it doesn't work
<GitHub165>
[smoltcp] whitequark commented on issue #52: There is now a `managed::ManagedMap`. Also, scratch what I said about FIFO buffers, that doesn't sound like a very good idea on reflection. I'm not actually sure what sort of data structure can be used to implement reassembly without fixing MTU upfront or suffering internal fragmentation. https://github.com/m-labs/smoltcp/issues/52#issuecomment-367665841
<travis-ci>
m-labs/smoltcp#774 (master - 21ca116 : whitequark): The build passed.
<GitHub25>
[smoltcp] dlrobertson commented on pull request #167 ee77812: True. This is just the Option parsing, but the actual NDISC parsing will be in `src/wire/icmpv6.rs` per the conversation for #159, so I'll rename it. https://github.com/m-labs/smoltcp/pull/167#discussion_r169944793
<rjo>
hartytp: yeah. he can focus on sayma. that's fine.
<hartytp>
okay. well, if you get to the point where it's an issue for you then feel free to comment on the Sinara issue. Otherwise, I'll leave it until some of the Sayma smoke clears
<hartytp>
yes, Rust seems nice, just finding the time to learn it
rohitksingh has joined #m-labs
<whitequark>
rjo: what do you mean? both of those channels are active on buildbot
<whitequark>
and yes, .condarc is used, and should be correct
<jkeller>
Ah, thanks for letting me know. Do branch and revision just enter as one would naively expect, i.e. --props=package=artiq-board,artiq_target=kc705,artiq_variant=nist_qc2,branch=<branch>,revision=<hash> ?
<cr1901_modern>
rjo: Is openocd gerrit registration disabled or something? I get "invalid token" every time I try adding my email.
* cr1901_modern
tries another email
<cr1901_modern>
Okay nevermind. Must blacklist comcast email addrs or something
<cr1901_modern>
I'll just set a different email for this project
<jkeller>
whitequark: forgot to tag you on the above question: Do branch and revision just enter as one would naively expect in the new syntax, i.e. --props=package=artiq-board,artiq_target=kc705,artiq_variant=nist_qc2,branch=<branch>,revision=<hash> ?
<rjo>
cr1901_modern: fine. but you need to add those to the proxy bitstreams as well.
<rjo>
cr1901_modern: and someone should step up and clean up that fpga/cpld tcl code in openocd and remove the globals.
<GitHub133>
[artiq] hartytp commented on issue #908: @marmeladapk Please can you use @enjoy-digital's patch to do an ARTIQ eye scan with and without SAWG and with both the old and new Exar settings?... https://github.com/m-labs/artiq/issues/908#issuecomment-367741899
<GitHub127>
[artiq] hartytp commented on issue #687: @jordens Novogorny/Novo has been obsoleted by Sampler, so can we rename this in the code as well, please? I would like the naming in ARTIQ to match the front panels/schematics/Wiki! https://github.com/m-labs/artiq/issues/687#issuecomment-367742234
<GitHub144>
[artiq] hartytp commented on issue #687: How much of it do you have? Are you planning to buy more? Are you planning to use Novogorny and Sampler? We can chat about this offline, but since we funded it, I would like to have the driver/docs match the PCB name we chose. https://github.com/m-labs/artiq/issues/687#issuecomment-367743447
<cr1901_modern>
rjo: I'm building them now, but I have no way to test them (other than S750 which is already in your repo). Of course, some of those FPGAs aren't available yet.
<GitHub41>
[artiq] jordens commented on issue #687: We are using two Novogorny v1.0 because we needed them. That means we'll keep it for now. Sampler is different enough to get its own codebase. And since almost everything on that wiki page refers to Novogorny, you may want to rename it back to Novogorny and create a page for Sampler ;)... https://github.com/m-labs/artiq/issues/687#issuecomment-367744091
<GitHub24>
[artiq] jordens commented on issue #687: I don't see the problem with consistency. Novogorny refers to Novogorny v1.0 and Sampler refers to Sampler v1.1. Treat them as different boards (they are). There is no confusion. https://github.com/m-labs/artiq/issues/687#issuecomment-367744447
<GitHub59>
[artiq] jordens commented on issue #687: It's an investment. There is no point in trashing it. And there is very little wrong with Novogorny. And it's just slightl slower (if at all) for non-NU-Servo usage. If there are issues with Sampler then Novogorny will be even more relevant.... https://github.com/m-labs/artiq/issues/687#issuecomment-367747435
<GitHub145>
[artiq] jordens commented on issue #687: I don't see the problem with consistency. Novogorny refers to Novogorny v1.0 and Sampler refers to Sampler v2.0. Treat them as different boards (they are). There is no confusion. https://github.com/m-labs/artiq/issues/687#issuecomment-367744447
<whitequark>
I suggest using --branch/--revision explicitly
<whitequark>
or just try it out
<whitequark>
the "new syntax" is not a buildbot change but rather a build recipe change
<GitHub164>
[artiq] jordens commented on issue #687: I don't think a discussion about "rights" is helpful here. It would involve talking about the right to the photos, to the analysis etc. I also see no reason why you would (or could) demand that we change the name for the code we write for the hardware we use. Especially since it seems like you don't want anything to do with it.... https://github.com/m-labs/artiq/issues/68
<marmelada>
rjo: there's nothing stopping me from importing arbitrary modules in artiq and using them during init and exit (not in kernel), right?
<marmelada>
example: calling usb i2c functions
<rjo>
marmelada: sure.
<rjo>
marmelada: will even work generally from kernels. they will be wrapped in RPCs and called on the host.
<marmelada>
sweet
mumptai has joined #m-labs
<rjo>
... unless the function signature does not play well with the ARTIQ-Python restrictions. i.e. you can't return mutable things like lists or objects.
<rjo>
and other stuff.
<marmelada>
nah, I was just planning to call function which changes i2c switch to eem
<GitHub170>
[artiq] jordens commented on issue #687: IMHO the challenge is content quality and responsibility/accountability. Whether it's a wiki on Github or something else is very much secondary. And is the content is good, the Wiki is a fine platform. https://github.com/m-labs/artiq/issues/687#issuecomment-367775765
<GitHub118>
[artiq] jordens commented on issue #687: I don't think a discussion about "rights" is helpful here. It would involve talking about the right to the photos, to the analysis etc. I also see no reason why you would (or could) demand that we change the name for the code we write for the hardware we use. Especially since it seems like you don't want anything to do with it.... https://github.com/m-labs/artiq/issues/68
<GitHub31>
[artiq] jordens commented on issue #687: The idea of a ARTIQ/Sinara "board"/"council"/"committee" was aired a couple of times. IMHO it's a good idea; it wouldn't be too complicated. And we could take lessons from the governance structure of other projects. Debian and others come to mind.... https://github.com/m-labs/artiq/issues/687#issuecomment-367789577
<hartytp>
sb0: "whitequark, why did you use a Cell here?" that was one of the questions I had earlier on that lead to my "time to learn Rust" comment
<hartytp>
my write pseudocode and hack away until the compiler errors go away approach to rust ran into trouble when I started poking at closures in the SDRAM code
hartytp has quit [Ping timeout: 260 seconds]
<cr1901_modern>
Of course I upgrade to 2017.4.1 and _of course_ it can't find the new devices. Of course not
<cr1901_modern>
Is there any way to tell Vivado to "refresh" the list of devices it thinks is installed on the system?
<larsc>
vivado talks to the hw_server to get access to the devices
<larsc>
which is a separate program
<larsc>
in my expierence it often locks up
<larsc>
killall -9 helps
<GitHub118>
[smoltcp] podhrmic commented on issue #60: Yep, sorry for the delay. I am working now on adding a [seL4](https://sel4.systems/) backend for smoltcp so that should be an interesting addition. Then I should be able to get back to this. But if you want to clean up the stale PR's, I am ok with closing it (the list of merge conflicts is getting longer) and then making a new PR later. Thoughts? https://github.com/m-la
<jbqubit>
.bit build from master for sayma gives error
<jbqubit>
csrs = module.get_csrs()
<jbqubit>
AttributeError: 'Identifier' object has no attribute 'get_csrs'
<jbqubit>
How far back should I pull to get sayma that builds?
<whitequark>
is your misoc and migen up to date
<whitequark>
?
<jbqubit>
Ya, old misoc. Got it to work. Thanks.
<GitHub8>
[artiq] jordens commented on issue #687: @hartytp Exactly. Nobody said that the Novogorny driver would replace the Sampler driver. There is thus no reason to bad-mouth Novogorny or the driver. Claiming that the presence of a Novogorny driver makes Sampler more expensive or the other way around is absurd. And I don't need to remind you that also for Sampler there are a similar number of manual fixes done to the boards. T
<cjbe>
sb0: Kasli-Kasli DRTIO worked for me out of the box
<cjbe>
sb0: I am now looking at latency between master and slave. I have a master output -> master input loop, and a master output -> slave input loop