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

I seriously doubt you see anything much bigger that the snippets on Open Cores. This is may be different in the educational community where open source is much more widely used, but in industry very few would be willing to give away what they spent zillions of man hours developing.

Try going to to nVidia and asking for the source to their logic models of their video chips! Why would they want to give the competitors their design? I understand that a lot of open source is aimed to be portable across many systems. People tend to confuse HDL as 'software'. It is not a program like a 'C' program for a CPU. It is actually describing hardware and often has to use primitives that are only available on certain ASICs, FPGAs, etc. You rarely optimize for portability. When I need to get something running fast, you MUST optimize for the architecture of your medium to push clock speed, etc. The HDL you end up may not be very useful to someone using a different ASIC. Furthermore, many man-hours are spent in this process and most companies are not willing to do this for somebody else's benefit.

One could make the argument that there should be a library for simple constructs that would be common to all FPGA, ASIC platforms. What you would end with is the equivalent of a C library that only adds to numbers. Not very useful for serious work.

In the FPGA world, there are lots of places were you can buy working IP cores that are fully documented and supported. My boss isn't willing to spend 4 times the cost of working 3rd party IP to debug an open source version that isn't documented that well and has no support.

The problem in this model is the same problem with the open source software community. While some of the products are nice, they are plagued with *lots* of useless projects/libraries that take a week to install, have poor documentation and no support. Why would I want to spend my time on that. Most forget that while open source stuff is free , it may take 4 times the time to use. This is only cheaper if your time doesn't cost a whole lot.

All this being said, I really like the open cores site. I would use it for hobby/side projects. As for serious commercial projects, I place more trust in either my own or paid for IP that is tested and supported.

-Eli

g.wall wrote:

I'm using the GRLIB/LEON processor from Gaisler research

which provides a fairly flexible/implementation independent set of VHDL libraries to implement a 32bit SPARC compliant processor.

The project appears popular with the European Space Agency, and LEON based designs keep popping up all over... From satellite applications to network routing.

The library is available under a dual license scheme where a GPLed version is released, but a commercial license is also available. This allows/encourages academic research/playing around (which I confess i'm doing), while also allowing developers to build their own (proprietary) applications on the LEON base. This model makes the whole project much more sustainable than other after-hours hobby type projects.

But it can be tricky applying the GPL to an HDL project, because traditional concepts like source code and binary executables are transferred to a domain with source, several intermediate netlist formats, some of which can be regarded as source when you're wide awake... And distribution of embedded systems is the other ill defined part - most users don't care/know about the embedded configurable logic, and they are unlikely to expand on a very application specific design (as Eli stated above). And what happens when you start combining HDL code with presynthesised netlists? I think a modified (HDL) GPL would be required to accurately cover the issue, much as is done by the GNU Free Documentation License.

In the meantime, if I have a nifty piece of HDL solving a problem, I'll probably post it somewhere, and hope someone else finds a use for it...

johannes

On a sunny day (Thu, 10 Nov 2005 11:24:08 -0500) it happened Eli Hughes wrote in :

Not completely correct, does not Altera has the 7400 TTL library? Is not opencores doing this exactly?

My experience with open source, as a WRITER of open source, is that bug are fixed and replies are within one or 2 days (by me). Some people take weeks to reply-- if at all. YMMV. Some send you a very complicated question you spend ages to figure out, you reply, and then never hear anything.... Some commercial companies have the same pattern, for example Xilinx representatives here. THESE behave almost like it is a favor that you can buy a FPGA. And on the other side of it, lotssoftware community. While some of the products are nice, they are

Ever try to install and run an official MS library? Most open source projects install without problems (on the right architecture). You mean you do not want to think AT ALL? ;-)

Not correct, it does not 4 times the time to use, makes no sense.

Sure, many times I wrote something because it was not there (in Linux). that is how the 50+ applications I released under GPL came about. If it EXISTED I would not have bothered writing it.

Sure a HDL library would be nice, if a university has that, maintains that, then it will benefit everybody, save you money. But if released under GPL-1 the rest of your HDL will likely have to be under GPL too. So, I have heard they are working on GPL-3 now..... do not know details. Software patents should not exist. And yes I admit to keeping HDL secret to protect others copying the design. It is the last border, the last defense! (... capitalism - communism... but maybe we need a synthesis, look at China).

But wait, somebody will invent the (startrek) replicator, and then what.

Yes, but having a TTL library is only useful for doing schematic in Altera's tools, not HDL. Evening thinking in TTL when you have an HDL is counter-productive!

I would agree mostly with this. But, generally for any company that is worth a damn I have never had a problem with support.

Yes, double clikc on icon. Wait a bit. Start programming. My experience with PC/GUI stuff is very limited though. I like to live in the hardware/micrcontroller world where I have control. I do not wish to be encumbered by an operating system which will only get in my way!

Not when it comes to installing and using something. My job is to make a product work, not chasing down 200 dependecies. :-)

You are right though. This has improved.

I prefer not to think. I like to "be still like broccolli".

I should have said: "4x the time to get the same useful result". This isn't always true, but when I pay for something I am paying for documentation. When I have to reverse engineer something to get it to work right I am wasting my time. And when the docs are skimpy, I get angry. This is not true of all open-source software (I love the PHP project, I use php for my web scripts!) but most open source projects are not that organized.

Boy, I wish the replicator existed! Then I could go home. :-)

-ELi

One of the reasons behind starting the FpgaC project on sourceforge was to head in that direction, especially in terms of reconfigurable computing at a hobby level, and small business level as the normal commercial tools are way out of sight, and everybody has a proprietary IP mindset.

For pure digital design, it's frequently pretty difficult to extract meaningful reusable IP, as many cores have such complex interfaces that it's common to have difficulty in fitting them into a completely difference architecture.

For reconfigurable computing, there is a lot of common library code that becomes usable with C based varients, particulary in terms of dynamic reconfiguration, interprocess (hardware threads) communication, and even high level device interfaces (drivers) that can be much more easily reused in various SoC and reconfigurable projects. Even basic OS services for reconfigurable computing are in dire need at this point. And compilers and loader tools that can handle dynamic partitioning and loadable segments. Doing this with ISE and mainstream tools is painful at best.

John

Problem 1.

There are ten times as many software designers as digital hardware designers. The average software guy is much better at setting up repositories, web sites and running regression tests than the average hardware guy. The average hardware guy knows enough HDL to get get by and maybe enough C language to turn on a circuit board. Standard software development processes like source control and code reuse are much less evolved in the hardware area.

Problem 2.

The average software designer couldn't describe two gates and flip flop in vhdl or verilog.

-- Mike Treseler

does that even matter for "reconfig. computing"?

Should have noted that the FpgaC project is still looking for additional developers, and the long term results of this project are still very open to change. It would be great to be able to build a comprehensive set of library that allow typical MPI and posix-threaded applications to build and dynamically load/run on multiple FPGA platforms. And to mature the compiler to handle a full traditional C syntax transparently.

I personally would like to see it handle distributed arithmetic transparently, so that it handles the data pipelining of high performance applications well using data flow like strategies. But that is open to the team as a whole, with inputs from the user community.

The OP asked about open source hardware design libraries, not reconfig. computing.

-- Mike Treseler

Problem 3.

The average software designer couldn't describe two gates and a flip-flop in C (or any other programming language), but would instead describe something that synthesizes to a large collection of gates and flip-flops.

in TMCC/FpgaC (and Celoxica, and a number of other C HDL like tools) what you just asked for is pretty easy, and comments otherwise are pretty egocentric bigotry that just isn't justified.

int 1 a,b,c,d; // four bit values, possibly mapped to input pins int 1 singlebit; // describes a single register, possibly an output pin singlebit = (a&b) | (c&d); // combinatorial sum of products for ab+cd;

I can train most kids older than about 6-10 to understand this process and the steps to produce it. It doesn't take an EE degree to understand or implement.

So beating your chest here is pretty childish, at best.

There is a small setup overhead for the main, but for example this certainly does NOT synthesize "to a large collection of gates and flip-flps" as you so errantly assert cluelessly:

main() {

int a:1,b:1,c:1,d:1; #pragma inputport (a); #pragma inputport (b); #pragma inputport (c); #pragma inputport (d);

int sum_of_products:1; #pragma outputport (sum_of_products);

while(1) { sum_of_products = (a&b) | (c&d); } }

Produces the following default output (fpgac -S example.c) as example.xnf: LCANET, 4 PWR, 1, VCC PWR, 0, GND PROG, fpgac, 4.1, "Thu Nov 10 19:42:27 2005" PART, xcv2000ebg560-8 SYM, CLK-AA, BUFGS PIN, I, I, CLKin PIN, O, O, CLK END SYM, FFin-0_1_0Running, INV PIN, I, I, 0_1_0Zero PIN, O, O, FFin-0_1_0Running END SYM, 0_1_0Running, DFF PIN, D, I, FFin-0_1_0Running PIN, C, I, CLK PIN, CE, I, VCC PIN, Q, O, 0_1_0Running END SYM, FFin-0_1_0Zero, BUF PIN, I, I, 0_1_0Zero PIN, O, O, FFin-0_1_0Zero END SYM, 0_1_0Zero, DFF PIN, D, I, FFin-0_1_0Zero PIN, C, I, CLK PIN, CE, I, VCC PIN, Q, O, 0_1_0Zero END SYM, 0_4__a, IBUF PIN, I, I, a PIN, O, O, 0_4__a END EXT, a, I SYM, 0_4__b, IBUF PIN, I, I, b PIN, O, O, 0_4__b END EXT, b, I SYM, 0_4__c, IBUF PIN, I, I, c PIN, O, O, 0_4__c END EXT, c, I SYM, 0_4__d, IBUF PIN, I, I, d PIN, O, O, 0_4__d END EXT, d, I SYM, 0_10__sum_of_products-OBUF, OBUF PIN, I, I, 0_10__sum_of_products PIN, O, O, sum_of_products END EXT, sum_of_products, O SYM, FFin-0_10__sum_of_products, BUF PIN, I, I, T0_15L49_0_10__sum_of_products PIN, O, O, FFin-0_10__sum_of_products END SYM, 0_10__sum_of_products, DFF PIN, D, I, FFin-0_10__sum_of_products PIN, C, I, CLK PIN, CE, I, 0_13_L21looptop PIN, Q, O, 0_10__sum_of_products END SYM, FFin-0_13_L21looptop, EQN, EQN=((~I1)+(I0)) PIN, I1, I, 0_1_0Running PIN, I0, I, 0_13_L21looptop PIN, O, O, FFin-0_13_L21looptop END SYM, 0_13_L21looptop, DFF PIN, D, I, FFin-0_13_L21looptop PIN, C, I, CLK PIN, CE, I, VCC PIN, Q, O, 0_13_L21looptop END SYM, SYMT0_15L49_0_10__sum_of_products, EQN, EQN=((I0*I1)+(I2*I3)) PIN, I3, I, 0_4__a PIN, I2, I, 0_4__b PIN, I1, I, 0_4__c PIN, I0, I, 0_4__d PIN, O, O, T0_15L49_0_10__sum_of_products END EOF

Go back and read the first line of the first post, and you will clearly see the author included reconfigurable computing in the discussion.

3b, Without realising it.

-jg

The interesting point in this process, is that the tools are evolving to hide design issues that are seldom a worry for typical cases like reconfigurable computing on FPGA compute engines.

Every programmer decides how big each and every variable should be. For a machine that has a few Gigabytes of memory, and a 64bit native word size, using 64bit variable may be either free, or faster as it may not take an extra step to sign extend the memory on register load.

When programmers move to smaller processors, they quickly learn that when programming a PIC micro, that 64bit word sizes just don't work well.

When programmers encounter FPGA compute engines the same processes quickly come into play, and a short mentoring of the newbies to size variables by the bit, or be careful and use char, int, long, and long long properly isn't that difficult, or even unexpected.

if the fpga is a single toy sized fpga, it's no different that programming a PIC micro, as resources are tight, and the programmer will adapt.

If the fpga system is 4,096 tightly interconnected XC4VLX200's and the application isn't particularly large, I suspect the programmer writing applications for this fpga based super computer will not have to worry about fit. If they are fine tuning the bread and butter simulations at places like Sandia Labs, I suspect the programmers will have more than enough experience and skill to size variables properly and be very much in tune with space time tradeoffs for applications far more complex than even a typical programmer would consider.

it's reconfigurable computing projects where libraries of designs become very useful, particularly for SoC designs that used to be an EE design task, and is rapidly becoming mainstreamed that software engineers are the most likely target as the market continues to mature and expand.

There will be some dino's that stand in the tar pits admiring the bits as the sun sets on that segment of their employment history.

Why should a C programmer expect that to synthesize any flip-flops at all? It looks purely combinatorial.

How would you write it if you did NOT want a flip-flop, but only a combinatorial output?

Anyhow, I wasn't suggesting that the language couldn't represent a few gates and a flip-flop. My point is that C programmers don't think in those terms, so anything they write is likely to result in really inefficient hardware designs.

For example, typical C code for a discrete cosine transform can be found here:

But I suspect that code will synthesize to something at least an order of magnitude larger and an order of magnitude slower than a typical HDL implementation.

That doesn't mean that you couldn't write a DCT in C that would synthesize to something efficient; it just means that a normal C programmer *wouldn't* do that. You'd have to train the C programmer to be hardware designer first, and by the time you've done that there's little point to using C as the HDL, since the whole point of using C as an HDL was to take advantage of the near-infinite pool of C programmers.

Eric

Exactly so. It's perhaps less commonly seen in C, since C *only* has low-level constructs, but the vast majority of C++ and Java programmers seem to have no conception of what the compiler is likely to emit for the programming constructs they use.

A former coworker once tried to write C++ code to talk to Dallas one-wire devices. He spend days trying to debug it before someone took pity on him and pointed out that by the time the constructor for one of his objects executed the entire transaction had timed out.

Eric

Actually you are quite wrong on this point. Programmers write tight and efficient code for embedded micro applications all the time.

Exactly the same processes come into play as we mentor programmers on projects that use an FPGA as the compute engine.

Good tools, reasonable training/mentoring, and design standards avoid gross mistakes when they matters.

When they don't, who cares?

So what's the point other than a gross management failure to properly train and mentor the responsible engineers .... maybe so they can beat their chests?

I've seen similar failures with EE's that thought they could write programs just because they learned to code C, or Fortran, or Basic, and then fell flat on their faces trying to implement trivial algorithms that any third year Computer Science student would do in their sleep.

I've seen similar failures with both EE's and CSc students fresh out of school lock up when faced with their first real development job simply because the lacked the confidence and experience (and mentoring management) to learn their first job.

So, what's your point really? .... that FPGA's are only for REAL EXPERIENCED EE's?

sorry ...