azonenberg changed the topic of ##openfpga to: Open source tools for FPGAs, CPLDs, etc. Silicon RE, bitfile RE, synthesis, place-and-route, and JTAG are all on topic. Channel logs: https://libera.irclog.whitequark.org/~h~openfpga
Degi has quit [Ping timeout: 268 seconds]
Degi has joined ##openfpga
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<sensille>
does spartan6 have internal tristate busses?
<sensille>
and, only loosely related, are there any efforts to reverse the anlogic bitstream?
Xark has quit [Ping timeout: 268 seconds]
russ has quit [Ping timeout: 252 seconds]
russ has joined ##openfpga
Xark has joined ##openfpga
Xark has quit [Ping timeout: 246 seconds]
Xark has joined ##openfpga
<mwk>
s6 doesn't
<mwk>
fpgas up to virtex2 and spartan2 did
<mwk>
(though these buses were emulated tristate; last real tristate was xc4000*/xc5200)
<mwk>
(the xc9500 one is also emulated)
<mwk>
and by emulated I mean a hw primitive that behaves exactly like a tristate bus but is immune to contention
<mwk>
alright, I think I'm done with the reversing; now for the verification step
<mwk>
... is anyone actually interested in my writing down xilinx CPLD bitstream documentation, or should I just leave the data files in my drawer when I'm done
<josuah>
mwk: could that plug itself to the effort from azonenberg which I think got upstreamed in yosys?
<josuah>
about the CoolRunner II
<mwk>
yosys doesn't have anything to do with actual bitstreams, it just synths
<mwk>
either way, I'm not particularly interested in writing a toolchain for CPLDs right now, just... wanted to test-drive some bitstream RE ideas on a small target
<mwk>
is the tristate stuff actually usable as a verilog-level tristate bus in synth? ISE doesn't seem to support that
<azonenberg>
No, it's not
<azonenberg>
basically, each of the 40 inputs to the PLA AND array has eight bitstream config bits associated with it
<mwk>
as for MC bits, I think I have all of them; or at least all that are in the jed files
<azonenberg>
which are intended to be one hot (although one is logically inverted so that the all ones bitstream state gives a well defined result)
kristianpaul has joined ##openfpga
<azonenberg>
one for logic 0, one for logic 1, one for each of six possible inputs
<azonenberg>
in the 2c32a, each of those six are selected by a via-programmed mux from one of 11 possible inputs
<azonenberg>
and the set of legal inputs changes from row to row
<mwk>
yeah, I know all of that
<azonenberg>
So if you assert more than one of those bitstream bits, you can and will get an internal bus fight. Setting all of them, including flipflop states, to give worst case contention is lethal to the component in about 10 minutes
<azonenberg>
i have not tested failure behavior with only a few bus fights
<azonenberg>
Has anyone extracted the interconnect config for larger parts though?
<mwk>
... I literally said I did
<azonenberg>
how?
<mwk>
a few minutes ago
<azonenberg>
i know you can get it out of the ISE data directory
<azonenberg>
but there were copyright issues around that
<mwk>
blackbox
kristianpaul has quit [Client Quit]
<azonenberg>
you got it for *all* of the larger parts?
<mwk>
yes
<azonenberg>
my understanding was the 32a and 64a were very similar
<azonenberg>
but the 128 and larger were different
<azonenberg>
i think it might have been a multilevel tree
<mwk>
just... give completely random tasks to the fitter, pinning all MCs and inputs
<mwk>
in a loop
<mwk>
and you'll soon see *all* the paths
<azonenberg>
Nice
<mwk>
takes likes a few minutes of runtime
kristianpaul has joined ##openfpga
<azonenberg>
but i never fully RE'd it as by the point i got to that point, the coolrunner was somewhat obsolete and icestorm had come out
<mwk>
and yes, indeed there's a multi-level tree
<azonenberg>
so i didnt see it being worth my time
<azonenberg>
Ok yeah that jives with what i expected
<mwk>
2-level or 3-level depending on part size
<azonenberg>
the 32/64 are 4 metal and the 128 and larger are 5 metal
<mwk>
though the third level only has a two-way selection
<azonenberg>
it seems like they changed the interconnect structure at that time
<mwk>
which roughly selects between "IBUF outputs" and "MC outputs" though not exactly
<azonenberg>
sorry my mistake, the 128 is still 4 metal
<mwk>
I still need to clean up the output format, but
<azonenberg>
the 256 is when it jumps to 5
<azonenberg>
so you're saying the 128 is still a multilevel tree?
<mwk>
hold on I'll just generate the files as-is
<mwk>
hmm let's see
<mwk>
... meow, fuzz faster please
<azonenberg>
the 128 looks to still have six groups of inputs but they're slightly unequal in size and i dont know how many per group (the image has some stitching artifacts)
<mwk>
oh, done
<mwk>
yes
<mwk>
it's a two-level tree
<azonenberg>
the 256 has so much more mess on it that without delayering it would be hard to see the structure
<azonenberg>
which i never did
<azonenberg>
the 32a i've decapped, delayered, and done high res imaging of the entire interconnect
<azonenberg>
so i know exactly down to the transistor how it works
<azonenberg>
and the 64, while i did not go that far, is well enough understood that i could probably draw you a schematic based on the fuzzing and the 32a layout
<mwk>
sounds like an awful lot of trouble for something that can be solved by just poking the toolchain
<azonenberg>
Circa 2015, the state of the art in P&R fuzzing was not nearly as advanced as it was now
<azonenberg>
2014*
<azonenberg>
i had tried to figure out a bunch writing bitstreams by hand and loioking at the comments in the jed file
<azonenberg>
and was able to figure out everything between that and the datasheet other than the interconnect
<azonenberg>
so i just decapped the chip and read the mux patterns off the via-3 layer
<azonenberg>
at which point it suddenly made sense