open-sourced FPGA (vhdl, verilog, C variants) design libraries, working toward a GNU (for hardware) paradigm

The GPL defines what source code means:

| The source code for a work means the preferred form of the work for | making modifications to it. For an executable work, complete source | code means all the source code for all modules it contains, plus any | associated interface definition files, plus the scripts used to | control compilation and installation of the executable.

In general, if a HDL source is automatically compiled to hardware via several intermediate netlist formats, only the original file(s) that a human wrote should be considered the source for the purposes of the GPL, since only those are the "preferred form ... for making modifications to it." If the programmer has been using scripts to tweak the intermediate netlist files, then those scripts are also part of the source. If the programmer has been manually tweaking the intermediate netlist files, then the manually tweaked files must also be considered as part of the source, in addition to the original source files.

Solution 1:

Develop high-level languages for hardware design. Make these similar enough to existing software development practices that developers only need a general understanding of hardware optimization techniques (e.g. pipelining, resource sharing, etc.), available hardware resources (e.g. LUTs and BlockRAMs), and how high-level language constructs map onto those hardware resources. Then one hardware engineer can easily train up 10 software engineers to the level of hardware knowledge that they need in order to be able to productively develop efficient hardware using a high-level language.

-- Fergus J. Henderson "I have always known that the pursuit Galois Connections, Inc. of excellence is a lethal habit" Phone: +1 503 626 6616 -- the last words of T. S. Garp.

A lot of people once seriously doubted that we'd ever have full-featured high-quality open-source compilers (GCC, lcc, etc.), operating systems (Linux, *BSD, etc.), office software (OpenOffice, KOffice, etc.), and so on. Those people were wrong.

Open-source efforts like OpenCores, GRLIB/LEON, FpgaC, JHDL, etc. are just the start of a trend that is only going to get stronger as time goes by.

-- Fergus J. Henderson "I have always known that the pursuit Galois Connections, Inc. of excellence is a lethal habit" Phone: +1 503 626 6616 -- the last words of T. S. Garp.

Solution 3:

Several steps are required:

(a) Provide source-level hardware resource profiling, so that developers using high-level languages for hardware design can determine how much each part of their source code contributes to the overall resource costs.

(b) Provide documentation of recommended HLL idioms for generating efficient hardware.

(c) Ensure that the high-level language used for hardware design has a way of expressing constructs that will map directly down to the each of the available hardware resources, such as LUTs and flip-flops, so that programmers can if necessary manually transform their code to optimize it at a fairly low level without having to switch to a different programming language.

(d) Implement compiler optimizations to perform as many as possible of these transformations automatically, or by means of pragmas or compilation options, rather than requiring the programmer to perform the transformations manually.

-- Fergus J. Henderson "I have always known that the pursuit Galois Connections, Inc. of excellence is a lethal habit" Phone: +1 503 626 6616 -- the last words of T. S. Garp.

Would it be possible to do just the opposite, and create a high-level language that lets a digital designer write efficient, high-performance software the same way he'd design hardware? Because I'd like to become an expert programmer without expending much effort.

Bob Perlman Cambrian Design Works

Wouldn't everyone .. experience gained without the pain, effort and study.

John

Expert \Ex*pert"\ ([e^]ks*p[~e]rt"), a. [F. expert, L. expertus, p. p. of experiri to try. See Experience.] Taught by use, practice, or experience, experienced; having facility of operation or performance from practice; knowing and ready from much practice; clever; skillful; as, an expert surgeon; expert in chess or archery. [1913 Webster]

I'm not suggesting that becoming an expert hardware designer isn't going to take effort. But currently popular hardware design tools are in the stone age in comparison to software design tools. The amount of effort required to implement even very simple functionality in synthesizable VHDL/Verilog is huge -- much higher than the effort required to implement the same functionality in software.

Becoming an expert warrior certainly takes effort, regardless of whether your weapon of choice is a sharpened stone axe or an AK47. But that's not a good reason to stick with stone axes.

-- Fergus J. Henderson "I have always known that the pursuit Galois Connections, Inc. of excellence is a lethal habit" Phone: +1 503 626 6616 -- the last words of T. S. Garp.

Depends what side of the coin you come from when you consider how "powerful" the tools are... Sure you can't use OP in Hardware... but software is getting to be bloatware... that's easy in software as the average PC has a ton of ram to play with.. in real hardware .. as in not RAMS (which are symmetrical and enjoy one transistor, one capacitor per element) there is a real cost per transistor.. and .. although its a stone axe... it hits very often, very fast and always on target :-)

Simon

Software as bloat [well, non-optimised] (which covers a lot of ground nowadays) has in fact been justified by people such as Eric Raymond with the rationale that processor cycles and memory is cheap and getting cheaper.

The issue in hardware (well, reasonably fast hardware) is bloat, by definition, is a bad thing[tm].

Taking a fairly standard for instance, let's implement a simple memory interface, but with a wrinkle; the bus has a *minimum* speed (such as DDR). Now you can't just run it a little slower - the memory devices

*won't work*. For such an application, a thorough knowledge of the interface (and the chips on the other side of the design) is a pre-requisite. It's no good saying do this, then that.

Earlier in the thread, I noticed some compilers automatically register everything. The problem there is now we get resource utilisation problems and we *can't route* and meet our timing criteria.

So, before we get to the 'advanced type of tools such as software has', we must first make them efficient and non-bloating.

Just my $0.02

Cheers

Petes