<kc8apf> on macOS, Scansion
<rqou> wtf, i'm only counting enough bits for 8 R4 wires in each direction?
<rqou> that's totally not enough
ym has quit [Ping timeout: 264 seconds]
ym has joined ##openfpga
unixb0y_ has joined ##openfpga
unixb0y has quit [Ping timeout: 265 seconds]
unixb0y_ is now known as unixb0y
pie_ has quit [Ping timeout: 268 seconds]
ZombieChicken has quit [Quit: Have a nice day]
pie_ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
Bike has quit [Quit: Lost terminal]
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 265 seconds]
futarisIRCcloud has joined ##openfpga
mIKEjONES has quit [Ping timeout: 240 seconds]
mIKEjONES has joined ##openfpga
<rqou> ping awygle
<awygle> ?
<rqou> did your designer friend ever get back to you re: "software for choosing palettes with colors that are sufficiently maximally different"?
<awygle> oh yeah I found a few good ones
<awygle> one sec
<awygle> language?
<rqou> preferably just a web thing
<awygle> Ah K.
<rqou> i.e. i just want colors, not anything fancy and hooked up with a "framework" or anything like that
<awygle> You want the three options linked from there
<awygle> I liked colorgorical the best
<azonenberg> awygle: colorbrewer?
<azonenberg> theres a couple of tools
<azonenberg> colorbrewer2.org
<awygle> also linked there
<azonenberg> ah ok, thats my personal favorite
<awygle> I wanted specifically to generate stuff dynamically, I ended up with a small python module, but I'm not at that pc atm
<azonenberg> ah ok yeah i dont have any tools for that
<rqou> btw azonenberg, did you see my new visualizations?
<rqou> it seems like i am only getting 8 left wires and 8 right wires per tile??
<rqou> something seems not right here
<azonenberg> no i didnt see
<rqou> i'm pretty sure i know where the interconnect->tile control bits are
<rqou> the reason i was getting really confused is that they way i've divided up the raw bytes into columns is wrong
<rqou> some of the tile control bits are in the "next" column the way i indexed them
<rqou> the problem now is that there really aren't enough bits anywhere to control 16 wires each way
<azonenberg> how sure are you that there's 16 each way?
<rqou> not very
<azonenberg> and not 8 wires that can be driven bidirectionally (but not in both directions at once)?
<azonenberg> it might be 16 logical routing channels but they're paired and each pair occupies one physical wire on the die
<rqou> that still doesn't add up to the correct total
<azonenberg> Or something
<rqou> that might be possible but not very likely?
<rqou> papers + patents + Marex's work all seem to imply that wires are unidirectional
<azonenberg> hmm
StCypher has joined ##openfpga
StCipher has quit [Ping timeout: 240 seconds]
<azonenberg> how's my swiss cheese of a power plane look so far? :p
<rqou> lol
<rqou> so non-symmetrical
<rqou> how's the house? :P :P
<azonenberg> rqou: We made progress today, bits and pieces of everything from framing the openings around the cable trays to installing the new bathroom exhaust fan and wiring it up
<rqou> still doesn't sound like you're quite ready for inspection
<azonenberg> also lots of miscelleaneous things
<azonenberg> labeling junction boxes, removing a few boxes i put in that i no longer need
<azonenberg> furring around wiring in the attic
<azonenberg> we still have a bunch of stuff on the checklist but the weekend isnt over
<azonenberg> So i'm hopeful
<rqou> are you not optimizing for "inspect asap?"
soylentyellow_ has quit [Ping timeout: 260 seconds]
<azonenberg> We are
<azonenberg> But the exhaust fan, for example, is an electrical device
<azonenberg> that needs to be wired :p
<azonenberg> As is the light fixture over the sink
<rqou> can you not add those afterwards?
<rqou> also wtf i seem to be seeing what i'm pretty sure is normally a two-hot mux with just one bit set?!
<azonenberg> No i can't
<rqou> why not?
<azonenberg> the old sink light was wired to a circuit that no longer existed
<azonenberg> So i had to run a new junction box there (the light fixture itself isn't getting hung until later)
<azonenberg> Then the junction box for the exhaust fan is part of the fan housing
<azonenberg> you run a cable fitting through a knockout on the fixture itself
<azonenberg> So i had to hang the housing, although the duct and fan/light assembly wont get installed until later
<azonenberg> in both cases some of the existing sheetrock had to get removed since the new one wasn't quite the same size as the old
<azonenberg> (and the bathroom isn't getting fully redone until later)
<azonenberg> then any time you have MC cable in an "accessible area" of an attic that runs perpendicular to a ceiling joist, you need wood furring on either side
<azonenberg> to protect it from being stepped on
<rqou> you really should have done more optimizing for "get shit done faster"
<azonenberg> The furring on the wiring is a code requirement
<azonenberg> they'd fail me at rough-in if it wasn't there
<rqou> coulda just stapled in some romex
<azonenberg> a) Romex can't go in cable tray
<azonenberg> b) romex has to be protected the same way in the attic
<azonenberg> The old stuff wasn't, of course
<azonenberg> But code requires it for new installs
<azonenberg> Also having lived in houses with rodent problems i'm not taking any chances
<azonenberg> This place had a *bird nest* in the attic
<azonenberg> And a wasp nest in the wall
<rqou> O_o
<azonenberg> There's no telling what critters might try to nom on the wires
<azonenberg> You see why i dont like romex now? :p
<azonenberg> Quality is neither cheap nor fast
<azonenberg> But yes the only type of wiring that doesn't require protection from stepping in an attic is hard conduit like EMT
<azonenberg> or possibly rigid PVC, but i dont know if that's kosher in attics for thermal reasons
<rqou> ugh, C4 control bits are totally confusing the hell out of me
<sorear> how many rodents do you have to have living in a house year-round before it's considered a rodent problem
<rqou> azonenberg: so, at this point in time, do you think the next step should be: 1) Finish up decoding the actual values of the tile input bits (not just the locations)
<rqou> 2) fix up the coordinate system for the visualization which is obviously messed up
<rqou> 3) figure out the coordinate system for wires
<rqou> 4) something else
<rqou> azonenberg: i think the best next steps will be
<rqou> 1) figure out the LAB input control bit actual values
<rqou> 2) figure out the coordinate system used for wires
<rqou> 3) fuzz IOs actually
<azonenberg> sorear: at my old apartment in troy we had no year-round residents but during the winter we'd often have one or two
<rqou> 4) fix coordinate system for visualization
<azonenberg> we'd catch one, be good for a couple weeks, then another would show up
<rqou> 5) fuzz R4/C4 controls
<rqou> what do you think?
<azonenberg> and it'd take us a while to figure out his favorite spots and catch him
<azonenberg> rqou: sounds plausible
<rqou> not too many bits left actually
<azonenberg> sorear: also things like attics are outside part of the building envelope
<azonenberg> and are thus much more susceptible to critters getting in
<rqou> azonenberg: also, based on exactly which bits are getting set in these visualizations, i can guess that the sparseness of the connectivity is in part related to the physical layout
<rqou> e.g. when a "right track" mux is set towards the bottom of a tile, the next mux tends to be towards the bottom of the "target" tile too
<rqou> i guess having wires crisscrossing everywhere isn't really good for layout :P
<azonenberg> lol
<azonenberg> yes
<rqou> azonenberg: also, right now i see a "huge gap" that (depending on how i offset stuff) exists past the ends of the io tiles
<rqou> do you think this is just wasted space?
ZombieChicken has joined ##openfpga
<azonenberg> unlikely
<azonenberg> but possible?
<rqou> why unlikely?
<cyrozap> I just went to the Silego website for the first time in a while and it redirected to Dialog Semi...
<cyrozap> Anyone know when that acquisition happened?
<rqou> months ago
<cyrozap> Oh, lol
<rqou> azonenberg: another thing that i'm having trouble figuring out: the bitstream has 3 bits every 4 bytes that don't fit into the normal pattern
<rqou> they appear constant most of the time but do occasionally change
<rqou> any ideas what might be going on?
bitd has joined ##openfpga
soylentyellow has joined ##openfpga
<rqou> i just discovered pcregrep and it's pretty cool
ZombieChicken has quit [Quit: Have a nice day]
<rqou> ok, my fuzzing technique definitely congested out a lot of routes that should exist
<rqou> tentative, do not trust: i think LAB input muxes are 4x 4-1 muxes (one-hot, sharing control bits) followed by another 4-1 mux
soylentyellow_ has joined ##openfpga
soylentyellow has quit [Ping timeout: 256 seconds]
<rqou> nope that's not right
<rqou> also something weird seems to be happening as lab->neighbor connections only cause one bit to be set
<rqou> hypothesis: the mux bits controlling LAB lines 0-4 and 13-17 are mirrored
<rqou> further new hypothesis: the mux structure is 3x 4-1 muxes (one-hot, sharing control bits) followed by another 4-1 mux, where the last input of that second mux is "some special neighbor wire"
<rqou> but right now it's too late to investigate this in detail
* rqou zzzzz
soylentyellow__ has joined ##openfpga
soylentyellow_ has quit [Ping timeout: 240 seconds]
<rqou> azonenberg: i found a die photo of max v
<rqou> in a really cool paper too
m_t has joined ##openfpga
Bike has joined ##openfpga
_whitelogger has joined ##openfpga
m_t has quit [Quit: Leaving]
<daveshah> icestorm errata from clifford (cost us a lot of debugging time): "routing" entries in the database are NOT bidrectional transistors as documentation previously suggested. Everything switch in the ice40 should be taken to be a unidirectional tristate buffer/mux from now on, at least pending further research. Online docs are being updated.
<daveshah> (arachne-pnr implemented this already. whether this was a "double bug" that turned out to be correct, or cseed found out and didn't tell anyone, is unknown)
drawkula has joined ##openfpga
tinyfpga_ is now known as tinyfpga
GenTooMan has joined ##openfpga
Miyu has joined ##openfpga
ZombieChicken has joined ##openfpga
Maya-sama has joined ##openfpga
bitd has quit [Remote host closed the connection]
hackkitten has quit [Ping timeout: 268 seconds]
StCypher has quit [Read error: Connection reset by peer]
StCypher has joined ##openfpga
<mithro> anyone here got some time to help me debug some stuff?
<rqou> azonenberg: so i finally decommissioned the giant mess of our network stack in my apartment
<rqou> it's so quiet now :P
gnufan1 has quit [Ping timeout: 256 seconds]
<rqou> whelp, pretty sure I managed to trigger a race condition in the Target self checkout machine
gnufan has joined ##openfpga
mumptai_ has quit [Remote host closed the connection]
Miyu has quit [Ping timeout: 260 seconds]
Maya-sama is now known as hackkitten
<openfpga-github> [Glasgow] whitequark closed issue #52: TI SN74LVC1T45 https://github.com/whitequark/Glasgow/issues/52
ZombieChicken has quit [Quit: Have a nice day]