<azonenberg_work>
I was working on the hardware side of things in my limited spare time
<azonenberg_work>
In between doing starshipraider for $dayjob, rtl for $sidegig, and construction :p
<rqou>
wait this side gig is _still_ going?
<azonenberg_work>
awygle: that table is a WIP but has much higher performance than the old version somewhere in the antikernel repo
<azonenberg_work>
Which is more thoroughly tested but cant handle 4x 10G interfaces worth of packet rate
<azonenberg_work>
rqou: um, yeah
<azonenberg_work>
not the first one, this is the second
<azonenberg_work>
how do you think i'm paying for all these construction supplies?
<rqou>
the HPC one, right?
<rqou>
i thought you were paying via your normal job
<awygle>
that's how he's paying the mortgage :p
Bike has quit [Quit: Lost terminal]
<azonenberg_work>
$dayjob basically covers mortgage, hotel, groceries, and gas
<rqou>
or paying via your wife's doodles of porkymans
<azonenberg_work>
And i think she's maybe sold enough this year to buy a pizza?
<azonenberg_work>
:p
<azonenberg_work>
(that and, her computer, drawing tablet, and art supplies are all in a box right now)
<awygle>
this is ~exactly why i don't own a house and have no plans to in the near future
<rqou>
lolwat
<rqou>
you really need to set that up so your wife can sell even more porkyman drawings :P
<azonenberg_work>
awygle: Owning a house is fine, owning a house AND paying to live somewhere else is expensive :p
<azonenberg_work>
I'd have quite a bit of surplus cash if i wasnt paying for housing twice
<azonenberg_work>
Even without $sidegig
<azonenberg_work>
i think if you add up the hotel and mortgage i'm paying about $60K/yr in housing
<rqou>
wait haven't you moved all your actual stuff over already?
<rqou>
can't you just crash at monochroma until you're done?
<azonenberg_work>
rqou: the lease on the rental ended july 31st
<azonenberg_work>
Our stuff is at the new house, piled up in boxes and under tarps while we sheetrock around it
<rqou>
right, but wouldn't staying with monochroma be cheaper than staying in a hotel?
<azonenberg_work>
That's one of the things slowing us down, we have to move all the boxes out of one room to work in another
<azonenberg_work>
Last time i talked to her it didnt seem like that was an option? she had offered initially then something came up that made it not possible
<azonenberg_work>
i forget details
_whitelogger has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
<awygle>
are the backs of network panels/low voltage panels standardized? the mounting hole pattern?
<openfpga-github>
Glasgow/master 33b526b whitequark: applet.{i2c_master,spi_master}: move to respective subdirectories.
<awygle>
whitequark: lol/sob
pie_ has joined ##openfpga
<whitequark>
awygle: anyway I think we have "MVP" gateware
<whitequark>
and software
<awygle>
hooray
<awygle>
we're the most valuable players
<awygle>
i think rev B is good to go, just needs a few tweaks to reduce coupling on the FPGA<->FXMA bus
<awygle>
so i guess not good to go, but close
<whitequark>
awygle: alright
<whitequark>
do you think you can order revB to your place and assemble it?
<whitequark>
i'm on clomipramine and hand tremors make it nigh impossible to place 0603
<awygle>
yep, no problem
<whitequark>
hell, I couldn't solder a 1.5 sq mm wire when I was on a larger dose
<whitequark>
can you make three? one for you, two for me
<whitequark>
so I can test sync
<awygle>
i'll make at least 4, so we can give azonenberg_work one
<awygle>
since that's come up recently several times
<whitequark>
ssweet
<whitequark>
thanks!
<whitequark>
and I guess once you're ready, same for revC
<whitequark>
I'll need to review your branch
<awygle>
yeah i'll bump that higher in priority now that you think we've dug out all the pcb bugs
<whitequark>
yep I think so
<awygle>
coolcool
<azonenberg_work>
Woo debugging
<awygle>
you're a debugging
<awygle>
so you want a rev B, azonenberg_work?
<azonenberg_work>
awygle: If somebody else assembles it, sure
<azonenberg_work>
I wont have a functioning lab for a while still
<whitequark>
azonenberg_work: to reiterate, revB doesnt tolerate pullups
<whitequark>
or pulldowns
<whitequark>
smaller than about 200k
<azonenberg_work>
I dont think i normally have pull*s on my jtag interfaces
<azonenberg_work>
except for whatever is on die
<whitequark>
sure
<whitequark>
oh, that reminds me
<whitequark>
I need to finally hook up MPSSE
<azonenberg_work>
Hmm, TDI and TMS have on die pullups
<whitequark>
how large?
<azonenberg_work>
The answer record doesnt say :p
m4ssi has quit [Remote host closed the connection]
<whitequark>
they're usually really weak on modern chips
<whitequark>
for power saving reasons
<whitequark>
so it's probably fine
<azonenberg_work>
Yeah thats what i figured
<azonenberg_work>
Incidentally, things like this are one of the many reasons i did not go with auto direction sensing on starshipraider
<whitequark>
azonenberg_work: FXMA was a deliberate choice for revA
<whitequark>
because I did not want BGA and could not fit explicit direction pins with the UP5K
<whitequark>
I knew it would be bad
<rqou>
iirc i warned you about this :P
<whitequark>
I have not expected that *literally every single real device* I needed to hook up to has pullups
<azonenberg_work>
Lol
<whitequark>
except for maybe UARTs
<whitequark>
though I think those just had weak on-die pullups
* azonenberg_work
continues to be amused at you hitting every single issue i did with starshipraider
<azonenberg_work>
Is the design space really that constrained that all you can do is pick slightly different tradeoffs?
<whitequark>
I think so yea
<whitequark>
well, there's some more significant differences
<whitequark>
like how I'm using USB and relying on the fast compile times for the FPGA
<whitequark>
less than 30s
<whitequark>
this means I don't need muxes inside, for example
<azonenberg_work>
so you do runtime recompilatoin to change config?
<rqou>
there's also my vaporware Guren that'll hit yet another part of the design space
<azonenberg_work>
yeah i am going to just use a big fpga and have lots more customizability there
<whitequark>
azonenberg_work: yep
<whitequark>
and I make it possible to compose applet
<whitequark>
*applets
<whitequark>
right now you can only compose up to two and each gets a separate HW port
<whitequark>
but in the future there'll be a mux so you could compose as many as you want
<whitequark>
this isn't really possible with prebuilt bitstreams
<whitequark>
Glasgow is fundamentally enabled by icestorm, it would never work with traditional toolchains
<rqou>
build all permutations? :P
<whitequark>
lol
<whitequark>
icestorm and migen I guess
<whitequark>
azonenberg_work: currently I don't even use registers for setting bit rate
<rqou>
it'll be like a shitkit3 :P
<sorear>
is there any "real fpga tool" precedent for having "symbolic values" in synthesis/pnr so that you can track a specific LUT and then change it post-pnr?
<whitequark>
sorear: sure
<whitequark>
you can give LUTs names and fix them in post-place blif
<whitequark>
I think currently icestorm doesn't quite always propagate those, though maybe it does
<whitequark>
in any case it's easily fixed
<sorear>
I know for a fact ASIC tools do this (exposing certain specific configuration values in such a way that they are in the top metal layer and can be changed *while dies are in the pipeline*)
<whitequark>
you can also do this kind of thing with tcl in xilinx tools
<whitequark>
it's not really ahrd
<whitequark>
assuming you're willing to synthesize the LUTs yourself
<sorear>
can you also use the tools to edit a specific named lut in a bitstream?
<whitequark>
icestorm bitstreams don't have module names
rohitksingh has quit [Quit: Leaving.]
azonenberg_work has quit [Ping timeout: 252 seconds]
<whitequark>
i guess you could take a signal name
<whitequark>
and go backwards to find a driver
<whitequark>
that'll work
<pie_>
<fouric> apparently, it's common practice in Verilog to use _three_ spaces per level of indentation
<pie_>
cursed
<whitequark>
fuck verilog :p
<awygle>
ugh we did that at my old employer
<awygle>
specifically because we couldn't agree on 2 or 4
<pie_>
awygle, jesus lol
<awygle>
so the Powers That Were decided universal misery was superior to 50% misery
<pie_>
awygle, just
<pie_>
fucking
<whitequark>
LOL
<awygle>
shortly after that decision i discovered i was a hardware engineer :p
<pie_>
have a repo canonical indentation and eeryne can set their editors up to do whatever they want
<awygle>
pie_: this is why i'm Team Tabs till i die
<pie_>
awygle, something something soft tabs?
<awygle>
if you like the separation of CSS and HTML, you should use tabs
<pie_>
i think i like spaces with soft tabs because it doesnt fuck up something
<awygle>
tabs are semantic not presentational, you can present them however you like and we can all be happy
<pie_>
i dont remember what the something is
<whitequark>
awygle: thats not true
<awygle>
just teach people that if they care about presentation they need to use real spaces
<pie_>
maybe pasting into the html
<whitequark>
people align stuff with tabs
<pie_>
jesus did i type that
<whitequark>
and then it breaks horribly
<pie_>
*pasting into a browser or something
<awygle>
whitequark: yeah they do and they need to stop
<whitequark>
inevitably
<awygle>
which of course is not a realistic expectation
<whitequark>
it's easier to convince them to use spaces
<pie_>
whitequark, oh yeah that might have been it
<whitequark>
yeah
<awygle>
i'm aware of why we can't have nice things
<whitequark>
lol
<awygle>
but it doesn't mean i'm not salty about it
<whitequark>
well
<whitequark>
tabs are a stupid hack
<whitequark>
we should represent code as ASTs
<whitequark>
the problem is illegal states
<whitequark>
awygle: also there's the GNU style
<awygle>
i agree with that as well
<whitequark>
where you indent by two columns using tabs for a multiple of four and then spaces
<awygle>
the "represent as ASTs"
<whitequark>
i can't believe this is not satire
<awygle>
I Can't Believe It's Not Satire
<whitequark>
lol
<awygle>
yeah there are many reasons i've never contributed to GNU software and i'd be lying if i said that wasn't one of them
<whitequark>
i once needed to fix a bug in binutils
<whitequark>
where it would have a split brain situation with regards to _GLOBAL_OFFSET_TABLE_ symbol and .got
<whitequark>
it'd place _G_O_T_ at the start of PLT or something
<whitequark>
christ that code is horrendous
<awygle>
don't worry it just underpins all the foudnations of modern computing
<sorear>
i find it hard to care about tabs when the code has hard form feeds
<whitequark>
lol yes
<whitequark>
awygle: well there's lld now
<whitequark>
i think freebsd uses clang+lld for a while
<sorear>
maybe someday lkml will be convinced to care about llvm, or fuschia or something else will take over
<awygle>
i know they _can_, i don't know if they _do_ by default
<whitequark>
sorear: there's lvmlinux
<whitequark>
llvmlinux
<whitequark>
they've upstreamed almost everything by now
<rqou>
let me know when clang/llvm will stop having a compiler driver that's too smart and undocumented for its own good
<sorear>
i don't believe you when you claim it's possible to invent something worse than gcc spec files
<rqou>
see, gcc has specs file while clang just has hardcoded guessing
<rqou>
and now you have to recompile it to change something
<whitequark>
yeah the driver is kind of awkward
<whitequark>
there's certainly utility to something like spec files when your compiler is inherently retargetable
<whitequark>
rqou: that said
<whitequark>
can't you make a command-line wrapper?
<whitequark>
this is more or less equivalent to spec files in usability anyway
<whitequark>
like a shell script
<rqou>
idk, can i? gcc has subcomponents like cc1 that you can technically directly invoke, but clang doesn't seem to have any documentation about this
<whitequark>
clang -###
<whitequark>
shows you all the subcomponents
<whitequark>
they're all invoked through the clang binary itself
<whitequark>
clang -cc1 :P
<rqou>
i guess gcc has limped along for long enough for people to have written docs out of frustration :p
<whitequark>
clang isn't all that undocumented
<whitequark>
the driver internals aren't, sure
<rqou>
last i looked the only docs i could find were bitrotted tutorials for adding a new backend
<rqou>
and only the very basic parts, not horror stories like shared libraries or TLS
<whitequark>
um have you looked at llvm.org/docs
<whitequark>
if you want a backend, there's a very good third-party doc
<rqou>
still doesn't seem to have docs on "weird systems glue shit" like vdso/FDPIC/etc.
<rqou>
but then again nobody really does :P
<rqou>
oh, apparently on some archs atomics are a nice mess too
<whitequark>
vdso is purely a library concern
<whitequark>
atomics uuuugh yes
<whitequark>
I had to write codegen for atomicrmw using LL/SC
<whitequark>
for or1k
<whitequark>
this was awful
<whitequark>
I mostly copied it from the MIPS backend
<rqou>
iirc on some archs the compiler would insert a syscall :P
<whitequark>
yes
<whitequark>
armv5 I think?
<rqou>
yeah i think
<rqou>
maybe sh did too (but llvm doesn't support sh anyways)
<rqou>
seriously all new arch designers should just stop using ll/sc
<rqou>
use ptr-sized/double-ptr-sized cas instead
<rqou>
iirc there was some twitter rant months ago along the lines of "if you use ll/sc you will spend the next decade+ amending the list of things you can't do between the ll and sc"
<whitequark>
yes
<whitequark>
by rygorous i think
<whitequark>
but this isn't a huge problem unless you expose ll and sc as primitives
<whitequark>
llvm emits hardcoded sequences that just expand to cas
<whitequark>
ll/sc still sucks in comparison because its potentially unbounded
<sorear>
not transactional memory? :P
<whitequark>
no
<awygle>
that "add a new backend" tutorial is good, but it was of limited use in working with an _existing_ backend unfortuantely
<whitequark>
there was a paper recently that has shown that HTM has similar performance to STM
<fouric>
oh hey pie_
<whitequark>
but HTM is limited by things like cache line boundaries
<rqou>
oh yeah, what awygle said
<whitequark>
i dunno, i found it pretty easy to work with existing backends
<rqou>
somehow last i looked the x86/arm code looked _nothing_ like anything in the docs
<awygle>
i didn't have too much trouble once i stopped reading that tutorial :p
<awygle>
i suspect the msp430 backend is about 5x more code than it needs to be, most of it could probably be tablegen
<whitequark>
well yeah, x86 is a monster
<whitequark>
arm is a little monster
<awygle>
a big.LITTLE monster
<awygle>
if you will
<whitequark>
omg
<rqou>
oh i just remembered
<rqou>
unwinding and c++ glue is also nice and undocumented
<rqou>
e.g. my failed attempt to fix ppc unwinding
<whitequark>
lol unwinding
<awygle>
irc is too interesting today, i have done no real work
<whitequark>
i ported libunwind to bare metal :p
<whitequark>
and it's upstream
<rqou>
somehow the horror story in gcc/binutils usually makes this "just work"
<whitequark>
more people have used it for more decades
<rqou>
except only for or1k for some reason
<whitequark>
oh god or1k
<whitequark>
yeah, i also ported libunwind to or1k
<whitequark>
and it's upstream
<whitequark>
the only part of llvm aware of or1k
<fouric>
whitequark: what's this about illegal states?
<pie_>
fouric, hey, where else have i seen you? xD
<whitequark>
fouric: if you represent code as AST
<pie_>
fouric, probably meaning things that dont parse properly
<whitequark>
you can't violate the AST's invariants easily
<whitequark>
like unbalanced braces
<awygle>
or1k gcc upstreaming is apparently being reviewed as we speak
<whitequark>
um
<whitequark>
it's upstream for a long time
<fouric>
you can enforce multiple levels of "AST"iness though
<fouric>
take Lisp for example
<whitequark>
it's not upstream in gdb anymore
<whitequark>
because it broke
<whitequark>
i built the last supported version and it can't even show backtraces
<whitequark>
piece of shit
<whitequark>
could never figure out what's wrong
<whitequark>
gdb's code is even worse than binutils
<fouric>
you can enforce (1) each parenthesis must have a matching pair (2) each form must be a valid Lisp form or (3) the program must be correct
<fouric>
for editing, you could just turn off (3) or even (2)
<whitequark>
fouric: then it's just an automated code formatter
<fouric>
not really
<fouric>
because structure editing is fundamentally different than text editing
<whitequark>
ok, code formatter with refactoring support
<whitequark>
you can do this today in IDEA
<fouric>
the difference is in the engine
<fouric>
IDEA is still ultimately a text editor
<fouric>
you can try to monkey-patch it to behave like a structure editor
<fouric>
but it's going to require orders of magnitude more work than just buckling down and writing a real one
* jn__
read: IKEA is still ultimately a text editor
<fouric>
even if the end result is similar
<rqou>
in my experience lldb is completely unusable
<whitequark>
libclang gives you a structure editor functionality
<whitequark>
rqou: the lldb ui is... weird
<whitequark>
i think they tried to avoid the gdb mess where it's a ton of ad-hoc shit
<awygle>
IKEA is a hex editor
<fouric>
jn__: IKEA is an aesthetics editor for your home
<whitequark>
but now you have to type long ass commands
<whitequark>
i think lldb is primarily developed as a backend for xcode
<awygle>
hence all the Allen keys
<jn__>
fouric: heh :>
<fouric>
i mean, you can definitely take text editors and make them _behave_ like structure editors
<fouric>
for common files and in most cases
<fouric>
see: emacs with paredit
<fouric>
...but they're often brittle
<fouric>
and ime emacs explodes a lot more often then i'd like when i start to add in other scripts
<sorear>
what's a structure editor that's actually more usable than a text editor
<fouric>
i don't really know _of_ any structure editors
<fouric>
but only because people don't write them
<fouric>
they shouldn't be inherently more difficult than text editors
<fouric>
actually, a lot of things, like syntax highlighting, become a lot easier
<whitequark>
i don't see how
<whitequark>
unless you lose highlighting when you go to text mode
<fouric>
what text mode? it's a structure editor
<fouric>
(sorry, that came out wrong)
<fouric>
to clarify: a structure editor is a tool whose primitives are the AST nodes of a programming language, as opposed to raw text, correct?
<whitequark>
18:55 < fouric> you can enforce (1) each parenthesis must have a matching pair (2) each form must be a valid Lisp form or (3) the program must
<whitequark>
be correct
<whitequark>
18:55 < fouric> for editing, you could just turn off (3) or even (2)
<whitequark>
so if you turn off (3) and (2) you're back to highlighting like today
<fouric>
if you turn off (3) and (2), you have a tree editor, which is still completely different than a text editor
<fouric>
oh, i see
<fouric>
just re-use your highlighting results from (2) then
<fouric>
have two levels of nodes: (1) generic lists+symbols and (2) LET/DEFUN/LAMBDA etc. nodes
<sorear>
right now I'm not interested in structure editors because I'm not convinced they're actually a good idea, and I'm not convinced they're actually a good idea because I haven't seen a good implementation
<whitequark>
ah ok
<sorear>
structure editors are definitely popular as a _concept_ and _widely upheld_ as a good idea by academia, see also: HTM
<fouric>
if you need your program to briefly become invalid under constraint (2), then "serialize" all of those semantically-rich nodes to type (1), keeping syntax-highlighting information
<fouric>
then you make the edits, then "deserialize" back to (2) and check for correctness
<whitequark>
but then you don't highlight newly added text.
<whitequark>
that sucks.
<fouric>
do it incrementally!
<sorear>
(I wrote a structure editor for templates once for $work because $boss really wanted that, but obviously there was no time to *finish the job*)
<fouric>
as you're editing (let ((foo-binding 10)) ...) to (let ((foo-binding 10) (bar-binding 20)) ...), after you finish adding the symbol bar-binding you can figure out what it is even if the entire program is not correct
<fouric>
that is, you can write code to infer that even though (let ((foo-binding 10) (bar-binding)) ...) is not correct, you can still figure out that bar-binding is a new binding and color it appropriately
<awygle>
you could "hallucinate" the appropriate closing node
<fouric>
oooh, that's a _really_ good name and yes
<awygle>
marpa calls this "ruby slippers" parsing
<awygle>
which i don't like as much
<whitequark>
fouric: ok yeah that works
<fouric>
awygle: yeah but it's still going to be a heck of a lot simpler in structure form than text form
<fouric>
well
<fouric>
theoretically
<fouric>
sorear: i will write you a good structure editor and change your mind
<whitequark>
famous last words
<awygle>
... are they? lol
<awygle>
struct IWillWriteYouAGood<T> where T: <Difficult>
<fouric>
pls no templates
<awygle>
that was intended to be a rust generic but i might have fucked up the syntax, i'm still not really fluent yet
<whitequark>
T: Difficult
<fouric>
:T
<awygle>
damn, close
<awygle>
#Someday i will write a bunch of rust in a row and internalize all this
<sorear>
rust in a ROW
<fouric>
port yosys to rust
<shapr>
fouric: don't open that can of worms
<fouric>
/s
<shapr>
the worms are too large, this will be tremors part ninety seven.
<sorear>
<3
<awygle>
good movie
<awygle>
(bad bad movie)
<qu1j0t3>
book?
<qu1j0t3>
what movie
* qu1j0t3
runz
<shapr>
on the other hand, the movie "holes" was wonderful
X-Scale has joined ##openfpga
<shapr>
My "intro to FPGA dev" class at work has grown to eight student, I better learn faster, it starts in a week and ahalf.
<etrig>
should be fine as long as you're a couple hours ahead of the students
<shapr>
I hope so
<shapr>
so, I want to get a bunch of software devs into FPGA dev, I've decided on the BeagleWire, any suggested pmods or grove modules that are likely to be interesting and fun?
<pie_>
hahaha
<pie_>
good luck shapr
<prpplague>
shapr: actually i'd recommend the http://papilio.cc/ for a starting point
<awygle>
shapr: VGA is always popular, external memory interfacing is always useful
<shapr>
I was unable to search pmod on that website and find any boards, is that because digilent has the copyright on that term?
<sorear>
ah no very different
<pie_>
i would make all my engineering friends lurk here if i could
<shapr>
sorear: did I already ask if you're going to ICFP this year? I think you said no?
<awygle>
Insane Clown Functional Programming
<sorear>
no, and probably not? if it's very nearby and cheap i'd consider it
<shapr>
awygle: pretty close!
<shapr>
sorear: st louis, but not cheap
* sorear
geography fails, finds a map to check the distance between MO and MA
<shapr>
basically, I'm trying to find pmod options sold by companies other than digilent, not finding much
<shapr>
sorear: carpool with ed :-P
<sorear>
ed who?
<shapr>
kmett
<shapr>
but he's probably flying ...
<shapr>
prpplague: big advantage of the beaglewire is that the yosys toolchain can run on the beaglebone itself, so I don't have to worry about students having the tools on their own board
<shapr>
that was my reason for choosing the beaglewire, doesn't mean I'm well informed :-)
<sorear>
that would be the longest ground trip I have ever been on
<awygle>
that's a pretty long drive
<shapr>
I drove from Birmingham, AL to Seattle once, then drove back a year later (via Madison)
<shapr>
awygle: who would I ask about pmod boards?
<shapr>
I suspect that's kinda newbie stuff for the people here
<awygle>
shapr: ask in ##fpga? bml_khubbard?
<shapr>
oh, there's another channel?
<awygle>
those would be my two guesses
<sorear>
i've been on a few family trips between san diego and livermore, nothing too exciting
<awygle>
i drove from Lincoln Nebraska to Renton Washington by way of Boulder Colorado
<awygle>
that's probably the longest road trip i've ever been on
<sorear>
i have not actually managed to drive farther than several circles around a parking lot
<shapr>
I used to drive twenty hours a week, don't miss it any.
<awygle>
dang, that is Too Much
<awygle>
i used to drive 10 and that was too much
<awygle>
the NE->CO->WA trip was apparently 27 hours (over three days), which means it does edge out Slidell LA to Tucson AZ at 20 hours (which i didn't drive, but i did ride when i was younger)
<shapr>
When I was coming back from Seattle towards Madison, I drove twenty hours, only stopping for gas. Starting hallucinating, decided it was time to stop.
<openfpga-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fAcdh
<openfpga-bot>
jtaghal/master 1d994fb Andrew Zonenberg: Initial version of protobuf schema for new jtaghal network protocol
<openfpga-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fAcbd
<openfpga-bot>
jtaghal/master c383f4e Andrew Zonenberg: Fixed a few errors in the protobuf specification. Protobuf is now compiled and linked with libjtaghal, but not actually used for anything.