Re: Configure FPGA via PCIe
- From: rickman <gnuarm@xxxxxxxxx>
- Date: Sat, 28 Feb 2009 23:40:02 -0800 (PST)
On Feb 27, 10:54 pm, Allan Herriman <allanherri...@xxxxxxxxxxx> wrote:
rickman <gnu...@xxxxxxxxx> wrote innews:62bd320f-8525-4302-8dd8-d9cf13545e3c@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
On Feb 27, 12:18 pm, Allan Herriman <allanherri...@xxxxxxxxxxx> wrote:
rickman <gnu...@xxxxxxxxx> wrote4...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
innews:55de02a8-97df-4a69-8ec4-9546dcac2
On Feb 27, 1:58 am, Kim Enkovaara <kim.enkova...@xxxxxx> wrote:
rickman wrote:
When you refer to "high end" processors, you are talking about a
literal handful of devices compared to the hundreds or thousands
of types of CPUs that are used in embedded systems. If you are
talking
I'm referring to chips like Intel atom, new PowerQuicc IIP/III
processors etc. They usually have few PCIe ports as a default and
if they are not enough a switch is needed. And I don't see why
low end would not adopt PCIe. Each saved pin helps to get into a
smaller and cheaper package (altough wirebond and PCIe frequencies
might be challenging).
sYes, I know which chips you are referring to. On a few high end
chip
(very high end) you are supporting the idea of utilizing the few
PCIe interfaces rather than using a small number of GPIO pins.
I predict that within a couple of years, many of the smallest (new)g
processors big enough to be able to run Vxworks or Linux will have at
least a couple of lanes of PCIe. If we were back in the 1980s
designin
with 8051s, these new processors would seem very powerful, but they
will be regarded as low end by the time I'm using them.
That may be true to some extent, but let's face it, even in five
years, these very high end embedded processors, which are really
embedded PCs, will still be the minority of the applications for
embedded processors and likely an even smaller percentage of the
controller for embedded FPGAs. There is no need for that level of
power in most apps, for example the retail routers that are powered by
ARM7 or ARM9 CPUs or the various processors in all sorts of handheld
devices that don't need to run WinCE or even WinXP. So the need is
just not there and is likely to not be there for some time to come.
If you want to use GPIO to configure that FPGA, you'll need a PCIe to
GPIO bridge, wasting both a PCIe channel and and a bridge / GPIO
chip. (I'm only half joking here.)
No, for the vast majority of apps, you are totally joking... or at
least exaggerating. PCIe is hardly ever the only means of comms other
than in embedded PC chips perhaps.
Earlier in the thread I used the Intel Atom as an example. That
processor & US15W support chip are aimed at netbooks, hence the lack
of I/O other than USB and PCIe (mostly).
Exactly! It is a two chip set aimed at an app where an FPGA has no
place.
These sort of architectures started to appear in embedded systems ay
couple of years ago. Soon they will be pervasive, except in the
batter
powered market (assuming that PCIe doesn't grow some sort of dynamic
power down capability).
You mean they have appeared in embedded PCs. That is a very different
animal from embedded systems where the CPU is designed in rather than
a CPU board being designed in.
There will still be 8051s and PICs but that's not what this thread's
about.
No, it is about configuring FPGAs.
That is a
tradeoff with those chips. But you are asking everyone buying
FPGAs to pay for the Silicon to implement the hard PCIe interface
We're already paying for that in the newer families, e.g. V6.
and make it part of the configuration logic.
This would be tiny compared to the PCIe end point logic that they
already have in there.
(And is "you pay for the programmable routing; the logic is free"
still valid?)
If you are in marketing, it is true. The rest of us have to pay hard
cash. Silicon costs cash even if it is vanishingly small, there are
still all the support costs. It will be added when it sells chips...
and not before! There are two ways PCIe configuration can sell
chips. One is if there are applications where the FPGA can't be used
without this feature. That is a very, very small set of apps. The
other is if the competition is selling chips with a useful feature
that you don't have. When this happens, they will all start selling
it. Just like Lattice selling low cost chips with SERDES functions.
Now X and A are coming out with that too. But until that happened, it
didn't cost X or A anything to not be selling that.
On top of that, I am still not
convinced that this can be done without some data in Flash which
someone else pointed out is required for initilization of the PCI
interface. Is this not the same with PCIe?
A general purpose bridge will need some sort of configuration device.
There is nothing saying this has to apply to a specific PCIe
bridge, or that any variable part of the configuration has to be
stored in Flash or EEPROM.
Even the FPGA has to have various parameters preset, no?
We already select the type of configuration with "mode" pins on the
FPGA. I'd be quite prepared to waste an additional 3 or 4 pins on a
1000 to 1500 pin device to select one of several different pre-canned
PCI configurations. The tradeoffs would be different for smaller
packages, but I'm not using those.
What about a 256 pin device? You are talking about having to give up
4 pins on the processor as being trouble, why are pins so free on an
FPGA? Besides, why would it be 3 or 4? Just what information has to
be set in order for the FPGA to respond on a PCIe port?
about adding a "switch" then you are adding an extra chip and
you can just as easily add any sort of chip to facilitate
booting the FPGA.
The problem is that there are only few vendors for special bridge
chips to GPIO etc. But for PCIe switches there are many vendors
even some with identical pinouts. That helps multisourcing for
manufacturing. Also Industrial temperature requirements narrow
down the choices.
You are dwelling on PCIe and I am not. There are many ways to skin
a cat and most do not require anything special in the FPGA. Look
at what I wrote without assuming this is using PCIe.
I'm the OP, which makes me the one dwelling on PCIe :) Besides, it'sn
i
the thread title.
You are missing my point. By "dwelling" I meant you are so focused on
the PCIe that you missed my point. You don't *need* PCIe to configure
an FPGA. It is more complex, higher cost and uses more I/Os on both
the CPU and the FPGA in the vast majority of designs. ***THAT*** is
the main point. The other options are just better in all respects for
99.9% of current and 95% of foreseeable apps. The Atoms of the world
are far in the minority.
Rick, I think you're the one missing the point. I think those (obviously
fabricated) stats relate to your personal experience and don't
neccessarily apply to all applications. *My* personal experience is that
100% of systems that *I design* would be made smaller and cheaper if
FPGAs could configure over PCIe.
I know that you think I am missing the point. That is what is not
happening here, communication. I feel I am explaining myself well and
you seem to feel I am being absurd. But your responses are not any
less absurd. In fact, the above response seems to be trying to parrot
my comments, so clearly if you feel my responses are absurd, then
yours must be as well.
I'm well aware that I'm probably in the minority of designers here. But
that isn't to say that the issues I face in design are not important.
The issue isn't with the number of designers, it is about the number
and profitability of the designs. The FPGA companies can't make money
adding every bell and whistle we all would like. PCIe may become a
defacto standard on many more processors in the future. But until
that is clear, I wouldn't expect X, A or L to worry about adding a
boot capability via PCIe.
You employ logical fallacies in your arguments. E.g. I used an example
of a 1000 to 1500 pin FPGA. You reply to my statement by implying that
it doesn't work for a 256 pin FPGA. Well, I already knew that, which is
why I qualified my statement with the size of the FPGA in the first
place. I just don't know how to respond to bad arguments like that
except in an emotive way, and as a result I'm stopping posting (since caf
is a civilised place).
You consider my responses illogical. The example you give is not a
"logical" argument, it is illustrative. For every 1000 to 1500 pin
FPGA sold, there are likely hundreds if not thousands of 256 pin FPGAs
with a significantly larger total profit. That is what the entire
issue is about, whether or not the FPGA makers will find it profitable
to invest time, resources, money and the *extremely* valuable product
Silicon in a feature that will be used by a small fraction of the end
users, and even then is a show stopper (preventing them from using an
FPGA) for nearly none of them.
Hey! I have been looking... no BEGGING the FPGA companies to make
more FPGAs available in smaller packages (meaning low pin count and
correspondingly low price) to no avail. The most recent families from
the vendors I have seen are even dropping support for the smaller
packages that I am currently using. They don't really care because it
just is not profitable for them to provide what I need (or at least
that is what they think).
You can choose to be blind to the realities of chip and board design,
but if you discuss them here, please don't expect me to also be as
blind.
I hope this was a civilized enough response.
Rick
.
- Prev by Date: Re: why is the bottom 5 lsb all zero of ingress_start_addr/egress_start_addr[27:6] from xapp859.zip?
- Next by Date: New person to CPLD programming
- Previous by thread: Re: why is the bottom 5 lsb all zero of ingress_start_addr/egress_start_addr[27:6] from xapp859.zip?
- Next by thread: Re: Configure FPGA via PCIe
- Index(es):
Relevant Pages
|
