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
Kolja Sulimma wrote: > Sorry Austin, that is complete nonsense. Xilinx can not own a file that > contains IP both from me an third parties. > A shared ownership might be possible but I really doubt that. That seems to be the most logical basis for a claim. Compare for example, this partial passage from RedHat's default licensing of the Cygwin compatability layer: "The Cygwin API library found in the winsup subdirectory of the source code is also covered by the GNU GPL (with exceptions; see below). By default, all executables link against this library (and in the process include GPL'd Cygwin glue code). This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all." This seems to say that if you compile in a way that includes bits of their library, RedHat has an ownership interest in your binary. The only difference is that they exercise that interest by extending the GPL to the result, whereas Xilinx exercises its interest by extending its restrictions on keeping the technology proprietary and only running it on Xilinx silicon. RedHat is also willing to sell you a license to use the parts of the Cygwin stuff which they own under non-GPL terms, and Xilinx may be willing to license a bit stream to you slightly differently if you can make a convincing argument to why it would be in their interest to do so.Article: 96176
Hi @ll, I'm new in FPGA Design. For my student research project I try to start running the Altium NanoBoard-NB1 with an Xilinx SPARTAN-IIE FPGA chip on it. I'm working with the Altium Designer 2004. I have also installed the XILINX ISE WebPack 8.1i, in order to be able to program the FPGA on the daughterboard. After translating the design an error message is displayed as follows: ERROR:Portability:90 - Command line error: Switch "-quiet" is not allowed Do I have to change any setting for the NGDBuild Option? Thanks for any help NilsArticle: 96177
Robin Bruce wrote: > A language is high-level with respect to another if it offers a greater > degree of abstraction from the complexities of implementation. And I might note that issues like pipelines and state machines flow from the semantics of sequential C syntax depending how a C to FPGA compiler implements that syntax. Pipelines occur naturally in sequential C on all platforms when the statement blocks are in an inverted order, a trick I have used for a few years and offered in C.A.F before. State machines are a natural by product of IF-THEN-ELSE sequential statements in any looping construct such as WHILE. It is much more natural to implement pipelines and state machines in C this way for people trained in sequential languages as the results are visually obvious and timing free. You get the advantage of being able to move the same code, between a variety of execution targets, which traditional HDL's limit.Article: 96178
"Nils" <nils.hannemann@email.de> schrieb im Newsbeitrag news:1138716434.545030.98410@o13g2000cwo.googlegroups.com... > Hi @ll, > > I'm new in FPGA Design. > For my student research project I try to start running the Altium > NanoBoard-NB1 with an Xilinx SPARTAN-IIE FPGA chip on it. > I'm working with the Altium Designer 2004. I have also installed the > XILINX ISE WebPack 8.1i, in order to be able to program the FPGA on the > daughterboard. > After translating the design an error message is displayed as follows: > > > ERROR:Portability:90 - Command line error: Switch "-quiet" is not > allowed > > Do I have to change any setting for the NGDBuild Option? > > Thanks for any help > > Nils > yes probably = DXP2004 uses switches not any more available in current releases of ISE so you need a workaround AnttiArticle: 96179
cs_posting@hotmail.com schrieb: > Kolja Sulimma wrote: > > >>Sorry Austin, that is complete nonsense. Xilinx can not own a file that >>contains IP both from me an third parties. >>A shared ownership might be possible but I really doubt that. > > This seems to say that if you compile in a way that includes bits of > their library, RedHat has an ownership interest in your binary. The > only difference is that they exercise that interest by extending the > GPL to the result, whereas Xilinx exercises its interest by extending > its restrictions on keeping the technology proprietary and only running > it on Xilinx silicon. RedHat is also willing to sell you a license to > use the parts of the Cygwin stuff which they own under non-GPL terms, > and Xilinx may be willing to license a bit stream to you slightly > differently if you can make a convincing argument to why it would be in > their interest to do so. That would be shared ownership, which is possible. But to claim that, Xilinx must argue that the bitstream contains material that is protected by copyright. Is is not enough that it was created with a tool that is protected by copyright. (Using a compiler/text editor vs. linking to a library/using a letter template) Some bitstreams might contain Xilinx library elements but clearly not all bitstreams do. Kolja Sulimma BTW: The ISE toolflow uses TCL at some points. If the use of a tool alone would impose the license of the tool on the result all bitstreams would be GPL. So Xilinx needs to explain why the EULA of ISE does affect the bitstream while the license of TCL does not.Article: 96180
Since I don't use Altera product at this point, what I don't know, is if there are open source friendly public disclosures by Altera which open up access to their tools in a friendly way.Article: 96181
Choose NIOS II it has 1,040,000 hits !!Article: 96182
Need SuggestionArticle: 96183
it sounds good, but how could this workaround look like? i have no ideas what i can do. there are a few checkboxes in the option menu but i can't find a topic which matches with my problem. :( and even in the xilinx design environment i couldn't find a topic.Article: 96184
"TigerSatish" <satishkmys@gmail.com> schrieb im Newsbeitrag news:1138718526.705207.34950@g49g2000cwa.googlegroups.com... > Need Suggestion > if you need it URGENT then only solution is to purchase a windows or linux PC and forget usb blaster on unix AnttiArticle: 96185
Hi all, I need a VHDL source code scrambler/descrambler. Polyn : x ^ 7 + x ^ 6 + 1 I found some information on web (LFSR xilinx, etc...), but I have some problem with my example. Thanks a lot for any reply about this subject (web, litteratur,vhdl code...). BrianArticle: 96186
Kolja Sulimma wrote: > The ISE toolflow uses TCL at some points. If the use of a tool alone > would impose the license of the tool on the result all bitstreams would > be GPL. So Xilinx needs to explain why the EULA of ISE does affect the > bitstream while the license of TCL does not. Does the license of TCL make claims about the output of TCL-using tools? My guess is it doesn't. So that's a difference right there - it doesn't really give us any clues about the potential validity of making such a claim.Article: 96187
Kolja Sulimma wrote: > BTW: > The ISE toolflow uses TCL at some points. If the use of a tool alone > would impose the license of the tool on the result all bitstreams would > be GPL. So Xilinx needs to explain why the EULA of ISE does affect the > bitstream while the license of TCL does not. Hey Guys, let's back off and let the open source advocates inside Xilinx to have time to work out how they want to be the good guys. They clearly recieve a lot of value from free open source that they use internally and put into their product. The backlash could clearly be creating XGPL licenses, which allow use for all but those companies that refuse to be equally open with their EULA's. That would a a lively debate, but we see it already with the number of free software licenses which specifically prohibt commercial use because of these abuses, and the mindset that if someone is going to profit from their work, they want part of the pie in the form of royalties or license fees. The reality is that all the information open source needs is out of their control anyway, it would just take a legal battle to secure it, that maybe even FSF would fund. I've already documented that fact. So, let's just give Xilinx a chance to think about this more carefully, and have a chance to volunteer to be good open source citizens.Article: 96188
Brian Drummond (brian_drummond@btconnect.com) wrote: : uh, in what way is C a higher level language than VHDL anyway? I guess that's a bit like comparing apples and oranges if we are talking about the *synthesizable* part of VHDL. Actually you've got me sat here scratching my head trying to decide now. There are constructs that aren't present in VHDL / or don't synthesize that I consider a higher level - e.g. things like C structs allow many variables to be passed around between areas of C code, without everything area (function) having to be upadated if (for example) extra variables are added to the struct. I don't think VHDL has such a neat, clean way of doing this. As I said before 'Why AnythingC' - I don't think it's high enough 'above' VHDL to make the pain of using a sequential orientated language for programming FPGAs worth while. It is good for hiding the truth about and FPGA implementation from a C programmer, but weather that is in anyones benefit... cdsArticle: 96189
Kolja Sulimma wrote: > Ed McGettigan schrieb: > >> The (A) company used these exact same EULA restrictions against Clear Logic >> and won. >> >> More details here: >> http://www.internetcases.com/archives/2005/09/ninth_circuit_a_1.html > > There is no mentioning of the EULA. Apparently there is a special law in > the US to protect semiconductor masks and the court treated the > bitstream as a mask work. > The EULA can still be completely invalid. > > I just skimmed the law, and I still do not see how Altera could possibly > have won. > It says > > "the “owner” of a mask work is the person who created the mask work" > If I start bitgen, I am generating the mask work and not altera. I use a > tool to do it, yes, but surely I am still the creator? > > But even if Altera was the owner, it goes on: > "the protection provided for a mask work under this chapter shall > commence on the date on which the mask work is registered under section > 908, or the date on which the mask work is first commercially exploited > anywhere in the world" > Surely Altera did not register my bitstream and did not exploit it > comercially before I sent it to Clear Logic? > > Then the law goes on, and explicitely allows to reverse engineer the > mask (bitstream) to create your own bitstreams with the information > obtained: > > §906 (a) 1 and 2: "it is not an infringement [...] for [...] a person > who performs the analysis or evaluation described in paragraph (1) to > incorporate the results of such conduct in an original mask work which > is made to be distributed." > > > I conclude that §906 (a) of the Semiconductor Chip Protection Act of > 1994 permits to reverse engineer bitstream information to create open > source tools. But hey, IANAL. > > Kolja Sulimma > > The previous link that I cited only discussed a narrow issue that was raised to an appellate court. Try this one instead which has notes on the on the Software License Agreement. Altera was not claiming that they "owned" the bitstream only that use of the bitstream was restricted to Altera only devices by the license of the software that created it. http://www.iplawobserver.com/2005/09/using-softwares-output-to-copy-chips.html EdArticle: 96190
[disclaimer: I'm a GCC developer and former Cygwin developer] One key difference between Cygwin and Xilinx, is that apps built with Cygwin also *include* part of cygwin (almost verbatim) in the resulting binary. Do bitstreams built by Xilinx tools *include* portions of the Xilinx tools in the resulting bitstream? Can Xilinx point to a bitstream and say "these 1000 bits are copied from our library" ? A better comparison is comparing Xilinx to GCC. The GCC license explicitly states that binaries built *with* GCC are not affected in any way by GCC's license. Note that binaries built *from* GCC (derived works) are a different story. GCC's runtime libraries have a specific clause that covers linking; if you build with GCC, linking doesn't incur the GPL. If you build with something else, linking does incur the GPL.Article: 96191
I need material wchich cover all about ADPLL, which contains about operating principles and design (vlsi also). If there are any links that have these information please let me knowArticle: 96192
Ed McGettigan wrote:
>
> The previous link that I cited only discussed a narrow issue that
> was raised to an appellate court. Try this one instead which has
> notes on the on the Software License Agreement. Altera was not
> claiming that they "owned" the bitstream only that use of the
> bitstream was restricted to Altera only devices by the license of
> the software that created it.
>
> http://www.iplawobserver.com/2005/09/using-softwares-output-to-copy-chips.html
>
One more link that which is the actual ruling made by the US Court of Appeals
for the 9th Circuit:
http://www.ca9.uscourts.gov/ca9/newopinions.nsf/01512427B6AF4BF88825707C0076B4A3/$file/0317323.pdf?openelement
The first half discusses the mask claims, the latter half discusses the SW License
claims on pages 17-23. Specifically on the bottom of page 23 the court found:
Altera customers cannot use the software, and
therefore create the bitstreams, without agreeing to the licensing
agreement, including the permitted use restriction. In
essence, a valid contract is a prerequisite to the creation of a
bitstream from Altera software, and the jury could logically
conclude that valid contracts were formed via the Altera
licensing agreements before customers sent bitstreams to
Clear Logic. We therefore affirm the district court’s denial of
judgment (sic) as a matter of law on the final claim.
Maybe we could now move any further legal oriented threads to comp.arch.fpga.legal :-)
and get back to technical issues and discussions. I know at least that this will
be my last post on this thread and the XDL/Open Source License threads.
Ed
--
Xilinx Inc.
Article: 96193Ed McGettigan schrieb: > The previous link that I cited only discussed a narrow issue that > was raised to an appellate court. Try this one instead which has > notes on the on the Software License Agreement. Altera was not > claiming that they "owned" the bitstream only that use of the > bitstream was restricted to Altera only devices by the license of > the software that created it. > > http://www.iplawobserver.com/2005/09/using-softwares-output-to-copy-chips.html Interesting. They invoke the Semiconductor Chip Protection Act by stating that the bitstream format contains information on the structure of alteras FPGA circuits and that it therefore something like a copy of alteras circuit layout was created. Clear Logic seems to believe that the jury was confused about what exactly was copied. I think that is very likely. You are allowed to reverse engineer if you incorporate the results in an original work. As I understand it clear logics mask is very different from alteras in that there is no configuration logic, sram cells, etc. There should be less then 1/6 of the transistors. Of course the structure will be similar, but what else should "incorporate the results" mean, clearly similarities are allowed? Still, that ruling does not apply to using an altera bitstream in a Xilinx FPGA oder implementing an altera bitstream in an ASIC (that is not similar to alteras FPGA structure) Kolja SulimmaArticle: 96194
Ed McGettigan wrote: > Altera customers cannot use the software, and > therefore create the bitstreams, without agreeing to the licensing > agreement, including the permitted use restriction. In > essence, a valid contract is a prerequisite to the creation of a > bitstream from Altera software, and the jury could logically > conclude that valid contracts were formed via the Altera > licensing agreements before customers sent bitstreams to > Clear Logic. We therefore affirm the district court's denial of > judgment (sic) as a matter of law on the final claim. > > Maybe we could now move any further legal oriented threads to comp.arch.fpga.legal :-) > and get back to technical issues and discussions. I know at least that this will > be my last post on this thread and the XDL/Open Source License threads. Thanks for the clearification Ed, and the small dose of contract law is good for everyone to keep them out of the defendants chair and having to learn a whole lot more. This statement about the enforcability of an EULA contract terms should be a wake up call to those that haven't thought these issues thru. In summary, the EULA contract NDA supercedes all other rights you might have to similar information in other settings. The confusion this week over the concepts of copyright fair use while under NDA, over contridictory statements about the open nature of VDL, and other rights issues have all been useful to learn and think about so we can protect ourselves and the IP we agree to use. Hopefully it's also been a learning exercise for Xilinx too. The real economic value for Xilinx is the sale of it's chips, and at some point open source access to the tool chain will greatly benefit the companies sales by expanding uses into new markets that the existing tool chain doesn't support. Certainly easy access to Xilinx product for personal research by students and hobbiests is a market builder that yields long term benefits as those individuals influence purchasing decisions for their employers and the companies they own.Article: 96195
Surely this is purely academic nitpicking going on here. Xilinx's ownership of your bitstream (which you agreed to when you installed their software) simply provides them a legal recourse should you try to retarget it to a different vendor's technology. They're in the business of selling chips, and with development systems like WebPack they make available free tools (which they invest massive amounts of money in) to reduce the cost to you to develop. They're not going to try to assert ownership of your Whizbang5000 IP - get real. I know people like to rant and rave about stuff like this. But for all practical purposes it's a no-op. Paul.Article: 96196
c d saunter wrote: > Brian Drummond (brian_drummond@btconnect.com) wrote: > > uh, in what way is C a higher level language than VHDL anyway? > I guess that's a bit like comparing apples and oranges if we are talking > about the *synthesizable* part of VHDL. Actually you've got me sat here > scratching my head trying to decide now. The truth is that it isn't in most ways. Java, C++, and other object oriented languages are. C started out it's origins a "The B programming Language" (http://en.wikipedia.org/wiki/B_programming_language) which was barely a step above assembly language on many of the small machines it was implemented on. As B evolved into C, it also replaced thousands of lines of assembly language, at little additional costs in size or performance. A good systems programmer codes C line for line with the accuracy of programming in assembler. That skill will continue as people use C syntax HLL's and HDL's to generate high performance circuits on FPGA's, and for these people the efficiency arguments of VHDL/Verilog in comparison to C subset languages will be moot. For a pure C syntax HDL list Handel-C there is very little difference between the results that a skilled engineer can get in comparison to VHDL/Verilog, and even that will diminish over time as the C based HDL's get the synthesis hints down pat that mature VHDL and Verilog tools implement today. > As I said before 'Why AnythingC' - I don't think it's high enough 'above' > VHDL to make the pain of using a sequential orientated language for > programming FPGAs worth while. That the language is sequential, doesn't mean that the resulting netlists are. This is certainly clear in FpgaC as long forward dependencies rapidly create deep combinatorial chains. In both VHDL/Verilog and C subset systems, you have to manually intervine to break the combinatorial chain into a pipeline. In C, we do this by inverting blocks of statements, and in VHDL/Verilog we do that by forcing the instantiation of FF's. Both are done by coding style hints. In C the results are clearly natural, and less likely to be error prone by accidentally inferring a FF which is a common error in VHDL/Verilog. Otherwise, the netlists from boolean's and arithmetics are functionally identical between all these languages as far as synthesis goes ... with the only differences being maturity, not issues of syntax limiting the synthesis. Ditto for data paths, and state machines. The only real difference is the ability to directly influence I/O specific features, which the C based tools MAY choose to defer to things like UCF files. > It is good for hiding the truth about and FPGA implementation from a C > programmer, but weather that is in anyones benefit... That is a good thing, as the size of the current FPGA market is stalled by the number of engineers that can write VHDL/Verilog and their productivity. Increasing the size of the FPGA market, to drive costs down for all types of projects, is significantly tied to using programming talent for all kinds of FPGA projects, including the new market of reconfigurable computing which VHDL/Verilog poorly addresses with the lack of VHDL/Verilog trained engineers that also understand software level system designs. This free's up EE design talent to design hardware, by transfering the back end of the project to software engineers with Computer Engineering or Computer Science degrees. More and more, software engineers will be a major player in FPGA product selection teams. FPGA companies which violate the sensibilities of software engineers by providing hardware only design tools, or licenses which are not open source friendly, or overly restrictive EULA's, will find that they may frequently loose design wins without a clear understanding why. FPGA companies may have established loyalties with the EE's, but that will not be enough to ensure design wins when software developers are also part of the product selection team. This single factor could change the entire face of the market in as little as 5 years. EE's may complain ... but the market is changing, and whining about it will not stop it.Article: 96197
fpga_toys@yahoo.com wrote: > That is a good thing, as the size of the current FPGA market is stalled > by the number of engineers that can write VHDL/Verilog and their > productivity. I don't think so - at least the job market for HDL engineers seems much smaller today than it did in the late 90's. I think the limitation on the FPGA market is the cost of the things, compared to more volume-appropriate ways of implementing the same functions. > Increasing the size of the FPGA market, to drive costs down for all > types of projects, is significantly tied to using programming talent > for all kinds of FPGA projects Seems to me like the real issue is that FPGA's are much bigger, and hence more expensive to manufacture, than other ways of getting many jobs done. Process gains make the FPGA's cheaper, but they also make other solutions cheaper too - and may make it logical to do something in software that needed hardware previously. > including the new market of > reconfigurable computing which VHDL/Verilog poorly addresses with the > lack of VHDL/Verilog trained engineers that also understand software > level system designs. This free's up EE design talent to design > hardware, by transfering the back end of the project to software > engineers with Computer Engineering or Computer Science degrees. > > More and more, software engineers will be a major player in FPGA > product selection teams. FPGA companies which violate the > sensibilities of software engineers by providing hardware only design > tools, or licenses which are not open source friendly, or overly > restrictive EULA's, will find that they may frequently loose design > wins without a clear understanding why. Yes, if you are going to market an FPGA as a general purpose dynamically configreable processing element then it needs to have a programming manual like that of a processor, or some other method of supporting just-in-time compilation. Right now most FPGA's are marketed more for the "ASIC in hours or minutes" application. To really go after a new market, the whole structure of the tool/silicon/IP matchup would have to be reconsidered.Article: 96198
Hi, When i changed the precision of power numbers to nW, the problem got resolved. priyaArticle: 96199
c d saunter wrote:
> I guess that's a bit like comparing apples and oranges if we are talking
> about the *synthesizable* part of VHDL. Actually you've got me sat here
> scratching my head trying to decide now.
>
> There are constructs that aren't present in VHDL / or don't synthesize
> that I consider a higher level - e.g. things like C structs allow many
> variables to be passed around between areas of C code, without everything
> area (function) having to be upadated if (for example) extra variables are
> added to the struct. I don't think VHDL has such a neat, clean way of
> doing this.
In vhdl, this is called a record, and records work fine for synthesis.
See type retime_t in the reference design below.
A vhdl single process design can also handle variables
"to be passed around between areas of code".
Note how the variable TxState_v
is accessed by the both of the
procedures cpu_regs and tx_state
in the reference design below.
http://home.comcast.net/~mike_treseler/uart.vhd
> As I said before 'Why AnythingC' - I don't think it's high enough 'above'
> VHDL to make the pain of using a sequential orientated language for
> programming FPGAs worth while.
I enjoy the pain, but you can already
do this with a plain-vanilla vhdl synchronous process.
-- Mike Treseler
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