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
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: 96151
When Xilinx FPGAs power up, internal logic and clock routing is gradually established as the configuration process proceeds. But all flip-flops are being held in a fixed state. At the end of configuration, this control signal ( often considered the "power-on reset") is released. Unfortunately, that control signal releases different parts of the chip at different times, since it has a total propagation delay that often is longer than a user-clock period. Different flip-flops or registers on the chip can thus become "alive" at different times, and when this difference occurs inside one state machine, an undesired sequence of operations might result. It is wise to equip critical state machines with their own locally synchronously delayed release of the "power-on reset" condition, or to disable the Clock Enable input with a synchronous controller that has signal routing shorter than a clock period. Or you can suppress the clock until after the "power-on-reset" signal has gone inactive. Once you understand that the trailing edge of "power-on-reset" might have a delay difference or skew that exceeds a whole clock period, the solutions become obvious. This subject has been covered many times in this newsgroup. Peter Alfke, Xilinx ApplicationsArticle: 96152
"John Williams" <jwilliams@itee.uq.edu.au> schrieb im Newsbeitrag news:newscache$i5fxti$dj2$1@lbox.itee.uq.edu.au... > Antti Lukats wrote: > >> I just love how easy it is to port uClinux to new platform, just >> change the UCF file and there you go :) > > You know Antti, in a very strange way you can take some credit for that > fact. Your statement in a comp.arch.fpga posting 18 months ago > > http://groups.google.com.au/group/comp.arch.fpga/browse_frm/thread/97f020e714a25237/2a12c984240d22e8?tvc=1&q=lukats+uclinux#2a12c984240d22e8 > > "NIOS uCLinux is WAY easier to get started then MicroBlaze uCLinux > thanks to the full integration of the config and integration into > Eclipse workbench, as EDK6.3 is also Eclipse based it would be possible > todo the same for MicroBlaze uClinux config and build. " > > p***ed me off so much I went and created the auto-config mechanisms that > now make mb-uclinux by far the easiest (and probably most popular) > soft-CPU Linux solution around. > > So, thanks - I think :) > > John Oh John, sorry when I got you pissed off. you know I am happen to so poor guy that I can not afford to have second workstation only for MicroBlaze development and as you know the MicroBlaze uClinux build until today can not be done on the Windows machine. So what I stated 18months ago stands so far that it is (or was at least) possible to configure and and build uClinux on single Windows PC a nice to have thing for poor souls like me not having separate linux PC box around. OTOH - I did only check the uClinux config from SOPC builder, it worked, but I have never ever seen it working as I do not happend to have NIOS uClinux ready hardware ready and hasnt cared enough to obtain such hardware so far either. And I have build uClinux systems way before the auto-config, and it has been always been easy for me (after the first try). I have spent a lot of time in desperate attempts to get coLinux environment setup with preconfigured microblaze uClinux toolchain after some pain it works but the way todo file transfer to windows host PC is real complicated, so only ysterday (or today if in US timezone) I did install Bochs source code and compiled Bocs x86 emulator on Windows for one simple reason: to have windows based virtual linux with pre installed images containing MicroBlaze toolchain and uClinux deve tools - so other poor guys (those with no Linux!) can also work on single PC and still develop for uClinux Microblaze and again just today I got finally working a MicroBlaze uClinux FPGA tested driver for SD Cards so I was able to mount in MicroBlaze uClinux a SD card formatted with FAT16 and after mount I did see files on the card. its FAST bit.banged software driver that works with SD (later I may add MMC card support too) cards in NON-SPI mode. It can work with any software controllabe PIO port, currently with GPIO CMD-DAT-CLK-card sense onto port, all other is software. a small bootloader exists that loads the full uClinux image from SD card using the same bitbang mode, load time approc 7seconds. This could be even better as I have not done assembly level optimization to the code yet. I am replying in such details as I was just about to contact you to ask what is the procedure to submit the driver to be included in the uClinux distribution (it is GPL licensed) John, dont judge me so hard, for those who primare work on linux its really hard to understand how much trouble it is setting up and maintaining 2 work stations for the linux cross compile. I just want to type make menuconfig make dep make from my primary workstation (winPC) as long as that is not possible, well it means additioal burden - at work I did today the following procedure 18 times 1 edit mmc.c 2 TFTP PUT mmc.c 3 stand up from my chair going to linux PC here working standing 4 copy from tftpboot to \drivers\block 5 make 6 back to my workplace, sitting down 7 TFTP GET image bin 8 copy image.bin to SD card, insert to FPGA board, reset 10 seconds linux prompt is ready :) I have a mouse-keyboard-switch, but linux doesnt work with it :( I really have killed pretty much of my time because of no easy solution exist for those whose primary system is windows - and that has to be so as FPGA tools are generically better supported on WinXP then linux so switching to linux completly is not an option for me. anyway I am hoping to have the BOCHS emulator setup to provide a solution that doesnt require the purchase of second PC for microblaze uclinux development cheers AnttiArticle: 96153
Thanks for all that helped in my last problem about det FSM. As a beginner, I always meet this situation: When some statements that perform a specific function and would be instantiated more than one times in a module, we may instantiate the statements as a function, a task or another module. For example, I may write a function, a task or a module to form a function of compare two signed number, and then instantiate it in my module. I want to ask that after synthesis and fitting, where are the differences when I am respectively writing statements as follow: /////////////////////////////////////////////////////////////////////////////////////////// //situation I module top_module(...); ... sub_module u1_submodule ( .port1(wire1), ... ); endmodule //sub module module sub_module(...); ... endmodule ///////////////////////////////////////////////////////////////////////////////////////////// //situation II module top_module(...); ... task_name(...); ... //task declaration task task_name; ... endtask endmodule ////////////////////////////////////////////////////////////////////////////////////////////// //situation III module top_module(...); ... function_name(...); ... //function declaration function function_name; ... endfunction endmodule ///////////////////////////////////////////////////////////////////////////////////////////////// Thanks a lot for any reply about differences between the 3 situations. YuQing YouthArticle: 96154
I don't believe it can be done with an analog fpga. Analog fpgas today don't have near enough bandwidth for video. The lattice programmable analog chips have a bandwidth of generally less than 1 MHz. There are some amps in the lattice ispPAC30 that have a GBW of 15MHz, and that is enough for NTSC, but if you wanted anything more than NTSC composite, then it's not going to happen. There aren't many other companies. Anadigm also makes "FPAAs" which have around a 2 MHz bandwidth, which is not enough for video. I don't currently know of any other existing analog fpga companies. This does raise a valid question, though. Why are all the FPAAs so terrible? Why can't they do something better than 1 MHz bandwidth. I just can't see how that's much use for any sort of signal processing (unless it's audio but audio can be processed with a $2 DSP probably way better than any FPAA could do it). As long as FPAAs are so terrible, there will never be many uses for them. When I can get a 1 GHz FPAA for $10, then there may be a market. -ArlenArticle: 96155
Hello everyone. Hevday Logic's Interactive Logic software is now available for free download from http://www.hevday.com For those of you who missed my first post, here are some of the features of Hevday Interactive Logic: - The ability to view and modify signals and data directly on schematics in an entire multi level design while the circuit is running, paused or while stepping the circuit one clock at a time. - Digital waveform style display of Data vs. Clock Cycles. - Long time scale waveform display of signals over periods of continuous operation up to 7 days. - Setting of breakpoints for debugging circuit state after predefined conditions. - A novel approach for determining maximum allowable clock frequency, based on testing actual circuit functionality. Hevday Interactive Logic has been designed for prototyping and small volume applications and uses Xilinx FPGAs. For more information, please visit http://www.hevday.com All feedback welcome. Regards, Andrew Ward.Article: 96156
I think that the issue of what's open source and what's propriety in Xilinx tools is not very well defined. Three licenses pop up at the start, The Xilinx "shall not" and 2 GPL "you can as you please" Xilinx don't distinguish what license covers what programs/libraries etc. Something GNU (and any lawyer) will say you must make clear. I would also suggest that why even bother with XDL in the first place.. sure its great for Xilinx... but make a common object language. This can be compiled into either Xilinx XDL.. which can use the Xilinx Tool chain to build an FPGA.. or into Altera to let Quartus do its thing. or any other FPGA Vender. The main thing is what's in your source. No Xilinx Libraries, no Altera, no nothing except GPL. In fact.. that's what Mentor and others do already by using EDF files. Then there aren't any legal issues ? Right ? XDL is then only used for Xilinx's :-) Simon "Austin Lesea" <austin@xilinx.com> wrote in message news:drm501$3ls9@xco-news.xilinx.com... > 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? > > Austin >Article: 96157
Hi all, Thanks so much for your replies. >> Try taking a look at how Parallax does this with their SmartPack development >> boards. They do the same thing as you're suggesting only with a PIC instead >> of an AVR. I've had a look at what Parallax does and it is one of the options that I've been exploring. They use a Pic to configure a Cyclone device. They also seem save the configuration on flash which the Pic reads at startup. Other than a basic explanation they dont give much information. >> Does your design include an AVR? If the RS232 is connected to the >> Cyclone2 and you have enough pins and some extra LEs you should be >> able to do this from the Cyclone. The design at this stage does not contain a AVR. The thinking for the AVR is that we always want a static method for updating the configurations (a bootloader). The AVR can be programmed when the unit is installed and this never changes so even if the programming/configuration of the FPGA is interrupted for some reason, and a valid configuration is not saved, at the next reset we'll still be able to access and configure the unit. I have also considered a PLD for this purpose but I think my C/C++ is better than my VHDL at this stage :-) Regards, RandallArticle: 96158
What about SSH ? Mostly when I work on the kernel, my test platforms are no just right beside me but connected to a "server" where it download (tftp & nfs) from and it's serial port is also connected to that machine. I can even hard-reset the platform from that machine. All I have to do is ssh to that machine with 2 terminals, and on one, lauche a terminal emultator to see the RS232 console output and on the other I can do the "common" tasks. Well, since my main pc is also Linux I don't do the compile on the server but nothing prevents me from ... And all that without sitting up ;) SylvainArticle: 96159
<fpga_toys@yahoo.com> schrieb im Newsbeitrag news:1138660630.962486.107720@f14g2000cwb.googlegroups.com... Dear mr John Lawrence Bass QUIP is not enough for you? https://www.altera.com/support/software/download/altera_design/quip/quip-download.jsp AnttiArticle: 96160
Antti Lukats <antti@openchip.org> wrote: ... > you know I am happen to so poor guy that I can not afford to have second > workstation only for MicroBlaze development and as you know the MicroBlaze > uClinux build until today can not be done on the Windows machine. Doesn't CoLinux work? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 96161
Dears Altera provided USB Balster has no driver for Unix/HP-UX The current USB Blaster provided by ALTERA uses FTDI Chip (FT245BM) to have USB Interface. It uses the USB driver provided by FTDI to perform the Kit programming. That means if you want to use the USB Blaster to program a Kit using a system with UNIX Solaris platform, you need to have FTDI (FT245BM) driver for this platform (UNIX). I looked at the FTDI site (http://www.ftdichip.com/Drivers/FT232-FT245Drivers.htm#D2XX) there I didn't find the FT245BM driver for UNIX. Any ideas on how to get the driver for UNIX? Can any one help me in getting a link to free driver for this cable or chip supporting the UNIX. Regards Satish KArticle: 96162
"Uwe Bonnes" <bon@hertz.ikp.physik.tu-darmstadt.de> schrieb im Newsbeitrag news:drn8vp$plj$1@lnx107.hrz.tu-darmstadt.de... > Antti Lukats <antti@openchip.org> wrote: > ... >> you know I am happen to so poor guy that I can not afford to have second >> workstation only for MicroBlaze development and as you know the >> MicroBlaze >> uClinux build until today can not be done on the Windows machine. > > Doesn't CoLinux work? > it does. nothing wrong running mincroblaze toolchain on it, the problem was copying the resulting file out from colinux the virtual network adapters and bridginh things did not want to work properly AnttiArticle: 96163
"Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com> schrieb im Newsbeitrag news:1138695589.614153.254960@g43g2000cwa.googlegroups.com... > What about SSH ? > > Mostly when I work on the kernel, my test platforms are no just right > beside me but connected to a "server" where it download (tftp & nfs) > from and it's serial port is also connected to that machine. I can even > hard-reset the platform from that machine. > > All I have to do is ssh to that machine with 2 terminals, and on one, > lauche a terminal emultator to see the RS232 console output and on the > other I can do the "common" tasks. Well, since my main pc is also Linux > I don't do the compile on the server but nothing prevents me from ... > And all that without sitting up ;) > > > Sylvain > :) I was possible yesterday lazy in non creative way, sure remote access would also work if linux accessible computer is on accessible, what is unfortunatly is not the case at home. I just need to setup some scripts that launch make and shuffle files. AnttiArticle: 96164
Amigo wrote: > Hi All, > > We are developing a product which uses a Cyclone2 device from Altera. > The unit is a completely sealed unit with only a RS232 link to the > outside. We want to be able to update the Cyclone2 configuration files > stored in a EPC device using the available RS232 link. Has anyone done > something similar out there? > > I have thought of writing a PC application which would serially send > the configuration files from the PC to a AVR and then the AVR would > program the EPC. There are a few unknows for me here. > 1. Which output file format could I use and interpret seeing that it > seems as if the .pof files generated by the Quartus software must be > interpreted and can only be used by Quartus? > 2. Are EPC devices the best things to use as there are numerous other > flash based configuration devices out there? > An alternative idea might be to use USB instead of RS232. There are some nice FTDI chips like the FT2232C which are effectively UART to USB converters (with corresponding virtual comms port drivers for the PC), which also have jtag programming pins designed for just this sort of application. If you always have the device connected to a PC, you don't need any flash at all on the card - the PC software can download the FPGA design on connection.Article: 96165
Hi, don't want to use the OPB because i have to buy the EDK. So ilooked at thze schematic and found the pins i need. A detailled description of the AC97 was useful to implement my design. Thanks for your answer. regards, lori.Article: 96166
Amigo ha scritto: > Hi All, > > We are developing a product which uses a Cyclone2 device from Altera. > The unit is a completely sealed unit with only a RS232 link to the > outside. We want to be able to update the Cyclone2 configuration files > stored in a EPC device using the available RS232 link. Has anyone done > something similar out there? My thesis was about remote update of altera FPGA with an EPC configuration device (sorry but it's in italian). I do the same with a NIOS system on the FPGA with a custom block to the external EPC interface with an HAL device driver for the flash. > > I have thought of writing a PC application which would serially send > the configuration files from the PC to a AVR and then the AVR would > program the EPC. There are a few unknows for me here. > 1. Which output file format could I use and interpret seeing that it > seems as if the .pof files generated by the Quartus software must be > interpreted and can only be used by Quartus? > 2. Are EPC devices the best things to use as there are numerous other > flash based configuration devices out there? Another type of remote update system I made, use the jtag port of the EPC with the jamplayer software. You can find the source code from the Altera website. I modified this software to use an FTDI 2232 device. Ask me if you want more information, source code, ecc MatteoArticle: 96167
Austin Lesea schrieb: > All: > > From our legal group- > Also, the bitstream created by using Xilinx software is owned > by Xilinx can only be used on Xilinx programmable products, for example, > FPGAs. LOL, ROTFL. Xilinx owns the bitstream? And Microsoft owns my PhD thesis because I typed it in Word? Wait, I created a PDF with Acrobat, so the PDF is owned by Adobe. But it was created from a file owned by Microsoft, so now Microsoft needs to sue Adobe. 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. There was a case about two years back were a computer game manufacturer claimed that it owned level files created by an editor delivered with a game. They lost the case. Please have you legal department read up the first sale principle and have them think again whether they can restrict what a private customer does with the output of the tools. And after they checked that for the US, have them recheck for scandinavian countries. Kolja Sulimma BTW: If I typed my HDL in the ISE editor, can I still publish it under GPL (according to your legal department)Article: 96168
bjzhangwn schrieb: > I want to implement an ata controller in the fpga,the controller use > the ultra dma mode to read and write datas,and I want to know if it is > difficult to implement it.Can some one give me some advice. if you need UDMA just go to t13.org, download the spec and start implementing ... the version from opencores does not support full UDMA implementation is straight forward but contstraining and meeting the timings is a little tricky ... I did this as my first learning-VHDL project bye, MichaelArticle: 96169
On 30 Jan 2006 15:28:41 -0800, 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? The viral clause must still apply to the reverse engineered tool; it has to define reverse engineering as a form of "use". - BrianArticle: 96170
bjzhangwn schrieb: > The ata controller in the opencores website don't support the ultra dma > mode,but I need the ultra dma mode?Have someone ever do it? the procedures are well documented and if you want to be a host, then you only need a very small subset of the functions ... t13.org has the full specs bye, MichaelArticle: 96171
Hello, I am trying to build an interface to a Analog Devices AD5447 digital analog converter on Xilinx Virtex-II 1000 and 3000 FPGAs. First the interface seems to work because the DAC outputs a sinus signal as supposed to do. Now as the design is getting bigger more and more noise is shown on the dac output. So I think this is related to timing issues concerning the dac interface. The AD5447 needs a clock signal (named CS) with a CS low time of minimal 10 ns and a CS high time of 7 ns minimal. I generate this signal using the recommended clock forwarding scheme consisting of a DCM with CLK0 and CLK180 BUFGs (each with a period of 20 ns, duty cycle correction, source synchronous timing) driving an DDR register in the IOB (first output is '0' to get a clock corresponding to the CLK180 DCM output). The DAC data setup time is 7 ns minimum before the rising edge of CS and the data hold time is 0 ns minimum. The data is clocked with the DCM CLK0 output to the IOBs. So at a rising edge of CLK0 the data is presented to the DAC and at a rising edge of CLK180(=CS) the data is sampled from the DAC. Now how do I get the data signals generated by a Xilinx DDS IP Core synchronized to the CS signal to met the timing requirements mentioned above? Particularly how to constrain the data path to the IOBs to meet a maximal delay of 3 ns behind the DCM CLK0 output? A "OFFSET OUT" constraint of 3ns seems not to work because of too long IOB path delays. Can this problem be solved with timing constraints or do I have to implement a clocking scheme with to distinct clocks, one for data generation and one to send the data together with a clock to the DAC? Thanks for your help. Best regards, S. Hagenkoetter.Article: 96172
A language is high-level with respect to another if it offers a greater degree of abstraction from the complexities of implementation. ANSI C is a high-level language with respect to assembler as, amongst other benefits, it precludes the need to worry about registers. A C-to-FPGA language, taking it here to mean any language that approximates the syntax of ANSI C, is only a high-level language with respect to VHDL when it offers abstraction. An example of such abstraction would be a C tool that compiles to VHDL that hides the need to worry about clocks, or lining up of concurrent operations and pipeline timing. A language is of a higher level than another if you can obtain the same functionality while being less specific on exactly how you want the functionality to be implemented. It has little to do with the extent to which the code is readable. Theoretically one could design an assembler whose input was flowery prose. It would look like human language, but if you still had to specify (albeit it in rhyming couplet) which variables belonged to which registers, you would have a low-level language. C syntax is neither inherently high-level nor low level, and its choice for C-to-FPGA compilers is near arbitrary. The important issue is the degree of abstraction, the quality of your compiler, its libraries and the underlying hardware it generates. Whether the code would look better resembling Java or C doesn't seem very relevant. The Java programming language is a higher level language than ANSI C. On the other hand, JHDL with its java-derived syntax is a lower level language than SRC's MAP compiler with its C-derived syntax. So: "uh, in what way is C a higher level language than VHDL anyway?" isn't an answerable question unless you explain which C-syntax derived hardware compiler you mean. Brian Drummond wrote: > On Mon, 30 Jan 2006 14:01:37 +0000 (UTC), > christopher.saunter@durham.ac.uk (c d saunter) wrote: > > >Robin Bruce (robin.bruce@gmail.com) wrote: > > > >: Hans wrote: > >: > If you have to choose a C language I would recommend you check out SystemC > >: > which might be better on your CV than Handel-C :-) > > > >: What's so good about SystemC? :) > > > >What's so good about AnythingC? > > > >I have quite strong feelings that whilst a high level language than > >Verilog/VHDL could be a real boon to FPGA development, C is far from a > >good prototype form for such a language.... > > uh, in what way is C a higher level language than VHDL anyway? > > - BrianArticle: 96173
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 SulimmaArticle: 96174
Antti Lukats wrote: > QUIP is not enough for you? > > https://www.altera.com/support/software/download/altera_design/quip/quip-download.jsp There are clearly questions about the Altera license too. "2. License to the Licensed Program: By this Agreement, ALTERA grants to you a non-exclusive license to use the Licensed Program (and any updates thereof for which you have paid a subscription fee) on the terms and conditions outlined in this Agreement. Any features for which you have not paid a subscription fee or any other unenabled features of the Licensed Program (unless ALTERA provides a software protection enabling key or code for such unenabled features) are unlicensed and you agree not to use or access such features. Certain licenses to the Licensed Program are time limited, to the extent designated by ALTERA and as may be set forth in the feature line license key that is issued, and will automatically time-out at the end of the designated period. The source code of the Software, and the algorithms, concepts, techniques, methods and processes embodied therein, constitute trade secrets and confidential and proprietary information of ALTERA and its licensors, and LICENSEE shall not access or use such trade secrets and information in any manner, except to the extent expressly permitted herein. ALTERA and its licensors retain all title, copyright, patent and other proprietary rights therein. LICENSEE agrees not to remove or obscure any copyright, trademark or patents notices found in or on any user documentation or the Software." Which follows the Xilinx strategy of claiming "trade secrets and confidential and proprietary information of ALTERA". That agreement continues with: "Pursuant to this Agreement, you may: (a) use the Licensed Program on a single computer (or, if you have purchased a floating node license, the number of concurrent users for which you have obtained licenses from ALTERA may use the Licensed Program on networked workstations); (b) use the Licensed Program for the sole purpose of programming logic devices manufactured by ALTERA and sold by ALTERA or its authorized distributors, [...] Your end customers may use ALTERA programmable logic devices that have been programmed with the Licensed Program." To limit your use exclusively to those activities which program Altera devices. The "by ALTERA or its authorized distributors" restrictions are very interesting, as it suggests that if you have purchased a gray market part, you are not allowed to use these tools to program it. Later in the same section: "YOU MAY NOT USE, COPY, MODIFY, DISTRIBUTE OR TRANSFER THE SOFTWARE OR ANY COPY, OR MERGED OR COMBINED PORTION THEREOF, IN WHOLE OR IN PART, EXCEPT AS EXPRESSLY PROVIDED FOR IN THIS AGREEMENT. IF YOU TRANSFER POSSESSION OF ANY COPY, OR MERGED OR COMBINED PORTION OF THE SOFTWARE, TO ANOTHER PARTY EXCEPT AS EXPRESSLY PROVIDED HEREIN, YOUR LICENSE IS AUTOMATICALLY TERMINATED. YOU MAY NOT DECOMPILE, DISASSEMBLE OR OTHERWISE ATTEMPT TO ACCESS THE SOURCE CODE OF THE SOFTWARE; PROVIDED, HOWEVER, THAT IF YOU ARE LOCATED IN A MEMBER NATION OF THE EUROPEAN COMMUNITY OR OTHER JURISDICTION THAT PERMITS LIMITED REVERSE ENGINEERING, YOU MAY PERFORM LIMITED REVERSE ENGINEERING, BUT ONLY AFTER GIVING NOTICE TO ALTERA AND ONLY TO THE EXTENT PERMITTED BY THE EC SOFTWARE DIRECTIVE OR OTHER APPLICABLE LAW." Which means that anyone outside the EU can not use the claimed proprietary rights outside this agreement, and those in the EU must provide advance notice. Overall the tone of the Altera agreement is the same EULA NDA with the typical flair of a corporate legal license - claim everything, yield little. This is troubling for open source developers. I current have a couple thousand MAX7K devices that I purchased gray market off eBay, which presumably were purchased thru supported distribution by the company that liquidated them at auction when they failed. If I pay the license fees, and then use that license to program these devices, will I have to forfeit the license and fees? I have not paid for a license, partly for that reason. It might be cheaper to dump them on eBay at a loss. The Altera language states that you have read and understand the agreement, which unless you are a lawyer, might be doubtful.
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