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
electronic_eel_ has joined #glasgow
electronic_eel has quit [Ping timeout: 265 seconds]
<esden> hey all, I am sorry if it is a very stupid question. (it seems that others don't have that issue) I was trying to install a newer version of glasgow (current master) and it is failing during the fx2 dependency install with.
<esden> ```
<esden> running build_ext
<esden> make: *** ../firmware/library: No such file or directory. Stop.
<esden> ```
<esden> writing manifest file 'fx2.egg-info/SOURCES.txt'
<esden> make -C ../firmware/library
<esden> What am I missing?
<esden> I have to work on my python setup script fu... I am not sure about what that path is relative to. I would imagine that it is trying to find the fx2 library. But the relative path to the software directoly would be ../vendor/libfx2/firmware/library ?
<esden> Anyways, pointers welcome. :)
<electronic_eel_> esden: IIRC I had that problem too
<electronic_eel_> it happens when you do not have libfx2 installed and you try to install the glasgow software
<electronic_eel_> the glasgow setup sees that libfx2 is missing and it is building it as dependency
<electronic_eel_> IIRC I fixed it by cloning libfx2 and installing it with it's setup before installing glasgow
electronic_eel_ is now known as electronic_eel
<electronic_eel> I should have probably created a pr (or a patch)
<esden> Ohh ok, I will try that. I was just following the README instructions. Those are already missing the mention of --recursive or `submodule init` & `submodule update`. I will send in a pr for the things when I actually manage to get things to work again. I got it to work in the past ;)
<whitequark> electronic_eel: esden: yeah, it's a submodule
<esden> It worked by going into the submodule and installing it manually... but following the readme fails.
<whitequark> yes, just fixed that
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JeszF
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 4409cd6 - README: fix installation instructions.
<esden> heh ... you are too quick I was about to submit a pr ;)
<esden> don't you think that `git clone --recursive https://github.com/GlasgowEmbedded/Glasgow` would be bit easier?
<esden> but I might be missing something
<esden> these are the changes I was thinking of submitting. But there might be a better way.
<esden> ohh right, the README also does not mention the fpga tools at all. There should be a mention of how to obtain them too I guess.
<_whitenotifier> [Glasgow] whitequark commented on pull request #158: cli: make output legible on black-on-white terminals too - https://git.io/Jesge
<whitequark> esden: --recursive would also clone the doc archive
<whitequark> which is huge
<whitequark> esden: you don't need all the other steps you added in README
<whitequark> or rather
<esden> well I did need them to get it to work ;)(
<whitequark> you shouldn't need them
<esden> ok then the build script has to be fixed
<esden> as described earlier, I was getting the "directory not found" error for some reason and electronic_eel confirmed having the same problem.d
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-2/±0] https://git.io/JesgI
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 05b8bbd - software: remove remnants of versioneer.
<whitequark> but you didn't clone the submodule.
<esden> (urgh ... I need to get better control over my keyboard)
<esden> I did clone the submodule.
<whitequark> hm
<esden> it still failed
<esden> I can do a clean clone and try again to make sure
<esden> this is how I found it as I was installing on a new clean machine
<whitequark> yeah, I'm going to need to check it in a container or something
<esden> ok... I maved away ~/.local to ~/.local-bak ... then cloned glasgow cleanly, inistialized the submodule, and ran `python3.7 setup.py develop --user`
<esden> this results in `Running fx2-0.7/setup.py -q bdist_egg --dist-dir /tmp/easy_install-79s02p_0/fx2-0.7/egg-dist-tmp-sxx_cxu9`
<esden> `make: *** ../firmware/library: No such file or directory. Stop.`
<whitequark> hm
<esden> I guess it is downloading it from pypi instead of using the submodule
<whitequark> yes
<whitequark> it should be doing exactly that
<esden> but that fails
<whitequark> ok i see
<whitequark> hm
<esden> I have to manually go into the submodule and install explicitly.
<whitequark> yeah, looking into it
<esden> awesome, thank you :)
<_whitenotifier> [whitequark/libfx2] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JesgV
<_whitenotifier> [whitequark/libfx2] whitequark 24dbb81 - software: fix check for prebuilt bootloader.
<_whitenotifier> [whitequark/libfx2] whitequark 3adb4fc - Bump version.
<_whitenotifier> [libfx2] whitequark created tag v0.8 - https://git.io/fjAQS
<_whitenotifier> [whitequark/libfx2] whitequark tagged 3adb4fc as v0.8 https://git.io/Jesgw
<whitequark> esden: fixed
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±3] https://git.io/Jesg1
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark c35b5b0 - software: bump libfx2 version.
<whitequark> was a missed commit in libfx2...
<esden> whitequark: awesome! Tested and it does indeed work now. :)
<esden> thank you for fixing it :)
<whitequark> np
<whitequark> I also updated instructions using a fresh Docker image
<esden> Sweet that looks great. Do you have thoughts about mentioning the requirement for fpga tools?
<whitequark> oh yeah
<whitequark> hmmm
<esden> I need to find the time to create a ppa that gets fpga tools nightly binaries into. Then it is easy to at least get on ubuntu and friends.
<whitequark> right
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JesgN
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 06dad0d - README: add Yosys/nextpnr requirement.
<esden> they also need icestorm to be able to build nextpnr-ice40 I think.
<whitequark> yes. that's in the nextpnr-ice40 instructions.
<esden> you could link to my build script, it makes thing at least a little easier: https://github.com/esden/summon-fpga-tools
<whitequark> i need to package all this stuff as a flatpak or appimage or something like that
<whitequark> i think that's not good enough. it needs to be some sort of ready to use archive/package/etc
<whitequark> i've been thinking about it
<whitequark> it's not easy
<esden> I am not saying it is good enough... I know a better solution is needed.
<esden> but it is not here yet :D
<esden> you could pull the apio binary zip file too...
<esden> but they release those very sporadically...
<esden> anyways, I need to catch some sleep. Thank you again for fixing the build issue. :)
<whitequark> o/
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JesaC
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 6c11895 - Travis: ignore deprecation warnings.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±3] https://git.io/Jesag
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark eb60009 - platform.rev_c[01]: update for changes in nmigen-boards.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark ed517d6 - platform.ice40: fix hang in toolchain_program().
pie__ has joined #glasgow
pie_ has quit [Ping timeout: 240 seconds]
<_whitenotifier> [Glasgow] electroniceel commented on pull request #158: cli: make output legible on black-on-white terminals too - https://git.io/JesVY
<desalin> I see this channel is not for Glasgow (City of). Any of the good people here know where one would look for such?
<_whitenotifier> [Glasgow] whitequark commented on pull request #158: cli: make output legible on black-on-white terminals too - https://git.io/JesVG
<whitequark> no idea, sorry
<_whitenotifier> [Glasgow] electroniceel commented on pull request #158: cli: make output legible on black-on-white terminals too - https://git.io/JesVu
<_whitenotifier> [Glasgow] whitequark commented on pull request #158: cli: make output legible on black-on-white terminals too - https://git.io/JesVz
<_whitenotifier> [Glasgow] whitequark closed pull request #158: cli: make output legible on black-on-white terminals too - https://git.io/JesRa
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JesVg
<_whitenotifier> [GlasgowEmbedded/Glasgow] electroniceel b6c88af - cli: make output legible on black-on-white terminals too
<ZirconiumX> It'd be a two-hash channel if so; i.e. ##glasgow
<electronic_eel> whitequark: about the -abc9 option for yosys - do you know of an easy way to detect if it is supported or not?
<whitequark> mhm
<electronic_eel> or is the policy for the time being that you need git head of yosys and nextpnr
<whitequark> yeah it is
<whitequark> I forgot -abc9 isn't in 0.9...
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JesVK
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 1b927c6 - README: require Yosys master.
<electronic_eel> ...was just going to mention the readme...
<emily> should probably gate -abc9 on yosys > 0.9 or something
<emily> so that it works out of the box
<whitequark> i think you need yosys master anyway because of nextpnr
<whitequark> they evolve in lockstep
<electronic_eel> 0.9 is the last release. I don't know of a practical way to find if your version > 0.9 already has -abc9 or not
<electronic_eel> probably you'd have to call it and parse the response or something
<whitequark> yes
<whitequark> that's what nmigen already does.
<electronic_eel> does it parse the error message? or just the version string?
<whitequark> version string
<whitequark> it includes an opaque number that indicates offset from the last version
<electronic_eel> yeah, that is easy, but not enough to detect -abc9 support
<electronic_eel> I haven't looked at the nmigen code doing that - do you think it is worth extending it?
<whitequark> no
<whitequark> that code is an nmigen implementation detail and should not be used in glasgow
<whitequark> i'm also really not interested in supporting arbitrarily old yosys versions
<whitequark> if something, i would rather add yosys, nextpnr and icestorm as vendor/ submodules
<electronic_eel> I think adding the maintenance burden for old versions is not necessary for now, so I concur
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/Jeso0
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 20356d3 - applet.video.vga_output: adapt to nMigen.
<electronic_eel> whitequark: thanks for fixing the travis builds btw, all the fails were a bit depressing
<whitequark> they still fail
<whitequark> just not on CI
<whitequark> oh
<whitequark> the travis builds, yes
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 3 commits to master [+0/-0/±3] https://git.io/Jesog
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark e43966a - applet.audio.dac: fix tests.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 26e4314 - applet.audio.yamaha_opl: fix tests.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 469bbee - applet.video.ws2812_output: fix argument parsing.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JesKs
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark b70a2fd - applet.program.ice40_sram: fix tests.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JesK8
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 4302a71 - applet.program.ice40_sram: remove useless condition.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 1eed212 - applet.program.ice40_sram: fix tests.
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to travis-synth [+0/-0/±1] https://git.io/JesKw
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark adc69bf - Travis: build Yosys and nextpnr.
craigo has quit [Ping timeout: 276 seconds]
<_whitenotifier> [Glasgow] Error. The Travis CI build could not complete due to an error - https://travis-ci.org/GlasgowEmbedded/Glasgow/builds/588463783?utm_source=github_status&utm_medium=notification
ExeciN has joined #glasgow
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to travis-synth [+0/-0/±1] https://git.io/Jes6d
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 25b9c5e - Travis: build Yosys and nextpnr.
carl0s has joined #glasgow
<_whitenotifier> [Glasgow] Error. The Travis CI build could not complete due to an error - https://travis-ci.org/GlasgowEmbedded/Glasgow/builds/588483929?utm_source=github_status&utm_medium=notification
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to travis-synth [+0/-0/±1] https://git.io/Jesis
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark 39ece2a - Travis: build Yosys and nextpnr.
ExeciN has quit [Ping timeout: 245 seconds]
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JesXF
<_whitenotifier> [Glasgow] whitequark deleted branch travis-synth - https://git.io/fhhGp
<_whitenotifier> [GlasgowEmbedded/Glasgow] whitequark deleted branch travis-synth
<whitequark> this will hopefully result in less brokenness
<whitequark> as now the applets are synthesized on travis
Sellerie has quit [Quit: The Lounge - https://thelounge.github.io]
cmr_ugh has quit [Changing host]
cmr_ugh has joined #glasgow
Sellerie has joined #glasgow
carl0s has quit [Remote host closed the connection]
bgamari_ has joined #glasgow
<bgamari_> whitequark, have you ever looked at Clash? https://clash-lang.org/
<whitequark> yeah
<whitequark> (a) i don't really use haskell, (b) i've had to debug the output of clash and it is of horrendous quality
<whitequark> totally unreadable, you basically have to reverse-engineer it
<bgamari_> that is true
<bgamari_> whitequark, the output definitely isn't readable
<whitequark> as an aside, my view is that a language is not enough
<whitequark> you need an stdlib and a portability layer
<bgamari_> that being said, in my experience if you take advantage of the type safety that the language provides you generally don't need to read the output
<whitequark> which... are not really separate
<whitequark> you always need to read the output.
<whitequark> at the very least, because of toolchain bugs downstream
<emily> can't say nmigen's output for Glasgow stuff is exactly stellar reading material either...
<whitequark> is it not?
<bgamari_> I'll admit, I did end up killing a day tracing unexpected behavior of a clash design back to vivado's buggy synthesis
<bgamari_> so you raise a fair point
<bgamari_> but that is the only time I've had to read the output, thankfully
<bgamari_> otherwise things "just worked" which was a very pleasant surprise
<bgamari_> admittedly, I am also rather biased towards Haskell
<emily> whitequark: i wouldn't describe this 11k line top.il file as particularly elucidating :v
<whitequark> have you done any designs in clash that had complicated clock trees and CDC arrangement?
<whitequark> emily: uh
<whitequark> the verilog output is the human readable one
<bgamari_> whitequark, I've had a couple of clock domains
<whitequark> (not as much as it should be, but i'll fix that)
<bgamari_> nothing terribly crazy though
<emily> Clash certainly has more clock-domain-crossing guarantees than nmigen does currently...
<whitequark> emily: I think you're missing my point
* bgamari_ suspects he is as well
<emily> I mean, you can lean on the compiler more when it's actually checking substantial design properties I think
<emily> but I agree that ugly compiler output is of course not necessarily beneficial
<whitequark> Clash is (in principle) good if you can express everything you need (especially CDC stuff) in its type system, because you can't really read its output, even in a pinch
<whitequark> nMigen doesn't have a type syste, but you can read its output fairly easily
<whitequark> this means that *if* everything you need fits into clash's model, *then* clash is clearly better
<whitequark> but otherwise it's clearly worse
<whitequark> it's a fairly common tradeoff with tools like it.
<bgamari_> sure
<whitequark> which is why I'm asking if it can express complex CDC stuff.
<whitequark> maybe it's good enough! i don't know! that's the question
<bgamari_> whitequark, it can express (and verify) clock domain crossing: http://hackage.haskell.org/package/clash-prelude-1.0.0/docs/Clash-Explicit-Synchronizer.html
<whitequark> does it have just those two?
<whitequark> because that's not really enough
<emily> it also has facilities for writing your own with unsafe features
<emily> a la Rust
<whitequark> sure
<bgamari_> that and the usual dual-port FIFO synchronizer
<whitequark> does it set correct attributes for the platform on the synchronizer signals?
<whitequark> if it doesn't, then its verification isn't actually guaranteeing the properties
<emily> does nmigen even have stuff for that?
<whitequark> yes.
<emily> fair enough
<whitequark> it sets ASYNC_REG on the 2FF synchronizer, and right now I'm discussing with someone a way to integrate it with timing analysis
<bgamari_> whitequark, you mean timing constraints?
<whitequark> which... is not trivial
<whitequark> that too
<whitequark> but I mean you need ASYNC_REG
<whitequark> or you don't actually get the MTBF guarantees you think you are getting
<whitequark> because it could place the two FFs on the different sides of the die
<whitequark> I also suspect the asyncFIFOSynchronizer has the same bug that nMigen has
<whitequark> (which makes it not actually safe)
<bgamari_> I don't think that clash has any particular cleverness for ensuring proper placement so you are likely right
<whitequark> yeah it doesn't, I looked at the source
<whitequark> so... it can "verify" CDC but it's unsound.
<whitequark> it's a guarantee nonetheless, but much weaker than what one might expect
<bgamari_> right
<bgamari_> frankly it would probably be better to implement the synchronizer not in clash but as a blackbox module
<bgamari_> in the HDL
<whitequark> not sure I agree
<bgamari_> in principle you could teach clash to emit attributes but I'm not sure what that would look like
<bgamari_> oh?
<whitequark> wait, it *cannot* emit attributes?
<whitequark> at all?
<whitequark> that means you cannot implement any sound CDC in clash lol
<bgamari_> ahh, never mind
<whitequark> aha, that makes much more sense
<whitequark> now you only have to inject the dependency on the platform into every CDC primitive and it would actually work
<bgamari_> that would be reasonably straightforward I suspect
<whitequark> re: me disagreeing with implementing CDC stuff in HDL (I assume you mean Verilog)
<bgamari_> right, for instance in verilog
<whitequark> it would suck that you have to reimplement one of the most error-prone modules in one of the most error-prone languages
<whitequark> you need to parameterize it, too
<whitequark> double the footguns
<oeuf> hm?
<whitequark> what
<oeuf> ah nevermind double
<bgamari_> fair enough
<whitequark> egg.
* oeuf purrs
<emily> we just need dependently-typed HDLs where you can prove the correctness of your clock-domain crossing...!
<whitequark> i am totally for it?
<whitequark> i mean
<whitequark> you ... can't actually do that
<whitequark> because it's like
<whitequark> CDC is never 100% reliable
<bgamari_> right
<whitequark> you could try to prove the MTBF, *but*
<bgamari_> emily, what is your definition of correctness?
<whitequark> not only this depends on the actual physical placement of the primitives
<whitequark> which is well outside the scope of your HDL
<whitequark> but worse
<emily> fair enough
<whitequark> there are some FPGA companies that don't actually qualify their primitives
<whitequark> so you *cannot* know the MTBF
<whitequark> i mean, silego just didn't have any timing info at all.
<emily> well, nobody says you have to support the worst companies
<whitequark> i'm not sure if you can actually determine the actual MTBF for ice40 from public data
<whitequark> you could probably evaluate it yourself at great expense and complexity.
<emily> whitequark: consider how much better clash is than https://twitter.com/importantshock/status/1176245623940681728 must have been
<whitequark> or suck o^W^W somehow convince lattice management to release you the right data which they'd have to generate from their models with some cadence crap
<whitequark> emily: ahahaha incredible
<bgamari_> heh
craigo has joined #glasgow