Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 98050

Article: 98050
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 03 Mar 2006 13:13:10 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: VirtexII routing data widths (further query)
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 03 Mar 2006 13:15:24 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: why use an FPGA when a CPLD will do ??
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 03 Mar 2006 13:16:27 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: why use an FPGA when a CPLD will do ??
From: "Anonymous" <someone@microsoft.com>
Date: Fri, 03 Mar 2006 21:27:20 GMT
Links: << >>  << T >>  << A >>

"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 configuration



Article: 98054
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: fpga_toys@yahoo.com
Date: 3 Mar 2006 13:50:37 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: fpga_toys@yahoo.com
Date: 3 Mar 2006 14:04:38 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: VirtexII routing data widths (further query)
From: fpga_toys@yahoo.com
Date: 3 Mar 2006 14:07:46 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: why use an FPGA when a CPLD will do ??
From: "Peter Alfke" <peter@xilinx.com>
Date: 3 Mar 2006 14:16:54 -0800
Links: << >>  << T >>  << A >>
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?
> 
> Thanks


Article: 98058
Subject: Re: VirtexII routing data widths (further query)
From: fpga_toys@yahoo.com
Date: 3 Mar 2006 14:33:41 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 03 Mar 2006 14:47:40 -0800
Links: << >>  << T >>  << A >>
Sigh,

Well, I tried to communicate again.  And supply an alternate viewpoint 
(which is most likely correct).

I apologize to the newsgroup.

Austin


Article: 98060
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 03 Mar 2006 14:50:31 -0800
Links: << >>  << T >>  << A >>
Steve,

Don't bother.

"toys" blames us for his failure.

It is unlikely he will do anything but flame us every chance he gets.

Austin


Article: 98061
Subject: Re: VirtexII routing data widths (further query)
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 03 Mar 2006 14:52:37 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: VirtexII routing data widths (further query)
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 03 Mar 2006 14:53:07 -0800
Links: << >>  << T >>  << A >>
<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
Subject: EDK: choices for simple internal control
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 3 Mar 2006 18:07:48 -0500
Links: << >>  << T >>  << A >>
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,
/Mikhail







Article: 98064
Subject: Re: Spartan 3 Expansion Board
From: "A. Karttunen" <Antti.Karttunen@reverse-next-part.liamg.com>
Date: Sat, 04 Mar 2006 01:24:49 +0200
Links: << >>  << T >>  << A >>
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 Karttunen



Article: 98065
Subject: Re: EDK: choices for simple internal control
From: Sylvain Munaut <com.246tNt@tnt>
Date: Sat, 04 Mar 2006 00:57:40 +0100
Links: << >>  << T >>  << A >>
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).



	Sylvain

Article: 98066
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: fpga_toys@yahoo.com
Date: 3 Mar 2006 16:01:37 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: "John_H" <johnhandwork@mail.com>
Date: Sat, 04 Mar 2006 00:24:56 GMT
Links: << >>  << T >>  << A >>
<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 Handwork



Article: 98068
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: fpga_toys@yahoo.com
Date: 3 Mar 2006 16:47:46 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: Nick Camilleri <nick.camilleri@xilinx.com>
Date: Fri, 03 Mar 2006 17:03:18 -0800
Links: << >>  << T >>  << A >>
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.

Nick

Article: 98070
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: fpga_toys@yahoo.com
Date: 3 Mar 2006 17:46:42 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: "John_H" <johnhandwork@mail.com>
Date: Sat, 04 Mar 2006 01:54:10 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: EDK: choices for simple internal control
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 3 Mar 2006 20:55:09 -0500
Links: << >>  << T >>  << A >>
"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...

/Mikhail



Article: 98073
Subject: Re: EDK: choices for simple internal control
From: Joseph Samson <user@example.net>
Date: Sat, 04 Mar 2006 02:18:41 GMT
Links: << >>  << T >>  << A >>
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 Samson

Article: 98074
Subject: Re: dynamic partial reconfiguration of Xilinx Virtex-4 FPGAs
From: fpga_toys@yahoo.com
Date: 3 Mar 2006 19:10:51 -0800
Links: << >>  << T >>  << A >>

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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search