open source fpga programmer programs

I know of no good (*) open source simulators or synthesis tools. You can forget about the back end tools - there are compelling reasons for these to be completely closed.

I suggest you drop your dogma, and use some of the many low cost or free (beer) tools, or learn about Wine (assuming you have an x86 machine).

(*) other people may regard certain offerings (e.g. Icarus) as good. YMMV.

Regards, Allan

Depends on your fpga's. For Xilinx there is no alternative since the P&R and bitstream generation tools are vendor proprietary. For Altera parts it's unclear at this point, at least one source believes they might open up shortly. Atmel isn't fighting open source at this point, and is actually relatively open about bitstream formats and architecture for AT40K/AT94K products to the point that we will be actively supporting those products in ways with FpgaC that simply are not possible on Xilinx. I suspect that will bring Altera out as well, since the breadth of the FpgaC project is pretty exciting for Reconfigurable Computing (RC).

The core patents for Fpga's will be expiring this decade, and if the open source RC movement is careful to establish prior art and register core technology patents, it should be possible to safely create an open source basis for RC similar to what gcc, gnu, FreeBsd, and Linux did for the mainstream software world.

Xilinx may try to control the market as AT&T/USL/Novel/SCO did, but in the end vendor neutral open source projects have a strong chance of being mainstream in the FPGA RC community inside a few years. I suspect that Altera, Amtel, Intel, and a few others will sieze the SoC market to take RC mainstream from the ground up. In that market Altera with the Arm core has a clear market edge as most embedded folks are already Arm experienced, where PPC is still a minority player in the global embedded market. The Altera Excalibur devices have been a very interesting pairing in that respect ARM + 20KE fpga and that product family is certainly going to grow, especially if an open source partnership develops for it.

With core patents expiring this decade, and early in the next, I would not be suprised if Intel, AMD, Actel, ASCII(One Chip MSX), and a few others are all capable of making the current FPGA leaders marketshare insignificant in a few years as embedded RC goes mainstream.

FpgaC is just getting off the ground, but with a strong vision toward realizing the 10 year old dream of mainstream RC.

Don't waste your time. Vendor's spend a *VERY* long time working out bugs in their software. With the level of complexity of an FPGA, you don't want to waste time with buggy software that is developed in someone else's spare time. All of the actually chip programming, routing stuff is vendor locked(for good reason), so your out of luck on that.

That being said, Xilinx does offer their software for Linux. It is not opensource but it does give you a non-windows alternative.

-Eli

Eli ... the open source community does as well. It's rather an insult against those of us that do volunteer our time toward open source project to brashly brand open source that way.

Consider that Xilinx believes the Linux is a stable platform for it tools, is it not? Consider thart Xilinx uses the GCC compiler for it's PPC support, does it not? Consider that Xilinx uses the GNU libraries on the PPC, does it not?

The only thing here that is wrong, is that Xilinx leaches off the backs of open source developers, then asserts prioprietary rights to open source efforts to do a BETER job at place, route, and bit steam generation. At least other mainstream corporations have the good sense to both embrace open source in their product offerings, and give back to the open source community at the same time.

See the what happened to JHDLBits thread.

John FpgaC developer

"There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies." - C A R Hoare

In other words, "shut up and get back on the couch".

"I won't run software written by cowards." - Adam Stiles, referring to software provided without source code

- Larry

My aim was not to insult. I am aware of alot of quality open source applications.

I agree that Xilinx does use open source tools like GCC and what not because of their quality but I think open source FPGA tools may be a little different. For it to work out, Xilinx would have to give away the gut of the parts so people could write applications properly. This would pose an issue with other companies such as brand 'A' to just take their IP. That is their business, to develop the best guts.

Sorry for the insult.

-Eli

Gcc wasn't the greatest compiler in it's early days either, Nor was linux or the gnu libraries. Over time things get better with use and community commitment. Open source EDA will too.

FPGA EDA tools have been high dollar revenue producers ... $10K to $100K per seat license. Xilinx uses that revenue to pay programmers, which have every incentive to protect their jobs by blocking competitive development of similar tools. At the same time, they have very limited resources, and can not respond to all users needs, such as a totally different placement, router, and bitstream tool set for reconfigurable computing because there are not established high volume users asking for this feature set.

I can, and will, continue to say that the existing tool chain is horrible for FpgaC to interface to as it's a huge bottle neck for compile, load and go ... and it's utilitization of hardware resources really sucks unless you are willing to let it work for several days ... and often even then the results suck because it makes some poor choices very early that it will not rip up and replace. FpgaC tends to produce lots of very regular mesh structures, which using very different placement/cost algorithm can be routed fast, on the fly, to a bit stream to support compile, load and go operations on the order of seconds, not hours -- with a substantially better fit than par simply by retaining the mesh relationships rather than abandoning them. The compiler by it's very nature, tends to produce a few types of structures, which are emitted with very little change, over, and over, and over. By carefully optimizing those emitted structures, and fine tuning the place and route process to be optimized for them, it a much simplier problem than xilinx par is optimized for, and much, much easiter get better utilization as the end result is something similar to dynamically generated cores which are just replicated and routed togather.

The big difference, is that these structures are not pure macros/cores ... but are logic blocks which the complier merges with adjacent blocks into packed LUTs. So what is output are not fixed regular structures in terms of pure macros/cores, but mesh structures of optimized logic pipelines. Xilinx par isn't tuned to recognize these mesh structures, and breaks them apart ... and other poor choices. Some things which FpgaC does as clear optimizations, also just drive par nuts ... like clock enables to reduce the depth of LUT based multiplexors and the need for FF feedback for idle states. The result is that par separates the LUT and FF from each other, then wastes another LUT for pass thru, and burns routing resources/dynamic power in the process. Greatly complicating the FpgaC to optimize around par's faults is a goose chase, since it may do something completely different the next release and we will waste a lot of time optimizing FpgaC for each and every ISE release ... with a growing number of divergent hacks. Simply taking something like the JHDLBits wire database and router and fine tuning it for FpgaC is MUCH MUCH easier, and decouples us from having a different hack for every change in ISE. Plus we get compile, load, and go times down to seconds, instead of the minutes or hours that it takes par to do a poor job.

We will put our efforts into supporting FPGA vendors that want our help, and appreciate the long term investment we are making into their products future, and their companies sales.

think to consider ghdl for vhdl simulation. I use it dayly and it is capable to compile the Xilinx unisim library and almost all simprim (except dsp48) so you can use it for rtl design and even for post synthesys and post map simulation.

But they've already got plenty of patents on that IP so it's not like someone could reverse engineer the bitstream and then just copy. Actually, I'm not convinced that you _can_ determine a lot from a bitstream format.

Now, as has been said elsewhere in this thread, a lot of those patents start expiring in this decade.

At any rate, it seems clear that Xilinx would not be in any way helpful to open source efforts to create alternative tools.

Phil

I have heard people say good things about GHDL, but it's a single language tool. It won't handle any of my Verilog code, and no free tool (of which I am aware) will handle mixed languge designs.

Regards, Allan

You obviously don't develop using any fpga or most dsps then ?

My guess is that, Xilinx is more afraid of their tools being used by other FPGA vendors. Probably they don't want ISE to support Altera devices and the like!, if it is opensourced. That may be the biggest risk for them - not reverse engineering.

Open source is great for a lot of things and I use it where possible but for other areas its a long way from useable.

Just wondering who did a lot of the work on the original ppc gcc ?

IBM or freescale empoyees ?

The JHDLbits ending so far isn't good. But I'd be very wary of doing any thesis project with a company I wasn't an empoyee of and even then I'd still be careful.

You need to have a legal agreement on paper before you start, may take time and a lot of effort but these days if you do not cover your arse you are asking for trouble.

Surely one problem is by the time you have the whole tool working correctly with a part, (or at least the initial part or two) there is a good chance that one or two new parts have been introduced and the people who may want to use that tool want to use the latest part.

What tool is cray using for their reconfigurable computing systems ?

If the parts are very similar it shouldn't be to much of a problem.

How is a company using an open source compiler leaching from open source ? If the software is placed in/under license where it can be used, what is the problem as long as the company follows the license ?

If you don't like it don't put the software under that license.

Rather than openly attacking and abusing xilinx in a public forum, surely a better move would be to sit down and talk to them ?

Alex

Except that the 20KE is *old*. I don't think Altera are going to bring it on, they seem to have decided to push NiosII as their embedded processor and let the hard-cores languish in history... unless you've heard different.

Cheers, Martin

There are probably a million different views, some a lot stronger than mine.

Taking the windfall profits by basing your product on open source is a real economic gain. And in my mind completely soured by playing hard ball in similar IP areas, such as JHDLBits.

The fraction of a percent of the windfall value they recieved by avoiding other commercial OS licenses which was donated to FSF, is completely soured by their inability to also open up some of their IP to open source in the form of JHDLBits.

Reading Alex's papers, it's pretty clear there was an expectation to make their project an open source gem ... and I'd be very suprised if multiple Xilinx employees (indluding the contract monitor) were not aware of that intent many months before Xilinx blocked it's release. Given that ERSA'04 was June 21-24, 2004, and two months later the FPL04 was August 30 and September 1, 2004 there was ample time to set the record straight by Xilinx in that time, assuming that a Xilinx person was not part of the paper reviews for these and other conferences where papers were submitted for consideration.

Now some would like to assert that the FpgaC project would be free to use the XDL interface, even though it's not formally documented and released outside the strict NDA License terms of the ISE software. That is FALSE, given that the JHDLBits team based their project on the JBits

I feel that Xilinx made a VERY poor business decision to reap the windfall profits of open source in one hand, and aggressively stop the JHDLBits project from releasing tools based on ISE and JBits SDK.

Everyone is free to make up their own minds, but lacking formal clearification by Xilinx about JHDLBits and open sources ability to use ISE tools and interfaces for other projects, the view from my seat is Xilinx has clearly said ANY use of their software products in open source is off limits. Thus making every aspect of the Xilinx product line closed to open source development.

When I say they have failed to give back to the community, I specifically mean that they continue to keep their product line off limits for open source development, by failing to openly and clearly document internal interfaces to ISE and related tools like JBits, and exempt those interfaces from the strict license terms.

If XDL was freely usable, I'm sure that it wouldn't take much work to retarget the JHDLBits code to that interface .... but I rather suspect that may be the same or equivalent interface they are currently using, and prohibted from releasing Open Source tools based on it.

So ... I feel it's pretty poor for Xilinx to take windfall profits by avoiding commercial compiler and OS licenses, than lock open source out of their product.

Xilinx staff are free to object ... and we can always toss this discussion into the wider open source community for comment.

schrieb im Newsbeitrag news: snipped-for-privacy@g47g2000cwa.googlegroups.com...

Dear whoever you are (hiding under bogus email address):

there are different licenses, the JBits license has always beeing a restrictive license so open open-source thing on top JBits could have been violation of the JBits license.

XDL is open, and can be used by any means you wish. Xilinx cant stop supporting XDL and cant go after anyone who releases open source tools that use XDL in the process. As long as only the XDL file format is used its ok, but as soon as you release open source software (without Xilinx permit) that actually integrates parts of Xilinx software (like JBits) you may have violated the license and that may have different follow ups.

If you think you can do something that has real value, go ahead and do it, there is no need to be afraid that Xilinx comes and stops you or your business. They want.

Get used to it ... even what appear to be real names are not verifiable.

I believe this is False, absolutely false. There is no document I'm aware of outside of express Xilinx NDA which describes the file format, the library elements, and their use. Producing such a file from information derived from documentation and use of licensed ISE materials IS (like it or not) completely NDA restricted.

If you know of such a document by offically released Xilinx which is not under NDA that describes the file format, library interfaces, and other information needed to produce a valid bit stream, then please post the location of that document here. Pointing ot materials obtained under the licenses NDA does not count ... IE Webpack.

Otherwise, it's just wishful thinking.

yes ... which means that just writing software that interfaces to ISE is in violation of the license terms ... IE open source efforts can not do so.

I'm sorry ... but I like my house and my toys ... I will not risk them to a judgement by Xilinx for violating their IP rights. Besides, it's just morally wrong to violate express IP rights of another and hope they will ignore you.

I guess its a difference between embedded hardware and 'software' developers. I have spent most of my time developing embedded hardware where assembly/C/Verilog rules.

I remember when we hired a 'software' (also insert *nix advocate, open source advocate, corporations are evil, etc) to help out with a project.

We had a working product when things started. Tight embedded code, streamlined hardware, etc.

Week 1:

Software Guy:" OK guys, I see you wrote your DSP code in Assembler and C. Lets re-write algorithms. What do you mean you statically allocated your 128K of memory? Let's dynamically allocate. By the way, I only run Linux on my PC"

Week 2: (Things are broke, still trying to get Linux Desktop to work on our network)

Software Guy: "I can't code on this system. Where is your O.S. to handle threads? What is an interrupt routine? What, no OS memory management. Lets Load Linux. After all, its open source and free. We can modify it to fill our needs. Its free."

Week 3: (Things are really Broke, still trying to get Linux Desktop to work on our network)

Software Guy: "What, gcc doesn't compile on a TI C6000? I need an OS. What? TI doesn't open source its compiler for the VLIW architecture. What , people want money for there hard work? Lets re-write all the development with GPL compatible stuff. All development tools should be open source. After all its free.

Many weeks later : (Things are FUBARed, still trying to get Linux Desktop to work on our network)

Software Guy: "My super-uper-duper modified lLinux version is too slow. I need a Quad Power PC system with 2GB of ram that uses 100watts of power to replace you single chip solution that is 2 Watts. But is has a open-source O.S. and is GPL compatable. Its FREE.

Software Guy gets shit-canned. Hardware guys never ask for software help again. We will hire more hardware guys. We could have bought 30 'proprietary development kits' for the cost of the 'free' stuff. And it would be documented better!

Moral of the story: There are people that have to ship product in very little time. Things have to work. We don't have time to re-write code because we refuse to use something that doesn't have the source released. There are some good open source projects out there but they took a long while to get documented and running good. Sure I use thunderbird mail. Its a cool opensource app. I use open source where its good. But I also have serious time lines and goals to meet. At some point one needs to rely on chip makers.

-Eli

starting the hardware software bigot wars just isn't useful, or productive, it's actually outright trolling.

There is a simlar point about hardware guys being frozen in paralysis because the project is too undefined to specify ... and the software guys jump in over their heads and steadily work toward a solution while the hardware guys are still paniced that the design isn't yet complete and signed off.

The real moral of the story is that we are all people, and we do the best we can with the experience and tools at hand.

John