HOME       UP       PREV       NEXT (Adopting a Suitable Coding Style for HLS)  

Classical HLS Compiler: Operational Phases

The classical HLS tool operates much like a software compiler, but needs more time/space guidance.

A single thread from an imperative program is converted to a sequencing FSM and a custom datapath.

  1. Lexing and Parsing as for any HLL
  2. Type and reference checking: can an int be added to a string? Is an invoked primitive supported?
  3. Trimming: Unreachable code is deleted, register widths are reduced where it is manifest that the value stored is bounded, constants are propagated between code blocks and identity reductions are applied to operators, such as multiplying by unity.
  4. Binding: Every storage and processing element, such as a variable or an add operation or memory read, is allocated a physical resource.
  5. Polyhedral Mapping: A memory layout or ordering optimisation for nested loops.
  6. Schedulling: Each physical resource will be used many times over in the time domain. A static schedule is generated. This is typically a scoreboard of what expressions are available when. (Worked example in lecuters.)
  7. Sequencer Generation: A controlling FSM that embodies the schedule and drives multiplexor and ALU function codes is generated.
  8. Quantity Surveying: The number of hardware resources and clock cycles used can now be readily computed.
  9. Optimisation: The binding and schedulling phase may be revisited to better match user-provided target metrics.
  10. RTL output: The resulting design is printed to a Verilog or VHDL file.

Some operations are intrinsically or better implemented as variable-latency. Examples are division and reading from cached DRAM.

This means the static schedule cannot be completely rigid and must be based on expected execution times.

Important binding decisions arise for memories:


13: (C) 2012-18, DJ Greaves, University of Cambridge, Computer Laboratory.