redstarcomrade has quit [Read error: Connection reset by peer]
trh has quit [Ping timeout: 252 seconds]
trh has joined #glasgow
andymandias has quit [Ping timeout: 245 seconds]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Ping timeout: 265 seconds]
Foxyloxy_ has joined #glasgow
Foxyloxy has quit [Ping timeout: 264 seconds]
miek has quit [Ping timeout: 244 seconds]
wiebel[m] has quit [Quit: Idle timeout reached: 172800s]
q3k[cis] has quit [Quit: Idle timeout reached: 172800s]
wiebel[m] has joined #glasgow
<wiebel[m]>
Is there an easy way to utilize the i2c and spi applets to snoop actual traffic instead of being part of communication?
Attie[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
no, those would have to be rewritten entirely since that's a different procedure
<whitequark[cis]>
especially for things like quad SPI
<whitequark[cis]>
(I suppose you could do SPI using a logic analyzer with a clock, but this is still a very different applet)
<wiebel[m]>
Ok thanks. I'm curious if I'm able and find the time to get deep enough into the fpga magic to get a simple i2c sniffer running.
<whitequark[cis]>
I advise using a logic analyzer
duskwuff[m] has joined #glasgow
<duskwuff[m]>
a lot of the code in i2c_target could probably be reused for an i2c sniffer, if you wanted to go that route
<wiebel[m]>
Thx I'll look into it. If I would actually be in need of a sniffer I'd grab my scope but I'm more interested in actually working with the oss toolchain for fpga. I find it most fascinating, also as I used vhdl some 20 years ago and this feels like an opportunity to get back into it in a new way. That's also a reason I'm very excited about the out-of-branch approach to keep the applet development more on point.
<whitequark[cis]>
out-of-branch?
<wiebel[m]>
Sorry out-of-tree I ment of course. I kind of wish for smaller steps.
<whitequark[cis]>
ah yeah. that won't officially happen until there is a stable, documented API for applets
<wiebel[m]>
I'm aware. but as I already fixed an old oot project from someone I at least noticed only minor changes. It already feels like a good entry point without having to maintain a fork.
<whitequark[cis]>
there will be large API breakages too, at some point
<wiebel[m]>
No matter how experimental it is currently I have the feeling you will steer into that general direction to allow for community created applets which I highly appreciate.
<wiebel[m]>
I don't think my project will reach a complexity at which I will struggle to adapt to a new api. Or do you strongly suggest to fork at this point.
davidc___ has quit [Ping timeout: 252 seconds]
<whitequark[cis]>
it's up to you; I'm just making the tradeoffs clear
davidc__ has joined #glasgow
<wiebel[m]>
I hear you. Also please let me tell you how much your work is appreciated, in code and in communication.
<whitequark[cis]>
thank you, this helps
<whitequark[cis]>
I've really struggled to keep up with Glasgow as I've been balancing that, Amaranth, and my job
<whitequark[cis]>
(... and a disability that currently defines my life, with extreme fatigue)
<whitequark[cis]>
it hasn't been something i found fun in quite a while, unfortunately
<wiebel[m]>
For that I must say you are very present around here. At least that's my impression.
<whitequark[cis]>
writing applets used to be fun for me, which is how I wrote so many and why they're so detailed. then COVID hit and I sorta got technically homeless, then there was a war, it's kind of a whole thing. I did keep up with the 1b2 production at least, and the project itself got productized
<whitequark[cis]>
meaning that you can connect it, click a button (ok, it's a few buttons, but very few for what it does), it works for you. it's approaching an Apple level of polish at places, which is fairly unusual for an open source hardware project
<whitequark[cis]>
but that's most of what I've done, mainly because writing applets is much less fun if you do it concurrently with a full time job and severe chronic pain
<whitequark[cis]>
I think the biggest problem I have in this project is that there is a certain standard I expect applets to be done to, but:
<whitequark[cis]>
- it's not really documented what it is, or how to reach it, and
<whitequark[cis]>
- while I can teach individual people on how to get there, it's an incredible investment of effort, and it's difficult to justify it if many of them would just... leave
<whitequark[cis]>
doing it piecemeal via code review just makes it extra miserable on top of an incredible investment of effort
<wiebel[m]>
I guess that's not uncommon when a hobby becomes a job. But your situation sounds really harsh. Props for still keeping it up.
<whitequark[cis]>
it's not a job because i'm not paid for it
<whitequark[cis]>
it's a secret third thing
<wiebel[m]>
But if it stops being fun it feels like work.
<whitequark[cis]>
oh, most of my open source work is work. two of my most popular projects, totalling like a billion downloads or something, are things i've never even used for myself
<wiebel[m]>
Maybe you should prioritize the out-of-tree API to keep the main app under you control and let loose of the rest. So that other people can also contribute without putting pressure on yourself to have conversations you'd rather not want to have.
<whitequark[cis]>
that doesn't actually solve anything
<whitequark[cis]>
an important goal is to have high-quality in-tree applets for lots of common protocols, which would be forfeited
<whitequark[cis]>
another important goal is to retain API flexibility until it's ready, which will be de-facto forfeited, because any significant API change will create a de-facto fork
<whitequark[cis]>
i think the solution is for other people to also put work in; to participate in a proverbial community, rather than just being consumers
<whitequark[cis]>
also, note that that out-of-tree API is itself a multiple-month major undertaking that is the absolute definition of hard work, no matter how it goes
<wiebel[m]>
True I probably underestimate that. But as long as you can cope with the strain of your standards and your available resources it sounds like a good plan.
<whitequark[cis]>
my standards are an interesting thing in that the project has been as successful as it is absolutely because of them
<whitequark[cis]>
it takes a madwoman to conclude that your Python package needs a zero-click FPGA toolchain installation and as a result of that conclusion go package it into WebAssembly and upload it to PyPI, yes?
<wiebel[m]>
Sure thing.
<whitequark[cis]>
anyway, I'll no longer be full time employed in two months
<wiebel[m]>
I'm not new to several toolchains and I was prepared for a living nightmare and was presented with an amazing out-of the box experience.
<whitequark[cis]>
hehe
<wiebel[m]>
I hope that's a good thing to have more time for yourself.
<whitequark[cis]>
yes, I specifically focused on OOBE right before the first 1b2 shipped
<whitequark[cis]>
this includes changing the firmware so that you never have to use Zadig or the friends on Windows instead of the glasgow CLI
<whitequark[cis]>
and this includes of course the FPGA toolchain packaging
<whitequark[cis]>
a few other things I don't quite recall too
<whitequark[cis]>
* first 1b2 batch shipped
<whitequark[cis]>
I felt that requiring people to install even oss-cad-suite first is kind of unacceptable if the idea is to make the FPGA bitstream build truly transparent
<wiebel[m]>
Only point is the glasgow itself calls tinkerers like myself who poke at every possible button and don't care for any rules so we try to break things and fix things. But here is nothing to fix. ;)
<whitequark[cis]>
yeah, the internals are actually very hackable even as they are, you can import everything piecewise like it's a library and do whatever you want
<whitequark[cis]>
despite the CLI being vertically integrated, it's just a facade
<wiebel[m]>
I was almost disappointed that my nix packaged hom-manager yosys, nextpnr, icestorm running on gentoo worked right away together with glasgow.
<wiebel[m]>
s/hom/home/
<whitequark[cis]>
oh right! there is also a Nix-inspired system for caching bitstreams
<wiebel[m]>
Oh as we are talking is there a clean way to rebuild a bitstream?
<whitequark[cis]>
did you know that for caching bitstreams, if you use the system yosys/nextpnr, it actually hashes the actual executable (together with its data files) in order to produce the final hash for the build product?
<whitequark[cis]>
so if you swap yosys underneath it, it will rebuild the bitstreams it has cached with no further action necessary
<whitequark[cis]>
the toolchain ID is formed from: yosys binary, yosys data files, nextpnr binary, icepack binary. if any of that changes, the bitstreams derived from that toolchain are automatically rebuilt
<whitequark[cis]>
this is why there is no glasgow cache command to toggle/inspect/clear the cache: it's transparent, and if for some reason it doesn't function properly, the cache needs to be fixed
<wiebel[m]>
Nicely executed so you hash the actual binaries producing the bitream along with the bitstream itself.
<whitequark[cis]>
when it caches a bitstream, it also remembers the entire stdout/stderr output of the toolchain, so if you run glasgow -vv, you get that repeated for you
<whitequark[cis]>
meaning you don't need to rebuild it just to see what the Fmax was
<whitequark[cis]>
it also checksums the bitstream itself and the console output, and if any of that doesn't match it wipes the entire thing and starts over, in case you had a drive failure or unclean shutdown or something
<wiebel[m]>
But this way you will never know if two different toolchains produce an exact match.
<whitequark[cis]>
wiebel[m]: yes. this wasn't a goal
<whitequark[cis]>
the goal was to prevent false cache hits, not false cache misses
<whitequark[cis]>
false cache hits are the devil of computing. meanwhile a false cache miss is just a minute at most on any modern machine
<wiebel[m]>
Of course but it would be hell of an interesting thing.
<wiebel[m]>
You should provide a -v or even a --debug flag to reveal the marvels of the inner workings.
<whitequark[cis]>
use glasgow -v
<whitequark[cis]>
the more -v you add, the more verbose it is, up to -vvvv
<whitequark[cis]>
the toolchain cache also makes sure to only ever use (a) a complete Wasm-based toolchain or (b) a complete native toolchain, without mixing and matching the two, mainly for legibility reasons
<whitequark[cis]>
s/cache/code/
<whitequark[cis]>
s/cache/runner/
<wiebel[m]>
dang I was trapped in glasgow build -h which doesn't show, sorry
<whitequark[cis]>
you can use the environment variable GLASGOW_TOOLCHAIN to change priority. the default is builtin,system meaning it first checks for the Wasm one and if it's missing, uses the system one, therefore implicitly gating on whether you used builtin-toolchain when installing glasgow or not
<whitequark[cis]>
you can do GLASGOW_TOOLCHAIN=system to enforce the native one, or GLASGOW_TOOLCHAIN=system,builtin to prefer it, etc.
<wiebel[m]>
I did that already to utilize my nix packaged toolchain
<whitequark[cis]>
it will even tell you what to install if you're missing all of them
<wiebel[m]>
a glasgow build --rev 3C forces a rebuild I might guess?
<wiebel[m]>
Oh trust me I noticed installed them one after the other.
<whitequark[cis]>
no, glasgow build uses the cache too
<wiebel[m]>
Can I enforce a rebuild? Or do I have to manually remove the cache?
<whitequark[cis]>
why would you want that? :3
<wiebel[m]>
To see it working. Like I said tinkerer ... ;)
<wiebel[m]>
So if I taggle builin and system do i get only hits?
<whitequark[cis]>
the sizes are representative
<wiebel[m]>
s/taggle/toggle/
<whitequark[cis]>
to benchmark toolchains it's probably easiest to just rm ~/.cache/GlasgowEmbedded/bitstreams/*
<wiebel[m]>
So the output is the bistream ans the other file metadata?
<whitequark[cis]>
bitstream plus terminal output
<wiebel[m]>
s/ans/and/
<whitequark[cis]>
there is no metadata
<wiebel[m]>
ahh ic
<wiebel[m]>
That is incoporated in the hash itself i guess
<whitequark[cis]>
yes
<whitequark[cis]>
all of the build inputs are a part of the hash
<wiebel[m]>
I truely hope you had a lot of fun building this .
<whitequark[cis]>
and, again in a Nix-like fashion, the build system clears the environment very thoroughly before launching a build, so stray environment variables like LD_PRELOAD or the like should be excluded
<whitequark[cis]>
it is not completely impossible to break it, as nothing is unbreakable, but you would have to genuinely try
<whitequark[cis]>
for example, nondeterminism in yosys or nextpnr could do it
<whitequark[cis]>
this is why I prefer the Wasm toolchain: the sandbox is single-threaded and essentially completely deterministic
<whitequark[cis]>
prefer as in, in terms of priority in the default configuration
<whitequark[cis]>
s/as//, s/,//, s/in//
<whitequark[cis]>
running the Wasm toolchain really is like applying a pure function to a bunch of inputs
<whitequark[cis]>
running the native toolchain is more of a gamble, though I did try to get it very reliable
<whitequark[cis]>
wiebel[m]: I think I mainly built it because I was unhappy with switching between e.g. jtag-pinout and jtag-probe being slow
<wiebel[m]>
What OS do you use if I might ask?
<whitequark[cis]>
I build most of my software because I feel that it should exist, but it does not, therefore I make it exist
<whitequark[cis]>
I use Debian
<whitequark[cis]>
* my software (and hardware) because I
<wiebel[m]>
With home-manager?
<whitequark[cis]>
no
<whitequark[cis]>
just normal Debian
<whitequark[cis]>
it's the standard XDG directory, which I felt is sufficiently self-evocative
WilfriedKlaebe[m has joined #glasgow
<WilfriedKlaebe[m>
This has been very interesting to read, and I now know a little more about glasgow. Like where it caches bitstreams.
<WilfriedKlaebe[m>
Yep, it just didn't occur to me to look.
<wiebel[m]>
True, together with the information about the <hash>.output containing actual information is in itself invaluable.
<whitequark[cis]>
the reason I search for the Wasm toolchain by default is that (a) it is incredibly robust and basically always works, provided wasmtime supports your platform, and (b) is guaranteed to be deterministic
<whitequark[cis]>
I actually use it myself despite being obviously able to build yosys and nextpnr
<whitequark[cis]>
I just don't want to ever think about which binary I have installed and so on
<whitequark[cis]>
but since it isn't available for all platforms, the default discovery clause is builtin,system and not builtin which would require an explicit override to use the native one
<whitequark[cis]>
so if it's not installable you just go back to "the old way"
<wiebel[m]>
That is in itself worth a lot. I remember when platformio was introduced. It was an absolute no-brainer to forget instantly every manual approach.
<whitequark[cis]>
I never actually made friends with platformio...
<wiebel[m]>
Having this env alone shows alot oversight.
<whitequark[cis]>
of foresight?
<wiebel[m]>
It's not pleasant but as soon as you have multiple architectures it help a lot
<wiebel[m]>
Of course foresight, excuse my poor english.
<whitequark[cis]>
which gives you a portable C/C++ toolchain that has a built-in libc and libc++
<wiebel[m]>
Don't you dare pull me into another rabbit hole, as if this one is not deep enough. ;)
<whitequark[cis]>
also Amaranth itself includes another copy of (part of) Yosys, which it also uses Wasm for
<whitequark[cis]>
same reasoning, different component
<whitequark[cis]>
(it's not used in Glasgow)
<whitequark[cis]>
I'm fairly uncompromising about usability
<wiebel[m]>
I got to go to bed. Thanks for the mightily insightful chat. Catherine
Foxyloxy_ has quit [Read error: Connection reset by peer]
<whitequark[cis]>
night
Foxyloxy has joined #glasgow
<whitequark[cis]>
I think my overall feelings about Glasgow is that I'm more than willing to lead but this needs to be a collaborative process and not just a pure "consumption" + "here's a patch I wrote for myself" one, and I need more time to actually be able to afford it given my health
<WilfriedKlaebe[m>
aaaand I managed to read this old 24LC256 :)
<whitequark[cis]>
nice
<WilfriedKlaebe[m>
took me way too long to realize that maybe I should enable the pullups when I don't have any, and that a 256kbit device might need two byte addressing
<whitequark[cis]>
oh yeah we should maybe enable pullups by default
<WilfriedKlaebe[m>
anyway, bedtime for me too - sleep well when you go!