[API][Backend][0.3] Unified simulation and implementation interface for HeteroCL

[hecmay]

This PR constructed a unified build interface in user front-end, and corresponding code generators to generate code for host and devices separately. Note that this PR is built on a merged version of branch v0.3 and master.

The newly supported platforms and corresponding EDA tools are listed as followed. Each platform comes with a default EDA tool (e.g. SDx installed on AWS FPGA AMI by default). The users can also specify the tool they want to use in python frontend. HeteroCL compiler will perform the code generation & compilation if the tool is installed and on system PATH.

• AWS F1 with Xilinx SDAccel & Vitis (supports both OpenCL and HLSC kernel generation)
• Zynq SoC with Xilinx SDSoC and Vivado HLS (only support HLSC kernel generation now)
• Stratix10 GX with Intel AOC (supports OpenCL kernel generation)

A brief example is shown as followed. We have default settings for each platform, the users are also allowed to modify the tool mode and kernel language to their preference (e.g. change the default kernel language from OpenCL to Vivado HLSC)

tool = hcl.tool.sdaccel
tool.mode = "hw"
target = hcl.platform.aws_f1(tool)
target.xcel.lang = "vhls" 

# create schedule and compile function module 
s = hcl.create_schedule([inputs...], kernel)
f = hcl.build(s, target)

# perform emulation or implementation 
f(input_A, input_B)

[zhangzhiru]

"target.xcel.lang = vhls" doesn't sound right. Why does an accelerator needs a language property? It should be part of the tool config.

[zhangzhiru]

tool = hcl.tool.sdaccel tool.mode = "hw"

These two lines also look very odd. I thought the modes we agreed on are sw_sim, hw_emu, hw_exe. Can we do the following instead?

target = hcl.platform.aws_f1() target.config_tool(compile="sdaccel", mode="hw_sim")

[zhangzhiru]

The current interface also lacks consistency. It's not clear why sdaccel is a member in hcl.tool, while "vhls" is passed as a string. Both of them are Xilinx tools.

[hecmay]

Yep. The config_tool() method is a better solution than hcl.tool. The tool mode hw is same as the hw_exe you mentioned above. I chose this term because SDAccel uses it as CLI argument to generate bitstream for FPGA.

[zhangzhiru]

Yep. The config_tool() method is a better solution than hcl.tool. The tool mode hw is same as the hw_exe you mentioned above. I chose this term because SDAccel uses it as CLI argument to generate bitstream for FPGA.

We don't need to be consistent with their terms. I suggest hw_sim, sw_sim, hw_exe, sw_exe

[zhangzhiru]

"target.xcel.lang = vhls" doesn't sound right. Why does an accelerator needs a language property? It should be part of the tool config.

@Hecmay can you also respond to this question?

[hecmay]

"target.xcel.lang = vhls" doesn't sound right. Why does an accelerator needs a language property? It should be part of the tool config.

@Hecmay can you also respond to this question?

HeteroCL can generate HLSC or OpenCL code for each accelerator available on certain platform. The target.xcels[0].lang = "opencl" is just an interface to help developers specify what backend languages they want HeteroCL to generate for the accelerators.

[zhangzhiru]

HeteroCL can generate HLSC or OpenCL code for each accelerator available on certain platform. The target.xcels[0].lang = "opencl" is just an interface to help developers specify what backend languages they want HeteroCL to generate for the accelerators.

This is supposed to be part of the tool settings. Can you propose a cleaner interface based on what we have discussed in this thread?

[hecmay]

HeteroCL can generate HLSC or OpenCL code for each accelerator available on certain platform. The target.xcels[0].lang = "opencl" is just an interface to help developers specify what backend languages they want HeteroCL to generate for the accelerators.

This is supposed to be part of the tool settings. Can you propose a cleaner interface based on what we have discussed in this thread?

# create platform with default settings
target = hcl.platform.aws_f1

# customize backend languages with dictionary  
target.config_tool(compile="sdaccel", mode="hw_sim",
                   backend={0: "opencl"; 1 : "hlsc"})

# another option : to generate OpenCL code for all accelerators 
target.config_tool(compile="sdaccel", mode="hw_sim",
                   backend="opencl")

[zhangzhiru]

another option : to generate OpenCL code for all accelerators

target.config_tool(compile="sdaccel", mode="hw_sim", backend="opencl")

backend => output output = "opencl" or "cpp"

So we can generate either OpenCL or HLS C for Xilinx? OpenCL only for Intel?

[hecmay]

target.config_tool(compile="sdaccel", mode="hw_sim", backend="opencl")

backend => output output = "opencl" or "cpp"

So we can generate either OpenCL or HLS C for Xilinx? OpenCL only for Intel?

Yes. The Intel HLS flow for AOC is still WIP and has not been tested yet. We have all other flows working well.

[hecmay]

@seanlatias there are some conflicts with your latest commits to v0.3. Will resolve it soon.