<Wanda[cis]>
have fully reverse engineered XC5200 bitstream again, this time using XACT; the two databases are a perfect match except for two pieces of test functionality (one is only exposed in XACT, the other only in ISE)
<Wanda[cis]>
I was going to do XC4000* as first XACT target, but changed my mind midway because XC5200 has much less annoying interconnect structure; will resume XC4000 work next
whitequark[cis] has joined #prjcombine
<whitequark[cis]>
nice
<mupuf>
Wanda[cis] just couldn't take the risk of leaving any bitstream feature left un-reversed, could she? So she had to make sure the legacy legacy synthesis tool agreed with the legacy synthesis tool :D
<whitequark[cis]>
xact is less of a legacy tool and more of a heirloom tool
<whitequark[cis]>
national monument synthesis tool
<mupuf>
ha ha
<Wanda[cis]>
mupuf: I do take verification seriously
<mupuf>
More seriously, I get it: you want to cross-validate the two reverse engineering workflows
<Wanda[cis]>
which... well, I suppose you've seen already
<mupuf>
but still... some may say that reversing one bitstream was already mission impossible and you decided to do it twice :D
<whitequark[cis]>
reversing bitstreams is relatively easy
<Wanda[cis]>
the cross-validation is useful, yes
<whitequark[cis]>
i thought it was hard and then i just did it (Project Bureau)
<mupuf>
Ha ha, I seem to remember Wanda[cis] telling me more than a decade ago that it was extremely tricky. That's why it seems a little funny to me
<whitequark[cis]>
i think the hardest part was that the placer was buggy and didn't expose some features correctly, probably because someone forgot a pair of {}
<Wanda[cis]>
though tbh I did this mainly because I knew there were extra test bits in XACT that I wanted to get
<Wanda[cis]>
mupuf: a decade ago?
<Wanda[cis]>
I have absolutely no memory of this conversation
<whitequark[cis]>
see, the key part that was missing a decade ago is not being quite dead inside yet
<whitequark[cis]>
i find that this really helps with reverse engineering anything
<Wanda[cis]>
I mean
<whitequark[cis]>
the less of a soul you have remaining, the easier it is to replace it with the soul of some other engineer you temporarily borrow from the void
<Wanda[cis]>
tbh a decade ago I didn't find reversing bitstreams all that hard
<Wanda[cis]>
I did get a fair bit into cyclone II reversing, even
<Wanda[cis]>
(it just happened to be what I had on hand)
<mupuf>
whitequark[cis]: Yeah, pretty sure it was before you started working on security stuff
<whitequark[cis]>
i worked on security stuff?
<whitequark[cis]>
that's news to me
<Wanda[cis]>
the reason I gave up was because of "ok, I reverse the whole bitstream, what then"
<mupuf>
err, sorry, I meant Wanda[cis]
<mupuf>
the other w lady ;)
<Wanda[cis]>
the perspective of having to write a whole-ass open source toolchain after a big reversing project was too much for me back then
<mupuf>
right, without a P&R toolchain, it is indeed a little useless
<Wanda[cis]>
of course
<whitequark[cis]>
i've tried manually constructing SOP terms with Project Bureau, there is even a tool to do that
<whitequark[cis]>
it is tedious
<mupuf>
I may be misquoting you then, that might have been what you meant
<Wanda[cis]>
as Catherine pointed out, these days I am dead enough to no longer be intimidated by that
<whitequark[cis]>
simply develop the rest of the toolchain
<Wanda[cis]>
and also, well, we actually have an open source toolchain these days
<mupuf>
Says the lady who was making bit-perfect C models of NV01 and NV03 :D
<mupuf>
Wanda[cis]: I think what has always been fascinating me with your work was always your resolution and complete lack of fear of failure or wasting time. And you've prevailed over and over and over again. It's been sooooooo inspiring
<mupuf>
I wish I had been following whitequark[cis] earlier too, for the same reasons!
<whitequark[cis]>
heh. i'm glad it's inspiring
<Wanda[cis]>
me too
<Wanda[cis]>
I don't really hear that often
<mupuf>
That is sad...
<Wanda[cis]>
as for fear of failure
<Wanda[cis]>
there are actually bits I am and have been concerned about
<Wanda[cis]>
I just... don't really let that stop me
<mupuf>
Who knows, maybe one day I'll be back in Warsaw for one reason or another and we could meet up again. I have a big hug in reserve for you :D
<Wanda[cis]>
timing info, for one
<Wanda[cis]>
though I'm much less concerned about that now after spending a night with Cat looking into this
<Wanda[cis]>
but fundamentally. ISE can generate bitstreams and do timing analysis for FPGAs I'm interested in.
<mupuf>
Sounds like a good starting point!
<Wanda[cis]>
this means I can, at the very least, replicate whatever it's doing given enough RE violence applied to it
<mupuf>
Do you know how the binning process works at the factory?
<Wanda[cis]>
it's just a matter of effort
<Wanda[cis]>
not really
<Wanda[cis]>
I've been wondering about the details a lot
<Wanda[cis]>
in the end, I came to a simple conclusion
<mupuf>
It could just be a static allocation based on the location on the wafer... or they may have some carefully-crafted gateware to do the binning for them. I would vote for the later, of course
<Wanda[cis]>
we cannot know the exact details of binning process, and measuring actual devices cannot possibly cover a large enough sample
<Wanda[cis]>
so the only way is to basically replicate ISE's timing data and algorithms
<mupuf>
yeah, the best you could achieve is akin to overclocking for a single chip... but this time with a toolchain making sure timings are actually proper and not just "happen to work"
<mupuf>
In other words, that's pretty niche and with real chances of getting it very wrong
<Wanda[cis]>
not worth the effort
<Wanda[cis]>
(effort of devloping a methodology of characterizing a chip of given FPGA family)
<mupuf>
+1
micko has joined #prjcombine
<micko>
Hi. Understand that focus is on Xilinx devices, but there is part of code for Lattice, is it a plan to try to do full RE and replace prjtrellis and icestorm ?
<micko>
Also what is the plan for chipdb integration with nextpnr, making a new crate for exporting bba data and making sure it is up to date with nexpnr or using some python-rust bridge on nextpnr import script side ?
<Wanda[cis]>
prjcombine was never meant to be xilinx-specific, correct
<Wanda[cis]>
I consider one of its main goals to be exploration of highly automated and widely applicable techniques for FPGA reversing
<Wanda[cis]>
I looked at Lattice at one point and some bits ended up in the repo (there's also some half-finished code on a branch that extracts p&r database in the prjcombine format, but I ended up not really liking the approach I chose there and kinda abandoned it; I'll probably rewrite it to something more like the XACT extractor at some point)
<micko>
Got it. Thanks a lot. No hurry there. Had look to other series of Lattice FPGA when I was doing XO2 and XO3 and there are certain patterns that could be reused.
<Wanda[cis]>
I don't have any immediate plans for further targets beyond Xilinx at this point; Lattice would be easy to support because of toolchain similarities to ISE, but if anything I'd like to test out some approaches on targets that are not very Xilinx/ISE-like
<Wanda[cis]>
either quartus or icecube comes to mind
<Wanda[cis]>
as for nextpnr
<Wanda[cis]>
there are no plans of any sort
<Wanda[cis]>
there's a story here, which you have actually been witness to
<Wanda[cis]>
of a previous xilinx reversing project of mine a few years ago, where Edmund demanded a demo for some rich asshole who'll definitely give us lots of money if he sees Spartan 6 with DDR2 or whatever
<Wanda[cis]>
the rush job I did back then to get all this working, and the complete failure afterwards, has basically completely destroyed all my desire to reverse FPGAs.
<Wanda[cis]>
took a few years until I could look at xilinx again
<micko>
Yeah, remember that. Anyway I just made a PR for one arch and soon starting on work on another (all in public this time), so at least there are some things that would be cleaned up and improved in himbaechel API extensions as needed by more strange architectures
<Wanda[cis]>
so no. I am not going to do anything about writing a production toolchain until I consider this project actually mature enough to support it.
<Wanda[cis]>
and given exactly how the last attempt failed
<micko>
Understand
<Wanda[cis]>
the main part of "mature enough" is having timing information
<Wanda[cis]>
(the other part is some in-hardware verification, but that part I'd actually compromise on)
<Wanda[cis]>
basically prjcombine is going slow and not looking for a quick blinky, by design
<micko>
That is perfectly fine, I am happy there is work going on there. I have multiple arch projects RE that are pending due to lack of time mostly
<Wanda[cis]>
(if anything, the first actual bitstreams I emit will be testcases for manual verification of some messy I/O and clock bits; I'll either do manual P&R or write some quick debug-grade P&R tool)
micko has quit [Ping timeout: 256 seconds]
micko has joined #prjcombine
micko has quit [Quit: Client closed]
melnary has quit [Remote host closed the connection]
melnary has joined #prjcombine
q3k[cis] has quit [Quit: Idle timeout reached: 172800s]