03:05 <mtrbot-ml> [mattermost] <sb10q> @hartytp FYI I'm not getting any clock to the FPGA from the si549. Might be a software problem, might also want to be careful there before making more PCBs with the same potential hardware problem

03:06 <mtrbot-ml> [mattermost] <sb10q> Do you have any saymas?

03:48 <mtrbot-ml> [mattermost] <sb10q> @rjo https://git.m-labs.hk/M-Labs/nix-scripts/commit/ddaaaa543bed8d2f0627dab080220c32459823fa

08:36 <mtrbot-ml> [mattermost] <sb10q> and you broke suservo on other variants: https://nixbld.m-labs.hk/build/25056/nixlog/1

09:55 <mtrbot-ml> [mattermost] <hartytp> @sb10q nope I still don’t have any saymas

09:55 <mtrbot-ml> [mattermost] <hartytp> Have you checked he supply voltages and oe for the 549?

09:55 <mtrbot-ml> [mattermost] <hartytp> It’s a pretty simple chip which we’ve used a lot on eval boards

09:56 <mtrbot-ml> [mattermost] <hartytp> If it has power, i2c and oe it should work so most likely a sw issue

10:00 <mtrbot-ml> [mattermost] <sb10q> it's not simple, there's this whole cmos/lvds adaptation trick

10:00 <mtrbot-ml> [mattermost] <sb10q> and no I didn't probe signals, I need to take the board out of the rack without front panel, risk of breakage, etc.

10:30 <rjo> sb: that's already fixed.

11:21 <adamgreig> whitequark: with pysim2 i'm missing a lot of input signals in the vcd output, even if they're explictly listed in write_Vcd, any ideas?

11:24 <adamgreig> for instance my module has a self.valid signal, it's combinatorially connected to fifo.w_en, but the vcd doesn't have top.valid or fifo.w_en signals, all I see are output signals

11:28 <adamgreig> in fact I don't think I see anything not written to from within the module, i.e. all inputs missing except clk and rst

11:51 <adamgreig> ...as far as I can tell, the traces argument to write_vcd actually doesn't get used anywhere?

12:09 <adamgreig> i haven't fully grokked the pysim source but it seems like only signals driven from the fragment initially given to Simulator get added to signal_names, and only things in signal_names get written to vcd; signals driven by processes added later don't seem to ever get added

12:27 <_whitenotifier-5> [nmigen-boards] zignig closed pull request #36: Flashmap - https://git.io/Je1nc

12:27 <rjo> Did anybody try ARTIQ on nix on wsl on Windows yet? Or ARTIQ on nix on Ubuntu on wsl on Windows. Those stacks may or may not be relatively easy to manage. Microsoft provides everything up to ubuntu.

12:34 <mtrbot-ml> [mattermost] <sb10q> I tried last year, it was difficult to install, slow, buggy and with very bad GUI support (needs a X server which makes the three issues worse)

12:35 <mtrbot-ml> [mattermost] <sb10q> WSL2 might be better on the slowness/bugginess front

12:36 <mtrbot-ml> [mattermost] <sb10q> That's why i'm still bothering with conda at all...

12:47 <_whitenotifier-5> [nmigen-boards] whitequark commented on pull request #36: Flashmap - https://git.io/JeMNn

12:50 <mtrbot-ml> [mattermost] <sb10q> Anyway I have a plan to build the conda binary windows packages (llvm etc.) with nix, including automated installs of visual studio and other dependencies

12:52 <mtrbot-ml> [mattermost] <sb10q> When run in sandboxes or VMs in snapshot mode, and with total control of conda channel contents, conda can't do much damage anymore

13:45 <airwoodix> Hello. When using nix to install the artiq tools, I get a conflict between python3.7-sip-4.19.18/.../sipconfig.py and python3.7-PyQt5.sip-4.19.18/.../sipconfig.py. This disappears when removing matplotlib (with Qt5 enabled as shown in the manual). Can anyone reproduce this? Is there a know fix (besides manually deleting python-sip from the nix

13:45 <airwoodix> store)?

14:52 <mtrbot-ml> [mattermost] <bradb> @sb10q Hi, I could use some help. Now that ARTIQ release 5 is out, we're going to stop using my personal fork and move over to the official repository. Up until this point, I've been building most of the ARTIQ packages in Hydra, and was able to add our packages (which depend on ARTIQ) with ease since I had access to a local build of ARTIQ. But now, there's no point in building AR <message clipped>

14:54 <mtrbot-ml> [mattermost] <sb10q> airwoodix: please share exact command/.nix file you used to create the problem

14:56 <mtrbot-ml> [mattermost] <sb10q> and deleting python-sip from the nix store manually will result in a corrupted store that can cause problems later on

14:57 <mtrbot-ml> [mattermost] <sb10q> and deleting it cleanly will cause it to be restored when you run the problematic command again

14:57 <mtrbot-ml> [mattermost] <sb10q> @bradb I would try using the channel expressions .tar.xz as a URL input

14:58 <mtrbot-ml> [mattermost] <sb10q> and set up nixbld.m-labs.hk as a binary substituter, and set useSubstitutes = true in your hydra install

14:59 <mtrbot-ml> [mattermost] <bradb> Ah, hadn't thought of that, thanks! Will give it a try and let you know.

14:59 <mtrbot-ml> [mattermost] <sb10q> "previous hydra build", I'm not sure what this does, maybe it's the right thing maybe not. you'd need to read the hydra sources to find out

15:00 <mtrbot-ml> [mattermost] <bradb> Yeah, I tried looking around in the Hydra source yesterday, but couldn't find the relevant file(s)

15:00 <mtrbot-ml> [mattermost] <sb10q> could be some perl source in "plugins"

15:02 <mtrbot-ml> [mattermost] <bradb> I'll check it out if I can't get the tarball method to work. Also, for setting up nixbld as a binary substituter, that's achieved by adding nixbld.m-labs.hk to nix.binaryCaches and the appropriate key to nix.binaryCachePublicKeys in my configuration.nix, right?

15:03 <mtrbot-ml> [mattermost] <bradb> Or do I need to do something extra for hydra to have access to those?

15:04 <mtrbot-ml> [mattermost] <sb10q> nothing extra, just useSubstitutes = true

15:05 <mtrbot-ml> [mattermost] <bradb> Okay cool, I've already got that set up properly then

15:09 <mtrbot-ml> [mattermost] <bradb> Hm, I don't see anything URL-related in the "Type" dropdown box for the hydra input

15:33 <mtrbot-ml> [mattermost] <bradb> Should I just pass the URL as a string and use curl in my top-level .nix file?

15:36 <mtrbot-ml> [mattermost] <sb10q> that won't work, you can't access the network in those .nix files unless you use fixed-output derivations

15:36 <mtrbot-ml> [mattermost] <sb10q> isn't it called "tarball" or something like that?

15:36 <mtrbot-ml> [mattermost] <bradb> Also I found the hydra source relating to fetching previous builds (https://github.com/NixOS/hydra/blob/45f8a0ef66699dcdb43418b419a244bdf6e1567d/src/script/hydra-eval-jobset) and as far as I can tell it doesn't support using another hydra build server. I think it just searches the local $db similar to the sysbuild option

15:36 <mtrbot-ml> [mattermost] <sb10q> I think that can take a remote URL

15:38 <mtrbot-ml> [mattermost] <bradb> I don't see a tarball option. Could it not be showing up for me for some reason?

15:40 <mtrbot-ml> [mattermost] <sb10q> try "nix expression" and then builtins.fetchTarball

15:40 <mtrbot-ml> [mattermost] <sb10q> it's surprising that the "hydra build" option doesn't support remote systems when there's another "hydra build (same system)" option

15:42 <mtrbot-ml> [mattermost] <bradb> Yeah, I'm not entirely sure what the difference is. It doesn't help that my ability to understand perl is pretty limited. But I don't see anything that looks like uri resolving. Just searching the db in a slightly different way as the "same system" option

15:44 <mtrbot-ml> [mattermost] <bradb> But also, I just noticed that the latest commit (circa 2013) for the PathInput plugin has the message "Add support for fetching URLs as inputs." so maybe that would work?

15:44 <mtrbot-ml> [mattermost] <sb10q> yes, maybe

15:44 <mtrbot-ml> [mattermost] <sb10q> try it

15:45 <mtrbot-ml> [mattermost] <bradb> Will do

15:48 <mtrbot-ml> [mattermost] <bradb> It appears to be fetching properly. I'm getting an evaluation error because I haven't changed any of the corresponding nix files, but the error is post-fetching, so I think it works

16:18 <mtrbot-ml> [mattermost] <bradb> Okay, everything appears to be working! The builds are successful, anyway. We'll see if I run into any issues when I try to do gateware builds

16:22 <mtrbot-ml> [mattermost] <bradb> Do you know if there's a way I can use the tarball from the latest build? The URL for the channel expression tarball is specific to the current build

17:35 <_whitenotifier-5> [nmigen] mwkmwkmwk opened pull request #279: hdl.ast: Fix width for unary minus operator on signed argument. - https://git.io/JeDft

17:52 <_whitenotifier-5> [nmigen] Failure. The Travis CI build failed - https://travis-ci.org/m-labs/nmigen/builds/620235258?utm_source=github_status&utm_medium=notification

18:02 <ZirconiumX> mwk: You broke it :P

18:05 <mwk> right

18:05 <mwk> obvious test is obvious

18:07 <ZirconiumX> More generally this has the fun implication that 0 != -0.

18:07 <ZirconiumX> Or, well, "not identical to"

18:09 <ZirconiumX> mwk: They seem to be dragged in by `python3 setup.py develop`

18:10 <ZirconiumX> Or else it'll complain enough

18:10 <mwk> no

18:10 <mwk> so far I needed to install yosys-smtbmc, symbiyosys, and currently compiling yices2

18:11 <mwk> (because I apparently had a symlink to yosys from .local/bin, but not to yosys-smtbmc)

18:11 <_whitenotifier-5> [nmigen] mwkmwkmwk synchronize pull request #279: hdl.ast: Fix width for unary minus operator on signed argument. - https://git.io/JeDft

18:11 <mwk> okay, fixed

18:11 <_whitenotifier-5> [nmigen] codecov[bot] commented on pull request #279: hdl.ast: Fix width for unary minus operator on signed argument. - https://git.io/JeDJL

18:11 <_whitenotifier-5> [nmigen] Success. Absolute coverage decreased by -0.03% but relative coverage increased by +17.8% compared to 7650431 - https://codecov.io/gh/m-labs/nmigen/compare/76504319962524b02c7d21111295b655e009bd76...21aebe4d9a832d1952e5d14d5b4dfd0df96cb469

18:11 <_whitenotifier-5> [nmigen] Success. 100% of diff hit (target 82.19%) - https://codecov.io/gh/m-labs/nmigen/compare/76504319962524b02c7d21111295b655e009bd76...21aebe4d9a832d1952e5d14d5b4dfd0df96cb469

18:13 <_whitenotifier-5> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/620250295?utm_source=github_status&utm_medium=notification

18:14 <_whitenotifier-5> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/620250295?utm_source=github_status&utm_medium=notification

18:15 <_whitenotifier-5> [nmigen] Success. Absolute coverage decreased by -0.42% but relative coverage increased by +17.8% compared to 7650431 - https://codecov.io/gh/m-labs/nmigen/compare/76504319962524b02c7d21111295b655e009bd76...2f6d3c6491c84c501ab4108c8bae5eb244983b78

18:15 <_whitenotifier-5> [nmigen] Success. 100% of diff hit (target 82.19%) - https://codecov.io/gh/m-labs/nmigen/compare/76504319962524b02c7d21111295b655e009bd76...2f6d3c6491c84c501ab4108c8bae5eb244983b78

18:15 <mwk> huh, how did travis finish successfully in 2 minutes this time, but took 17 minutes to crash previously

18:16 <_whitenotifier-5> [nmigen] Success. Absolute coverage decreased by -0.03% but relative coverage increased by +17.8% compared to 7650431 - https://codecov.io/gh/m-labs/nmigen/compare/76504319962524b02c7d21111295b655e009bd76...2f6d3c6491c84c501ab4108c8bae5eb244983b78

18:17 <mwk> ZirconiumX: and as for 0 != -0, well

18:17 <mwk> it already worked like that before, depending on the signedness involved

18:19 <mwk> as in, if the 0 going in was 4-bit unsigned, it's going out as 5-bit signed

19:35 <kc8apf> https://pypi.org/project/migen/ shows a 0.9.2 release but there isn't a corresponding tag or commits on https://github.com/m-labs/migen. Is the PyPI an official release?

20:22 <vup> kc8apf: looks like this is the commit: https://github.com/m-labs/migen/commit/98fb0217f543800e356fafcc6c831edf3a4fb2b6

20:41 <kc8apf> Ah, tag didn't get pushed

23:08 <Astro-_> though zc706 qspi works in the simpler read-only mode, its status flags just haven't started turning in manual i/o mode. :(

23:18 <Astro-_> however, the register is called intr_status and other implementations use interrupts.

23:18 <Astro-_> I wonder if it's time to implement the arm gic interrupt controller?

23:22 <mtrbot-ml> [mattermost] <sb10q> Yes, check the rpi.nix file in nix-scripts

23:24 <mtrbot-ml> [mattermost] <sb10q> We don't need interrupts. Can the IRQ line status be read back just to work around shit-hardware problems without actually triggering an interrupt?

23:27 <mtrbot-ml> [mattermost] <sb10q> That may be required anyway if the end goal is to manipulate the registers with openocd to write the flash

23:28 <mtrbot-ml> [mattermost] <sb10q> How does vivado write the flash?

23:28 <mtrbot-ml> [mattermost] <sb10q> And the non-manual mode can't be used for writing?

23:58 <Astro-_> just reading back is what I've been trying to do

23:59 <Astro-_> the non-manual mode is r/o

23:59 <Astro-_> vivado... will investigate