ZipCPU|Laptop has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
digshadow has joined ##openfpga
gnufan has joined ##openfpga
gnufan1 has quit [Ping timeout: 248 seconds]
<pie_> qu1j0t3, cute
<qu1j0t3> [RISC-V LowFive board]
<pie_> i never really had a reason to jump on the riscv bandwagon except opensource!one~one:D~!!!@
<pie_> do i want one?
ZipCPU|Laptop has quit [Ping timeout: 240 seconds]
<rqou> oh yeah, whitequark: is your US visit that you mentioned last week or so happening?
enriq has joined ##openfpga
<whitequark> rqou: I think so, slightly later than planned though
gnufan1 has joined ##openfpga
gnufan has quit [Ping timeout: 248 seconds]
soylentyellow has joined ##openfpga
ZipCPU|Laptop has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<azonenberg> whitequark: any updates on expected dates yet?
<whitequark> azonenberg: I have a complicated chain of dependencies that have to be met for this trip to work out
<whitequark> I don't even have tickets booked yet
<rqou> lolwat
* azonenberg imagines whitequark doing topological sorting on a whiteboard
<rqou> gantt charts :P
<whitequark> azonenberg: you have no idea.
soylentyellow has quit [Read error: Connection reset by peer]
<whitequark> azonenberg: the thing is i'm batching like five or six visits into a single chunk of flight, and i tend to promise to bring things that aren't easily obtainable by people i visit
<whitequark> and those things often require something else to make them
<whitequark> so like I'll bring an ACR kit with me among others
Hootch has joined ##openfpga
<azonenberg> ACR?
<azonenberg> american chemical reagent? :p
<whitequark> air conditioning/refrigeration
<whitequark> someone wants me to teach building vapor compression cycle systems to them
<whitequark> i was like, "sure"
* azonenberg doesn't think you can get a few gallons of R-134A through airport security
<azonenberg> Or do you just mean tools?
<whitequark> tools
<whitequark> also a few gallons? 200g is enough for a system that can do like 2kW at RT evap
<azonenberg> well i assumed if you were doing instruction / prototyping there'd be leaks
<azonenberg> also, out of curiosity, have you ever tried building an air cycle system?
<azonenberg> Like airliner HVAC packs
<whitequark> still, GALLONS?
<whitequark> leaks that large means you have liquid refrigerant spewing from a massive hole in the tubing
<azonenberg> Lol
<azonenberg> not that it'd be practical to do at ground level if you didn't have a turbine or something to provide all the compressed air
<whitequark> and a really shitty job in general
<azonenberg> But still, could be fun to do as a demo
<whitequark> air cycle, no
<whitequark> but uh
<whitequark> sec
<whitequark> google "vortex tube"
<azonenberg> ooh cool
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
soylentyellow has joined ##openfpga
massi has joined ##openfpga
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
<rqou> aargh i have two homework problems where i _know_ why they are true, but i can't figure out how to properly write a proof
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
enriq_ has joined ##openfpga
enriq_ has quit [Ping timeout: 240 seconds]
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
m_t has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
gnufan has joined ##openfpga
gnufan1 has quit [Ping timeout: 248 seconds]
enriq_ has joined ##openfpga
enriq_ has quit [Ping timeout: 240 seconds]
teepee has quit [Ping timeout: 240 seconds]
sn00n has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
enriq has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
m_t has quit [Quit: Leaving]
fpgacraft2_ has joined ##openfpga
fpgacraft2 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft2_ is now known as fpgacraft2
kuldeep has quit [Ping timeout: 246 seconds]
kuldeep has joined ##openfpga
Morn_ has quit [Ping timeout: 260 seconds]
Morn_ has joined ##openfpga
massi has quit [Remote host closed the connection]
digshadow has quit [Quit: Leaving.]
soylentyellow has quit [Ping timeout: 240 seconds]
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pointfree> By the way is that openfpga planning-session/taskforce at azonenberg's place happening today or sometime in the future? It's a great idea, and I wish I could have gone, but I just couldn't get up to Seattle :(
<pointfree> I wouldn't want have been entrusted to drive rqou's car. I do have driver's license from the Commonwealth of Massachusetts in my wallet but I haven't used it in several years.
<azonenberg> I didnt think we had ever set a date
<azonenberg> i mean if folks show up i'll do it... :P
<azonenberg> It will definitely happen, but ideally i want to try to get a lot of folks in the same place
<azonenberg> We'll see what whitequark's availability looks like
<azonenberg> and rqou's class schedule
<azonenberg> i think the rest of us are pretty open
enriq has joined ##openfpga
<azonenberg_work> ooook so
<pointfree> It would also be great to meet cyrozap in person, but he's in Texas somewhere and I don't know how often he goes through Seattle or the Bay Area.
<azonenberg_work> i think my code would be massively simpler if extract_reduce had an option to replicate gates that had other loads
<azonenberg_work> rqou: https://i.imgur.com/GdBtlM2.png
<azonenberg_work> $670, 671
<azonenberg_work> (and B of 670 is driven by another off-screen AND gate)
<azonenberg_work> should all become a $reduce_and
<azonenberg_work> Even though they have other loads, so we can't get rid of the original gates
<azonenberg_work> We can maybe make this a configurable option as you might not always want it
<azonenberg_work> Detecting digital comparators is waaay easier this way
<azonenberg_work> in particular $eq(foo, 'hbar) can be detected as $reduce_and(foo[0], !foo[1], !foo[2]...)
<azonenberg_work> and this should work regardless of whether foo has any other loads on it that might, say, check for foo[0] & !foo[1]
digshadow has joined ##openfpga
soylentyellow has joined ##openfpga
<openfpga-github> [yosys] azonenberg pushed 1 new commit to master: https://git.io/v579N
<openfpga-github> yosys/master fd068c9 Andrew Zonenberg: Initial skeleton code for detection of TFF counters with odd cycle length. Fixed bug where counters without reset would crash.
<openfpga-github> [yosys] azonenberg pushed 1 new commit to master: https://git.io/v57HO
<openfpga-github> yosys/master e38e165 Andrew Zonenberg: Fixed another crash in recover_tff_counters
<azonenberg_work> rqou: My plan is to make it so extract_reduce does not delete the consumed cells
eduardo__ has quit [Ping timeout: 248 seconds]
<azonenberg_work> only the last cell in the chain
eduardo__ has joined ##openfpga
<azonenberg_work> then run "opt"
<azonenberg_work> opt_clean*
<azonenberg_work> that way, if they have other loads they will stay but get deleted if not
<azonenberg_work> Then amend the matching logic to allow cells that have multiple loads
<openfpga-github> [yosys] azonenberg pushed 1 new commit to master: https://git.io/v575I
<openfpga-github> yosys/master e2584bc Andrew Zonenberg: extract_reduce now only removes the head of the chain, relying on "clean" to delete upstream cells. Added "-allow-off-chain" flag, but it's currently ignored.
<rqou> azonenberg_work: so wait, you're trying to create reduce cells that continue past single cells that fan out to multiple nets?
<rqou> i don't think that's as simple as how you propose to do it
<rqou> i think you need to create a new reduce cell for every original cell that has multiple fanouts
soylentyellow has quit [Ping timeout: 260 seconds]
sunxi_fan1 has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 248 seconds]
pie__ has quit [Ping timeout: 240 seconds]
<rqou> oh yeah azonenberg_work when are you leaving?
pie_ has joined ##openfpga
<azonenberg_work> rqou: i'll play a bit and see
<azonenberg_work> i leave sunday afternoon
<rqou> ok, much later than i thought
<rqou> anyways, i thought about it a bit, and i think there is a very unelegant solution:
<azonenberg_work> oh?
<rqou> apply your modified reduce algorithm repeatedly until convergence
<rqou> :P
<azonenberg_work> Lol
<azonenberg_work> That could work
<rqou> yeah
<rqou> but clifford will probably yell at me :P
<rqou> especially since it needlessly converts an O(n) algorithm to an O(n^2) algorithm
<azonenberg_work> Lol
<azonenberg_work> Well i'm going to see what happens with a single iteration
<rqou> here in ##openfpga, algorithms are optimized for minimal brainpower and LOC, not the usual figures of merit of time/memory :P :P
m_t has joined ##openfpga
clifford has joined ##openfpga
sunxi_fan1 has quit [Ping timeout: 246 seconds]
<azonenberg_work> ok so, test case: https://i.imgur.com/3teEO5R.png
<azonenberg_work> Right now, it fails to find any reductions whatsoever
<rqou> hmm
<rqou> that should definitely work
<rqou> maybe it's a different problem
<azonenberg_work> I'm working on it
<azonenberg_work> i have it finding the first stage 4:1s
<azonenberg_work> but i want it to find the 8:1 too
<pie_> azonenberg_work, i was wondering if this would be good for silicon RE education but it says tsmc 180nm process http://www.cpushack.com/2017/06/05/sifive-fe310-setting-the-risc-free/ is that bad?
<azonenberg_work> pie_: 180 nm is a little small for reading optically, but it's totally doable with even a baseline SEM
<azonenberg_work> https://siliconpr0n.org/archive/doku.php?id=azonenberg:microchip:pic32mx340f512h
<azonenberg_work> this is an example of TSMC 180
<azonenberg_work> If you're looking to practice on a modern standard cell chip but don't have SEM access I suggest 350 nm
<azonenberg_work> for example, most of the older 8-bit PICs
<azonenberg_work> any of the non-XLP PIC10/PIC12/PIC16 should be MCHP 350nm
<azonenberg_work> the PIC10F200 is pretty small and i was planning to use it as a testbed for automated RE once i make a machine vision front end for my tools
<pie_> azonenberg_work, i mean i was guessing theres some form of the original data to compare to in this case
<azonenberg_work> http://siliconpr0n.org/archive/doku.php?id=azonenberg:microchip:pic10f200
<azonenberg_work> http://siliconpr0n.org/archive/doku.php?id=azonenberg:microchip:pic12f683 this di is significantly bigger, but i have way better imagery of it
<azonenberg_work> die*
<azonenberg_work> http://siliconpr0n.org/archive/lib/exe/fetch.php?cache=&media=azonenberg:microchip:pic12f683_poly_04_bf_neo40x_annotated.jpg
<azonenberg_work> http://siliconpr0n.org/archive/lib/exe/fetch.php?cache=&media=azonenberg:microchip:pic12f683_poly_02_bf_neo40x_annotated.jpg
<azonenberg_work> Given images like this of the upper layers you could, given time, RE the whole chip
<pie_> the riscv ecosystem isnt as simple as i thought
<shapr> tell me more
kuldeep has quit [Quit: Its never too late!]
kuldeep has joined ##openfpga
<pie_> huh this is a prety short datasheet... https://static.dev.sifive.com/SiFive-E310-G000-manual-v1.0.3.pdf
soylentyellow has joined ##openfpga
<openfpga-github> [yosys] azonenberg pushed 1 new commit to master: https://git.io/v5536
<openfpga-github> yosys/master 686c37d Andrew Zonenberg: Implemented off-chain support for extract_reduce
<openfpga-github> [yosys] azonenberg created extract-reduce-tweaks (+4 new commits): https://git.io/v553P
<openfpga-github> yosys/extract-reduce-tweaks 76c11d7 Clifford Wolf: Update ABC to hg rev cd6984ee82d4
<openfpga-github> yosys/extract-reduce-tweaks 5c4ea13 Clifford Wolf: Merge branch 'master' of github.com:cliffordwolf/yosys
<openfpga-github> yosys/extract-reduce-tweaks 3404934 Andrew Zonenberg: extract_reduce now only removes the head of the chain, relying on "clean" to delete upstream cells. Added "-allow-off-chain" flag, but it's currently ignored.
<openfpga-github> [yosys] azonenberg pushed 1 new commit to master: https://git.io/v5537
<openfpga-github> yosys/master f788b0d Andrew Zonenberg: Merge https://github.com/cliffordwolf/yosys
* azonenberg_work shudders at the thought of the impending rebase when he gets back from his trip
<azonenberg_work> going to be fuuuun
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
soylentyellow has quit [Ping timeout: 240 seconds]
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
soylentyellow has joined ##openfpga
m_t has quit [Quit: Leaving]
<DocScrutinizer05> azonenberg_work: would you know if there's any bypass to the SLG46533 "writing I2C-addr (reg:<1867:1864>) via I2C is invalid" issue? I'd like to use multiple (well, 2) unprogrammed 46533 on same I2C bus, hoped for a "runtime" addr assignment via daisychaining
<azonenberg_work> No experience with GP5 I2C, sorry
<azonenberg_work> My guess is, it wont work
<rqou> oh yeah, when are we getting gp5 support? :P
<azonenberg_work> any reason you cant have two buses?
<rqou> and xc2 support? :P :P
<azonenberg_work> XC2 - thats mostly on you, lol
<DocScrutinizer05> ugh, GP5, thought it was 4
<azonenberg_work> GP5 - i want to finish GP4 first
<azonenberg_work> And i cant do THAT until i get this con out of the way
<azonenberg_work> i'll be focusing on RE until next week
<azonenberg_work> then shifting gears more towards forward again
<rqou> now when are we getting s3a/s6/a7/vu+ support? :P :P :P
<rqou> how many lawsuits/C&Ds will vu+ trigger?
<DocScrutinizer05> azonenberg_work: http://susepaste.org/70012407
<awygle> rqou: you're a terrible person :-P
<rqou> we already knew that :P
<DocScrutinizer05> this suuuucks, need to preprogram the 46533 _just_ for the dang I2C addr
<DocScrutinizer05> means I need to either buy a bazillion programmed chips or program them manually myself
<azonenberg_work> Welp
* azonenberg_work feels DocScrutinizer05 scrutinizing him
<DocScrutinizer05> nah
<DocScrutinizer05> :-)
<azonenberg_work> Even though i have a PhD? :p
<azonenberg_work> Or is it only MDs you scrutinize
<DocScrutinizer05> O scrutinice doc...uments
<DocScrutinizer05> I scrutinize*
<rqou> oh btw azonenberg_work: any last-minute stuff you want me to do now that i'm not working on problem sets?
* DocScrutinizer05 needs to check what's the recent policy of silego regarding pre-programmed chips
<rqou> just get an intern to load chips into a zif socket and click program :P
<rqou> azonenberg_work: once you've programmed some of the bits in the OTP for gp4, can you still set additional bits?
<DocScrutinizer05> yes
<DocScrutinizer05> at least on GP5
<DocScrutinizer05> err 46533
<azonenberg_work> I have not tested
<DocScrutinizer05> asked that when I last time looked into this issue
<rqou> what are you using GP5 for?
<DocScrutinizer05> silego *could* program one reel of SLG46533 to a new address and sell them without other issues, particularly all 0 bits would still be programmable to 1
<DocScrutinizer05> rqou: me?
<rqou> yeah
<rqou> huh, i thought all of these open phone projects had died
<DocScrutinizer05> no issue for the 10 prototypes we're building right now. But for production it possibly sucks depending on the minimum chip count Silego offers with preprogramming
<rqou> again, just make it intern-powered :P
<DocScrutinizer05> hmm?
<rqou> get a human to manually program chips
<DocScrutinizer05> that human would be me, untaping, programming, and retaping a 1000 chips
<DocScrutinizer05> or 2000
<DocScrutinizer05> need 4 variants a 500, ok 500 of them need no programming at all
<DocScrutinizer05> actually in final design we only need 3 46533, so only 2 * NNN to program
<rqou> bribe more humans with beer? :P
<rqou> (note that this approach does not scale)
<DocScrutinizer05> definitely doesn't
<DocScrutinizer05> plus I have no idea how to retape those critters after programming
<rqou> ooh right i forgot you need to do that
<DocScrutinizer05> fab will kill me when I semd them 2 jelly glasses with 500 SLG46533 in each
<rqou> digikey calls this "bulk" packaging :P
<DocScrutinizer05> LOL
<DocScrutinizer05> SLG46533V (programmed) Min: 3000 Fs.k me!
<DocScrutinizer05> buying 3000 when I need 600
<DocScrutinizer05> 2 times
<DocScrutinizer05> in the end I got ~5k chips for the trash bin
<rqou> maybe you can ask them for something special?
<rqou> because in total you really do need several thousand
<DocScrutinizer05> not really several, maybe 2k
<DocScrutinizer05> total
<DocScrutinizer05> but yeah, *maybe they'd be willing to program 1k A, 1k B, and leave 1k unprogrammed
<DocScrutinizer05> http://susepaste.org/18785689 they either are mad or their webshop is pathetic
<DocScrutinizer05> (no discount on buying a 3k instead of 100)
<DocScrutinizer05> you'd think a 3k unprogrammed should be slightly cheaper than 3k programmed
<pie_> 990 euro phone mobo ; __ ;
<pie_> DocScrutinizer05, maybe they dont mark up smaller orders? :O
<DocScrutinizer05> rqou: anyway Neo900 is alive
soylentyellow has quit [Ping timeout: 246 seconds]
<awygle> Cross platform builds strike rqou yet again
<rqou> it's not even "really" cross platform
<rqou> x86_64-linux-gnu vs x86_64-linux-musl
<rqou> also musl is objectively better :P
<DocScrutinizer05> hmmm better how?
<DocScrutinizer05> pie_: excuse my poor english, what's the meaning of "mark up an order"?
gnufan has quit [Quit: Leaving.]
<awygle> DocScrutinizer05: in this context "mark up" means "increase the price of"
<DocScrutinizer05> thanks
<rqou> musl is better because it's small, actually understandable, tries to be correct, and can correctly be statically linked
<awygle> It's also MIT instead of LGPL, which is a point in some direction :-P
<awygle> Why are you statically linking the C standard library?
<awygle> (realizing in advance that I will regret the question)
<rqou> so that you can have a single, dependency-free, distro-independent binary
<rqou> e.g. the same binary will work on a raspi vs an android phone
<rqou> and you don't even have to swear at bionic
<pie_> completely random question, does sandwiching stuff between two connected ground planes decrease noise
<pie_> or do you jus tcouple your own noise to the ground planes :D