Digilent FPGA & Handel-C

I wouldn't choose VHDL either :)

But it does come down to personal preferrence and what you are used to programming in. The following example compiles in to about a 100 or so LUT/FF's in the beta-2 soon to be released for FpgaC. The WHOLE process block is concurrent, with sequential symantics for variable reuse.

So, we have implict concurrency for pipelining, bit level control for a bit serial design, that maps directly to 3 stages of 9 bits, with input and output ports (which could have had pins assigned as a LOC attribute), and a structured interface description which could be placed in a project include directory for reuse between design files.

So, what's the point other than a religious war of my language is better than your language without an specific metrics other than personal judgement?

/* * BitSer.c - FpgaC Pipelined Bit Serial Sort Example 1 * copyright 2006 by John Bass, DMS Design under FpgaC BSD License * * This example builds a pipelined merge sort for bit serial unsigned * integers, using LUT based multiplexors. The sort happens in log2(N) * stages, with a log2(N) latency thru the pipeline. The muxes each * check the data relationship, and latch the sort mswap mux selector * at the first inequality until endword is seen. * * One variation of this design is to buffer the bit serial words into * LUT rams and return the sorted data on the same I/O pins. In FpgaC * that would be a stage of small arrays for retiming. This would allow * a sorting engine with X pins to sort unsigned bit serial integers of * length N in time 2*N clocks, and a latency of N clocks. * * Another variation of this design is to fill the FPGA with additional * stages and make the internal sort wider than the available I/O pins * in support of a much larger streaming sort with multiple passes. The * additional array memory and sorting muxes would form a bubble sort * that would carry that many words down thru the stream. * * Other variations are changing the word flag to the first bit, to clear * the mux selectors. */

/* * Pipeline 8 streams of bit serial data words */ struct stage { int s0:1; // stream 0 int s1:1; // stream 1 int s2:1; // stream 2 int s3:1; // stream 3 int s4:1; // stream 4 int s5:1; // stream 5 int s6:1; // stream 6 int s7:1; // stream 7 int endword:1; // sentinal to reset mux selector, active high } in, p1, p2, out; // pipeline stages

/* * Setup I/O port mapping */ #pragma inputport (in.s0) #pragma inputport (in.s1) #pragma inputport (in.s2) #pragma inputport (in.s3) #pragma inputport (in.s4) #pragma inputport (in.s5) #pragma inputport (in.s6) #pragma inputport (in.s7) #pragma inputport (in.endword)

#pragma outputport (out.s0) #pragma outputport (out.s1) #pragma outputport (out.s2) #pragma outputport (out.s3) #pragma outputport (out.s4) #pragma outputport (out.s5) #pragma outputport (out.s6) #pragma outputport (out.s7) #pragma outputport (out.endword)

/* * Define C Preprocessor macro for basic sorting mux engine */ #define mux(stagein, stageout, s1, s0) { \ int mlatch:1, mswap:1; \ if(~mlatch & (stagein.s1 ^ stagein.s0 )) { \ mlatch = 1; mswap = stagein.s0; \ } \ if(mlatch && mswap) { \ stageout.s1 = stagein.s0; stageout.s0 = stagein.s1; \ } else { \ stageout.s1 = stagein.s1; stageout.s0 = stagein.s0; \ } \ if(stagein.endword) \ mlatch = mswap = 0; \ }

/* * An FpgaC process is started up when the bitstream is configured * and processes implicitly loop forever */ process Sort() {

/* * To build a pipeline, we describe the last stage first, * and the first stage last. Thus as execution proceeds * logically down this procedure, stage n gets it's data * form stage n-1 below till we get to the device input */

// Pipeline Stage 3: Sort stage 2 to output pins

mux(p2,out,s7,s3);mux(p2,out,s6,s2);mux(p2,out,s5,s1);mux(p2,out,s4,s0); out.endword = p2.endword;

// Pipeline Stage 2: Sort stage 1 to stage 2

mux(p1,p2,s7,s5);mux(p1,p2,s6,s4);mux(p1,p2,s3,s1);mux(p1,p2,s2,s0); p2.endword = p1.endword;

// Pipeline Stage 1: Sort input pins to stage 1

mux(in,p1,s7,s6);mux(in,p1,s5,s4);mux(in,p1,s3,s2);mux(in,p1,s1,s0); p1.endword = in.endword; }

Been in TMCC/FpgaC for 10 years .... tristate I/O.

For the last of these points, or all of them? Do you think C's include mechanism is somehow more reliable than use clauses? ... or makes it easier to identify the source of a name-clashing entity?

Just a little bit more than personal judgement; the claim I was questioning was whether C was a higher level language - NOT that it was somehow "better" in someone's personal judgement - which is a matter of preference and familiarity.

(So far the concrete examples of VHDL's failures happen to be things it does fine, like records, or even better than C, like "use" and packages instead of includes, but let's wait and see)

okay... I see lots of instantiation of individual entities, but no higher level abstraction. But I may be missing something.

For example, if n happens to be something other than 8, do you have to re-write it extensively, and get every parameter invocation right in every instance in the new version, or do you change a single generic, and let "generate" do all the work of creating a correct design?

- Brian

Name clashing isn't normally a problem for C programmers, as it generally only happens in global naming, and then relatively rarely.

There are two reference points there, depending on if you are comparing the two by their "highest level of abstraction" or the two by their "lowest level of abstraction", combined with the problem of just what do you consider an abstraction. And a more thorny problem of how you wieght features on that scale.

Clearly VHDL, Verilog, and C are generally equivalent for the basics of booleans and arithmetics as languages (with a few minor hickups).

Real functions, procedures, and the like are one of several higher levels of abstraction that you might judge an HLL over and HDL. The ability of C to partition a design between LUT's (using netlists), Virtual Machines (compiled to pop codes or other VM machine codes), general purpose processors, or even highly specialized parallel processors would generally suggest that the language isn't directly tied to the lowest levels of abstraction which would prevent or hinder such portability, and thus maintain an overall higher level of abstraction.

C has complex state machine functions in the form of looping combined with conditionals and function invocations, which are natural for traditional programmers, and a higher level of abstraction that what you generally have available in an HDL to evoke the same state machine and process flow.

But that is not what I was responding to. What I was responding to was your list of things you were asserting a C based HLL netlist compiler was in your mind significantly poorer at, or completely missing. Concurrency, Bus I/O's, reusable design elements/interfaces, etc ... which are different in C, but not significantly inferror ... as which is best, is clearly a judgement call based on preferences.

We tend to do that in C with scripting. Something I frequently see done for VHDL/Verilog as well to generate optimized arrays of functional blocks. The implict looping functions to replicate arrays of logic blocks isn't generally enough to complete the additional logic that wider or more complex arrays of logic blocks may need, for anything other than a simple bus width change. So, this is a very slight advantage for certain classes of reuable design elements that applications targeted for C don't generally need.

Don't know (I am a VHDL programmer :-), the point I was trying to make is that from a job prospective having SystemC on your CV might be slightly better than having a propriety language like Handel-C. I have no idea which one is better just that I hear more noises on SystemC than on Handel-C.

Regards, Hans.

C is probably not but don't forget that SystemC has all the goodies(?) of an object oriented language and support deterministic concurrency like VHDL. I like VHDL but I do recognise that for high level modelling you need to resort to these kinds of languages. Perhaps one day we get "SystemVHDL" although it seems accellera and the EDA industry have given up :-(

Hans