pie__ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
s0n1cB00m has quit [Quit: Till next time!]
m_w has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
amclain has quit [Quit: Leaving]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<azonenberg>
rqou: try running yosys on that box
<azonenberg>
Or does it not work?
<azonenberg>
also, just got home
<azonenberg>
Investigating the crash now
digshadow has quit [Ping timeout: 255 seconds]
<azonenberg>
rqou: soooo i cannot reproduce
<azonenberg>
I get a bunch of warnings for "couldn't get timing data"
<azonenberg>
but not a crash
<azonenberg>
when there's no timing.json
<azonenberg>
this is the intended result
<azonenberg>
(eventually the file will obvs be called "timing-slg46620.json" etc
<azonenberg>
)
<openfpga-github>
[openfpga] azonenberg commented on issue #94: What platform/architecture? Can you provide a core dump or gdb backtrace etc?... https://git.io/vHir1
<openfpga-github>
[openfpga] azonenberg opened issue #95: Regression from hidapi switchover: Multiple dev boards don't seem to work right https://git.io/vHirF
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Po-ta-to, boil em, mash em, stick em in a stew.]
eightdot has quit [Ping timeout: 268 seconds]
eightdot has joined ##openfpga
eightdot has quit [Ping timeout: 246 seconds]
eightdot has joined ##openfpga
eightdot has quit [Ping timeout: 240 seconds]
eightdot has joined ##openfpga
eightdot has quit [Ping timeout: 240 seconds]
eightdot has joined ##openfpga
eightdot has quit [Ping timeout: 255 seconds]
eightdot has joined ##openfpga
eightdot has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 246 seconds]
<rqou>
azonenberg: just to clarify, the "multiple boards don't work" is on the merged master, right?
<rqou>
not on the crap removal PR?
<openfpga-github>
[openfpga] rqou commented on issue #94: This is really strange. Crashed for me on both x86_64 and PPC Debian Sid, and seems to be an infinite loop in FindCombinatorialPaths:... https://git.io/vHi1h
<openfpga-github>
[openfpga] rqou commented on issue #95: Can you please run before/after with --debug? https://git.io/vHiMs
<openfpga-github>
[openfpga] rqou commented on issue #95: Er, really strange question: while testing this, did you ever run the old libusb-based version? If so, then this version will not work until you unplug and replug the board. This is because the old code detached the Linux HID driver to get it out of the way, but it doesn't ever attach it back. Once that happens, this version can't access it anymore. https://git.io/vHiMu
eightdot has joined ##openfpga
<openfpga-github>
[openfpga] rqou closed issue #68: Every other invocation of gp4prog fails on Raspbian on RPi2 https://git.io/vyTti
<rqou>
azonenberg: could you also please test the crap removal PR? that has rewritten how enumeration works
<azonenberg>
rqou: that is on the merged master
<azonenberg>
Just got back from grocery shopping
<azonenberg>
have a few things to take care of first
<openfpga-github>
[openfpga] azonenberg commented on issue #95: That would explain a lot. Confirmed, that's the problem.... https://git.io/vHiD6
<cr1901_modern>
Who the hell goes grocery shopping at 10 at night?
<azonenberg>
cr1901_modern: Me, obviously
<azonenberg>
$WIFE worked as a night stocker at walmart in a previous career
<azonenberg>
We're used to it
<cr1901_modern>
... Huh... I see...
<azonenberg>
and if i come home from work, we have dinner, then we wait around an hour or so for rush-hour traffic to die down
<azonenberg>
it's 2100 or so
* cr1901_modern
goes back to lurking, satisfied with the answer.
<azonenberg>
then if i code for a few minutes before we leave it's a bit later, so shopping from 2130 to 2200, then put stuff away, it's 2215
<azonenberg>
rqou: i'll test the other PR in a bit
<azonenberg>
Re #94, i'll investigate further but there's a good chance the problem will go away as i continue implementing the timing analyzer
<azonenberg>
it's going to get refactored massively
<azonenberg>
So i dont want to spend a ton of time hunting it at this point
<azonenberg>
there's so much placeholder code and i suspect hte bug is in there
<azonenberg>
And speaking of timing.json, i have some optimization to do on my characterization code
<azonenberg>
right now doing a single chip, measuring I/O buffers, LUTs, cross-connections, inverters, and delay lines at 3.3V +/- 5%. ambient temperature only
<azonenberg>
takes 1078 seconds
<azonenberg>
once i add 1.8 and 5V range it'll be closer to an hour
<azonenberg>
and that isnt even all the hard IP, or temperature corners
<azonenberg>
right now i am bottlenecking horribly on the jtag interface, i need to push more of my measurement code into the FPGA
<azonenberg>
so i only report results rather than lock-stepping every bit of the measurement
m_w has quit [Quit: leaving]
pie_ has joined ##openfpga
<rqou>
heh, as opposed to grocery shopping, i just went to one of berkeley's "meme" fast food restaurants :P
<openfpga-github>
[openfpga] rqou commented on issue #95: Just for completeness, I tested interactions with the blob. The blob doesn't seem to have problems grabbing the device even if libusb detached the kernel driver, but it also does correctly reattach the kernel driver, so there are no new problems with that. https://git.io/vHiSJ
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 245 seconds]
<cyrozap>
rqou: nicememe.restaurant
<cyrozap>
Yes, that's a valid domain name and it's available to purchase.
<rqou>
i think i have enough vanity domains for now
<rqou>
(thanks lain :P )
<azonenberg>
WTFFFFF
* azonenberg
stares at console log
<azonenberg>
Apparently moving an inner loop from "C talking to FPGA over JTAG" to an FPGA state machine that runs in a couple of clock cycles
<azonenberg>
resulted in a ~40% *slowdown*
<azonenberg>
i have to have screwed something up somehow
<rqou>
so out of curiosity i looked at how much effort it would be to try and support freebsd in the hidapi backend _without going through libusb_
<rqou>
it appears (haven't actually tried) that the user<=>kernel interface is much simpler
<rqou>
but random stuff like "how do I enumerate devices" isn't really documented too well
<rqou>
but the actual data exchanging just uses read() and write()
<rqou>
why do people still use libusb?
<rqou>
libusb's code has a ton of random crap in it too
<rqou>
plus there was the hostile takeover
<azonenberg>
Presumably for non-HID applications
<azonenberg>
Not familiar with the politics
<rqou>
the old maintainer gave a talk at CCC about how some person from ireland staged a hostile takeover of the project
<rqou>
you might remember there was a libusbx at one point? that was the thing
<rqou>
nobody really noticed because nobody really cares about libusb as long as it just magically stays working
<azonenberg>
sooo profiling a bit to see where bottlenecks in gp4tchar are
<azonenberg>
Loading a new bitstream takes ~120 ms
<azonenberg>
the post-program setup (changing the voltages and waiting a bit for them to stabilize) takes ~60 ms
<azonenberg>
Measuring a pin-to-pin delay takes ~4 sec
<azonenberg>
interestingly enough it's variable, it took as little as 2 in one case and 3 another but otherwise almost exactly 4 sec
<azonenberg>
Guess it's time to profile the measurement code now
<rqou>
hmm i just noticed i introduced a fun footgun with the hidapi change
<rqou>
if you aren't root and didn't use the udev config file, you'll get a really strange error
<azonenberg>
oh?
<azonenberg>
can that be sanely fixed?
<rqou>
because with hidapi enumeration will succeed but opening will fail internally
<azonenberg>
interesting
<rqou>
or maybe it always did that?
<azonenberg>
i recall opening failing if you didnt have perms
<rqou>
the message you'll get is "ERROR: hid_open_path failed"
<rqou>
hmm maybe it always did that
<azonenberg>
Sooo it looks like each measurement currenelty tkaes ~20 ms
<azonenberg>
takes*
<azonenberg>
innnteresting
<azonenberg>
Because that suggests there is a bottleneck FPGA-side??
<openfpga-github>
[openfpga] rqou opened issue #96: gp4prog: print a more helpful message if there is a permission error https://git.io/vHiQV
<cyrozap>
rqou: There's a lot of random crap in libusb to deal with weird variations between platforms.
<rqou>
none of it seems to affect "here, have a control transfer"
<cyrozap>
It has to work around any OS bugs that exist.
<rqou>
it's for stuff like isoc or silly platforms like android it seems
<rqou>
except the particular code i was looking at was how on linux, there is a "udev" code path, a "sysfs" code path, and a "usbfs" code path
<rqou>
just to enumerate devices
<rqou>
apparently device enumeration is hard on every platform
<azonenberg>
ooook so
<azonenberg>
If i comment out most of the FPGA code and just return a bogus value immediately
<azonenberg>
i get ~1.1 ms per inner-loop iteration
<azonenberg>
Which makes sense, it's bottlenecked by the ~1 ms USB RTT
<azonenberg>
Sooo this means my FPGA code that should run almost instantaneously
<azonenberg>
is taking ~19 ms to run
<azonenberg>
wtff
Hootch has joined ##openfpga
<rqou>
heh, i'm writing metadata intended for future use on crates.io for xc2bit
<rqou>
searching crates.io for "eda" -> 0 results
<rqou>
"fpga" -> 0 results
<rqou>
"hdl" -> 2 results
<rqou>
so... yeah
<rqou>
"web" -> 335 results
<rqou>
hmm rust just doesn't have that many crates yet
<rqou>
<10k crates total
<rqou>
azonenberg: if you were to pick <=5 keywords to describe xc2bit, what would they be?
massi has joined ##openfpga
<azonenberg>
um
<azonenberg>
fpga bitstream xilinx coolrunner eda
<azonenberg>
?
<rqou>
not "cpld?"
<azonenberg>
oops
<azonenberg>
sorry yeah
<rqou>
hmm any potential trademark problems with xilinx and coolrunner?
<azonenberg>
IANAL but we'd be using them to refer to a product our toolchain targets
<rqou>
yeah, i think that makes it ok
<azonenberg>
generally the point of a trademark is to prevent third-party knockoffs from reusing the original branding
<rqou>
probably needs a disclaimer in the readme
<azonenberg>
we're using them to refer to the actual manufacturer's product
<azonenberg>
as long as it's clear we're neither affiliated nor endorsed with the OEM
<azonenberg>
should be ok
<rqou>
yeah, but we don't have one of those CYA disclaimers right now :P
<azonenberg>
I have one for the greenpak stuff
<azonenberg>
in the doc
<azonenberg>
So probably not a bad idea to add one
felix_ has quit [Ping timeout: 240 seconds]
felix_ has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 240 seconds]
qu1j0t3 has joined ##openfpga
qu1j0t3 has quit [Ping timeout: 246 seconds]
qu1j0t3 has joined ##openfpga
<rqou>
"cargo doc" is amazing
<rqou>
by far the best documentation tool i've used
<openfpga-github>
[openfpga] rqou pushed 16 new commits to master: https://git.io/vHPIP
<openfpga-github>
openfpga/master ea22558 Robert Ou: xc2bit: Refactor IOB into its own file
<openfpga-github>
openfpga/master ae2cf4f Robert Ou: xc2bit: Add Cargo metadata
<openfpga-github>
openfpga/master 368ae67 Robert Ou: xc2bit: Clean up magic numbers related to FB structure
<jn__>
hmm, wait, that's doesn't directly show rustdoc generated content
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
digshadow has joined ##openfpga
<azonenberg>
rqou: this is why i havent gone beyond the 2c256 in my testing
<azonenberg>
i just pretend the 384/512 dont exist
<azonenberg>
(you can probably imagine why the 1024 got axed)
amclain has joined ##openfpga
massi has quit [Remote host closed the connection]
pie_ has quit [Ping timeout: 240 seconds]
digshadow has quit [Ping timeout: 255 seconds]
azonenberg_work has joined ##openfpga
m_w has joined ##openfpga
m_t has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
Guest61631 is now known as gruetzkopf
digshadow has joined ##openfpga
mifune has joined ##openfpga
pie_ has joined ##openfpga
eightdot has quit [Ping timeout: 246 seconds]
eightdot has joined ##openfpga
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
m_w has quit [Client Quit]
m_w has joined ##openfpga
<azonenberg>
Innnteresting
<azonenberg>
So it looks like the new greenpak5 part just announced yesterday
<azonenberg>
has four 150 mA LDOs
<azonenberg>
But they also have SKUs with two 300 mA or one 600 mA
<azonenberg>
Which makes me think they're the same die just bonded out in parallel
<openfpga-github>
[openfpga] azonenberg opened issue #97: Refactoring: Rename gp4par to "gpkpar" to reflect planned support for other GreenPAK device families https://git.io/vHXml
<openfpga-github>
[openfpga] azonenberg commented on issue #97: This applies to gp4prog as well https://git.io/vHXm4
digshadow has quit [Ping timeout: 245 seconds]
<openfpga-github>
[openfpga] azonenberg opened issue #98: Refactoring: Rename Greenpak4Netlist*, possibly move to xbpar, since it's fairly free of GP4-specific code https://git.io/vHXmE
<openfpga-github>
[openfpga] azonenberg opened issue #99: Refactoring: Everything in gp4par/make_graphs.* should move to Greenpak4ParEngine https://git.io/vHXYs
digshadow has joined ##openfpga
<azonenberg>
rqou: my hope is that in a couple of months i'll have largely caught up with the core IP blocks that they're reusing everywhere
<azonenberg>
and adding support for a new greenpak will be as simple as adding one function that just specifies where in the bitfile each block goes
<azonenberg>
and/or implementing any new blocks that they introduced with that part
<azonenberg>
and running my existing timing characterization tool on a few samples of the new part