<qu1j0t3>
that you need a license better than "do whatever you want, i don't care" :)
<awygle>
oh lol well, yes
<awygle>
i meant a license in the FlexLM sense
<awygle>
"you can't run this unless you send us your MAC address for some reason even though it's not even using the internet"
<awygle>
... what happened in 1991?
<qu1j0t3>
oh
<qu1j0t3>
1991 was a random date, happens to be the date of gpl v2 tho
<qu1j0t3>
iirc
<awygle>
ah
* awygle
was <1 years old in 1991
<jn__>
"My MAC address? 46:55:43:4b:20:55!"
<qu1j0t3>
awygle: I'm sorry the whole thing was predicated on the wrong sense of "license", ignore me, it;s the red wine talking
<awygle>
mm wine
knielsen has quit [Ping timeout: 256 seconds]
marcan has quit [Ping timeout: 265 seconds]
marcan has joined ##openfpga
knielsen has joined ##openfpga
<qu1j0t3>
:)
GenTooMan has quit [Quit: Leaving]
noobineer has quit [Ping timeout: 260 seconds]
<pointfree>
Prf_Jakob: wow cool idea!
<pointfree>
Prf_Jakob: So is the idea to have an fpga or fpgas on a ram stick that one can put in their laptop or desktop and access from within linux directly instead of over usb?
<azonenberg>
pointfree: i think the goal is to have it just be a common physical form factor with readily available connectors
<azonenberg>
some of the aspberry pi modules are like that
<sorear>
I think I've heard of people using M.2 for pointfree's thing
<azonenberg>
jn__: lol
<rqou>
as a test i recently installed the ancient altera max+ii software and told the online license requester that my HOSTID was 000000000000
<rqou>
because wine didn't support obtaining any of them
<rqou>
worked :P
<pointfree>
sorear: hm interesting. Thank you
* pointfree
thinks his laptop has an M.2 slot for an fpga
rohitksingh_work has joined ##openfpga
Lord_Nig- has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 264 seconds]
Lord_Nig- is now known as Lord_Nightmare
Bike has quit [Quit: Lost terminal]
wpwrak has quit [Ping timeout: 240 seconds]
wpwrak has joined ##openfpga
<rqou>
arrgh how do i get rust to accept an Index trait without using a trait object?
<rqou>
why do all of these examples _suck_?
<rqou>
ah fuck it i'll just let it use a trait object
scrts has quit [Ping timeout: 260 seconds]
azonenberg_work has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
<whitequark>
awygle: sweeet thanks
scrts has quit [Ping timeout: 256 seconds]
wpwrak has quit [Ping timeout: 256 seconds]
wpwrak has joined ##openfpga
pie_ has joined ##openfpga
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
scrts has joined ##openfpga
renze has quit [Quit: Spaceserver reboot?!]
scrts has quit [Ping timeout: 260 seconds]
renze has joined ##openfpga
scrts has joined ##openfpga
<Prf_Jakob>
pointfree: Ah no nothing so clever, I justed need a lot of GPIO so was looking for a cheap connector with lots of pins that is small.
<Prf_Jakob>
So the SODIMM would be 4 or more layers and what you connect it to could be a cheap 2-layer board.
openfpga-github has joined ##openfpga
<openfpga-github>
openfpga/master 294fe0e Robert Ou: xc2bit: Decode via bittwiddler as well
<openfpga-github>
openfpga/master 8003153 Robert Ou: xc2bit: First port to using new bittwiddler
<openfpga-github>
openfpga/master 0593dd1 Robert Ou: xc2bit: Automagic bit packing - first test
<openfpga-github>
[openfpga] rqou pushed 8 new commits to master: https://git.io/vx7us
<whitequark>
azonenberg: hm why aren't you sleeping
<azonenberg>
whitequark: waiting for a P&R run to finish
<whitequark>
azonenberg: so I'm thinking about Glasgow
<azonenberg>
and?
<whitequark>
it looks like CY7C's slave FIFO interface, even when used synchronously, is timed in a way that only lets me grab one word per two IFCLK cycles
<whitequark>
and IFCLK is at most 48 MHz
<azonenberg>
So at max 24 Mword/s?
<whitequark>
indeed
<whitequark>
the FIFO interface can be 8- or 16-bit
<azonenberg>
You beginning to see why i went with Ethernet for starshipraider? :0
<whitequark>
I don't have the pins for 16 bits though on the main FPGA
<azonenberg>
:) *
<azonenberg>
it really does seem like the superior interface in most cases
<whitequark>
so I was thinking about adding an iCE40LP384 that would act essentially like a DDR SERDES
<azonenberg>
How many fpgas are you going to have on this thing? lol
<azonenberg>
what's the main one again?
<whitequark>
iCE40UP5K
<whitequark>
an alternative would be going with iCE40HX8K but that means losing 1 Mbit of single-port RAM
<whitequark>
oh and the HX8K packages suck
scrts has quit [Ping timeout: 256 seconds]
<whitequark>
it's either BGA or that 144-pin TQFP
<whitequark>
and like... no
<whitequark>
just no
<azonenberg>
bga is fine, but the ice40 bgas suck
<azonenberg>
they dont have any wirebonded bgas last i checked, basically all wlcsp
<azonenberg>
so you dont get sane pitches like 0.8 - 1mm
<whitequark>
wait what
<rqou>
there is a 0.8mm
<azonenberg>
oh?
<azonenberg>
not on the small ones right?
<azonenberg>
in any case 0.8 is still hard to use on oshpark
<azonenberg>
1mm is about the limit for large bgas there
<whitequark>
oshpark lol
<whitequark>
I'm going for dirtypcbs
<whitequark>
they're next door and much cheaper
<azonenberg>
Which is why i like HyperRAM so much vs e.g. DDRx
<azonenberg>
1mm 24-ball package is super layout friendly
<whitequark>
azonenberg: oshparh is 6/6 right?
<azonenberg>
for 4 layer it's 5/5 on FR408
<whitequark>
oh right 4 layer
* whitequark
aims for 2-layer
<azonenberg>
for 2 layer it's 6/6
<azonenberg>
i havent done a 2L design in so long
bitd has joined ##openfpga
<azonenberg>
My designs tend to be dense and full of large, expensive parts
<azonenberg>
Trying to penny pinch on pcbs isn't worth it, and trying to lay out a board with some of this stuff in 2 layers is nearly impossible
<azonenberg>
doing it with good SI is even harder
<azonenberg>
4 is a minimum for me to consider a serious design
<azonenberg>
i'll go up to 6 if i have to but i wouldnt do a high speed design on <4
<whitequark>
I haven't done a 4L design... ever
<whitequark>
but I might do in this case
<azonenberg>
whitequark: any time you work with a bga more than about 4x4 balls you basically have to do 4L
<azonenberg>
trying to do any kind of high speed stuff pretty much mandates it too, because you need a ground plane and then you have only one routing layer
<whitequark>
yeah but I don't want to go BGA
<azonenberg>
plus ground on one side of the board and power on the other leads to very wide traces to get sane impedances
<azonenberg>
Then once you start working with chips that have 10+ power/ground pins and multiple rails
<azonenberg>
you need to get a nice low inductance path from the PSU to the decoupling caps and then to the IC
<azonenberg>
2L boards pretty much always have the power distribution network all broken up by signal traces
<azonenberg>
trying to route four power rails on one layer is hard enough when all you're doing is power
<azonenberg>
fitting signals onto the same layer makes it near impossible
<azonenberg>
then a solid, unbroken ground plane for SI reasons on top of that takes up another layer
<whitequark>
wellll I have 5V, 3.3V and 1.2Vcore
<azonenberg>
then you have two for signals and components
<azonenberg>
oh and at higher speeds if you have compnents adjacent to the power layer rather than the ground layer
<azonenberg>
you need to avoid crossing splits in the power layer where you jump from one voltage to another
<azonenberg>
Or have capacitors to bridge the gaps to provide a ground return path at AC
<azonenberg>
4 layer is like the bare minimum to make that possible and it already takes a lot of finagling to jam as many power rails as i normally have into one layer
<azonenberg>
often i have to steal part of a signal layer for power routing when i have a non-planar graph
* whitequark
looks through iCE40 part lists
<azonenberg>
whitequark: my general rule is... 2L for trivial stuff like breaking out one connector to another at low speeds
<azonenberg>
4L for general purpose
<whitequark>
define "low speed" and "high speed"
<azonenberg>
past a few tens of MHz i'd definitely want to go 4L
<whitequark>
hm okay, so that means definitely 4L for me
<whitequark>
for multiple reasons
<azonenberg>
below there it prooobably doesnt matter but it honestly isn't worth the cost to me
<azonenberg>
my time + cost of components to respin
<azonenberg>
vs doing it right the first time
<azonenberg>
anyway, then 6L for designs with >256 ball BGAs that need more than two layers to fan out
<azonenberg>
and 8L (i have not actually done this yet) for a design that not only has lots of signals, but needs more than one power layer because i have so many rails
<azonenberg>
whitequark: in general though, the choice of layer count isn't driven by SI it's driven by routability
<azonenberg>
for me
<azonenberg>
Since almost none of my nontrivial designs can be routed in 2L without reeeally long snaky power routing
<whitequark>
so, of all the iCE40 FPGAs the only good ones are LP384-SG32 and UP5K-SG48
<azonenberg>
SG is what, qfn?
<whitequark>
QFN, yes. the rest are all BGA or QFP
<azonenberg>
eew qfp
<whitequark>
one 0.8mm BGA-256 and one QFP-144
<azonenberg>
i hate those, they're so huge
<whitequark>
neither is going to work for me I think
<azonenberg>
yeah
<whitequark>
*maybe* I could discard most pins on the BGA-256 package but I don't like it
<azonenberg>
i'm excited for the new spartan-7 package, CPGA196
<whitequark>
makes the board less accessible too
<whitequark>
I want it to be usable OSHW
<azonenberg>
actually no, i meant FTGB196
<whitequark>
so what do you think of my idea of using LP384 as a SERDES?
<whitequark>
it's $1.6
<azonenberg>
Which is 14x14 balls 1mm pitch BGA
<azonenberg>
basically a little baby version of FTG256 with two less rows
<azonenberg>
sounds like it'll work fine
<azonenberg>
i've used coolrunners as io expanders in the past too
<whitequark>
it's slightly annoying because of IO count
<whitequark>
21 GPIOs
<azonenberg>
yeah that's light
<azonenberg>
What is the goal of the serdes?
<whitequark>
UP5K has 39 GPIOs
<azonenberg>
how many bits at what speed DDR -> how many bits at what speed SDR
<whitequark>
oh! sec
<whitequark>
16 bits at 48 MHz SDR to 2 bits at 192 MHz SDR
<azonenberg>
Oh so it's not just DDR to SDR, you're actually speeding it up
<whitequark>
er I typoed
<whitequark>
16 bits at 48 MHz SDR to 2 bits at 192 MHz DDR
<whitequark>
otherwise the bit rates don't match up
<azonenberg>
Can you even do 192 MHz DDR on an ice40?
<whitequark>
yes
<azonenberg>
So, what about using an xc2c32a as the serdes?
<whitequark>
the buffers are good up to 250 MHz with LVCMOS33
<azonenberg>
you get 21 GPIOs in the qfn-32 xc2c32a, the I/Os contain DDR FFs
<whitequark>
so exactly like ice40?
<azonenberg>
Pretty similar, yeah
<azonenberg>
But might be cheaper
<whitequark>
mouser doesn't even have xc2c32a
<azonenberg>
xc2c32a-4qfg32c is... non-stock on digikey :o
<azonenberg>
they pulled it i guess?
<whitequark>
none on farnell
<whitequark>
lol rqou you're working on a dead chip
<azonenberg>
they have the slower -6 speed
<rqou>
er, what
<azonenberg>
digikey has them for $1.75
<azonenberg>
Just not the -4
<rqou>
coolrunner-ii isn't EOL?
<whitequark>
azonenberg: that's more expensive than iCE40LP384
<azonenberg>
whitequark: yeah price must have gone up
<whitequark>
rqou: but if I can't buy it what's the difference
<azonenberg>
it was $1.30ish when i started the project
<azonenberg>
rqou: no its not eol
<azonenberg>
but digikey no longer stocks the -4 speed grade in some/most packages
<azonenberg>
you have to buy a tray of 400ish
<azonenberg>
You can however buy single units of -6
<rqou>
i think that's always been the case?
<azonenberg>
huh i could have sworn -4 was available at one point
<whitequark>
azonenberg: so correct me if I'm missing something here
<whitequark>
LP384 doesn't have a PLL so it needs a 192 MHz clock input
<azonenberg>
That sounds right
<whitequark>
so: 16 lines at 48 MHz connecting to CY7C68013A, 2 single-ended lines at 192 MHz connecting to iCE40UP5K, 1 single-ended clock input from iCE40UP5K, 1 direction input from UP5K, 1 strobe input from UP5K
<whitequark>
that's every pin connected
<whitequark>
the single-ended lines should be fine because they only go at most a few mm across the board, right over the ground plane
<azonenberg>
yeah i'd still terminate them to avoid overshoot
<whitequark>
hmmm
<whitequark>
how do I do that?
<azonenberg>
series termination is just a resistor between driver and load
<azonenberg>
you can do the math or you can guesstimate ~33 ohms :p
<whitequark>
lol
<whitequark>
hm
<whitequark>
R1 = Z0-Zout, Z0=50ohm with 14mil traces on dirtypcbs stackup
<azonenberg>
Yeah, you can estimate Zout to be pretty low ~10 ohms or run IBIS simulations
<azonenberg>
but most fpga gpios are fairly low impedance
<azonenberg>
So i figure if the line is 50ish ohms and the driver is 10ish, terminate with 40ish
<azonenberg>
33-39 is usually a good bet, won't be perfect but unless your signals are really fast it'll be good enough
<whitequark>
so the drivers are 8mA at 3.3Vio
<whitequark>
wait, that doesn't help
<whitequark>
hm
<jhol>
mithro, digshadow: just tinkering with the symbiflow-arch-defs repo
<jhol>
icebox-rr_graph-import.py
<whitequark>
azonenberg: iCE40 says Zout=20ohm
<whitequark>
so, 33 ohm series it is lol
<azonenberg>
So 33 ohms will be slightly overterminated for a 50 ohm line
<azonenberg>
or you can use a slightly narrower than 50 ohm line
<azonenberg>
which will allow better trace packing
<whitequark>
that's a good point
<whitequark>
12.6 mil for 53 ohm Z0, 14 mil for 50 ohm Z0
<azonenberg>
i mean you can even go say 75 ohm if you want
<azonenberg>
the only reason to use 50 exactly is because some other part of the system is matched to that
<azonenberg>
Matching through the whole system is what matters, not the number
<whitequark>
I understand that, yes
<azonenberg>
So going higher Z with smaller traces is often good for digital stuff
<whitequark>
75 is 6 mil exactly
<azonenberg>
Convenient
<azonenberg>
So if you use a common 49.9 ohm resistor
<azonenberg>
you're at 50 + 20 = 70 ohms, slightly underterminated which gives a faster rise time and a tiny bit of overshoot
<azonenberg>
But not enough to matter i'd guess
* whitequark
looks up trace width for Z0=20ohm
<whitequark>
1.35mm
<whitequark>
yeah uh I see why people use termination now
<azonenberg>
Lol
<azonenberg>
i mean the other option is to use an impedance matched driver
<whitequark>
on iCE40? :D
<azonenberg>
well no :p
<azonenberg>
But if you tweak the drive strength right you can match the driver to the line and not need an explicit termination at the source
<whitequark>
actually hang on I have an idea
openfpga-github has joined ##openfpga
openfpga-github has left ##openfpga [##openfpga]
<openfpga-github>
openfpga/master c9ac852 Robert Ou: xc2bit: Shrink mem usage by packing PLA bits...
<openfpga-github>
openfpga/master 39a800a Robert Ou: xc2bit: Take Write by value
<openfpga-github>
[openfpga] rqou pushed 2 new commits to master: https://git.io/vx7Ka
<whitequark>
ah no that won't work
diadatp has joined ##openfpga
<azonenberg>
"foo_ff <= foo_ff;"
<azonenberg>
Hmm, wonder why that flag wasn't being set right
diadatp has quit [Ping timeout: 256 seconds]
<azonenberg>
yet another reason i want a good HDL linter, assigning a value to itself in a clocked always @() block should be a warning
<azonenberg>
more precisely, assigning a value to itself but never anything else
diadatp has joined ##openfpga
<whitequark>
hm actually now that I read CY7C datasheet more carefully
<whitequark>
if I'm doing *bursts* then it can give me 8 bits on every IFCLK posedge
<whitequark>
and since I have massive buffers inside the FPGA it is very easy for me to do large bursts
<whitequark>
yeah I don't need this SERDES
<whitequark>
the FPGA alone gives me 384 Mbps
<whitequark>
azonenberg: do you know offhand what's the largest data rate you can put through an USB2 bulk or iso endpoint
<whitequark>
Cypress testing says they could get 192 Mbps with isochronous and 350 Mbps with bulk endpoints
<whitequark>
so yeah when heavily bursting BULK endpoints I'm limited by the USB side of the link, not FPGA side
diadatp has joined ##openfpga
diadatp has quit [Ping timeout: 255 seconds]
<whitequark>
azonenberg: the CY7C package design notes are *weird* for QFN
<whitequark>
they say I need to put a 5x5 grid of vias under it
<whitequark>
all covered with solder mask on top of via
<whitequark>
"to resist solder flow into the via" hrm
wpwrak has quit [Ping timeout: 245 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
diadatp has joined ##openfpga
wpwrak has joined ##openfpga
diadatp has quit [Ping timeout: 260 seconds]
eduardo__ has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
eduardo_ has quit [Ping timeout: 265 seconds]
scrts has joined ##openfpga
soylentyellow has quit [Ping timeout: 264 seconds]
soylentyellow has joined ##openfpga
<jhol>
mithro, digshadow-c: so icebox-rr_graph-import.py is feeding into VPR. I see a bunch of warnings, so I'm just going to go ahead and start squashing those and see where we get to
rohitksingh_work has quit [Ping timeout: 240 seconds]
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale has joined ##openfpga
rohitksingh_work has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
<mithro>
jhol: Which means that things which are not being tested on travis are almost 100% likely to be broken
<jhol>
yeah well I'm accumulating patches as I go - some hacky, some not
<mithro>
jhol: Great - I'm not above merging hacky stuff if they add direct value
wpwrak has quit [Ping timeout: 265 seconds]
<mithro>
jhol: BTW Which branch are you looking at?
<jhol>
I'm based on mithro/rr_graph_lib_new}
<mithro>
jhol: Great!
<jhol>
yay - VPR gave me a segfault - now I'm really getting somewhere
<mithro>
jhol: I think it would really help to rewrite the ice40 import to use the rr_graph library as it would make it easier to figure out how things are broken
<mithro>
jhol: Oh - a bit more history
<mithro>
jhol: Originally, I was putting all the routing in the rr_graph, the vpr devs suggested that I move the local-tracks into the tiles, so I started attempting to do that
<mithro>
jhol: Only to discover that vpr did not like that more
<daveshah>
Yeah, that way we can build up more realistic routing
<jhol>
hmm ok
<mithro>
daveshah: The idea being we can have one architecture which includes the logic tiles directly and one architecture which includes the tiles via a "wrapper" which adds the local routing
<mithro>
jhol: See how there is a large "commented out" section at the bottom? That is what use to be needed to make that tile valid for including in an architecture as a top level pb_type
<mithro>
daveshah: Hopefully daveshah means we don't need that any more
m_w has quit [Quit: leaving]
<mithro>
jhol: IE I wanted the ability to explore both options - routing in the rr_graph and routing inside the tile
<mithro>
jhol: As I was not confident which one would end up _actually_ working
wpwrak has joined ##openfpga
rohitksingh has joined ##openfpga
<awygle>
whitequark: hello
<awygle>
looks like you ended up at all the conclusions I would have suggested
<awygle>
that QFN layout is quite common, it's a way to not pay for via in pad
<mithro>
hey awygle
rohitksingh has quit [Quit: Leaving.]
<whitequark>
awygle: hi
<whitequark>
which part?
<whitequark>
conclusions that is
<awygle>
4l, don't need serdes (or rather even if we needed it I would probably have tried to talk you out of it on complexity grounds)
<awygle>
75 ish ohms, terminated
<whitequark>
nod
<whitequark>
so I'm looking at power sequencing
<whitequark>
both the FPGA and the Cypress chip need it
<awygle>
incidentally 50 ohms is the geometric mean of "max power handling" and "minimum loss" for air core coax
<awygle>
while 75 is right on minimum loss
<whitequark>
oh huh
<awygle>
75 is also easy to match to a 300 Ohm folded dipole
<awygle>
(apparently, I've never done that)
<whitequark>
awygle: so the FPGA wants 1V2 before 3V3
<whitequark>
more annoyingly, CY7C wants RESET to be held for 100us after Vcc reaches 3V0
<whitequark>
but definitely less than 100ms to satisfy USB spec
<whitequark>
so let's say we use the MIC5355-S4YMME dual 1V2/3V3 LDO with enable inputs
* whitequark
looks up
<whitequark>
"32-Rail PMBus Power Sequencer" what in the fuck
<awygle>
whitequark: leaving for work, give me 30m or so
<whitequark>
ah k
diadatp has quit [Ping timeout: 276 seconds]
diadatp has joined ##openfpga
<mithro>
jhol: FYI -- If you want my attention, please mention my nick - otherwise there is a good chance it'll take me a long time to reply
<jhol>
mithro: no problem!
<jhol>
so I'm just working on the rr_graph script
<jhol>
- couple of questions: what does the rr_graph library offer?
<jhol>
channels.py, graph.py
<jhol>
with the channels, I'm getting the feeling that there shouldn't be any - do it all with <direct>. no channels, switches or segments
<daveshah>
jhol: That may be problematic with the lack of bidirectional IO on tiles at present to represent general routing
<daveshah>
If I'm understanding your idea correctly
<jhol>
well put it this way... did you guys manage to describe the routing correctly using channels and segments?
<jhol>
mithro said he had it working that way at one point, the VPR devs told him to do it with <direct> links, which lead to VPR crashing
<jhol>
if I had the choice I'd like to do it with <direct> links because it a more natural way of describing the ice40
noobineer has joined ##openfpga
noobineer has quit [Remote host closed the connection]
<jhol>
--- perhaps with a hack of adding 2 links for each direction
<daveshah>
Yes, I agree direct is a good route forward. The 2 links is a reasonable hack for now
<jhol>
just hope it doesn't make VPR explode somehow
<mithro>
You can't use the direct links right now
<jhol>
so bug 274 isn't going to be easily fixable?
<mithro>
jhol: Not in the short term
noobineer has joined ##openfpga
<jhol>
ok... so channels it is then!
<jhol>
I see a lot of code in play for that stuff
<jhol>
does it work?
<mithro>
Define "work" ? :-P
<jhol>
haha
<mithro>
jhol: I believe the rr_graph library should import an existing rr_graph.xml and provide you with the information needed to poke around and modify it
<jhol>
ok... well then I'll take the channels code in icebox-rr_graph-import.py and refactor it to use rr_graph.channels, and import that into icebox-routing-import.py
<daveshah>
That sounds like a good step to me
<jhol>
then do the same do the same with the rr_nodes, and it will surely work straight away
<daveshah>
No, that was a typo. I meant icebox-rr_graph-import
<jhol>
:) - just checking!
<mithro>
jhol / daveshah: I'm not sure those diagrams are still correct...
<awygle>
whitequark: so "1.2V VCore, 3.3V VIO+Cypress VCC, Cypress reset"?
<daveshah>
mithro: I think neighbourhood tracks go left and right too
<awygle>
on the LM3880
<daveshah>
But I'm not sure whether that's also needed as another channel
<whitequark>
awygle: yep I think so
<awygle>
whitequark: that seems reasonable to me
<mithro>
daveshah: They do
<daveshah>
jhol: just a random heads up but I would suggest joining #vtr-dev too - very occasionally we discuss vpr stuff there too. The VTR maintainer is also there
<jhol>
ok - I'll do that
<mithro>
jhol: Also, don't necessarily trust anything I say - if something seems wrong, do double check I might be recalling incorrectly
<mithro>
I have a terrible memory
<jhol>
sure - there's a lot of fuzzy truth here
<jhol>
your updates to the ice4 diagram are looking good
<mithro>
jhol: As I said - I was looking for the least resistance path to getting things working
<mithro>
jhol: Wanted to have something which worked before trying to dive into figuring out the "correct" way -- really want to compare it to other solutions
<jhol>
mithro: the ice4 arch xml doesn't have the EMPTY perimeter right now
<gruetzkopf>
we did the video card thing yesterday.. tried playing portal2 until lockup happens. didn't lock up
<mithro>
jhol: That might be because we only discovered that we needed when I switched to looking at the Artix-7...
rohitksingh has quit [Quit: Leaving.]
<awygle>
whitequark: s'cool :) just being sillty
<jhol>
I'll update it
<gruetzkopf>
the terrible efi in this laptop turned off the intel card though, because eGPU vendor == possible iGPU vendor
<awygle>
whitequark: what do you see as our work breakdown going forward btw?
<awygle>
i know you wanted to do some kicad stuff, and you've done most of the firmware work, do you want me to just keep babysitting kicad library PRs from here on?
diadatp has quit [Ping timeout: 264 seconds]
<whitequark>
awygle: hmmm good question
<whitequark>
do you have any preferences?
<awygle>
not particularly
<awygle>
i'm happy to take on a support/bikeshedding role, i have plenty of other things to do. or if you want me to do the PCB, i'm pretty good at that. the only thing i'm pretty grossly unqualified for is fx2 firmware lol
<whitequark>
hum, okay
<mithro>
whitequark: I would love to find out more about your fx2 stuff but sadly I don't have the bandwidth :-(
<whitequark>
I'm fine with doing all fx2 work
<mithro>
jhol: I added a bit more explanation to the diagram...
<whitequark>
mithro: well so far I rewrote the entirety of fx2lib using only the datasheet because I hated the license
<mithro>
whitequark: Yes I saw
<mithro>
whitequark: I'm very interested in optimized bitbanging routines for the fx2 -- I started doing some work on generating them here -> https://github.com/mithro/fx2-ftdi-emulation/tree/master/bitbang -- more then happy to relicense anything if it helps you
<mithro>
Feel free to laugh at how horrible inept my attempts are :-P
[X-Scale] has joined ##openfpga
<whitequark>
hm but why
<whitequark>
mithro: in my case though I only need to bitbang the config port of FPGA
<balrog>
gruetzkopf: what laptop are you dealing with?
<mithro>
whitequark: Why do you ever do anything that horrific? To work around a mistake in hardware :-P -- We originally had the EERPROM on a different address and the FPGA was going to just emulate an eeprom. However it turns out the eeprom we ended up using did not support being moved to the alternative address...
X-Scale has quit [Ping timeout: 268 seconds]
[X-Scale] is now known as X-Scale
<whitequark>
and doing that at 6 MHz is entirely fine
<mithro>
whitequark: On the bitbanging side - the eventual goal was to speed up JTAG interface to the FPGA via the FX2 - (basically replace our hugly slow firmware here -> https://github.com/mithro/ixo-usb-jtag)
<whitequark>
well, my goal is to *implement* the JTAG interface on the FPGA
<whitequark>
one of
<whitequark>
I'd also like to have a 250 Msps capable LA
<mithro>
whitequark: At some point I wanted the FX2 to appear as a serial port and then allow you to program the FPGA by just "xmodem"ing a .bit (or .bin) file into.... -- Now I'm more interested in appearing as a dfu compatible device rather than serial port + xmodem....
<rqou>
anybody who is good at usb want to test out my "smuggle data in U2F" idea?
azonenberg_work has joined ##openfpga
<rqou>
i really really want "security-toaster-free" browser access to usb devices that isn't stuck in bikeshedding
<awygle>
rqou: why not just... take the toaster
<mithro>
whitequark: anyway - sadly I don't have time to really think much about this anymore -- but if you need a rubber duck or other person who has looked at fx2 stuff _way_ too much I can find some time
<rqou>
because now users have to accept a toaster
<rqou>
also only works in chrome (see: bikeshedding)
<whitequark>
mithro: thanks!
<awygle>
for someone who complains as much about security being crap as you do you sure are trying hard to circumvent security :p
<awygle>
the second reason is a better one
<rqou>
meh, physical access = pwned anyways with current security models
<mithro>
whitequark: Oh -- If things overlap enough with stuff I'm interested in, then I'd even be potentially up for funding prototype runs and similar, specially if it enables you to progress faster
<mithro>
digshadow: Morning! jhol has started playing with the ice40 and vpr, might want to have a quick look through the logs
<digshadow>
mithro: will do
<Prf_Jakob>
whitequark: Stupid question, the work you are doing makes the FPGA acts as a config memory programmer?
<pie_>
rqou, if ur not a noob anyway.
<whitequark>
mithro: hmm which things are you interested in?
* pie_
doesnt have a stash of 0days yet
<whitequark>
Prf_Jakob: I'm not sure I understand the question
<whitequark>
what's config memory?
<Prf_Jakob>
whitequark: Sorry I'm new to FPGAs and don't know the proper words for things, the memory thing that holds the bitstream for the FPGA,
<whitequark>
no, in my case CY7C68013A programs the FPGA
<Prf_Jakob>
Aah, thanks!
<mithro>
whitequark: A DFU firmware for the FX2 which can program an FPGA is interesting to me... Figuring out how to eak the most performance out of the FX2 also does... 250 Msps capable LA is almost interesting to me (but I'd prefer 1.25Gsps ;-) -- more people hacking on the FX2 generally is of interest....
<whitequark>
mithro: hmmm I don't like DFU all that much, it's very complex
<whitequark>
so far I've basically implemented the DFU_DNLOAD request and that's it
<whitequark>
why DFU specifically?
<awygle>
Prf_Jakob: it is true though that the full Glasgow-JTAG will be able to program config memory for _other_ FPGA boards, as well as load bitstreams directly over SPI/JTAG and do several other kinds of serial communication
<Prf_Jakob>
awygle: Cool
<whitequark>
and generally you'll be able to feed it a bitstream ridiculously quickly
<rqou>
mithro: 1.25 Gsps wut
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<azonenberg_work>
mithro: what would you need 1.25 Gsps LA for?
<azonenberg_work>
the only things i do that fast are FPGAs and i can just compile a LA into the design
<rqou>
also such a weird number
<azonenberg_work>
I could use a sampling oscilloscope faster, for eye diagrams
<azonenberg_work>
rqou: he probably is implying kintex7 max ddr lvds input rate
<azonenberg_work>
artix7*
<mithro>
azonenberg_work: Actually I really want 6-12Gsps :-P
<azonenberg_work>
mithro: oversample with a GTP?
<azonenberg_work>
:p
<mithro>
rqou: azonenberg_work is correct :-)
<azonenberg_work>
mithro: are you familiar with my starshipraider project?
<rqou>
also what transport are you going to put that onm
<mithro>
azonenberg_work: Nope!
<rqou>
on?
<azonenberg_work>
mithro: "bus pirate" + "future"
<azonenberg_work>
it's meant to be a general purpose embedded systems debug/test/reversing tool
<mithro>
azonenberg_work: So similar to the Daisho?
<azonenberg_work>
mithro: Not quite
<azonenberg_work>
Scaled-down prototype: artix7, gig-e, 32 MB of 32-bit 333 MT/s HyperRAM, one I/O card interface
<rqou>
except that i don't like the way azonenberg is going about it, so i want to do something that shares the same hardware with a totally different software stack
<azonenberg_work>
Prototype exists but no i/o cards yet
<mithro>
Lol - HyperRAM :-P -- Why not DDR?
<rqou>
mine will be called "bus armada" because it will attemt to take over the bus pirate and fail catastrophically
<azonenberg_work>
Because hyperram is 1 mm pitch and thus very friendly for cheap batch pcb fab
<azonenberg_work>
afaik it's the only dram with a >0.8mm ball pitch
<azonenberg_work>
Full version, planned on paper but not built: kintex7, 10G SFP+, gig-e, 4GB of DDR3, four I/O interfaces, possibly a GTX expansion card slot too
<azonenberg_work>
Each I/O card slot has 12V power + 3.3V VCCIO feeds, I2C for configuration/detection, eight LVCMOS33 outputs, eight LVCMOS33 output enables, and eight LVDS inputs
<mithro>
azonenberg_work: I have something similar planed...
<rqou>
wtf
<azonenberg_work>
we should collaborate
<azonenberg_work>
The primary I/O card will be an 8-bit digital I/O module with variable voltage and threshold
<azonenberg_work>
it'll run from 1.2 to 5V levels at ~500 Mbps (full 500 on input, output speed will vary slightly with voltage due to buffer limitations)
<azonenberg_work>
Tolerant to +/- 12V on inputs without hardware damage although correct operation is not guaranteed
<azonenberg_work>
mithro: anyway the fun bit is the firmware
<azonenberg_work>
It'll have a TCP offload engine on board
<azonenberg_work>
So you can plug it into a LAN and talk straight to it
<mithro>
The firmware is easy - I just pay _florent_ to do it for me :-P
<azonenberg_work>
The native wire protocol will be protobufs inside very simple TCP framing
<azonenberg_work>
One port for configuring the I/O crossbar to connect protocol modules to I/O pins, set voltage levels on i/o banks, etc
<rqou>
^ lol mine won't be anything like this
<azonenberg_work>
then each virtual instrument has its own port
<rqou>
i think protobufs are dumb
<azonenberg_work>
rqou: seems like the best option if you want to have an instant API for many languages to use
<azonenberg_work>
mithro: there will always be a LA sniffing all 32 I/O pins
<awygle>
rqou: why do you think protobufs are dumb?
<azonenberg_work>
additionally you can connect various instruments
<azonenberg_work>
for example JTAG on pins 3-4-5-6
<rqou>
fun protobuf stories from <redacted>
<azonenberg_work>
as soon as you hook that up, you have a jtaghal-compatible server on port 4141
<rqou>
also it's just imho not good
<azonenberg_work>
find a UART on pins 10 and 11? Set it up, then telnet to the UART server port
<rqou>
e.g. weird complicated variable-size ints but no fixed-sized ints at all
<azonenberg_work>
rqou: um
<azonenberg_work>
they have int32/int64 fixed size
<azonenberg_work>
in addition to varints
<rqou>
ok, not enough
<azonenberg_work>
(the raw TCP uart will be an additional option besides a protobuf API that lets you do in-band flow control, baud rate changes, etc)
<rqou>
also, i would smuggle all day over fake-http/websockets/webrtc/etc.
<azonenberg_work>
mithro: then you can have additional io cards for things like "unbuffered LVDS at higher speeds" or "analog input" etc but i expect the protected digital i/o to be the way to go for most applications
<awygle>
i really like the _idea_ of cap'n proto, but i want it like, inside a language
<rqou>
because fuck touching any "native" gui toolkits
<azonenberg_work>
rqou: lol
<azonenberg_work>
meanwhile, my plan is to go with straight gtkmm for the GUI client
<azonenberg_work>
but have the primary intended workflow be the generated C++ API to the protobuf backend
<mithro>
azonenberg_work: _florent_ already has the parts needed - LiteEth, LiteDRAM and LiteScope
<rqou>
lol I'd never do anything like that
<azonenberg_work>
i.e. you fiddle in the gui to figure out what you need
<rqou>
also fuck C++ APIs
<azonenberg_work>
Then script the fun stuff in C++
<balrog>
rqou: I need to take a serious look at rust, btw
* rqou
nopenopenope
<balrog>
I've read a little about it and I'm liking what I see
<balrog>
C++ interop is the biggest problem, OF COURSE
<awygle>
rust +1, rust is great
<awygle>
C++ interop is a C++ problem
<mithro>
I already have stuff which makes it so that Sigrok can talk directly to LiteScope -- but again never had the time to finish it....
<rqou>
balrog: the documentation for rust kinda sucks though
<balrog>
awygle: there's a HUGE PILE of stuff done in C++ and that will not change
digshadow has quit [Ping timeout: 255 seconds]
<awygle>
balrog: yeah i know. i just mean that C++ doesn't interoperate with _anything_ in a useful way, so rust isn't "worse" than any other option.
<awygle>
C++ barely interoperates with C++
<awygle>
and only because of frankly heroic work by C++ compiler devs
<rqou>
someone should hack bindgen to generate c++ vtables/rtti lol
<awygle>
doesn't it? i thought bindgen could handle like, single inheritance or something
<rqou>
it can?
<mithro>
You can wrap C++ in a C interface pretty easily...
<rqou>
awygle: try rebuilding the abandoned xbpar-rs
<rqou>
mithro: HAH funny
<rqou>
you should also look at xbpar-rs
<awygle>
C is the lingua franca of FFI because it _actually has a defined in-memory format_ and i don't understand why more languages don't follow suit
<rqou>
the FFI glue had more lines of code than the actual implementation
<azonenberg_work>
mithro: well i'm not using sigrok
<sorear>
C++ has a defined in-memory format in the same sense C does (C/C++ compilers document their formats for both and maintain ABIs whenever possible), it's just so much more complicated that there are hardly any third-party consumers
<azonenberg_work>
Sigrok is GPL and I needed permissive liecnsing
<awygle>
azonenberg_work: did you? why?
<rqou>
er, is it documented? iirc people had to RE MSVC's C++ ABI
<azonenberg_work>
The whole antikernel project and all of the infrastructure is permissively licensed to allow/encourage commercial reuse/forking
<sorear>
the canonical document describing C memory layouts on x86_64 Linux is the x86_64 psABI and it also covers C++ details (partially by reference to the Itanium ABI, but still)
<azonenberg_work>
The other issue is, i dont think sigrok scales to the kind of performance i want
* awygle
counts to ten slowly and repeats "don't start a fight about licensing" under his breath until he calms down
<rqou>
yeah, on Linux it is mostly documented
<azonenberg_work>
I'm actually in the process of planning a GPU-accelerated rewrite of my existing LA/DSO client app
<balrog>
I can understand why sigrok is GPL...
<rqou>
i really really want WebVk lol
<azonenberg_work>
with OpenGL rendering of waveforms stored in vertex buffer objects
<sorear>
also with C you can generally expect people to provide signatures
<rqou>
HAH funny
<azonenberg_work>
and hopefully at some point, OpenCL/CUDA protocol decodes
<sorear>
C++ types are sufficiently more complicated that I've only ever seen it done by parsing headers
<rqou>
try wrangling the win32 api some time
<rqou>
they "provide signatures"
<azonenberg_work>
awygle: the goal is to be able to process on the order of 50K WFM/s from a 1 GHz 10 Gsps quad channel DSO
<azonenberg_work>
In real time
<awygle>
azonenberg_work: i know
<awygle>
lol
<rqou>
but their headers are close to unusable
<azonenberg_work>
awygle: I dont think sigrok can do that
<awygle>
azonenberg_work: i agree
<azonenberg_work>
or even come *close*
<awygle>
i just wondered why you felt that you needed permissive licensing
<rqou>
WebVk when :P
<awygle>
and the answer is "to encourage commercial re-use"
<azonenberg_work>
Yeah
<azonenberg_work>
I want antikernel and the related stack to be widely used in commercial products eventually
<azonenberg_work>
I don't care if their fork is closed source
<azonenberg_work>
my code is a gift to the world and its value is in no way decreased by someone else using it, no matter how
<azonenberg_work>
And if someone decides that a binary blob fork with more features is worth more to them than a version without that feature but source available, that's their choiec
<azonenberg_work>
Not mine
<awygle>
hm can i quote you on that? i am considering a blog post on this topic and the above would be gold
<azonenberg_work>
Sure
<azonenberg_work>
Basically, when it comes to software licensing, I'm a free-market idealist
<azonenberg_work>
I compete on the basis of cost (zero), somebody with more budget competes on the basis of feature set
<azonenberg_work>
The end user is free to decide which they value more
<pie_>
im just an idealist but sometimes i think about wanting to do what i want without starving :(
<azonenberg_work>
pie_: see, i do security testing for $dayjob
<azonenberg_work>
this is for fun
* pie_
hasnt actually published any software yet
<azonenberg_work>
gp4par is the only project i have ever released under a copyleft license
<pie_>
yeah i know
<azonenberg_work>
and it took a lot of convincing
<awygle>
oh? i thought gp4par was bsd
<azonenberg_work>
no
<awygle>
is it lgpl?
<azonenberg_work>
Yes
<awygle>
pff that's barely copyleft :p
<azonenberg_work>
If a project is very tightly coupled to one vendor's product and you're worried about them soaking it up into their IDE etc, i can understand
<azonenberg_work>
But i wanted to allow them to poetntially link it into greenpak designer as a blob
<azonenberg_work>
And only provide source to the HDL flow
rohitksingh has joined ##openfpga
<azonenberg_work>
With the LGPL linking rules we'd have to still be able to drop in our own gp4par/libgreenpak4 binary
<azonenberg_work>
and use with their ide
<awygle>
yeah i get that, lgpl actually makes a lot of sense for greenpak stuff
<awygle>
(in some but not all ways)
<azonenberg_work>
But for a standalone project that doesn't have one and only one potential corporate acquirer
<azonenberg_work>
I always go permissive
<awygle>
what pie_ said is telling, i think
<rqou>
(drama) lol, vice decided to write about surveillance in china and yet continues to ignore @RealSexyCyborg
<awygle>
you're fortunate to be in a position where that's a choice you can make with little consequence
<azonenberg_work>
anyway although licensing was the original reason i didnt use sigrok
<awygle>
(and to be clear, so am i)
<azonenberg_work>
(my VERY early versions were CLI tools that just spawned gtkwave binaries off a captured VCD, but i quickly decided I needed to provide a UI for trigger control etc)
<pie_>
awygle, fwiw id probably starve anyway lmao
<azonenberg_work>
Scalability is now the big issue
<awygle>
pie_: lol
<pie_>
can we just like, go make a killing dual licensing pcbhdl
<rqou>
pie_: get out of HU lol
<azonenberg_work>
The opengl rewrite is going to have to wait until I move obviously
<azonenberg_work>
But it should be awesome
<azonenberg_work>
i'm hitting limits with gtk scrolling etc anyway
<rqou>
no vulkan?
<pie_>
lol
<azonenberg_work>
and cairo rendering
<azonenberg_work>
tl;dr you cannot have a cairo canvas more than 32K pixels on a side
* awygle
wishes he had time to work on pcbhdl, it seems cool
<pie_>
azonenberg_work, fwiw i get the feeling thats not how you're supposed to do stuff like that anyway
<pie_>
awygle, ive been vaguely thinking about just osme kind of programming _frontend_ for cad in general (a la openscad), but ramp up the interactivity as much as possible
<awygle>
pie_: yeah i've been thinking about that too actually
<awygle>
i even did some initial prototyping but i got sucked into "oo graphics is fun" instead
<pie_>
hah...
<azonenberg_work>
pie_: well, the new system is going to have opengl rendering and scrolling done differently
<pie_>
im just talk :P
<pie_>
azonenberg_work, re: the 32k wide thing
<rqou>
i can never get "into graphics"
<rqou>
somehow i find all the examples/tutorials suck
<pie_>
rqou,opengl sucks
<pie_>
fuck opengl
<pie_>
love opengl
<azonenberg_work>
pie_: the part that makes it tricky is that i can't trivially map from time to position
<rqou>
except the NeHe tutorials which I've been told are now essentially useless
<awygle>
pie_: if you're ever awake at a time when i'm not at work (9 hour time difference is brutal) let's compare notes
<azonenberg_work>
on the graph
<awygle>
rqou: even when they weren't useless they were never really _good_
<azonenberg_work>
because i have RLE compression on the LA captures
<azonenberg_work>
and "broken time" where there's no events
<rqou>
awygle: why not?
<pointfree>
Well I prefer to write free&open software both at night and during the day and for that reason I go with GPL. GPL focuses on end-users, but GPL happens to be more business friendly (for the party writing the software, that is).
<awygle>
rqou: well maybe that's not fair. they never taught you the "right way" to do things. but that wasn't really their goal, i guess.
<pie_>
awygle, what i basically end up doing wrt graphics is playing with complex analysis by writing opengl fragment shaders for https://github.com/Gargaj/Bonzomatic
<pie_>
ive been meaning to do a more seriousish foray into graphics for a while, but yknow.
<azonenberg_work>
rqou: i need to teach myself "modern" opengl
<rqou>
i don't even know what that even means anymore
* awygle
wants to learn vulkan but can't justify it
<azonenberg_work>
i.e. no matrix stack, no fixed function pipeline
<rqou>
I'd probably go straight to vulkan
<awygle>
All Shaders All The Time
<azonenberg_work>
awygle: exactly
<pie_>
yepppp
digshadow has joined ##openfpga
<awygle>
rqou: OpenGL 4 and Vulkan _seem_ similar but vulkan is _much_ more work
<awygle>
based on my explorations at the end of last year
<azonenberg_work>
i'm used to having fixed function for most stuff then apply a shader to one object if i need it for some fancy effect
<pie_>
also something something use a framework and not raw
<rqou>
nobody seems to have a vulkan tutorial that I find usable though
<azonenberg_work>
opengl 2.x :p
<pie_>
but real men dont use intellectual condoms
<pie_>
m i rite
<azonenberg_work>
i got started in the 1.3 days, shaders were a GL_ARB_ extension
<awygle>
almost certainly no
<azonenberg_work>
that only a few cards supported
<pie_>
awygle, well, i mean, hmu when youre not woking :P , also i have some tests coming up so my mind is in a different place
<azonenberg_work>
awygle: that said, i'm looking forward to having protocol decodes + rendering on the GPU
<azonenberg_work>
With CUDA-OpenGL interop
<rqou>
i did most "GL" work with fake GL-like layers in devkitPro, so I'm probably worse
<azonenberg_work>
To do things like "accumulate sample data coming in over 40GbE and render a 60fps realtime eye diagram"
<awygle>
pie_: how far into university are you?
<pie_>
awygle, ive got a looot to go.
<pie_>
bit more than half way through bachelors
<pie_>
(id be done already but family shit happened)
<awygle>
ah :/
<rqou>
anyways, i really want a vulkan tutorial optimized for "people who already know linear algebra really well and operating systems really well but knows absolutely nothing about 'graphics'"
<rqou>
but apparently no such people exit except me or something
<rqou>
*exist
<balrog>
vulkan is for all intents and purposes "OpenGL 5"
* pie_
mumbles something about an api reference
<pie_>
i suppose the problem with learning stuff like this is "is there even any underlying principles or do you just learn a bag of rnadom stuff"
<jn__>
well, there is probably more structure than "here's a list of functions, just use them!"
<rqou>
i did that, and then everyone told me I was doing it wrong
<rqou>
e.g. "how do i start drawing something? ah, glBegin. wait wtf that's wrong?"
rohitksingh has quit [Quit: Leaving.]
<azonenberg_work>
rqou: that's the fixed function pipeline
<azonenberg_work>
i.e. opengl 1.x
<azonenberg_work>
and supported in 2.x but deprecated
<azonenberg_work>
in 3-4 they removed it
<azonenberg_work>
i forget exactly
<Prf_Jakob>
It was during the 3.x series they removed most of it.
<azonenberg_work>
i was kinda annoyed by that
<azonenberg_work>
like, you can definitely get better performance using VBOs
<azonenberg_work>
But sometimes i just want to add a quick polygon for debugging
<azonenberg_work>
having to set up a shader and everything for that is a lot of work
<rqou>
<insert @eevee's rant or jwz's rant here>
<azonenberg_work>
also, i dont think they even do lighting/fog etc for you anymore
<Prf_Jakob>
Yeah for those things it's annoying, I think they expected people to do their own immidiate framework for those kinds of thing.
<azonenberg_work>
pretty sure you have to basically make a minimal shader that replicates the part of the fixed function pipeline you cared about
<Prf_Jakob>
Indeed
<azonenberg_work>
Good news is, for this particular application, IDGAF :D
<azonenberg_work>
I'm going to be doing solid color polygons and lines with no textures, fog, lighting, perspective, etc
<azonenberg_work>
just 2D ortho projection using Z for layering only
<azonenberg_work>
The only textures i have will be fonts
<rqou>
ugh fonts
<azonenberg_work>
actually, i'm considering using Cairo for that
<azonenberg_work>
render my text to a cairo bitmap then push a texture to the gpu
<azonenberg_work>
then just refresh the bitmap any time the text changes
<rqou>
fonts are such a nightmare and I'm amazed anybody can do them correctly
<azonenberg_work>
Prf_Jakob: did you see the "segmented" render mode i had in my scope ui?
<Prf_Jakob>
azonenberg_work: No I did not
<rqou>
why do "graphics/vidya" people really like the term "middleware?"
<rqou>
also, why is their "middleware" often closed-source and shitty?
<azonenberg_work>
Prf_Jakob: basically, i capture with run-length encoding and store a dT between every sample
<awygle>
Fonts seem like they should be easy but are hellaciously hard
<Prf_Jakob>
rqou: Because that's how you sell game engines to managment/investors.
<azonenberg_work>
For short time intervals with no activity, for some subjective definition of "short"
<azonenberg_work>
I just decompress and render the polylines as-is
<azonenberg_work>
For longer intervals, like between uart messages or something
<azonenberg_work>
I create a "broken line" effect in the UI
<azonenberg_work>
like used for big dimensions in engineering drawings
<rqou>
e.g. there some woman who seems to be very Twitter-famous and develops a afaict vaporware texture compressor as a proprietary tool
<rqou>
just seems really strange to me
<awygle>
are you talking about Stephanie Hurlburt?
<rqou>
i think so?
<azonenberg_work>
Prf_Jakob: anyway, this gets fun because there's no longer a trivial mapping between sample index in the buffer, time since start of capture, and position in pixels along the axis
<rqou>
yes
<awygle>
it's not vaporware. I won't get into the larger discussion lol
<rqou>
it's not?
<rqou>
i can't find any "real" information about why it's novel or better
<azonenberg_work>
Right now this works in "offline" mode... you set up the scope, do a single trigger, then it downloads the data over 100baseTX (which takes a few seconds) and renders
<Prf_Jakob>
azonenberg_work: So those graphs are rendered on the GPU or the CPU?
<rqou>
I'd at least like some kind of technical explanation about what it's doing other than "trust us, it compresses a lot better"
<azonenberg_work>
CPU, this is Cairo
<azonenberg_work>
But i plan to move that to GL down the road
<awygle>
rqou: you can get that, call and schedule a pitch meeting
<azonenberg_work>
Prf_Jakob: what i want is realtime streaming
<rqou>
lol
<awygle>
software like that is sold fundamentally differently than what you're used to
<azonenberg_work>
scope is connected to PC over 10/40GbE
<Prf_Jakob>
azonenberg_work: Ah nice
<rqou>
every time i hear anything like that i immediately assume "must be crap"
<azonenberg_work>
trigger, capture, push a gigabyte of pixel data out to the PC, start capturing again
<azonenberg_work>
of waveform data*
<azonenberg_work>
or more likely, a megabyte or two
<azonenberg_work>
then a few ms later you get another MB of data from the next capture
<Prf_Jakob>
azonenberg_work: Well you could send the processed or raw sample data to the gpu and write a clever shader to generate the waveform.
<azonenberg_work>
Repeat for a few thousand waveforms per second
<azonenberg_work>
That's the plan
<azonenberg_work>
The GPU will also do protocol decodes in CUDA
<awygle>
rqou: i immediately assume "i can't afford this", crapness is an independent axis
<azonenberg_work>
(no plan to support non-nvidia cards for that)
<Prf_Jakob>
As a AMD fan, please use OpenCL :p
<awygle>
i wish opencl was a viable alternative, i really do
<azonenberg_work>
Last time i checked opencl - opengl interop (same buffer used as both texture/vertex data and compute data) was hard to impossible
<azonenberg_work>
and cuda did it well
<awygle>
but it's just _so much worse_ than CUDA
<rqou>
I'm not fundamentally against proprietary software or anything like that, but stuff that hides behind "contact us" always makes me skeptical
<azonenberg_work>
This was several years ago
<Prf_Jakob>
Or just OpenGL compute.
<balrog>
why not opengl compute?
<awygle>
yeah azonenberg_work for your application compute shaders actually amke sense
<balrog>
azonenberg_work: please don't do CUDA without a cross platform implementation that's not vendor locked :<
<azonenberg_work>
balrog: because that didnt exist in opengl 2.x when i last used gl? :p
<azonenberg_work>
i'm going to look at the various options
<balrog>
nvidia *loves* when people use cuda :(
<awygle>
compute shaders almost never make sense for GPGPU but for "computing on stuff i also have to render" they make a lot of sense
<rqou>
e.g. proprietary CAD/EDA at least tends to have screenshots and/or feature lists even though the $$$$ is hidden behind "contact us"
<awygle>
balrog: does opencl have unified memory yet?
<azonenberg_work>
awygle: i dont want unified memory
<awygle>
or some analogy to streams?
<azonenberg_work>
i like numa
<awygle>
azonenberg_work: i know lol
<rqou>
network card dma into vram when :P
<awygle>
rqou: now, if you have the right network card
<rqou>
(this apparently already works if you can convince the APIs to let you)
<azonenberg_work>
That would be nice, but i may have to do a pass through main system ram
<awygle>
azonenberg_work: implement a NIC :p
<azonenberg_work>
still, i should be able to get way better performance then rendering in cairo :p
<azonenberg_work>
awygle: i've thought about it but dont want to deal with pcie
<azonenberg_work>
and i cant exactly hang a nic off of 40GbE
* awygle
does
<balrog>
rqou: did you read the presentation on that Basis compression thing?
<azonenberg_work>
pcie and usb are two protocols i never want to touch
<rqou>
"the" presentation?
<rqou>
balrog: which one?
<balrog>
slides from GDC2017 talk
<balrog>
it looks like a library that provides for texture compression optimized to quickly/easily decompress to GPU formats
<balrog>
> Follow this link for full slides of this GDC 2017 talk
<rqou>
yes, I've seen that
<rqou>
it doesn't seem to tell me anything
<awygle>
what is it that you'd want it to tell you?
<rqou>
a rough idea of what the algorithm does, why it can be universal and/or compress better
<rqou>
e.g. (bullshit example follows) "it's novel because we used machine learning and blockchain to make other people run the algorithm for us" would be a good quick overview
<qu1j0t3>
that'd be a window i'd close in about 3 nanoseconds
<rqou>
right, it was a nonsense example
diadatp has quit [Ping timeout: 263 seconds]
<qu1j0t3>
:)
<cr1901_modern>
Don't think you'll get that level of detail wrt the compressor; that part is proprietary
<cr1901_modern>
decompressor is open tho
<rqou>
the impression i normally get from secrecy like this is that either *) it's vaporware *) it's actually pretty trivial
<rqou>
imho for something that actually requires a bunch of engineering to recreate, giving a rough overview shouldn't hurt anything
<awygle>
I honestly don't even think it's terribly proprietary, just uninteresting to her intended audience
<awygle>
She's not presenting an academic paper, she's pitching businesses
<cr1901_modern>
Well that too
<rqou>
yeah, I'm probably not the intended audience at all because I'm only really interested in the tech and don't really have a use for the actual product
<rqou>
also, in case it might be misinterpreted, i don't think she is a fake, and i withdraw the use of the term vaporware
<awygle>
Right. On Twitter she's talked at length about removing technical details from slides like these
<awygle>
rqou: sorry if I kind of piled on you there, didn't mean to.
<rqou>
i was trying to convey the sense of "duke nukem forever" and not "lol no way she did that"
<rqou>
no, it's fine. i realized myself why the word vaporware is bad
<balrog>
vaporware is very much inaccurate in this case
<rqou>
especially given current events
<balrog>
rqou: I feel like part of it in this case is "let's not encourage widespread adoption pre-standardization of the format"
<balrog>
just like why there isn't yet an AV1 spec
<awygle>
balrog: didn't that come out like last week?
<balrog>
(well there is, but it's not finished and no one supports it yet. there wasn't one until very recently)
<q3k>
cr1901_modern: I'd like to start experiment with formally verifying migen/litex code (of my own), and I'm wondering if there's any reason this isn't upstreamed into migen
<awygle>
Kk lol
<balrog>
awygle: it was in "closed" draft for several months
<rqou>
now how big is the patent portfolio around it? :P
<awygle>
big enough for MAD I think
<balrog>
rqou: also remember that S3TC just lost patent protection a few months ago
<rqou>
oh wtf
<rqou>
patents suck - news at 11
<rqou>
I'm particularly unimpressed by compression patents in particular because for some reason there's a lot of them but the fundamental research was all done in the 70s and 80s
<rqou>
imho entropy coding and fourier-like transforms just aren't that novel or interesting
<balrog>
yep
<balrog>
and generally should have a ton of prior art
<balrog>
if you dig around enough
<cr1901_modern>
q3k, see #m-labs chat
<balrog>
cr1901_modern: have you done any more pic work?
<balrog>
I'm just wondering how that's coming along
<cr1901_modern>
balrog: I got a blinky
<balrog>
nice :D
<balrog>
the route I was going to take was to port a usb demo to it
<rqou>
oh _you're_ the one helping hack the tl866
m_t has quit [Remote host closed the connection]
<balrog>
I was looking at porting the cdc_acm m-stack example
<balrog>
if you want WIP code I can send it
m_t has joined ##openfpga
<rqou>
at least this means that this work is in good hands :P
<cr1901_modern>
rqou: Thanks for the compliment, but I haven't done much yet :P
<cr1901_modern>
balrog: I'm waiting for digshadow to get back to me about mstack
<digshadow>
cr1901_modern: what about mstack? I wasn't aware you were waiting on anything
<q3k>
afaik if you want to actually ship something with the usb logo you'll need to get certified with usb-if, anyway
<rqou>
so just don't? lol
<q3k>
(certified that you have enough money to pay them)
<RaivisR>
awygle, the guy responsible for pid.codes is on this chan
<digshadow>
If its a question whether to use it vs cypress, I'd say use mstack if it seems plausible
<digshadow>
but I don't have a strong opinion. Just keep the usb stack source code clearly separated
DocScrutinizer05 has quit [Ping timeout: 263 seconds]
<rqou>
afaik (ianal) if you don't use usb logos you can pretty much do whatever you want including squatting vids
<awygle>
there are many things in the linux table with opemoko or pid.codes vids, but none with 0xf055
<cr1901_modern>
digshadow: See privmsg
<cr1901_modern>
ahhh
<cr1901_modern>
alright
<awygle>
to be fair to usb-if (who do not deserve it), there is a compliance testing element to certification, iiuc
<rqou>
lol sure
<rqou>
like inrush and suspend current? :P
* awygle
shrugs
DocScrutinizer05 has joined ##openfpga
<rqou>
cc lain :P
<awygle>
i just know they have key parties^H^H^H compliance workshops
<awygle>
azonenberg_work: what temperature do you use for your iron when doing rework on SAC305?
mumptai has joined ##openfpga
mumptai has quit [Remote host closed the connection]
<azonenberg_work>
awygle: with my current aoyue? about 350C
<awygle>
jeebus
<azonenberg_work>
Although who knows if thats actually the temp the tip runs at :p
<awygle>
i used to use 350C for leaded, i had to pump my Hakko to 400 last night to get even reasonable reflow
<azonenberg_work>
i'm considering running decently lower with a curie point iron
<q3k>
uhm
<q3k>
either your measurement is off
<q3k>
or you're using a shitty thin conical tip
<q3k>
or that is a MASSIVE ground plane
<q3k>
for leaded solder
<awygle>
i'm using a pretty small tip but it's not conical
<awygle>
starting to suspect the temp measurement is off
<q3k>
i regularly do 320 dungerees science for leaded
<q3k>
cranking it up 350 when doing large ground planes
<awygle>
the entire board is two giant ground planes with stitching vias, but that shouldn't affect like, normal pads
<q3k>
shouldn't
<awygle>
... i wonder if it's in fahrenheit?
<awygle>
but then it'd be too low...
<q3k>
and it's not like I have a great iron, fakko fx-888d with genuine tip
<q3k>
*hakko
<awygle>
that's exactly what i have
<q3k>
but that is an okay mispelling
<q3k>
yeah, 400 freedom temperature units wouldn't touch solder
<q3k>
get one of those tip temperature measurement gadgets
<q3k>
iirc the station has a copensation setting - did you get it second hand and it was perhaps mis-set?
<q3k>
*compensation
<awygle>
i got it from amazon iirc
<awygle>
but it was like 3 years and 2 cross-country moves ago
<awygle>
so it could have become mis-compensated
diadatp has quit [Ping timeout: 264 seconds]
diadatp has joined ##openfpga
diadatp has quit [Read error: Connection reset by peer]
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
diadatp has joined ##openfpga
Bike has joined ##openfpga
diadatp has quit [Ping timeout: 265 seconds]
diadatp has joined ##openfpga
bitd has quit [Quit: Leaving]
<rqou>
wtf
<rqou>
cortex-m-rt dropped zero-cost stack overflow protection in order to gain support for lld?
<rqou>
in what world is this even close to a good trade-off?
<awygle>
wow that's uh
<awygle>
bold
<awygle>
especially for "size". like who cares
<rqou>
no, "size" was needed for the stack overflow protection trick to work
<awygle>
oh, really?
<rqou>
but honestly i would just ignore the llvm equivalent of binutils altogether
<rqou>
IME they basically completely don't work
<awygle>
well of course you would rqou
<rqou>
what do you mean?
<awygle>
i would, perhaps, _fix_ LLD
<awygle>
or at least feature flag that stuff off
<rqou>
although i've been told i'm a pretty big abuser of binutils
<qu1j0t3>
"But I can give it up any time I want."
<rqou>
e.g. i used to have a build system that would objcopy a binary into a .o
<rqou>
and afaict llvm just doesn't have that
<Ultrasauce_>
yeah I just switched my android stuff over to clang and I noticed the ndk still uses the gnu binutils
<Ultrasauce_>
which introduces some great incompatibilities!
<rqou>
wait why?
<rqou>
i thought that's supposed to work better?
<Ultrasauce_>
well they did deprecate gcc
<rqou>
ime "just" replacing gcc with clang works fine in theory
<rqou>
except the clang compiler driver is different/dumber
<awygle>
hmm i wonder why arm-none-eabi-size died on lld files
<awygle>
that seems like a pretty normal thing to do
<rqou>
but if you manually tell clang to link stuff like crt1 it works
* awygle
is reading blog posts
<Ultrasauce_>
I hit some obnoxious abi incompatibilities and ran away screaming
<Ultrasauce_>
not a yak I have time to shave these days...
<awygle>
this whole thing seems overcomplicated and makes me want to write a constraint satisfaction linker
<jn__>
i heard the chromeos SDK uses gcc + clang++
<rqou>
yeah, that's been my overall impression of the clang/llvm ecosystem
<awygle>
well not the clang/llvm stuff, japaric's hack to get a section linked at the top of RAM
<rqou>
oh that lol
<rqou>
yeah, it's kinda dumb
<awygle>
also, i know it's not intended to, but this wouldn't work on an MSP430 for several reasons
<awygle>
and i'm frankly surprised it works on arm
<rqou>
why not?
<awygle>
i guess 32 bit address space gives you room for a sparse memory map
<awygle>
but on msp this would just run into device registers and end up setting your UART clock to some bizzare value
<rqou>
lol
<awygle>
also writes to unmapped memory (of which there is some) don't always trap on msp, it depends where you are in the memory map
<awygle>
sometimes they "complete" but have no effect
<rqou>
yeah i think avr is similar
<rqou>
but potato uCs will be potatos, not much you can do
<Ultrasauce_>
afaik most cortex-m implementations will have regions like that
* awygle
resists the urge to be defensive about msp430s
<Ultrasauce_>
stm32 is better fite me irl
<awygle>
eh i'm not interested in "better" really
<awygle>
stm32s are good, so are msp430s
<awygle>
avrs are not :p
<balrog>
avr or pic?
<awygle>
actually avrs are fine. the only actually "not good" micros i've used were pics
<balrog>
:D
<Ultrasauce_>
I like how simple putting together an avr toolchain is
<balrog>
too bad mikeryan isn't here or I'd quote him xD
<awygle>
... isn't AVR still not upstream in GCC?
<balrog>
awygle: pretty sure it is
<balrog>
awygle: why is there no good pic18 C compiler?
<balrog>
well there is a good one but it deoptimizes code unless you pay for it
<rqou>
AVR's been upstream in gcc since forever
<balrog>
is the architecture so badly suited for C?
<rqou>
balrog: yes
<rqou>
it's awful
<rqou>
one register
<awygle>
hmm, i guess it is
<rqou>
no call indirect iirc
<awygle>
LLVM was pretty recent
<awygle>
something i always wanted to do but never got around to was play with msp430-qemu
<rqou>
at some point someone really needs to get out their asbestos flame-resistant armor and then write a thing that duct-tapes gcc .md files into LLVM :P
<awygle>
ah yes, gcc-flavored markdown
<rqou>
lol
<q3k>
balrog: SDCC does PIC18
<balrog>
q3k: not well
<q3k>
well, as well as you can compile C for that ungodly architecture
<balrog>
supposedly the XC8 compiler does better if you pay for it
<q3k>
but I assume you're better off spending your budget on moving to a uC family that isn't objectively bad
<rqou>
yeah, it's weird how PIC seems to be in the boundary of microcontrollers that are proprietary crap vs having open tools
<awygle>
the fact that all this compiler talk makes me want to finish my MSP430 LLVM backend stuff is exactly why i have such a hard time ever finishing any projects
<balrog>
rqou: what's more common is proprietary libs
<rqou>
oh that's still a thing
<balrog>
(see: esp8266)
<rqou>
yeah, exactly what i had in mind
<balrog>
(brcm is also a huge offender but they're not really uC)
<balrog>
awygle: llvm doesn't have msp430 upstream already?
<q3k>
even nrf52 still wants you to run this huge proprietary blob if you want BLE
<q3k>
because they implemented tons of stuff in software and are anal about someone possibly 'stealing' it (why?!)
<rqou>
i thought there was an open thing under the apache umbrella?
<balrog>
rqou: referring to what?
<awygle>
balrog: it does but it doesn't have an MC layer or LLD support
<balrog>
awygle: ah...
<rqou>
it's especially weird because afaik BLE's physical layer isn't really that interesting
<rqou>
balrog: nrf52
<awygle>
balrog: also the code generation needed substantial work the last time i looked at it (but pftbest has been doing at least some stuff)