2 ms·
I saw some good reverse engineering of FPGA's like this work: https://vtechworks.lib.vt.edu/bitstream/handle/10919/51836/Soni_RK_T_2013.pdf https://vtechworks.
by nickpsecurity 8y ago
I saw some good reverse engineering of FPGA's like this work:
https://vtechworks.lib.vt.edu/bitstream/handle/10919/51836/Soni_RK_T_2013.pdf https://vtechworks.lib.vt.edu/bitstream/handle/10919/51836/S...
It has a lot of details on things that are clock-related. Since Im not hardware guy, I can't ssy if it has info needed, if another work could get it building on this, or what. So, what you think?
- monocasa 8y agoIt's not quite what I'm talking about, and what he has listed there is generally pseudo publicly documented. Xilinx for instance, more or less supports programming at the bitstream level rather than the HDL level for stuff like runtime reconfigurable blocks. So there isn't much there in his thesis that isn't covered in the docs. What he covers (for the purpose of this discussion) is how the clock blocks (straight up PLLs if you've done any embedded development) are connected to the rest of the fabric. That's sort of the digital side, and the hard part is the analog side. Ie. "what are the propagation delays of different configuration of LUTs and fabric, and who can you play games with in place and route in order to meet timing". It's an important feedback step in place and route. You can get neat trivial stuff running, but without decent timing analysis it'll be hard to tell if your design will have weird bugs at runtime. Or will lack optimizations that will help you meet timing with an equivalent design. I mean, that stuff is almost a black art even with high quality timing analysis.