redstarcomrade has quit [Read error: Connection reset by peer]
skipwich_ has quit [Quit: DISCONNECT]
skipwich has joined #glasgow
redstarcomrade has joined #glasgow
joerg has quit [Ping timeout: 250 seconds]
joerg has joined #glasgow
<d1b2>
<axiesmoothie> That can't be accurate right (from crowdsupply) Estimated to ship: Jul 31, 2023
<whitequark[cis]>
it might be
<d1b2>
<axiesmoothie> dang congrats then after so long of struggle, i bet you all want to focus on other things in your life now (or at least not the hardware lol)
<whitequark[cis]>
I'm not involved in manufacturing or fulfillment in any way (1b2 is doing that entirely on their own)
<whitequark[cis]>
I'm just supporting the software stack when the units do ship
<d1b2>
<axiesmoothie> okk then to 1b2 uhuhuh
<d1b2>
<axiesmoothie> whitequark: are u getting a fair pay out of this considering the time it's been?
<whitequark[cis]>
at the moment there is no agreement stating I will be paid anything
<d1b2>
<ewenmcneill> Axie: Personally I think it's unlikely anything Glasgow-related will ship to end users in July 2023. Last we knew the cases were still in China, and the cases had to arrive in the USA and be shipped with the "early bird" Glasgows to Mouser before Mouser could start shipping anything to end users.
redstarcomrade has quit [Read error: Connection reset by peer]
ar-jan has joined #glasgow
ar-jan has quit [Ping timeout: 244 seconds]
ar-jan has joined #glasgow
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #glasgow
ali_as has quit [Ping timeout: 244 seconds]
ali_as has joined #glasgow
<jn>
(wow, i only now realized that d1b2 isn't random keymashing but the Discord(?) 1bitquared bridge)
<whitequark[cis]>
yse
<whitequark[cis]>
* yes
<d1b2>
<esden> Hey @axiesmoothie, I am not sure how closely you are monitoring this channel here. It is a much better source of up to date information than the CrowdSupply delivery date... we are adjusting that date as needed, it will be shifted into the future again with the next CS update that I am about to write this week. As @ewenmcneill accurately states the cases are still in china. When they arrive here , we have to pack them into boxes, and ship them to
<d1b2>
mouser, then mouser has to ingest them into their system, and then they will start shipping them to early bird backers. (that is only 200 first units of boards and cases) Second, WQ asked me to make the hardware quite a while ago, I agreed as I think this project is interesting. Since the campaign ended at the exact moment chip shortage hit, we ended up paying huge prices for parts, then things took forever after that until we actually got all the parts,
<d1b2>
were able to finalize the PCB design only after that, and case design after that. 1b2 now spent several 10s of thousands of dollars beyond what the backers provided to keep this project moving forward and not end up bankrupt. And we will have to spend way more than that to get this project to the finish line. I would love to compensate WQ for the work, but that is definitely not in the cards until we make our money back by selling hardware after we
<d1b2>
fulfill all the campaign. I hope this clarifies things a bit... I know it is really hard to see how daunting this project has been for everyone involved without being directly part of it and in the trenches.
<d1b2>
<esden> @jn that does not mean that there is not random keysmashing coming form me 😄
<whitequark[cis]>
people view my relationship to 1bitsquared as borderline exploitative sometimes, but it's actually how I wanted things to go
<whitequark[cis]>
basically, 1b2 takes all the risk (and hoo boy was there a LOT of risk involved, and SO MANY things went wrong) and reaps all the profit
<d1b2>
<esden> hehe... well I hope there will be some profit at the end 😭 😅
<d1b2>
<esden> we will make it to the finish line! I promise that!
<whitequark[cis]>
at the time when i agreed to it i was quite well informed of what manufacturing hardware at scale is like, and how it can squeeze people out, and I opted out of that
<ar>
in the meantime, i know of at least one person who decided to do a short run (~10pcs) of glasgow. but, again, small scale is, in many ways, a lot simpler
<d1b2>
<esden> you did the right thing 😄 especially with the hindsight
<whitequark[cis]>
considering that it was also around the time when my disability got significantly worse it is something i think of as a very appropriate move
<d1b2>
<esden> I hope you are getting these things a bit under control
<whitequark[cis]>
🤍 has got the NHS to dispense the necessary meds and i am currently working at a place which does respect having disabilities, so, I'd say so
<d1b2>
<attiegrande> good to have visibility on these things - thanks both for talking about it openly
<whitequark[cis]>
I still live paycheck to paycheck and often like, end up eating rice for the last part of the month, which sucks
<d1b2>
<esden> That is good to hear @whitequark 🙂
<whitequark[cis]>
it's like... a few causes of precarity down, some remain
<d1b2>
<esden> I really hope that over time things get out on the straight including the finances.
<whitequark[cis]>
moving is expensive. being sick is expensive
<whitequark[cis]>
having someone you care about depend on you to not go homeless is, well
<d1b2>
<esden> @ar indeed... 10 units can be assembled by hand under a microscope... no big deal... 2000 not so much 🙂
<d1b2>
<esden> @whitequark indeed 😦
<d1b2>
<attiegrande> 💚
<ar>
esden: exactly. funnily enough, they're going to assemble big part of it with jlcpcb
<d1b2>
<esden> Sure, that is a decent strategy to cut down on assembly time. That said I personally would stencil solder paste over the whole board, hand place the parts and then reflow... you can't do that when there are already some parts soldered to the board.
<d1b2>
<esden> But if one is a soldering iron jockey jlcpcb is a decent jellybean assembly option 🙂
<ar>
yup. and, again, something that doesn't scale to 2000 units
<galibert[m]1>
So "Orders placed now ship Jul 31, 2023" is for sure incorrect at this point?
<galibert[m]1>
(Cases say Oct. already)
<d1b2>
<vegard_e> I think jlcpcb could scale fine to thousands of units if you wanted to, but at that point, it's a rather expensive option
<d1b2>
<esden> I mean, things should start moving quite quickly soon. The first batch of cases is 1000 units. When they arrive, we inspect them, everything goes well we will place the next batch order of 1000. It takes about 4weeks for a batch to be done.
<d1b2>
<vegard_e> IME what jlcpcb excels at are low NRE, which means it's excellent for low volume orders, but they charge quite a premium on some of the parts
<galibert[m]1>
Amusingly, if the date is going to move I'm probably going to order it, I just don't want it to arrive when I'm away on vacation because international shipping is sometimes a mess
<tpw_rules>
does this mean the early birds won't be all that early?
<d1b2>
<esden> @tpw_rules well yes, nothing is early with this project 😄
<tpw_rules>
i mean relative to the other orders lmao
<d1b2>
<esden> Based on my estimates, it will still be a month or two gap between "early bird" and the main orders start shipping.
<tpw_rules>
ok
<d1b2>
<vegard_e> I thought the «early» in «early bird» mainly referred to the time of ordering, not the time of shipping 🙂
<d1b2>
<vegard_e> «early bird gets the worm» and all that
<d1b2>
<esden> this will hopefully give us a chance to figure out the biggest glasgow software painpoints without having EVEREYONE asking for support
<tpw_rules>
yeah they get the first worms
<d1b2>
<vegard_e> the worm being a limited number of discounted units
<sorear>
didn't realize production counts had reached the thousands
<d1b2>
<esden> I think I might be counting also the units that CrowdSupply pre ordered
<d1b2>
<esden> ok yes, CS pre ordered 1k Glasgows and 700 cases.
<d1b2>
<esden> of which they probably sold already a bunch after the campaign was over so that still counts
<galibert[m]1>
Hmmm, if I want to order one I should go through CS or something else?
<galibert[m]1>
whatever the best for 1b2
<d1b2>
<esden> At the moment you can only pre order on the CS page. I can't put them in our store until we fulfill their order from us. :/
<galibert[m]1>
what should I do that's the best for 1b2? Go with CS, wait for your store to have them?
<d1b2>
<esden> But that is fine, just pre order it there, then you will reserve a spot in the queue.
<galibert[m]1>
I have no hurry
siriusfox has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
siriusfox has joined #glasgow
cakes has joined #glasgow
cakes has joined #glasgow
cakes has quit [Changing host]
ar-jan has quit [Ping timeout: 244 seconds]
<d1b2>
<ewenmcneill> For those who would like to “tip the creator” of the glasgow, whitequark does still have a Patreon: https://www.patreon.com/whitequark
<d1b2>
<esden> Ohh yeah good point @ewenmcneill
duderonomy has quit [Read error: Connection reset by peer]
duderonomy has joined #glasgow
<whitequark[cis]>
it is time for our Saturday meeting
<whitequark[cis]>
Attie, are you around?
<whitequark[cis]>
one thing I did is https://github.com/YosysHQ/yosys/pull/3859, which removes the need to add any weird workarounds around the yowasp build of yosys tooling
<whitequark[cis]>
and I think I'll continue this by implementing the toolchain identification code in Glasgow
<mwk>
whitequark[cis]: so we've been wondering what's up with the bitarray thing
<Wanda[cis]>
... er why are we using IRC
<Wanda[cis]>
so there's a PR, and it looks... correct if a little gross
<Wanda[cis]>
do you want to move it more in the "slow but simple" direction?
duderonomy has quit [Read error: Connection reset by peer]
<whitequark[cis]>
yeah. I'd like to have something that inspires confidence in its correctness when you're looking at it
<whitequark[cis]>
so for example, we could reuse support.bits and make support.bitarray use support.bits instances as chunks?
<Wanda[cis]>
chunks?
<Wanda[cis]>
... tbh, using python integers as a backend is quite horrible
<whitequark[cis]>
using support.bits as a mutable container is possible but it's slow since it creates huge bignums every time
<whitequark[cis]>
Wanda[cis]: is it? I think it's a really neat approach
<Wanda[cis]>
it's very horrible
<Wanda[cis]>
for one simple reason
<whitequark[cis]>
how so?
<Wanda[cis]>
you cannot grab a bit slice in O(1) time, or at least we don't know a way to do it
<Wanda[cis]>
and very definitely cannot change a bitslice in that time
<Wanda[cis]>
due to them being immutable
<whitequark[cis]>
well, yes
<whitequark[cis]>
I wanted something I can implement easily and quickly that would be reasonably fast without any doubt to its correctness
<Wanda[cis]>
so actually we've been thinking of basing bitarray on bytearray and, if anything, changing bits to work on top of bitarray?
<whitequark[cis]>
it is "reasonably fast" as in it doesn't make any applets I know slow
<whitequark[cis]>
hmm
<Wanda[cis]>
consider the fact that we may want to hold eg. FPGA bitstream in a bitarray
<whitequark[cis]>
yeah, thats why we still depend on the bitarray package
<whitequark[cis]>
despite it being... the way it is
<whitequark[cis]>
let me think about it for a sec
<whitequark[cis]>
so I don't see any reason why bits needs to stay immutable
<whitequark[cis]>
I made it immutable originally because I wanted a backend for bitstruct that is sane, and also a better way to manipulate JTAG
<whitequark[cis]>
bitarray has an unhinged contract for its init which constantly tripped me up
<whitequark[cis]>
s/init/`__init__`/
<whitequark[cis]>
oh, right, using it as a dict key
<whitequark[cis]>
yeah let's have bits and frozenbits with them sharing the same backend
<whitequark[cis]>
you have green light to reimplement the entire thing however you think is best
<Wanda[cis]>
<whitequark[cis]> "you have green light to reimplem..." <- alright; we're thinking `bytes`/`bytearray`-backed structure with packed bits, but simple bit-at-a-time algorithms
<d1b2>
<esden> Ok sounds good. On manufacturing side. I have made some serial sticker test prints, and progressed with @attiegrande to make sure the data matrix codes are readable. Last but not least is some code that I need to write that ties provisioning, testing and serial sticker printing together.
<Wanda[cis]>
could also go really simple and just take up a whole bytearray byte for each bit, but that'd explode memory requirements for big bitstreams
<whitequark[cis]>
yes
<whitequark[cis]>
something like a 100MB+ (that's compressed!) bitstream for xcvu19p
<Wanda[cis]>
yeah
<whitequark[cis]>
Maya actually tried to build a bitstream for that one on her laptop with 8 GB of RAM
<whitequark[cis]>
it ... did not go well
<Wanda[cis]>
lol.
<Wanda[cis]>
yes
<whitequark[cis]>
she forgot that it has that little RAM.
<whitequark[cis]>
swap didn't help so in the end she just asked me to get the same version of vivado, apply the same patch, and run it >_>
<Wanda[cis]>
that thing is... huge
<whitequark[cis]>
i think it's like, three xcvu9p dice stacked together?
<Wanda[cis]>
we're still struggling with desining some nice deduplicated data structures for it that'd still be fast to access
<Wanda[cis]>
no, it's 4 (unnamed) dice
<Wanda[cis]>
(which are not used in any other released FPGA)
<whitequark[cis]>
her work was using it for simulation of a thing and the next version of a thing required, uhh, about a dozen xcvu19p
<whitequark[cis]>
so it'd be like, seven of these duo things connected in a star configuration with FMC+-to-FMC+ cables or something like that
<whitequark[cis]>
actually i've been told that proFPGA configures systems for each customer individually so it's just however many of these modules they want to put on the backplane or something like that
<whitequark[cis]>
bottom line is that it's a lot of FPGAs
<whitequark[cis]>
used to run an entire modern manycore SoC in lockstep at around 50 MHz and do... i dunno, whatever you do for test and bringup