<cr1901_modern> I wish I had space for a "clean room". Or even a "clean shoebox".
<azonenberg> cr1901_modern: I plan to try building a glove box in the not too distant future
<azonenberg> and try to put airlocks on the tools
<azonenberg> so i can avoid ever handling them in open air (and thus requiring a cleanroom)
<jn__> a glove box is pretty much a "clean shoebox" :)
<azonenberg> lol
<azonenberg> well i was thinking more like a full benchtop glovebox
<azonenberg> my eventual goal was to have several different areas for high-vac processing, wet chem, imaging, etc
<azonenberg> each with airlocks coming off them
<azonenberg> attached to a glove box
<azonenberg> So i can have one small maybe 2x2x2 foot cube for miscellaneous activities and transfer of samples
<azonenberg> then move things between all the tools through it
<cr1901_modern> azonenberg: My main point is that logistically I don't think I could do homecmos even if I wanted to; I live on the second floor of a condo
<cr1901_modern> I don't have a shed or basement to store all the materials involved
<cr1901_modern> and I feel uncomfortable using the kitchen sink for this :)
<azonenberg> Lol, yes
<azonenberg> I dont think it will be reachable for someone in that situation any time soon
<azonenberg> my goal is for a well funded, resourced individual, or midsized hackerspace, to be able to do it
<azonenberg> That is already a stretch
<balrog> azonenberg: I watched a Louis Rossman Group video where they did HDD repair in a laminar flow hood
<balrog> Hah
<cr1901_modern> azonenberg: What if I rented public storage? lol
<cr1901_modern> I mean, they'd probably terminate my lease, but worth a shot
<qu1j0t3> hahaha Louis
<balrog> qu1j0t3: it worked!
<balrog> This was the one where they did a spindle motor swap where they taped the platters with scotch tape
<cr1901_modern> azonenberg: Honestly, what could I possibly do in my situation to make homecmos even slightly more probable?
<jn__> <troll>put it in a truck container</troll>
<cr1901_modern> Well, ppl have PODS here
scrts has quit [Ping timeout: 240 seconds]
<qu1j0t3> ok, Rossman just _wishes_ he were azonenberg
<qu1j0t3> azonenberg: next level
scrts has joined ##openfpga
<balrog> qu1j0t3: lol he doesn't give a shit
digshadow has quit [Quit: Leaving.]
m_w has quit [Quit: Leaving]
_whitelogger has joined ##openfpga
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 240 seconds]
Hootch has joined ##openfpga
<rqou> lain: but there's no cat :P
<rqou> you need to use cat-5e, not dog-5e
<lain> haha
qu1j0t3 has quit [Ping timeout: 240 seconds]
qu1j0t3 has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
lexano has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Client Quit]
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
amclain has joined ##openfpga
<openfpga-github> [yosys] azonenberg pushed 3 new commits to master: https://git.io/vQXfi
<openfpga-github> yosys/master 9557fd2 Clifford Wolf: Add attributes and parameter support to JSON front-end
<openfpga-github> yosys/master 8a69759 Clifford Wolf: Add techlibs/xilinx/lut2lut.v
<openfpga-github> yosys/master 4b2d1fe Clifford Wolf: Add JSON front-end
m_w has joined ##openfpga
digshadow has joined ##openfpga
mifune has joined ##openfpga
<rqou> whitequark, digshadow: either of you familiar with gas chromatographs? what's up with this one? http://www.ebay.com/itm/CE-GC-8000-TOP-Gas-Chromatograph-w-AS800-Autosampler-/162498772674?hash=item25d5ae7ec2:g:VdEAAOSwNuxXbGSV
<azonenberg> rqou: So, for your current coolrunner code
<azonenberg> How hard would it be for you to run it backwards?
<azonenberg> i.e. turn a JED into yosys JSON
<azonenberg> formatted properly for feeding back into your tool
<rqou> i specifically abandoned that because you were going to write coolrunner2.v
<azonenberg> o_O
<azonenberg> So, for bitstream RE purposes
<azonenberg> I want to be able to do this
<rqou> remember i had a demo that dumped out a shitty .v file?
<azonenberg> i'm going to be implementing it for greenpak in the next day or so
<azonenberg> yeah, you dont need verilog output
<azonenberg> i want something that spits out a JSON netlist
<azonenberg> It should be possible to do with your existing data model, right?
<rqou> sure?
<azonenberg> just add a JED reader and JSON serializer
<rqou> er actually not quite yet :P
<rqou> LOC isn't implemented :P :P
<rqou> for anything, including pins
<azonenberg> Adding LOCs would be a plus but as a minimum, something with logically equivalent behavior and no pin locking
<azonenberg> Basically what i'm trying to do as a demo in the not too distant future
<azonenberg> is something that will take in a coolrunner bitstream and spit out a greenpak bitstream that's logically equivalent
<digshadow> rqou: I am not
<digshadow> what do you want to do with one
<azonenberg> And vice versa
<rqou> digshadow: idk, this one was just super cheap
<rqou> so there has to be something weird going on
<azonenberg> i'll probably mostly demo greenpak-to-coolrunner b/c i can use my open flow for that
<azonenberg> But i want to show the power of the IR
<rqou> wait, you want to output a generic netlist? not a techmapped/placed netlist?
<rqou> afaik yosys can dump a netlist at any stage of its internal processing
<rqou> also TIL that .json netlists couldn't be re-imported until today
<azonenberg> rqou: yes but that isnt the point
<azonenberg> I want to import a netlist into yosys
<azonenberg> From a .jed
<azonenberg> The goal is jed -> cr2par --invert -> json -> yosys read_json -> yosys untechmap_xc2c -> yosys synth_greenpak4 -> yosys write_json -> gp4par -> gp4prog
<azonenberg> or the other way around with gp4 and xc2c swapped
<rqou> ah i see
<rqou> so you would generate a techmapped/placed netlist, and hook un-techmapping logic into yosys
<azonenberg> Yes
<rqou> so yosys turns into a big dumping ground of "graph algorithm things"
<azonenberg> Alternatively, rather than using it for bitstream translating
<azonenberg> You could add code to yosys to increase abstraction in the netlist
<azonenberg> I might make it call out to other tools too
<azonenberg> but for translating, yosys seems like a good spot to put the techmapping
<azonenberg> The "untechmap" code would likely be as simple as linking a model of each primitive, flattening the netlist, and optimizing
<rqou> hmm now that i think about it, why _doesn't_ yosys have subcircuit extraction already?
<azonenberg> I think it might
<azonenberg> to some extent
<azonenberg> but, point is, this is the goal
<azonenberg> I'm going to work on doing the reverse gp4par today
<rqou> sure, there's "extract"
<azonenberg> $CLIENT is being derpy and hasnt gotten me the stuff i am supposed to be hacking on yet
<rqou> but that's not "real" subcircuit extraction
<azonenberg> And i just got a talk on fpga bitstream RE accepted to a con
<azonenberg> so i can justify it
<azonenberg> But yeah, basically the goal is to use yosys's internal netlist representation as an IR
<azonenberg> And be able to freely convert between verilog and bitstreams for all supported devices
<azonenberg> using this IR as a working ground
<balrog> :)
<rqou> except yosys's internal netlist representation isn't the most fun to actually use
<azonenberg> So for example you could eventually take a netlist for a half-full xc7a1005
<azonenberg> xc7a100t*
<azonenberg> lift the bitstream up to a cell level netlist
<azonenberg> re-par it for an xc7a50t
<balrog> rqou: I'd look into extending it... maybe borrow ideas from LLVM IR
<azonenberg> and spit it out as a new bitstream
<rqou> it's basically a generic graph data structure right now and can contain whatever you want
<rqou> different passes have different assumptions about what's in it
<azonenberg> Yes, it would help if it had some kind of tagging ot indicate what level it's at
<rqou> except some passes (*cough* *cough* abc) can go back and generate cells from earlier passes
<azonenberg> abc... that's a can of worms
scrts has quit [Ping timeout: 240 seconds]
<azonenberg> I hesitate to call it a can
<azonenberg> more like a bucket
scrts has joined ##openfpga
Hootch has quit [Quit: Leaving]
<azonenberg> rqou: proposed name for gp4par inverse mode: gp2json
<azonenberg> thoughts?
<azonenberg> or gpk2json
<azonenberg> (keeping in mind the eventual plan to rename gp4par to gpkpar, reflecting that it's going to support more than just greenpak4)
<rqou> hmm, more bikeshed candidates: gpkunpar, ungpkpar
<jn__> gunpkpar :P
<rqou> gp2json looks really weird to me
<rqou> gpk2json looks better
<jn__> gp2json reads like "GreenPak2 JSON"
<azonenberg> That was my thought
<azonenberg> gpkjson would be ok too
<azonenberg> is that better?
<jn__> it certainly leaves less space for misinterpretation
<azonenberg> Yeah
<azonenberg> I'll go with that
<rqou> hmm, we should standardize on naming conventions at some point
<rqou> my converting tools have a "2" in the middle
<rqou> e.g. xc2jed2crbit
<azonenberg> Yes we should standardize
<azonenberg> the concern with 2 is that it can be misinterpreted as a version number or something
<rqou> what about gpk2json?
<rqou> hmm yeah
<azonenberg> I plan to refactor all of the gp4* tools to be gpk*
<azonenberg> since they will support 4 and 5
<rqou> especially when my tools have two 2s in them :P
<azonenberg> Exactly
<rqou> azonenberg: super troll-y name for RE tools: unpar
<rqou> definitely won't be confused with any archivers or anything! :P
<azonenberg> lol
<balrog> unpar/depar
<rqou> dejed :P
<balrog> if you plan to target multiple families :P
<lain> dispar
<azonenberg> Also...
<lain> inversepar
<azonenberg> Right now, libgreenpak4 is a static library
<lain> 1/par
<azonenberg> There is a significant amount of overhead in every one of our apps now as a result of that
<azonenberg> Thoguhts on moving it to a so?
<rqou> no no no no i hate .sos
<lain> is that because linux hasn't solved the dll hell problem? :P
<rqou> probably?
<rqou> i mean, even windows hasn't solved the dll hell problem :P
<lain> they have
<lain> just nobody uses the solution
<rqou> you mean winsxs?
<lain> no
<lain> strong names for assemblies
<rqou> that only works on managed code afaik?
<lain> why would you ever not :D
<lain> but yeah in general even without strong names, the managed code story is wayyyyy better
<balrog> why not move it to an .so?
<rqou> lain: sure, let's turn openfpga into a giant c++(native)+rust+C#+random MSIL glue project :P :P
<lain> I see no reason for all the things that aren't C# in that list
<lain> :V
<lain> </troll>
<rqou> Rust > C#
<rqou> let's fight :P
<lain> no thanks I don't feel like crushing anyone today :3
<rqou> but i have the backing of the Rust Evangelism Strike Force :P :P
<lain> haha
<lain> C# doesn't need evangelism, it's just obviously the right choice ;)
<balrog> but microsoft!
<balrog> and java-like (ew!)
scrts has quit [Ping timeout: 260 seconds]
<rqou> but does C# have a doge and a homura to run bots? :P
<lain> in all seriousness though, why not a .so?
<jn__> any good build system for a library should allow static and dynamic libraries to be built, so making .so the default shouldn't hurt too much
<rqou> iirc running a locally-built .so is a huge massive pain
<rqou> also, a .so might force you to consider the giant pile of worms of "ABI stability"
<rqou> a non-abi-stable .so doesn't seem super useful
<lain> depends if you're targeting external use or only using it within your project
<rqou> i'm personally a fan of the opposite extreme of "everything statically linked"
<rqou> this way there can't be any dependency hell
m_w has quit [Quit: Leaving]
<azonenberg> rqou: then you have a 10+ MB library linked into each of ten binaries
<azonenberg> and what should be a 15 MB download is now 100+
<rqou> but you really don't
<azonenberg> um
<rqou> gp4par non-stripped is 8.6mb
<azonenberg> yes, that is large :p
<azonenberg> gp4tchar is 7 MB
<azonenberg> gpkjson is going to be big too i imagine
<rqou> try building a stripped release build
<azonenberg> In any case not a rush but somethign to think about when we do releases
<rqou> a stripped gp4par is 1.6mb
<azonenberg> also, local shared libraries are no problem if you have them in the build directory
<rvense> cbower
<azonenberg> Yes but why would we strip?
<rqou> you don't need to mess with rpath?
<azonenberg> we want symbols so folks can debug if something goes wrong
<azonenberg> maybe if you want to move stuff around and run in different locations
<rqou> debian normally packages a separate -dbg package for that
<azonenberg> but generally you either run in the build dir or you make install
<rqou> i just remember drepper having written a YUGE document about how to create shared libraries that seemed far more complicated than desired
<rqou> i also remember having to mess with LD_LIBRARY_PATH to get local builds to work
scrts has joined ##openfpga
mifune has quit [Ping timeout: 248 seconds]
uelen has quit [Remote host closed the connection]
uelen has joined ##openfpga
<rqou> azonenberg: hmm apparently you can make linux behave a lot more "windows-like" by adding $ORIGIN to rpath
<rqou> this way the loader will look for .so files in the same directory as the binary
<rqou> that might be ok, but i would probably still prefer static builds
<rqou> this way you only get the "saves space/memory" feature of shared objects without any of the distro/ABI footguns
<azonenberg> You dont get the space/memory savings if it's static
<azonenberg> the whole point is you're not shipping a copy of the lib in each binary
<rqou> er, sorry
<rqou> i meant that using $ORIGIN in rpath would get the advantages
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vQXoH
<openfpga-github> openfpga/master 847a62d Andrew Zonenberg: Initial skeleton of gpkjson
mifune has joined ##openfpga
mifune has quit [Ping timeout: 240 seconds]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
m_w has joined ##openfpga
deep-book-gk_ has joined ##openfpga
deep-book-gk_ has quit [K-Lined]
* azonenberg facepalm
<azonenberg> My gp4-stqfn20-thermal has a bad pinout
<azonenberg> the even and odd pin number columns are swapped
<azonenberg> Time to figure out how to fix...
<balrog> azonenberg: oops :/
<azonenberg> It looks like if i remove the pin header
<azonenberg> and put it on the opposite side of the board
<azonenberg> that should flip it
<azonenberg> i just have to see if that will lead to mechanical issues where things physically wouldn't fit
<azonenberg> Whiiich it probably would
<azonenberg> Soooo
* azonenberg thinks
<azonenberg> I will definitely be respinning the board
<azonenberg> just thinking about if i can save the current design
<azonenberg> (also going to try not moving any components so it stays stencil compatible)
<azonenberg> Looks like, for now
<azonenberg> if i were to replace the 90 deg header with a straight one
<azonenberg> s.t. the board was vertical like a flag
<azonenberg> it would work
<azonenberg> This might actually be easier in terms of allowing access for the peltier plate
fitzsim has quit [Remote host closed the connection]