<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
<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
<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