<azonenberg>
larsc: it's getting there, at this point i'd say only a few more days (of actual work, depends on my schedule when i can get to it) to have the whole chip pretty much decoded
<azonenberg>
At which point i can stop the reverse engineering and start the forward engineering
<azonenberg>
as well as some refactoring to make it easier to scale the code to larger CR-II devices
<azonenberg>
right now i only support the 32a
<azonenberg>
the 64a will be a fairly easy upgrade as the architectures are almost identical
<azonenberg>
the 128 and larger are a different architecture which would require some code changes
<larsc>
how does the architecture influence the bitstream format? Is it mostly different, or same structure but different data?
<azonenberg>
the low end devices each have one input-only pin, i have not yet decoded the bits for using it
<azonenberg>
the higher-end do not
<azonenberg>
low end are two I/O banks, larger is more (but thats an easy change too)
<azonenberg>
the PLA is identical
<azonenberg>
the global routing is different for each device but i have not yet seen any reason to believe the big are any more different from each other than the small
<azonenberg>
the big difference is the low-end devices have one macrocell format
<azonenberg>
the high-end have two, and it's not the same as that of the low end
<larsc>
hm
<azonenberg>
they introduce a new class "buried macrocells" which are internal logic only, not broken out to pads
<azonenberg>
these are basically a subset of the low-end macrocell
<azonenberg>
minus the I/O config
<azonenberg>
but the non-buried mcells in the high-end devices have a lot of new options
<azonenberg>
for example "datagate"
<azonenberg>
and SSTL capability on the inputs
<azonenberg>
that will take more work
<azonenberg>
first priority is a full F/OSS toolchain for the 2c32a
<larsc>
it's nice seeing you getting there
<azonenberg>
I think in another week i'll be able to go from bitstream to RTL source
<azonenberg>
then use the xilinx tools to re-synthesize
<azonenberg>
and get a bit-for-bit identical output
<azonenberg>
(for the 32a)
<azonenberg>
or at least, logically equivalent
<azonenberg>
there's a few spots where its hard to control what the optimizer does
<azonenberg>
which makes generating certain structures to study tricky :p
<larsc>
if your tool was e.g. a compiler and the cplds be ISAs, would you say the difference between high and and low end is more like the differens between MIPS I and MIPS II or more like between MIPS and ARM?
<azonenberg>
I'd say it's closer to x86 and x86-64 lol
<larsc>
ok
<azonenberg>
Low end macrocell config (xilinx-generated comment in the bitstream)
<azonenberg>
N Aclk ClkOp Clk:2 ClkFreq R:2 P:2 RegMod:2 INz:2 FB:2 InReg St XorIn:2 RegCom Oe:4 Tm Slw Pu*
<lekernel>
the rpi way: "let's use a members-only standard implemented with a proprietary chip plus an obscure blob, and go conference-hopping in OSHW events"
<larsc>
one fallout from the v3.10 merge, idle didn't work anymore
<wpwrak_>
azonenberg: (My tools are on track to be *massively* faster than the xilinx ones) what's next on your list ? competitive swimming against a pile of rocks ? ;-)
mumptai has joined #milkymist
lekernel has quit [Quit: Leaving]
Alarm has quit [Ping timeout: 252 seconds]
<azonenberg>
wpwrak_: lol
<azonenberg>
I was actually thinking a 100m sprint vs a tree sloth
* wpwrak_
wonders how the sloth would perform if adding hornets to the equation
<larsc>
a sloth is quite power efficent though
<wpwrak_>
optimally fine-tuned sleep states
<larsc>
by years and years of natural selection, he who sleeps the most survives ;)