When it gives them a competitive advantage in their market. IMO the use of PR in a commercial environment is absolutely related to money by definition. That's what companies (try to) do, invest money to make money. My point is that I've not heard of a single successful commercial project using PR. (NB. That doesn't mean there haven't been any, just I've not heard of one.) I think this is because it's too expensive in terms of R&D investment and the tool chain has a support lifetime of about a year!
I already understand this, I think. Companies use students to experiment with PR because real engineers are too expensive to waste on something that's not ready for prime-time. (Tongue-in-cheek alert for that last sentence!) It's also a good educational project I believe. You learn that not everything's possible! ;-) As I said, it'd be great if Xilinx's new tool flow works, but it's a big gamble given PRs track record. Thanks again, Syms.
Hi Austin, Thanks for your post, can you point me to those press releases? I agree with you SDR could be a good application for partial reconfiguration. As for the miltary project, are you suggesting the project will overrun by 10-20 times the cost or 10-20 times the schedule? :-) Both? I'm not sure my employment could stand a fraction of either of those! When I first saw the V4 architecture, it did strike me as more suited to PR than previous devices, if Xilinx get a stable tool flow, I bet you'll get a competitive advantage from it. Best regards, Syms.
I agree with you. I know about the possibilities of partial reconfiguration because I have been using (and continuous on it) PR during the 5 years that I need to finish my PhD. Thesis: JBits, PARBIT, Modular design (Module-based). I have had to suffer the consequences of use this technology (like Symon, I think). But finally I finished my final application: A Hardware-Accelerated SSH on a Self-reconfigurable MicroBlaze-uCLinux system (using a Spartan-3 device and ISE 6.3). It was a very big challenge, but it finally works fine in a commercial Spartan-3 board. Next step... Virtex-4 ;)
About your answer, I am very happy to know that there are some interesting areas that require PR. They are the support that PR needs :)
I do not understand the commercial advantage, if you do not need it to make your product. Another thing will be the marketing advantage... "we can do these things" or "we do it more sophisticated". Then I understand it.
Austin talked about some applications that needs partial reconfiguration. It possible that SDR requires PR to improve the flexibility and adaptability of the system. That is the answer that I am looking for ;)
In my case, when I started my PhD. Thesis I thought that PR was "impossible mission", but now I believe that PR is possible. I need to look for another challenge ;)
Yes... I did my diploma thesis on it, i.e. on dynamic partial reconfiguration using the ICAP in Virtex-II Pro devices. The idea was to use the embedded PowerPC or a Microblaze to reconfigure other parts of the FPGA doing e.g. image processing. The next step would've been reconfiguring components of the SoC On-the-Fly. Like you load/unload Linux kernel modules, you were supposed to be able to load/unload peripherals for the processor.
The end result was more or less: Yes, it's possible, but there are so many restrictions and so many problems with the tools that there really isn't a single application that is worth the immense extra effort you have to put in simply to make it work somehow. Instead, just get a bigger FPGA, cram it all in and be done with it.
I literally spent WEEKS doing nothing else than running the same design over and over and over again, trying all the different command line switches for all the tools, trying ISE-versions from 4.2 to 6.3 with all corrresponding EDK-releases and the service packs for each, just to find one single combination of tools and service packs that wouldn't constantly quit on me with another dubious "INTERNAL_ERROR" or "FATAL_ERROR" somewhere along the way. And every time my boss was as kind as to open a web case for me (as you don't get support when you're a student, understandably), the answer was the same: "Will be fixed in the next service pack, currently there is no work-around", "Is a known bug that will be fixed in the next release" and so on.
Yeah, they DID fix it in the next release (ISE7.1), by disabling partial reconfiguration completely. No more "INTERNAL_ERRORS"!
Of course it's INTERESTING... I could think of dozens of things that would be nice to play around with. But once you're not a student anymore, you simply don't have the time to play around, unless maybe you're in research or an academic environment.
But there's no way I'd even think about doing PR in a PRODUCT, unless it's for small things like changing RocketIO parameters and the like. In Virtex4 I think you can do PR to change DCM parameters on-the-fly, that's another thing that seams feasible. But not exchanging whole modules of logic.
Well, JBits didn't handle Virtex-II Pro then. Don't know if it does now... JBits seemed pretty much dead the last time I checked.
And when I did my thesis, the Virtex-II Pro-bitstream format was still undisclosed. That would've helped, too...
But, too late now...
Nice to hear that now finally there seem to be tools that really can handle it, even though they're not shipped with ISE and you even have to buy some extra, like PlanAhead.
Don't have the time to play around with it, but I'd be glad to hear some experiences if someone really gets it working reliably.
'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...
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.
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'.
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.
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.
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.
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?
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.
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.
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?
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.