open source fpga programmer programs

We are not asking that Xilinx release Xilinx source, just that they relax their very tight NDA on EVERYTHING that is ISE related.

This is the issue ... sponsered by is NOT the same as completely fair market paid for. I doubt that when Xilinx finally decided to block this project that they fairly compensated the entire team for their total labor hours and materials for the project that were forced to be forfieted behind the enforced NDA.

I doubt the outcome here is that Xilinx "bought" the project and decided to bury it ... prove me wrong please.

Crucial is everything ... file formats, library interfaces, usage procedures, etc

EVERYTHING that is a derivative of the documentation, and use, of the product.

It's not about religion, it's about playing fair with the open source teams. The JHDLBits SF project was registered I believe April 17, 2004, they gave public talks on open source for Xilinx for at least two major conferences in June and Sept, and a few months later got stopped dead in their tracks.

Playing fair with open source is not taking all that yields wind fall profits by avoiding competitive licensing, then shutting down open source teams on NDA violations which may actually be far more minor that they appear, and having EVERY software interface to their product under NDA. The only public interfaces are an obsolete XNF specfication (and I'm not entirely sure that's public) and a vague EDIF interface with non-documented interfaces that you need to extract from ISE NDA restricted documentation.

So me where there is ANY legal interface which allows you to program the full Xilinx offering of FPGA's from XC4K's (which are great hobby devices) to current XC4V products without geting encumbered in ISE license restrictions prohibiting open source software development and disclosure of interfaces? I don't see a legal one ... so show me ...

yep ... let's find a reasonable solution so we can write open source software to develop net lists for ISE tools without getting tied up in the ISE NDA restrictions.

I think it comes down to this:

If your software doesn't work, you tell the customer, "download a patch from our web site."

If your hardware doesn't work, you tell the customer, "here's your RMA number. Send the unit back (at your expense) and if it's under warrantee we'll fix it for free; otherwise, it'll cost $$$."

As for why hardware guys don't like to just "jump in" when a project is poorly defined: just tell the boss: "Ooops, there was a fsck-up in the product definition so we have to dump that run of 1000 fully-assembled boards."

-a

I had not thought of that - but this is the first truly plausible explanation why the programming data are kept secret I ever see. I could see it was about control, but I could not see the why. This is definitely a possibility.

Thanks,

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

So why then block open source place, route, and bit stream gen tools that equally benefit all? That is not about using Xilinx software for Altera parts.

I have only written tools for CPLDs, so there may be FPGA-only related details which I miss, but it appears that they are blocking as much as possible to not make reverse engineering too easy (it is always possible, the question is whether it will seem easy enough for someone to do it). And then again, the reasons may be totally different. The world is by far not the purely market driven place we are deafened about by the screaming media every day.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Hmmm...did I somehow end up in the wrong newsgroup? I thought this was comp.arch.fpga, where if your hardware doesn't work, you tell the customer "download a patch from our web site" -- thus the name _field programmable_ gate array. Granted, it's entirely possible to use an FPGA in a design that doesn't allow its associated Flash to be updated

-- but it's certainly a long ways from a given.

Jerry,

that was right on.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Sometimes the fix to the problem can't be done in the FPGA but rather must be done in the "other stuff" on the board. Or what if the FPGA you chose is large enough for the original design but won't fit the fixed design?

Or what if your design doesn't have a convenient external programming interface? How many customers have the JTAG tools?

-a

I didn't say that every possible hardware flaw could be fixed via a patch. I objected to the claim that none of them could be.

In the end, however, you're right: a design certainly _can_ be screwed up to the point that the only hope for it is to throw it away and start over. OTOH, if you're creating a design that bad, software isn't going to be enough different to notice -- a company run so badly that it releases utterly hopeless messes to its customers isn't going to be saved by software being more dependably patchable.

To quote from your former message,

The number of things which can be done is probably infinite. However, programmability is a major feature of programmable devices - or at least I naively thought so until today :-). This posting is not meant to contradict your last message which says, if analyzed correctly, more or less the same. It is just meant to make the analysis easier :-).

Cheers,

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Oh, it certainly is.

His point (and I agree that it's valid) is that sometimes things that need changing aren't in the FPGA itself. Just for example, if you decide to add some sort of extra I/O to some hardware, you're typically going to need some sort of physical connection. Putting an Ethernet MAC into your FPGA is pretty straightforward, but won't do much good without the physical hardware to allow the user to connect his Ethernet cable.

That particular change would really be in design scope rather than indicating a defect in the implementation though. Perhaps a more reasonable example would be that the design had Ethernet all along, with the MAC on the FPGA, but the PHY as a separate chip. A problem in the PHY chip might be curable by changes in the FPGA.

At the same time, a lot of ancillary chips like this tend to have relatively simple requirements, reducing the likelihood of subtle problems in their designs -- and sometimes even if there is a problem in such an ancillary chip, you can assure against putting it into the situation where the error arises.

Actually, I tend to run unused I/O's to a header very close to the Fpga that can take a daughter card. This does allow for easy external additions after the project is "done".