gsuberland has quit [Remote host closed the connection]
gsuberland has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
FFY00_ has joined #glasgow
FFY00 has quit [Ping timeout: 264 seconds]
<whitequark[cis]>
<nf6x[m]> "Just curious: Are there any..." <- there were years ago but we eventually decided it's not viable and we'll probably just leave them be
<whitequark[cis]>
specifically i need a team name (`@GlasgowEmbedded/<something>`) for people who can make cross cutting changes to the entire monorepo
<whitequark[cis]>
and i want it to be short
<whitequark[cis]>
ideas?
<Darius>
Ripsaw
<Darius>
although I suppose a ripsaw cuts with the grain not against it..
<whitequark[cis]>
that's incomprehensible to a casual reader
<whitequark[cis]>
apparently instead of adding yourself to CODEOWNERS for every file you need to add yourself to the list of people who can bypass CODEOWNERS
<whitequark[cis]>
ok, I've just disabled "require review by code owners" entirely because that mechanism was designed incompetently
<whitequark[cis]>
it's now basically a "subscribe me to this mailing list" file rather than "gate merges on my approval" file
<_whitenotifier-9>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-590-b0466d476707babc78bc3226481cb1efe7204b08 - https://github.com/GlasgowEmbedded/glasgow
<whitequark[cis]>
using the merge queue means that none of the bypasses that you have for this purpose actually work
<whitequark[cis]>
like, ok i can see that "require review" in github's eyes means "require review of someone else than author" (except it only sometimes does that), but combining that weird behavior with defanging explicitly enabled bypasses just makes it unusable
<galibert[m]>
Shamans ? For the ones who can change things everywhere
<whitequark[cis]>
that's incomprehensible to a casual reader
<galibert[m]>
Ok
<whitequark[cis]>
I eventually went for "owners" since the group would include all org owners
<joshua_>
'owners' is what I would choose from the top of my head; there are a bunch of annoyingly grandiose cutesy grandiose options also but I don't think they're your aesthetic; 'admin' and 'global' are basically the other options that are not cutesy single word; 'owners-all', 'admin-all', etc. are scope-and-privilege words that can be turned into a more full system later ('owners-python', 'committers-python', 'approvers-python', 'approvers-all') but those ar
<whitequark[cis]>
joshua_: your message got cut off after "but those ar"
<whitequark[cis]>
(this is an irc 'feature', it's cut off server side)
<whitequark[cis]>
and yeah you are correct in that i hate the annoyingly grandiose cutesy options :)
<whitequark[cis]>
i think each software project is entitled to two or maybe three weird quirky names while it's still cute. after that it becomes just aggravating
<_whitenotifier-9>
[glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-590-b0466d476707babc78bc3226481cb1efe7204b08 - https://github.com/GlasgowEmbedded/glasgow
<joshua_>
...but those are not one word
<whitequark[cis]>
approvers is something i did not come up with and may use in the future, thanks
<joshua_>
'approvers' and 'owners' distinct: 'owners' has the connotation of being able to rambo a change in, 'approvers' has the connotation of having privileges sufficient to +1 a change but not to unilaterally put a commit in the repo
<joshua_>
the grandiose cutesy options being, like, 'overlords', 'masters', 'maestros' (that's a bad Italian pluralization of "masters, but ineptly trying to sidestep the somewhat-racial connotations of the term in the US")
<whitequark[cis]>
cursed
fishmonger[m] has quit [Quit: Idle timeout reached: 172800s]
<overflo_97375[m]>
i asked catherine on fedi before about pulseview support and it said, its not a thing yet but COULD be made a reality, limiting factor being the available 18k FIFO memory and esden is working on a RAM-pak that might be handy for in-memory storage of readings.
<overflo_97375[m]>
i never touched FPGAs ever and i am so excited to finally have something that i have a real-world use for 🙂
<whitequark[cis]>
oh hey!
<jn>
overflo_97375[m]: you've come to the right place, amaranth and glasgow are rather pleasant ways of touching FPGAs :)
<whitequark[cis]>
yeah so we have a standalone (non PV) analyzer applet but it's severely hampered by a combo of fixed 48M sample rate and the 18K of onboard RAM
<whitequark[cis]>
USB sporadically has high latency that causes underflows, and the applet stops whenever it hits an underflow
<whitequark[cis]>
I made that applet as a proof of concept while in a rather awful environment and haven't touched it since, so it kinda needs to be rewritten entirely
dne has quit [Remote host closed the connection]
dne has joined #glasgow
<blackbit[m]>
yeah, we met a few times, just briefly though. gretting from the salzburg CCC. this is an OT conversation, let's take this somewhere else
whitequark[m] has quit [Quit: Idle timeout reached: 172800s]
pg12 has quit [Ping timeout: 268 seconds]
pg12 has joined #glasgow
pg12 has quit [Ping timeout: 268 seconds]
pg12 has joined #glasgow
getorix[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has joined #glasgow
<ebb>
Congrats on the milestone esden[m] :) hadn't realised I was at the very tail end of the crowdfund
<ebb>
In estimated ship date we now trust
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
Attie[m] has joined #glasgow
<Attie[m]>
"We are marking a big milestone. We just shipped the last Glasgow boards that were part of the crowdfunding campaign!"
<Attie[m]>
🥳 - well done esden !
<whitequark[cis]>
i just read a flash with Glasgow at 190 Mbps
<whitequark[cis]>
> 0x4000000 byte / 2.835 s -> Mbps
<whitequark[cis]>
approx. 189.3724 megabps
<whitequark[cis]>
this is without even a PLL, just by cleverly using DDR buffers, using the new Amaranth I/O infrastructure
<whitequark[cis]>
next milestone: reading a flash with Glasgow at 336 Mbps (USB 2 saturation bandwidth)
<Attie[m]>
😱
<whitequark[cis]>
so, i couldn't do 336 (it fails timing), but i did hit 228 Mbps
<whitequark[cis]>
at a frequency this high there's significant crosstalk issues using the glasgow wiring harness... it's not really specced for 60 MHz IO
<whitequark[cis]>
so, theoretically i should be able to go further
<whitequark[cis]>
buuut i think i'm hitting some sort of issue with my CDC
notgull has quit [Ping timeout: 252 seconds]
<whitequark[cis]>
I think it's both the broken AsyncFIFO reset, and the fact that at a frequency that high, the SB_IO input capture window starts to matter
<whitequark[cis]>
yeah, i am having an issue where having both sides of my AsyncFIFO and the QSPI core in the same domain (fast.{clk,rst} = sync.{clk,rst}) works fine each time
<whitequark[cis]>
but one side behind a PLL with the same frequency does not work so well
notgull has joined #glasgow
<nf6x[m]>
I appreciate the detailed technical background of the VIO issue in the latest crowdfund update. 🍻
modchatbot[m] has quit [Quit: Idle timeout reached: 172800s]
<theorbtwo[m]>
I wonder if there's scope for a bit of automagic speed setting for things where we have a validate process available. IE, keep reading the same data at slower rates until it stops changing on us, and then read the rest of the flash at that speed.
<whitequark[cis]>
the issue here seems to be on the FPGA side
<whitequark[cis]>
I'm not actually sure if SB_IO capture window is a problem at all
<whitequark[cis]>
maybe it is, maybe it's not, but until the CDC is fixed we won't know
<theorbtwo[m]>
I expect most of the time for my uses my horrible wiring job will be the limiting factor, but I am mostly wondering if we can have a process general enough that you don't need to code most of it for every use, and it doesn't matter where the problem is, because we dynamically figure out how fast the system can go reliably by actually trying the system.
<theorbtwo[m]>
(And by CDC do you mean USB communications device class?)
<whitequark[cis]>
no
<whitequark[cis]>
clock domain crossing
<theorbtwo[m]>
Aha!
<whitequark[cis]>
and I don't think that works because with the CDC issues, i can read sometimes read 4 MB twice in a row before it fails the third time
<whitequark[cis]>
how can you know how much data is enough data to read and validate?
<whitequark[cis]>
there are basically three regions: BER (bit error rate) well under 10^-10 (no issues), BER well above 10^-6 (easily detected), and the weird in-between place where it's bad enough to cause problems but not bad enough to be visible on casual testing
<whitequark[cis]>
and your algorithm is basically precision guided to go into that exact region
<theorbtwo[m]>
Whee.
<theorbtwo[m]>
That's not even the problem I thought it would have, which is deterministic errors, where it'd be wrong the same way twice in a row, so we would assume it was right.
<whitequark[cis]>
oh, no, timing issues are never like that
<whitequark[cis]>
this is because if you have a marginal issue, then random noise, or simply temperature variations in your room will cause it pass or fail seemingly randomly
nyanotech has quit [Remote host closed the connection]
<whitequark[cis]>
which is basically why you have to apply actual engineering rather than guessing and trying
josuaH[m] has joined #glasgow
<josuaH[m]>
Let's end our sentences with semi-column for programming sake;
nyanotech has joined #glasgow
<whitequark[cis]>
(one aspect of said actual engineering is that the level shifters have a finite propagation time and you have to take that into account if you're going fast enough)
<whitequark[cis]>
(i think it's about 3 ns one direction, but it also depends on the voltage)
<whitequark[cis]>
fortunately that isn't an issue for single data rate (Q)SPI given that it caps out at about 120 MHz, but if you did DDR it would become a serious issue at 80 MHz, and probably before that too
<whitequark[cis]>
this isn't something we had to ever care about in any applet because the old Amaranth I/O was kiiiinda unfit for purpose
<josuaH[m]>
FX2 and iCE40 together... that is some sweet spot!
<josuaH[m]>
Some advantage in waiting for so long too: that permits to have feedback right at the beginning of the production: i.e. an issue with the default firmware that slipped past testing.
<josuaH[m]>
Hoping that everyone here enjoyed building it as much as we will use it 😄
<josuaH[m]>
s/😄/😀/
<whitequark[m]>
that was actually completely unrelated to the production schedule
<whitequark[m]>
i just noticed one day that it wasn't fixed
<nf6x[m]>
"Oops" is a very relatable word. 🙂
redstarcomrade has quit [Read error: Connection reset by peer]
<whitequark[m]>
(also I don't think we have non-default firmware? it's not user-serviceable)
<nf6x[m]>
I'm working on my first addon board, because that seems more approachable to me than learning Amaranth so that I can do anything useful with Glasgow. 🙂 It's a DIP 40 adapter with I/O expansion, inspired by esden's PROM dumper addon. I have a few noob questions, if that is ok...
<nf6x[m]>
I note that in the PROM dumper design, the VIO outputs and Vsense inputs are all tied together. Is it considered best practice to connect both VIO outputs together on an addon which uses both A and B banks and uses a single I/O voltage?
<nf6x[m]>
Is there any concern of damage if a user accidentally programs different VIO voltages with the two VIO nets connected to each other?
<nf6x[m]>
Should the Vsense inputs normally be connected to VIO on an addon card?
Lord_Nightmare has joined #glasgow
<esden[m]>
mhh... now that I think about it, it is probably a bad idea to have the two VIO voltages connected to each other on the addon board... not sure what my thinking was back when I designed the board... it was so long ago 😅
<esden[m]>
but having vsense connected to VIO has the advantage that you can monitor the actual voltage you output
<theorbtwo[m]>
I'd actually think having one vsense connected to vio and the other connected to programming voltage would be useful on the prom board, assuming programming voltage is something you want to support.
<theorbtwo[m]>
(I can't remember the details, but the vsense ADCs have a lot more range than most of the rest of the board.
sigstoat[m] has joined #glasgow
<sigstoat[m]>
i certainly wouldn't tie them together. they come from different regulators with different analog-y bits for feedback.
<nf6x[m]>
That's what I was thinking, so I was confused when I saw them tied together in esden's PROM addon design.
<sigstoat[m]>
looks like the topology and reverse current protection of the vio regulator is probably how esden was getting away with it.
<sigstoat[m]>
i wouldn't do it on purpose, but i bet you could get away with paralleling those.
<nf6x[m]>
I have them all connected in my work-in-progress layout, but I hope to see esden (@_discord_269693955338141697:catircservices.org) 's opinion about connecting them in the revC3 era.
<nf6x[m]>
It's still work in progress, but here are some renderings. My theory is that people like pictures.
<nf6x[m]>
Sadly, Aries doesn't seem to provide 3D models for their ZIF sockets. I've emailed them to ask for one, but I haven't heard back yet. 😢
<sigstoat[m]>
fyi i made a kicad library for making glasgow hats. https://github.com/jkominek/glasgow-hats/ i haven't tested it a lot, but it might have some value for you
<nf6x[m]>
I probably don't need >300mA. My use case is dumping things like PROMs. I was originally going to make a simplified dumper for just 14-18 pin bipolar PROMs, but then I went in a silly direction and decided to make a generalized 40 pin DIP adapter with 32 bits of bidirectional I/O expansion. If I didn't goof, it should end up compatible with applets expecting esden's PROM dumper board if it's jumpered properly, but also allow fancier stuff.
<nf6x[m]>
Are photos posted to the Discord visible to the IRC and Matrix folks?
josHua[m] has joined #glasgow
<josHua[m]>
yes
<nf6x[m]>
Yay! Pictures are fun.
<theorbtwo[m]>
Looks pretty handy.
duskwuff[m] has joined #glasgow
<duskwuff[m]>
I feel like there's an interesting continuum between what you've got and generalized programmers like the TL866 series
<nf6x[m]>
Yeah, it's hard to decide just where to pound in the nail along that continuum. It's hard to find the right balance between capability and elegant simplicity. Everybody will likely have a different opinion based on the specific tasks they have in mind.
<nf6x[m]>
I made a special-purpose dumper for 8051 mask rom devices a while back. It involves booting the DUT from external ROM and then letting the DUT control its own EA pin with a GPIO to get access to the mask ROM contents, and it only works for early devices which don't have any code protection features such as latching the EA state at reset time.
<nf6x[m]>
I wonder whether it might be possible to do the same thing with my Glasgow DIP40 adapter? I have not yet thought through whether it would be possible to satisfy the 8051's external memory access timing through a serial I/O expander.
<nf6x[m]>
I can't wait to get my hands on a much higher pin count Glasgow derivative, even if I have to contribute design work and/or money to make that happen. 😉
hysiact[m] has joined #glasgow
<hysiact[m]>
Hello! I saw the update today, great news! One problem: it says that all the backer Glasgow’s have shipped. Mine… hasn’t. On crowd supply, it says that my status is “crowd funding” but I don’t have a shipping notification.
<tpw_rules>
i think by shipped it was meant that they have left production and are on their way to the distributor. it will still be a bit before the distributor gets them to you
<tpw_rules>
but i am not project staff
vegard_e[m] has joined #glasgow
<vegard_e[m]>
I think when the update says shipped, it means that the batches of boards are shipped to Mouser, not necessarily that Mouser have yet received them and distributed them towards the individual backers
<tpw_rules>
ye
<tpw_rules>
yes*
<esden[m]>
hysiact (@_discord_757890527440928768:catircservices.org) As zyp says. "We" as in 1BitSquared, have shipped two big boxes of Glasgows to Mouser. These two boxes contain the last Glasgows for the core campaign. It does not mean they shipped to you specifically yet. Those two boxes are scheduled to arrive at Mouser tomorrow. Based on previous batches it will take Mouser about a week to dispatch them. You can check your queue status on the
<esden[m]>
tracking page here: https://glasgow.1bitsquared.com It should say that "it will ship soon" for all the items in your order. Sorry the update was unclear about it.
<esden[m]>
hysiact (@_discord_757890527440928768:catircservices.org) if you still have questions feel free to send me a DM with your order number and I can help you untangle the mystery. 🙂
<hysiact[m]>
Thanks for the clarification. That was not clear to me in the email.
<esden[m]>
Yeah sorry... it is not always easy to discern how people will read things. 🙂
redstarcomrade has joined #glasgow
thomasflummer[m] has joined #glasgow
<thomasflummer[m]>
I just received mine today... looks very nice with the little light guides in the case and I must say that getting set up on my Mac went really easy following the installation guide... firmware update and all was a very nice experience. Super good job to all that have helped with that!
<esden[m]>
thomasflummer (@_discord_564209469697818633:catircservices.org) yey! Great to hear! 🙂 I hope it serves you well.
<thomasflummer[m]>
I also noticed you nice box labels... was that a requirement from Mouser, or mostly for your handling?
tomkeddie[m] has quit [Quit: Idle timeout reached: 172800s]
ewenmcneill[m] has quit [Quit: Idle timeout reached: 172800s]
redstarcomrade has quit [Read error: Connection reset by peer]