cucapra / dahlia

Time-sensitive affine types for predictable hardware generation
https://capra.cs.cornell.edu/dahlia
MIT License
134 stars 8 forks source link

Offshoot ideas #160

Open rachitnigam opened 5 years ago

rachitnigam commented 5 years ago

Random, potentially malformed ideas for add-ons.

rachitnigam commented 5 years ago

--explain flag for errors

When 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

rachitnigam commented 5 years ago

C2Fuse

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.

sampsyo commented 5 years ago

""Debug Symbols"" for EDA Failure Diagnosis

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.

sampsyo commented 5 years ago

Hardware Externs

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.

rachitnigam commented 5 years ago

Fully serializable IR/AST

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.

rachitnigam commented 5 years ago

Demonstrate common SW compiler optimizations don’t make sense for HW

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.

rachitnigam commented 5 years ago

HLS for Digital Signal Processing

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.

rachitnigam commented 5 years ago

Bindings in other languages

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.

sampsyo commented 5 years ago

^^ 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.