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

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.

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.

to instantiate primitives, like I still often do, even though it's 2016.

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

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.

I was pretty happy with Chisel for programming at a higher level. It's in S cala so it's a good blend of type safe but powerful and easy to write. It a lso 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.

n-

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.

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?

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

n-

I attended a Xilinx meeting a couple of weeks ago. They told us that the ne w tools (e.g SDSoc) are created for a new pool of engineers, e.g software e ngineers, architects, etc. So this new pool of engineers is also able to de sign FPGAs. They showed a "nice" slide with a very small pool of FPGA engin eers 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

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)

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 :(

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.

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.

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

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.

"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

I think Celoxica is defunct.

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

So there it is!