Breakout discussion notes

[sampsyo]

After the lunch break, we'll have a 30-minute period for breakout discussions on LATTE-ish topics. The scribe for each breakout room should paste their notes from their session here.

The mission is to identify the path from here to a world where accelerator design is a widespread, everyday activity just like software development. We divide into four breakout rooms to answer these questions on each topic:

• What is already working well enough (and doesn’t really need further research right now)?
• What are the most important problems that are impeding mainstream adoption?

The four breakout room topics are:

• language design
• analysis/optimization
• testing/verification
• system integration (e.g., CPU+FPGA, CPU+ASIC, module integration, multi-FPGA systems)

[slyubomirsky]

Language design group notes (correct me if my summary is inaccurate)

System Verilog vs Verilog
- One position: RTL tools take too long to catch up with new analyses ("we have the best we can have without metaprogramming"), not clear that there is much room for advancement at the lowest levels
- The tools aren't great for Verilog or VHDL in the first place. The tools don't support all the constructs equally well (reliability of tooling is a problem, as is standardization)
- System Verilog and Verilog are not specified for synthesis -- they are specified with computational models that are good for simulation, but don't say what a synthesis compiler should do

What are barriers to adoption for accelerators?
- Cost of developing an accelerator (esp. ASIC, maybe less so for FPGA) is high, so that's going to be an economic barrier
- What are the applications that a given technology is useful for? Especially given the price points and the difficulty of getting performance compared to alternatives (a lot of people don't go for low-hanging fruit optimizations in software)
- Tools are proprietary, preventing developing the same rich ecosystem as with software languages
- Bad layers of abstractions (everyone is targeting different FPGA interfaces, but if we stuck to one, that could allow for building lots of tools on top of it). Not clear what the right abstraction would be (would want to keep some high-level information)
- Not only do tools have issues, but they're also *slow*: if tools are bad and *fast*, we can find the subsets that work reasonably well and stick to those (analogy to Javascript's very rough edges)

Provisional conclusion: We need some kind of common IRs to be able to build up a more dependable development stack ("converging on good IRs")

[gilbo]

For the next discussion, I'd recommend "Application Workloads" as a topic. It's unclear which applications it makes sense to accelerate and on which underlying technology from an integrated cost-benefit perspective. e.g. When are FPGAs the best choice? When are existing accelerators the best choice? When is developing an ASIC a good opportunity?

[pmokri87]

Testing and verification:
What's working:

1. functional verification works correctly.
2. The software check work correctly
   What can get better:
3. A high-level verification abstract might be helpful.
4. A more transparent verification environment would help: better tools, better error messages (conceptual concurrency, software errors,...)
5. A structured verification would help.

We were talking about whether the question "how to verify" can be improved or not.

[MichaelJKlaiber]

Comment and Suggestions provides by the people in the "system integration" group

What is already working well enough (and doesn’t really need further research right now)?

• HLS Tools

What are the most important problems that are impeding mainstream adoption?

• Tools need to be more SW programmer friendly
• Heterogeneous System, e.g. fpgas with embedded cpu, socs with all kind of devices and on-chip memory
• Mapping of workload to computation entities: CPUs and Accelerators, FPGA
• Performance Expectation based on (static) analysis
• Taken communication into account: when is offloading worth (or does transferring the data )

[sahandKashani]

Comments from the Analysis/Optimization group:

• Hardware compile times are long and incremental compilation sounds like a solid way of shortening this delay. Incremental
  compilation involves freezing parts of a design, but this must currently be done manually. Having a way to
  automatically freeze parts of a design during design space exploration would allow doing design iterations through a
  CAD tool much faster.

• "It works in simulation, not in hardware" bugs:

  • HLS tools tend to focus on elaborating kernels. Though they can minimize loop IIs, they do not generate the memory
    systems at the interface of the kernel to feed the beast. Is there a way to automatically generate these memory
    interfaces (banking, ...) to guarantee a certain performance threshold?

  • A common problem with hardware design is that circuits tend to work in simulation, but hang when actually placed
    on an FPGA. Hangs often occur due to misconfigured memory interfaces that cause bus stalls. If tools could generate
    correct-by-construction memory systems automatically, it would avoid very costly bus protocol debugging that can
    unfortunately only be done with bus probles.

• HLS tools use polyhedral analysis and SMT solvers for different types of problems. Is there any type of unifying
  theory between these 2 techniques such that we would be able to optimize entire applications within a single
  framework? This would allow compilers to easily return a single unbiased answer w.r.t which parts of an application
  limit performance.

• Fast math compiler flags for HLS tools