Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Ok, to be completely fair now that Xilinx clearly doesn't allow open source tools to generate net lists for the features of current Xilinx devices (other than old limited EDIF and XNF interfaces), just what access does open source have to generate usable netlists for Altera products? What fpga companies are open to open source tools augmenting their vendor supplied tools to support their products?Article: 96126
John, If you create a XDL from using Xilinx tools, then the license says that the XDL must be used to program a Xilinx device, and that you are prevented from doing any reverse engineering, disclosure of IP, etc. Nothing would prevent you from writing a parser that prepared a nice usage report for display, however. Or, if you use an XDL that you create, and then put it back into a Xilinx tool, the same license restrictions apply. I am not sure, but I don't see any other uses of XDL covered by the agreement. It is, after all, just an ASCII format of connections. Why anyone would use it, and not use our tools, I wouldn't know. They could just as well use YADL (yet another design language - I have no copyrights, or trademarks, so I make this acronym freely available to all). One case I see now is that you create a tool to convert something (like c) into XDL. Then someone else uses our tools to create bitstreams. Sounds good to me! But: only If you (and they) didn't reveal anything about our tools, IP, etc. And you and they never used our software to develop your tool. Or to test our tool (both of which would be a violation of the agreement). Or to reverse engineer our software or hardware. Then we get bitstreams (which are covered by the use agreement from the person who used the generated XDL from your tool to push through our tool) which sells more of our silicon. Again, I am no lawyer, so at this point, I am just blathering on with my own opinions. AustinArticle: 96127
Austin Lesea wrote: > "XDL and related info being a public use interface to ISE outside of NDA > restrictions" is clearly prohibited. > > But, if XDL is used inside of the agreement, then that is OK. > > For example, if you created a XDL file with our tools, and then > processed it with your tool, and then wanted to use in in silicon other > than Xilinx, that is prohibited. It seems that there are really two different issues at stake here (in the context of people wanting to release open source XDL-interfacing tools). 1. - disclosing the XDL interface. The XDL file format is not published anywhere (I don't think, not even in Xilinx doco). So almost by definition, to use it you have to reverse engineer it. Thus, to release an open source tool that speaks XDL, you are disclosing Xilinx proprietary information that was obtained contrary to the terms of the EULA. That's naughty, and probably justifies a nastygram from the lawyers. 2. - targetting non-Xilinx parts. Disregarding (1) above, if I release a tool that speaks XDL, am I responsible for what people do with it? I would argue "no", but I'm sure you could find a lawyer who would argue "yes". That's a legalistic interpretation. But, back in the real world, what Xilinx wants to do is sell FPGAs. The best way to get Xilinx on side is to help them do that. They'll either look the other way, help you along, or if you're really good at it - buy you out. So, how do you create an XDL tool that does a "reach through" on Xilinx's condition that you only use Xilinx tools to target Xilinx parts? Well, maybe hybrid licensing is one approach. As long as you write the software from scratch, with no existing GPL (e.g.) code, then you can license the tool under any conditions you like[1]. For example, you could say "This software is released under the terms of the Gnu General Pulbic License version 2.0 (or BSD or whatever), PLUS the provision that the tool be used only to target Xilinx FPGAs". You'll probably want a lawyer to write this one, and Xilinx's lawyers would also want a look in. Richard Stallman would probably have a minor fit over the concept of bundling an commercial exclusivity clause with the GPL, but oh well. What you've now created is a hybrid license, incompatible with the pure GPL (ok, so you can't host it on sourceforge, no big deal). If someone uses the tool to target an Altera part, then they are breaking the conditions of their license and it is therefore immediately revoked. You would add a viral clause which makes sure that further refinements of the tool are also covered by the same dual condition (GPL + Xilinx only). So, if the goal here is to develop open source XDL tools, I think there are probably creative solutions, that will involve some compromises. If the goal is just to whinge about Xilinx's EULAs, then mission accomplished, and we can all go back to work. Regards, John [1] If it's your code, you can insert any condition you like, no matter how silly. How about "It is a condition of using this software that you wear a propellor-head cap and stick your tongue out while doing so". Very silly, but if you don't like the conditions, don't use the software!Article: 96128
cs_posting@hotmail.com wrote: > It seems like you are hoping Xilinx legal will meet you here. That > might be a good result, but you may have to first talk to them on their > turf to issue the invitation. Actually what I was hoping for was an open source advocate inside the company to act as the interface point between public discussions and Xilinx Legal. If the culture is clearly anti-open source, then I surely would not expect someone to put their job on the line as an advocate. Actually, I think I've already been accurately given the answers, and took a lot of heat for exposing part of the private discussions I have had about this touchy subject.Article: 96129
cs, Going from "using XDL" for some unspecified reason, to "open source" is a big step. Too big. There is nothing "open source" about any of Xilinx's software. Right now, the discussion has been about an ASCII representation of connections that Xilinx developed as a convenience (replaced an earlier format). XDL's use is only restricted by the agreements on the software that created it, and uses it (that we supply). It also specifically allows uses (for which it is intended) like someone writes a parser to generate a nice report from the XDL file (noted in the comments on XDL in our documentation). If you chose XDL to use as your intermediate language for your CS111 FPGA, I think it would be a curious choice, but one we would not have much claim to, as if you had your own tools to create it, and use it, test it; and you never used our tools, IP, or patents, why would we care? AustinArticle: 96130
Austin Lesea wrote: > Nothing would prevent you from writing a parser that prepared a nice > usage report for display, however. True ... if the format were public outside ISE, and the related EULA NDA. So, in practice today, not possible ... > Or, if you use an XDL that you create, and then put it back into a > Xilinx tool, the same license restrictions apply. See above, without a public description of XDL, then you have to use ISE tools to obtain it ... info that is again EULA NDA locked. > I am not sure, but I don't see any other uses of XDL covered by the > agreement. It is, after all, just an ASCII format of connections. Just a proprietary ASCII format of connections until publicly disclosed. Once the format/syntax is publicly available. Then to use it you need to know the names of the Xilinx objects that you can instantiate, and what the arguments are for those objects (pin names and functions). Which again, is only documented inside ISE subject to EULA NDA terms.Article: 96131
Austin Lesea wrote: > John, > > If you create a XDL from using Xilinx tools, then the license says that > the XDL must be used to program a Xilinx device, and that you are > prevented from doing any reverse engineering, disclosure of IP, etc. > > Nothing would prevent you from writing a parser that prepared a nice > usage report for display, however. Since you start out by contradicting yourself, it's really hard to figure out what you mean.Article: 96132
Austin Lesea wrote: > One case I see now is that you create a tool to convert something (like > c) into XDL. Then someone else uses our tools to create bitstreams. > > Sounds good to me! But: only > > If you (and they) didn't reveal anything about our tools, IP, etc. Without the equiv public data found in the XNF specification ... file format and object definitions ... it's not possible.Article: 96133
Austin Lesea wrote: > Going from "using XDL" for some unspecified reason, to "open source" is > a big step. Too big. For you perhaps, but open source code under a freedom-preserving license is perhaps the most likely variety of tool that volunteers might develop. The other alternative, closed software developed by those who hope to sell seats, and will license what they need from you, seems more in your comfort zone to date. > There is nothing "open source" about any of Xilinx's software. That's not what we're talking about, though I seem to recall some cygwin-ish files floating around in the install - but let's call that off topic. > Right now, the discussion has been about an ASCII representation of > connections that Xilinx developed as a convenience (replaced an earlier > format). Which if half of your comments are to believed is too encumbered to be of any use outside a private or closed source tool - or if the other half are to be believed, is available and harmless. > XDL's use is only restricted by the agreements on the software that > created it, and uses it (that we supply). It also specifically allows > uses (for which it is intended) like someone writes a parser to generate > a nice report from the XDL file (noted in the comments on XDL in our > documentation). Yes, but someone else can take that parser and use it as a starting point for something like reverse engineering. Unless the license terms _of the parser_ prevent that. But if they do, then parser (despite not being Xilinx software) is not a free and open tool. > If you chose XDL to use as your intermediate language for your CS111 > FPGA, I think it would be a curious choice, but one we would not have > much claim to, as if you had your own tools to create it, and use it, > test it; and you never used our tools, IP, or patents, why would we care? If it really talks the same XDL you do, then someone can use it as a bridge between a new language and your silicon (which you would like) or between your tools and someone else's silicon. The later would allegedly be a violation of your license terms, but not of the license terms of the proposed XDL tool - unless the XDL tool is not a free and open piece of software. If the proposed XDL tool is not a free and open piece of software, then some of the participants in this discussion aren't interested in writing it. We could have a whole other discussion about why, but the obvious reason is that it's too big a project to be worthwhile without input from many sources and the justification of many users.Article: 96134
Austin Lesea wrote: > Going from "using XDL" for some unspecified reason, to "open source" is > a big step. Too big. > > There is nothing "open source" about any of Xilinx's software. This is the companies right, no matter how much we object. There has to be a business decision that open source is in the companies best interests ... which is where talking about this and lobbying might be of use. > Right now, the discussion has been about an ASCII representation of > connections that Xilinx developed as a convenience (replaced an earlier > format). Until a document shows up on the public web site, with equiv data to the XNF specifications ... file format and object definitions, it's a closed proprietary standard, that requires violating the ISE EULA NDA to make public any use of it. > XDL's use is only restricted by the agreements on the software that > created it, and uses it (that we supply). It also specifically allows > uses (for which it is intended) like someone writes a parser to generate > a nice report from the XDL file (noted in the comments on XDL in our > documentation). *IF* there were a public document like the XNF spec, this statement would be true. Today it is false, as no one has been able to find such a public document yet. > If you chose XDL to use as your intermediate language for your CS111 > FPGA, I think it would be a curious choice, but one we would not have > much claim to, as if you had your own tools to create it, and use it, > test it; and you never used our tools, IP, or patents, why would we care? With a public XDL format and library objects document, this is exactly what we hope for.Article: 96135
John Williams wrote: > What you've now created is a hybrid license, incompatible with the pure > GPL (ok, so you can't host it on sourceforge, no big deal). If someone > uses the tool to target an Altera part, then they are breaking the > conditions of their license and it is therefore immediately revoked. > > You would add a viral clause which makes sure that further refinements > of the tool are also covered by the same dual condition (GPL + Xilinx only). But what if someone figures out XDL by reverse engineering your tool, rather than Xilinx's software? How do you prohibit someone from reverse engineering (ie, reading and taking notes) open code?Article: 96136
I thought it might be a relatively fun and easy project to do a audio/video (coax or rca) matrix that can take any number of n inputs and route them to any n ouputs (1 to 1, 1 to all, etc). I know this can be done using circuitry, but what about Analog FPGAs? Have analog FPGAs matured enough where something like this is feasible? Do they have enough resources to implement all the multiplexers needed/Article: 96137
On 2006-01-30, Austin Lesea <austin@xilinx.com> wrote: > > There is nothing "open source" about any of Xilinx's software. I think everyone here understands that. While I consider it regrettable, I choose not to agitate for a change in that situation. > XDL's use is only restricted by the agreements on the software that > created it, and uses it (that we supply). It also specifically allows > uses (for which it is intended) like someone writes a parser to generate > a nice report from the XDL file (noted in the comments on XDL in our > documentation). That's a nice statement. Please back it up by posting the document titled "Xilinx Design Language" on the 'net, accessible to people who have not clicked on the ISE EULA. The copy I see in an old ISE-6.2 install is Version 1.6, updated 07/07/2000. Nobody (I hope) wants to pirate that copyrighted work. But our rights to use the information contained in that document would be much clearer -- and legally match both the assertions made here in c.a.f and the implications in the XDL document itself -- if that document got untangled from the ISE EULA. > If you chose XDL to use as your intermediate language for your CS111 > FPGA, I think it would be a curious choice, but one we would not have > much claim to, as if you had your own tools to create it, and use it, > test it; and you never used our tools, IP, or patents, why would we care? That's not for me to decide. The point of being squeaky-clean legal is that an XDL-using project would not get shut down even _if_ Xilinx decided to care. - LarryArticle: 96138
cs_posting@hotmail.com wrote: > John Williams wrote: > > >>What you've now created is a hybrid license, incompatible with the pure >>GPL (ok, so you can't host it on sourceforge, no big deal). If someone >>uses the tool to target an Altera part, then they are breaking the >>conditions of their license and it is therefore immediately revoked. >> >>You would add a viral clause which makes sure that further refinements >>of the tool are also covered by the same dual condition (GPL + Xilinx only). > > > But what if someone figures out XDL by reverse engineering your tool, > rather than Xilinx's software? How do you prohibit someone from > reverse engineering (ie, reading and taking notes) open code? > I don't know. Maybe it doesn't matter. The purpose of "though shalt only target Xilinx parts" is to keep Xilinx off your back. If someone reads your code and reimplements the XDL parser for Evil, instead of Good, maybe it's Xilinx problem to pursue, and not yours? JohnArticle: 96139
cs, I see. Seems we never even disclosed the basics of the XDL format. I had thought that we had disclosed its construction, and structure. Well then. Looks like XDL is off limits, too. Now that we have that understood, perhaps we can retire this entire thread and move onto something else? AustinArticle: 96140
In article <1138660375.447864.74580@g49g2000cwa.googlegroups.com>, <cs_posting@hotmail.com> wrote: >fpga_toys@yahoo.com wrote: > >> I can not personally broker a deal for an open source project, because >> I can not control the use and modification of the project in the open >> public. I would not accept the personal liability should Xilinx think I >> could even control what happens to the information after we publish >> it. >> >> So public discussion, that all can use is the only productive forum >> for open source uses. > >I think you could get the ball rolling with some email, but I agree >that all of the 'decisions' woul d have to be very public, and even >enough late-stage discussion to illuminate them, for the result to be >of any use for a free and open project. > >It seems like you are hoping Xilinx legal will meet you here. That >might be a good result, but you may have to first talk to them on their >turf to issue the invitation. My wife was a paralegal in the past couple of years till she realized she really didn't like working with Lawyers... Anyway, one of her daily tasks was to print out email that had come for each of the lawyers in the office. They apparently couldn't figure out how to read email on their computer, they needed someone to give them a hardcopy of it - that being the case, I don't know how you'll get lawyers to use usenet ;-) So, to summerize the legal problem as I understand it so far: 1) Xilinx people (presumably AEs) have said that you can use XDL (including parsing it) so long as you don't violate the EULA - and then they say that using XDL to target Xilinx parts will not violate the EULA. 2) Others (fpga-toys) say NO, you can't even parse XDL without violating the EULA because to do so requires you to know the format of XDL which is not published anywhere and is only available by running the xdl command and looking at the resulting file (and since the xdl program is covered by the EULA it's output is also covered). So you can't freely distribute a program that parses XDL. You could parse it with your own program, but you wouldn't be able to legally distribute the parser to others because they might not be under the EULA. (there are other claims made by fpga-toys related to the exclusive nature of XDL use not being compatible with open source licenses like GPL - but for now let's stick with the first two issues and get back to this one later) It seems that I recall somewhere in one of these threads that someone from Xilinx mentioned an appnote about XDL. If one existed, that described the format of XDL wouldn't that constitute a public documentation of XDL which is not covered by EULA? However, I could not find such an appnote on the Xilinx site when I searched for it. If such an appnote exists, where is it? If the appnote doesn't exist, would it be possible for Xilinx to create one? It would need to describe the XDL format and then be published on the Xilinx site. It seems to me that this would go a long ways towards resolving the legal ambiguity of creating open source tools around XDL. Since the XDL format itself looks quite simple, I would imagine that a document like this wouldn't need to be very long. I would also bet that the software group within Xilinx already has documention that would work. How about it Xilinx folks? Can you get permission from your lawyers to publish an XDL spec on your website? If you can, that would probably resolve the issue. If your lawyers say no, then I suspect it wouldn't help for me (or any other outside entity) to ask and I would also be hesitant to create any open source XDL tools because of the potential legal issues. It's an easy question for you to ask your lawyers and the answer would tell us a lot. PhilArticle: 96141
On a sunny day (Mon, 30 Jan 2006 12:56:47 -0800) it happened Austin Lesea <austin@xilinx.com> wrote in <drluif$3ls4@xco-news.xilinx.com>: >Jan, > >Xilinx restricts the use of the bitstream to only be used with its products. > >In that sense, we retain "ownership." I am not a lawyer, so I can't >speak or quote legalize. What I placed in quotes was from a lawyer. > >They do not make typos. > >I might. > >Austin > OK, in that sense I can live with it. I hope that we, as non lawyers, will not be creating a problem where it is not, or not supposed to be. Since I have no intention of using the bitstreams webpack generates for anything else then Xilinx devices, I think I am in the clear :-) Regards JanArticle: 96142
In article <drm501$3ls9@xco-news.xilinx.com>, Austin Lesea <austin@xilinx.com> wrote: >cs, > >Going from "using XDL" for some unspecified reason, to "open source" is >a big step. Too big. > >There is nothing "open source" about any of Xilinx's software. > >Right now, the discussion has been about an ASCII representation of >connections that Xilinx developed as a convenience (replaced an earlier >format). > >XDL's use is only restricted by the agreements on the software that >created it, and uses it (that we supply). It also specifically allows >uses (for which it is intended) like someone writes a parser to generate >a nice report from the XDL file (noted in the comments on XDL in our >documentation). > >If you chose XDL to use as your intermediate language for your CS111 >FPGA, I think it would be a curious choice, but one we would not have >much claim to, as if you had your own tools to create it, and use it, >test it; and you never used our tools, IP, or patents, why would we care? Yeah, nobody's looking to do that because, like you say, it wouldn't make sense. Austin, Please see my other post made just a few minutes prior to this one: Basically I asked someone at Xilinx to ask your legal dept if you can publish an appnote that shows the format of XDL on your website. If you can do that, then I think we're fine. If not, then it won't help for outside entities (such as myself) to ask your legal dept if it's OK if I develop open source tools that parse and manipulate XDL. If your lawyers tell you No then that would give us an indication of whether or not we need to spend anymore energy pursuing this route. If your lawyers give you the green light, then I think we're fine. To reiterate: The only way we can build an XDL parser at this point is to look at the output of the xdl program. If we were to build an XDL parser and then release it freely it looks like we violate the EULA. We're not asking for XDL to be put under an open source license (at least I'm not); we're asking that the XDL format be made available somewhere on your website such that the format itself is available outside of the EULA. Then, if I'm understanding the legal arguments made by fpga-toys correctly, we _could_ create an XDL parser and release it freely (the XDL parser under open source) without violating the EULA. PhilArticle: 96143
In article <newscache$3egxti$xu7$1@lbox.itee.uq.edu.au>, John Williams <jwilliams@itee.uq.edu.au> wrote: >Austin Lesea wrote: > >> "XDL and related info being a public use interface to ISE outside of NDA >> restrictions" is clearly prohibited. >> >> But, if XDL is used inside of the agreement, then that is OK. >> >> For example, if you created a XDL file with our tools, and then >> processed it with your tool, and then wanted to use in in silicon other >> than Xilinx, that is prohibited. > >It seems that there are really two different issues at stake here (in >the context of people wanting to release open source XDL-interfacing tools). > >1. - disclosing the XDL interface. The XDL file format is not published >anywhere (I don't think, not even in Xilinx doco). So almost by >definition, to use it you have to reverse engineer it. Thus, to release >an open source tool that speaks XDL, you are disclosing Xilinx >proprietary information that was obtained contrary to the terms of the >EULA. That's naughty, and probably justifies a nastygram from the lawyers. > >2. - targetting non-Xilinx parts. Disregarding (1) above, if I release >a tool that speaks XDL, am I responsible for what people do with it? I >would argue "no", but I'm sure you could find a lawyer who would argue >"yes". > >That's a legalistic interpretation. But, back in the real world, what >Xilinx wants to do is sell FPGAs. The best way to get Xilinx on side is >to help them do that. They'll either look the other way, help you >along, or if you're really good at it - buy you out. > >So, how do you create an XDL tool that does a "reach through" on >Xilinx's condition that you only use Xilinx tools to target Xilinx parts? > >Well, maybe hybrid licensing is one approach. As long as you write the >software from scratch, with no existing GPL (e.g.) code, then you can >license the tool under any conditions you like[1]. For example, you >could say > >"This software is released under the terms of the Gnu General Pulbic >License version 2.0 (or BSD or whatever), PLUS the provision that the >tool be used only to target Xilinx FPGAs". > >You'll probably want a lawyer to write this one, and Xilinx's lawyers >would also want a look in. Richard Stallman would probably have a minor >fit over the concept of bundling an commercial exclusivity clause with >the GPL, but oh well. > >What you've now created is a hybrid license, incompatible with the pure >GPL (ok, so you can't host it on sourceforge, no big deal). If someone >uses the tool to target an Altera part, then they are breaking the >conditions of their license and it is therefore immediately revoked. > >You would add a viral clause which makes sure that further refinements >of the tool are also covered by the same dual condition (GPL + Xilinx only). Yes, I've been thinking exactly the same thing. I don't see where requiring Xilinx-only usage is all that big of a deal, AND practically speaking you don't give up much at all since most retargetting should probalby be done at some higher level anyway. > >So, if the goal here is to develop open source XDL tools, I think there >are probably creative solutions, that will involve some compromises. If >the goal is just to whinge about Xilinx's EULAs, then mission >accomplished, and we can all go back to work. > Really, I think all we need at this point is for someone at Xilinx to get permission to put an XDL file format spec on their website somewhere as an appnote. If that can be done, then I think we're good to go. PhilArticle: 96144
In article <1138663721.351662.283480@g49g2000cwa.googlegroups.com>, <cs_posting@hotmail.com> wrote: >John Williams wrote: > >> What you've now created is a hybrid license, incompatible with the pure >> GPL (ok, so you can't host it on sourceforge, no big deal). If someone >> uses the tool to target an Altera part, then they are breaking the >> conditions of their license and it is therefore immediately revoked. >> >> You would add a viral clause which makes sure that further refinements >> of the tool are also covered by the same dual condition (GPL + Xilinx only). > >But what if someone figures out XDL by reverse engineering your tool, >rather than Xilinx's software? How do you prohibit someone from >reverse engineering (ie, reading and taking notes) open code? > If the XDL file format is available on the Xilinx site they wouldn't need to RE our tool. At that point if some 3rd party creates an XDL->[Altera|Atmel|...] tool, then it's the 3rd party's problem, not ours. But again, practically speaking I really don't think that it's the best place for doing design retargetting. PhilArticle: 96145
Phil Tomson wrote: > In article <newscache$3egxti$xu7$1@lbox.itee.uq.edu.au>, > John Williams <jwilliams@itee.uq.edu.au> wrote: > >>What you've now created is a hybrid license, incompatible with the pure >>GPL (ok, so you can't host it on sourceforge, no big deal). If someone >>uses the tool to target an Altera part, then they are breaking the >>conditions of their license and it is therefore immediately revoked. >> >>You would add a viral clause which makes sure that further refinements >>of the tool are also covered by the same dual condition (GPL + Xilinx only). > > Yes, I've been thinking exactly the same thing. I don't see where requiring > Xilinx-only usage is all that big of a deal, AND practically speaking you don't > give up much at all since most retargetting should probalby be done at some > higher level anyway. The loss is not practical, so much as philsophical. There is a critical distinction between "Open Source" software and "Free" software. "GPL + Xilinx only" could be open source, but it is definitely not Free. Some developers may not care, for others it could be a show-stopper. JohnArticle: 96146
Phil Tomson wrote: > >You would add a viral clause which makes sure that further refinements > >of the tool are also covered by the same dual condition (GPL + Xilinx only). > > Yes, I've been thinking exactly the same thing. I don't see where requiring > Xilinx-only usage is all that big of a deal, AND practically speaking you don't > give up much at all since most retargetting should probalby be done at some > higher level anyway. Still, it's essentially impossible to do this and have the tool be open source. If the code is open source it can be published in a book; that book can be purchased as a physical object and under the first sale doctrine used as reference material to guide any effort someone wants - including trying to make chips that compete with Xilinx. > Really, I think all we need at this point is for someone at Xilinx to get > permission to put an XDL file format spec on their website somewhere as an > appnote. If that can be done, then I think we're good to go. Yes, that would simplify things. Another option is that some of the applications (reconfigureble computing for example) might not need the whole thing to be able to show results promising enough to warrant consideration of expanded releases in the future. If I understood the complaint with high level interfaces for that application, it's that the authors of these experimental tools want to produce very low level, repetitive structures, but modern synthesis tools take their carefully crafted output and munge it by in essence trying to figure out what the silly human wanted so that they can optomize it with trade secrets - which in this unique case is counterproductive. What if just enough of the format of XDL or something similar were released to expose a low level "programming" interface that's sort of a gigantic version of a very primitive FPGA architecture, either without most of the modern improvements other than size, or without anything but the most basic ways of using whatever advanced functional blocks are included in the release? It seems if something like that could be released, and people demonstrated something interesting with it that hinted at chip sales, maybe cases could be made for releasing other information.Article: 96147
Phil Tomson wrote: > To reiterate: The only way we can build an XDL parser at this point is to look > at the output of the xdl program. If we were to build an XDL parser and then > release it freely it looks like we violate the EULA. We're not asking for XDL > to be put under an open source license (at least I'm not); we're asking that > the XDL format be made available somewhere on your website such that the format > itself is available outside of the EULA. Then, if I'm understanding the legal > arguments made by fpga-toys correctly, we _could_ create an XDL parser and > release it freely (the XDL parser under open source) without violating the > EULA. To do RubyHDL ... IE ... produce netlists, you also need the objects publicly defined that you need to build a netlist describing connections with. Also, the EULA doesn't offer distribution rights to others bound by it. That will take a separate agreement with Xilinx legal where you take on some personal liability for your RubyHDL's distribution and use.Article: 96148
Austin Lesea wrote: > I see. Seems we never even disclosed the basics of the XDL format. I > had thought that we had disclosed its construction, and structure. > > Well then. Looks like XDL is off limits, too. > > Now that we have that understood, perhaps we can retire this entire > thread and move onto something else? Sure ... I think we have more than hashed this to death :( It's probably better at this point to lobby it as a business decision with sales/marketing and real customers.Article: 96149
Hi, Background: Spartan 3 FPGA, Xilinx 6.3 tools I am currently having a problem with what I think is a power up reset. I have a fairly complicated design consistings of several state machines and a controller. I can get this to work easily by either downloading to the eeprom without powering off as well as simply downloading the bit file over jtag. However, when I power off and on the firmware no longer works. I know this particular board works with a much simpler version of this bit file, and has no problems with powering up. Is the fact that my new design is more complicated allowing a power up reset problem to come into focus because the older versions of this were much simpler and not as prone to these types of problems? Is there some way to put a counter on the spartan 3 and do a global reset with it? Tomorrow I think I will try to wire a hard reset onto the board but it is going to be a pain, I hope someone else might have encountered and solved a similar problem. thanks, wolf
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z