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
mumptai has quit [Quit: Verlassend]
<sb0>
d_n|a, you are not supposed to modify it (all modifications go through the Notifier directly). so "data" is a bad choice as it doesn't point this out. "data_view" could be okay.
<sb0>
rjo, now == since when? you modified the resets?
<GitHub40>
ionpak/master 8737557 Sebastien Bourdeauducq: remove 1U box from BS vendor from shopping list
attie has quit [Ping timeout: 248 seconds]
attie has joined #m-labs
_whitelogger has joined #m-labs
_whitelogger_ has quit [Remote host closed the connection]
attie has quit [Ping timeout: 248 seconds]
attie has joined #m-labs
mumptai has joined #m-labs
<sb0>
rjo, the kasli 1.1 boots and ethernet and drtio are working, but there is nothing on the serial output. i did built the bitstream with --hw-rev v1.1
<sb0>
rjo, okay. fixed it. it's no longer on the first FTDI UART channel...
<GitHub-m-labs>
misoc/master 0654d33 Florent Kermarrec: sdram_phy/kusddrphy: operate odelaye3/idelaye3 in time mode and output initial dqs delay value on csr to allow reconfiguration
<GitHub-m-labs>
artiq/master 8475c21 Florent Kermarrec: firmware/libboard/sdram: kusddrphy now use time mode for odelaye3/idelaye3, now reloading dqs delay_value (500ps) with software
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #908: I just did some changes to operate the ODELAYE3/IDELAYE3 in "TIME" mode instead of "COUNT" mode. I was using "COUNT" mode since was not able to get the DELAY_VALUE reseted correctly in "TIME" mode but i added a workaround for that. Phase shift between DQ and DQS should now always be guaranted to be 500ps. https://github.com/m-labs/artiq/issues/908#issuecomment-
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: > @hartytp the 1.5V rail supplies both SDRAM and relevant bank of FPGA. So the current consumption is related only with SDRAM transactions. That's why we observe small transients when the memory cycles start. We will measure it once again with the Xilinx IP core tester. Tomorrow I go for a conference, @marmeladapk could you please measure the DC voltage on some cap under
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: > @hartytp the 1.5V rail supplies both SDRAM and relevant bank of FPGA. So the current consumption is related only with SDRAM transactions. That's why we observe small transients when the memory cycles start. We will measure it once again with the Xilinx IP core tester. Tomorrow I go for a conference, @marmeladapk could you please measure the DC voltage on some cap under
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: > I just did some changes to operate the ODELAYE3/IDELAYE3 in "TIME" mode instead of "COUNT" mode. I was using "COUNT" mode since was not able to get the DELAY_VALUE reseted correctly in "TIME" mode but i added a workaround for that. Phase shift between DQ and DQS should now always be guaranted to be 500ps.... https://github.com/m-labs/artiq/issues/908#issuecomment-3
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: @marmeladapk So, the voltage drop with the Xilinx stress test is less than the voltage drop with the M-Labs core at a light load? Or is this just the measurement accuracy?... https://github.com/m-labs/artiq/issues/908#issuecomment-371445191
<GitHub-m-labs>
misoc/master 760097d Florent Kermarrec: sdram_phy/kusddrphy: revert dqs preamble/postamble since not working for continuous transfers, will need a proper implementation
<rjo>
sb0: timing on sayma already fails before the reset changes (fails with b0282fa8). you'll have to do some yak shaving.
<hartytp>
rjo: can you bump misoc in artiq-dev, please?
<hartytp>
I want to try _florent_'s new SDRAM code
<rjo>
hartytp: even though he says it's not working?
<hartytp>
AFAICT, that's just the preamble part
<hartytp>
the COUNT/TIME mode bit seems to work
<hartytp>
(I think from the comments)
<rjo>
instead of changing artiq, i'd uninstall conda misoc and artiq-dev and just use misoc in development mode (pip install -e . in the misoc checkout).
<hartytp>
okay
<rjo>
if you want to switch back to artiq-dev, just pip uninstall misoc and conda install artiq-dev=....
<rjo>
hartytp: or do you have other reasons for using artiq-dev that i don't know about?
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub-m-labs>
[artiq] jordens commented on issue #939: You could also shave off one `rtio_output()`, i.e. one event, by not updating the spi config each time between two writes to the attenuators or the same DDS. But you'd do that in a separate API. https://github.com/m-labs/artiq/issues/939#issuecomment-371521216
<GitHub-m-labs>
[artiq] enjoy-digital commented on issue #908: @hartytp: thanks for the results (even if i was expecting better ones). I need to do more tests with our boards. If you have time, you can test the test bistream i send to see if you have good result with it.... https://github.com/m-labs/artiq/issues/908#issuecomment-371537457
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: @marmeladapk can you do an eye scan using the latest version of ARTIQ/misoc (after Florent's recent patch) and see what it looks like on your board that was giving mem test errors? Otherwise, I'll do it on my board some time tomorrow. https://github.com/m-labs/artiq/issues/908#issuecomment-371548572
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: @enjoy-digital have you checked recently that Sayma is definitely meeting timing with Sawg and that there is nothing suspicious in the Vivado output that could be responsible for this? https://github.com/m-labs/artiq/issues/908#issuecomment-371549298
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: @enjoy-digital I assume it's not related to this, but there are definitely timing violations around the ethmac (IIRC @jordens already pointed that out). ... https://github.com/m-labs/artiq/issues/908#issuecomment-371553239
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #947: (The value we had before was for GTX+62.5MHz clock with a short fiber, which is why we are seeing this problem now with the 150MHz clock) https://github.com/m-labs/artiq/issues/947#issuecomment-371555552
<GitHub31>
[smoltcp] dlrobertson commented on pull request #178 51989ad: I think you mean `IGMP` is not implemented in other address families. Multicast is a requirement for IPv6. See [MLDv2].... https://github.com/m-labs/smoltcp/pull/178#discussion_r173231189
<GitHub127>
[smoltcp] dlrobertson commented on pull request #178 51989ad: multicast addresses are used in IPv6 as well. See: [MLDv2]. The first implementation may only store `IpAddress::Ipv4` variants in this map, but I think the map should contain `IpAddress` instead of `Ipv4Address`.... https://github.com/m-labs/smoltcp/pull/178#discussion_r173230042
rjo1 has quit [Read error: Connection reset by peer]
rohitksingh has quit [Quit: Leaving.]
d_n|a has quit [Remote host closed the connection]
d_n|a has joined #m-labs
<d_n|a>
sb0, rjo: What's your stance on accepting smaller refactorings upstream? I'm currently implementing something for which I need to touch a lot of the sync struct/dataset db code, and I might as well make some changes for clarity and upstream them first (e.g. move "mod" action names into an enum, etc.)
<d_n|a>
(I.e., what I'm asking is whether I should spend the time pulling them out separately, or whether to wait for the big feature PR – which will likely be more controversial than the individual changes.)
sn00n has joined #m-labs
<sn00n>
hi
<mumptai>
hi sn00n
rjo1 has joined #m-labs
<rjo1>
d_n|a: depends on the fallout for the downstream projects like artiq and litex. but generally positive. maybe several of the bigger refactorings could be bundled.
rjo12 has joined #m-labs
rjo1 has quit [Ping timeout: 240 seconds]
attie has quit [Ping timeout: 252 seconds]
attie has joined #m-labs
rjo12 has quit [Quit: AtomicIRC: The nuclear option.]
rjo1 has joined #m-labs
rjo1 has quit [Client Quit]
<GitHub52>
[smoltcp] astro commented on pull request #178 51989ad: Unlike `ip_addrs` (for IPv4) you may join a number of of groups. I didn't want to waste 16 bytes per IPv4 address. My use-case is Embedded Rust. https://github.com/m-labs/smoltcp/pull/178#discussion_r173278115
attie has quit [Remote host closed the connection]
attie has joined #m-labs
<GitHub31>
[smoltcp] dlrobertson commented on pull request #178 51989ad: Yes, it may optimize space for use-cases that are IPv4 only, but for use cases that are IPv4 and IPv6 we then have two `ManagedMap`s one for IPv4 and the other for IPv6. https://github.com/m-labs/smoltcp/pull/178#discussion_r173282596
<GitHub-m-labs>
[artiq] cjbe commented on issue #947: My preference would be for an RTT measurement. As @klickverbot says, links will typically be 2m - 15m, but up to (at least) 30m on occasion. https://github.com/m-labs/artiq/issues/947#issuecomment-371627509
<rjo>
d_n|a: oh. i misunderstood where you are coming from. i think it would be great if you could split them somewhat. especially if you can isolate parts where you are not certain that we all agree yout changes are good.
<d_n|a>
rjo: I'll let them trickle down (erm, up) as I'm finishing things up, then.
<rjo>
d_n|a: but i have no idea what kind of "big feature pr" you have in mind.
<rjo>
d_n|a: just general cleanup with a bunch of knock on effects? or an actual "feature package"
<rjo>
d_n|a: but i suspect we can (or you can) merge stuff pretty quickly if the past changes are indicative...
<d_n|a>
The thing I'm working on is a generic framework for experiments that are multidimensional scans of the same "kernel"/"physical experiment"/… (where parameters, plotting, etc. don't need to be handled manually). I.e. you write the code to acquire a single data point and let the framework handle the rest.
<d_n|a>
The intention is to cover 95% of the common cases, to make work in the lab more agile.
<d_n|a>
For example, when setting up a qubit laser, you quickly put together an experiment that just does a single pulse with parameters for frequency and time, and using pre-existing fragments for cooling/readout/…
<d_n|a>
You then get to run it continuously for alignment, do frequency scans, look at flops, etc. without extra work, but crucially also scan all the other parameters of child fragments, like EIT cooling detuning or whatever
<d_n|a>
The latter (access to all parameters) is really the most important point
<rjo>
d_n|a: yeah. we had discussed something like that in ~2015 or thereabouts but didn't put it on top of the list as it seemed we could get along without. it is really useful.
<d_n|a>
The whole thing is born out of my experience (and prior work) on the Zurich system – I didn't think not having that would be as cumbersome as it is, but for more complex things, constantly having to set up new scan experiments and plots really decreases one's efficiency in the lab, because there is no way to intuitively explore system behaviour.
<d_n|a>
Not sure yet how much of that will be upstream-able, but I suspect most of it if we can agree on the design
<rjo>
d_n|a: yes. feel free to lead the discussion and sketch the implementation.
<rjo>
d_n|a: i'm obviously tainted and have a bunch of ideas and half-baked opinions about how to do it that have emerged over the many years in the labs. i think having a fresh perspective is good.
<rjo>
sb0: i am seeing weird behavior with unexpected RTIO underflows, busy and sequence errors when the idle kernel is evicted in response to a new kernel starting. anything come to mind? if not i'll cut it down to a repro and send it your way.
<d_n|a>
rjo: Not sure whether my perspective qualifies as fresh either, although the fingers on a single hand are still enough to count the number of years in my case. ;)
<d_n|a>
rjo: I'm quite keen on getting something ready soon (i.e. a week or two) for our internal use – we are wasting enough time constantly reinventing this already. I have a design sketched out, although not formally written down. Will post a prototype for comments as soon as I have something to show.
<rjo>
d_n|a: sounds good. i was already itching to sell you on my view but will hold off.
<d_n|a>
rjo: Oh, feel free to try and sell me on your ideas; I don't claim infallibility ;)
AceChen has quit [Ping timeout: 240 seconds]
mumptai has quit [Quit: Verlassend]
d_n|a has quit [Ping timeout: 256 seconds]
d_n|a has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]