ChanServ changed the topic of #glasgow to: glasgow debug tool · code https://github.com/GlasgowEmbedded/Glasgow · forum https://glasgow.whitequark.org · logs https://freenode.irclog.whitequark.org/glasgow
visitor has joined #glasgow
visitor has left #glasgow [#glasgow]
_whitelogger has joined #glasgow
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 4 commits to master [+0/-0/±5] https://git.io/JeZQh
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 7f2d599 - access.direct.demultiplexer: fix assert.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 6cbb617 - applet.audio.yamaha_opl: allow undervolt glitching.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 88dfe4e - applet.audio.yamaha_opl: allow changing network endpoint.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 67cffef - applet.audio.yamaha_opl: do unsigned→signed conversion in gateware.
_whitelogger has joined #glasgow
thaytan has quit [Ping timeout: 240 seconds]
thaytan has joined #glasgow
<Getorix> seems to work fine on clean mac snapshot. these are some things worth discussing:
<Getorix> 1. I currently used `ktemkin/oss-fpga` tap to install opensource fpga toolchain. Eventually we should probably have similar tap under GlasgowEmbedded
<Getorix> 2. on mac glasgow installs itself to `$HOME/Library/Python/3.7/bin/`, which is probabaly fine but maybe we want to add symlink there from /usr/local/bin/
<Getorix> 3. On the very first glasgow call there might be an error "E: __main__: device not found", however second and all further attempts are fine (maybe because of vmware)
<whitequark> interesting
<Getorix> this is current mac setup instruction: https://gist.github.com/alexhude/150ca8a28a938da7c8ad5a1ad4be9332
<Getorix> after everyone is happy with the changes we can embed it into Glasgow README.md
HexGlaze_ has joined #glasgow
HexGlaze has quit [Ping timeout: 268 seconds]
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±3] https://git.io/JeZbN
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark f8ed49b - applet.audio.yamaha_opl: rewrite player to use WebSockets.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark a04b4d8 - applet.audio.yamaha_opl: set CHA/CHB=1 in $C0..C8 in OPL3 during reset.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JeZNc
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 31b2370 - applet.audio.yamaha_opl: fix minor frontend issues.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 48eed42 - aplet.audio.yamaha_opl: raise chunk size.
<emily> Getorix: fwiw you can also get Glasgow using Nix on macOS, it has prebuilt binaries for the entire FPGA toolchain and Glasgow is packaged
<emily> (I maintain the packages)
<Getorix> hmm Nix?
<emily> which alleviates having to deal with 5 different package managers and the impure system states they leave you to manage
<emily> https://nixos.org/nix/ https://nixos.org/nixpkgs/ it's a purely functional (declarative + sandboxed + reproducible) build system/package manager for linux/macos/etc.
<emily> sort of like Bazel + a package manager put together, if you're familiar with Bazel (although Nix predates it)
<emily> in practice it means you should be able to
<emily> # curl https://nixos.org/nix/install | sh
<emily> # nix run nixpkgs.glasgow -c glasgow run benchmark
<emily> and have it Just Work
<Getorix> hehe, brew is enough for me I think :)
<emily> although right now you'd need to use the unstable nixpkgs channel which requires a little setup
<emily> fair enough
<emily> a handful of people (incl. M-Labs) are using Nix for FPGA design stuff because it involves so many interlocking toolchains with complicated setup procedures and is hard to make easy to setup and reproducible, which Nix addresses nicely
<emily> so I just figured I'd plug it in case it might be helpful to you :)
<Getorix> also if ppl vote for brew we can always add prebuild binaries there as well
<Getorix> yeah, thanks for letting me know, I will take a look for sure
<emily> that first-time run issue is strange
<emily> hm, "If there is no existing kernel extension installed for the device, libusb will run out of the box, you do not even need to have root privilege and there is no need to set up udev rules like Linux."
<emily> maybe it's something like, first run it sets up the kernel extension
<emily> but that only works by the second run
<Getorix> I don't think it is using any separate kernel extension
<Getorix> usblib should use IOKit USB to talk to device which is already loaded
<Getorix> for FTDI it is a bit different but it is not our case
<emily> ah
<emily> ok, just my unfamiliarity with macOS (it's been a long time)
<Getorix> I can trace kext loading though, worth checking
<Getorix> we should probably add Nix setup instruction for macOS as well if ppl are using it
<emily> dunno if anyone is using it on macOS, I only recently got Glasgow in there and the toolchain building on the macOS builders :)
<emily> I don't personally have access to a macOS box so my latency for fixing issues is a bit long
<emily> I've reported some things like https://github.com/YosysHQ/yosys/issues/1357 that got fixed though
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±3] https://git.io/JeZN7
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 8fbad05 - aplet.audio.yamaha_opl: raise chunk size.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark c3dee7d - applet.audio.yamaha_opl: fix mounting at a path.
<_whitenotifier> [Glasgow] electroniceel synchronize pull request #159: Add applet gpio.pca953x - https://git.io/JeG5u
emily has quit [Remote host closed the connection]
<_whitenotifier> [Glasgow] electroniceel commented on pull request #159: Add applet gpio.pca953x - https://git.io/JeZxo
emily has joined #glasgow
<emily> I: g.device.hardware: building bitstream ID 96b8de80b454b669b99b4f440ac376e6
<emily> ERROR: Max frequency for clock 'cd_sync_clk_if_0__i': 46.98 MHz (FAIL at 48.00 MHz)
<emily> tfw your blinkenlights are too advanced
<electronic_eel> emily: huh, what kind of pwm did you try?
<emily> it was actually just a bad refactor to use a counter when i shouldn't have
<electronic_eel> hmm, aren't pwm or pdm solutions usually based around a counter?
<emily> is there any convenient way to get the generated verilog for an applet?
<ZirconiumX> emily: from nmigen.back import verilog; print(verilog.convert(YourApplet()))
<ZirconiumX> You'll need to specify ports too I think
<emily> alas, Applets are not elaboratable
<emily> and with Subtarget you need to pass in target stuff that I'm not quite sure where to get from ><
<_whitenotifier> [Glasgow] emilazy opened issue #163: config/99-glasgow.rules should maybe set ENV{ID_MAKER_TOOL} - https://git.io/Jenez
<_whitenotifier> [Glasgow] electroniceel commented on issue #163: config/99-glasgow.rules should maybe set ENV{ID_MAKER_TOOL} - https://git.io/JeneX
ec0 has quit [Ping timeout: 276 seconds]
ec0 has joined #glasgow