C to FPGA

[Rick C. Hodgin]

An interesting video:

C to FPGA Compilation and Domain-Specific Computing
https://www.youtube.com/watch? v=TNF8EhKDM1c

A tool stack taking C and C variants to FPGA, along with some
findings on different approaches, and at different speed
targets in optimization. Very little concern over power budgets
in their current implementation, but consideration in the
future by additional optimization and / or customization.

Best regards,
Rick C. Hodgin

 

[Kevin Neilson]

C to FPGA Compilation and Domain-Specific Computing
https://www.youtube.com/watch? v=TNF8EhKDM1c

A tool stack taking C and C variants to FPGA,

In the video he notes that he had to rewrite the inner loops at a low level to optimize them for hardware synthesis. This is a characteristic of all of these tools: you rewrite it in very low-level code to get it to work well in hardware. Guess what? You are now doing hardware engineering. You've gained absolutely nothing.

 

[Rick C. Hodgin]

Kevin Neilson wrote:

In the video he notes that he had to rewrite the inner loops at
a low level to optimize them for hardware synthesis. This is a
characteristic of all of these tools: you rewrite it in very low-level
code to get it to work well in hardware.

What was the mm:ss? I'd like to put his note in context.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

Rick C. Hodgin wrote:

Kevin Neilson wrote:
In the video he notes that he had to rewrite the inner loops at
a low level to optimize them for hardware synthesis. This is a
characteristic of all of these tools: you rewrite it in very low-level
code to get it to work well in hardware.

What was the mm:ss? I'd like to put his note in context.

I watched it again. The toolset is able to take unaltered C code, or
System C code, and process it through. An MPEG-4 example showed
a target achieved of 30 fps on unaltered code.

The considerations regarding optimization allow for various targets.
For some high speed throughput goals the target is not achievable
through the toolset due to hardware use limitations on logic
units or work per clock. In those cases rewriting C algorithms to lower-
level ops can then coax the toolset to produce a solution for your
RTL needs. It's an enabler for higher speed goals, but, it is not
required in general to produce a workable model for FPGA or
ASIC.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

At about 35 minutes or so he also talks about a startup company
that licensed the toolset for commercial use. The presenter
said they have expanded the toolset into C++. They are former
students of his.

Best regards,
Rick C. Hodgin

 

[Jan Marjanovič]

On Sunday, October 2, 2016 at 2:40:25 AM UTC+2, Rick C. Hodgin wrote:

At about 35 minutes or so he also talks about a startup company
that licensed the toolset for commercial use. The presenter
said they have expanded the toolset into C++. They are former
students of his.

Best regards,
Rick C. Hodgin

The tool he is talking about is xPilot, which was then licensed to AutoESL under the name AutoPilot. The AutoESL was later bought by Xilinx which re-branded the tool as Vivado HLS. The signs of it previous name still remain in the names of the types, e.g. ap_int, ap_fixed.

 

[Rick C. Hodgin]

Jan Marjanovič wrote:

The tool he is talking about is xPilot, which was then licensed
to AutoESL under the name AutoPilot. The AutoESL was later
bought by Xilinx which re-branded the tool as Vivado HLS. The
signs of it previous name still remain in the names of the types,
e.g. ap_int, ap_fixed.

Thank you! Linked here:

https://www.xilinx.com/products/design-tools/vivado/integration/esl-design.html

Best regards,
Rick C. Hodgin