kuldeep has quit [Ping timeout: 256 seconds]
kuldeep has joined ##openfpga
<whitequark> digshadow: nope.
<whitequark> you could probably do it with grep.
DocScrutinizer05 has left ##openfpga ["systemd breaking up recursion in dbus"]
<digshadow> whitequark: with some knowledge of the bitstream internals?
<digshadow> I don't remember seeing resource utilization in there, but can double check
<awygle> on further reflection it seems like you should be able to get what you want from yosys, no? at least in terms of "how many LEs are being used". it seems unlikely that icebox/icestorm could tell you any more except possibly how many resources your particular part number has.
<awygle> i guess if you only have the .asc you need to run it through icebox_vlog to feed it to yosys
<whitequark> awygle: it's kind of weird but yosys doesn't have resource utilization stats for any of the targets
<whitequark> that's reasonable to some degree because e.g. gp4par can fold LUTs into inverters and back
<digshadow> awygle: I'm not only using yosys
<digshadow> but also would be better to be sure that nothing funny happened
<awygle> whitequark: but will it tell you "i synthesized 9436 of this cell"?
<whitequark> i think it does yeah
<whitequark> but you can also just use grep for that
<awygle> that's the best you're going to get until you run arachne, i think
<whitequark> digshadow: `grep -c SB_LUT4 bitstream.asc`?
<awygle> (or gp4par or xc2par or whatever)
<whitequark> er, wait, asc
<whitequark> hang on
<mithro> tinyfpga: Why can't I click on the board images on https://tinyfpga.com/ to take me to more info on the board?
<digshadow> whitequark: it looks like I could look for all 0 sections
<whitequark> ok yeah don't know about an asc, I thought you had a blif
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
<whitequark> so I have a floorplan viewer (unreleased) that can open an asc
<digshadow> ah cool
<whitequark> I can whip up a resource utilization page for it real quick if you wanna
<whitequark> can you give me the bitstream for testing
<digshadow> hmm CLI tool would be useful
<digshadow> I'm comparing a bunch of tools
<whitequark> well I can make it CLI I guess
<mithro> digshadow: Try iceexplain ?
<awygle> this should be a really easy add to icebox
<digshadow> mithro: not familiar with that, let me look
<whitequark> yeah but I'm not motivated to do that :p
<awygle> :p fair enough
<whitequark> icebox_explain doesn't really give you resource util
<mithro> icebox_explain ?
<whitequark> oh hm
<whitequark> digshadow: nevermind
<whitequark> icebox_stat does what you want
<whitequark> icebox_stat file.asc
pie__ has joined ##openfpga
ZombieChicken has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
<digshadow> whitequark: perfect! thanks
<awygle> oh sweet
pie__ has quit [Ping timeout: 265 seconds]
<digshadow> I don't see a --version flag on any of the icebox tools. Is there a way to query from an installed instance something resembling a version?
<digshadow> also note icebox_asc2hlc.py has a --version but it actually outputs copyright info, not version info
unixb0y has quit [Ping timeout: 256 seconds]
unixb0y has joined ##openfpga
<whitequark> I don't think there is
<whitequark> icebox is kind of hacky
<mithro> digshadow: Can you get the "git describe"?
<digshadow> mithro: not from an installed instance
kuldeep has quit [Ping timeout: 268 seconds]
<tinyfpga> mithro: I’ll add a link to the pictures :)
<mithro> tinyfpga: Anywhere on that column would be nice :-P
<mithro> tinyfpga: Would be good to have a TinyFPGA B2 link somewhere too?
kuldeep has joined ##openfpga
pie_ has joined ##openfpga
<mithro> Does anyone understand what padin_1 / padin_0 is all about?
<mithro> Looks like it might have something to do with the in built oscillators?
<mithro> The <span style="font-family:monospace">CLKHF</span> output of SB_HFOSC is connected to both IPConnect tile (0, 28) output <span style="font-family:monospace">slf_op_7</span> and to the <span style="font-family:monospace">padin</span>
<mithro> icebox/icebox.py: (1, 331, 143): ("padin_glb_netwk", "3"), # (1 3) (331 144) (331 144) routing T_0_0.padin_3 <X> T_0_0.glb_netwk_3
<mithro> Looks like it can be used to connect io_X/PAD to padin_X which is an alias for a glb_network_Y ?
<awygle> mithro: each iob has 2 pads, and so can connect to 0 1 or 2 pins. Is that what you mean?
<awygle> Io tile, io cell, whatever ice calls it
<mithro> So a bunch of IO tiles can drive the global networks -- if an IO tile can drive a global network, then the fabout is connected to one global network and the GLOBAL_BUFFER_OUTPUT (direct from the PACKAGE_PIN) can drive a another specific global network
<mithro> I don't quite understand where padin_x comes in there...
<mithro> Looking at http://www.clifford.at/icestorm/bitdocs-1k/tile_0_9.html it seems like it is just an alias for the glb_netwk_X name?
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<pie_> rqou, so you figure out your dump?
<rqou> pie_: right mux index 0 kinda makes sense?
<pie_> *ahruf* :D
<pie_> .... *whsug
<pie_> wtf
<rqou> it'd be really helpful if you could figure out how the row index permutation works
<pie_> *shrug
GenTooMan has quit [Quit: Leaving]
digshadow has quit [Ping timeout: 255 seconds]
digshadow has joined ##openfpga
<rqou> azonenberg: ping?
<azonenberg> rqou: ack
<rqou> can you take some guesses as to wtf is going on with the horizontal pin permuting?
<rqou> i don't think you need too much uarch understanding for this, just good pattern-recognition skills
<rqou> alternately, any thoughts as to what should be analyzed next?
genii has quit [Remote host closed the connection]
<rqou> hmm, so far there is very limited connectivity between differently-numbered wires
_whitelogger has joined ##openfpga
unixb0y has quit [Ping timeout: 260 seconds]
unixb0y has joined ##openfpga
pie_ has quit [Read error: Connection reset by peer]
<daveshah> mithro: still around?
<mithro> daveshah: ha
<mithro> daveshah: I was just about to ping you
<mithro> daveshah: Do you know anything about the blockrams in the 8k?
<daveshah> Vaguely
<daveshah> The main thing is that various signals swap tiles
<daveshah> I think LSB/MSB and read/write address/clock swap round
<daveshah> But you can check by seeing exactly which signals are in the database for each tile
<mithro> daveshah: "The cell ports are spread out over the two tiles as follows:" is wrong? It's dependent on which RAMB/RAMT column?
<mithro> daveshah: That is what I'm discovering
<daveshah> No, its dependent on 1k/8k
<daveshah> As above
<mithro> DEBUG:root:On PI( 8,13) skipping entry [!B4[0],B4[1],!B5[0],B5[1] buffer local_g0_2 ram/RCLKE]: dst missing PV(10,15):local_g0_2 (local_g0_2) node X010Y015<|07|>X010Y015 => *PV(10,15):ram/RCLKE* (ram/RCLKE) node None
<mithro> daveshah: Hrm? You mean the 8k and 1k have different ordering?
<daveshah> Yes
<daveshah> The RAMs are quite different between the two. The config bits change meaning too
<mithro> daveshah: So that page should really say "In the 1k, the cell ports are spread out over the two tiles as follows:" ....
<daveshah> I think all wires swap between the two tiles from 1k to 8k
<daveshah> Yes
<daveshah> Everything subsequent, like the 5k, is the same as the 8k
<daveshah> BTW the padin signals are the connections from the pad just before the global network itself
<daveshah> The connection from them to the global network is enabled by an extra config bit
<daveshah> By default fabout is routed to the global network
<mithro> daveshah: Is there a way in icebox to look up a ram tile signal name (IE ram/RADDR_0 ram/RE) and find out if that is in a RAMB or RAMT tile?
<daveshah> mithro: probably, but I think you can just say that they all swap over going from 1k to 8k
<daveshah> I think that will be easier in fact
<whitequark> mithro: what are you doing btw?
<mithro> whitequark: Getting ice40 into vpr
<mithro> whitequark: For timing driven PnR -- blinky is working on the 1k + icestick
<mithro> Most of my time is being spent finding issues in the ice40 documentation :-P
<mithro> daveshah: So GLOBAL_BUFFER_OUTPUT is actually connected/disconnected to padin_X which is shorted to a global network?
<daveshah> Yes, so long as the padin_pio config bit is set
<daveshah> Otherwise the SB_GB driven from fabout is connected to the global network
<rqou> hey whitequark are you good at puzzles/patterns?
<mithro> daveshah: so you can't drive both the fabout and padin_X global networks at the same time?
<whitequark> rqou: no i hate them
<daveshah> mithro: No, of course not - that would be a short circuit
<rqou> lol nvm
<daveshah> But you can use both padin and fabout at the same location, because they drive different networks
<whitequark> mithro: please document all the issues somewhere
<whitequark> in any way
<mithro> daveshah: Not sure what you mean by "<daveshah> mithro: No, of course not - that would be a short circuit"?
<daveshah> mithro: two drivers for the same net is clearly a short circuit
<mithro> daveshah: but the fabout and padin_X are driving different networks?
<daveshah> whitequark: docs have been updated for the biggest problem found (actually we found it during $thing_on_cliffords_twitter)
<daveshah> The routing muxes actually be unidirectional
<daveshah> mithro: yes, you can use fabout and padin at the same location
<daveshah> So long as each glb_netwk only has one driver
<whitequark> mithro: btw any interest in ice40 floorplan viewer?
ZombieChicken has quit [Quit: Have a nice day]
<whitequark> I wrote one with Qt, it works way better than this other thing in html
<mithro> whitequark: Oh?
<rqou> but now you have to deal with qt
<daveshah> whitequark: we are working on something like that too, more information at the end of the month
<whitequark> daveshah: shit
<daveshah> Coincidentally also using Qt+OpenGL
<whitequark> why the fuck is this secrecy happening?
<daveshah> But it is not designed to take a bitstream in, so it's not quite the same
<rqou> yeah, this is what happens when symbiflow claims to be doing foss
<whitequark> "more info wherever" more info now
<whitequark> or this isn't open-source
<daveshah> Go and pester clifford, not my decision
<rqou> symbiflow is doing foss, corporate/academic edition
<rqou> so no, not foss
<whitequark> anyway go build and play with this https://github.com/whitequark/icefloorplan
<rqou> needs a makefile?
<daveshah> Some of it is open source...
<rqou> twitter teasing is not foss either
<whitequark> rqou: qmake .; make
<rqou> lesson: don't have your project be sponsored by $BIG_COMPANY
<daveshah> Tbh that's not really why it's not open source yet
<whitequark> looks something like that anyway https://imgur.com/a/k42gioa
<whitequark> there's no routing pushed yet because i still don't have a non-ugly rendering for it, but i think i know how to do it, finally
<daveshah> whitequark: looks awesome (much better than what we have right now)
<whitequark> daveshah: join forces?
<rqou> whitequark: missing a -std=c++11 somewhere
<rqou> getting errors about std::function
<whitequark> rqou: starts with CONFIG += c++11
<whitequark> are you building with qt4 or qt5?
<rqou> g++ -c -m64 -pipe -O2 -Wall -W -D_REENTRANT -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -o main.o main.cpp
<whitequark> oh
<mithro> rqou: says mister <redacted>
<whitequark> i'm not sure if it even works with qt4, try qt5-qmake
<rqou> <redacted> is not related to the open-source FPGA efforts
<mithro> whitequark: what is that displaying?
<whitequark> mithro: one logic slice on an ice40-384 fpga
<whitequark> i correctly decode everything on logic tiles other than local tracks and span wires
<whitequark> for luts i infer the function from the lut bits
<mithro> whitequark: I mean, C+D is describing a LUT?
<whitequark> mithro: yes
<whitequark> there's another mode that displays LUT as raw bits or a different way to render logic function
<mithro> whitequark: So A/B on those LUTs are unused?
<whitequark> yes
<rqou> whitequark: which -dev packages do i need to install?
<whitequark> rqou: ugh let me just write a README
<whitequark> rqou: ok nope it doesn't work with qt 4
<rqou> mithro: anyways, project chibi has nothing redacted
<rqou> the redacted projects are not open fpga projects
<rqou> whitequark: so i installed qt5-qmake
<rqou> it installs a binary x86_64-linux-gnu-qmake
<rqou> when i run it the -std=c++11 is passed
<rqou> and then it complains that there's no QApplication include
<rqou> so i need a -dev package of some kind?
<daveshah> rqou: nothing has ever been redacted in Trellis either, I agree with that on a personal level
<daveshah> Just there are other constraints, just sorting out things like copyright and stuff properly, for bigger projects
<daveshah> I promise there's nothing more sinister than that going on anywhere in SymbiFlow
<rqou> that's not what i've been hearing
<whitequark> rqou: done
<rqou> oh wtf it doesn't start with lib
<rqou> no wonder i couldn't find it
<rqou> huh, why didn't i have this installed before, that's interesting
<openfpga-github> [icefloorplan] whitequark pushed 1 new commit to master: https://github.com/whitequark/icefloorplan/commit/0dc1e7a0c1cd63e87bd224614286eadecffb503a
<openfpga-github> icefloorplan/master 0dc1e7a whitequark: Fix dead links in README.
<rqou> ok, now it's building
<rqou> shoulda made it a web thing
<whitequark> rqou: qt5 compiles to wasm
<whitequark> so i -could- make it a web thing
<rqou> O_o it does?
<whitequark> yeah
<rqou> with accelerated rendering?
<whitequark> duh
<whitequark> how else
<rqou> there was a very very early qt emscripten demo that was slow as shit
<whitequark> it's even "only" 4M
<whitequark> qt5 doesn't render without gl
<whitequark> well
<whitequark> the entire stack uses gl
<whitequark> specific widgets not necessarily
<whitequark> fun fact: i actually render the floorplan -without- gl specifically, because antialiasing in gl is shit
<rqou> um, how do i do anything? :P
<whitequark> qt optimizes the hell out of software rasterization so it's pretty much just as fast
<whitequark> see README
<rqou> right, the demo that still gets linked was qt4 i think?
<whitequark> qt4 is so 2010s
<rqou> anyways, it was a giant hack compiled with a very early emscripten
<whitequark> er, 2000s
<rqou> meh, works
<rqou> wtf "use gl mode" looks way worse than normal
<whitequark> exactly
<whitequark> try opening more complex bitstreams
bitd has joined ##openfpga
<whitequark> also hover nets
<rqou> yeah i'm opening my saturn cdb dumper hack thing
<whitequark> it may not have routing but it associates symbols with nets already :p
<rqou> wow this is really really good
<rqou> can you make me one for max v when project chibi is done?
<whitequark> sure why not
<rqou> er, ram/io aren't shown are they?
<whitequark> i didn't do ram/io drawing code yet
<rqou> yeah ok
<whitequark> spent like three weeks so depressed i was pretty much catatonic
<whitequark> tends to prevent software development
<rqou> oh :(
<whitequark> well, fortunately mirtazapine seems to work pretty well
<rqou> hope you feel better now
<whitequark> about as well as clomipramine but i can actually stand up without fainting and walk more than three meters in a line
<rqou> oh final note, i have to use x86_64-linux-gnu-qmake rather than qmake
<rqou> qmake is still the qt4 version
<rqou> maybe i need to mess around with debian alternatives?
<whitequark> debian whatever has qt5 qmake as qmake
<whitequark> buster?
<whitequark> testing.
<rqou> um, i'm on a somewhat-outdated sid
<rqou> maybe that's the issue
<rqou> did they flip it recently?
<whitequark> not a clue
<whitequark> debian does weird shit constantly
<rqou> i know right?
<whitequark> i trust they usually have a good reason but god damn it
<whitequark> how hard can it be to put some linux binaries in tarballs
<whitequark> (narrator: hardest problem in computing)
<rqou> well, i'm still on a slightly franken-debian because some newer packages broke things and i haven't had time to fix them
<openfpga-github> [icefloorplan] mithro opened pull request #2: Add include for std::functional (master...master) https://github.com/whitequark/icefloorplan/pull/2
<q3k> whitequark | fun fact: i actually render the floorplan -without- gl specifically, because antialiasing in gl is shit
<q3k> what do you mean?
<q3k> you MSAA and it works? (tm)
<rqou> i should probably deal with the problems soon since apparently debian is nearing a release or something?
<q3k> or do you mean GL_LINES?
<q3k> (fuck GL_LINES)
<rqou> and the version skew is probably not good
<openfpga-github> [icefloorplan] whitequark closed pull request #2: Add include for std::functional (master...master) https://github.com/whitequark/icefloorplan/pull/2
<mithro> whitequark: How do I zoom?
<whitequark> q3k: whatever qt does when rendering to gl doesn't look nice
<q3k> whitequark: hum
<whitequark> mithro: see README
<q3k> whitequark: works for me, literally
<q3k> wrote Qt5 GL code... yesterday
<whitequark> seriously, does anyone read that shit
<q3k> looks fine on all the graphics cards I've tested
<whitequark> whom did i write it for lol
<rqou> the "Ctrl" part isn't emphasized enough
<whitequark> q3k: can you clone and take a look at what i'm doing wrong
<rqou> it doesn't behave like any "cad/eda/graphics" tool i've ever used
<whitequark> rqou: without Ctrl it interacts badly with touchpads that have horz/vert scroll
<rqou> how so?
<rqou> ooh you mean touchpads that still use oldschool "edge" scrolling?
<rqou> rather than two-finger?
<whitequark> rqou: nope
<whitequark> i have two-finger 2d scrolling
<mithro> whitequark: What does the "compact logic notation" mean?
<rqou> hmm, never had problems with that, but whatever
<whitequark> mithro: try it
<rqou> can you make it an option?
<rqou> also, can i get middle-mouse-button panning?
<mithro> whitequark: Yes, I don't understand why its "=1"?
<whitequark> mithro: "exactly one bit is 1"
<whitequark> ie xor
<whitequark> ">=1" is or
<whitequark> rqou: patches welcome? :p
<whitequark> i don't really have a middle mouse button here
* mithro wants +/- keys for zooming :-)
<daveshah> mithro: I think is is basically the IEEE standard?
<whitequark> yeah ^
<rqou> wait there's an ieee standard for how to write logic equations?
<daveshah> rqou: surely you did it at uni?
<rqou> nope
<daveshah> Classic first year EE, at least in the UK
<daveshah> Symbols, not equations
<rqou> just ad-hoc DNF
<whitequark> mithro: wish granted
<rqou> ooh _those_ symbols
<openfpga-github> [icefloorplan] whitequark pushed 1 new commit to master: https://github.com/whitequark/icefloorplan/commit/99eac4c456503f6b59d7b4f30a44d492665512af
<openfpga-github> icefloorplan/master 99eac4c whitequark: Bind zoom on +/- buttons.
* rqou just checked wikipedia
<rqou> yeah, we just used the "distinctive shape" forms
<daveshah> We did mostly too, but also the IEEE ones
<rqou> i don't think i've ever seen anybody use the IEEE ones
<daveshah> We also spent quite some time discussing how the use the IEEE standard to build symbols for more complex gates
<rqou> we never did that
<daveshah> Very useful to the bulk of students going on to work in companies building systems out of assorted 74-series MSI logic :P
<whitequark> i thought about doing distinctive shapes but decided i'm lazy
<whitequark> and they aren't very useful for 4-luts anyway
<rqou> yeah true
<daveshah> Yeah, most of the time post synthesis stuff ends up being some weird function or other
<daveshah> Being able to detect full adders, in combination with carry logic, would be neat
<rqou> oh, you mean "what azonenberg was asked to research before ioa put him on projects that actually earn money"
<rqou> aka "clifford can't make extract_fa work"
<rqou> although i can't really complain because i couldn't find the bug either
<whitequark> daveshah: I detect full adders
<whitequark> in icefloorplan
<daveshah> whitequark: oh, even more awesome
<whitequark> it says ∑ for those
<whitequark> there's only really one encoding for a full adder with the ice40 layout so it was easy
<whitequark> you know the really funny thing?
<whitequark> that other floorplan viewer did logic function recognition by building a 65536 element map
<whitequark> bruteforcing it basically
<whitequark> i... wrote a oneline condition for every function
<whitequark> i spent longer second-guessing whether i'm missing something than writing it
<rqou> hmm, i think azonenberg's RE project can be improved by doing some early passes _before_ untechmapping
<whitequark> rqou: no but seriously, can you just implement that so i don't have to find a mouse
<rqou> i've never worked with qt
<rqou> currently doing something else
<whitequark> oh
<whitequark> alright then i'll uhh. let's see
<whitequark> rqou: i copied the top answer from stackoverflow :P
<openfpga-github> [icefloorplan] whitequark pushed 1 new commit to master: https://github.com/whitequark/icefloorplan/commit/8e71c226424b91074278f00b0cadef5c21e977db
<openfpga-github> icefloorplan/master 8e71c22 whitequark: Allow panning with middle mouse button....
<rqou> nice, works
<whitequark> pester me if you want routing badly
<whitequark> i got myself nerdsniped by Coq, kinda
<rqou> ugh the max v interconnect is full of strange not-quite-identical patterns
<rqou> i should just decap one
<daveshah> whitequark: icefloorplan built with no trouble on Arch and works well for a picosoc test even without OpenGL. But I do notice occasionally zooming out too far causes it to flip
<whitequark> daveshah: flip?
<whitequark> lol wtf
<whitequark> literally flip
<whitequark> i'll uh... fix that
_whitelogger has joined ##openfpga
<mithro> How did it get 2:47 am!?
_whitelogger has joined ##openfpga
ZipCPU|ztop has quit [Ping timeout: 265 seconds]
unixb0y has quit [Ping timeout: 248 seconds]
unixb0y has joined ##openfpga
clifford has joined ##openfpga
clifford has quit [Client Quit]
clifford has joined ##openfpga
clifford has quit [Client Quit]
Miyu has joined ##openfpga
<awygle> ctrl+scroll is the most intuitive binding for zoom, fite me
<qu1j0t3> sure, at a pinch
<cr1901_modern> I too prefer ctrl+scroll for zoom. shift-scroll for horizontal pan. scroll for vertical pan. Like inkscape does it
<cr1901_modern> (pinch? of course you wouldn't use inkscape on a touchscreen :)...)
lain has quit [Ping timeout: 268 seconds]
<awygle> I like click and drag panning. But I prefer right click or control click rather than middle mouse like kicad
<Ultrasauce> my colleague has one of those mice with no detentes in the scroll wheel
<Ultrasauce> zooming can get kind of scary
<qu1j0t3> i have an Apple mouse with the little rubber nipple, i.e. it never works properly for scrolling
<awygle> Altium does this thing where if you hold middle click it freezes the cursor in place and then zooms in when you move the mouse up and out when you move down
<awygle> It's extremely weird but I definitely find myself using it
lain has joined ##openfpga
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!]
pb_ has joined ##openfpga
<pb_> rqou: surprise-surprise, quartus names are related to interconnect permutations.
<pb_> you may want to look for patterns with them. also, it maybe time to look at name mapping for bigger chips.
pb_ has quit [Quit: leaving]
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
eduardo__ has quit [Quit: Ex-Chat]
<rqou> oh wtf
<rqou> i'm still missing LE->fabric connections
<rqou> the bottommost one goes into the row below, but the topmost one also goes into the row above
Miyu has quit [Ping timeout: 240 seconds]
bitd has quit [Quit: Leaving]
ZombieChicken has joined ##openfpga
<awygle> daveshah: ping?
<daveshah> awygle: pong (but midnight now and I'm tired, only around for a few more mins)
* awygle sort of regrets missing the "u up" joke
<awygle> daveshah: on the ice40 UP, do you know whether CDONE can be configured as a user I/O?
<daveshah> awygle: only in the wlscp30 package
<awygle> specifically in the QFN - it's pretty clear that the WLCSP can do so
<awygle> awesome, thanks
<daveshah> No, no evidence that its possible in the QFN
<daveshah> I think in the WLCSP they just connect one of the IO not used in that package to the same pad
<awygle> yep
<awygle> is CDONE open drain? or push pull?
<daveshah> Open drain
<daveshah> Low during config, then floating
<awygle> sweet. thanks again, sleep well etc
<daveshah> Thanks, good luck with the Glasgow work
* oeuf floats
oeuf is now known as egg|zzz|egg
<awygle> thanks
<awygle> ugh why don't vendors publish footprints. why is that so hard.
<rqou> lol
<rqou> you know, i do occasionally think about how it's amazing any engineering every can get done
<awygle> yeah the more i learn about engineering the more i'm of two minds
<awygle> one is "we took sand and made the internet, that's fucking amazing"
<awygle> the other is "i'm terrified of cars and bridges and elevators now"
<rqou> at least supposedly civil infrastructure was built with much more serious/for-realz design practices
<rqou> and not the internet's "worse is better"
<awygle> that's what i hear
<awygle> but i literally can't imagine what that looks like
<qu1j0t3> i am increasingly concerned that this stuff doesn't survive generational transfer.
<qu1j0t3> we keep having to pull people out of retirement to figure stuff out.
<qu1j0t3> that has a time limit.
<awygle> i'm not totally sure what you're referring to
<qu1j0t3> just a bunch of things been observing in recent years
<qu1j0t3> incl ageism
X-Scale has joined ##openfpga
<rqou> hrm, the column ios really are worse than the row ios in a lot of ways
<rqou> there's no path from lab outputs to the column io local interconnect
<rqou> just the hacked-on fast path
<rqou> afaik there's no fast input either
<rqou> the left and right ios are also not identical?!