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
Joerg wrote: > Hello Bo, > > >>>That won't help when you live in CA. The real paradox is that if you have >>>the certs in one state it still doesn't allow you to work under it in >>>another. So theoretically you'd need 51 registrations (with fees...) to >>>be able to work countrywide under PE. Makes no sense to me at all. >> >> Not necessarily. Most states PE board have 'commity' licensure--ie >> recognition of PE from another state and will allow you to hang a shingle >> in their state if you pay the fees etc to have the license >> transferred--or maybe better stated "reissued in the commity state". A >> coworker of mine is >> PE in 3 states and only took exams in one. (ie NC, GA, AL). >> > > That's what I meant. Comity allows for mutual recognition to avoid > having to sit through umpteen exams. But they all want the paperwork and > their fees. I just wonder why the states can't just accept each others > licenses at face value. Guess it's a turf issue and they all want the > money. > > Regards, Joerg > > http://www.analogconsultants.com Among other things it is like MD licensing, it is of intentionally limited portability. Electrical engineers have it better than civil engineers in that comity is near universal (prove registration + pay the additional State's fees and you are in), but for civil's seismic requirements vary much more. -- JosephKKArticle: 95801
On Wed, 25 Jan 2006 17:14:49 +0100, Holger Blum <usenet0106@kennsch.net> wrote: >Hello Brian! > >Brian Drummond wrote: > >> On Sat, 14 Jan 2006 23:00:05 +0100, Holger Blum <usenet0106@kennsch.net> >> wrote: >>>This formula is, apart from a missing parenthesis, ok, but the next one >>>for known coefficients says >>>Output width = ceil(log2(2^(b-1)*abs(sum(coef))*N))+1 >>> >>>Again missing right parenthesis and the N is in my eyes wrong, because >>>it is already included in the sum of coefficients. Could anyone approve >>>this? I have to cite this paper in a thesis in lack of another source >>>for this equation (though it seems to be obvious, but I have to be sure). >> >> >> The coefficients can be both positive and negative, and (for a unity >> gain filter) will typically sum to 1, not N. > >I know. But this formula uses already scaled and quantized coefficients, >so they sum up to a much higher number which then can be taken to >determine the actual width of the output signal (for a DC input signal). If the "much higher number" happens to be a power of 2, this is normal - simply scale the result to unity by selecting bits (effectively a shift). It is equivalent to moving the location of the decimal point (actually binary point). >In my design I have achieved unity gain by scaling the coefficients for >an integer number of used bits and picking the desired active bits from >the full-precision output. I am new to DSP on FPGA, but I think, that >this is the right way. It sounds as though you understand the issues; if your simulations work, that confirms it. - BrianArticle: 95802
On 25 Jan 2006 09:00:56 -0800, "Eric" <dasani8888@hotmail.com> wrote: >Hi, >Read/Write processes are generated by Xilinx EDK when I used >create/import peripheral wizard. I only modified the write process, and >wrote an adding function. Sorry I removed the comments when I posted >the code. But here it is: > > -- Bus2IP_WrCE or Memory Mapped > -- Bus2IP_RdCE Register > -- "1000" C_BASEADDR + 0x0 > -- "0100" C_BASEADDR + 0x4 > -- "0010" C_BASEADDR + 0x8 > -- "0001" C_BASEADDR + 0xC > > slv_reg_write_select <= Bus2IP_WrCE(0 to 2); > slv_reg_read_select <= Bus2IP_RdCE(0 to 2); These select 3 bits (0 to 2) from the 4-bit field in the comment above. Which 3 bits? When you simulate, do you see all 3 strobes going active when they should? - BrianArticle: 95803
On 25 Jan 2006 20:00:26 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: >In article <1138195188.897993.200480@g47g2000cwa.googlegroups.com>, > <fpga_toys@yahoo.com> wrote: >> >>Phil Tomson wrote: >>> But then someone brought up the fate of JHDLBits: apparently the prjoject was >>> squashed by Xilinx. Does anyone have any details about what happened? >>The status from the team a year ago was: >> >> "we are still trying to figure out a schedule with Xilinx >> corporation on the release of the project. [...] >>I've asked a several Xilinx staff about it both on and off the record. >>On the record, >>no reply. Off the record, "it will never happen". The fine print in >>Xilinx tools licenses >>is a claim preventing reverse engineering of the chip layouts and >>databases, even >>though this is clearly visible to the user from several tools ranging >>from the fpga >>editor to the bit stream generator. >So barring any sort of 'creative' solution an XDL manipulation tool would >probably not be doable. I suspect differently. The key phrase from fpgatoys is "P&R to bitstream tool". Xilinx have been ABSOLUTELY consistent on NOT making this public since before the XC6200 came out - the openness of its bitstream was unique at the time. Yet they DO supply XDL - and I don't think they ship it by mistake. That was why my suggestion was to bypass the bitstream translation and work entirely within what Xilinx do provide, instead of breaking the (reasonable or otherwise) terms of the license agreement. Sure there is a theoretical possibility that Xilinx could cease XDL ... but IMO it's more likely to disappear "because nobody uses it" than for the reverse reason. Its survival to date may indicate that it has internal uses, such as tracing obscure NCD bugs. >Perhaps it's possible if the open source tool would have no 'compilation of >database details'? For example, you say that the information needed is >'clearly visible' from the various Xilinx tools themselves. No they aren't. FPGA editor isn't an electron microscope! It portrays a representation of the routing, good enough to manipulate it and diagnose and fix problems, but I think of it more like the London Underground map than an Ordnance Survey (or USGS) map or a satellite photograph. I don't see how compiling information at that level of detail would be a problem. >>They put a lot of energy into the project, then were told to >>shutup and >>walk away. > >Very poor form on Xilinx's part. If "fpgatoys" spin is correct. But then, Xilinx lie about LUT counts, mislead about power consumption, leach off the Open Source movement and probably contribute to global warming too. Or did Xilinx just stop funding the effort? >Just as I said in the other thread: Corporations like control. Xilinx, having >the majority share of the market, especially seems to like control. Perhaps >one of the hungrier vendors would be willing to work with the open source >community. If so, then in the longrun it's Xilinx's loss. Yes, and as Jim Granville says, their customers like control too. So, for an open source effort that wants to succeed, it's probably wise to avoid threatening that control. I think Ray nailed it. If you take the viewpoint of rescuing the world from the evil Xilinx Corporation and their closed bitstream format, they might not appreciate your efforts. (does Austin really have a white cat?) But if you actually use the tools they have made available, you may have a better chance. - BrianArticle: 95804
I'm quite new to this area..I'm completeing a bachelor in electronics..As a part of my project i'm to create a sdram controller for xilinx 11 pro(ff1152) based memec board...Although memory managent is available as a ref design..We are not using the power processor inside.The subsequent modules are in VHDL.Can anyone give me some directions on this one?i'd be grateful..Article: 95805
On 25 Jan 2006 17:32:26 -0800, "Paul Marciano" <pm940@yahoo.com> wrote: > >John Adair wrote: >> You might want to have a look at our product Raggedstone1. It has the much >> larger XC3S400-4FG456C part fitted. Programming cable is included and card >> can be used in a PCI slot or stand-alone with the optional PCI I/O Header. >> Details here http://www.enterpoint.co.uk/moelbryn/raggedstone1.html. > >As a learner and experimenter I like the look of that board, but how >much does the Xilinx PCI core for the Spartan 3 cost? The Xilinx core ... a lot ($1995 for a single project license) But keep watch for an announcement from John A. in the near future... - BrianArticle: 95806
fpga_toys@yahoo.com writes: > In that market Altera > with the Arm core has a clear market edge as most embedded folks are > already Arm experienced, where PPC is still a minority player in the > global embedded market. The Altera Excalibur devices have been a very > interesting pairing in that respect ARM + 20KE fpga and that product > family is certainly going to grow, especially if an open source > partnership develops for it. > Except that the 20KE is *old*. I don't think Altera are going to bring it on, they seem to have decided to push NiosII as their embedded processor and let the hard-cores languish in history... unless you've heard different. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 95807
fpga_toys@yahoo.com writes: > Ray Andraka wrote: > > Seems those who keep yelling for open bit streams aren't bothering to > > look at what is available, or try working with pieces. They all seem to > > want full open bitstream without even understanding what all it entails > > to be able to successfully work with it. You could do pretty much > > everything they seem to be looking to do within the existing XDL > > framework, and it gives the ability to use parts of the existing tools > > so you don't have to develop the entire tool chain from soup to nuts. > > Pick a piece of it and plug it into the existing tools. > > It's not clear that XDL is in fact an official interface that will > avoid a > C&D order from Xilinx .... if it were completely documented, and the > parts data bases behind it completely documented, then your assertion > would be clearly true ... however, it isn't. Some reverse engineering > in unavoidable to use it fully, and that has clear restrictions from > Xilinx. It is documented - in the XDL files it produces. The parts databases are also documented in a fashion, as you can ask the XDL tool to dump them for you in XDL format. And XDL is used by parts of the Xilinx tool flow, so it's unlikely to go away. You should be able to solve all your placement problems with XDL and then feed the results into the router (which will do a reasonable job once it has a good placement). Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 95808
Martin Thompson wrote: > fpga_toys@yahoo.com writes: > > It's not clear that XDL is in fact an official interface that will > > avoid a > > C&D order from Xilinx .... if it were completely documented, and the > > parts data bases behind it completely documented, then your assertion > > would be clearly true ... however, it isn't. Some reverse engineering > > in unavoidable to use it fully, and that has clear restrictions from > > Xilinx. > > It is documented - in the XDL files it produces. The parts databases > are also documented in a fashion, as you can ask the XDL tool to dump > them for you in XDL format. To get those files requires assuming the license terms of non-disclosure. It remains a controlled and propietary format until such a time that Xilinx releases it in a public documents, outside those license terms.Article: 95809
Austin, Sorry if I didn't make it clear - the board already exists and provides a 2.5V supply to the XO, so while LVDS is LVDS, it does matter to us what the supply voltage is. We could hack up the board to change the supply voltage, but would rather not. That's why we want a drop in replacement for the Epson. The first issue is finding one with extended temperature (we can do that) but the problem we have is figuring out in advance if the XO performance will be good enough for the V2Pro's MGTs. Do you have any performance requirement specs for the XO used for the MGTs that we could use in this search? My reason for coming to the group was to find a part others have used with success --- Ron "Austin Lesea" <austin@xilinx.com> wrote in message news:dr8j0r$igb6@xco-news.xilinx.com... > Ron, > > Look for an LVDS output oscillator. > > Then the matter of supply voltage does not matter. > > LVDS is LVDS: does not matter if it runs off of 2.5V, or 3.3V. > > Austin > > Ron Huizen wrote: > >> Does anyone have experience using any oscillators for the MGTs on the >> V2Pro other than the two listed in Xilinx's app note (Epson and >> Pletronics)? >> >> We've always used the Epson part (100, 125, or 156.25 MHz) in the past >> but now need an extended temp version which they don't have, and >> unfortunately the Pletronics part, which does have an extended temp >> version, has a 3.3V supply instead of the 2.5 supply like the Epson. >> >> Ideally, we want a drop in for the Epson, which is a 6 pin 5x7 package, >> pin 1 enable, 2.5V supply. Issues or concern are termination and jitter. >> >> ------------ >> Ron Huizen >> BittWareArticle: 95810
<fpga_toys@yahoo.com> schrieb im Newsbeitrag news:1138281184.454302.70800@g14g2000cwa.googlegroups.com... > > Martin Thompson wrote: >> fpga_toys@yahoo.com writes: >> > It's not clear that XDL is in fact an official interface that will >> > avoid a >> > C&D order from Xilinx .... if it were completely documented, and the >> > parts data bases behind it completely documented, then your assertion >> > would be clearly true ... however, it isn't. Some reverse engineering >> > in unavoidable to use it fully, and that has clear restrictions from >> > Xilinx. >> >> It is documented - in the XDL files it produces. The parts databases >> are also documented in a fashion, as you can ask the XDL tool to dump >> them for you in XDL format. > > To get those files requires assuming the license terms of > non-disclosure. > It remains a controlled and propietary format until such a time that > Xilinx releases it in a public documents, outside those license terms. > there is no non-disclosure just download ISE webpack and run XDL, there is no license above the standard webpack license -- Antti Lukats http://www.xilant.comArticle: 95811
fpga_toys@yahoo.com wrote: > austin wrote: > > They weave a web of untruths and half whispers with convenient > > coincidences to explain their troubles. > > Xilinx's ommissions and the quest for that data is not a cultish > movement. ...snip... > This is not a regligous debate ... this is real engineering up front > for worst > case loads, not tinking in the lab with missguided retrofit cooling. If I were you, I wouldn't worry too much about Austin. He is pretty knowledgeable techincally even if his work with the customer leaves something to be desired. I will say that with some of the stuff that Austin posts, you would think he was a conspiracy theorist. You have posted your concerns and have gotten some responses. The resonse from X seems to be a lot like the way they responded to the data sheet LC count issue in the past. You are not likely to get anything further out of them at this point. As you post more you just feed the trolls (or become one).Article: 95812
Alex Gibson wrote: > How is a company using an open source compiler leaching from open source ? > If the software is placed in/under license where it can be used, what is the > problem > as long as the company follows the license ? There are probably a million different views, some a lot stronger than mine. Taking the windfall profits by basing your product on open source is a real economic gain. And in my mind completely soured by playing hard ball in similar IP areas, such as JHDLBits. The fraction of a percent of the windfall value they recieved by avoiding other commercial OS licenses which was donated to FSF, is completely soured by their inability to also open up some of their IP to open source in the form of JHDLBits. Reading Alex's papers, it's pretty clear there was an expectation to make their project an open source gem ... and I'd be very suprised if multiple Xilinx employees (indluding the contract monitor) were not aware of that intent many months before Xilinx blocked it's release. Given that ERSA'04 was June 21-24, 2004, and two months later the FPL04 was August 30 and September 1, 2004 there was ample time to set the record straight by Xilinx in that time, assuming that a Xilinx person was not part of the paper reviews for these and other conferences where papers were submitted for consideration. Now some would like to assert that the FpgaC project would be free to use the XDL interface, even though it's not formally documented and released outside the strict NDA License terms of the ISE software. That is FALSE, given that the JHDLBits team based their project on the JBits 3.0 SDK and had their open source project completely blocked. I feel that Xilinx made a VERY poor business decision to reap the windfall profits of open source in one hand, and aggressively stop the JHDLBits project from releasing tools based on ISE and JBits SDK. Everyone is free to make up their own minds, but lacking formal clearification by Xilinx about JHDLBits and open sources ability to use ISE tools and interfaces for other projects, the view from my seat is Xilinx has clearly said ANY use of their software products in open source is off limits. Thus making every aspect of the Xilinx product line closed to open source development. When I say they have failed to give back to the community, I specifically mean that they continue to keep their product line off limits for open source development, by failing to openly and clearly document internal interfaces to ISE and related tools like JBits, and exempt those interfaces from the strict license terms. If XDL was freely usable, I'm sure that it wouldn't take much work to retarget the JHDLBits code to that interface .... but I rather suspect that may be the same or equivalent interface they are currently using, and prohibted from releasing Open Source tools based on it. So ... I feel it's pretty poor for Xilinx to take windfall profits by avoiding commercial compiler and OS licenses, than lock open source out of their product. Xilinx staff are free to object ... and we can always toss this discussion into the wider open source community for comment.Article: 95813
A colleague and I have adapted the pci32tlite_oc core from opencores.org to run on raggedstone1. I've also written a Linux driver for it. Both available here: http://projects.varxec.net/doku.php/raggedstone1Article: 95814
<fpga_toys@yahoo.com> schrieb im Newsbeitrag news:1138284941.167890.6900@g47g2000cwa.googlegroups.com... > > Alex Gibson wrote: >> How is a company using an open source compiler leaching from open source >> ? >> If the software is placed in/under license where it can be used, what is >> the >> problem >> as long as the company follows the license ? > > There are probably a million different views, some a lot stronger than > mine. > > Taking the windfall profits by basing your product on open source is a > real > economic gain. And in my mind completely soured by playing hard ball in > similar IP areas, such as JHDLBits. > > The fraction of a percent of the windfall value they recieved by > avoiding > other commercial OS licenses which was donated to FSF, is completely > soured by their inability to also open up some of their IP to open > source > in the form of JHDLBits. > > Reading Alex's papers, it's pretty clear there was an expectation to > make their project an open source gem ... and I'd be very suprised if > multiple Xilinx employees (indluding the contract monitor) were not aware > of > that intent many months before Xilinx blocked it's release. Given that > ERSA'04 was June 21-24, 2004, and two months later the FPL04 was > August 30 and September 1, 2004 there was ample time to set the record > straight by Xilinx in that time, assuming that a Xilinx person was not > part > of the paper reviews for these and other conferences where papers were > submitted for consideration. > > Now some would like to assert that the FpgaC project would be free to > use the XDL interface, even though it's not formally documented and > released outside the strict NDA License terms of the ISE software. That > is FALSE, given that the JHDLBits team based their project on the JBits > 3.0 SDK and had their open source project completely blocked. > > I feel that Xilinx made a VERY poor business decision to reap the > windfall > profits of open source in one hand, and aggressively stop the JHDLBits > project from releasing tools based on ISE and JBits SDK. > > Everyone is free to make up their own minds, but lacking formal > clearification > by Xilinx about JHDLBits and open sources ability to use ISE tools and > interfaces for other projects, the view from my seat is Xilinx has > clearly said ANY use of their software products in open source is off > limits. Thus > making every aspect of the Xilinx product line closed to open source > development. > > When I say they have failed to give back to the community, I > specifically mean that they continue to keep their product line off limits > for open > source development, by failing to openly and clearly document internal > interfaces to ISE and related tools like JBits, and exempt those > interfaces from > the strict license terms. > > If XDL was freely usable, I'm sure that it wouldn't take much work to > retarget the JHDLBits code to that interface .... but I rather suspect > that may > be the same or equivalent interface they are currently using, and > prohibted > from releasing Open Source tools based on it. > > So ... I feel it's pretty poor for Xilinx to take windfall profits by > avoiding commercial compiler and OS licenses, than lock open source out of > their > product. > > Xilinx staff are free to object ... and we can always toss this > discussion into the wider open source community for comment. > Dear whoever you are (hiding under bogus email address): there are different licenses, the JBits license has always beeing a restrictive license so open open-source thing on top JBits could have been violation of the JBits license. XDL is open, and can be used by any means you wish. Xilinx cant stop supporting XDL and cant go after anyone who releases open source tools that use XDL in the process. As long as only the XDL file format is used its ok, but as soon as you release open source software (without Xilinx permit) that actually integrates parts of Xilinx software (like JBits) you may have violated the license and that may have different follow ups. If you think you can do something that has real value, go ahead and do it, there is no need to be afraid that Xilinx comes and stops you or your business. They want. -- Antti Lukats http://www.xilant.comArticle: 95815
I don't think this is off-topic. It certainly relates to FPGAs. Those in the FPU IP market might be interested to learn that it certainly looks like there's going to be one less competitor out there...Article: 95816
Antti Lukats wrote:
> <fpga_toys@yahoo.com> schrieb im Newsbeitrag
> > To get those files requires assuming the license terms of
> > non-disclosure.
> > It remains a controlled and propietary format until such a time that
> > Xilinx releases it in a public documents, outside those license terms.
> >
>
> there is no non-disclosure
>
> just download ISE webpack and run XDL, there is no license above the
> standard webpack license
The standard ISE license contains:
"License. XILINX, Inc. ("XILINX") hereby grants you a nonexclusive
license to use the application, demonstration, and system software
included on this disk, diskette, tape or CD ROM, and related
documentation (the "Software") solely for your use in developing
designs for XILINX Programmable Logic devices. No right is granted
hereunder to use the Software, or its products, to develop designs for
non-XILINX devices. You own the media on which the Software is
recorded, but XILINX and its licensors retain title to the Software and
to any patents, copyrights, trade secrets and other intellectual
property rights therein."
Which clearly A) restricts your use of the software to activities
directly related to programming Xilinx devices, and B) claims full
rights to everything contined in the release. Implictly, derivative
works, that is development based on information disclosed directly or
indirectly in the release, is also restricted. ... AKA documenting
interfaces for open source use, or developing software derived from
this release (software, documentation, files, etc). This is further
clearified with:
"Restrictions. The Software contains copyrighted material, trade
secrets, and other proprietary
information. In order to protect them you may not decompile, reverse
engineer, disassemble, or otherwise reduce the Software to a
human-perceivable form. You agree not for any purpose to transmit the
Software or display the Software's object code on any computer screen
or to make any hard copy memory dumps of the Software's object code.
You may not modify or prepare derivative works of the Software in whole
or in part. You may not publish or disclose the results of any
benchmarking of the Software, or use such results for your own
competing software development activities, without the prior written
permission of Xilinx. You may not make any copies of the Software,
except to the extent necessary to be used on separate non-simultaneous
computers as permitted herein, and one copy of the Software in machine-
readable form for backup purposes only. You must reproduce on each copy
of the Software the copyright and any other proprietary legends that
were on the original copy of the Software."
Which clearly states the licensed material may not be used to prepare
derivative workes, or fairly broadly from the benchmarking provision,
perform competing software development activities based on analysis of
their product (AKA benchmarking).
These are clearly broad and inclusive terms which cover all aspects of
using derived and derivative IP based on materials contained in the
release.
AKA ... no open source access to disclosed interfaces inside this
material.
Article: 95817<fpga_toys@yahoo.com> schrieb im Newsbeitrag news:1138287854.181856.171000@g14g2000cwa.googlegroups.com... > > Antti Lukats wrote: >> <fpga_toys@yahoo.com> schrieb im Newsbeitrag >> > To get those files requires assuming the license terms of >> > non-disclosure. >> > It remains a controlled and propietary format until such a time that >> > Xilinx releases it in a public documents, outside those license terms. >> > >> >> there is no non-disclosure >> >> just download ISE webpack and run XDL, there is no license above the >> standard webpack license > > The standard ISE license contains: [snippped] > These are clearly broad and inclusive terms which cover all aspects of > using derived and derivative IP based on materials contained in the > release. > > AKA ... no open source access to disclosed interfaces inside this > material. > gosh, of course you can not use any interfaces or pieces of the xilinx licensed material. Thats clear. XDL is just an readable ASCII file format. if your tool generates XDL then its ok, as long as you do not use any parts of materials from Xilinx. XDL is meant as interchangeable file format, like EDIF. You can use it if you want. But you must of course be aware of the different license agreement tems, sure. -- Antti Lukats http://www.xilant.comArticle: 95818
I am writing veerilog code for DDR2 SDRAM controller using the micron memory module and I want to implement it on Virtex-4 FPGA.......but I am a new comer to verilog and due to time constraints I am afraid that i won't be able to write the complete code(complete all modules)......so can any one provide me a synthesizable code......the one i cud get from the xilinx web site( reference design) is not synthesizable.....plz helpArticle: 95819
Anand" <thisisandu@gmail.com> schrieb im Newsbeitrag news:1138288572.991824.321210@g44g2000cwa.googlegroups.com... >I am writing veerilog code for DDR2 SDRAM controller using the micron > memory module and I want to implement it on Virtex-4 FPGA.......but I > am a new comer to verilog and due to time constraints I am afraid that > i won't be able to write the complete code(complete all > modules)......so can any one provide me a synthesizable code......the > one i cud get from the xilinx web site( reference design) is not > synthesizable.....plz help > just start Xilinx memory interface generator (MIG) click a few times and you get synthesizeable and work code inclusive FGPA toplevel test fixture. then assing pins in UCF and ready you are! -- Antti Lukats http://www.xilant.comArticle: 95820
Antti Lukats wrote: > <fpga_toys@yahoo.com> schrieb im Newsbeitrag > > AKA ... no open source access to disclosed interfaces inside this > > material. > > gosh, of course you can not use any interfaces or pieces of the xilinx > licensed material. Thats clear. > > XDL is just an readable ASCII file format. if your tool generates XDL then > its ok, as long as you do not use any parts of materials from Xilinx. > > XDL is meant as interchangeable file format, like EDIF. You can use it if > you want. But you must of course be aware of the different license agreement > tems, sure. NO ... absolutely not. EDIF has it's format publicly disclosed. There is no corresponding document for XDL ... so just producing XDL files with open source software would use material under the licenses NDA in voilation of it's terms ... specifically disclosing the file format without permission, and having developed competitive software after express limitiations against such an act. As soon as you emit library blocks in an XDL file, you would disclose proprietary interfaces to their library too, in volation of the NDA protecting their documentation at minimum, if not proprietary device information from their databases. Actually, the license gives you no right to disclose any internal data format, except the resulting programming bit stream. So, unless Xilinx decides to publicly release these file formats, library definitions, and related material ... open source development in support of Xilinx FPGAs is off limits. We have large companies like Sun that do give back to the open source community in the form of IP for use in the community. Open Solaris, Open Office, JAVA are reasonable contributions in exchange for the wind fall that comes from using open source products in a commercial product. That is the standard of conduct. Not the highly restrictive licenses attached to every important Xilinx software tools, document, and interface.Article: 95821
Antti Lukats wrote: > Dear whoever you are (hiding under bogus email address): Get used to it ... even what appear to be real names are not verifiable. > XDL is open, and can be used by any means you wish. Xilinx cant stop > supporting XDL > and cant go after anyone who releases open source tools that use XDL in the > process. I believe this is False, absolutely false. There is no document I'm aware of outside of express Xilinx NDA which describes the file format, the library elements, and their use. Producing such a file from information derived from documentation and use of licensed ISE materials IS (like it or not) completely NDA restricted. If you know of such a document by offically released Xilinx which is not under NDA that describes the file format, library interfaces, and other information needed to produce a valid bit stream, then please post the location of that document here. Pointing ot materials obtained under the licenses NDA does not count ... IE Webpack. Otherwise, it's just wishful thinking. > As long as only the XDL file format is used its ok, but as soon as you > release open source > software (without Xilinx permit) that actually integrates parts of Xilinx > software (like JBits) > you may have violated the license and that may have different follow ups. yes ... which means that just writing software that interfaces to ISE is in violation of the license terms ... IE open source efforts can not do so. > If you think you can do something that has real value, go ahead and do it, > there is > no need to be afraid that Xilinx comes and stops you or your business. They > want. I'm sorry ... but I like my house and my toys ... I will not risk them to a judgement by Xilinx for violating their IP rights. Besides, it's just morally wrong to violate express IP rights of another and hope they will ignore you.Article: 95822
<fpga_toys@yahoo.com> schrieb im Newsbeitrag news:1138289887.289407.179820@o13g2000cwo.googlegroups.com... > > Antti Lukats wrote: >> <fpga_toys@yahoo.com> schrieb im Newsbeitrag >> > AKA ... no open source access to disclosed interfaces inside this >> > material. >> >> gosh, of course you can not use any interfaces or pieces of the xilinx >> licensed material. Thats clear. >> >> XDL is just an readable ASCII file format. if your tool generates XDL >> then >> its ok, as long as you do not use any parts of materials from Xilinx. >> >> XDL is meant as interchangeable file format, like EDIF. You can use it if >> you want. But you must of course be aware of the different license >> agreement >> tems, sure. > > NO ... absolutely not. > > EDIF has it's format publicly disclosed. There is no corresponding > document for XDL ... so just producing XDL files with open source software > would > use material under the licenses NDA in voilation of it's terms ... > specifically disclosing the file format without permission, and having > developed well you really sound paranoid about the issue. If you do some tools that produce XDL and help xilinx to sell their silicon they will not go hunting you down. In how many different ways I have to say that? If you start an open-source project that is totally useless but exposes all xilinx internals they will get upset. And with good cause. -- Antti Lukats http://www.xilant.comArticle: 95823
Hallo, I would insert multichannel opb sdram controller into a project. I would use xcl bus to access read/write datas into a integer matrix. I would know if every time I would perform read/write operations into a element of the matrix I need to: 1) disable data cache 2) init cache with address of matrix element 3) enable cache Is it correct? Following that the system copy the region of sdram into bram cache to perform operations on it? Many Thanks MarcoArticle: 95824
rickman wrote: > You have posted your concerns and have gotten some responses. The > resonse from X seems to be a lot like the way they responded to the > data sheet LC count issue in the past. You are not likely to get > anything further out of them at this point. As you post more you just > feed the trolls (or become one). yep ... the several threads have been useful to discuss difficult problems that Reconfigurable Computing faces with regards to strict IP limitations these folks require, and effectively prohibt open source development with. Calling them to task for heavily using open source in their products, while agressively prohibting open source development for their product line will no doubt hit nearves that may over time lead all the FPGA companies to actually open up to a reasonable degree and reap the rewards of extensive open source development which supports their all sales and greatly enhances their product offerings. Those that leach off open source, while completely blocking open source development for their products, need to be called on the carpet for that, and probably regularly till they get the hint that open source is a TWO way relationship -- they need to give as much IP as they take.
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