<rqou>
ugh can i just throw money at coilcraft and get a transformer?
<rqou>
or do i actually have to go through the whole exercise i did in lab? :P
<awygle>
I mean probably depends on how much money
* whitequark
stabs arachne-pnr again with a stabbing implement
<whitequark>
fucking bug-ridden mess
<rqou>
huh is it just me or is it actually the case that a) nobody really cares very much about flyback controllers and b) very few people want a flyback _boost_ controller?
<whitequark>
you mean a non-inverting flyback? or what?
<rqou>
no
<rqou>
e.g. TI has a bunch of -48V to sane voltage converters
<whitequark>
what the hell is a flyback boost controller?
<rqou>
i meant the magnitude of the output voltage is higher
<rqou>
than the magnitude of the input
<rqou>
rather than lower
<whitequark>
ah
<rqou>
and to start with there's only 32 flyback controller ICs in TI's catalog anyways
<rqou>
everybody seems to be focusing on other applications, not this segment
<awygle>
linear has a cool self sensing part iirc
<whitequark>
why do you even need a flyback controller specifically
<rqou>
e.g. ultra-high-efficiency buck converters
<rqou>
i want to go from sane voltage to ~400V for that nixie tube thing
<whitequark>
a flyback is a FET plus FET driver plus oscillator plus a comparator
<rqou>
it's apparently supposed to be at ~360V
<rqou>
yeah i know that
<whitequark>
well?
<rqou>
i was looking for an integrated controller IC
<whitequark>
use any chip providing those parts
<whitequark>
like, with an integrated FET?
<rqou>
no, with some fancy control loop and sensing crap
<rqou>
maybe i don't care about that
<whitequark>
why do you need that
<rqou>
i guess i don't? :P
<rqou>
hence why m-labs just used the amazing thing called "a microcontroller" :P
<rqou>
screw it i'll just manually build my own control loop
<rqou>
with blackjack and hookers
<cr1901_modern1>
>rqou: i can totally imagine somebody wanting smoltcp to be usable for TCP over SLIP/PPP?
<cr1901_modern1>
rqou: I'd like to add PPP at some point, but it's currently low on my priority list. TCP over serial is pretty cool.
<awygle>
I used to want slip. I like slip.
<whitequark>
ok so this is weird
<whitequark>
I added a 1023-cycle long power on reset and the weirdness stopped
<whitequark>
but e.g. a 255-cycle long power on reset doesn't work
<cr1901_modern1>
try 511?
<whitequark>
i mean it's clearly comewhere between those values
<whitequark>
but *why*&
<whitequark>
oh hm
<cr1901_modern1>
Time for a binary search
<whitequark>
no
<whitequark>
the precise number gives me zero insight into the cause of it
<whitequark>
maybe I'm enabling the clock too early
<awygle>
are you releasing reset before the clock is stable maybe?
<whitequark>
no, it should be enabled throughout
<whitequark>
but that's probably the cause
<whitequark>
I'm having the clock enabled while the FIFO bus is still tristated
<rqou>
whitequark: do you know if ionpak is designed to operate in DCM or CCM?
<rqou>
just out of curiosity?
<whitequark>
expand those
<rqou>
discontinuous conduction mode vs continuous conduction mode
<rqou>
on the flybacks
<whitequark>
don't know
<whitequark>
awygle: ayup that was the cause
<awygle>
cool
<whitequark>
i'm now enabling the interface clock only after the bus is enabled
<whitequark>
or rather simultaneously
<whitequark>
and have a 63 cylce reset
<whitequark>
63 because arachne fails timing with 15 cycles
<whitequark>
okay, so enabling the bus THEN enabling the clock does the trick
<whitequark>
I might not even need explicit reset in the FPGA
<whitequark>
nope, still need it
<rqou>
seriously, why are all nixie circuit examples on the interwebs BJT-based?
<zkms>
because nixie tubes are trad and so are BJTs?
<rqou>
i guess
<whitequark>
>nixie tubes are trad
<rqou>
i'd much rather have MOSFETs
<rqou>
i certainly wouldn't want to use crappy soviet-era BJTs
<awygle>
i feel like BJTs are easier for higher voltage than MOSFETs, despite that feeling being obviously contradicted by reality
<whitequark>
oh for fucks sake
<rqou>
awygle: wait what?
<whitequark>
no it doesn't work even with explicit reset
<rqou>
i'm pretty sure modern MOSFETs have higher voltage handling than BJTs?
<whitequark>
with BJTs you can make cascode ladders
<rqou>
yeah but who does that except for class? :P
<rqou>
also FETs can be put into a cascode configuration too?
<awygle>
rqou: emotionally i feel that high voltage BJTs are easier/cheaper than MOSFETs, but that's not actually true
<cr1901_modern1>
I share awygle's sentiments, tbh
<rqou>
all you weirdos :P
<rqou>
i never liked BJTs
<whitequark>
there's IGBTs
<rqou>
yeah i know
<rqou>
but tail current
<awygle>
i also think of mosfets as digital and bjts as analog
<rqou>
i just don't do analog :P
<rqou>
simple!
<awygle>
> i'll just manually build my own control loop
<rqou>
still digital :P
<rqou>
hrm
<rqou>
i think i need to yak shave a bit before i can get to building this
<rqou>
not the analog thing that just leads to "herp derp i have no idea what i am doing"
<rqou>
(i _did_ take the class on it :P )
<gruetzkopf>
GTO!
<rqou>
nobody likes GTOs, go away :P
<gruetzkopf>
pfft
<gruetzkopf>
train maintenance personnel disagrees with you
<gruetzkopf>
germany has had success stories like class 0442 trains killing 423-igbt trains by emi
<rqou>
ok, for "grid"-type applications yes, GTOs
<rqou>
i don't do that
<gruetzkopf>
"you can swap the igbt modules much easier" - yeah, but i don't know of a single class 423-gto or class 425 train which is not on it's first set of GTOs
<rqou>
gruetzkopf: any mercury arc rectifiers left? :P
<gruetzkopf>
none in operation that i know of
<rqou>
wait wait wait
<rqou>
gruetzkopf: germany actually replaces train parts with *gasp* new technology?
<rqou>
not like BART scrounging ebay for NOS parts?
<gruetzkopf>
not really, they switched between series 1 and series 2+ of class 423
<zkms>
how do you drive GTOs
<rqou>
yeah but BART is _finally_ _now_ switching to a new series of trains
<gruetzkopf>
we still have quite a lot of class 420 trains in operation
<gruetzkopf>
they were build for the 1972 olympic games in munich
<whitequark>
whats GTO
<awygle>
gate turnoff thyristor
<whitequark>
oh lol
<awygle>
I have never done a power supply that could kill me and I'm content with that lol
<rqou>
you never really see them outside "grid" applications
<rqou>
oh, and EL drivers i guess
<gruetzkopf>
class 424 has it's floor 993mm over top-of-rail, class 425 at 798
<rqou>
huh i just realized this nixie power supply i need can actually kill you
<zkms>
also didn't BART have issues with thyristors dying in their trains a few years ago?
<awygle>
Well I guess a 5W uhf transmitter can kill you but it's not really the power supply doing it.
<gruetzkopf>
class 423 and it's successor 422 are entry-compatible with class 420
<gruetzkopf>
(which is also where the EMU length and power rating come from)
<gruetzkopf>
67400mm, 2350kW
<awygle>
ugh I need to consume food in order to continue living..
<rqou>
hmm thinking about things i think the next board i need to do should be a lern2bga board
<rqou>
i need to get a working reflow-based workflow
<gruetzkopf>
i have some ridiculous zarlink/microsemi TDM crossconnect switches in 1.5mm grid bga :D
<rqou>
you mean "easy mode" :P
digshadow has joined ##openfpga
* whitequark
stabs FX2LP
<whitequark>
"oh, it lets me use positive polarity for RD and WR pins", I thought.
<whitequark>
"how convenient", I thought.
<whitequark>
of course, glitches on these lines when enabling the bus cause spurious packets to be committed.
<rqou>
much attention to detail with the ascii art
<whitequark>
look if i'm gonna translate it it's going to be the best fucking translation of an USSR datasheet in the entire anglosphere
<rqou>
alright, i'll format this nicely and everything, but tomorrow
<rqou>
i'll also go stick this into one of the university's nice scanners
<rqou>
which among other things will not be randomly rotated :P
<whitequark>
what do you mean it's NOT nicely formatted?
<whitequark>
blasphemy
<rqou>
i meant as an "enterprisey" format like PDF :P
<rqou>
along with the original images
<rqou>
your document is great by itself
<whitequark>
hahaha
<rqou>
wtf "is compliant to technical specification ОДО.339.519 ТУ and considered fit for operation"
<awygle>
smash cut to six days later, whitequark lies collapsed in a pile of old soviet documents having gotten trapped in a recursive translation loop
<whitequark>
exactly what it says on the tin
<whitequark>
I don't think that ТУ is on the web anywhere
<whitequark>
it's from, like, 1983
<rqou>
is this the silly USSR bureaucratese you mentioned?
<whitequark>
which part
<whitequark>
the bizarre sentence structure? yes
<whitequark>
normally when I translate from Russian I adjust sentence structure to what's common in English but for documents like these you might as well just pipe it into /dev/null and rewrite fromscratch
<whitequark>
which I definitely don't have time for
<rqou>
they qualify this for short duration operation at MINUS TWENTY DEGREES?!
<rqou>
i guess russia is cold
<awygle>
Siberia man
<whitequark>
minus twenty barely qualifies as cold
<whitequark>
now minus forty is pretty cold
<whitequark>
russian schools don't close at minus twenty.
<whitequark>
I know because I fucking had to go to school
<rqou>
so this definitely won't have any problems at all in california climate :P
<whitequark>
through heaps of snow
<whitequark>
at minus twenty
<rqou>
hmm if my math is right, each small indicator should nominally draw just under 2mA
<rqou>
but wait
<rqou>
if everything in a row is lit up, that's 128 mA
<rqou>
* 400V is just over 50 W
<rqou>
um
<rqou>
a 50W 400V power supply sounds pretty scary
<whitequark>
wow i cant believe how simple that circuit is
<whitequark>
compared to even glasgow
<rqou>
wtf are those symbols?
<rqou>
i've never seen a transformer drawn that way
<whitequark>
that's just how eagle does it
<rqou>
hrm that's definitely not what i remember
<rqou>
oh wait
<rqou>
i was using the SFE libs
<rqou>
that might be why
<rqou>
also wait
<rqou>
if this nixie display is fully on, it draws _50 W_?!
<rqou>
i guess i've gotten spoiled by modern electronics :P
<whitequark>
well, it doesn't draw that continuously
<rqou>
yeah, not if you're displaying something
<rqou>
wait
<rqou>
do plasma TVs use less power if the screen is black?
<whitequark>
yes
<rqou>
anyways, i need to rethink exactly how i want this to work now
<rqou>
i originally wanted to run this display off of a "herp derp, have a 1S lipo"
<rqou>
but 50W is much more power than i was expecting
<rqou>
i was expecting the display to be more like 5W
<whitequark>
are you sure you're accounting for the duty cycle correctly?
<rqou>
i'm doing a worst case
<rqou>
every cell lit on every row
<rqou>
one pixel is already 2mA
<rqou>
and as you cycle through the rows nothing changes
<rqou>
if they're all lit
<awygle>
That arc supply is cool
<rqou>
anyways, the battery life doesn't have to be amazing if the display is fully on, but pulling (50 W / nominal 3.7 V) ~= 14 A out of a tiny 1S lipo might not be good for it
<rqou>
i also assume that this was never originally intended to be battery-powered? :P
<whitequark>
we're all lit
<awygle>
1s6p :-P
<rqou>
no, no parallel plz
<rqou>
i'd rather have a higher voltage
<whitequark>
just connect 108 1S cells in series
<whitequark>
then you don't need any boost
<rqou>
lolol
<awygle>
108s balance charging IC - 300$
<awygle>
Our spacecraft battery was 2s3p
<awygle>
And it was fine
<rqou>
wait wait wait
<rqou>
how the hell can modern laptops turn on their screens for something like _14 hours_?!
<whitequark>
LEDs
StCypher has quit [Read error: Connection reset by peer]
StCipher has joined ##openfpga
<rqou>
i guess you really have to appreciate modern engineering
<whitequark>
that and modern laptops are mostly battery
<rqou>
so according to cnet the 15 inch 2015 mbp has a battery of "only" 100 Wh
<whitequark>
yes
<whitequark>
if you make it bigger it doesn't fit in airplanes
<rqou>
which can only (at worst) light up this 64x64 nixie display for 2 hours
<rqou>
:P
<rqou>
i think i might give up on having a battery on this thing
<whitequark>
also that's an absurd amount of battery
<whitequark>
I think my laptop is less than this WITH an external battery pack
<rqou>
and here i was expecting it to work with a 1s1p cell :P
<rqou>
not even close lol
<rqou>
> i also assume that this was never originally intended to be battery-powered?
<whitequark>
why not?
<whitequark>
run it off a car battert
<rqou>
sure
<rqou>
i meant a lipo cell
<whitequark>
there WERE no lipo cells back then
<rqou>
i know
<rqou>
oh, about the "originally intended" comment?
<rqou>
yeah, you can run it off of a car battery
<whitequark>
the 1st commercial lipo cell is 1991
<rqou>
yeah i thought you were responding to my earlier statement
<rqou>
hmm i think 2 hours worst case runtime is probably acceptable for me so i might make this portable after all
<rqou>
since a) it's a toy b) you can always drop the duty cycle even lower
<rqou>
wait
<rqou>
the power wasted in the resistors actually exceeds normal SMD dissipation limits
<rqou>
goddammit
<whitequark>
hahaha
<rqou>
i guess those didn't exist back when this display was made either :P
<rqou>
not as embarrassing given the "temporary workaround" for the .nsf bug
<awygle>
are there Unicode stroke fonts?
<whitequark>
sort of
<awygle>
Like for pcb silk etc?
<rqou>
not a good one
<whitequark>
solvespace includes one :P
<rqou>
afaik
<whitequark>
but it isn't very good, it's a patchwork of random characters
<rqou>
kicad doesn't have full unicode support because they are lame :P
<rqou>
(not serious, kicad is pretty cool overall)
<awygle>
Kicad is... It makes me kind of melancholy I guess?
<awygle>
Like a moldy old ruined church
<rqou>
oh wtf why does _everything_ in adafruit just have to have a silly cute name?
<rqou>
pop quiz: wtf does "bonnet" mean in the context of raspberry pi?
<awygle>
It's like a hat but... Half of one?
<awygle>
That's a flat guess
<rqou>
pretty much
<whitequark>
that... makes a disturibng amount of sense
<rqou>
what a silly name
<rqou>
also "hat" is a silly name too
<awygle>
what does, bonnet or the church thing?
<rqou>
"we couldn't use the word 'shield' because we need to have a distinct branding or something"
<whitequark>
bonnet
<awygle>
lol
<rqou>
also idk what's special about this exactly but they also have a product whose name is "HUZZAH32"
<rqou>
everything just seems excessively silly and obfuscated
<rqou>
pretty much a case of "it's only funny/cute the first time"
<whitequark>
it's not targeting you
<whitequark>
it's targeting people who are encountering it for the first time
<rqou>
does being cute/funny actually help with that?
<whitequark>
enormously
<rqou>
"enormously"?
<whitequark>
for you, EE is boring
<whitequark>
for most people, EE is scary/inaccessible/complicated
<awygle>
Related, I saw a really good take on webassembly recently. Javascript programmer really excited to get closer to the metal, instead of systems programmer excited to avoid Javascript. Idk why I never thought of it that way before.
<awygle>
arright, bedtime. I'll do Glasgow Rev b after work tomorrow, so between 7 and 11ish PDT
<awygle>
Goodnight all
bitd has joined ##openfpga
ondrej2 has quit [Ping timeout: 255 seconds]
ondrej2 has joined ##openfpga
pie_ has quit [Ping timeout: 248 seconds]
<rqou>
huh, apparently sliding mode control for dc-dc converters is possible
<rqou>
but apparently it doesn't really help much?
<rqou>
"at least comparable to standard current control
bitd has quit [Ping timeout: 240 seconds]
<rqou>
hmm actually
<rqou>
why aren't there all that many dc-dc converter controllers that are 100% software controlled?
<rqou>
or maybe they are and i just don't know about it?
<rqou>
anyways, this can end up being a very fun future
<rqou>
azonenberg: can you imagine having to update firmware on your dc-dc converter/PMIC?
<rqou>
whitequark: was it you who mentioned that TI had a ridiculously powerful BMS solution with an ARC core in it?
<azonenberg>
rqou: i considered making one on a greenpak
<azonenberg>
didnt have time to look into how practical it would be
<azonenberg>
I might also try doing one on an fpga just to learn more about smps design etc
<azonenberg>
rqou: re font bugs
<azonenberg>
you do know that windows, at least up until i think 8.x
<azonenberg>
parsed truetype in the *kernel*
<azonenberg>
Which means that bugs in handling of the hinting bytecode resulted in ring0 rce
<rqou>
yeah I knew about that
<rqou>
even Microsoft themselves got tired of it and fixed it
<rqou>
re: smps design: you should have helped me suffer through the power electronics course :P
<rqou>
btw azonenberg what do you think about the "package a die next to some XeF2" thing i was talking about earlier?
<azonenberg>
there's better ideas
<rqou>
O_o?
<azonenberg>
First off, XeF2 is a solid with a high vapor pressure
<azonenberg>
The etch rate is not at all high
<rqou>
yeah they had this problem :P
<azonenberg>
About 16 um per *hour*
<rqou>
which is why this part of the idea was eventually abandoned
<azonenberg>
so with a typical say 320um thick die (to make the math work out nicely)
<azonenberg>
You're looking at 20 hours to destruct
<rqou>
and the project turned into "make a die able to jump in the air"
<azonenberg>
The easiest option is to have the die be of no security value
<rqou>
nah, there's a better way
<azonenberg>
i.e. sensitive data (firmware, bitstream, whatever) is all in sram
<rqou>
apparently somebody in the lab was playing with some XeF2
<azonenberg>
And you have the tamper boundary simply zeroize the ram
<azonenberg>
Another issue is, if you decap the xef2-encapsulated chip
<azonenberg>
a small amount may turn into HF
<rqou>
and noticed that if you just pressed the die against the solid XeF2 it would react "vigorously"
<azonenberg>
Interesting
<azonenberg>
Still, doesnt seem super practical to trigger
<rqou>
so the thing to make darpa happy turned into "yeah, we used a normal mechanical spring"
<azonenberg>
and it's no more effective than say thermite
<rqou>
it's slightly better
<rqou>
they had a die, some Al foil with a heater wire, and some mechanical spring/piston thing
<rqou>
it was triggered by heating the wire which broke the Al foil
<azonenberg>
How did they keep the XeF2 fumes from wrecking the die normally?
<rqou>
the Al foil
<azonenberg>
oh so the foil was gas-tight
<rqou>
yeah
<azonenberg>
not just sitting there
<azonenberg>
interesting
<rqou>
it's not nearly as secure as ZoidbergHSM
<rqou>
anyways, the actually cool project was when they made a die that could jump
<rqou>
i had no idea you could do that without breaking it
rohitksingh_work has quit [Read error: Connection reset by peer]
soylentyellow has joined ##openfpga
<tnt>
Anyone know why the iCE5LP4K the only one without PWM hard ip ? Is that "hard ip" really just a soft IP they put in the unused logic of the smaller ones ?
<daveshah>
tnt: for the iCE5LP, yes
<daveshah>
the actual hard IP in it is broken and disabled for some reason
<daveshah>
but so they could still advertise it, they replaced it with fake hard IP that actually just uses the unused logic elements
<daveshah>
I think you can still use it in the 4k, at the expense of 300 LEs or so
<tnt>
daveshah: ok :) Yeah that table looked suspitious to me.
<daveshah>
but the lower devices are actually 4k dice with a soft resource cap, that excludes the RGB IP, so you don't lose LEs
<daveshah>
the RGB IP in the ultralite and ultraplus is real BTW
<tnt>
ok, good to know, thanks.
rohitksingh has joined ##openfpga
soylentyellow_ has quit [Ping timeout: 260 seconds]
rohitksingh has quit [Quit: Leaving.]
genii has joined ##openfpga
soylentyellow_ has joined ##openfpga
Bike has joined ##openfpga
ondrej2 has quit [Quit: Leaving]
rohitksingh has joined ##openfpga
m_t has joined ##openfpga
* tnt
just found out about "Lattice Radiant"
m_t has quit [Quit: Leaving]
rohitksingh has quit [Quit: Leaving.]
angl has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
xdeller has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
indy has joined ##openfpga
<awygle>
oh wow TIL you can't have one font for all of unicode, even ignoring all the regional complexities, because the font formats won't allow it
<rqou>
wait what?
<rqou>
"won't allow it"?
<awygle>
apparently only 65535 glyphs per font
<rqou>
lololol
<awygle>
due to using a uint16 for indexing
<rqou>
i wonder what symbola does
<bofh_>
symbola doesn't have >65535 glyphs, lol.
<rqou>
it doesn't?
<bofh_>
like it has no hanzi for starters, that's a huge chunk of the BMP and the *entire* SIP.
<rqou>
aaah
<rqou>
yeah, that solves it :P
<awygle>
there are "font stacks" that you can use to work around this apparently. but i am like a leetle bebe in this field so i don't really know what that means
digshadow has quit [Ping timeout: 260 seconds]
<cr1901_modern1>
Can't you draw lots of glyphs by "combining" them into one?
<Bike>
i don't think you could draw hanzi just out of radicals. not sure tho.
<rqou>
you can, but *) i don't know how good it will look *) i don't know how much space that will actually save
rohitksingh has quit [Ping timeout: 248 seconds]
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
m_w has joined ##openfpga
digshadow has quit [Ping timeout: 256 seconds]
digshadow1 has left ##openfpga [##openfpga]
digshadow has joined ##openfpga
<rqou>
ugh this nixie driver is way more complicated than i expected
rohitksingh has joined ##openfpga
<rqou>
i just remembered that P-FETs are awful
<rqou>
so building the high side switches will be "fun"
<rqou>
since i already need custom magnetics i might just stack some extra windings to create a higher voltage for doing gate driving
<shapr>
oh, is the translation linked somewhere?
<rqou>
give me some time to scan the original better and package them together
<shapr>
awygle: are you streaming glasgow rev 2 work?
<rqou>
anyways, taking power electronics seems like it was totally worth it
<rqou>
being able to do custom magnetics and dc-dc converters opens up so many possibilities
<awygle>
shapr: uh I can if you like and are in a compatible time zone
<awygle>
rqou: just make the pfet bigger, problem solved
<rqou>
yeah, but then they cost a lot more $$$
<shapr>
I'm in EST
<rqou>
very few people want ~400V P-FETs
<rqou>
yeah they exist, for like an OOM more than N-FETs
<shapr>
yeah, took me forever to find a benchtop power supply that would do 400+ volts, but I finally got one for free!
<rqou>
and just stacking on some more windings is pretty simple given that i don't really care how good the cross regulation is
<rqou>
you just gain some fun complexity with a floating gate drive
<rqou>
as in, floating 400V above the rest of the circuit
<shapr>
according to my research, that was the last heathkit model that had tubes
<rqou>
how much power?
<shapr>
?
<rqou>
max current?
<shapr>
oh, I don't know. I've never had a PSU before. I'm as far aways from having an EE degree as possible.
<shapr>
I've never owned an oscilloscope either.
<rqou>
hmm actually
<rqou>
i don't know if I actually need this
<sorear>
shapr: o/
<shapr>
hi sorear!
<rqou>
because the source of the FETs is way below 400V
<rqou>
wait
<rqou>
nvm
<rqou>
no it isn't
<rqou>
anyways, in case anybody was wondering how you get those crazy flyback transformers with all kinds of extra windings, this process is one way :P
<awygle>
sounds like i should have taken power electronics
<awygle>
i wonder if i can get glasgow rev B and a blinky bitstream for smolfpga both done tonight and still get 8 hours of sleep before leaving for portland..
<daveshah>
awygle: do you have anything you need from me for ice40lm? Pretty tired tonight so will be going to sleep soon
<daveshah>
Next step should be generating a chipdb using icebox_chipdb
<daveshah>
Then the modifications to get arachne-pnr to accept that are trivial (10 lines)
<awygle>
daveshah: na i think i'm good :) i'm sure i'll be back to annoying you once i get to the hard ip, but i'm not setting a timetable for that yet
<daveshah>
awygle: yeah who cares about that :P
<awygle>
hehe
<awygle>
i'm a completionist
<daveshah>
Internal oscillators are the next step I suggest
<daveshah>
Hard IP won't be too hard anyway
<awygle>
yeah internal oscillators seem useful
<daveshah>
It just connects through IO tiles from my memory of the LM architecture
<daveshah>
You could just treat the hard IP as an external peripheral and supply a suitable PCF file...
<daveshah>
(not a serious suggestion)
<awygle>
haha
<daveshah>
Tracing the connections should be easy, just small changes to the scripts I made for the UltraPlus
<daveshah>
But they'll need to be handled differently in arachne-pnr because in the ultraplus they were effectively fake logic cell IO rather than fake external IO
<awygle>
right
<awygle>
i looked at that a bit
<daveshah>
Fake logic cell IO sounds dodgy, but it's how all functionality - except logic cells - in the ECP5 is connected to the fabric...
<daveshah>
Luckily using their TCL API it is possible to trace those automatically
<awygle>
looking forward to getting done with LM so i can work on trellis a bit. probably not til june though..
<daveshah>
I will be awesome having you on board for that. Help is definitely needed
<daveshah>
Particularly by that point, when more infrastructure will be in place and lots of fuzzers will need to be written for all functionality
<daveshah>
IO, IOLOGIC, EBR, DSP, SERDES, etc
<awygle>
that's the stuff i'm most interested in anyway, so it works out :p
<awygle>
hm. what software does everyone use to just... program SPI?
digshadow1 has joined ##openfpga
<awygle>
i just want a linux command line tool that takes a /dev node for an mpsse cable and a .bin file and programs SPI FLash
<rqou>
flashrom?
<rqou>
(from the coreboot project)
digshadow has quit [Ping timeout: 246 seconds]
<awygle>
hm yeah maybe
<awygle>
sort of worried i'll typo a command and brick my laptop lol
<rqou>
loo
<rqou>
lol
<rqou>
yeah, it has a warning for that :P
<awygle>
that's good
<daveshah>
awygle: iceprog
<daveshah>
It works with a mpsse cable
<daveshah>
Supports basically any flash device
<awygle>
huh, ok
<rqou>
wait it does?
<awygle>
i thought it was just for the icestick and other lattice dev boards
<daveshah>
Yeah
<rqou>
huh
<daveshah>
No, just needs any FTx232H
<rqou>
as much as flashrom?
<daveshah>
Probably some really obscure flash chips that fail
<daveshah>
Never had a problem myself
<daveshah>
There's a PR for one flash chip that has problems that's open (can't be merged because it causes other issues)
<rqou>
you should advertise this capability more :P
<daveshah>
Yeah it's actually really nice
<daveshah>
I know it's worked with everyone's upduino, and they were using random flashes off the Chinese factory floor
<daveshah>
Some even came pregorammed with data from a cisco router
<awygle>
lol awesome
<daveshah>
Many models were in circulation
<awygle>
i just used whatever tinyfpga used
<rqou>
lolwtf
<awygle>
so i suspect it'll be fine
<rqou>
why is the upduino so crappy?
<daveshah>
I'm sure it will work
<daveshah>
because 8$
<rqou>
oh
<daveshah>
Except its 10$ now
<rqou>
i didn't know that
<daveshah>
The one with a ftdi programmer on and a ground plane (albeit a useless one) is $17
<daveshah>
AFAIK the guy that did the UPDuino is somehow associated with Lattice
<daveshah>
So almost certainly getting chips for free or next to nothjng
<daveshah>
It's actually listed on the Lattice website for some reason
bitd has quit [Quit: Leaving]
<awygle>
i think of it as lattice stumbling mostly-incompetently into realizing the potential of the maker movement
<awygle>
(ugh i can't believe i just typed "the maker movement")
m_w has quit [Quit: Leaving]
<awygle>
it seems like they've realized that far from being a bad thing, the ice40 RE has been great publicity for their low-end parts
<awygle>
and are trying to capitalize on it in a bumbling corporate kind of way
<daveshah>
awygle: I don't know if you heard, but their European sales division even let us give a workshop and talk on icestorm at an official Lattice event recently
<awygle>
i saw that on twitter yeah
<daveshah>
They certainly aware of it
<daveshah>
*are
<awygle>
hmm... potentially high-risk, but has anyone talked to them about trellis?
<daveshah>
No comment
<awygle>
lol fair
<daveshah>
Long story
<kc8apf>
heh, yes, long story
<cr1901_modern1>
what is trellis?
m_w has joined ##openfpga
<daveshah>
cr1901_modern1: the project to document the ecp5
<cr1901_modern1>
noted. I have no idea when I'll actually get to it tho. I can't even grok the ice40 docs well
<daveshah>
cr1901_modern1: sure. Another place to start would be to do the ice40 ultra
<daveshah>
Or UltraLite
<daveshah>
Tbh I went into the ultraplus without understanding a lot of the icestorm docs
<daveshah>
Was much easier to learn by playing about imo
<cr1901_modern1>
This isn't a slight on anyone's technical writing skills. I don't know if it's possible to make RE docs of this nature pleasant to read.
<awygle>
Seconded. The docs are not good.
<cr1901_modern1>
(for me anyway)
<awygle>
And they don't obviously map to the code.
* kc8apf
is writing a blog post on 7-series bitstream format at the moment
<daveshah>
Yeah, I've found it's all too easy to treat the docs as a personal brain dump rather than as a general resource
<daveshah>
I think once you have a FPGA architecture in your head, it's intrinsically quite hard to go back to the point of not understanding it in order to write accessible docs
<cr1901_modern1>
Curse Of Knowledge
<awygle>
That's true of everything
<kc8apf>
writing intro docs is a unique talent
<awygle>
If it wasn't so flow breaking I'd write blogs while I was teaching myself
<awygle>
But then everything would take six times as long
<kc8apf>
unless those docs helped other people get on the same page so they can help you along
<awygle>
True. It's more practical for longer term projects. Unfortunately I kind of suck at longer term projects. It's a personal flaw I'm working on.
<balrog>
sounds like MAME :/
<balrog>
"just look at the implementation, it's self explanatory" -- well if you haven't been working on it for years, it's not so much
<awygle>
Yup. It's really rough for corporate projects too. Only fresh eyes can see the problems, but only experienced eyes can fix them (for some values of "only" in either case)
<tnt>
Anyone familiar with iceprog internals ? I'm trying to make it work for a jtagkey2 and failing miserably :/
<rqou>
iirc it's your typical mpsse mess
<rqou>
but if you're using the jtagkey line specifically, they have some output enables that you need to enable
<tnt>
yeah ... and in set_gpio I just don't understand why the gpio var is initialized to '1' ...
<daveshah>
tnt: I think that defaults to either creset or cdone high (I can't remember which is which)
<daveshah>
Beware also that the MPSSE chip select is not used from memory, a gpio is used instead
<daveshah>
If using a generic breakout, best bet is to copy a Lattice dev board for the wiring
<daveshah>
Not sure about how the jtagkey works
<daveshah>
Chip select is ADBUS4
<tnt>
yeah, the jtagkey is the only ftdi I have basically so I have to deal with that and however it's wired.
<tnt>
and I'm pretty sure set_gpio is the only think I'd need to change but ... well, not working out so I'm trying to understand because initializing that gpio var to '1' makes no sense to me since the LSBs of that byte are not the GPIO AFAIK
<tnt>
ADBUS0 should be clock
<daveshah>
tnt: my only guess is its to prevent spurious clock toggles
<daveshah>
If clock is high at that point
<rqou>
holy shit i just realized that I haven't been on Sproul in months
<rqou>
gotta appreciate the chaos one last time :P
<daveshah>
Looks like the dictionary contains the 8 most common 8-bit patterns according to their bitstream docs
<awygle>
that's not very interesting to me, the actual reverse engineering is not something i care about. just the open source tools.
<awygle>
so low priority, like you said
<daveshah>
Sure, it doesn't even matter for the ecp5
<daveshah>
Where there is inevitably copious spi flash
<daveshah>
Only needed for MachXO2 internal flash usage
Bike has quit [Ping timeout: 260 seconds]
<awygle>
mhm
<awygle>
hm i guess implementing the decompression shown in that patent would violate it, huh
digshadow1 has quit [Ping timeout: 255 seconds]
<q3k>
isn't it just an US patent?
<pie_>
q3k, still seems like an issue when a large portion of your collaborators are us based or something...
<pie_>
so, what happens if you violate a us patent while not being in the us, but host on us servers? :D
<pie_>
guh. licensing sucks. people needing to make a living sucks.
<q3k>
pie_: step 0) don't host on US servers
<pie_>
\o/ :D
<q3k>
(it's expensive and DMCA is too easy to abuse)
<pie_>
osmething something github
GenTooMan has joined ##openfpga
digshadow has joined ##openfpga
<rqou>
are there any popular git hosts outside the US?
<rqou>
gitlab is also US-based
<q3k>
just run gogs/gitea/gitlab/cgit on your own
<rqou>
somebody should make a git"coffeeshop" :P
<q3k>
unless you're hot for the 'social coding' part of it
<rqou>
i'm sure that will still be popular with certain developer demographics here :P
<q3k>
I use code.hackerspace.pl, but that's only for hswaw members
<rqou>
yeah, my server is still in the US
<rqou>
got good connectivity here
<q3k>
anyway, if you're a US citizen this is probably useless anyway
<kc8apf>
gitlab can be run anywhere
<rqou>
but seriously, somebody please make git"coffeeshop"
<rqou>
i'm sure all the "rubyists" will like it
<q3k>
kc8apf: not that it should :P
<rqou>
wait, the "rubyists" are the ones that wrote Homebrew, right?
<q3k>
git.dragonsector.pl.... is using 6GB of RAM for gitlab right now
<q3k>
even tho it has 0 traffic
<rqou>
the thing that they clearly took too many bonghits before writing
<awygle>
i don't even get your reference this time, rqou. wtf is git"coffeeshop" supposed to be
<rqou>
"coffeeshop" is a place in NL where you can smoke weed
<awygle>
ah
<awygle>
here we just call them weed shops
<awygle>
there's one kitty-corner from my apartment. they're putting in an outdoor balcony, i have the chance to voice my opposition at the next town hall meeting.
<awygle>
are gogs and/or gitea any good?
<q3k>
pretty devent
<q3k>
*decent
<q3k>
gitea is a fork of gogs that's community maintained
<q3k>
gogs has a BDFL that disappears for weeks sometimes
<awygle>
am i the only one who thinks that if your github alternative is hosted on github... you're sort of admitting defeat right out the gate?
<q3k>
i don't think they scale at all though (not that gitlab does)
<q3k>
I really want a git hosting setup where the repos aren't just bare git repos on a filesystem
<q3k>
it's such a beautiful thing to fit into distributed storage.
<awygle>
what would your alternative look like?
<q3k>
have a CAM of hash -> {commit,blob}
<q3k>
shard and replicate as needed
<rqou>
^
<q3k>
+ inter-region replicas for resilience
<awygle>
hm
<q3k>
and then next to that a traditional database to map project/repo/branches/tags to commit hashes
<awygle>
is that a common thing? distributed CAMs?
<awygle>
(this is another space i know next to nothing about)
<q3k>
as long as you have a nicely spread out key (you do) that is the only thing you need to look up by (it is at the lowest layer) then yes
<q3k>
you can even use a fuckton of postgresen/mysqlen
<q3k>
it's the easiest form of database
<q3k>
i would maybe try to map it into ceph object storage?
<q3k>
seems like the best solution OOTB
<q3k>
of course, you still want to cache look ups
<q3k>
notably, trees (ie. have storage of commit hash -> tree data of the parents of that, maybe limited to N commits back)
<q3k>
otherwise retrieval would be slow
<q3k>
but the nice thing is that once a commit hash exists, it never changes
<q3k>
so there's no need to flush any caches because data changed
<awygle>
this sounds cool but also way over my head...
<q3k>
and the best thing is that you share data cross repos (a fork of linux is instant, free, and basically a COW)
<q3k>
I mean, I might be missing something
<q3k>
gitlab kiiinda started implementing that
<q3k>
ie they finally have a git repo service thing
<q3k>
but it's still backed by NFS (whyyyy)
<q3k>
from what I can tell gitlab wasn't really designed properly - just started as a shitty stateless rails app with an ORM-based database and keeping repos on the local filesystem
<q3k>
and then stopped scaling at some point
<q3k>
(another reason for the DB nuke accident they had - they have >the< production database that's an SPOF)
<q3k>
(another reason for the somewhat frequenc NFS outages they had)
<q3k>
(I think they just ended up paying some enterprise vendor for $magic_sauce_nfs_share)
<sorear>
So does gaffe talk to xc2bit
<q3k>
even 9p is better than NFS for this
<awygle>
on the one hand i'm like "jeez guys design things to scale"
<awygle>
but on the other hand i'm kind of sympathetic to not overdesigning
<q3k>
of course.
<rqou>
git sounds pretty trivial to scale up though
<q3k>
I do think they were extremely shortsighted/understaffed
<rqou>
er, for just the storing/retrieving objects part
<q3k>
ie the moment they saw that the business is taking off, they should've noticed that NFS is not going to cut it
<rqou>
the local client part has totally different scalability problems
<q3k>
and allocated a bunch of engineers to R&D on a future storage backend
<q3k>
which, AFAIK, they didn't
<awygle>
there's some sort of critical ability to carve out space for forward-looking stuff that seems really difficult to achieve in companies
<q3k>
I even applied to them once after their DB failure because I noticed that they're having issues then maybe I can solve it.
<q3k>
Got to HR, HR asked me to answer a few questions including 'how would you solve gitlab scaling issues', I answered it in the required response size.
<q3k>
Got rejected without talking to anyone technical ¯\_(ツ)_/¯
<q3k>
I might have been full of shit, but at least I expected them to tell me so.
* q3k
ramble ramble
* awygle
rabble rabble
<awygle>
container stuff is so far up in the clouds
<rqou>
lol
<awygle>
I'm reading about argo
<awygle>
It mostly sounds pretty cool but it occasionally uses phrases that I'd expect to sound horrified in a bragging way
<kc8apf>
sorear: nope. I haven't started to look into xc2 yet.
<awygle>
"Define workflows where each step in the workflow is a container."
<kc8apf>
awygle: heh. there's also Brigade
<awygle>
"Run rich CI/CD pipelines using Docker-in-Docker"
<q3k>
>docker-in-docker
<q3k>
wheee
<kc8apf>
when you want to build a docker image from inside a container
<q3k>
I know.
<q3k>
It's still terrifying.
<kc8apf>
indeed
<awygle>
I'm sure it's good and useful
<q3k>
Generally the workflow for building and managing docker images is horribad.
<awygle>
Just to people whose lives are very different than mine
<kc8apf>
eh, Dockerfile on GitHub with an automated build on Docker Hub is pretty straightforward
<q3k>
mostly the fact that passing options to docker containers is entirely untypes/schemaless
<q3k>
*untyped
<kc8apf>
deploying those containers is another matter
<q3k>
so it's annoying to chase out bugs
<q3k>
and to design your pipeline so it's doesn't break when someone forgets to change a parameter name here but not there
<q3k>
ie. the whole passing-args-via-env is extremely annoying
<rqou>
personally i hate the idea of "app containers"
<q3k>
i love the idea of self-contained applications
<q3k>
especially for production
<kc8apf>
argo helps quite a bit with those problems
<awygle>
app containers are the logical endpoint of your static linking mania, rqou
<q3k>
but I achieve it with fat binaries
<rqou>
yeah, i would have achieved those with either a) a static binary
<q3k>
via static linking
<rqou>
or a "packer"
<q3k>
yes
<rqou>
which can itself use cgroups
<awygle>
actually the logical endpoint is unikernels or library operating systems
<awygle>
but containers at least live on the same block
<q3k>
well, generally getting rid of POSIX as an abstraction layer
<q3k>
POSIX is horrible
<rqou>
i like system containers
<q3k>
UNIX is horrible
<q3k>
it just doesn't work these days
<kc8apf>
static binaries still need other bits to handle resource isolation
<awygle>
okay but what's the alternative
<rqou>
i would probably prefer something halfway in between
<q3k>
awygle: none yet
<rqou>
e.g. "a LAMP container"
<q3k>
awygle: that's the thing
<rqou>
not "i ran a single go binary in a container"
<q3k>
kc8apf: yeah, gvisor is probably good here these days
<q3k>
kc8apf: i used to use nsjail for that
<awygle>
for me, unix is not as terrible as implementing the alternative would be. *shrug*
<q3k>
kc8apf: but that's basically superceded by gvisor
<rqou>
so my idea would mean that the container still has e.g. a zombie reaping init
<rqou>
and can run more than a single process
<q3k>
rqou: you need something that reaps zombies in a pid namespaces
<awygle>
oh brigade is from MSFT. it might actually be shaped like my brain then.
<q3k>
rqou: if you have any sort of fork/exec/processes
<rqou>
yeah, you can use some kind of trivial init
<kc8apf>
awygle: they acquired it
<rqou>
imo if you have e.g. "just a single go binary" you can just invoke the necessary cgroups/namespace syscalls on yourself
<rqou>
rather than having somebody externally box up the program with this huge "framework"
<q3k>
rq
<q3k>
whoops
<q3k>
not from go
<q3k>
because of the threading model of go
<awygle>
"kubernetes-native" is a deeply upsetting turn of phrase...
<q3k>
(it's fucky - go doesn't let you have a meet-me-point where all processes are moved into the same namespace, because it immediately starts off in multi-proc mode if you want multiple cpu threads)
<q3k>
also I don't like the idea of processes daemonizing/cgrouping/jailing themselves
<kc8apf>
there's a whole bit about trust. environment needs to be isolated from the host OS _before_ the binary is run
<q3k>
you end up with a) everyone having to reimplement the same shit b) no clear interface/supervision
<q3k>
systemd gets this right
<kc8apf>
assigning unique IPs to each container is another big deal. Borg doesn't and port exhaustion is a pain.
<q3k>
let every process stay in the foreground and whatever spawned it handle taht and put it where it belongs
<q3k>
kc8apf: is it, really? never encountered that as an sre, maybe borg swe/sre handled it well enough by then already
<q3k>
kc8apf: i like the idea of ipv6 address per job/container/unit-of-job-scaling-and-replication
<q3k>
kc8apf: the fact that k8s ships with v4 by default is a joke
* kc8apf
Java MapReduces routinely burn all UDP ports. Creates a mess.
<q3k>
my team used flume, never had to touch a mapreduce in my life
<q3k>
and even when I had to touch flume jobs I just kidnapped a random SWE to help me out
<kc8apf>
turning on v6 in k8s is non-trivial
<rqou>
wut
<rqou>
why?
<kc8apf>
my home cluster gives out v6 addresses per pod but I can't reach external v6 addresses
<q3k>
what's your networking layer?
<q3k>
calico bgp should let you route to the internet
<kc8apf>
cilium
<rqou>
my network is v4+multiple v6 on every port
<q3k>
so should rudder/flannel with vxlan
<kc8apf>
oh, it should
<rqou>
there's a v6 global and a v6 ULA
<kc8apf>
I haven't bothered to figure out why it odesn't
<rqou>
ULA is flagged deprecated because v6 source address selection is dumb
<awygle>
jesus wtf is borg
<q3k>
kc8apf: huh, not a fan of having policy defined by a middleman like this
<rqou>
borg is google's internal cluster management thingy
<q3k>
kc8apf: proper grpc auth / acl is the way to go imo
<kc8apf>
cilium _can_ do policy
<rqou>
oh you two are still talking about google crap :P
<kc8apf>
but it's mostly about leveraging XPF for performance
<q3k>
kc8apf: so bpf is used to actually route here?
<kc8apf>
yup
<q3k>
that sounds overly complicated
<q3k>
i can't believe that this is actually faster than the linux stack :/
<rqou>
there are some proposals to replace all of *tables with eBPF
<kc8apf>
I ran calico previously. BGP peering outside the cluster is a big mistake
<q3k>
kc8apf: what was your setup? ibp, same ASN?
<kc8apf>
q3k: why? instead of loading IP tables with tons of rules, they get compiled into BPF
<q3k>
kc8apf: ... why iptables?
<q3k>
oh, for the service layer/network?
<q3k>
yeah, fuck that whole mess
<kc8apf>
metallb is much better
<awygle>
i need one of those burning brain memes for container shit...
<awygle>
what is a bare metal kubernetes cluster? that doesn't make sense to me
<awygle>
kubernetes isn't an OS (... is it?)
<kc8apf>
bare metal vs VMs
<q3k>
awygle: ie you run k8s on bare metal machines
genii has quit [Remote host closed the connection]
<q3k>
awygle: not in a cloud env where things are abstracted away for you already (like the network, storage...)
<kc8apf>
instead of GKE or ECS
<awygle>
i.... okay. sure.
<awygle>
is AKS==GKE==ECS? or are those ACI?
<q3k>
kc8apf: so is metallb supposed to run on the edge or for pod/service connectivity? the website isn't immediately telling
<kc8apf>
AKS==GKE
<kc8apf>
ECS isn't k8s, I think
<q3k>
ah, it's a LoadBalancer, so internal
<kc8apf>
q3k: metallb adds a loadbalancer-controller
<q3k>
I want a better Ingress controller at some point
<q3k>
one that that terminates TLS and provides beyondcorp/uberproxy-like SSO
<q3k>
for small deployments where these things can be collapsed into a single layer
<q3k>
maybe with announcements via BGP to let your ECMP-compatible edge router know where to send you traffic
<kc8apf>
In my case, the k8s cluster runs 10.x.x.x inside the cluster. Internal LB gets a 10.x.x.x. MetalLB is BGP peer to my router and sets up the external routes.
<kc8apf>
Ingress is then nginx on top of that
<q3k>
so the metallb external routes there are for non-k8s services to be able to access k8s?
<kc8apf>
I've found at least one ingress-controller that adds OAuth checking
<q3k>
i looked at nginx/oauth combos and they all stick
<q3k>
*stink
<awygle>
so is it possible to run "bare metal" kubernetes on somebody's cloud? or is that sort of inherently non-bare-metal?
<kc8apf>
q3k: yes. I run my Unifi AP controller on k8s. AP is outside k8s but can talk to it
<awygle>
i don't really get why VMs would come into this in the first place tbh...
<q3k>
ie they don't cookieshare between domains, so you need to have an oauth client per domain
<q3k>
which is stupid
<kc8apf>
awygle: when you use GKE, the k8s master is completely managed for you and nodes _must_ be GCE VMs
<kc8apf>
same for AKS
<q3k>
i want login.X.com to be an OAuth client, and then let other services confirm identity from there instead
<kc8apf>
bare metal means you are providing the nodes, be that actual hardware or your own VMs
<rqou>
wtf why is this all acronym soup?
<awygle>
okay
<awygle>
so nobody offers "yo i have some machines, i will give you containers on them, and also a nice API to programmatically create more"?
<kc8apf>
q3k: I found one that does that. I don't recall the name.
<awygle>
without VMs?
<q3k>
awygle: if you wanna mess about with k8s, check out GKE, it's really good to get started, although pricey
<q3k>
kc8apf: link me if you find it, because I have a design doc started for that already :P
<q3k>
kc8apf: and I don't want to reinvent the wheel too much
<awygle>
all this shit akes me want to run screaming into the night, but also makes me want to run a datacenter and print money
<rqou>
apparently datacenters are really expensive to operate
<q3k>
power is expensive.
<kc8apf>
awygle: GKE is "I don't want to think about setting up k8s or dealing with hardware. Just give me a k8s master to talk to."
<q3k>
internet is ecpensive.
<q3k>
otherwise, eh, you can do everything else super cheap (but you get what you pay for)
<awygle>
kc8apf: i think maybe i have a bad internal model of k8s
<rqou>
datacenter internet is much less expensive than US last mile
<q3k>
if you find a location you can just dump the hot aisle air outside then you don't even need cooling :P
<rqou>
US last mile is just so insanely expensive
<q3k>
rqou: if you want unmetered, commited, it's stil not cheap
<rqou>
that's why you repeatedly hear ideas of "let's use satellites to bypass the last mile"
<kc8apf>
awygle: k8s runs on top of a host Linux install. k8s handles launching docker containers on some node within the k8s cluster.
<awygle>
i basically think of k8s as "i want to do cloud stuff but i don't want to be beholden to {google, microsoft, amazon} so i invented a shim layer on top of those clouds so i'd be more portable"
<rqou>
or "let's shoot surface waves in between the old POTS wire because we _just_ can't get new wires"
<q3k>
rqou: he.net transit 100Mbps burstable to 1Gbps is $200 p/m
<q3k>
and then he.net transit is Not Great (tm)
<kc8apf>
awygle: pretty much. k8s is job scheduling on top of Linux.
<rqou>
really?
<rqou>
i've always heard that he.net is pretty good
<q3k>
depend
<q3k>
*depends
<q3k>
they oversubscribe a lot (as you saw, 5x)
<rqou>
also, $200 p/m isn't _that_ expensive compared to comparable home internet speeds
<q3k>
and then they announce prefixes everywhere so sometimes it gets fucky
<q3k>
I pay around $100 for 300Mbps consumer grade DOCSIS here
<rqou>
yeah, but you're in europe
<rqou>
not with our insane last-mile prices
<awygle>
so you run k8s on top of N linux machines (real or virtual) and the k8s master calls k8s workers and they call docker to make containers to run a program? that seems semi-reasonable if kind of a deep stack
<q3k>
it's still more expensive than Poland
<q3k>
I paid around $30 for the same deal in Poland
<kc8apf>
awygle: yup. that's the idea
<kc8apf>
kubelet runs on each node and makes sure the containers get restarted, etc
<q3k>
awygle: you haven't seen deep stacks :P
<kc8apf>
if a kubelet disappears, the master reschedules the jobs onto other nodes
<q3k>
*ahem* bigtable on colossus on bigtable on bigtable on bigtable... *ahem*
<q3k>
(which is public! at least, there's some google slides about it)
<kc8apf>
q3k: I was the bottom of the stack for a long time.
<awygle>
i don't get why docker is involved, and adding VMs seems like a waste, but sure
<q3k>
kc8apf: chubby?
<kc8apf>
q3k: SVS
<q3k>
don't know that acronym.
<kc8apf>
q3k: per-machine health monitoring daemon
<q3k>
oh
<rqou>
q3k: here 1 gigabit docsis is apparently $126 p/m
<rqou>
consumer-grade
<q3k>
kc8apf: when was that?
<kc8apf>
awygle: docker is used to handle launching an isolated job
<kc8apf>
q3k: 2009-2014?
<rqou>
huh, afaict this is actually less than it was before
<q3k>
kc8apf: I remember other daemons for that from my time at the gurglers (until a year ago)
<awygle>
so if k8s is orchestrating all the containers, why do i need argo/brigade to orchestrate my orchestration?
<q3k>
kc8apf: yeah, I think it got replaced
<rqou>
must be Sonic giving comcrap a nice kick in the ass
<q3k>
kc8apf: I worked on the New GTape (tm)
<q3k>
kc8apf: some really cool shit I wished I could talk about
<q3k>
,_,
<kc8apf>
q3k: yeah. I started the project to replace SVS as my noogler project. Only took 7 years.
<q3k>
heh
<kc8apf>
awygle: k8s is an intent-based system. you describe the jobs you want running and it will make it so
<kc8apf>
argo is providing a way to say: run this, save the data over here, then run this
<kc8apf>
k8s has no notion of ordering
<awygle>
hm. okay... so k8s is more for "i have all these microservices, i want them to run forever"
<q3k>
awygle: and before you complain that it's too much turtles, the separation does make a lot of sense
<kc8apf>
awygle: yup
<q3k>
awygle: not necessarily forever
<q3k>
awygle: there's also different scheduling types in k8s
<awygle>
and argo is more like "i have a task, the task is a DAG, i want to do the task and then stop"
<pie_>
kc8apf is an intent-based system. you describe the jobs you want running and it will make it so
<kc8apf>
or one-shot tasks
<kc8apf>
pie_: heh
<pie_>
x'D
<q3k>
awygle: either one-shot pods, or Nx pods guaranteed to run, or Nx replica sets with different versions changing over
<q3k>
awygle: it's layered, like an onion.
<awygle>
q3k: i mean... it's a _lot_ of turtles. i'm willing to accept that it's good and useful, but that's more faith in smart people than any kind of emotional resonance.
<q3k>
awygle: because it makes sense for one part to be just responsible to run a pod until it can, another to make sure there's at leat this many of this pod running, and another to make sure that we can roll forward/back different versions of the same pod
<q3k>
awygle: all of this starts making more sense where you're in a murder mystery^W^Wmicroservice setup
<awygle>
mhm
<awygle>
i'm sure
<q3k>
and it's also much less magical than it appears to be
<q3k>
(honestly)
<q3k>
k8s is somewhat complex at first glance
<awygle>
yeah i'm sort of wildly vascillating between feeling like it's magic and feeling like it's a gigantic kludge
<q3k>
but then once you get it running it really boils down to being a directory of things (resources) you want to have, and k8s make sure that it's the case
<q3k>
which is a fitting way of thinking about it
<rqou>
i've found that almost all of these tools are awful for my use case
<awygle>
that description makes it sound like super-Puppet
<q3k>
rqou: absolutely
<rqou>
which is usually "i have _one_ machine, i want to run a thing"
<kc8apf>
awygle: both? k8s is an improved kludge after learning from Borg
<awygle>
but i thought that was uh... Terraform
<pie_>
use nix
<q3k>
rqou: you shouldn't even attempt to run k8s until you have a) monitoring b) provisioning / config management c) shared storage d) machines dying regularly
<kc8apf>
awygle: terraform only changes things when you run it
<rqou>
but somehow people want to package all their fancy shit into these frameworks
<kc8apf>
k8s is constantly ensuring jobs are running
<q3k>
awygle: also terraform is for cloud resources, not software
<rqou>
whereas i usually have "i have one machine. if it's broken, i'm sorry too bad"
<q3k>
awygle: terraform will create your EC2 instances, your VPCs, your RDSes
<q3k>
awygle: also terraform will suck the life force out of you because it's shit
Bike has joined ##openfpga
<rqou>
idk if you should be blaming docker or ruby for that rant i linked
<kc8apf>
q3k: seems to be true of most HashiCorp products
<rqou>
but still, this shouldn't be this difficult
<q3k>
(mostly the DSL they have, but also the broken statefile management)
<q3k>
kc8apf: vagrant is... barely okay
<q3k>
kc8apf: but yes, everything else is just extreme vendor lock-in in open source disguise
<awygle>
christ. okay so you'd (in theory) have Terraform magic up a Kubernetes cluster which would use Docker to magic up a bunch of containers, and then Argo would poke Kubernetes to change the extant containers in some kind of structured way?
<q3k>
something like this
<q3k>
again, you really shouldn't need to do any of this unless you can't remember how many servers you have
<awygle>
sure
<q3k>
definitely be aware of it adn don't write yourself into a corner with the software you're developing
<q3k>
but don't go all out
<awygle>
i just have this tick where i have a hard time using something if i don't like, believe it works
<awygle>
so it's hard to use (e.g.) AWS Lambda without having some way to picture wtf is actually happening
<q3k>
aws lambda is actually pretty fantastic
<awygle>
i am way more tempted to use the Azure version
<awygle>
in general Azure makes more sense to me than AWS
<q3k>
I used it to add some indexes to uploaded S3 artifacts into dynamodb
<q3k>
and it just worked (tm)
<q3k>
I don't like the deployment setup (zipfiles?!?!)
<q3k>
but otherwise I can't complain
<awygle>
but yeah, the idea makes some kind of sense to me for certain things. especially things like a hypothetical place+route
<awygle>
"i want to do a thing in a bursty way on bajillions of machines"
<q3k>
calling into k8s from within a k8s cluster is still somewhat weird
<kc8apf>
I'm looking at argo so I can gather all the known parts from Vivado in one step and then run N copies in parallel to generate a bitstream per part
<q3k>
kc8apf: they have support for some oldschool clustering solution, no?
<kc8apf>
same for running the prjxray fuzzers
<kc8apf>
q3k: that's even worse to setup
<q3k>
kc8apf: like IBM-grade enterprise linux scheduling
<awygle>
have to imagine the licensing would be difficult
<kc8apf>
I know how to get Vivado running under Docker
<kc8apf>
and I already have k8s at home
<q3k>
kc8apf: you should talk to G33KatWork about his vivado-in-docker setup
<q3k>
ah, you already have your own
<awygle>
but yes, also a good example
<q3k>
I have ispLEVER running in docker
<q3k>
via wine
<q3k>
including some magical tooling to unpack installshield
<q3k>
fuck my life
<kc8apf>
prjxray database generation takes ~8h on a 16-core machine right now
<kc8apf>
q3k: I've been fighting with iCEcube2 to install it via docker
<rqou>
hooray for wine+binfmt_misc
<kc8apf>
some ancient QT installer that _requires_ X to do anything
<q3k>
eh
<q3k>
I can take a look some day
<q3k>
when I have time :P
<q3k>
I like forcing things to run under docker
<q3k>
worst case you manually unpack the installer
<q3k>
shouldn't be too difficult
<kc8apf>
I want to run the icestorm fuzzers in the same way I'm planning to run prjxray
<kc8apf>
i've been working on that
<kc8apf>
looks like QTResources containing zips
<q3k>
or then again
<kc8apf>
containing.....something
<q3k>
just run the installer in docker
<q3k>
then save/commit the image
<q3k>
dockerfile-less containers are sometimes okay for this like this
<kc8apf>
true
<q3k>
that reminds me
<q3k>
need to setup k8s in hswaw soon
<q3k>
once we have the yolocolo ready
<q3k>
was going to re-use coreos, but considering it's dead, I don't know how to proceed
<whitequark>
rqou: just use a gate drive transformer
<kc8apf>
I may rebuild my home cluster with Rancher
<q3k>
i was thinking of using it, too
<awygle>
kc8apf: q3k: thanks for the education, i appreciate it. hope i didn't sound too disparaging or anything.
<q3k>
i don't usually like automagic, though
<q3k>
awygle: you're very welcome
<kc8apf>
awygle: not at all. this is pretty normal for people just starting with this stuff
<rqou>
whitequark: is that really any simpler than adding a few more turns on a flyback?
<q3k>
also the deployment is supposed to be somewhat r&d-like...
<whitequark>
rqou: depends on what are you trying to do exactly
<whitequark>
either works
<whitequark>
GDT gives you more control
<q3k>
was thinking of rolling my own machine bootstrap setup, that would also take care of machine certificates / root of trust
<rqou>
i'll add that to the list of options to evaluate
<rqou>
but seriously, having the ability to design custom magnetics is actually really really cool
<zkms>
what are you designing custom magnetics for
<rqou>
flyback magnetics are almost always customized
<rqou>
because everybody wants something slightly different
<awygle>
kc8apf: in your opinion, is the fact that most people encountering this stuff for the first time freak out, due to essential or inessential complexity?
<kc8apf>
awygle: yes
<rqou>
or did you mean "what is the final application?"
<zkms>
latter
<rqou>
the final application is driving that crazy soviet 64x64 nixie display
<whitequark>
you buy the fucking coilformer and the fucking core and the fucking wire etc
<kc8apf>
awygle: also the current software has inessential complexity due to how it is built over time
<awygle>
unsatisfying, which means almost certainly correct :p thanks again
<rqou>
you also need to understand how to do the fucking calculations :P
<rqou>
otherwise you end up with a loud overheating saturating transformer that doesn't work :P
mwk has quit [Quit: leaving]
mwk has joined ##openfpga
<rqou>
whitequark: weren't you the one that was saying EE is intimidating? magnetics design can be intimidating too (just like other subfields like RF, etc.)
<G33KatWork>
I should publicize my dockver vivado stuff. I build it mainly to not pollute my main system with this stuff and the pain to make this work on arch instead of ubuntu
<G33KatWork>
but when I publizice it, I have to maintain it ;_;
<kc8apf>
G33KatWork: I'm going to push mine up to github.com/gaffe-logic