high level languages for synthesis

Hi,

What is your opinion on high level languages such as systems C, handel-C 
etc. for FPGA development instead of VHDL/Verilog?

Sanka

Sanka Piyaratna wrote:
> Hi,
> 
> What is your opinion on high level languages such as systems C, handel-C
> etc. for FPGA development instead of VHDL/Verilog?
> 
> Sanka

Gulp.

I've just embarked on trying to master VHDL, and now
you're telling me there's something easier. Doh!

-Dave
PS I don't think I answered your question.

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

David Ashley schrieb:

> Sanka Piyaratna wrote:
> > Hi,
> >
> > What is your opinion on high level languages such as systems C, handel-C
> > etc. for FPGA development instead of VHDL/Verilog?
> >
> > Sanka
>
> Gulp.
>
> I've just embarked on trying to master VHDL, and now
> you're telling me there's something easier. Doh!
>
> -Dave
> PS I don't think I answered your question.
>
> --
> David Ashley                http://www.xdr.com/dash
> Embedded linux, device drivers, system architecture

no C is not answer.
sure some C to FPGA tools work pretty nicely.

I think the ability to use any HDL if required is a bit +
quite often some imported IP is in the "other HDL"
so you cant do it all in single language. and always
rewriting from one into another isnt also an option.

Antti

I wouldn't bother, the abstraction added is not sufficient above
properly written HDL to warrent the extra step.  To get reasonable
implimentation you will end up writting "C" in such a limited form it
won't help you much.


Sanka Piyaratna wrote:
> Hi,
>
> What is your opinion on high level languages such as systems C, handel-C
> etc. for FPGA development instead of VHDL/Verilog?
> 
> Sanka

kayrock66@yahoo.com wrote:
> I wouldn't bother, the abstraction added is not sufficient above
> properly written HDL to warrent the extra step.  To get reasonable
> implimentation you will end up writting "C" in such a limited form it
> won't help you much.

Certainly not for several reasons.  First, the coding in VHDL/VERILOG
can be MUCH MUCH of a worse style, especially building FSM's awkwardly
in VHDL/Verilog that are a natural nesting of If-then-else wrapped in
natural for/while/do loops. Secondly, process style coding in VHDL
isn't that different then C to start with, and lacks the horrible VHDL
verbosity and constructions. Third, I'd like to see what applications
you think this is true for ... it may well mean you need to think in
other ways. Give some examples.

BTW ... see the examples in the FpgaC projects current SVN directory. I
will be adding several more, as well as completing the PCI core project
once some limitations of the Beta-2 release are fixed shortly. I'm
currently coding a symbolic boolean solver to replace the truth table
form we got from the TMCC project that will do a much better job of
technology mappling and allow better time/space tradeoffs for
combinatorials. Some of the examples I will be rewritting in a more
natural form soon, taking advantage of soon to be release features in
Beta-3 and Beta-4 this fall.

I agree some of the examples are just as twisted as VHDL/Verilog
designs, just to make sure what is instantiated is a pipelined high
performance bit stream. Many of these tricks can be equally well used
in Handel-C or Streams-C, and not that unlike the VHDL/Verilog
constructs to do the same thing.

After having read several PCI core implementations in VHDL and Verilog,
I can clearly say they are MUCH MUCH harder to understand, and not
nearly as clear and concise as the C version prototype I currently have
as a work in progress example.

Antti wrote:
> no C is not answer.
> sure some C to FPGA tools work pretty nicely.
>
> I think the ability to use any HDL if required is a bit +
> quite often some imported IP is in the "other HDL"
> so you cant do it all in single language. and always
> rewriting from one into another isnt also an option.

I'm always open to practical examples where someone thinks VHDL or
Verilog is clearly the ONLY solution, or even the best solution. First
I'd like a chance to consider what is wrong with FpgaC today, and what
might be done better in future releases as it matures. As FpgaC matures
over the next year it would be very nice to get rid of the bad warts.

At the same time, I believe that many applications are justified
applications of Handel-C, StreamsC, SystemC, or even FpgaC as it
matures. Writing VHDL/Verilog largely has all the same complexity and
long term maintainence problems that writting structure assembly
language has for the software world. Likewise, moving up the ladder to
HLL's like C which have good hardware targeting will bring hardware
design up a notch in reliability and long term maintainability that the
software world saw in abandoning assembly language, and even C level
coding today.  Allowing hardware designers to design at TTL building
block level creates unnecessary complexity in the design expression
that is prone to costsly error introduction, if not  for the original
designer, certainly for less skilled engineers that are required to
support the design for the product life.

Unfortunely, hardware engineers frequently build unnecessary design
complexity into a project, by having "fun" doing binary design level
implementations, rather than abstract process level data flow and FSM
construction using higher level language abstractions that are easier
to design with, less error prone, and much more supportable by a larger
class of engineers. There is a reason the software world doesn't allow
software engineers to write production programs in native machine
language ones and zeros, or even use high level assembly languange in
most cases .... and increasingly not even low level C code.  The time
for allowing engineers to design hardware at the ones and zeros binary
level is passing too as the tools like System C emerge and produce
reasonable synthesis with co-design.

On a sunny day (24 Aug 2006 23:20:57 -0700) it happened fpga_toys@yahoo.com
wrote in <1156486857.335345.201150@i3g2000cwc.googlegroups.com

>:There is a reason the software world doesn't allow
>software engineers to write production programs in native machine
>language ones and zeros, or even use high level assembly languange in
>most cases .... and increasingly not even low level C code.

There are many many cases where ASM on a micro controller is to be preferred.
Not only for code-size, but also for speed, and _because of_ simplicity.

For example PIC asm (Microchip) is so simple, and universal, and
there is so much library stuff available, that it is, at least
for me the _only_ choice for simple embedded projects.
No way 'C'.
Yes hardware engineers add sometimes great functionality with a few lines of
ASM or maybe Verilog, cool!

I guess it is a matter of learning, I started programming micros with
switches and 0010 1000 etc, watch the clock cycles.. you know.
Teaches you not to make any mistakes, as re-programming an EPROM took
15 to 20 minutes erase time first...  
Being _on_ the hardware (registers) omits the question of 'what did that
compiler do', in many cases gives you more flexibility.
C already puts some barrier, special versions of C for each micro
support special functions in these micros....

But from a 'newcomer' POV perhaps coding part of a project in a higher
level language... but hey...

In spite of what I just wrote .. anyways why wants everybody all of the
sudden Linux in FPGA? So they can then write in C?
Have it slower then in a cheap mobo ?

Ok, OTOH I appreciate the efforts for a higher level programming, as long
as the one who uses it also knows the lower level.
That sort of defuses your argument that 'engineers need less training' or
something like that, the thing will have to interface to the outside world
too, C or not.
 
>The time
>for allowing engineers to design hardware at the ones and zeros binary
>level is passing too as the tools like System C emerge and produce
>reasonable synthesis with co-design.

Much more important then _how_ it is coded is the design, idea, behind it.
Yes one sort of paint may give better results then an other painting the
house, but wrong colors will be wrong with all kinds of paint.
If it becomes a fine line, like art, then it is the painter not the paint.

Jan Panteltje wrote:
> On a sunny day (24 Aug 2006 23:20:57 -0700) it happened fpga_toys@yahoo.com
> wrote in <1156486857.335345.201150@i3g2000cwc.googlegroups.com
> 
> 
>>:There is a reason the software world doesn't allow
>>software engineers to write production programs in native machine
>>language ones and zeros, or even use high level assembly languange in
>>most cases .... and increasingly not even low level C code.
> 
> 
> There are many many cases where ASM on a micro controller is to be preferred.
> Not only for code-size, but also for speed, and _because of_ simplicity.

I just want to contribute my $.02 to this. For years, perhaps 15, since I
heard about FPGA's I've wanted to get involved in them. It's been
absolutely clear to me, with 30 years of computer experience, that
reconfigurable computing has unlimited potential for increasing
computational
power beyond the traditional single thread general purpose cpu model.

A recent article in linux journal talks about doing encryption, AES128 or
something similiar, was 500X faster when done in an fpga VS having the
cpu do it. 500X! That's 9 generations of Moore's law. Yes for the very
specific task of doing this one thing, it speeds up that much, but for
general stuff?

That's not the point. With an ASIC you can do only one thing. But with
an FPGA you can have it do whatever is needed at that moment.

There's a startup I just heard about, forgot the name, but since AMD
just released complete specs on their hypertransport protocol used
in Opterons, this startup is producing FPGA devices that fit on a small
PCB that itself is pin compatible with an Opteron. So you can take a
standard multi cpu server, install one of these instead of an opteron,
and because it "breathes" so well (tens of gigabyte/second IO) you
can really make use of the FPGA. PCI approaches are hampered by
the bandwidth of the PCI bus, BTW. That is, PCI card with FPGA on it
doesn't gain you a lot because the pci bus itself is a choke point.

Finally in my own experience I've seen in the one project I did some
DSP coding, encoding live video to mpeg-2 I frames, I was able to
achieve 60x performance improvement beyond compiled 'c' code
by writing hand coded ASM + making some compromises that no
compiler could ever make, but which a human can easily. It's
similiar to lossy compression vs perfect compression -- the compiler
can only do perfect coding, however if you can do a little math that
is fast and "good enough" accuracy, you can reap huge rewards in
performance. To do *this* kind of performance improvement required
a human. However it's theoretically possible that a compiler could
target an algorithm to an FPGA and achieve a perfect implementation
of the algorithm, yet at 500X the performance, without having to
have human intuition.

So the whole thesis is this:
1) With silicon speed we're running up against limits of how fast
we can operate cpu's at.
2) Special purpose cpus like DSP's can achieve huge performance
improvements, but getting them require tradeoffs a compiler can't
make -- they require human decision making processes.
3) With reconfigurable computing (FPGA's) in theory you can get
massive performance improvements by just implementing the
desired algorithm into the fabric of an FPGA.

So what has to happen is to make it painless for engineers to
be able to use FPGAs as a resource, on the fly, within applications.
If that means using high level 'c' like languages and smart
compilers, and if it's in theory possible, then go for it. Right now
using FPGAs for stuff is very pain*ful* compared to doing the
same thing in software. That's got to change.

NOTE: The cpu manufacturers seem to be heading down the
path of multiple cpu cores, each with its own cache, on the
same chip. Since they can't make 'em faster, start packing
more of them on the die. Software wise they're backwards
compatible, but this just leaves it up to the programming
community to try to optimize their code better for multiple
cores. You don't see a lot of that yet. Multi thread programming
is itself very complicated and a huge source of bugs/lockups/
deadlocks/etc. So to take advantage of that effectively will
probably require delegating thread distribution to the
compiler -- which is similiar to what has to happen with
doing fpga coding with a high level language. What's
really necessary in both cases is for a programmer to just
think in terms of single thread execution, write his program,
and the compiler does the rest...

Someone earlier noted the similarity between fpga coding
now and ASM programming in the past. I agree with this
completely. FPGA use has to move out of the voodoo, priestly
arena it's in get into the hands of the common man.

-Dave


-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

On a sunny day (25 Aug 2006 19:15:47 +0200) it happened David Ashley
<dash@nowhere.net.dont.email.me> wrote in <44ef3043$1_2@x-privat.org>:

....
>So the whole thesis is this:
>1) With silicon speed we're running up against limits of how fast
>we can operate cpu's at.
>2) Special purpose cpus like DSP's can achieve huge performance
>improvements, but getting them require tradeoffs a compiler can't
>make -- they require human decision making processes.
>3) With reconfigurable computing (FPGA's) in theory you can get
>massive performance improvements by just implementing the
>desired algorithm into the fabric of an FPGA.
>
>So what has to happen is to make it painless for engineers to
>be able to use FPGAs as a resource, on the fly, within applications.
>If that means using high level 'c' like languages and smart
>compilers, and if it's in theory possible, then go for it.

It is in my view a bit more complicated.
As you mentioned, we are heading for multi core stuff.
But just that, *exactly that*, is something where you need to work on
the top level.
A recent example is Cell processor.
I have studied Cell now a bit in depth, and there is Linux development
stuff for it (Sony PS3 is coming).
Yet to get the most of it, you have to write your applications so you
assign specific tasks to each 'help processor'.
Do it in C or asm, but you still need to know the hardware structure,
where the bottle-necks are, bandwidth etc...

You mentioned crypto, well I did the crypto thing for brute force with
FPGA, in the end the gain may not be so high, unless you use really
big chips and unfold all loops (DES for example).
When you unfold all loops the Verilog becomes so simple you will _want_
to write in Verilog, not in 'C'!!
This is because these algos actually come from a hardware philosophy,
can be made easily with gates... Not 'sequential C code like' at all.
Well that is my experience with my cracker... 
So all that makes me say: OK if you want sequential code and run
Linux on a FPGA, but like you mention, it is perhaps better to have the
plug in FPGA board for the high speed stuff, with lower bandwidth connection
to a normal processor that runs sequential code and is the perhaps programmed
in C or a higher level language.



>Right now
>using FPGAs for stuff is very pain*ful* compared to doing the
>same thing in software.

No, it is not( ;-) ), use the right tool for the right thing :-), FPGA
is fun, state machines, if you must use them, are not so bad either.

>That's got to change.

[But] You have got to learn.
Maybe you are right, maybe not, but to fly a jet requires training....
Speaking some other languages then your own requires learning.
Maybe one day we have this implant so we can all do this.... speak
25 languages, fly a 747... As you pointed out, in case you really know
the details and start optimising, as in that DSP case, it is fun :-)
But for some it is a mystery, too difficult.
But _you_, by effort, determine what group you are in.

Jan Panteltje wrote:
> There are many many cases where ASM on a micro controller is to be preferred.
> Not only for code-size, but also for speed, and _because of_ simplicity.
>
> For example PIC asm (Microchip) is so simple, and universal, and
> there is so much library stuff available, that it is, at least
> for me the _only_ choice for simple embedded projects.
> No way 'C'.
> Yes hardware engineers add sometimes great functionality with a few lines of
> ASM or maybe Verilog, cool!

Hi Jan, .... one size certainly doesn't fit all, especially where the
tools are poor or lacking.

Having written Asm since mid 1960's in a grand scale on over 30
architectures, I'm certainly not asm adverse when needed. I have
however strongly advocated C since first writing device drivers for
UNIX machines starting in 1975. Learning to write low level "symbolic
asm" in a C compiler is a needed skill for anyone doing machine level
coding optimization. Debugging compilers on new architectures is also
painful, and requires solid skills in machine languages. As does doing
cross architecture operating systems porting, as bringing up both new
hardware and new software tools (asm, linker, compilers, libraries) is
more an exercise in debugging at the machine level than it is high
level design. I made my living do hardware/software at that level for
over 30 years, and still do today.

One the other hand, I've watched to asm bigots fall one by one over the
last 30 years, as entire industries switch from asm coding as the
defacto standard to HLL's. All of your arguments are the same they
made. In the end, the HLL tools mature, reach nearly hand coding
levels, and a slow migration occurs from 100% asm, to 20%, asm after
the first C recode, to 10%, to 5%, to under a small fraction of 1%.
There are minimum machine thresholds where HLL's are viable, and that
isn't an embedded micro with 64 bytes of r/w registers/memory and a few
Kbytes/bits of program rom. On the other hand, the price difference
between a highly capable micro with resources to easily support 99% HLL
coding and a bare bones chip is getting pretty small, and frequently
when you factor devevelopment costs and life cycle maintainence costs
into the cost of the product, the difference is actually negative ....
IE the tiny chip is MUCH  MUCH more expensive in both real costs and
time to market costs as compared to a large micro using HLL development
tools, well trained HLL development engineers, and clean
readable/maintainable well structured C/HLL (such as Forth).

I helped Ron Cain with UNIX resources and design ideas back in the late
1970's to do "Small C' for the micro's of that day ... not pretty asm,
but functional. I've also worked with tiny embedded micro's running
Forth, that knocked off applications in weeks that would have taken
years to debug in asm, if you could get it to fit. I've also done
hardware design for more than 30 years, including more than my share of
PLD work using early PAL's and PALASM level tools. There is a good
reason VHDL/Verilog exist .... and as many good reasons they should not
be the mainstay development tools at the current low level they provide
in two decades from now ... especially for FPGA's.

It's with more than a weekend warriors experience, that I see C on
FPGAs making a huge difference for both hardware design, and
reconfigurable computing.


>
> I guess it is a matter of learning, I started programming micros with
> switches and 0010 1000 etc, watch the clock cycles.. you know.
> Teaches you not to make any mistakes, as re-programming an EPROM took
> 15 to 20 minutes erase time first...
> Being _on_ the hardware (registers) omits the question of 'what did that
> compiler do', in many cases gives you more flexibility.
> C already puts some barrier, special versions of C for each micro
> support special functions in these micros....

I started programming on 4K 1401 card machines, with at most 5-10 test
runs a week. Desk checking was everything ... and having a full work
day between runs pretty much insured it. Program complexity is however
far past what even a good coder can get running in one or two test
cycles these days. So ... been there, done that, and it sucks rocks. As
does large scale bit level design today.

> In spite of what I just wrote .. anyways why wants everybody all of the
> sudden Linux in FPGA? So they can then write in C?
> Have it slower then in a cheap mobo ?

Dunno ... didn't advocate that, especially not for LUT level FPGA work,
as there are not enough LUT's on the planet to implement linux as a
netlist.

> Ok, OTOH I appreciate the efforts for a higher level programming, as long
> as the one who uses it also knows the lower level.
> That sort of defuses your argument that 'engineers need less training' or
> something like that, the thing will have to interface to the outside world
> too, C or not.

First I don't exactly make that arguement, but I do make the arguement
that fewer numbers of engineers need that level of training ...
something that greatly separates the newbie's from the experienced.
Organizationally that makes a huge difference in costs, time to market,
maintainability, and survivability in a global market.

It also means that you don't let experienced designers create job
security by coding at a level only they can maintain, except where
critically necessary and there exists other staff available in house,
or as consultants, to carry the torch long term.