s1dev has joined ##openfpga
noobineer has joined ##openfpga
noobineer has quit [Ping timeout: 240 seconds]
oeuf has quit [Read error: Connection reset by peer]
azonenberg_work has quit [Ping timeout: 240 seconds]
s1dev has quit [Ping timeout: 256 seconds]
m_w has quit [Quit: Leaving]
Bike has quit [Quit: Lost terminal]
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 244 seconds]
s1dev has joined ##openfpga
<rqou> esden are you in Vegas?
<mithro> Has anyone played with https://github.com/kactus2/kactus2dev ?
<esden> rqou: not yet, I arrive on Thursday.
azonenberg_work has joined ##openfpga
s1dev has quit [Quit: Leaving]
mumptai has joined ##openfpga
<awygle> azonenberg_work: HTSW?
<azonenberg_work> awygle: ?
<awygle> reflowable 100-mil headers
<azonenberg_work> oh
<awygle> samtec HTSW will def. work but probably on the high end price wise
<azonenberg_work> Is there a female version?
<azonenberg_work> i basically want something like a pmod connector but more pins
<awygle> there are tons of mating connectors
<awygle> idk which ones are suitable for reflow tho
<azonenberg_work> Yeah but how many are hi temp? :p
<azonenberg_work> exactly
<azonenberg_work> i want a reflowable 18-20 pin pmod connector
<azonenberg_work> And so far i dont think one exists
<awygle> any smd samtec can be reflowed
<awygle> im sure they have a tht female 100-mil i just haven't dug it up
<awygle> the hstw has a whole guide on paste-in-hole printing
<azonenberg_work> i'm looking at the SSW series now but that doesnt look reflowable
<azonenberg_work> yeah i saw that
<azonenberg_work> i specifically wanted either pth or smt with support pegs
<azonenberg_work> So it wouldnt shear off too easily
<azonenberg_work> But reflow compat is higher priority than being pth to me
<azonenberg_work> awygle: use case: making a starshipraider probe card
<azonenberg_work> basically a passive adapter that goes from the qstrip on the level shifter board to (in this case) 0.1" headers for low speed flying-lead probes
<azonenberg_work> plus a discovery eeprom
<pie_> i need to get a ups for a desktop machine, any recommendations?
<pie_> plan would be to protect against power surges and do a graceful shutdown on power loss
<pie_> inb4 $$$ :/
<pie_> actuall maybe i should ask the german guys because europe
<sorear> symbiflow/fpga-tool-perf contains dead links to files that have presumably not yet been posted
<sorear> it seems a little odd to me that we'd use the packer for lut cascading instead of including that in the cost function and letting SA decide if it's worthwhile. doing carry chains ahead of time is much less odd because carry chains are much less optional, if you have carry primitives then *not* packing them is very wasteful
<daveshah> LUT cascade is a bit tricky, because if you don't use it then you have to pack differently, because the LUT output can only be used in LUTCascade mode and not otherwise
<sorear> oh, we're doing lut+ff in packing?
<sorear> possibly interesting experiment: modify the timing database to say that cascading is exactly as fast as general routing. measure the timing difference of a cascade-packed and non-cascade-packed design to quantify the flexibility cost
<sorear> is it known whether cascading works with the carry chain?
<daveshah> We don't implement LUT cascade at all
<daveshah> IIRC the vendor tools don't combine cascade and carry
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
<daveshah> We do combine lut+ff because on tbe ice40 that's normally a trivial decision and halves place time effectively
<daveshah> IMO ramcascade will be more interesting
<daveshah> That's much easier to implement because ram is forced into columns anyway, so it's basically zero cost
<daveshah> And atm congestion does seem fairly high around ram sometimes
indy has joined ##openfpga
<azonenberg_work> Just kicked off a tiny new PCB to oshpark
<azonenberg_work> Now i have to design the actual io card (prototype)
<rqou> why are you working on starshipraider?
<azonenberg_work> rqou: $work wanted me to spend some time on the io buffer
<azonenberg_work> but i needed a bridge from the buffer to the outside world
<azonenberg_work> since most stuff doesnt have qstrips on it :p
<azonenberg_work> This is just a bridge from the qstrip native connector on the io card to 0.1" pin headers
<azonenberg_work> i'll make versions with mmcx's, sma's, etc too
mumptai has quit [Remote host closed the connection]
oeuf has joined ##openfpga
scrts has quit [Ping timeout: 256 seconds]
scrts has joined ##openfpga
cr1901 has quit [Ping timeout: 244 seconds]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
cr1901 has joined ##openfpga
Miyu has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
rohitksingh has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
bibor has quit [Quit: WeeChat 1.6]
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 256 seconds]
digshadow has quit [Ping timeout: 248 seconds]
X-Scale has joined ##openfpga
digshadow has joined ##openfpga
m_w has joined ##openfpga
X-Scale has quit [Ping timeout: 244 seconds]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<rqou> so i just now discovered that i can buy 1000 apa102 rgb leds for like USD$200
scrts has quit [Ping timeout: 244 seconds]
<rqou> why didn't i do badgelife? :(
<daveshah> istr some patent shit with leds like that
scrts has joined ##openfpga
<rqou> meh, don't care :P
<rqou> not for hashtag badgelife at least
<rqou> does anybody know if apa102 LEDs have the die attach issue that ws2812s have?
scrts has quit [Ping timeout: 244 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
<shapr> rqou: how'd you find that good of a price?
<rqou> AliExpress?
m_w_ has joined ##openfpga
Maya-sama has joined ##openfpga
scrts has joined ##openfpga
m_w has quit [Ping timeout: 256 seconds]
Miyu has quit [Ping timeout: 256 seconds]
X-Scale has joined ##openfpga
rohitksingh has quit [Ping timeout: 244 seconds]
m_w has joined ##openfpga
<rqou> so, according to my back-of-the-envelope estimates, the hardest part of badgelife is power budget
<rqou> how the heck do people manage to light LEDs for like a week on a coin cell?!
<shapr> rqou: I use a massive lipo
<shapr> with jst-2 plug so I can have one charging in the room, and one in my pocket
<sorear> green LEDs, voltage converters, and lenses?
<shapr> my team lead just put together his own defcon badge with neopixels and a rotary dial
<azonenberg_work> high brightness leds and pwm?
<shapr> rqou: I worked on a fairy godmother dress a few years back, we used 3x18650 packs and happily the play was done in a dim/dark theatre, so we could turn down the brightness
<sorear> Does that actually save energy vs. a constant low current?
<qu1j0t3> yeah you pwm so that they're only on when someone is looking!
* qu1j0t3 gets his coat
<shapr> human eyes average the brightness over time (1/24 of a second?)
<azonenberg_work> sorear: LEDs have a certain current where you get the max efficiency in lumens/watt
<azonenberg_work> For max battery lifetime you want to keep the current in that range and then PWM sharply on/off
<azonenberg_work> to vary perceived brightness
* qu1j0t3 learns
<azonenberg_work> While minimizing time in the linear region
<sorear> huh. I figured lumens/amp was constant and the game was minimizing forward voltage
<rqou> is there a reason why nobody seems to use the 2020 size apa102 leds?
<rqou> also apparently nobody puts sk9822s in the 2020 package?
digshadow has quit [Ping timeout: 240 seconds]
<rqou> i really wish i had the ability to wirebond my own leds :P
digshadow has joined ##openfpga
<rqou> azonenberg_work: challenge for you: figure out how to make those 64x64 soviet nixie displays run on batteries for a reasonable amount of time :P
<rqou> they're extremely power hungry
<rqou> also, potentially-can-kill-you badgelife sounds fun :P
<azonenberg_work> lol
inoor has joined ##openfpga
inoor has quit [Remote host closed the connection]
digshadow has quit [Ping timeout: 256 seconds]
<sorear> nuclear powered badge
<azonenberg_work> sorear: the black badge a few years ago was radioactiv
<azonenberg_work> e
<pie__> everything is radioactive
<pie__> question is how much :P
<pie__> too bad betavoltaic cells are so expensive (and so low power) :p
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
bibor has joined ##openfpga
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow1 has quit [Client Quit]
digshadow has quit [Ping timeout: 240 seconds]
<awygle> what subset of {MAC, PHY, driver} determines whether a NIC supports things like multiqueue in linux?
Maya-sama has quit [Ping timeout: 256 seconds]
m_w has quit [Ping timeout: 260 seconds]
Maya-sama has joined ##openfpga
ZipCPU has quit [Ping timeout: 240 seconds]
<jn__> awygle: i'm pretty sure the driver for the MAC layer has to at least communicate this to the rest of the system
ZipCPU has joined ##openfpga
<jn__> and i guess the MAC hardware also has to actually have multiple queues, else it won't make sense
<azonenberg_work> awygle: ^
<awygle> yeah that was what i was wondering, whether it's the MAC or the PHY that has the physical queues
<awygle> and/or if they each have to be designed for them somehow
<azonenberg_work> Doing the math it looks like the FPGA-side host interface on INTEGRALSTICK will be an 8-bit full duplex source sync LVDS bus
<azonenberg_work> plus 50 single ended GPIOs at your choice of VCCIO
<azonenberg_work> If i have free pins in bank 15 i might break some of those out to the q-strip too
Maya-sama has quit [Ping timeout: 244 seconds]
<azonenberg_work> Those will be fixed 3.3V
<awygle> at the user level, i don't have to do anything special to make use of scatter-gather DMA support, right? the driver will deal with that for me?
<jn__> awygle: i'm pretty certainly guessing it's in the MAC hw
<azonenberg_work> I also will need a level shifter because due to other constraints the FPGA JTAG will be 1.8V and the MCU 3.3
<azonenberg_work> awygle: yeah the MAC is where all the queueing is
<awygle> jn__: yeah, i expect you're right (which is of course the one part of the system i can't change :( ) thanks!
<azonenberg_work> at the PHY level you're going from whatever the wire format is to *GMII
iximeow_ has joined ##openfpga
<awygle> and i'm correct that without multiple queues there's no benefit to receiving from multiple threads?
<azonenberg_work> It depends on if you bottleneck with what you do with the data
<azonenberg_work> if you read a packet then spin for a while crunching it then one queue is plenty
<azonenberg_work> as far as bottlenecking in the tcp/ip stack i'm not sure
<awygle> i mean, if receiving isn't the bottleneck then surely there's no reason to receive from multiple threads regardless
<azonenberg_work> it may depend on the kernel driver for the nic etc
digshadow has joined ##openfpga
<rqou> azonenberg_work: thoughts on "use sr-iov and steal the VF into userspace bypassing the kernel"?
<azonenberg_work> ...
kristianpaul has quit [*.net *.split]
Lord_Nightmare has quit [*.net *.split]
lexano has quit [*.net *.split]
iximeow has quit [*.net *.split]
iximeow_ is now known as iximeow
Lord_Nightmare2 has joined ##openfpga
<rqou> this is definitely a thing btw
<rqou> just usually not with sr-iov but there's no reason why not
kristianpaul has joined ##openfpga
Lord_Nightmare2 is now known as Lord_Nightmare
<azonenberg_work> Hmmm so that wont work
lexano has joined ##openfpga
<azonenberg_work> So it looks like, FPGA side, INTEGRALSTICK has a total of 50x LVCMOS33, 9x LVDS, and 24 LVCMOS18 signals available
<azonenberg_work> to be routed to the host board connector
<shapr> yay, new fpga toy arrived, BeagleWire iCE40 FPGA Cape: https://twitter.com/shapr/status/1027333462435487746
<awygle> yay!
<shapr> Finally I have something that has both ice40 and pmod headers
Bike has joined ##openfpga