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 c
an'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
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
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.
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.
On the down side, I did run into occasional issues with the framework and i
t's harder to debug in hardware since the compiled version is pretty obfusc
ated. The module inputs are there but other combinatorial glue logic and in
ner wires had random names.. tried to fix that but ran into framework issue
s with wire/register naming. It might be doable or I might have used it imp
roperly but this was a hobby project and I did not have too much time to pu
t into it.
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.
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();
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
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.
(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.
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
So HLS continues its small market penetration of "unique" designs only...
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
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)