high level languages for synthesis

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:

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:

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.

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 snipped-for-privacy@yahoo.com wrote in :There is a reason the software world doesn't allow

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.

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.

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 wrote in :

....

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.

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.

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

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

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.

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.

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.

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

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.

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

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.

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

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 snipped-for-privacy@yahoo.com wrote in :

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 ;-)

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.

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.

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.

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!

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.

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

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 snipped-for-privacy@yahoo.com wrote in :

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?