Open rachitnigam opened 5 years ago
--explain
flag for errorsWhen a type error occurs, use the (currently non-existent) machinery to draw out an abstract design and show why the circuit diagram is invalid.
CC @sgpthomas
Write a compiler that converts a random C/C++ program into a Fuse program. Having feature parity with Vivado HLS (i.e. C2Fuse fails iff HLS fails) would be really cool.
We'd like to be able to diagnose failures that happen later in the EDA toolchain—i.e., synthesis, technology mapping, and place-and-route—by exposing them in the source code. For example, if your design fails because the target FPGA doesn't have enough LUTs, we want to "blame" the consumption on some source-level construct in our language. This would require embedding (into the generated RTL) the analog of debug symbols in CPU object code to perform the reverse mapping to our source code.
Take hardware modules, either written directly in Verilog or in some other "generator" language like Chisel, and expose them as extern
-like functions to Fuse programs. Seen this way, Fuse is a composition language for hand-coded RTL components. In the limit, we would replace built-in primitives like +
with externs.
Tools like Jason’s automatic loop optimiser might want to use fuse instead of vivado HLS to write transformations and verify that they don’t violate the safety guarantees that Fuse provides. Having a common representation that be used by external tools and can be easily parsed back for typechecking would be useful for quickly integrating them with Fuse.
Most HLS tool from the past decade rely on LLVM/GCC toolchain to get SW optimizations “for free”. However some optimizations like loop order changes directly affect constructs like unrolled loops, pipelines and reduction trees.
This would involve implementing SW optimization passes and systematically showing that they generate bad hardware.
According to this overview doc by texas instruments, DSPs have similar restrictions to FPGA programs (statically known loop bounds/estimates for instruction pipelining etc.)
Might be worth targeting DSPs in the future.
From talking to people in Oculus it seems having a whole new language is a non starter for any kind of adoption. One way to sidestep is problem in having bindings in C++ and Python that generate a Fuse AST and pass it onto the compiler.
This seems to be the strategy taken by Halide (by extension, TVM), TACO, etc.
^^ It occurs to me that "c2fuse" (https://github.com/cucapra/seashell/issues/160#issuecomment-477346046) could be construed as a different solution to the same problem of basic language familiarity.
Random, potentially malformed ideas for add-ons.