dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
zhangx...@gmail.com
Virtex-4 FPGAs. I have readed those article sur the site of Xilinx
e.g; the guild of configuration , use guid etc. but I havent also any
idea for the begining. I wish someone can give me a real exemple or
some advices for the dynamic partial reconfiguration of Virtex-4.
thanks on advance,
xun
Symon
Check out Xilinx's PlanAhead product. Quote:-
"New Partial Reconfiguration features and capabilities in PlanAhead 8.1
simplify the implementation of this complex but powerful design flow.
Combined with the ISE 8.1i Design Tools, PlanAhead 8.1 delivers the
industry's only front-to-back solution for partial reconfiguration."
www.xilinx.com/planahead
Make sure you report back to let us know how you're getting along!
Good luck (you'll need it!) Syms.
<zhangx...@gmail.com> wrote in message
news:1139929097.2...@g44g2000cwa.googlegroups.com...
Javier Castillo
Good Luck
Peter Alfke
http://www.fpgajournal.com/articles_2006/20060207_cray.htm
Apparently RC works...
Peter Alfke
Steve Lass
included in 8.1i.
PlanAhead is also required. You need to contact your local FAE to gain
access
to this software.
Steve
Javier Castillo
Spartan3 works fine. I said that Partial Reconfiguration on Virtex4
using ISE doesnt work. I dont know if using PlanAhead it works.
We have made many experiments and using Virtex4 during the final
assembly phase it fails due to problem with the disabled DCMs, and
many global logic that appears during this phase. That global logic
goes from TIE elements to CE inputs of the registers inside the
slices. For smal designs we have route it manually and we've got some
simple design of PR on Virtex4, but for larger designs is imposible to
route that logic. Appart for it there are a problem about using
Virtex4 block rams in modular design, I reported it, and it supposed
to be solved in a IP update for ISE8.1. I havent test it yet.
Yesterday, when I downloaded SP2 for ISE8.1 I tested again the designs
and the problem of the global logic and unconnected DCMs havent
disappear.
Regards
Javier
Stephane
there is no evidence of _dynamic_ reconfiguration in this article.
Actually, Smith-Waterman algorithm is not a good candidate for
demonstrating dynamicity, because the query sequence occupies only an
edge of the accelerator array => programming a long register is ok.
Changing algorithm coefficients would benefit from DPR, but actually,
biologists never do so!
Xilinx paper "Gene Matching using JBits" in FPL 2002 was an
implementation of the Needleman-Wunsch algorithm (simpler than S-W); it
also uses a run-time query, and implementation is optimized for given
coefficients, so it's not clearly taking advantage of DPR.
Anyway JBits was demonstrated to work.
Stephane
Vic Vadi
of special hooks intended to increase the flexibility of usage of
Partial Reconfig. Unfortunately the tools haven't quite caught up yet.
This should improve with the new Plan Ahead 8.1 and future Software
releases. Some applications like Software Defined Radio and
Reconfigurable Computing are driving this.
If you run into a problem please call the hotline or file a CR. If
Partial Reconfig is important to you - let your local FAE know. That way
in the future the software and tool support for Partial Reconfiguration
will get the priority it deserves.
- Vic
Love Singhal
Planahead 8.1 supports partial reconfiguration in Virtex 4.
Check out this recent article:
http://www.us.design-reuse.com/news/news12519.html
Frank
"Love Singhal" <loves...@gmail.com> wrote in message
news:1141290150.8...@v46g2000cwv.googlegroups.com...
Hi Singhal,
has the partial reconfig evolved since last time the Virtex 2 nightmare?
I did partial reconfig with V2 FPGAs, and it was really buggy and
inflexible.
Sean Durkin
> The Virtex4 hardware supports partial reconfiguration and includes a lot
> of special hooks intended to increase the flexibility of usage of
> Partial Reconfig. Unfortunately the tools haven't quite caught up yet.
> This should improve with the new Plan Ahead 8.1 and future Software
> releases.
reconfiguration, and that was with ISE4.2. "Will be fixed in the next
service pack", "should work in the next release", "This is not supported
yet, but well be later on.", "This is a known issue that is scheduled to
be fixed in a future software release.".
Kind of reminds me of GNU/Hurd, which is always scheduled to be usable
"next year", or "Duke Nukem Forever", which has been scheduled to be
released for the past 9 years.
Now it's 4 major releases and probably a dozen service packs later, and
the bottom line is: It has never worked properly, it still doesn't, and
in the past few years support in the tools hasn't even gotten a little
better, because all the problems seem to be re-introduced with every
major release all over again. And of course, as soon as a new FPGA
family is introduced (Spartan 3, Virtex 4), all the effort seems to be
going (understandably) into implementing partial reconfiguration for
these new devices, not into fixing bugs in the existing support for
older devices.
The high-point of all of this was with the release of ISE7.1, when
partial reconfiguration was completely disabled until SP4.
> Some applications like Software Defined Radio and
> Reconfigurable Computing are driving this.
Nice to hear that now *finally* there seem to be applications for the
mass market that make the whole subject "interesting" to Xilinx.
In past years the whole thing was more or less academic in nature, and I
totally understand that priorities are low when there's only little or
no money behind it. This is all perfectly reasonable and understandable.
But the thing that bugs me is that Xilinx has been using partial
reconfiguration to promote their parts for years, and as soon as you
really dive into the subject you find out that the parts do indeed
support it, but the software does not, or has only very buggy or
rudimentary support.
So when you ask someone from Xilinx you usually get a link to some
marketing press release which states "Yes, partial reconfiguration
works, we're better than all of our competitors!", which is obviously
only part of the truth...
cu,
Sean
Ivan
I think than actually the PR is well-supported in Virtex-II. This family
is the reference device for all PR documents. But it depends of the
complexity of your design.
The question is if new families will be supported, particularly
Virtex-4, because the new architecture appears to be incompatible with
the actual PR methodology. PlanAhead should be the solution. However it
is necessary to evaluate if it works well for all kind of applications,
because simple PR design works perfectly in all devices: Spartan-II,
Virtex, Virtex-II, etc... as Javier Castillo said.
Regards,
Ivan
Ivan
your comments reveal that you are very annoyed about PR. I think it is a
hard work to make use of it, but actually there are a lot of interesting
applications and research works when PR has been applied successfully.
Of course these good results have been obtained at present. When ISE 4.2
was released, the PR was well-supported by the JBits tool. You chose the
wrong tool :(
Regards,
Ivan
Steve Lass
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.
Steve
Love Singhal
>From what I have read in the documents (I have not implemented the
complete flow yet), the support for partial reconfiguration has indeed
evolved in Virtex 4.
First, the Planahead tool handles modular based flow better than just
the floorplanner in the previous modular based flow.
Second, the Virtex 4 has fixed size frames (16 clbs) based partial
reconfiguration rather than a column based partial reconfiguration.
This basically means that there can be multiple frames in one column of
any Virtex 4 device. Thus, the whole column does not have to be
reconfigured all at once. This could reduce a lot of complexity for
interconnects that connects one side of reconfigurable region to
another side (they do not have to be routed using long wires only, for
example).
I think designs with partial reconfiguration could be implemented
better in Virtex 4 than in Virtex 2, but as I said, I have not yet
implemented the complete flow.
Love Singhal
http://www.ics.uci.edu/~lsinghal
Symon
news:4407EC49...@xilinx.com...
> 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.
>
Are any non-academic customers using this flow with reliable success? My
point being, it's probably a great post-graduate project, but should I be
willing to bet my companies R&D money on it? Is there a commitment from
Xilinx to support this design flow into the future? I'd like to see some IP
cores based on this being released by Xilinx. It would show that the Xilinx
IP developers believe in it!
Please don't get me wrong, I'm typing in a friendly tone of voice! I really
hope you guys have it cracked this time. I hope you can understand the
caution expressed by some of the more cynical posters on CAF!!
Many thanks, Syms.
Symon
news:44083507$0$15795$1472...@news.sunsite.dk...
> willing to bet my companies R&D money on it? Is there a commitment from
Ivan
I think that the use of PR is not related with the money of companies.
The real question will be: is there any kind of application where PR is
really necessary? Companies try to reduce the cost of the products, and
the research and development is only necessary when the solution is not
available with the current technology... why they have to use PR in
their designs when they do not need it?
Moreover, you need to understand that some of academic
researches/customers (as you said) are using PR in their projects
because they are financed by companies. They are looking for this kind
of applications... like Xilinx people, I think.
Regards,
Ivan
Austin Lesea
I can't give you the names of the companies, as we have non-disclosure
policies. I can direct you to our web pages that have customer
testimonials and press releases.
I will say that for development of software defined radio (SDR),
reconfigurability is the only practical solution (OK, IMHO). As such,
we have been highly motivated to make it (the flow) work (better) by the
demand from companies supplying advanced communications from around the
entire globe who also believe as we do.
Is it perfect yet? No.
Is it something people are investing megabucks in?
You bet. SDR for JTRS is a $5 billion program for the next 7 years
(just one program). Like any military program you can expect that to
overrun by ten or twenty times that.
Is all that $$ FPGA chips? No, of course not. There are batteries,
antennnas, plastic cases, etc.
Is it enough $$ to have FPGA and DSP companies sit up and take notice? Yup.
Austin
Austin Lesea
Software defined radio is one application. And even here, there are
people who say that DSP can also do the job for less cost/power.
Spacecraft traveling to other planets is another (although you could
argue that they just need to be reprogrammed, and not dynamically).
Also possibly orbiting communications satellites.
So far, there is more solution than problem.
There are examples where a vendor did something very clever, and saved
money and had a competitive advantage using dynamic reconfiguration, but
nothing that has taken the world by storm.
Austin
Symon
Thanks for your reply, I've included some comments for your perusal!
"Ivan" <gmi...@terra.es> wrote in message
news:%rZNf.706502$kp.49...@telenews.teleline.es...
> Hi Symon,
>
> I think that the use of PR is not related with the money of companies. The
> real question will be: is there any kind of application where PR is really
> necessary? Companies try to reduce the cost of the products, and the
> research and development is only necessary when the solution is not
> available with the current technology... why they have to use PR in their
> designs when they do not need it?
>
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!
>
> Moreover, you need to understand that some of academic
> researches/customers (as you said) are using PR in their projects because
> they are financed by companies. They are looking for this kind of
> applications... like Xilinx people, I think.
>
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.
Symon
news:du9o62$ar...@xco-news.xilinx.com...
> Symon,
>
> I can't give you the names of the companies, as we have non-disclosure
> policies. I can direct you to our web pages that have customer
> testimonials and press releases.
>
> I will say that for development of software defined radio (SDR),
> reconfigurability is the only practical solution (OK, IMHO). As such, we
> have been highly motivated to make it (the flow) work (better) by the
> demand from companies supplying advanced communications from around the
> entire globe who also believe as we do.
>
> Is it perfect yet? No.
>
> Is it something people are investing megabucks in?
>
> You bet. SDR for JTRS is a $5 billion program for the next 7 years (just
> one program). Like any military program you can expect that to overrun by
> ten or twenty times that.
>
> Is all that $$ FPGA chips? No, of course not. There are batteries,
> antennnas, plastic cases, etc.
>
> Is it enough $$ to have FPGA and DSP companies sit up and take notice?
> Yup.
>
> 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.
Ivan
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 :)
Regards,
Ivan
Ivan
> Hi Ivan,
Hi Symon,
> 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 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 ;)
> 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! ;-)
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 ;)
> 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.
And I thank you as well.
Regards,
Ivan
Sean Durkin
> Hi,
>
> your comments reveal that you are very annoyed about PR.
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"!
> I think it is a
> hard work to make use of it, but actually there are a lot of interesting
> applications and research works when PR has been applied successfully.
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.
> Of course these good results have been obtained at present. When ISE 4.2
> was released, the PR was well-supported by the JBits tool. You chose the
> wrong tool :(
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.
cu,
Sean
Austin Lesea
Austin Lesea
'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.
Austin
fpga...@yahoo.com
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.
Austin Lesea
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...@yahoo.com
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.
fpga...@yahoo.com
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.
Austin Lesea
Well, I tried to communicate again. And supply an alternate viewpoint
(which is most likely correct).
I apologize to the newsgroup.
Austin
Austin Lesea
Don't bother.
"toys" blames us for his failure.
It is unlikely he will do anything but flame us every chance he gets.
Austin
fpga...@yahoo.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?
John_H
news:1141430497.9...@i39g2000cwa.googlegroups.com...
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 Handwork
fpga...@yahoo.com
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?
Nick Camilleri
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.
Nick
fpga...@yahoo.com
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.
John_H
<fpga...@yahoo.com> wrote in message
news:1141433266....@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...@yahoo.com> wrote in message
news:1141433266....@t39g2000cwt.googlegroups.com...
>
> That they are hyper sensitive to the truth is my fault?
And ending with...
<fpga...@yahoo.com> wrote in message
news:1141433266....@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.
fpga...@yahoo.com
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.
fpga...@yahoo.com
Nick Camilleri wrote:
> 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.
>
> Nick
I'm certain that your teams working on this were both tallented and put
the best available effort given priorities to doing a good job.
Neither I, nor anyone else, can do a good job evaluating the difficulty
and probability of sucess for RC and PR for your existing chips and
software architecture, without access to the design information you
hold locked up. So, it's impossible for anyone outside your NDA circle
to have done their homework.
I've also spent 35 years walking into the middle of clients projects,
which were frequently stalled, failed, and/or past contract
ship/delivery dates. Nearly everyone of those teams were competent,
and many top in their field. They had also reached the limits of their
formal training, skills, and experience to find a solution to their
project deadlock -- OR -- that were locked into failure by the product
specifications forced on them, resources made available, or
restrictions against using viable alternative designs, architectures,
etc. Frequently the solution path for the projects was a combination
of outside ideas, outside experience, and outside influence to change
the product specifications, resource alloctions, and removing the road
blocks to other viable solution strategies.
I'm certain that if it was easy for you to do with the requirements,
resources, and restrictions place on your developers, that you would
have delivered a strong reliable RC and PR tools by now.
I'm also certain that ourside your organization, free of the
requirements, resource limitations, and organizational restrictions
that a different team will respond to a different requirement set and
find a viable solution limited only by the existing hardware
architecture. And with that success, they will be able to clearly
articulate the changes needed to make future Xilinx RC and PR product
generations not only very viable, but a strong success for everyone
involved, including Xilinx and your customers.
Rainer Buchty
Nick Camilleri <nick.ca...@xilinx.com> writes:
|> 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.
See, and that is the problem.
As of now, research is actively pursuing what could become the next
set of killer apps. Just check out for the vast efforts being currently
put into "reconfigurable computing", "organic computing", "adaptive
computing" to give a few buzzwords.
Xilinx seemed to have *the* ultimate product for that, but despite all
claims, PR support is hardly there. There have been some few successes
in this field (e.g. Becker et al. from Univ. Karlsruhe), despite all
hassles with varying ISE versions. But in the end, there are still too
many obstacles to really *use* PR.
Forgot the name, but in this very thread some other poster described
his experiences and how they basically came down to getting to know
which (sub)version of ISE supported what, and which versions were broken
with respect to PR. Which is exactly our experience as well.
A couple of weeks ago David Kramer posted in this group for specific help
regarding problems with PR [1].
I didn't see one single answer from "you Xilinx guys" *here* regarding his
topic.
After all, fpga_toys has a point: You are advertising a feature which
basically is broken. In hardware it's supported, but using your development
software it's rather inaccessible without jumping through a good number
of hoops. Personally, I'd be more than lucky if there would be an easy way
to accomplish the following:
- creating an internal bus connecting a number of same-sized "slots", i.e.
regions within the FPGA to be filled with exchangeable functionality
- being able to exchange the functionality of those slots on the fly
(dynamical partial reconfiguration)
- do that with Virtex-IIpro and Virtex-4FX
I don't mind if that works only through a shell script (in fact, I'd
prefer it that way), if it works at all without throwing INTERNAL_ERRORs
and FATAL_ERRORs -- and if it works consistently and not with one
specific subversion of one specific ISE version so that when I upgrade
the software the design isn't broken or having to chose which chip family
I can't use for being able to do PR.
Don't ge me wrong: as a university researcher I am more than thankful for
the support Xilinx gives us. But as of now I have a feeling that PR on
Virtex-II/4 might vanish like XC6200 did vanish end of the 90s just because
of the lack of proper software support: if a hardware feature is not
properly accessible via the development software it won't be used. Therefore
no multi-million dollar revenue will come from that, and following your
argumentation you won't put major effort into it if you can't be sure that
there's a multi-million dollar revenue to expect.
That's a vicious circle only *you* can break: either by releasing software
which supports PR without major obstacles, or put out enough information
(could be under NDA, as I'm not that religious to demand that everything is
open-sourced) so that fpga_toys (or whoever) is able to build supporting
software.
Rainer
[1] http://groups.google.com/group/comp.arch.fpga/tree/browse_frm/thread/cc25adfd2f813f81
fpga...@yahoo.com
Rainer Buchty wrote:
> That's a vicious circle only *you* can break: either by releasing software
> which supports PR without major obstacles, or put out enough information
> (could be under NDA, as I'm not that religious to demand that everything is
> open-sourced) so that fpga_toys (or whoever) is able to build supporting
> software.
>
> Rainer
>
> [1] http://groups.google.com/group/comp.arch.fpga/tree/browse_frm/thread/cc25adfd2f813f81
I'm not that religious about open source either. But I also see that
some perception of value needs to justify the cost in corporate
america, or the board will question wasting the dollars that the stock
holders have a right to expect be spent for value.
I don't see another solution at this time.
I do know that RC on xilinx is dead with the ISE tax to use such a
computer or accel card, and for a product that doesn't even support RC
as it needs to be supported in a high value multiprocessing
multiprocessor FPGA based computer.
Clearly Xilinx thinks this will not be a high volume revenue source,
and compared to dedicated sales they are probably right. So we can
never expect support at the levels needed to support good RC and PR on
their product line. It's not right to bitch at them for not doing a
better job when the revenues aren't likely to cover the work.
I do think that asking them to open up enough we can support ourselves
is of value, and they have the right to decline. At least everyone
will know the rules of the game, and not waste their energies on a dead
end Xilinx RC and PR dream if they refuse. There are other vendors
that might see this as their gold mine, and openly support developers
helping them.
fpga...@yahoo.com
Nick Camilleri wrote:
> 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 read Neal Steiners thesis and related papers several time over the
last couple years (etd-09112002-143335):
A Standalone Wire Database for Routing and Tracing in Xilinx
Virtex, Virtex-E, and Virtex-II FPGAs
Along with the papers for VPR and VPR for Virtex, JHDL docs, and
several related projects.
That however, doesn't describe the work necessary to do a good router
for Virtex-2, Pro, or Virtex-4 products .... which I believe is info
only available from Xilinx.
Any other suggestions for doing our homework?
Frank
"Love Singhal" <loves...@gmail.com> wrote in message
news:1141379383....@i40g2000cwc.googlegroups.com...
> Hi Frank,
> >From what I have read in the documents (I have not implemented the
> complete flow yet), the support for partial reconfiguration has indeed
> evolved in Virtex 4.
> First, the Planahead tool handles modular based flow better than just
> the floorplanner in the previous modular based flow.
> Second, the Virtex 4 has fixed size frames (16 clbs) based partial
> reconfiguration rather than a column based partial reconfiguration.
> This basically means that there can be multiple frames in one column of
> any Virtex 4 device. Thus, the whole column does not have to be
> reconfigured all at once. This could reduce a lot of complexity for
> interconnects that connects one side of reconfigurable region to
> another side (they do not have to be routed using long wires only, for
> example).
> I think designs with partial reconfiguration could be implemented
> better in Virtex 4 than in Virtex 2, but as I said, I have not yet
> implemented the complete flow.
>
> Love Singhal
> http://www.ics.uci.edu/~lsinghal
>
Frame based partial reconfiguration is really neat. Next time I will
definitely
try them out, but is the software available in Webpack 8?
Steve Lass
to answer all of the questions posted:
Q: Does the released ISE software support partial reconfiguration?
A: In some cases, yes.
Q: Does anyone have a commercial product that successfully employed
partial reconfig?
A: Yes, there are a few.
Q: Why did Xilinx say partial reconfig worked when most of the time, it
doesn't?
A: We released software for partial reconfig about 4 years ago. At that
time, there was a flow that worked if you did everything in the right
way. There were a couple of people in my group that were assigned to
help customers through the mine field. It was rare that our sales force
told us about customers using partial reconfig, so we assumed that
nobody was using it. Because of other priorities, and the apparent lack
of interest, the partial reconfig software languished.
Q: Is there a killer app that will drive Xilinx to put the effort needed
to make partial reconfig a workable flow?
A: Yes. There are software defined radio applications that are
lucrative enough to get our attention.
Q: Does Xilinx now have software that works for partial reconfig?
A: Yes. We have a team that has modified the current software, created
a new flow, and tested the software with different applications. In
addition, PlanAhead makes it much easier to lay out your design and run
DRCs to ensure that partial reconfig will work.
Q: How do I get this software?
A: Contact your local FAE. If you're at a university, contact the
university program. Our Xilinx Labs research department is supporting
the universities.
Q: Why don't you release the software with ISE?
A: The plan is to release it with ISE in version 9.1i. For now, we have
an efficient team assigned to refine the flows and fix bugs as soon as
they are found.
Q: Is frame reconfiguration really cool?
A: Yes. However, Virtex2 and Virtex2-Pro together with our new software
let you do what could be considered a partial frame write. Even though
you are writing the entire frame (column), Virtex devices don't glitch
when you write exactly the same config bits. This allows you to have
static logic above or below a reconfig region. We reconfigure the
static region, but it continues to work. This also allows us to have
static routes that pass through a reconfig region. The software
reserves these routes when routing the reconfig region.
Q: The software license fees are $3k - $5k. How can we use this for
reconfigurable computing?
A; I'm not sure where these prices came from. If you are creating a
reconfigurable computer, contact me and we can discuss an OEM deal for
much less money.
Q: Should I feel comfortable adding partial reconfig to my current
application?
A: Personally, I would wait a couple of months. We are currently
rolling out the software to our SDR customers and will be spending our
effort supporting them. In addition, many of the FAEs have not been
trained on the new partial reconfig flow. And they are the first line
of support.
Steve
Ivan
> Ivan wrote:
>> Hi,
Hi Sean,
>>
>> your comments reveal that you are very annoyed about PR.
> 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.
Your diploma thesis looked for the same goal than my PhD. Thesis. I was
working with MicroBlaze in Spartan-3 (there is not ICAP, but it is
possible the self-reconfiguration too). I know another student working
with OpenRISC is Virtex-II. PR works reasonably well in these two
systems. I succeed in obtaining PR coprocessors.
Regards,
Ivan
Ivan
> I am responsible for the partial reconfiguration software. Let me try
> to answer all of the questions posted:
Hi Steve,
thanks for your answers.
>
> Q: How do I get this software?
> A: Contact your local FAE. If you're at a university, contact the
> university program. Our Xilinx Labs research department is supporting
> the universities.
Yes... I am working on it ;)
Regards,
Ivan
Identity Hidden
"Steve Lass" <la...@xilinx.com> wrote in message
news:dugco2$83...@cliff.xsj.xilinx.com...
That's nice, I guess I will give our discontinued SDR project another
chance.
What is the estimated time of ISE 9.1i release?
zhangx...@gmail.com
PR with the methode difference-based partial reconfiguration , ça
marche , but I never find out the differents with the others version.
and someone said the PlanAhead provides a single envirenement to manage
the preceding guideline but it must call my local FAE, so I dont know
how easy with it for the PR . if anyone knew it please told me! thanks
a lot
regards
xun
Steve Lass
Identity Hidden wrote:
> That's nice, I guess I will give our discontinued SDR project another
> chance.
> What is the estimated time of ISE 9.1i release?
January 2007
>
>
>
zhangx...@gmail.com
xun
Valerios
I am a student, write a diploma about application of partial
reconfiguration. Would not you to give me materials where is the
fast-acting with partial reconfiguration and without it compared?
Beforehand thankful.
Paul Hartke
another resource:
http://www.cs.uq.edu.au/~jwilliams/mblaze-uclinux/Mailing_List/
The archive is available here:
http://www.itee.uq.edu.au/~listarch/partial-reconfig/