specing has quit [Read error: Connection reset by peer]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<rqou>
azonenberg: how do i get yosys to check circuit equivalence? is this very simple or very hard?
<pie_>
rqou, maybe its even np complete! \o/
<pie_>
isnt it SAT or something?
<azonenberg>
Yes
<azonenberg>
It is
<azonenberg>
i think yosys has formal equivalency checking capabilities, if nothign else you could do it by feeding both the same inputs and asserting the outputs
<azonenberg>
but i think you'd have to manually constrain equivalence of the FFs
<azonenberg>
or it'd have them power up to different states and fail immediately
<rqou>
but they all have initial states?
<rqou>
do i want formal equivalence checking or do i need to actually go and set up the whole smtbmc flow?
<azonenberg>
that's now how the solver works
<azonenberg>
not*
<azonenberg>
It assumes the system can start in any state that's legal according to your assertions
<azonenberg>
at time T
<azonenberg>
then tries to find a state at T+1 that violates them
<rqou>
why doesn't the inital state become an assertion?
<azonenberg>
Suppose you had a state that could only be hit after a few hundred thousand clocks
<azonenberg>
the solver isn't going to run that far
<azonenberg>
it's just going to see that this is a possible state of the system, and assume it can happen eventually
<rqou>
oooh i see what you're saying
<rqou>
it'll fail the induction step
<azonenberg>
Yeah exactly
<azonenberg>
The base case i think cares about initials
<azonenberg>
But not the induction
<azonenberg>
it took me a while to wrap my head around that
<rqou>
ugh
<rqou>
but this means that checking for bugs in my json dumper by just using the formal verification tools doesn't quite work
digshadow has joined ##openfpga
<azonenberg>
It would be nontrivial, but i'd love to figure out a way to do it eventually
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/v76gU
<openfpga-github>
openfpga/master d442b37 Andrew Zonenberg: Greenpak4*: Implemented parameters for ABUF to Flipflop (alphabetically).
<rqou>
hey azonenberg do you want me to push to master?
<azonenberg>
rqou: Sure
<rqou>
alright, huge mess incoming :P
oeuf has joined ##openfpga
<openfpga-github>
[openfpga] rqou pushed 31 new commits to master: https://git.io/v7623
<openfpga-github>
openfpga/master abecd79 Robert Ou: yosys-netlist-json: Make creator optional
<openfpga-github>
openfpga/master 2a2cbef Robert Ou: yosys-netlist-json: Import existing code from xc2par
<openfpga-github>
openfpga/master 4133843 Robert Ou: Initial commit of Yosys netlist crate
egg|egg has quit [Ping timeout: 240 seconds]
<pie_>
huuuuuge messs
<pie_>
[dog-toilet-paper.gif]
<pointfree>
pie_: /r/REMath I hadn't heard of that subreddit. Thanks!
<pie_>
pointfree, :)
<pie_>
if nothing else at least id make a mediocre librarian! :D
<rqou>
azonenberg: so what do you want me to do next? hunt for bugs? clean up the code? or move on to something else?
<azonenberg>
rqou: Bug hunt and cleanup, for the short term
<azonenberg>
i'll play with it when i have time
<azonenberg>
Kinda overloaded right now
<azonenberg>
(gee, big surprise)
<pie_>
:P
<pointfree>
So I'm putting together a PSoC 5LP-based device and I'd like to avoid almost doubling the cost with a second PSoC for recovery and programming (aka the KitProg). Supposedly one can program the PSoC over the USB connector. Is this correct? Does anyone here have experience with this? cyrozap?
<cyrozap>
pointfree: Yeah, if you have a bootloader on the device, you can program it over USB, but you could just as easily slap a $1.50 STM32 on the board with an OpenOCD-supported CMSIS-DAP firmware (like this one: https://github.com/x893/CMSIS-DAP)
<cyrozap>
You don't _need_ a KitProg to program a PSoC, you can do it with any JTAG/SWD adapter (assuming the device is either erased or has its NVM bits properly set to enable debugging).
theMagnumOrange has quit [Ping timeout: 276 seconds]
<cyrozap>
Or, you could just add an SWD/JTAG header to the board to program the bootloader with an external adapter, then load all your application code using the bootloader. Unless you're specifically making a dev/experimentation board, that's probably the least-expensive route to take.
<azonenberg>
i almost never use integrated programmers these days
amclain has quit [Quit: Leaving]
<pointfree>
The board is for developers and I'd like to make it updatable and recoverable (if wiped), ideally without the erasable supporting software on the board.
<pointfree>
Although maybe it's reasonable to expect people to have a programmer lying around (?)
<rqou>
i hate expected programmers to be lying around
<rqou>
i never have the appropriate one when i need it
<azonenberg>
rqou: you need a starshipraider
<azonenberg>
:p
<rqou>
i also occasionally want a lower-cost option though
<rqou>
yesterday i was joking in a different channel that somebody needs to fork the black magic probe firmware, make it support AVRs, and call that "blue magic probe"
<rqou>
and then do that again for PIC support and call it "red magic probe"
<rqou>
hmm, and starshipraider can be "white magic probe" because it supports all of the above :P
<azonenberg>
:p
coin0___ is now known as coino_
<pointfree>
hmm... PSoC USBIO D+ shares the same pin as SWDIO, and USBIO D- shares the same pin as SWDCLK. They aren't listed as GPIO's.
scrts has quit [Ping timeout: 260 seconds]
<azonenberg>
Huh
<azonenberg>
my iobufs are not being optimized out
<azonenberg>
wonder why
<azonenberg>
Not a big deal
scrts has joined ##openfpga
<openfpga-github>
[yosys] azonenberg pushed 2 new commits to master: https://git.io/v76wS
<openfpga-github>
yosys/master 4ff1b88 Andrew Zonenberg: Merge branch 'master' of github.com:azonenberg/yosys
<openfpga-github>
yosys/master fa9cf65 Andrew Zonenberg: Fixed typo in COUNT8 model
<pie_>
rqou, white supremacy
<pie_>
:D
* pie_
runs
<rqou>
stop shitposting and do something useful! :P
<pie_>
well i should go sleep again
<awygle>
pie_ is shitposting like i shitpost after 3-4 days of sleeping about 3 hours a night
<rqou>
alright, i really need to figure out how i'm going to test this jed2json tool
<openfpga-github>
[openfpga] rqou pushed 6 new commits to master: https://git.io/v76rE
<openfpga-github>
openfpga/master e4c4ae6 Robert Ou: xc2bit-jed2json: Remove some of the duplicated code for adding wires
<openfpga-github>
openfpga/master b299cb6 Robert Ou: xc2bit: Refactor out helper function to get ZIA table row
<openfpga-github>
openfpga/master 6e2ada5 Robert Ou: xc2bit-jed2json: Fix up duplicated code for constructing cells
<pie_>
rqou, well reall you need two of something to compare no? :/
<rqou>
i've done a bunch of manual testing
<awygle>
pie_: i infer that it stands for C Verilog Compiler or something of the sort http://www.tachyon-da.com/ it was linked from the gtkwave home page
<pie_>
but who wants to write two implementations with possiblythe same bugs eh
scrts has quit [Ping timeout: 240 seconds]
<rqou>
nah, you can just write some verilog and run it through ISE
<pie_>
rqou, not sure if it helps but you could try "recompiling" the json, running it through again and see if it matches?
oeuf has quit [Read error: Connection reset by peer]
<rqou>
except my output doesn't actually compile in ISRE
<rqou>
*ISE
oeuf has joined ##openfpga
scrts has joined ##openfpga
<rqou>
azonenberg: hey, what happens if the input and output voltage range don't match?
<azonenberg>
Never tested
<rqou>
azonenberg plz go and grade the CSCI 4974 / 6974 homework again :P
<azonenberg>
lol
<azonenberg>
I didnt do cross sections
<azonenberg>
or detailed dopant profiling
<azonenberg>
sooo not enough info to tell
<rqou>
don't your images have dash etch?
<rqou>
hmm, might not be sufficient for IOBs
digshadow has quit [Ping timeout: 240 seconds]
<azonenberg>
its qualitative
<azonenberg>
not quantitative
<azonenberg>
so, no
<rqou>
but dash etch is probably good enough for normal logic, right?
<rqou>
oooh offtopic
<rqou>
azonenberg: i have a source for another dataset to test high-level circuit RE
<rqou>
the visual 6502 data
digshadow has joined ##openfpga
<azonenberg>
eh, i'd have to look at it
<azonenberg>
i dont know much about 6502 guts
<azonenberg>
all of my stuff is designed to work on static cmos
<azonenberg>
also is the v6502 data broken down into cells or raw transistors?
<rqou>
raw transistors
<azonenberg>
if i could get a cell level netlist i could work on that
<rqou>
it's not built out of standard cells
<azonenberg>
So yeah it might be interesting for asic RE
<azonenberg>
But not too applicable to any of my current tools
<azonenberg>
i'm targeting standard cell cmos
<rqou>
no, i'm not talking about processing the polygons
<azonenberg>
what i meant is
<rqou>
i'm assuming you just import the netlist into yosys
<azonenberg>
my algorithms need gates
<azonenberg>
not fets
<rqou>
can't you just turn fets into gates? :P
<azonenberg>
not trivially, no
<azonenberg>
thats another research problem
<azonenberg>
and i'd rather develop such a tool for CMOS
<rqou>
hmm, why not?
<azonenberg>
rather than wasting time doing something for nmos that i wont use for anything modern
<azonenberg>
You have to figure out which transistors are connected into a single gate
digshadow has quit [Ping timeout: 246 seconds]
<azonenberg>
unless you want to do full analog modeling
<azonenberg>
to keep it clean and behavioral you can't model stuff like internal pullups
<rqou>
er, i was thinking you can just model them all with the switch model and wire-ands
<rqou>
hey, this is one use of vhdl resolution functions :P
<azonenberg>
If we want to do ASIC import i guess at some point we will have to do tristate support
<azonenberg>
but i may just convert them to a mux cascade explicitly
<azonenberg>
in the import stage
<azonenberg>
so the core logic engine always works on signals with one and only one driver
<azonenberg>
a la FPGA
<azonenberg>
That would make it LOT easier to analyze
<rqou>
i'm looking at the yosys documentation and isn't that what "tribuf" does?
<azonenberg>
Don't know
<azonenberg>
When we do it isn't important
<azonenberg>
but my higher level de-synthesis code will expect it
<rqou>
hmm, i've done a decent amount of manual testing on my jed2json
<rqou>
i think i'm going to distract myself with writing a tutorial on "how to use yosys-smtbmc"
<awygle>
please do, that would be great
<awygle>
having moved is fantastic, but moving is the worst
<awygle>
in your experiences, how often is the speed of simulation a pacer for HDL development?
<rqou>
my designs tend to be pretty small and simulate at reasonable speed
<rqou>
synthesis on the other hand...
<rqou>
:P
<rqou>
how goes the work on PAR?
<awygle>
progress is slow but steady
<awygle>
i got horribly ill this weekend
<awygle>
so plus side, nothing else to do, minus, i kept passing out
<awygle>
i am finding it hard not to get nerd-sniped into "how do i make this a generally useful framework". i've mostly been hacking on arachne, but i'm thinking i might try and break out _just the placer_ into a standalone utility for now
<rqou>
i personally would write a totally naive new implementation in python or whatever as a prototype
<awygle>
ew, python :P
<awygle>
so here's the thing, right
<awygle>
the interesting bit of this is the algorithm (algorithms, really, i want to prototype a few)
<awygle>
and plugging into arachne lets me concentrate on the interesting bits rather than, say, parsing blif
<awygle>
but the ice40 really isn't big enough to warrant massive parallelism, and i don't have a good Maximum Complexity test suite anyway
<rqou>
you can always use json instead of blif :P
<awygle>
so i guess i'm just gonna have to do some spadework before i can get to the fun stuff *shrug*
<rqou>
i don't know how much that helps though
<awygle>
this is a general frustration i have with the space (warning, rant)
<awygle>
why the _hell_ are we all using different (blif parsers|json parsers|verilog parsers|vhdl parsers)?
<rqou>
lolol
<awygle>
this is exactly what's wrong with the commerical world - no two tools can communicate because they all support a different subset of the standards
<awygle>
you end up with this common-denominator, "are you sure it's ok to use ~C99~ Verilog-2005?" nonsense
<awygle>
but carving the verilog frontend out of yosys would probably be nontrivial, and would certainly be rude. and taking it over to icarus and saying "hey please use this" would be ruder. so... idk what the solution is really
<rqou>
um, you can get yosys to go from verilog to ast/"ilang"
<rqou>
but that is hard to do too much with
<awygle>
yeah. i've heard a lot of talk about "LLVM for hardware" but i'd honestly rather have "clang for verilog"
<awygle>
anyway. rant over lol
<azonenberg>
awygle: yosys is promising to be the LLVM for hardware IMO
<rqou>
um, you definitely don't want yosys for that
<azonenberg>
RTL -> IR -> backend
m_w has quit [Quit: leaving]
<rqou>
yosys's verilog frontend accepts all kinds of bullshit that's invalid
<rqou>
cue an azonenberg rant here :P
<azonenberg>
and yes there's that :p
<azonenberg>
awygle: have you seen my linter notes?
<azonenberg>
i have a long list of bugs / questionably legal code i want to add checks for in the yosys frotn end
<azonenberg>
Right now yosys is pretty good at handling valid input
<azonenberg>
Not so good at wrong code
<awygle>
right. and if we had _one_ verilog parser, that _everyone_ worked on - steve icarus, clifford, we of ##openfpga, etc etc, maybe that wouldn't be true
<awygle>
well... two. wouldn't want to get monoculture-y :P
<awygle>
azonenberg: uh i've seen the linter notes yes, but they're not leaping to memory. i'll refresh, after i've finished moving and have time for things again (probably next week)
<awygle>
speaking of, back to manual labor. so long y'all, thanks for the rant
<azonenberg>
Woop
<azonenberg>
ok, this is good progress
<azonenberg>
I think
scrts has quit [Ping timeout: 240 seconds]
awygle has quit [Ping timeout: 276 seconds]
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v766i
<openfpga-github>
yosys/master ccebec0 Andrew Zonenberg: Finished initial GP_COUNT8/14/8_ADV/14_ADV sim models. Don't support clock divide, but do everything else.
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v766M
<openfpga-github>
yosys/master 10d7425 Andrew Zonenberg: Fixed typo in last commit
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v7665
<openfpga-github>
yosys/master b324f07 Andrew Zonenberg: Fixed undeclared "count" in GP_COUNT14_ADV
<openfpga-github>
[yosys] azonenberg pushed 3 new commits to master: https://git.io/v766A
<openfpga-github>
yosys/master 28d6d0e Andrew Zonenberg: Merge branch 'master' of github.com:azonenberg/yosys
<openfpga-github>
yosys/master 4368b0a Andrew Zonenberg: Fixed undeclared "count" in GP_COUNT8_ADV
<openfpga-github>
yosys/master c1131c9 Andrew Zonenberg: Fixed undeclared "count" in GP_COUNT14_ADV
<rqou>
oh btw azonenberg: since i suck at verilog, can i get you to write me a clock divider sim model at some point? :P
digshadow has joined ##openfpga
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v76iD
<openfpga-github>
yosys/master 4265e38 Andrew Zonenberg: Added level-triggered reset support to GP_COUNTx simulation models
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v76iA
<openfpga-github>
yosys/master 841ea44 Andrew Zonenberg: Changed LEVEL resets to be edge triggered anyway
<azonenberg>
grrr
<azonenberg>
Thought i had this working :(
scrts has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
<rqou>
uh wait what
<rqou>
hmm, iirc when i wrote the code with posedge ise would generate a level-triggered reset
<rqou>
wait
<rqou>
hmm
<rqou>
now i need to double-check whether i have a problem or not
<azonenberg>
playing aroudn to make sure this works the way i want...
<rqou>
hmm, how do you even distinguish level and edge triggered resets?
<azonenberg>
For the time being i'm not
<azonenberg>
So the sim models won't be perfect
<rqou>
i don't even know how to get yosys to infer one or the other
<azonenberg>
But blinky only uses level triggered so i'm good :p
<rqou>
wait
<rqou>
isn't this a level-triggered reset that you've described?
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v76PV
<openfpga-github>
yosys/master efd52c3 Andrew Zonenberg: Changed LEVEL resets for GP_COUNTx to be properly synthesizeable
<azonenberg>
For LEVEL? yes
<azonenberg>
So the rising/falling stuff is broken
<azonenberg>
they act as high/low level for now
<azonenberg>
I'll try and fix it later
<rqou>
wait, what is broken? i'm now confused
<azonenberg>
Blinky works, i'm focusing on that :p
<rqou>
aah
<rqou>
they're all level-triggered
<rqou>
is that the problem?
<azonenberg>
Yes
<rqou>
why does gp4 even have edge-triggered resets?
<rqou>
i don't think i've ever used those
<azonenberg>
i think its an artifact of some other hard IP sharing the same block
<azonenberg>
which is level triggered
<azonenberg>
the mux was there so they doc'd it
<openfpga-github>
[openfpga] azonenberg pushed 2 new commits to master: https://git.io/v76PM
<openfpga-github>
openfpga/master c006c50 Andrew Zonenberg: Merge branch 'master' of github.com:azonenberg/openfpga
<openfpga-github>
openfpga/master bd28b5a Andrew Zonenberg: Finished initial netlist export
<azonenberg>
my counter inference logic never uses it
<azonenberg>
in particular, the weirdest
<azonenberg>
both-edge-triggered reset :p
<rqou>
i legitly don't know how to infer an edge-triggered reset
<rqou>
wait wtf
<azonenberg>
Any time RST changes, either way, the counter resets
<azonenberg>
i just throw an error if you encounter that right now, lol
<rqou>
fortunately for me xc2 only has level-triggered resets
<rqou>
sanity!
<openfpga-github>
[yosys] azonenberg pushed 1 new commit to master: https://git.io/v76Xf
<openfpga-github>
yosys/master c277c3c Andrew Zonenberg: Fixed typo in error message
<azonenberg>
Basically, anything you can do to make that more useful
<azonenberg>
i think i am going to want to splitnets actually before doing anything else
<azonenberg>
there's some vectors there that aren't necessarily actual vectors
<azonenberg>
so hold off for a sec...
<azonenberg>
ok there we go
<azonenberg>
re-uploaded
<azonenberg>
Don't rely on symbol names being at all useful
<azonenberg>
a) they're part of the untechmapping process and not the actual bitstream
<azonenberg>
b) depending on cell lib they're going to change wildly or be entirely missing
<azonenberg>
So you have to work entirely on the gate graph
<rqou>
hmm wait
<rqou>
i would expect abc to be able to find adders
<azonenberg>
Try it
<azonenberg>
I dont really care what tools are used :)
<rqou>
i have no idea how :P
<azonenberg>
Well, we already have something no fpga re project has ever done before afaik
<azonenberg>
We can go from two totally different bitstream formats to a unified IR
<rqou>
you mean not-a-spreadsheet and not-graph-paper RE? :P :P
<azonenberg>
Yes
<rqou>
why is so much of EDA powered by spreadsheets and graph paper?
<awygle>
because "[graph paper] is a universal interface"
<rqou>
hmm this is tricky
<rqou>
azonenberg: your siliconexposed blinky for coolrunner-ii actually doesn't generate an adder
<rqou>
it actually generates a cascade of TFFs
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
DocScrutinizer05 has quit [Ping timeout: 258 seconds]
<azonenberg>
rqou: interesting
<azonenberg>
can we infer that into a counter, though?
<azonenberg>
or something along those lines?
<rqou>
that'll be a bit tricky given that we can't even infer TFFs yet
DocScrutinizer05 has joined ##openfpga
<rqou>
arrgh it's so annoying how alan mishchenko doesn't have office hours
<awygle>
somebody fund a GSoC project to make abc not horrible
<rqou>
sorry, ucb too poor for that :P
<awygle>
rqou: i've already ranted once today, don't serve me up a softball like that :P
<rqou>
i'm sure a lot of people have "fun" rants about the state of california and funding
<awygle>
my rant is actually about the regents, but meh
<azonenberg>
rqou: so i seem to have a weird race condition or something in splash
<azonenberg>
tl;dr my 'scopeclient' app fails to dependency scan correctly, with an incorrect path resolution error
<azonenberg>
iff you change any of its code while there's >1 build daemon connected
<azonenberg>
you can build the rest of the project fine with 4
<azonenberg>
so the workaround is to clear cache, attach one builder, build scopeclient, attach other 3 builders, build rest of project
flaviusb has joined ##openfpga
<azonenberg>
Dont have time to debug right now sadly :(
<rqou>
wow there is basically zero documentation whatsoever about how to use abc
<rqou>
why does abc have so much random incomprehensible and commented-out code?
<azonenberg>
Good question :p
<azonenberg>
also, TFW you realize that your board isn't working because the "enable" bit you set high is actually a "powerdown" bit
<azonenberg>
Not my only problem, but i'm sure it wasn't helping :p
DocScrutinizer05 has quit [Ping timeout: 258 seconds]
DocScrutinizer05 has joined ##openfpga
<awygle>
speaking of horrible software, lattice diamond makes me want to short lattice stock, because clearly no one there has ever actually used their software but they just shipped it anyway
<awygle>
any application whose _nominal flow_ _regularly_ results in data loss and crashes should not exist
<awygle>
tl;dr somebody reverse engineer the ECP5 plz
<rqou>
meh, nobody uses ECP5
<rqou>
:P
coino_ has quit [Ping timeout: 276 seconds]
awygle is now known as nobody
nobody is now known as _nobody
<_nobody>
stupid nickname registration ruining my sarcasm razzlefrazzlegrummin...
<rqou>
now i just need to extract these into $alu cells
<azonenberg_work>
Awesome :D
<azonenberg_work>
Does it work on greenpak yet?
<azonenberg_work>
or no
<rqou>
no
<rqou>
i haven't investigated why
<rqou>
er, i did investigate your json
<azonenberg_work>
Let me try doing a "y = a+b" as a 4 bit adder or something
<rqou>
that's also built out of TFFs
<azonenberg_work>
on greenpak
<azonenberg_work>
when i get home
<azonenberg_work>
And see if i can infer an adder off your design
<azonenberg_work>
off your code*
<azonenberg_work>
Is this a custom yosys pass or what?
<rqou>
right now it's just a chain of yosys commands in just the right way
<rqou>
i don't believe this is guaranteed to extract _all_ adders though
<rqou>
only some of them
<azonenberg_work>
Doesnt matter, as long as it doesnt have false positives
<azonenberg_work>
for something like this i'd rather have undecipherable gates than incorrect high level primitives
<rqou>
yeah, i'm going to have to be careful on the "extract to $alu" step
<rqou>
the other steps are pretty hard to have false positives on
<azonenberg_work>
Ok
<azonenberg_work>
I want to work on finding counters made out of TFFs soon
<azonenberg_work>
As this seems to be a common implementation paradigm
<rqou>
well, you can end up with "HALF_ADDER" somewhere where that's not the actual correct high-level function
<azonenberg_work>
Yeah but not a chain of them
<rqou>
but it'll still be logically equivalent to a half adder
<azonenberg_work>
Exactly
<azonenberg_work>
The loose and/xor/or are corrrect too i assume?
<rqou>
yeah
<azonenberg_work>
Awesome
<rqou>
that works by just applying "the massive abc hammer"
<azonenberg_work>
Lol
<rqou>
at least abc is decently fast on designs of this size
<azonenberg_work>
So when i get home i'll test an adder on greenpak against your pile of commands (which should be easy to put into a yosys pass as needed)
<azonenberg_work>
If it finds it i'll be very happy
<jn__>
and here i am buying a PA-RISC workstation for nostalgia
<pie_>
shoulda desoldered those fpgas
<jn__>
oh, it's itanium. i expected MIPS
<pie_>
how does this guy know it so well
<pie_>
seems to anyway
<jn__>
manuals?
<pie_>
makes sense i guess
<pie_>
the sgi crest thing on the front of the servers makes me think of the hitman game
<pie_>
idk if those are epoxy blocks or what, couldnt really understand from what he said, he should get someone to xray/ct them :D https://youtu.be/kKjchciO_wc?t=840
<pie_>
man apparently the dude finds this stuff on ebay