Digilent FPGA & Handel-C

"Mahmoud" ha scritto nel messaggio

i yet studied VHDL and i would like to study a new language as Handel-C. Do you counsil me VHDL? why?

If you have to choose a C language I would recommend you check out SystemC which might be better on your CV than Handel-C :-) You can download a free event based simulator from OSCI. The userguide contains some examples for VHDL/Verilog designers. I would also check out Opencores's sc2v SystemC to Verilog converter,

Hans.

What's so good about SystemC? :)

: Hans wrote: : > If you have to choose a C language I would recommend you check out SystemC : > which might be better on your CV than Handel-C :-)

: What's so good about SystemC? :)

What's so good about AnythingC?

I have quite strong feelings that whilst a high level language than Verilog/VHDL could be a real boon to FPGA development, C is far from a good prototype form for such a language....

cds

Depends greatly on what the application is that is targeted for FPGA's, and how much freedom is necessary to divide the application between LUT's, on chip microproccesors, and specialized statemachines such as p-code or jave VM's.

For instance writing a pipelined wire speed network stack and application targeted for execution on FPGA's as a combination of logic and a VM is probably SIGNIFICANTLY easier to do in a C based language. Especially since you can use the same source compiled to LUT's, processors and VM's to partition the design in various ways as a late project optimization or to freely move between specific FPGA chips.

Trying to instantate specific forms of logic for a complicated hardware design MIGHT be a bit easier in Verilog/VHDL, while being unable to easily move the same source code to a VM or processor as you optimize the system design or move between target chips.

As with most highly specialized tools, you tradeoff generality and the degrees of freedom in design choices gained using more general tools with a larger implementation space.

uh, in what way is C a higher level language than VHDL anyway?

- Brian

A language is high-level with respect to another if it offers a greater degree of abstraction from the complexities of implementation.

ANSI C is a high-level language with respect to assembler as, amongst other benefits, it precludes the need to worry about registers.

A C-to-FPGA language, taking it here to mean any language that approximates the syntax of ANSI C, is only a high-level language with respect to VHDL when it offers abstraction. An example of such abstraction would be a C tool that compiles to VHDL that hides the need to worry about clocks, or lining up of concurrent operations and pipeline timing.

A language is of a higher level than another if you can obtain the same functionality while being less specific on exactly how you want the functionality to be implemented. It has little to do with the extent to which the code is readable. Theoretically one could design an assembler whose input was flowery prose. It would look like human language, but if you still had to specify (albeit it in rhyming couplet) which variables belonged to which registers, you would have a low-level language.

C syntax is neither inherently high-level nor low level, and its choice for C-to-FPGA compilers is near arbitrary. The important issue is the degree of abstraction, the quality of your compiler, its libraries and the underlying hardware it generates. Whether the code would look better resembling Java or C doesn't seem very relevant.

The Java programming language is a higher level language than ANSI C. On the other hand, JHDL with its java-derived syntax is a lower level language than SRC's MAP compiler with its C-derived syntax.

So: "uh, > >

And I might note that issues like pipelines and state machines flow from the semantics of sequential C syntax depending how a C to FPGA compiler implements that syntax. Pipelines occur naturally in sequential C on all platforms when the statement blocks are in an inverted order, a trick I have used for a few years and offered in C.A.F before. State machines are a natural by product of IF-THEN-ELSE sequential statements in any looping construct such as WHILE.

It is much more natural to implement pipelines and state machines in C this way for people trained in sequential languages as the results are visually obvious and timing free. You get the advantage of being able to move the same code, between a variety of execution targets, which traditional HDL's limit.

: uh, in what way is C a higher level language than VHDL anyway?

I guess that's a bit like comparing apples and oranges if we are talking about the *synthesizable* part of VHDL. Actually you've got me sat here scratching my head trying to decide now.

There are constructs that aren't present in VHDL / or don't synthesize that I consider a higher level - e.g. things like C structs allow many variables to be passed around between areas of C code, without everything area (function) having to be upadated if (for example) extra variables are added to the struct. I don't think VHDL has such a neat, clean way of doing this.

As I said before 'Why AnythingC' - I don't think it's high enough 'above' VHDL to make the pain of using a sequential orientated language for programming FPGAs worth while.

It is good for hiding the truth about and FPGA implementation from a C programmer, but weather that is in anyones benefit...

cds

The truth is that it isn't in most ways. Java, C++, and other object oriented languages are. C started out it's origins a "The B programming Language"

which was barely a step above assembly language on many of the small machines it was implemented on. As B evolved into C, it also replaced thousands of lines of assembly language, at little additional costs in size or performance.

A good systems programmer codes C line for line with the accuracy of programming in assembler. That skill will continue as people use C syntax HLL's and HDL's to generate high performance circuits on FPGA's, and for these people the efficiency arguments of VHDL/Verilog in comparison to C subset languages will be moot. For a pure C syntax HDL list Handel-C there is very little difference between the results that a skilled engineer can get in comparison to VHDL/Verilog, and even that will diminish over time as the C based HDL's get the synthesis hints down pat that mature VHDL and Verilog tools implement today.

That the language is sequential, doesn't mean that the resulting netlists are. This is certainly clear in FpgaC as long forward dependencies rapidly create deep combinatorial chains. In both VHDL/Verilog and C subset systems, you have to manually intervine to break the combinatorial chain into a pipeline. In C, we do this by inverting blocks of statements, and in VHDL/Verilog we do that by forcing the instantiation of FF's. Both are done by coding style hints. In C the results are clearly natural, and less likely to be error prone by accidentally inferring a FF which is a common error in VHDL/Verilog.

Otherwise, the netlists from boolean's and arithmetics are functionally identical between all these languages as far as synthesis goes ... with the only differences being maturity, not issues of syntax limiting the synthesis. Ditto for data paths, and state machines.

The only real difference is the ability to directly influence I/O specific features, which the C based tools MAY choose to defer to things like UCF files.

That is a good thing, as the size of the current FPGA market is stalled by the number of engineers that can write VHDL/Verilog and their productivity.

Increasing the size of the FPGA market, to drive costs down for all types of projects, is significantly tied to using programming talent for all kinds of FPGA projects, including the new market of reconfigurable computing which VHDL/Verilog poorly addresses with the lack of VHDL/Verilog trained engineers that also understand software level system designs. This free's up EE design talent to design hardware, by transfering the back end of the project to software engineers with Computer Engineering or Computer Science degrees.

More and more, software engineers will be a major player in FPGA product selection teams. FPGA companies which violate the sensibilities of software engineers by providing hardware only design tools, or licenses which are not open source friendly, or overly restrictive EULA's, will find that they may frequently loose design wins without a clear understanding why. FPGA companies may have established loyalties with the EE's, but that will not be enough to ensure design wins when software developers are also part of the product selection team. This single factor could change the entire face of the market in as little as 5 years.

EE's may complain ... but the market is changing, and whining about it will not stop it.

I don't think so - at least the job market for HDL engineers seems much smaller today than it did in the late 90's. I think the limitation on the FPGA market is the cost of the things, compared to more volume-appropriate ways of implementing the same functions.

Seems to me like the real issue is that FPGA's are much bigger, and hence more expensive to manufacture, than other ways of getting many jobs done. Process gains make the FPGA's cheaper, but they also make other solutions cheaper too - and may make it logical to do something in software that needed hardware previously.

Yes, if you are going to market an FPGA as a general purpose dynamically configreable processing element then it needs to have a programming manual like that of a processor, or some other method of supporting just-in-time compilation. Right now most FPGA's are marketed more for the "ASIC in hours or minutes" application. To really go after a new market, the whole structure of the tool/silicon/IP matchup would have to be reconsidered.

In vhdl, this is called a record, and records work fine for synthesis. See type retime_t in the reference design below.

A vhdl single process design can also handle variables "to be passed around between areas of code". Note how the variable TxState_v is accessed by the both of the procedures cpu_regs and tx_state in the reference design below.

I enjoy the pain, but you can already do this with a plain-vanilla vhdl synchronous process.

-- Mike Treseler

Yes - also I believe VHDL is matching a full "include" mechanism, wheras both C and Verilog have this. Perhaps it's abusive to do so, but that can be used to abstract out all sorts of stuff.

er, s/matching/lacking

: In vhdl, this is called a record, and records work fine for synthesis. : See type retime_t in the reference design below.

: A vhdl single process design can also handle variables : "to be passed around between areas of code". : Note how the variable TxState_v : is accessed by the both of the : procedures cpu_regs and tx_state : in the reference design below.

:

Hi Mike, Once again I stand corrected and wiser - thanks for the example!

Now if only there was an include statement as well to let the shared definitions reside in a seperate file...

Cheers, Chris

The downside is that a preprocessor allows a new category of bugs that are immune to regression testing at simulation time.

-- Mike Treseler

cpp works fine on non-c text files. Shouldn't take too much hacking if you use make rather than a gui.

-- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.

to which the obvious answer would be to compare the synthesizable subset of VHDL with the synthesisable subset of C ;-)

Records.

There's nothing fundamentally not-synthesisable about them, though tool support may be spotty.

They aren't quite as useful as I would like, because (AFAIK) all elements in a record must share some characteristics like port directions; e.g. address and strobe can share a record (they are both outputs from my module), but data (bidirectional) and ack (input) cannot.

But port directions would pass over the head of something C-like anyway.

I'm a long way from convinced it's _as_ high.

If you need a sequential oriented language - it's right there in VHDL; just don't leave the current process.

If you need to support concurrency, I wouldn't choose C.

If you need to cleanly separate interfaces and implementations, I wouldn't choose C.

If you want to perform arithmetic on access types (aka pointers), I grant you, that's another matter...

All that being said, I wouldn't like to write a word processor in VHDL. But even that could be argued that's a compiler and library issue, rather than a language issue.

- Brian