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