high level languages for synthesis

Jan Panteltje wrote:
> 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'!!

Hardly ... been there, done that, and know better .... having written
FpgaC versions of both the RC5 and AES engines using loop unrolled
pipelined code. Both projects brought out problems where FpgaC didn't
implement things right, or did a poor job ... both of which provided
the insights about what needs to be added to FpgaC or fixed, in Beta-3
and Beta-4 this fall.

It's also why I used this thread to ask for specific examples of things
that are difficult to express in C ... to continue that process.

> This is because these algos actually come from a hardware philosophy,
> can be made easily with gates... Not 'sequential C code like' at all.

BEEP .... wrong. The Algos are frequently math based, first implemented
in C, and later ported to hardware.

> Well that is my experience with my cracker...

I've done my share of cracking since the early 1970 ... including a
major achidemicly sponsored two years of machine level disassembly of
an XDS940 derivative operating system and significant identification of
both implementation and architectural design flaws that were
exploitable for kernel level access. Ditto with reverse engineering of
a number of other projects, and an equal interest in crypto cracking at
a number of levels.

> 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.

I think that running linux as netlists is crazy, .... building FPGA
computers with embedded hard/soft cores that run linux, is well,
natural progression.

Jan Panteltje wrote:
>>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.

When I say painful I'm mostly speaking of the turnaround time
from source change to test. 30 minutes to try something else
on actual hardware -- from a software development point of view
that's a lot of time. From a VHDL developer depending on the
project that can actually be considered *fast*...I just wish the
build process wasn't so slow. It's like batch processing again.

VHDL development itself *won't* be painful. I'm not familiar
enough with it yet so it's a little slow going. But this is as you
say just part of paying the price for learning a new skillset.

> 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.

I'm glad you mentioned that it is fun. It was very fun doing
that work. This stuff to a lot of people is just work. VHDL
and FPGA stuff is a taste of the wonder and joy of discovery
I had when I was 10 and learning 8080 assembly language.

The last time that fun with learning occurred was when I was
doing some OpenGL programming for the first time.

Anyway to get back onto the subject, what would be really
cool is if you could just code your program in 'c' or whatever
language, and some magical development tool would break
it up into stuff to go onto an fpga and even if that takes hours
to build, you only have to do it *once*, and it is guaranteed to
work the first time. Then the masses would be able to use
this technology for day to day stuff.

-Dave



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

David Ashley wrote:
> Anyway to get back onto the subject, what would be really
> cool is if you could just code your program in 'c' or whatever
> language, and some magical development tool would break
> it up into stuff to go onto an fpga and even if that takes hours
> to build, you only have to do it *once*, and it is guaranteed to
> work the first time. Then the masses would be able to use
> this technology for day to day stuff.

The whole goal of creating an ANSI syntax and semantics C out of the
FpgaC project is exactly that. Design, test, debug, in a normal "C"
environment, and run under FpgaC on FPGA's. It's gone a little slower
than I would like, as few people have good skill sets to join the "fun"
doing the FpgaC development at this stage, and I have late life kids
still in school to support.

fpga_toys@yahoo.com wrote:
> The whole goal of creating an ANSI syntax and semantics C out of the
> FpgaC project is exactly that. Design, test, debug, in a normal "C"
> environment, and run under FpgaC on FPGA's. It's gone a little slower
> than I would like, as few people have good skill sets to join the "fun"
> doing the FpgaC development at this stage, and I have late life kids
> still in school to support.

I'm interested in this FpgaC. I don't want to avoid VHDL, but I'm
interested in improving the development tools + approaches.

One of the Neal Stephenson books, or more than one, makes an
interesting point about the concept of metaphores. Or it could
be an Eric S Raymond essay like at first there was the command line...

Anyway there are lots of programmers that use their HLL and never
lift the hood and to them the behind the scenes work is magic or
voodoo. I like looking inside and knowing how it works. Not everyone
needs to know the low level details -- but if you happen to be
comfortable/competent in all the different levels, you can really be
effective in solving problems or devising solutions.

So an FpgaC type approach, as in an HLL that takes care of all
the nitty gritty details and yet does an effective job (compared to
hand coding VHDL) would be a good thing.

In the 80's I used to program the Amiga computer, and I worked only
in 68000 assembly language. There were compilers, like Lattice and
Manx Aztec C, but I couldn't stand them. Why? Because the coding
turnaround time was so sloooow... I could make a change to my ASM
code and try it in seconds or fractions thereof. A compiler would take
10X longer. That adds up.

However computers got faster. Compilers got faster. Generated code
got better. System architectures got more optimized for compiled
code. I learned 'c'. All the code I wrote in 68000 assembly language
is basically...lost. It has no life now. So I'm no longer an ASM zealot.
But *at* *the* *time* it was ok to be one, and it happened to work.

So I wouldn't go back to ASM only, but I use ASM when it's appropriate.
Nowadays you do first pass in HLL then if speed/optimization is a
concern you just do small pieces in hand coded ASM -- a tiny fraction.

The parallel as previously mentioned by others between ASM and
HLL development seems to match exactly with VHDL/Verilog and
...what? Something that may not exist yet but ought to. Maybe it's
FpgaC.

So is there a web site for this or something?

-Dave



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

On a sunny day (25 Aug 2006 11:36:16 -0700) it happened fpga_toys@yahoo.com
wrote in <1156530963.995508.197810@i3g2000cwc.googlegroups.com>:

>FpgaC versions of both the RC5 and AES engines using loop unrolled
>pipelined code. Both projects brought out problems where FpgaC didn't
>implement things right, or did a poor job ... both of which provided
>the insights about what needs to be added to FpgaC or fixed, in Beta-3
>and Beta-4 this fall.
>
>It's also why I used this thread to ask for specific examples of things
>that are difficult to express in C ... to continue that process.
>
>> This is because these algos actually come from a hardware philosophy,
>> can be made easily with gates... Not 'sequential C code like' at all.
>
>BEEP .... wrong. The Algos are frequently math based, first implemented
>in C, and later ported to hardware.


Well, I agree with many things you say, many things have different angles
too (BTW I am pretty conversant still with 8080 or Z80, even wrote a CP/M
clone for Z80, in asm of course ;-)
 http://panteltje.com/panteltje/z80/index.html
that was just in a holiday... was fun, ran Software Toolworks C, more a
subset of modern C...) , but as far as for example DES goes, it was really
designed so it could be implemented in hardware for fast real time crypto,
at least that is the way I understood it, just a diagram with gates...

Sure you can make fine encryption with math.. that exists, better for 
a normal PC.

I have some time ago downloaded FPGA-C, but did not get around to try it
yet.
It could be interesting to for example take the ffmpeg H264 encoder C code
and generate HDL? Would that work?
That would be an acid test for me, if it could do that.
 
But it would perhaps take some fun out of figuring out how to do it
in Verilog, would be _very_ fast time to market for a video encoder....

Would have to be GPL too.

But however you slice it, C executes code sequential.
FPGA can have many circuits working in parallel.

Seems to me as a high level language you would want something more
object oriented? FPGA-C++ ? I do not like C++....
I just have to try that FPGA-C some time I think, else it is philosophy
only...
Maybe some project will come up.

Jan Panteltje wrote:
> But however you slice it, C executes code sequential.
> FPGA can have many circuits working in parallel.

Actually that concept is wrong, the truth is that C resolves back
references using a sequential model, of last assignment must be
preserved, but that is true in hardware too ... whatever last sets a
memory cell or FF is it's defacto state.

C as a language syntax, and symantics makes ABSOULUTELY no claim as how
the implementation may, or may not, use concurrency whereever possible
to accellerate the algorithm specification. So, just as multi-issue
pipelined processors are free to reorder execution of some machine
code, the compiler is free to reorder, and parallelize the execution of
a C algorithm when executing as netlists in an FPGA.

Some C algorithms are inheriently serial .... memory accesses with
explict memory array referencing, others are not.  Good C coders
interesting in run time performance, understand computer architecture,
and can make reasonable algorithm choices for the target hardware.
Introducing C programing for FPGA execution, just extends the target
architectures a good programmer can exploit.

> Seems to me as a high level language you would want something more
> object oriented? FPGA-C++ ? I do not like C++....
> I just have to try that FPGA-C some time I think, else it is philosophy
> only...
> Maybe some project will come up.

Object Oriented as implemented in most variations assume dynamic
creation of objects at runtime, which is a little difficult with
current FPGA's to dynamically allocate the LUT's and routing to
instantiate run time objects .... when FPGA internal architectures
become openly documented and not locked behind proprietary rights and
stiff NDA then even that will be possible.

David Ashley wrote:
> The parallel as previously mentioned by others between ASM and
> HLL development seems to match exactly with VHDL/Verilog and
> ...what? Something that may not exist yet but ought to. Maybe it's
> FpgaC.
>
> So is there a web site for this or something?

http://sourceforge.net/projects/fpgac

The first beta is generally usable on most of the TMCC platforms, as I
tried not to break much. The beta-2 cut broke a few things in
VHDL/Altera for the new extensions, none of which are difficult to fix,
and will hopefully get some attention this fall.

it's mostly usable for older Xilinx devices where it's possible to
hijack an XNF to EDIF conversion using earlier Xilinx releases. I
target most Virtex, Virtex-E, Virtex-2, and Virtex-Pro parts using
xnf2edf from ISE 4.2, then use ISE 6.2i to build with, all with command
line tools under Linux. Use xnf2edf.exe under wine, and native Linux
ISE 6.2i. Some things currently work amazingly well, and others are
mediocre at best, but there are clear ways to fix those.

See what's checked into SVN ... it's a bit more current. Fixes, help,
comments always welcome. There are several of us doing development
around time demands for work, families, etc ... but I mostly carry it.
I have several major changes, including a new symbolic boolean solver
in my personal development tree that will be checked soon. The LUT-4
based truth table design is fast, but produces relatively poor
technology mappings .... and doesn't scale with the 2^N nature of truth
tables, and the QM sum of products back end.

It's certainly not product yet. But I can see it reaching that by year
end -- with the Beta-4 release goals.

Have fun!

> When I say painful I'm mostly speaking of the turnaround time
> from source change to test. 30 minutes to try something else
> on actual hardware -- from a software development point of view
> that's a lot of time. From a VHDL developer depending on the
> project that can actually be considered *fast*...I just wish the
> build process wasn't so slow. It's like batch processing again.
That's also where simulation can be such a powerful tool.  You can check out 
and verify a whole heck of a lot and (if you have a testbench coded) 
automate the regression testing.  I'll agree with the 30 minute turn around, 
but those are also for what I would call the relatively simple changes (i.e. 
the DOH...bonehead! ones that everyone makes at times) since most of that 30 
minutes is chewed up by the build time and not the actual debug/analysis/fix 
effort.

> Anyway to get back onto the subject, what would be really
> cool is if you could just code your program in 'c' or whatever
> language, and some magical development tool would break
> it up into stuff to go onto an fpga and even if that takes hours
> to build, you only have to do it *once*, and it is guaranteed to
> work the first time. Then the masses would be able to use
> this technology for day to day stuff.
Synthesis tools (and software compilers) do that today and always 
have....well, almost.  You go through the build process and the FPGA (or 
software program) is guaranteed to work exactly as you stated that you 
wanted it to do....an alternative definition of a 'bug' is when what you 
wanted (i.e. the specification) is not what you said you wanted (i.e. the 
source code that you fed into the compiler/synthesis engine).

'Works as designed' is a given (except for the occasional bugs that pop up 
in the compiler/synthesis tool itself).  'Works as intended' is another 
thing entirely where the right language (whatever that may be) and a skilled 
user/designer are probably the biggest aids in minimizing the gap between 
'as designed' and 'as intended'.

I know, I'm just stating the obvious here ;)

KJ 

KJ wrote:
> 'Works as designed' is a given (except for the occasional bugs that pop up
> in the compiler/synthesis tool itself).  'Works as intended' is another
> thing entirely where the right language (whatever that may be) and a skilled
> user/designer are probably the biggest aids in minimizing the gap between
> 'as designed' and 'as intended'.
>
> I know, I'm just stating the obvious here ;)

yes, and it can not be said enough times. The turning point is a
complexity * (probability of mistake) product which predicts the likely
hood of making errors.

When you build circits a bit at a time, then a 2M bit device will have
a development error rate of 2M times the probablity of a bit programmer
error. If those 2M bits are better described as 50 lines of HLL, the
error rate is a different product based on 50 times the probablility of
an HLL coding error. This second probablility can be relatively low, or
in some cases very high too (such as a C programmer writing their first
complex Lisp). In addition, debug time is directly proportional to
expression size ... looking for a needle in a haystack problem, vs
sorting thru 50 pins.

HLL's tend to leverage smaller well defined complexity, to produce
lower over all system probablility of error.

On a sunny day (26 Aug 2006 13:48:18 -0700) it happened fpga_toys@yahoo.com
wrote in <1156625298.673980.153570@i42g2000cwa.googlegroups.com>:

>When you build circits a bit at a time, then a 2M bit device will have
>a development error rate of 2M times the probablity of a bit programmer
>error.

When you build circuits a bit at the time (like electronic circuits),
then you also test these.
That leaves you with a good library of circuits.
Combining these is merely interconnecting.
At such a point already 'what language' becomes highly irrelevant.
This works in electronics designs, this works in software coding, and this
works in HDL coding.
For example I have a good UART, LCD driver, and quite a few other modules
(or 'bits' if you will), and can just wire these together.
You cannot just multiply errors, as especially in these smaller modules
there are either no errors, or extremely few. Overview of these
smaller pieces is simpler, allowing you to optimise and debug in a better way.
Over the years you end up with a good library that is tested and bug free,
_reducing_ the probability of errors.

When I code in C (in Linux mainly) I _always_ use pieces of software I
wrote, cut and paste is easy.
Why re-invent the wheel every time? Or why let a program re-invent the wheel,
with all uncertainties it brings?