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
toys, I know you do not agree with me, but the market voted, and we saw no $. You can have a different opinion of what happened, and why, but since I was there, and I saw it all happen, I hope you will respect that I might be right. I certainly acknowledge the difficulties imposed by the license, but I do not agree that the license terms was the 'kiss of death'. Austin fpga_toys@yahoo.com wrote: > Austin Lesea wrote: > >>Sean, >> >>'JBits' was a great academic project (lots of degrees and happy grad >>students and advisors), and was seen as the solution for reconfigurable >>computing. >> >>It failed. Commercial flop. End of story. >> >>As with anything else that fails (like the xc6200), it is dead and gone, >>yet there are those who loved it, and can't seem to realize that it is >>no more... >> >>C'est domage, et triste: c'est la vie. > > > > Nothing like insulting a bunch of xilinx reconfigrable computing > advocates by calling them, and their pet projects which need JBits, > failures because it didn't have a commercial, billion dollar market > success. I think it's a chicken and egg problem ... the success and > failure, is because Xilinx has not really allowed people to use those > interfaces, by keeping them tightly locked up with NDA terms which > might be important for tightly controlling information between > corporate customers, but is the death of open academic development tied > to open source deliveries. > > Given the number of other academic programs which are built on JBits, > and the unique access it provides, and the slow emergance of > reconfigurable computing due to device costs and lack of low level > access to the parts by open source developers, maybe the real problem > is that the Xilinx corporate culture hasn't been able to decide to open > up enough that people really can do reconfigurable computing and fully > exploit the low level interfaces necessary for it. >Article: 98051
toys, Open FPGA_Editor. Start a new project for a part. Add nothing (or maybe an output pin that drives a '1'). Write out the .ncd. That is the 'empty' design, with all rules checked and met. Start from there. Austin fpga_toys@yahoo.com wrote: > Austin Lesea wrote: > >>Chris, >> >>Have you looked at the device in FPGA_Editor? >> >>You should. > > > It would be nice if the fpga editor would allow you to start it without > a design loaded, select the device that you want to explore/edit/design > with, go into edit mode, and save the resulting design from the editing > (if any). Or open an existing design, and be able to extend it by > editing iob's and slices that do not have design elements loaded. ... > but that is another point ... > >>From the posters second question, it's likely he's not familar with how > to operate fpga editor. > > Actually just looking at it probably will not answer his question, as > the defaults don't show you very much. He needs to get close in, turn > on all the resources (as many are turned off to reduce the visual > clutter), and put it in edit mode. IE from the tool bar, where the > yellow controls are: > > 1) turn on local lines > > 2) turn on long lines > > 3) turn on pin wires > > 4) turn on Pips > > 5) turn on switch boxes > > Then from the loaded design, select a site entry from list 1, click on > the red find tool to zoom in on it, then zoom out one or two steps and > look around that are in detail. > > start clicking on the circles at the edges of the switch boxes to see > the connection resources available, and open up the clb and iob blocks > that have design elements to see the internal connections. >Article: 98052
Matt, If you use a a cpld, you need to post in comp.arch.cpld Austin Matt Clement wrote: > Hey guys/gals > > What are the advantages and disadvantages of using a CPLD instead of using > an FPGA for a design? > > Thanks > >Article: 98053
"Matt Clement" <clement@nanotechsys.com> wrote in message news:Qp1Of.111$eP4.86@trnddc05... > Hey guys/gals > > What are the advantages and disadvantages of using a CPLD instead of using > an FPGA for a design? > > Thanks > > lower cost, less power consumption, smaller size, easier configurationArticle: 98054
Steve Lass wrote: > It's great to see so much interest in partial reconfiguration. I posted on > Feb 14, but mayby wasn't clear. We have developed new tools and a new flow > for partial reconfig. That software works with ISE 8.1i, but is not > included with > ISE 8.1i. You need to contact your local FAE to get the software. It's more than new software that is needed. It's a new Xilinx corporate culture that will stand behind anyone that puts there job on the line to use it. Read this entire thread. Xilinx talks about it, demonstrates it, but consistantly fails to deliver it. Given this history, would you put your job on the line by suggesting using it in a low-medium volume commerical product where Xilinx doesn't have the ring in their nose to fix your problems quickly ... rather than say well, nobody elese has that problem, it's not worth the investment to fix our offering, maybe in some future release? But more importantly, the company completely blocks open source from having access to the hardware details to deliver what is needed for RC, so that anyone that does want to stick their neck out for such a commercial project, at least has control over fixing their tools when they fail. There is a reason GCC, Linux, and many other successful open source projects have left their commercial counter parts in the dust. Support. Real support for important "LITTLE" details that do not have commercial high volume demand to get them fixed by cost/revenue driven priority sorting of "LITTLE" bugs. The tools team at Xilinx seems (from an outside perspective) to have two priorities: 1) new device support 2) major customer showstopper (blocked shipments) bugs. everything else falls by the wayside with cost/benefit sorting RC needs FPGA's to be as open and completely usable is their processor counter parts .... and that is every bit of the instruction stream needs to be openly documented ... which means that every bit of a configuration stream needs to be openly documented. Till then, both PR and RC are held hostage, and being purposefully killed, because Xilinx lacks the resources to fix the "LITTLE" bugs for the LITTLE customers.Article: 98055
Austin Lesea wrote: > toys, > > I know you do not agree with me, but the market voted, and we saw no $. > > You can have a different opinion of what happened, and why, but since I > was there, and I saw it all happen, I hope you will respect that I might > be right. > > I certainly acknowledge the difficulties imposed by the license, but I > do not agree that the license terms was the 'kiss of death'. > > Austin You can continue to insult me with the "toys" slur, but the fact remains, PR and RC have been broken in Xilinx's tools all along, and the priority to fix the PR and RC tools problems has been lacking .... as clearly stated by other posters in this thread. Xilinx refuses to open up access to allow an alternate tool chain to be developed specifically to support PR and RC demands that are not part of your high volume customers needs. Real PR and RC on Xilinx product is dead, because Xilinx killed it BEFORE it could become a commercial success. Reconfigurable Computing must have open access to bit streams, with tools that can place and route on the fly, with reliable and easy to manage partial configuration. Fixed location tiles do not allow dynamic linking of netlists for execution .... it only allows 1960's style overlays with addresses fixed as link (place and route) time. It does not allow for modular fitting netlists to the execution device at run time -- it requires relinking (replace and routing) every executable netlist for each and every device. When it comes to RC, Xilinx is thinking fixed configuration (batch OS days mentality of manually configured job streams) rather than modern dynamically loadable multitasking multiprocessor systems design.Article: 98056
Austin Lesea wrote: > toys, > > Open FPGA_Editor. Start a new project for a part. Add nothing (or > maybe an output pin that drives a '1'). > > Write out the .ncd. That is the 'empty' design, with all rules checked > and met. > > Start from there. > > Austin Maybe that's fixed in current release .... I just get: /home/jbass/bin/fpga_editor: line 5: 26156 Segmentation fault /raid/xilinx/bin/lin/fpga_editor $*Article: 98057
There is a big difference in logic capabilities. Let's express that in the number of flip-flops or registers: CPLDs are good for up to 200 flip-flops, they get disproportionally expensive for larger designs. Modern FPGAs start at 2,000 flip-flops, and go up to to 200,000 flip-flops, plus many other circuits, like RAM, multipliers etc. CoolRunner CPLDs offer extremely low power consumption, and small physical size, and low cost for the smallest parts. FPGAs fit a much wider range of applications. The choice between the two technologies is usually quite clear-cut. Peter Alfke, Xilinx Applications ===================================== Matt Clement wrote: > Hey guys/gals > > What are the advantages and disadvantages of using a CPLD instead of using > an FPGA for a design? > > ThanksArticle: 98058
fpga_toys@yahoo.com wrote: > Maybe that's fixed in current release .... I just get: > > /home/jbass/bin/fpga_editor: line 5: 26156 Segmentation fault > /raid/xilinx/bin/lin/fpga_editor $* If that were an open source tool, I would open it in the source code debugger, fix the bug, and a few minutes or few hours later, actually experience a tool that doesn't crap out on something that is'nt mainstream everybody uses it feature.Article: 98059
Sigh, Well, I tried to communicate again. And supply an alternate viewpoint (which is most likely correct). I apologize to the newsgroup. AustinArticle: 98060
Steve, Don't bother. "toys" blames us for his failure. It is unlikely he will do anything but flame us every chance he gets. AustinArticle: 98061
toys, Do you have a case number? Austin fpga_toys@yahoo.com wrote: > Austin Lesea wrote: > >>toys, >> >>Open FPGA_Editor. Start a new project for a part. Add nothing (or >>maybe an output pin that drives a '1'). >> >>Write out the .ncd. That is the 'empty' design, with all rules checked >>and met. >> >>Start from there. >> >>Austin > > > Maybe that's fixed in current release .... I just get: > > /home/jbass/bin/fpga_editor: line 5: 26156 Segmentation fault > /raid/xilinx/bin/lin/fpga_editor $* >Article: 98062
<ignore> fpga_toys@yahoo.com wrote: > fpga_toys@yahoo.com wrote: > >>Maybe that's fixed in current release .... I just get: >> >>/home/jbass/bin/fpga_editor: line 5: 26156 Segmentation fault >>/raid/xilinx/bin/lin/fpga_editor $* > > > If that were an open source tool, I would open it in the source code > debugger, fix the bug, and a few minutes or few hours later, actually > experience a tool that doesn't crap out on something that is'nt > mainstream everybody uses it feature. >Article: 98063
Dear EDK experts, I have a top-level ISE project with an EDK subsystem. In that top-level design I have a state machine, which has very little to do with the processor subsystem, but requires several bits for control. What would be the most natural way of doing this? The options I am aware of are as follows: 1. Make the state machine a custom OPB peripheral; 2. Control it with an OPB_GPIO module; 3. Control it through DCR; 4. Fully-custom control logic on the OPB bus. The GPIO approach seems the easiest to me (perhaps because I've never tried using DCR), but I would like to know what others do in such cases. Thanks, /MikhailArticle: 98064
zhangweidai@gmail.com wrote: > I have a Spartan 3 starter kit. Im going to build an expansion board > that will have some more components on it. does anyone know where i can > get some examples? or guides to do this? i know im going to use a > standard 2x20 right male connector, and i the pin functions. but an > example board would be most helpful. i also want to attach some sma > connectors on it to get testpoints. > > the plan might be.... build pcb layout, have expert review design, > produce gerber, and send to be printed. someone recommended 33each.com > > pz > If you are using Digilent's Spartan-3 Starter Kit, then a word of warning: Most (or at least many) of the pins on expansion connectors are located in various IO-blocks that contain also the pins connected to the development board's leds, 7-segment display, push-buttons, slide-switches and what else. And as these use only 2.5 V levels, you have to use IOSTANDARD = LVCMOS25 also for your own I/O-pins in the expansion connector, as one cannot assign different levels to the pins in ONE and SAME IOB. (I realized this only when the ISE started giving error messages about different voltage levels...) What I built is a simple opto-isolator card, with which I can control (not very fast though, because of the optos...) my TTL-level contraptions without fearing frying the Spartan-3. There are 16 output-lines and 8 input-lines, and I use the B1-expansion connector, because its pins are not shared with SRAM (A2 would work as well). I built this on a stripboard, with almost all the components sitting in DIL-16 sockets (except the regulator which feeds the 5V-side of the board). If I had a digicamera at hand, I would post a photo of it... I guess you have the user's guide which details the pins. If not, then the copy can be found at Xilinx' site: http://www.xilinx.com/bvdocs/userguides/ug130.pdf And indeed, Digilent has many nice expansion boards: http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Accessory&Cat=Accessory and http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Peripheral&Cat=Peripheral Cheers, Antti KarttunenArticle: 98065
MM wrote: > Dear EDK experts, > > I have a top-level ISE project with an EDK subsystem. In that top-level > design I have a state machine, which has very little to do with the > processor subsystem, but requires several bits for control. What would be > the most natural way of doing this? The options I am aware of are as > follows: > > 1. Make the state machine a custom OPB peripheral; > 2. Control it with an OPB_GPIO module; > 3. Control it through DCR; > 4. Fully-custom control logic on the OPB bus. If it's microblaze, FSL can be a choice (for DCR on microblaze you would require a opb2dcr bridge iirc so fsl is lighter). SylvainArticle: 98066
Austin Lesea wrote: > "toys" blames us for his failure. > > It is unlikely he will do anything but flame us every chance he gets. > > Austin And just what failure is that? Or is that just another of your insults to customers today?Article: 98067
<fpga_toys@yahoo.com> wrote in message news:1141430497.903677.289420@i39g2000cwa.googlegroups.com... > > Austin Lesea wrote: >> "toys" blames us for his failure. >> >> It is unlikely he will do anything but flame us every chance he gets. >> >> Austin > > And just what failure is that? > > Or is that just another of your insults to customers today? Dear sir (since your name is a slur), Please consider that your passionate dissertations on this newsgroup in the past on how Xilinx has ignored the customers and the open source community at large by profiting off the back of open source developers before them may put off an employee or two of the company you directly lambasted. I have grown to not bother reading your posts most of the time because the complain/information ratio is way too high for my tastes. Feel free to continue posting in the manner you do but know that it doesn't reflect well on the continuing contributions you may be able to make in this forum. Thanks for your time, - John HandworkArticle: 98068
John_H wrote: > Please consider that your passionate dissertations on this newsgroup in the > past on how Xilinx has ignored the customers and the open source community > at large by profiting off the back of open source developers before them may > put off an employee or two of the company you directly lambasted. That they are hyper sensitive to the truth is my fault? We had a long discussion, that clearly ended up with the agreement that Xilinx's NDA terms block Open Source access while they use it for profit to avoid paying developers to provide development tools and operating systems for their PPC core products. And that is a justification for Austin and Peter to then purposefully start attacking me personally to deflect the discussion away from their employer? Austin falsely claims I'm blaming them for "my failures" to shift the discussion. I don't see any discussion of my failures, or my blaming them for any failure I've had. I do see a number of other posters in this thread raising the same concerns I have. I don't see their concerns being addressed. This isn't personal. ... this is about the facts. Let's talk about the facts. Let's talk about the real issues. Let's move past this personal BS. So, do you have anything material to offer the discussion?Article: 98069
fpga_toys@yahoo.com wrote: > Austin Lesea wrote: > >>toys, >> >>I know you do not agree with me, but the market voted, and we saw no $. >> >>You can have a different opinion of what happened, and why, but since I >>was there, and I saw it all happen, I hope you will respect that I might >>be right. >> >>I certainly acknowledge the difficulties imposed by the license, but I >>do not agree that the license terms was the 'kiss of death'. >> >>Austin > > > You can continue to insult me with the "toys" slur, but the fact > remains, PR and RC have been broken in Xilinx's tools all along, and > the priority to fix the PR and RC tools problems has been lacking .... > as clearly stated by other posters in this thread. Xilinx refuses to > open up access to allow an alternate tool chain to be developed > specifically to support PR and RC demands that are not part of your > high volume customers needs. > > Real PR and RC on Xilinx product is dead, because Xilinx killed it > BEFORE it could become a commercial success. > > Reconfigurable Computing must have open access to bit streams, with > tools that can place and route on the fly, with reliable and easy to > manage partial configuration. Fixed location tiles do not allow > dynamic linking of netlists for execution .... it only allows 1960's > style overlays with addresses fixed as link (place and route) time. It > does not allow for modular fitting netlists to the execution device at > run time -- it requires relinking (replace and routing) every > executable netlist for each and every device. > > When it comes to RC, Xilinx is thinking fixed configuration (batch OS > days mentality of manually configured job streams) rather than modern > dynamically loadable multitasking multiprocessor systems design. > Partial reconfiguration is a very difficult problem to solve in software, and it requires tons of man-hours to accomplish this. As Austin said, it is a simple business decision: do we spend most of our software man-hours on supporting the tools in general, or on PR, which not many people use? Obviously, most of our revenue comes from the "general" group, and most of the PR applications right now are either research, university-related or hobbies. If PR were a billion dollar opportunity, I can guarantee that Xilinx would be spending a lot of time and effort streamlining the software and making it as useable as possible for the customer base. But since the squeaky wheel gets the oil, most of the focus is improving the speed and quality of the existing tools, and adding commonly-needed features. Having worked on partial reconfiguration for many years, I acknowledge that it hasn't been very easy to work with, and there have been many limitations. We also have not delivered on our promise to make PR work smoothly (I know, because I've been given the same promises!) If you know of a killer-app for partial reconfiguration, I'm sure we would be happy to listen and try to meet the market's needs. I believe, however, that your statement that somehow the licensing agreement killed the opportunity is rather short-sighted. Marketing and sales talks with many customers in the field, and there was just no "huge demand" for it, and therefore it wasn't pursued aggressively, like DSP and Embedded Software, both of which have their own specialized divisions now. Fixed-location tiles (or pre-defined, rectangular areas) is almost a necessity, given the gargantuan increase in complexity for what you propose, dynamic-linking of netlists at runtime. It shows you haven't done your homework when it comes to understanding the problems that are associated with PR. You're basically saying "I want a cell-phone that can call anywhere in the world, can get perfect reception in a tunnel, can transmit data to space stations, and measure the surface tempature on Jupiter." Well, if it was that easy, we would have done it by now. NickArticle: 98070
Nick Camilleri wrote: > Having worked on partial reconfiguration for many years, I acknowledge > that it hasn't been very easy to work with, and there have been many > limitations. We also have not delivered on our promise to make PR > work smoothly (I know, because I've been given the same promises!) I've only been doing this for some 5 years now ... and never been willing to put a client on the line by suggesting including it in a commercial project. I've been mostly interested lately in the super set of PR, which is reconfigurable computing as a general computing platform. That's a very different market than dedicated applications. It also has very different demands and cost benefit concerns. This year, with the introduction of mid sized Virtex-4 parts at very reasonable prices, tips the cost benefit scales for a lot of applications. The last decade of RC research finally has a hardware platform to take to market. Now we need to deal with software. Trying to sell RC accelator boards as high performance computers is tough, with the hardware being just at the breakeven point cost wise. The killer is forcing the customer to spend $3-5k per year per seat for licenses for place and route to obtain legal permission to use their $5k accellerator board. This would be equivalent to Intel/Motorola/AMD/IBM blocking access to assembler and linker tools, and demanding a yearly royalty/maint fee to use the chip. This licensing problem with ISE is the deal breaker for Reconfigurable computing for any user that wishes to use the accelerator for any application that is not fixed or externally vendor supported in bitstream binary form. The solution need is either free place and route tools that can be bundled with the accelarator card, or open source access to provide those tools, and maintain them. > If you know of a killer-app for partial reconfiguration, I'm sure we > would be happy to listen and try to meet the market's needs. I believe, > however, that your statement that somehow the licensing agreement > killed the opportunity is rather short-sighted. Marketing and sales > talks with many customers in the field, and there was just no "huge > demand" for it, and therefore it wasn't pursued aggressively, like > DSP and Embedded Software, both of which have their own specialized > divisions now. I agree that there probably isn't a single killer app. Nor will there be a killer-market niche with the current place and route licensing as the cost of ownership over 5 years is an order of magnitude more expensive than the board itself. So. How do we move forward with RC on Xilinx chips? Declare it a dead market? Or open the bottom end of the tool chain so Open Source can provide the product support that Xilinx clearly can not see a market justification to provide? > Fixed-location tiles (or pre-defined, rectangular areas) is almost a > necessity, given the gargantuan increase in complexity for what you > propose, dynamic-linking of netlists at runtime. It shows you haven't > done your homework when it comes to understanding the problems that > are associated with PR. You're basically saying "I want a cell-phone > that can call anywhere in the world, can get perfect reception in a > tunnel, can transmit data to space stations, and measure the surface > tempature on Jupiter." Well, if it was that easy, we would have done > it by now. I KNOW it's hard, difficult, and nearly impossible today. I discuss what it needs to be to long term to effectively use FPGAs as compute engines in a general purpose environment. Maybe we can both develop and RC market on less than desirable architectures today, and keep this in mind as the next generation product is developed? High bandwidth access to configuration memory is also on the list for RC, and hardly a concern for dedicated applications. There are some dozen things on the RC list of must haves, that probably would not break the bank if resolved for the next generation product cost.Article: 98071
Quotes rearranged for irony: <fpga_toys@yahoo.com> wrote in message news:1141433266.375495.61080@t39g2000cwt.googlegroups.com... > > And that is a justification for Austin and Peter to then purposefully > start attacking me personally to deflect the discussion away from their > employer? <fpga_toys@yahoo.com> wrote in message news:1141433266.375495.61080@t39g2000cwt.googlegroups.com... > > That they are hyper sensitive to the truth is my fault? And ending with... <fpga_toys@yahoo.com> wrote in message news:1141433266.375495.61080@t39g2000cwt.googlegroups.com... > > So, do you have anything material to offer the discussion? Nothing material to the discussion, just the comment that you do not HELP yourself by helping to fan the flames with hot air. It takes two to tango.Article: 98072
"Sylvain Munaut" <com.246tNt@tnt> wrote in message news:4408d793$0$29227$ba620e4c@news.skynet.be... > If it's microblaze, FSL can be a choice (for DCR on microblaze you would > require a opb2dcr bridge iirc so fsl is lighter). It's PPC... /MikhailArticle: 98073
MM wrote: > Dear EDK experts, > > I have a top-level ISE project with an EDK subsystem. In that top-level > design I have a state machine, which has very little to do with the > processor subsystem, but requires several bits for control. What would be > the most natural way of doing this? The options I am aware of are as > follows: > > 1. Make the state machine a custom OPB peripheral; > 2. Control it with an OPB_GPIO module; > 3. Control it through DCR; > 4. Fully-custom control logic on the OPB bus. > > The GPIO approach seems the easiest to me (perhaps because I've never tried > using DCR), but I would like to know what others do in such cases. If it's just a few bits, then the GPIO is probably the easiest to implement. The OPB_IPIF and PLB_IPIF are good options for more complicated designs. --- Joe SamsonArticle: 98074
Nick Camilleri wrote: > Partial reconfiguration is a very difficult problem to solve in > software, and it requires tons of man-hours to accomplish this. As > Austin said, it is a simple business decision: do we spend most of our > software man-hours on supporting the tools in general, or on PR, which > not many people use? Obviously, most of our revenue comes from the > "general" group, and most of the PR applications right now are either > research, university-related or hobbies. I actually see a long term profit for my company to build and support add in reconfigurable computing boards with Xilinx FPGAs as coprocessors. A small niche market by Xilinx corporate standards. There are several dozen other companies with similar business plans and products, such as John Adair's Ragstone product line. The problem is that while you can get a few students and universities to buy the boards with discount access to your tool chain (or completely ignoring the licensing), the license costs for ISE are more than the board in the first year, and an order of magnitude more than the board over it's life. This total cost of ownership problem tilts in favor of ANY processor solution, except for researchers. This probably costs Xilinx in chip sales, by closing the RC market. Xilinx has actually invested quite a bit of money directly and indirectly in PR and RC, but in ways that didn't yeild usable product level results. Partly because the research wasn't integrated into the tool chain. Partly because the results were fragmented in too many directions, that few actually materialized into a useful complete form. I see the solution for both Xilinx and it's Customers requiring a new strategy, where the research is directly integrated into your product. What I would like to propose is one of two solutions: 1) Release to Open Source the existing sources for JBits, PAR, BitGen and the device library formats. Continue to support synthesis tools and related utilities as ISE with it's current licensing. Press Altera and third parties to do the same over time, and share the same backend engine. I would guess that you probably have between 3-5 engineers that currently support those tools, with much of their labor being invested into support for new products. They would continue that role, while also being core developers for the open source product. 2) Release the device library formats so that open source place, route and bit stream generation tools which specifically target PR and RC can evolove without additional funding from Xilinx. Xilinx can direct it customers to participate in the open source PR and RC efforts and remove that support burden from your overhead costs, except for the largest customers (if any). Xilinx employees can participate in the open source effort as non-employee compensated personal projects. I suspect that over 5-10 years, option 2, will in effect result in option 1. Either way, Xilinx can shed the support costs of PR and RC, set a clear leadership position in the process, and gain nearly automatic user/researcher funded integration of best research practices into the low level tools. There need not be a direct cost to Xilinx to support RC and PR with either of these options, as it will clearly be open source and the user/customer problem. The gain should be removing the ISE license costs as a barrier to adoption of reconfigurable computing add-in co-processor boards. The shoot out, is then cost of Xilinx parts (with increased volume) and the cost of high end prcoessors (already struggling for volume). I believe that Xilinx can make money, us board vendors can make money, and we can see if RC really is viable long term without the ISE TAX burden.
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