You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 4, 2021. It is now read-only.
Chips engineering (and eventually reverse engineering) world suffers a lot from fragmentation - some tools produce Verilog, some VHDL, some - only subsets of them, creating low-level LLVM-like alternative will help everyone, so HDL implementations will opt only for generating this low-level HDL and routing/synthesizers accept it. LLVM or WebAssembly - you can see how many languages and targets are supported now by both. With more open source tools for FPGA this is more feasible now than ever. Most of the people suggest to adapt FIRRTL for this. There is a good paper on FIRRTL design and its reusability across different tools and frameworks. If you are familiar with binary analysis tools like rev.ng or retdec, you can see they are based on the uplifting the native code to LLVM code and applying optimization passes to make the output graph much more readable. I believe similar approach can be used for VLSI reverse engineering too. Please consider this option. So if you have any feedback - you are welcome to leave the comment in the corresponding thread.
Chips engineering (and eventually reverse engineering) world suffers a lot from fragmentation - some tools produce Verilog, some VHDL, some - only subsets of them, creating low-level LLVM-like alternative will help everyone, so HDL implementations will opt only for generating this low-level HDL and routing/synthesizers accept it. LLVM or WebAssembly - you can see how many languages and targets are supported now by both. With more open source tools for FPGA this is more feasible now than ever. Most of the people suggest to adapt FIRRTL for this. There is a good paper on FIRRTL design and its reusability across different tools and frameworks. If you are familiar with binary analysis tools like rev.ng or retdec, you can see they are based on the uplifting the native code to LLVM code and applying optimization passes to make the output graph much more readable. I believe similar approach can be used for VLSI reverse engineering too. Please consider this option. So if you have any feedback - you are welcome to leave the comment in the corresponding thread.
See f4pga/ideas#19
The text was updated successfully, but these errors were encountered: