2020-09-17 17:31:24 +00:00
|
|
|
# xilinx 7-series tools
|
|
|
|
|
|
|
|
|
|
WARNING: very poor code quality. expect that you'll probably have to make changes to fit your needs
|
|
|
|
|
|
2020-09-17 17:55:01 +00:00
|
|
|
questions -> idk email me or send me a message on mastodon or something. https://tilde.town/~haskal
|
|
|
|
|
|
2020-09-17 17:31:24 +00:00
|
|
|
- xilbitstream.py - a script that prints the contents of 7-series bitstreams and saves files for
|
|
|
|
|
any configuration frames found inside. supports either endian, with or without the xilinx
|
|
|
|
|
header. nominally does not crash on encrypted bitstreams (!!), but of course it can't really
|
|
|
|
|
make any sense of them either - you'll need the key
|
|
|
|
|
- xilswap.py - simply swaps endianness of each 32 bit word. nothing too fancy
|
|
|
|
|
- pcap_dump_tool - a bare metal ARM tool for zynq bitstream readback. it saves the currently loaded
|
|
|
|
|
bitstream to emmc. it's bare metal because the xilinx linux driver had a bug that prevented it
|
|
|
|
|
from working correctly. additionally, some low-level steps needed to be taken to ensure the
|
|
|
|
|
readback was not corrupted. comments explain each step. you will need to adjust the parameters
|
|
|
|
|
based on the fpga part you have, however. also it needs to be built with the xilinx toolchain
|
2020-09-17 17:47:41 +00:00
|
|
|
- bram_decode_tool - decodes block RAM frames dumped from 7-series bitstreams by guessing the order
|
|
|
|
|
of bitlanes based on a provided "known file" using some hacky statistical analysis. uses a
|
|
|
|
|
project x-ray database to understand the content of the block RAM frames - included is the
|
|
|
|
|
zynq7 database file from https://github.com/SymbiFlow/prjxray-db/ (licensed CC0). however you
|
|
|
|
|
can provide a different database file for different parts. this tool only handles the BRAM
|
|
|
|
|
construction where 32 BRAMs compose each of the 32 bits in a word, because that's the specific
|
|
|
|
|
scenario i wrote it for. if you have a different setup, where BRAM elements hold more than one
|
|
|
|
|
bit of a word you'll need to make changes. additionally, it's based on pure guesswork and needs
|
|
|
|
|
you to know at least some of the contents of the RAM for comparison. perhaps a smarter version
|
|
|
|
|
could check where the BRAM elements are connected and guess the order based on that - but it
|
|
|
|
|
would require lifting the rest of the configuration space which is hard (though one chinese
|
|
|
|
|
paper very dubiously claims to have lifted xilinx AND intel bitstreams to RTL code -
|
|
|
|
|
https://doi.org/10.1109/ACCESS.2019.2901949 - to this i say code or it didn't happen tbh)
|
