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
Well yes actually. The board that is cheaper that a car tank of UK gas. John Adair Enterpoint Ltd. - Home of Raggedstone1. The US$90 Development Board. http://www.enterpoint.co.uk "Jeff" <jeff.ward@gmail.com> wrote in message news:1138218352.156121.236190@f14g2000cwb.googlegroups.com... > Chris, > > I bought the S3 starter board last year for a VHDL senior class > project. I implemented a 32-bit CPU in it, and demonstrated a program > which detected prime numbers on the 8-segment display. The whole > design took about 90% of the chip, but it went smoothly, and for $99, > how can you beat it?! > > However, like Antti said, today I would spring for the S3E for $149. > It has a larger FPGA, more RAM, and a couple more goodies on the board. > The only downside is that they are newly released and you may have > trouble getting ahold of one. > > Cheers, > -Jeff >Article: 95726
Hi -
I kind of like a DDR FF emulation circuit that Gabor described in a
post last May; see the drawing below (please view with fixed-width
fonts). You use two D FFs and three XORs to create the function of a
FF that clocks on both edges. The extra gates at the inputs and
outputs mean that the setup time and CP-to-Q delays suffer somewhat,
but the Q output is glitch-free.
-----------------------.
| |
| __ |
'-\\ \ .--o--. |
|| |------|D S Q'-o-)--.
.--//_/ | | | | |
| .----|> | | | |
| | | R Q| | | |
| | '--o--' | | | __
DIN ------o | | | '--\\ \
| | | | || |- Q
CLK ------)--------o | | ---//_/
| __ | | | |
'--\\ \ | .--o--. | | |
|| |-)----|D S Q'-)-o--'
-//_/ | | | |
| '---o|> | |
| | R Q| |
| '--o--' |
| |
'--------------------'
Me, if my circuit were operating at low speed, I'd probably just use a
2X clock. And I agree with Symon that gating the clock line is
something you do only if you have no other choice, and then only if
you understand the implications (I'm sure Peter understands them, but
those new to design may not).
Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com
and
http://www.sonic.net/~bobperl/blogger/2006/01/clock-gating-just-say-no.html
Article: 95727hutzelbutz wrote: > However, I _do_ like graphical user > interfaces and once everything is set up, I can press one button to run > the complete designflow over and over again... Some people like one, > some the other, no worries, everybody is free. I agree. For my own part, I like the commadn line interface. Once everything is set up, I can type "make", press return, and run the complete designflow over and over again. :-) I find it faster and more convenient to type "make" than to mouse to a button. But that's a matter of personal taste.Article: 95728
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? If >> someone succeeded in developing an open source ecosystem of tools built around >> XDL, would that project also suffer the same fate? (It would be nice to know >> before investing much time and effort in developing tools around XDL) > >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. Xilinx funded the >research and > some parts of the project contained proprietary information, so >we have been > trying to come to an agreement. We are still hoping for a >release sometime > soon." > >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. From what I have been told, any >compilation of >data base details into an open source equivalent P&R to bitstream tool >as was done >by the JHDLBits team will result in a C&D Order from Xilinx. So barring any sort of 'creative' solution an XDL manipulation tool would probably not be doable. 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. So if a tool merely parsed the output of those tools to obtain the information needed it would not have any 'compilation of database details'. The problem of course is that it would make the open source tools dog slow: a design would have to be generated that would be sizeable enough to produce reports containing enough info, then after that it could start fixing the nets in the user's design. Possible, but probably not feasible. > >So, Xilinx let this team proceed, gained a lot of publicity from it as >marketing >collaterial, and then dashed the teams hopes of taking it open source. >I doubt >the team would have partnered with Xilinx had the outcome been clearly >stated >up front. They put a lot of energy into the project, then were told to >shutup and >walk away. Very poor form on Xilinx's part. > >Much of what the FpgaC project needs to support compile, load, and go >for Xilinx >product is trapped in this project, with a clear warning from Xilinx to >stay clear. >The likely outcome is to focus on other vendors which are more willing >to allow >open source investment in RC technologies which support their products. > 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. PhilArticle: 95729
Hi John, I guess it's a matter of tradeoffs: $9 cheaper, but the S3 board has more switches, a VGA output, a serial output, and an PS/2 port. And shipping Raggedstone1 to the US is $45. -JeffArticle: 95730
yyqonline wrote: > I am not sure how to realize the same function (double the frequence of > the clk)? > Maybe some of the FPGA's architecture support this. > Then I would like to know how this circuit perform as far as asic is > concerned? That's exactly where I'd expect to run into problems. It's not too difficult to characterize it in a particular FPGA, but the performance in the FPGA tells you almost nothing about what to expect in an ASIC. Using asynchronous logic in an FPGA leads to trouble, and doing it then expecting it to work the same in an ASIC could lead to a disaster. As others have suggested, unless your transition rate is extremely fast, you're much better off using a clock at a higher rate, a synchronizer (two chained FFs), another FF, and an XOR between the D and Q of that last FF. That will get you a pulse with a width of one clock cycle every time the input transistions.Article: 95731
In article <1138208191.124642.257590@f14g2000cwb.googlegroups.com>, <fpga_toys@yahoo.com> wrote: > >fpga_toys@yahoo.com wrote: >> So, Xilinx let this team proceed, gained a lot of publicity from it as >> marketing >> collaterial, and then dashed the teams hopes of taking it open source. >> I doubt >> the team would have partnered with Xilinx had the outcome been clearly >> stated >> up front. They put a lot of energy into the project, then were told to >> shutup and >> walk away. >> >> Much of what the FpgaC project needs to support compile, load, and go >> for Xilinx >> product is trapped in this project, with a clear warning from Xilinx to >> stay clear. >> The likely outcome is to focus on other vendors which are more willing >> to allow >> open source investment in RC technologies which support their products. > > >I should probably add that Xilinx leaches a hell of a lot of value off >open >source by using Linux as a host platform for it's tools, GCC at the >main >production compiler for PPC core software, GNU for the libraries for >PPC, and Linux in several forms as host operating systems for it's >product offerings. True. > >It's probably worth writing Austin, Peter, and the other regular usenix >posters >from Xilinx and making it clear just how much Xilinx benefits from open >source, the Xilinx market created by open source, and the developers >which >frequently volunteer their time supporting Xilinx open source use. It would take lots of letters to have any impact. > >And then suggest that they take their thumb off the JHDLBits project, >and >start doing a better job of contributing back to the open source >community. >If that isn't enough to get their attention, maybe switching design >wins to >Altera and letting them know why. > But is Altera any more open than Xilinx? I'm not sure that I've seen anything to suggest that they are. PhilArticle: 95732
Antti Lukats wrote: > I have hacked an secured digital sound transmittion standard once a long > time ago. It is amazing what has to be done to digitized voice in order to > hide its nature of being voice data. If you digitize voice at a constant bit rate, any reasonable encryption algorithm with feedback (not ECB mode) will make it impossible to determine that the encrypted data is voice (vs. something else of the same bit rate) unless the attacker has the key or can break the cryptosystem. Single DES (56-bit keey) is not sufficient only because a brute-force key seach is possible. AES, triple DES, or many other algorithms would be suitable. Personally, I would use triple DES, as DES has withstood much more cryptanalysis than has yet been applied to AES. The real problem with secure voice communication is not the encryption per se; for practical purposes that is a solved problem. The major difficulty is key distribution; if you don't do that well, the system will be susceptible to man-in-the-middle attacks. EricArticle: 95733
I have a problem with license file generated from altera.com for the MAX+plus II 10.2. Id does not include VHDL/Verilog/FLEX8000 support so its useless :(. Is there any way to use those chips? I'v already got quite a few of EPF84282A in nice boards with 512KB of ram and want to learn FPGA on a cheap. I just tried "MAX+PLUS II software for students & universities" instead of "MAX+PLUS II BASELINE software" and was able to generate license with VHDL/Verilog support, but still no FLEX8000 :( -- I really have no idea what this means. And since I can't install linux on it, I'm gonna go back to surfing pr0n. the penguins are psychotic / just smile and waveArticle: 95734
Chris.Gammell@gmail.com writes: > Just wondering if anyone has tried out the Spartan-3 starter board > offered on Xilinx's website (the 99 dollar one). Yes. It's quite a good value. > If so, how is the speed/capacity for your needs? For my needs, it was fast enough, and the size of the part was sufficient for a lot of the things I do. I ended up buying the same board with a larger chip (XC3S1000) from Digilent for $150 in order to fit a few of my largest projects. > How about the simplified JTAG interface, does that perform OK? I'm not sure what's "simplified" about it, but the supplied cable (equivalent to a Xilinx Parallel Cable III) works just fine. EricArticle: 95735
I'll admit shipping is an issue and we have brought it down a lot based on the numbers we are moving we now have much better rates to us from our courier. That shipping is usually next day if we get an order early in the UK day. We may be able to extend the low cost ship that we use in Europe to US but as yet we don't know what issues we might have in customs clearance. But if guys in the US buy more well it might get a lot better. After all the large players in distribution like DIGI-KEY ship to us for free on orders over $180. A bit ironic as we end up shipping a lot of the parts back on a board to the US more often than not. Out interest what does a typical US distributor charge for carriage? The functionality bits differences are now mainly covered by our add-on modules. We are putting together a competative bundles of modules that will be announced soon. They will be extra but you still get better value in my opinion with our bundles. Website photos of the first modules to be released have been done and should appear on our website in the next couple of days. Some pricing too. Another thing worth mentioning is that if a group of students, or college, get together they can buy a UAP pack of 5,10,20 etc boards at discount of any of our products including the Raggedstone1. The Raggedstone1 specials (XC3S1000,XC3S1500, XC3S2000) will also be made available under this program too TBA. They won't be released otherwise than in bulk buys from strategic customer or in our forthcoming competitions. Also carriage on group buys drops the unit carriage effectively by a lot when spread over say 5 units which is about US$70-80 from my rusty memory so worth doing. We are considering having a US distributor, or division, to handle the level of sales we have in your area but that is probably a while off yet. John Adair Enterpoint Ltd. - Home of UAP - University Access Program. http://www.enterpoint.co.uk "Jeff" <jeff.ward@gmail.com> wrote in message news:1138219349.466762.179790@g14g2000cwa.googlegroups.com... > Hi John, > > I guess it's a matter of tradeoffs: $9 cheaper, but the S3 board has > more switches, a VGA output, a serial output, and an PS/2 port. > > And shipping Raggedstone1 to the US is $45. > > -Jeff >Article: 95736
On Wed, 25 Jan 2006 21:19:55 +0100, hackbox.info <hackbox.info@gmail.com> wrote: > for anybody ever interested, inserting this to license.dat seems to work FEATURE maxplus2_6K_8K alterad 2010.01 permanent uncounted HOSTID=ANY SIGN=C 3D03989960D8228 -- I really have no idea what this means. And since I can't install linux on it, I'm gonna go back to surfing pr0n. the penguins are psychotic / just smile and waveArticle: 95737
allanherriman@hotmail.com ha scritto: > Dave Feustel wrote: > >>I am no longer running Windows. Are there any open source programs >>for programming fpgas? I know about Icarus, but I don't think that >>program actually programs chips. > > > I know of no good (*) open source simulators or synthesis tools. > You can forget about the back end tools - there are compelling reasons > for these to be completely closed. think to consider ghdl for vhdl simulation. I use it dayly and it is capable to compile the Xilinx unisim library and almost all simprim (except dsp48) so you can use it for rtl design and even for post synthesys and post map simulation. > > I suggest you drop your dogma, and use some of the many low cost or > free (beer) tools, or learn about Wine (assuming you have an x86 > machine). > > (*) other people may regard certain offerings (e.g. Icarus) as good. > YMMV. > > Regards, > Allan >Article: 95738
fpga_toys@yahoo.com wrote: > Ray Andraka wrote: > >>Why is it so hard to justify. One could argue that you can't use 100% >>of a microprocessor either. Any given instruction leaves part of the >>microprocessor idle: it is impossible to use all of the features all of >>the time. > > > First, apples and oranges and cow pucky comparison. It's not about > leaving unused resources idle, it's about not idling used resources, > which is exactly the problem here. Good compilers get well inside of > 99.x% efficiency for code to hardware fit in terms of the application > for most architectures. Even poor compilers tend to get better than a > 90% fit. When it's only possible to get a 50%, or less fit, by your > standards in an fpga for the primary execution path netlist, that is a > HUGE derate. Most good compilers pack pipelines with very, very, very > few wasted cycles for nearly 100% hardware effieciency for the > application. The goal, is to reach similar efficient pipeline packing > on FPGA's, and waste few if any resources in the process. I agree with > your argument, that the existing Xilinx fpga's and tools will not yeild > close to 100%, and we need to derate that expectation that we carry > forward from traditional instruction set pipeline packing experience. > You are the Xilinx expert here, and if you claim less than 50% packing > efficiency with Xilinx product ... I'm not going to stand here and > argue with you about that. > > I will argue, that given better integration to a different place and > route tool, such as that contained in JHDLbits, that FpgaC can do > significantly better than "less than 50% efficiency/utililization" of > LUT/FF based resources for a large number of unrolled loop > applications, such a finite difference modeling, RC5 code cracking, and > other dense unrolled loop pipelines which are common in the industry as > threaded/MPI/PVM multiprocessor applications. > I think you missed my point. The FPGA is not a processor, and its design is circuit design, not a one dimensional sequencing of instructions. As I mentioned an FPGA offers many more degrees of freedom. That translates directly into more design 'corners'. It is not possible to simultaneously hit all of them. That's the price of freedom. Have you used JHDL? The higher densities you suggest do take more work to achieve, and come about through using placed macros. The same can be done using the xilinx tools by building a hierarchical library of placed macros. There is nothing inherent in the tools preventing this, but as I have said, it takes more design effort to get there. There is no magic bullet regardless of who developed the tools. BTW, the efficiency I was referring to on a uP is the utilization of the gates. Each instruction only uses a fraction of the logic in the uP; the rest is idled. I only brought that up in an attempt to level the field between the two. You really can't compare them.Article: 95739
Marco wrote: > Hi, on page 25 of DS099-3 Spartan3 DC and Switching Characteristics, > there's a a formula for the maximum number of SSOs allowed within an > I/O bank. I have a XC3S200FT256 working in LVCMOS33 standard (fast, > 2mA), its table 22 value is 3, while its table 23 value is 44. Do I > really have a limit of 3x44=132 SSOs for each bank? This value excedes > by far the number of pin per bank in this package... It is "reasonable" > for output currents of 24mA or 16mA, where it limits the SSOs to 9 and > 21 respectively. > This post is only to check if what I found is correct or if I'm wrong. > Thanks, Marco Your calculations are correct. It essentially means that you can safely switch all outputs in a bank using the LVCMOS33, 2 mA, FAST I/O standard. If your performance and DC current requirements are met, it's generally best to use the weakest output driver possible. It generally results in improved signal integrity (more SSOs allowed, drive a PCB trace further without worrying about transmission line effects, etc.). In cases where you mix I/O standards in the same bank, there are benefits to knowing how much additional "headroom" that you have for a given standard. See XAPP689 for additional details. http://www.xilinx.com/bvdocs/appnotes/xapp689.pdf --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 95740
Paul Marciano wrote: > Peter Alfke wrote: > >>The circuit is reliable, although the generated pulse width is >>determined by gate delays. But it is self-compensating, since the clock >>pulse will not end until the flip-flop has toggled. It's kind of >>clever, if I am allowed to say so... >>Peter Alfke > > > Peter, > > Newbie question - I remember seeing an edge detector made up from a > single XOR gate and a few inverters to add a propagation delay, but no > registers. > > Would such a circuit be equivalent to yours? Any pros/cons either way? The idea of the register, is you get some register-dependance time into the system, as the CLK will eventually be used to CLK registers - but otherwise the ideas are similar. The risk I see, is on large CLK trees, and very nimble registers - you really need to get the CLK tree delay 'into the loop' If the OP has a 640KHz SqW signal, and wants to keep it low risk, simple to analyze, and avoid the complexity of faster clocks, he could use 1 x 74HC1G97/1G98 Single Gate logic device externally, Wired as a XOR or XNOR, with a RC delay on one IP of 100~200ns. ( ie as above ) These devices have Schmitt inbuilt. Use the leading edge as CLK, as the trailing edge will be RC determined, and it will move slightly on each 'phase' with HL and LH thresholds. Choose XNOR or XOR gate, depending on which edge you require. -jgArticle: 95741
I won't comment on the usefulness of the board, as I'm highly biased. :-) Just FYI, the Spartan-3 Starter Kit is now bundled with the CPLD Design Kit for $99. http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-SPAR3-CPLD-DK IMHO, for new FPGA or CPLD users or those new to digital design, this bundle is fairly easy to use. The FPGA board includes easy-to-use asynchronous SRAM. There is a more advanced board, the Spartan-3E Starter Kit Board, for $149 that includes DDR SDRAM, parallel Flash, SPI serial Flash, etc. However, it is also more difficult to use for new users. This board is primarily targetted to more advanced designs and to embedded processor (i.e. MicroBlaze) applications. http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-SPAR3E-SK-US There are also a variety of Spartan-3/-3E boards provided by third-party companies. Depending on your application needs or interests, one of these boards may include other interfaces or capabilities that you want. Take a look also at the following list, although I'm sure that it does not include all the various vendors. http://www.xilinx.com/xlnx/xebiz/productview.jsp?category=-21488 --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 95742
Ray Andraka wrote: > BTW, the efficiency I was referring to on a uP is the utilization of the > gates. Each instruction only uses a fraction of the logic in the uP; > the rest is idled. I only brought that up in an attempt to level the > field between the two. You really can't compare them. I did understand, and objected to this assertion. I'm half EE and half computer science, and have worked both fields for 35 years. The way to get a huge bang for the buck with RC is to generate hundreds, or thousands of mini state machine driven dedicated function processors, much is the same way as you build pipelines of dedicated function processing elements for DSP on FPGAs with distributed arithmetic. You drop them into the fpga as a mesh fabric for 2D algorithms, as a pipeline for 1D algorithms, and even as a flattened 3D mesh if necessary. Highly regular connectivity, short routing, and locally optimal placement are all not just possible, but highly likely, with the right tools. Specialized array processing applications are likely targets. Most of the demos I've worked with fill an fpga, and have a VERY small number of idle LUTs. It's been painful to get par to do the right thing, thus my frustration with the existing tools, and a growing understanding of why they are what they are, and why that is wrong for where we are heading and how our usage fundamentially is different that the current tool chains design strategies. FPGAs are a poor fit for non specialized functions which are largely sequentlal and lack any dominate computational kernel, with a few exceptions. Others like wire speed network stacks and applications which can be pipelined, and similar application structures with streaming data are a strong fit with high degrees of parallism from the pipelined streaming data. There are a few other cases, most of which also exploit either replication or pipelining with streaming data. Any where we can disconnect from sequential memory operations to distributed LUT/FF memory with well defined operations in parallel is a good fit. I suspect we will find others as well, as our experience builds with this technology. Addtions planned for FpgaC over the next year all target functionality to support applications with this profile. The distributed arithmetic to support finite difference kernels and matrix operations are high on my list, for the same reasons as they have been hugely sucessful in the DSP community. If you review the feature requests in the fpgac project on sourceforge, you will find the start of a laundry list of things we need to address over the next year to reach long term goals. Those goals include automatic partitioning of applications between netlists and more traditional processors or virtual machines (p-code or java vm like) to get the best resource utilitization for parallel sections of code, and sequential non-pipelinable code sections. This is a very large project to be incrementally implemented over a period maybe as long as several years. Some of it is well defined applications of traditional practice to fpga computing, other parts of it are in effect research projects as we break new ground to address problems with the technology, problems with mapping existing practice to this technology, and just new ground where new uses or new implementations fundamentally require a change in existing practice for fpga computing. For the same reasons that it's futile to invest much energy into assembly language program optimizations, we view hand optimization of placement and netlists a very poor practice. That same energy invested into incremental improvements in the tool chain, from compiler to bitstream generation tools will yield long term benifits and push the state of art until deminishing returns is reached at high utilitization and high degrees of overall efficiency. It's not going to happen over night, we don't have all the answers today, but I'm certain that none of the road blocks visible today are long term problems.Article: 95743
Note also you can buy the S3 board directly from Digilent (http://www.digilentinc.com), and they give you the option of upgrading to a XC3S400 or XC3S1000. Looks like it includes the power supply and cable, but you probably need to download the webpack software yourself.Article: 95744
Leon wrote: > :-) wrote: > >>Hi I will play around with XC95xxx and I'm wondering if someone can >>tell me if the parallel JTAG cable schematic found in the documentation >>is worth to build ... > > > You'd be better off just buying the Digilent JTAG3 cable: > > http://www.digilentinc.com > > At $12, it's just not worth building your own. One was supplied with > the Digilent Spartan-3 kit I've got, it works very well. > The price is for the cable is good, but they will charge me $18us to send it in Quebec Canada. They used at it seems Global Express Mail and UPS ( it's a no go for UPS, they usually charge you $50 for every thing passing the border...). Weather forecast for the week seem not good I'll maybe build a proto for the xilinx free cable . > >>I'm also looking for supplier of PLCC to DIP socket adapter, I know >>Aries makes somes , any others cheap supplier ? > > > Why not simply use a PLCC socket like I did: > > http://www.geocities.com/leon_heller/pld_starter.html > Yes that what I'm gonna do. Thanks for your info :-) > Leon >Article: 95745
Thanks for all replies. It much more clear now. -- unArticle: 95746
In article <1138199130.162720.321920@g44g2000cwa.googlegroups.com>, Chris.Gammell@gmail.com wrote: > Hey All, > > Just wondering if anyone has tried out the Spartan-3 starter board > offered on Xilinx's website (the 99 dollar one). I am a student > developing a project on an FPGA and that seemed like the most cost > effective option for me. Has anyone tried it? If so, how is the > speed/capacity for your needs? How about the simplified JTAG interface, > does that perform OK? Thanks in advance and I look forward to hearing > from you. > > Chris xess.com also offers inexpensive xilinx based boards.. Same price range as digilents, but not as many on board features ( but they are smaller.. its a tradeoff )Article: 95747
Let me rephrase my question. I have a fpga pci card with a dual pci bridge between the virtex II pro and the pci bus of the host computer to which this card is connected. The processor bus connects fpga with the bridge. The dual pci bridge from tundra is dma capable. I have changed a core (A processor bus master/slave) in the fpga to provide this dma functionality. My aim is to transfer data from the fpga to the host memory. I can provide the source address which is an address of a location inside the fpga. Now my problem is that what should be the destination address ? I have to send the data to the host RAM. Since this address has to be pre decided before a transaction can begin how can I get this value in the fpga so that I can program this from the fpga.Article: 95748
In article <dr8h4b$1480$1@f04n12.cac.psu.edu>, Eli Hughes <emh203@psu.edu> wrote: >fpga_toys@yahoo.com wrote: >> Eli Hughes wrote: >> >>>Don't waste your time. Vendor's spend a *VERY* long time working out >>>bugs in their software. With the level of complexity of an FPGA, you >>>don't want to waste time with buggy software that is developed in >>>someone else's spare time. All of the actually chip programming, >>>routing stuff is vendor locked(for good reason), so your out of luck on >>>that. >>> >>>That being said, Xilinx does offer their software for Linux. It is not >>>opensource but it does give you a non-windows alternative. >> >> >> Eli ... the open source community does as well. It's rather an insult >> against those of us that do volunteer our time toward open source >> project to brashly brand open source that way. >> >> Consider that Xilinx believes the Linux is a stable platform for it >> tools, >> is it not? Consider thart Xilinx uses the GCC compiler for it's PPC >> support, does it not? Consider that Xilinx uses the GNU libraries on >> the PPC, does it not? >> >> The only thing here that is wrong, is that Xilinx leaches off the backs >> of open source developers, then asserts prioprietary rights to open >> source efforts to do a BETER job at place, route, and bit steam >> generation. At least other mainstream corporations have the good >> sense to both embrace open source in their product offerings, and >> give back to the open source community at the same time. >> >> See the what happened to JHDLBits thread. >> >> John >> FpgaC developer >> > > >My aim was not to insult. I am aware of alot of quality open source >applications. > >I agree that Xilinx does use open source tools like GCC and what not >because of their quality but I think open source FPGA tools may be a >little different. For it to work out, Xilinx would have to give away >the gut of the parts so people could write applications properly. This >would pose an issue with other companies such as brand 'A' to just take >their IP. That is their business, to develop the best guts. But they've already got plenty of patents on that IP so it's not like someone could reverse engineer the bitstream and then just copy. Actually, I'm not convinced that you _can_ determine a lot from a bitstream format. Now, as has been said elsewhere in this thread, a lot of those patents start expiring in this decade. At any rate, it seems clear that Xilinx would not be in any way helpful to open source efforts to create alternative tools. PhilArticle: 95749
It is only for other items you want to store in Platform Flash like say some config data. Nothing to do with the FPGA load itself other than sharing the loading prom. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Xavier T" <xavier.tastet@gmail.com> wrote in message news:1138141209.271572.221810@g14g2000cwa.googlegroups.com... > Hi John ! > I checked the XAPP 684, and don't see where it deals with fpga > programming... > Maybe I read it too fast > X. >
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