<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>
(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
<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
<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
* 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
<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
<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