Mod-24: The State of High-Level Synthesis in 2016

[Kevin Neilson]

It's 2016 and I still have to write out most of my code at very low levels of abstraction like I did ten years ago. Whenever I hear about a new tool that supposedly converts C to gates, I don't even look into it, because I can't even get Verilog to synth properly.

My latest example: I needed to reduce an 12-bit number, mod-24.

input [11:0] x;
always@(posedge clk) xmod24 <= x%24;

When I put this in Vivado, what do I get? 40 LUTs (plus some carry chains) and 10 levels of logic. TEN. Needless to say, that won't meet timing at 350MHz, especially when it involves getting on and off a bunch of little carry chains.

So then I have to go down a level of abstraction:

input [11:0];
// x%24 = 8*(floor(x/8)%3) + x%8
always@(posedge clk)
xmod24 <= {x[11:3]%3, x[2:0]};

Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't have to instantiate primitives, like I still often do, even though it's 2016.

Needless to say, I am not about to waste a bunch of time trying out any new "high-level synthesis" tools.

 

[rickman]

On 7/22/2016 11:35 PM, Allan Herriman wrote:

On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:

It's 2016 and I still have to write out most of my code at very low
levels of abstraction like I did ten years ago. Whenever I hear about a
new tool that supposedly converts C to gates, I don't even look into it,
because I can't even get Verilog to synth properly.

My latest example: I needed to reduce an 12-bit number, mod-24.

input [11:0] x;
always@(posedge clk) xmod24 <= x%24;

When I put this in Vivado, what do I get? 40 LUTs (plus some carry
chains) and 10 levels of logic. TEN. Needless to say, that won't meet
timing at 350MHz, especially when it involves getting on and off a bunch
of little carry chains.

So then I have to go down a level of abstraction:

input [11:0];
// x%24 = 8*(floor(x/8)%3) + x%8
always@(posedge clk)
xmod24 <= {x[11:3]%3, x[2:0]};

Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't have
to instantiate primitives, like I still often do, even though it's 2016.

Needless to say, I am not about to waste a bunch of time trying out any
new "high-level synthesis" tools.


I find it easy to ignore HLS, but I still suffer from it because it
splits the tool vendors' development budget across multiple tools.


I got all excited when I first heard about high level synthesis. Then I
discovered that the language was C - hardly high level, and not
particularly well suited to the sorts of things that FPGA coders need to
do.
It's not about making a better language though - it's about allowing non-
FPGA people to do FPGA things, all in the name of market share.

I wouldn't say that. I know when I have heard using C for synthesis
discussed it is more about being able to write the entire project in C
and pick multiple options for the hardware vs. software trade off. I
have no idea how realistic this might be. But I don't think it is about
suddenly having a vast pool of talent to design hardware.

--

Rick C

 

[Allan Herriman]

On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:

> It's 2016 and I still have to write out most of my code at very low
levels of abstraction like I did ten years ago. Whenever I hear about a
new tool that supposedly converts C to gates, I don't even look into it,
because I can't even get Verilog to synth properly.

My latest example: I needed to reduce an 12-bit number, mod-24.

input [11:0] x;
always@(posedge clk) xmod24 <= x%24;

When I put this in Vivado, what do I get? 40 LUTs (plus some carry

chains) and 10 levels of logic. TEN. Needless to say, that won't meet
timing at 350MHz, especially when it involves getting on and off a bunch
of little carry chains.

So then I have to go down a level of abstraction:

input [11:0];
// x%24 = 8*(floor(x/8)%3) + x%8
always@(posedge clk)
xmod24 <= {x[11:3]%3, x[2:0]};

Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't have
to instantiate primitives, like I still often do, even though it's 2016.

Needless to say, I am not about to waste a bunch of time trying out any
new "high-level synthesis" tools.

I find it easy to ignore HLS, but I still suffer from it because it
splits the tool vendors' development budget across multiple tools.


I got all excited when I first heard about high level synthesis. Then I
discovered that the language was C - hardly high level, and not
particularly well suited to the sorts of things that FPGA coders need to
do.
It's not about making a better language though - it's about allowing non-
FPGA people to do FPGA things, all in the name of market share.


Allan

 

[Emilian Miron]

I was pretty happy with Chisel for programming at a higher level. It's in Scala so it's a good blend of type safe but powerful and easy to write. It also catches silly Verilog errors like using an undeclared wire because of a typo. Writing tests was also easier compared to Verilog. There's a sample Risc V core as well with various number of stages.

https://chisel.eecs.berkeley.edu/

On the down side, I did run into occasional issues with the framework and it's harder to debug in hardware since the compiled version is pretty obfuscated. The module inputs are there but other combinatorial glue logic and inner wires had random names.. tried to fix that but ran into framework issues with wire/register naming. It might be doable or I might have used it improperly but this was a hobby project and I did not have too much time to put into it.

On Saturday, July 23, 2016 at 12:00:03 AM UTC-4, rickman wrote:

On 7/22/2016 11:35 PM, Allan Herriman wrote:
On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:

It's 2016 and I still have to write out most of my code at very low
levels of abstraction like I did ten years ago. Whenever I hear about a
new tool that supposedly converts C to gates, I don't even look into it,
because I can't even get Verilog to synth properly.

My latest example: I needed to reduce an 12-bit number, mod-24.

input [11:0] x;
always@(posedge clk) xmod24 <= x%24;

When I put this in Vivado, what do I get? 40 LUTs (plus some carry
chains) and 10 levels of logic. TEN. Needless to say, that won't meet
timing at 350MHz, especially when it involves getting on and off a bunch
of little carry chains.

So then I have to go down a level of abstraction:

input [11:0];
// x%24 = 8*(floor(x/8)%3) + x%8
always@(posedge clk)
xmod24 <= {x[11:3]%3, x[2:0]};

Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't have
to instantiate primitives, like I still often do, even though it's 2016..

Needless to say, I am not about to waste a bunch of time trying out any
new "high-level synthesis" tools.


I find it easy to ignore HLS, but I still suffer from it because it
splits the tool vendors' development budget across multiple tools.


I got all excited when I first heard about high level synthesis. Then I
discovered that the language was C - hardly high level, and not
particularly well suited to the sorts of things that FPGA coders need to
do.
It's not about making a better language though - it's about allowing non-
FPGA people to do FPGA things, all in the name of market share.

I wouldn't say that. I know when I have heard using C for synthesis
discussed it is more about being able to write the entire project in C
and pick multiple options for the hardware vs. software trade off. I
have no idea how realistic this might be. But I don't think it is about
suddenly having a vast pool of talent to design hardware.

--

Rick C

 

[Kevin Neilson]

I guess the good news is that I'll have a job for a few years at least. The machines are still pretty bad at my job.

 

[Kevin Neilson]

I remember going to a Celoxica Handel-C presentation long ago. As I recall they did try to convince managers that any software person who wrote C could also design FPGAs with Handel-C.

 

[Robert Walczyk]

What about SDSoC Development Environment? Anyone with some hands on experience? I've seen a demo a few moths back and that looked promissing

 

[rickman]

On 7/23/2016 3:58 PM, Kevin Neilson wrote:
> I remember going to a Celoxica Handel-C presentation long ago. As I recall they did try to convince managers that any software person who wrote C could also design FPGAs with Handel-C.

Those people can also program FPGAs in VHDL. Did they try to say it
would take no training?

--

Rick C

 

[Devas]

On Saturday, July 23, 2016 at 6:00:03 AM UTC+2, rickman wrote:

On 7/22/2016 11:35 PM, Allan Herriman wrote:
On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:

It's 2016 and I still have to write out most of my code at very low
levels of abstraction like I did ten years ago. Whenever I hear about a
new tool that supposedly converts C to gates, I don't even look into it,
because I can't even get Verilog to synth properly.

My latest example: I needed to reduce an 12-bit number, mod-24.

input [11:0] x;
always@(posedge clk) xmod24 <= x%24;

When I put this in Vivado, what do I get? 40 LUTs (plus some carry
chains) and 10 levels of logic. TEN. Needless to say, that won't meet
timing at 350MHz, especially when it involves getting on and off a bunch
of little carry chains.

So then I have to go down a level of abstraction:

input [11:0];
// x%24 = 8*(floor(x/8)%3) + x%8
always@(posedge clk)
xmod24 <= {x[11:3]%3, x[2:0]};

Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't have
to instantiate primitives, like I still often do, even though it's 2016..

Needless to say, I am not about to waste a bunch of time trying out any
new "high-level synthesis" tools.


I find it easy to ignore HLS, but I still suffer from it because it
splits the tool vendors' development budget across multiple tools.


I got all excited when I first heard about high level synthesis. Then I
discovered that the language was C - hardly high level, and not
particularly well suited to the sorts of things that FPGA coders need to
do.
It's not about making a better language though - it's about allowing non-
FPGA people to do FPGA things, all in the name of market share.

I wouldn't say that. I know when I have heard using C for synthesis
discussed it is more about being able to write the entire project in C
and pick multiple options for the hardware vs. software trade off. I
have no idea how realistic this might be. But I don't think it is about
suddenly having a vast pool of talent to design hardware.

--

Rick C

I attended a Xilinx meeting a couple of weeks ago. They told us that the new tools (e.g SDSoc) are created for a new pool of engineers, e.g software engineers, architects, etc. So this new pool of engineers is also able to design FPGAs. They showed a "nice" slide with a very small pool of FPGA engineers and a very big pool of software engineers.

 

[Theo Markettos]

Emilian Miron <emilian.miron@gmail.com> wrote:

I was pretty happy with Chisel for programming at a higher level. It's in
Scala so it's a good blend of type safe but powerful and easy to write.
It also catches silly Verilog errors like using an undeclared wire because
of a typo. Writing tests was also easier compared to Verilog. There's a
sample Risc V core as well with various number of stages.

Likewise we use Bluespec for much of our work. Which AIUI Chisel is a
hardware construction language (ie it's in some ways a very powerful macro
language for Verilog, but the actual semantics are similar), Bluespec is
derived from Haskell.

Bluespec's unit of operation is the atomic rule. You write rules which can
'fire' (perform their work) when the conditions are right. Those conditions
can either be explicit (only fire in given conditions) but also implicit, so
you can write:

rule pipelineStage (freeze==False);
let x = fifo1.deq();
fifo2.enq(x);
endrule

As well as the explicit condition 'freeze==False' on the rule, fifo1.deq()
has an implicit condition - the rule will only fire (ie data enqueued into
fifo2) if fifo1 is exporting valid data. There is no way to make a mistake
in the protocol and accidentally introduce invalid data.

Since Bluespec is derived from Haskell, polymorphism and higher order types
are part of the language DNA, so it's easy to make parameterisaed
components, and the FIFO semnatics makes it easy to plug them together. The
above example is polymorphic - it'll work for any type emitted by
fifo1.deq(), assuming fifo2.enq() accepts the same type.

Bluespec is perhaps the opposite of high level synthesis: it's good at
controlling how data is moved around. C-to-gates HLS focuses on the
compute, without considering how data is communicated. But the
communication in more-than-trivial C programs tends to be complex - using
the stack, heap and so on, maybe also threading.

You can't just build a C program with HLS and expect it to use your BRAMs
and your DDR3 as easily as C airily assumes the uniform flat address space
of the PDP-11. On a CPU, caches and memory controllers hide that from
you. In hardware they don't.

That's not to mention that a C representation takes an algorithm which might
have lots of parallelism and squeezes it down into a serialised form, and
then we expect HLS to re-extract all this parallelism? Compilers are not
magic.

HLS tackles writing the algorithms which I view as the easy bit, while I
think moving the data around is the hard problem it just ignores.

Theo

(I did run the example code through the Bluespec compiler, but it just
output verilog of '% 24' - it views optimising that as the vendor tools'
job. Which it's probably right about)

 

[Devas]

On Monday, July 25, 2016 at 12:38:58 PM UTC+2, Allan Herriman wrote:

On Sun, 24 Jul 2016 23:48:46 -0700, Devas wrote:

On Saturday, July 23, 2016 at 6:00:03 AM UTC+2, rickman wrote:
On 7/22/2016 11:35 PM, Allan Herriman wrote:
On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:

It's 2016 and I still have to write out most of my code at very low
levels of abstraction like I did ten years ago. Whenever I hear
about a new tool that supposedly converts C to gates, I don't even
look into it, because I can't even get Verilog to synth properly.

My latest example: I needed to reduce an 12-bit number, mod-24.

input [11:0] x;
always@(posedge clk) xmod24 <= x%24;

When I put this in Vivado, what do I get? 40 LUTs (plus some carry
chains) and 10 levels of logic. TEN. Needless to say, that won't
meet timing at 350MHz, especially when it involves getting on and off
a bunch of little carry chains.

So then I have to go down a level of abstraction:

input [11:0];
// x%24 = 8*(floor(x/8)%3) + x%8 always@(posedge clk)
xmod24 <= {x[11:3]%3, x[2:0]};

Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't
have
to instantiate primitives, like I still often do, even though it's
2016.

Needless to say, I am not about to waste a bunch of time trying out
any
new "high-level synthesis" tools.


I find it easy to ignore HLS, but I still suffer from it because it
splits the tool vendors' development budget across multiple tools.


I got all excited when I first heard about high level synthesis.
Then I discovered that the language was C - hardly high level, and
not particularly well suited to the sorts of things that FPGA coders
need to do.
It's not about making a better language though - it's about allowing
non-
FPGA people to do FPGA things, all in the name of market share.

I wouldn't say that. I know when I have heard using C for synthesis
discussed it is more about being able to write the entire project in C
and pick multiple options for the hardware vs. software trade off. I
have no idea how realistic this might be. But I don't think it is
about suddenly having a vast pool of talent to design hardware.

--

Rick C

I attended a Xilinx meeting a couple of weeks ago. They told us that the
new tools (e.g SDSoc) are created for a new pool of engineers, e.g
software engineers, architects, etc. So this new pool of engineers is
also able to design FPGAs. They showed a "nice" slide with a very small
pool of FPGA engineers and a very big pool of software engineers.


Yay, Xilinx development money spent on another tool I'll never use.


In the meantime, I'm using ISE for my Virtex 6 designs (which I have to
support until 2020-something). Xilinx hasn't updated ISE since 2013. ISE
will never support the current versions of VHDL or Verilog. Its bugs
will never be fixed.


I'm sure this makes sense to the people in marketing.

Allan

It is all money. More engineers and companies designing FPGAs, more money for Xilinx, and who cares that the high level synthesis tool does not create the optimal code. How more LUTs are used (by HLS) how more money for Xilinx

The same with VHDL 2008, SystemVerilog is more money than VHDL 2008. And it is your problem that ISE will not be updated even your device is not supported by Vivado

 

[Allan Herriman]

On Sun, 24 Jul 2016 23:48:46 -0700, Devas wrote:

On Saturday, July 23, 2016 at 6:00:03 AM UTC+2, rickman wrote:
On 7/22/2016 11:35 PM, Allan Herriman wrote:
On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:

It's 2016 and I still have to write out most of my code at very low
levels of abstraction like I did ten years ago. Whenever I hear
about a new tool that supposedly converts C to gates, I don't even
look into it, because I can't even get Verilog to synth properly.

My latest example: I needed to reduce an 12-bit number, mod-24.

input [11:0] x;
always@(posedge clk) xmod24 <= x%24;

When I put this in Vivado, what do I get? 40 LUTs (plus some carry
chains) and 10 levels of logic. TEN. Needless to say, that won't
meet timing at 350MHz, especially when it involves getting on and off
a bunch of little carry chains.

So then I have to go down a level of abstraction:

input [11:0];
// x%24 = 8*(floor(x/8)%3) + x%8 always@(posedge clk)
xmod24 <= {x[11:3]%3, x[2:0]};

Now I get 4 LUTs and TWO levels of logic. TWO. At least I didn't
have
to instantiate primitives, like I still often do, even though it's
2016.

Needless to say, I am not about to waste a bunch of time trying out
any
new "high-level synthesis" tools.


I find it easy to ignore HLS, but I still suffer from it because it
splits the tool vendors' development budget across multiple tools.


I got all excited when I first heard about high level synthesis.
Then I discovered that the language was C - hardly high level, and
not particularly well suited to the sorts of things that FPGA coders
need to do.
It's not about making a better language though - it's about allowing
non-
FPGA people to do FPGA things, all in the name of market share.

I wouldn't say that. I know when I have heard using C for synthesis
discussed it is more about being able to write the entire project in C
and pick multiple options for the hardware vs. software trade off. I
have no idea how realistic this might be. But I don't think it is
about suddenly having a vast pool of talent to design hardware.

--

Rick C

I attended a Xilinx meeting a couple of weeks ago. They told us that the
new tools (e.g SDSoc) are created for a new pool of engineers, e.g
software engineers, architects, etc. So this new pool of engineers is
also able to design FPGAs. They showed a "nice" slide with a very small
pool of FPGA engineers and a very big pool of software engineers.

Yay, Xilinx development money spent on another tool I'll never use.


In the meantime, I'm using ISE for my Virtex 6 designs (which I have to
support until 2020-something). Xilinx hasn't updated ISE since 2013. ISE
will never support the current versions of VHDL or Verilog. Its bugs
will never be fixed.


I'm sure this makes sense to the people in marketing.

Allan

 

[Kevin Neilson]

They did claim that software engineers with no hardware experience could be designing FPGAs after a very short training period. Which might have been true. But there's a difference between doing FPGAs and doing them well.

 

[Kevin Neilson]

That's what they like to say. It sounds nice. But software engineers still can't program parallel processor arrays well, let alone FPGAs.

These tools can all make a functional FPGA, but if it uses too many gates and has too many levels of logic, you're better off using software.

 

[rickman]

On 7/26/2016 1:30 PM, Kevin Neilson wrote:
> They did claim that software engineers with no hardware experience could be designing FPGAs after a very short training period. Which might have been true. But there's a difference between doing FPGAs and doing them well.

I suppose the proof of the pudding is in the eating. Who is using this
tool for production in this way?

--

Rick C

 

[Tom Gardner]

On 26/07/16 18:43, Kevin Neilson wrote:

That's what they like to say. It sounds nice. But software engineers still can't program parallel processor arrays well, let alone FPGAs.

These tools can all make a functional FPGA, but if it uses too many gates and has too many levels of logic, you're better off using software.

Be aware that the "high frequency trading" mob put
trading algorithms (i.e if X then buy shares Y)
into FPGAs to shave off the odd millisecond latency.
Obviously development turnaround time for the
algorithms is very important.

That's a good use-case for software->gates.

They've also laid their own $600m trans-Atlantic
fibre optic cable to avoid contention and latency,
and have bought up all the microwave transmission
towers between Chicago and New York because the
speed of light in fibres is noticeably slower than
that in air.

 

[Mark Curry]

In article <5792e5fa$0$2798$c3e8da3$76491128@news.astraweb.com>,
Allan Herriman <allanherriman@hotmail.com> wrote:

I find it easy to ignore HLS, but I still suffer from it because it
splits the tool vendors' development budget across multiple tools.


I got all excited when I first heard about high level synthesis. Then I
discovered that the language was C - hardly high level, and not
particularly well suited to the sorts of things that FPGA coders need to
do.
It's not about making a better language though - it's about allowing non-
FPGA people to do FPGA things, all in the name of market share.

"High Level Synthesis" tools, IMHO are poorly named. Most of the current
incantations don't move the design abstraction level up. Rather, they
force the abstraction LOWER for the software engineering person.

My software team could use HLS tools. They'd have a learning curve to lower
their current abtraction level. They'd need to start "thinking hardware", and
consider the inherent parallelism of hardware.

They're quite capable of this. Problem is they DONT WANT to. They'd prefer
to be moving their software coding to a higher level of abstraction (through
advances is SW languages and techniques). Then leave all these
"fiddly hardware details" to the hardware designers.

For the hardware designers, C (or C++) is a very poor basis for a hardware
description language.

So HLS continues its small market penetration of "unique" designs only...

Regards,

Mark

 

[Kevin Neilson]

I think Celoxica is defunct.

 

[Theo Markettos]

Mark Curry <gtwrek@sonic.net> wrote:

They're quite capable of this. Problem is they DONT WANT to. They'd prefer
to be moving their software coding to a higher level of abstraction (through
advances is SW languages and techniques). Then leave all these
"fiddly hardware details" to the hardware designers.

Indeed. It puzzles me why hardware designers would think that a pile of
nested for loops consist of a high level abstraction.

If we're concentrating on compute to the exclusion of all else (as HLS seems
to), the algorithm might be defined in terms of matrix operations, so surely
it's that which should be the input to the HLS toolchain? In a matrix
multiply, say, the parallelism is inherent and it is friendly to the
programmer: they want to compute matA*matB and all the other details can be
left to the tool to figure out. At the very least it leaves plenty more
scope for the tool to improve, rather than trying to unpick C loops that
represent matA*matB.

Matlab isn't a great language for many reasons, but it does make it possible
to write code with implicit parallelism pretty easily, without even thinking
about it. That would be heading towards my definition of 'high level'.

(I'm not familiar with Simulink-to-gates flows, because I'm not a great fan
of schematics. Perhaps the tools are better in this space)

Theo

 

[Jecel]

On Wednesday, July 27, 2016 at 11:41:11 AM UTC-3, rickman wrote:

On 7/26/2016 8:11 PM, Kevin Neilson wrote:
I think Celoxica is defunct.

So there it is!

Celoxica was a very successful company that was bought out by
a much larger competitor and immediately shut down. This left
many customers who loved the product without any good options.

And this is why I refuse to use non open source tools no matter
what advantages they claim to have. You can't know if they will
still be available tomorrow. The exception (for now) is the
vendor tools for generating the FPGA bitfiles.

-- Jecel