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
2017JanFebMarApr2017

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 16450

Article: 16450
Subject: Re: JTAG: Altera & Xilinx
From: Rich McNeil <mcneilr@mediaone.net>
Date: Sun, 23 May 1999 07:48:28 +0500
Links: << >>  << T >>  << A >>
I was looking into this also.  We use the Byteblaster from Altera all the
time.
Xilinx does not support the Jam player and from the FAE I talked to,
they will not.  They are looking into a java based programmer instead. Do a
search on Xilinx's home page for java.
I guess they just can't play together ...even if it is for the customer!

Vasant Ram wrote:

> Hello! I've got the Xilinx FPGA/JTAG parallel port cable that comes as
> part of the XC9500 demo board, and wanted to know if it it was at all
> possible to use this with Altera devices. If not, is there any freeware
> schematic so one could make an Altera JTAG programmer? Is it possible to
> program a JTAG device independent of software (MAXPLUS II vs. Foundation,
> etc)?
>
> Also, can one actually use JTAG to apply stimulus to the EPLD/observe
> signals? I've always been a bit confused about that.
>
> Thanks for the help.
> Vasant
>
> remove nospam to e-mail.

Article: 16451
Subject: Re: Xilinx M1.5 Crash
From: Zoltan Kocsi <root@127.0.0.1>
Date: 23 May 1999 18:38:51 +1000
Links: << >>  << T >>  << A >>
Bob Sefton <rsefton@home.com> writes:

> just not much you can do about it). Blame the GUI problems on
> Microsoft not Xilinx. There's not a Windows application in
> existence that runs on all Windows machines.

Then I wonder why FPGA tool vendors push Windows so much ? 
Do they get paid a commission from Microsoft ? 
Can their CEOs play golf with Bill once a month ?

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+
Article: 16452
Subject: Re: High Speed Reconfigurability
From: Tim Tyler <tt@cryogen.com>
Date: Sun, 23 May 1999 19:23:06 GMT
Links: << >>  << T >>  << A >>
In comp.arch.fpga brian_n_miller@yahoo.com wrote:
: rolandpj@bigfoot.com wrote:

:> I like to to view the problem as an extension of HotSpot/JIT.
:> ... Why not do the same thing, but right down to the hardware?

: Reliability.  If an FPGA fails to reconfigure itself properly,
: then how to recover?

The issue of how to recover from errors in a parallel computing system is
not an insoluble one - provided you are prepared to make some performance
sacrifices en route to the goal.

JVN made some of the first tentative steps in this direction in his
"Synthesising Reliable Organisms from Unreliable Components" paper.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

Vice versa - poems about brothels.
Article: 16453
Subject: Re: High Speed Reconfigurability
From: Tim Tyler <tt@cryogen.com>
Date: Sun, 23 May 1999 20:04:13 GMT
Links: << >>  << T >>  << A >>
In comp.arch.fpga Roland PJ Pipex Account <rolandpj@bigfoot.com> wrote:
:>Roland Paterson-Jones <rpjones@hursley.ibm.com> wrote:

[HotSpotting Java bytecode onto FPGAs]

:>This would probably wind up being a rather poor way of exploiting the
:>power of the available hardware ;-/

: In the same way that a pentium/<paste your least favourite cpu> is a poor
: way of exploiting 16m(?) transitors ;-)

Yes, in /exactly/ that sense ;-)

:>Apart from it's thread support, Java's pretty inherently serial.  The
:>thought of attempting to extract parallelism from such a serial stream of
:>instructions usually makes me feel nauseous.
:>
: ...but this is exactly what any optimising compiler does - evaluating
: dependencies is quite close to extracting paralellism - you just need to
: schedule for an infinite-scalar machine, plus conditionals and both their
: branches can be evaluated simultaneously, plus loops can be unrolled to the
: limit of the hardware...

Extracting parallelism from serial code always seems like a dreadful idea
to me.  Sometimes to get a parallel version of a serial algorithm, you
have to completely rewrite it from scratch using a completely new
approach.

While it's quite possible to extract a certain degree of parallelism
from serial code, only extremely advanced artificial intelligence
techniques will be able to deal with complicated cases, and in general,
no finite state machine can re relied upon to perform the task.

: The HANDEL-C examples where the explicit 'par' keyword is used to
: parallelise loops, didn't look too hard to auto-detect.  I imagine any
: detection in C code is going to be more difficult than that for Java
: (due to C's dirty semantics).

Inserting specific keywords into Java would be virtually impossible
without Sun's co-operation.  No doubt making a variant of Java that
targetted FPGAs would be a more sane approach (performance-wise)
than using vanilla Java (which obviously wasn't designed with such
applications in mind).

Even plain ol' Java would no doubt experience /some/ acceleration if
implemented partly on FPGAs (though the ~=400% slower clock speed might
currently mean that very little code benefits very much at the moment).

: I'm not too interested in extracting 100% from an architecture (the answer
: to this is handcoding to the lowest level). What I'm interested in is the
: fastest way to run software that is easily written. I'm convinced that the
: compiler needs to do the hard work, not the programmer. This becomes crucial
: as the scale of a program grows.

For /most/ applications having software that's easy to write is an
important requirement.  It's not my own personal priority, though; I want
lots of (largely asynchronous) parallelism, and very high speed - and
don't care about much else...

:>Java's ability to exploit parallelism (aside from threading code)
:>really isn't very good.  [...] Writing a smart compiler to examine loops to
:>see if this sort of thing is occurring seems to me to be a backwards
:>approach: a /sensible/ concurrent language should allow this type of
:>parallelism to be explicitly indicated, rather than expecting advanced AI
:>techniques to extract the information about when it can and can't be done
:>from the code.

: Good point. Are you suggesting a HANDEL-C-like approach?

Not /really/, except in so far as explicit indication of which code may be
parallelised seems desirable to me.

: I'd like to be convinced that a compiler is really unable to detect these
: things. Do you have an example that would demonstrate this to me?

A compiler /could/ detect lots of sorts of parallelism (in principle).

In general the problem of determining correctly whether a loop is capable
of being executed in a different order from the way specified by the
original programmer (while maintaining the same logical operation) is a
problem equivalent to Turing's halting problem.

The problem /may/ be soluble in a number of important/common cases,
however.

: (on the other hand, what if you're wrong, and it's not parallelisable?

That's OK.  The negative consequences are if a programmer declares
that some code may be executed concurrently and it turns out that
it needs to be executed in a particular sequence, then the code may
perform in a non-deterministic manner.

As code which performs non-deterministically is easy to write in Java
anyway (e.g. either allow program flow or depend on the random number
generator, or the timings of some operations, or start up a couple of
interacting threads), I don't see this as much of a problem.

: Should the compiler verify all such parallelisable assertions?

No - that would probably be impossible ;-)

: This is likely to be as difficult as auto-detecting them in the first place.

Indeed.

: If this stuff is difficult for a compiler to detect, then it's sure to be
: difficult for a human to decide for all but the smallest examples.)

Well, that's not /necessarily/ so.  Human programmers can do things like
trying the code either way and picking whichever way produces the desired
result (an option not available to the compiler).

It may even be that the code is /not/ strictly parallelisable, but that
the indeterminacies resulting from executing code sections out of the
original sequence are tiny or irrelevant for some reason (this would
be the case with a large section of one of my programs).  A compiler might
have a hard time figuring out such cases without explicit clues.

In some respects, I'm sympathetic to the view that human programmers
shouldn't have to bother with concurrency issues.  OTOH, I don't see
that it can be avoided in practice - parallelising serial algorithms is
currently /much/ too difficult a problem to be left to machines.

Designing an electronic circuit is too different a design problem to
writing a serial program to expect that a good solution to the
programming problem will easily translate into a good soultion to the
circuit design one.

Intelligence is needed to do much of the translation.  It's a domain is
one where human programmers are currently much more adept than machines.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  tt@cryogen.com

Chaste makes waste.
Article: 16454
Subject: Re: 4062XL problems and solutions
From: Ray Andraka <randraka@ids.net>
Date: Sun, 23 May 1999 21:18:32 -0400
Links: << >>  << T >>  << A >>
This is a common problem with high clock rates in larger parts.  Distribute
the CE in a pipelined tree structure, with each branch node on the tree
driving only geographically close CLBs.    Alternatively, you can replicate
the CE generation logic several times and place each copy so that it drives
only geographically close CLBs.  Put any gating logic on the CE function ahead
of the CE flip-flops (watch out for the Xilinx macros in that regard, many
include an OR gate on the CE input to make sure CE gets applied when another
macro input is applied - Load on the CC16CLE for instance).  If possible, use
the CE input to the CLB.  If the CE has to use the LUT, then make sure the CE
signal comes in at the last level of the logic, so that it does not have
multiple CLB delays.



> > Problem #1 - Clock enable
> >   The biggest problem I ran into was routing getting the clock enable to
> > the logic to slow it down to 40 Mhz.  In order for the clock enable to
> > work properly, it has to be there in 1 80Mhz cycle = 12.5 ns. I found
> > that using a bufg or bufgls did not work for especially for the iobs.
> > The solution for me was to route the problem locally through another
> > flop by reclocking the clock enable.
>



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 16455
Subject: Re: Case study: Viewlogic's IntelliFlow
From: Ray Andraka <randraka@ids.net>
Date: Sun, 23 May 1999 21:25:44 -0400
Links: << >>  << T >>  << A >>
Jim,

My experience with intelliflow is about the same.  My initial impression of it
was "What the Hell do I need that for, it just gets in the way of what I want
to do".  I can see perhaps where it might be useful for someone who didn't
already know how to drive the tools separately and who didn't mind the
learning curve for a "helper" application.  I personally put it in about the
same category as the dancing paper-clip in microsoft products, only it isn't
quite as annoying.

Jim Kipps wrote:

> Bill-
>
> Thanks for the feedback.  I've had my own struggles with early releases of
> IntelliFlow and still have some, but the general useability of IntelliFlow
> has
> improved significantly since its first release.  The current release in
> Workview Office 7.53 is much improved with a new project wizard.  It's
> worth another look.  May I ask which version you were using?
>
> Regards,
> -Jim
>
> Bill Kury wrote:
>
> > In article <3741869F.9CFD2583@viewlogic.com>,
> >   fpga@viewlogic.com wrote:
> > >
> > > IntelliFlow Users,
> > >
> > > If you would like to contribute to a case study of Viewlogic's
> > > IntelliFlow, please respond to this email.  I'd like to know about
> > > your experiences, good and bad, with this tool and what impact
> > > it has had with your design methodology.  I'll post a summary
> > > of the results to comp.arch.fpga at the conclusion of the study.
> > >
> > > Thanks,
> > > -Jim
> > >
> >  Well..this is a thorny subject.  I have the viewlogic tools for doing
> > fpga's including viewsim,intelliflow, and Fpga express.  Viewsim is
> > excellent, it is very fast and allows you to see simulation in progress.
> >  Fpga express is also quite good.  I have never used symplicity or
> > exemplar so I can't compare to those two but, I have been able to get
> > fpga express to do everything that I need.  Intelliflow is another
> > question entirely :(  I am sorry but I have to be honest.  I found it
> > terrible!  I had a tough time just trying to get it to work, the support
> >  was not very good, and, probably it's worst feature is that the
> > documentation is about at good as a bump on log.  I struggled with it
> > for a couple of weeks, then I ended up going on a vhdl course where I
> > was able to use the aldec tool's.  There was no comparison.  I bought
> > the aldec tool's and use them to this day.
> > I have to premise this conversation with a couple of things.  First,
> > when I was using the viewlogic tools, I was in the learning stage of
> > vhdl.  When you are at this stage, the viewlogic tools immediately show
> > their flaws.  If I remember correctly there is a compiler called vantage
> >  used in viewlogic.  This compiler would give me the most wonderful
> > messages if I had something wrong in my code.  How that message
> > correlated to the problem is beyond my scope of reasoning.( Maybe the
> > problem is that I don't have enough scope :)))
> > To be intelliflow specific, when a new vhdl file is added that would not
> > analyze, it would come back with "File would not analayze".  This is
> > good except for the fact that some idea to what the problem is would be
> > nice.
> > I know that I have kind of gone off in various directions but to
> > summarize, intelliflow is best rated poor.  It does not let you spend
> > your time sorting out design issues, instead, you spend your time
> > sorting out tool problems.
> >
> > Sorry :(
> >
> > Bill
> > > --
> > > --------------------------------------------------------
> > > James R. Kipps                  FPGA Marketing Manager
> > > jkipps@viewlogic.com            Phone: (508) 303-5246
> > > --------------------------------------------------------
> > >
> > >
> >
> > --== Sent via Deja.com http://www.deja.com/ ==--
> > ---Share what you know. Learn what you don't.---
>
> --
> --------------------------------------------------------
> James R. Kipps                  FPGA Marketing Manager
> jkipps@viewlogic.com            Phone: (508) 303-5246
> --------------------------------------------------------



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 16456
Subject: Re: Is schmitt trigger possible with Xilinx 9536?
From: Ray Andraka <randraka@ids.net>
Date: Sun, 23 May 1999 21:31:16 -0400
Links: << >>  << T >>  << A >>
I don't think so, Tim.

The only way to create a schmitt trigger function in a PLD without schmitt
trigger inputs is to use up an additional pin as an output to provide feedback
to a resistive divider.  The other option you have is to add a schmitt trigger
chip between the input and your PLD.




> I  created a Schmitt trigger once on a Lattice CPLD, using schematic entry.
> You can do it with a 2-input NAND and an inverter.
>



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 16457
Subject: Re: Virtex based PCI cards
From: Ray Andraka <randraka@ids.net>
Date: Sun, 23 May 1999 21:40:20 -0400
Links: << >>  << T >>  << A >>
Austin,

Unless it is a board for something going into production, I'd rather have the
PCI in a separate part so that I can get use of the entire virtex part, and so
I don't have to worry about how the PCI interface is going to affect the
floorplanning for my stuff.  I only use these type of boards in one-off
designs and as prototyping platforms.  For the most part, they are way too
expensive to use in a product that is going to be produced and sold in any
kind of quantity.

Austin Franklin wrote:

> Why don't you guys have the PCI interface in the Xilinx?
>
> Malachy Devlin <m.devlin@nallatech.com> wrote in article
> <B4000FE0503ED211864100104B4C66C30972A9@CONTEXT>...
> > Nallatech has been supplying a Virtex development platform since
> > February. This is a 32bit 33Mhz PCI card with a 300K - 800K Virtex
> > device and 2 individual banks of 2MBytes 100Mhz ZBT SRAM.
> > The PCI card, called the Ballynuey, handles all the PCI issues and comes
> > with a pre-configured Spartan that handles the PCI interfacing and data
> > buffering between the Virtex and the PC application. PCI drivers, Virtex
> > debug tool, FPGA configuration and Application API are included with the
> > card.
> > Additionally the card includes 4 DIME modules for expansion and custom
> > I/O. Currently there are modules for Image Capture and Display, a Dual
> > XCV1000 module (yes over 2Million gates!) and various other I/O modules
> > (e.g. LVDS) with more in the pipeline. The modules can provide over
> > 2Gbytes/sec bandwidth and has over 200 I/O connections.
> >
> > Configuration of the on-board Virtex is configured dynamically over the
> > PCI using the tools provided with the card (and is much faster than
> > Xchecker!) If additional DIME modules are placed on the card their FPGAs
> > are also individually configurable via PCI.
> >
> >
> > Check out the web site for more details and new developments soon to be
> > announced at http://www.nallatech.com/
> >
> >
> > Malachy Devlin
> > Nallatech Ltd
> > m.devlin@nallatech.com
> >
> >
> > > -----Original Message-----
> > > From: alfred fuchs [mailto:alfred.fuchs@siemens.at]
> > > Posted At: 12 May 1999 19:09
> > > Posted To: fpga
> > > Conversation: Virtex based PCI cards
> > > Subject: Re: Virtex based PCI cards
> > >
> > >
> > > I've just finished the design of a CompactPCI board (6U) with
> > > one Virtex1000
> > > and two synchronous SRAM-modules (2Mx72). It mainly uses
> > > rear-panel-I/O
> > > (more than 100 signals) and is therefore open for various
> > > applications. The
> > > PCI-IF is a PLX9054, the FPGA is configured by the PCI-master.
> > > Pricing is TBD, but we tend to be expensive.
> > >
> > > Alfred Fuchs
> > > Siemens Austria
> > > PSE PRO LMS2
> > > +43/1/1707-34113
> > >
> > > Atif Zafar schrieb:
> > >
> > > > Hello:
> > > >
> > > >     Does anyone know of any development boards (PCI) that
> > > use the Virtex
> > > > FPGA? I am interested in a board with preferably several
> > > XV800 or XV1000
> > > > devices along with RAM for prototyping a custom graphics pipeline. I
> > > > have heard of the PCI Pamette board, but to my knowledge
> > > this does not
> > > > have Virtex silicon. Thanks for any info.
> > > >
> > > > Atif Zafar
> > > > Regenstrief Institute
> > > > Zafar_A@regenstrief.iupui.edu
> > >
> >
> >



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 16458
Subject: Re: Request FAQ
From: Ray Andraka <randraka@ids.net>
Date: Sun, 23 May 1999 21:51:21 -0400
Links: << >>  << T >>  << A >>
Here's the FAQ:

1.  Q: Is there a FAQ?  A: No, scan deja-news for your question.



As for the rules:
1.  Don't use the email addresses pulled off usegroup postings for your spam
mailing list.  The regular contributors to this newsgroup generally post on
their time and provide a very valuable service for readers who may not have the
expertise of these power users.  There is little that is as annoying as a ton of
unsolicited advertising junk filling up the email in-basket.

2.  The usual other rules.

Rob Putala wrote:

> Where can I obtain a FAQ for this newsgroup?  I would like to advise
> subscribers of opportunities I am working on, but do not want to upset or
> get flamed.
>
> Any help with the rules will be appreciated!  Also, any suggestions on other
> newsgroups will be welcomed.
>
> --
> rcp@frontiernet.net
> F-O-R-T-U-N-E Personnel Consultants of Worcester
> (978) 466 - 6800



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 16459
Subject: For Sale: Altera Max+Plus II
From: chris@spam.com (Chris)
Date: Mon, 24 May 1999 02:43:11 GMT
Links: << >>  << T >>  << A >>
Hello,

I'm selling a full Altera MAX+Plus II package, V9.01.  It's new and still sealed.  This package is their "Magnum" 
product which supports full VHDL.  Great for DSP design.  Includes manual, CD-ROM and dongle.  Doesn't include 
maintainance.  I will transfer ownership thru Altera upon purchase.  Originally $7000, asking $1600, including shipping.

- Chris

Note: to reply change "spam" to "netcom" in the return address, thanks.

Article: 16460
Subject: Re: IOB tristate register in Xilinx XLA devices
From: "David Hawke" <dhawke@globalnet.co.uk>
Date: Mon, 24 May 1999 12:05:21 +0100
Links: << >>  << T >>  << A >>
Hi,

1.5is2 allows you to generate a back annotated netlist in order to simulate
the device, in that respect, with the hard macro.
Be careful when timing the design as FFS to FFS does not work with the
TRIFF. Use Period = etc.

The only problem is functional simulation.

2.1i supports the correct use of the TRIFF in 4kXLA, and SpartanXL. Virtex
is already supported in 1.5is2.
2.1i FCS is June.

Regards,
David Hawke.
Xilinx.

Edward Moore wrote in message
<927376848.20543.0.nnrp-03.c2de43d1@news.demon.co.uk>...
>Has anyone successfully used the iob tristate registers in a 4000-XLA
device
>?.
>
>I am trying to decrease the clock to tristate time of some outputs
connected
>to ZBT rams. I've read the relevant xilinx app-note on how to use the iob
>.nmc hard-macro, and i can't see any sensible way of doing a front-end
>simulation of the xilinx device and the rams, since the iob macro doesn't
>have a PAD pin.
>
>It seems i would need to have one design for simulation, using a model of
>the iob register connected to the rams, and another design for P&R which
>doesn't have the i/o pins. Is this correct ?.
>
>I was hoping for Unified Library support for the iob tristate flip-flop,
but
>Xilinx seems to be moving away from using iob library primitives (they
don't
>seem to be used for Virtex's). So has anyone heard of when the P&R software
>will be able to utilize the tristate registers automatically ?
>
>Edward Moore
>
>PS : you can use a -XL bitstream in a -XLA device, and suprisingly
>vice-versa.
>
>


Article: 16461
Subject: Re: Xilinx M1.5 Crash
From: Bob Sefton <rsefton@home.com>
Date: Mon, 24 May 1999 13:10:30 GMT
Links: << >>  << T >>  << A >>
They push their Windows products vs. the Unix competition but I've
never heard a tool vendor stupid enough to push the OS itself as
superior to anything.

Zoltan Kocsi wrote:
> 
> Bob Sefton <rsefton@home.com> writes:
> 
> > just not much you can do about it). Blame the GUI problems on
> > Microsoft not Xilinx. There's not a Windows application in
> > existence that runs on all Windows machines.
> 
> Then I wonder why FPGA tool vendors push Windows so much ?
> Do they get paid a commission from Microsoft ?
> Can their CEOs play golf with Bill once a month ?
> 
> Zoltan
> 
> --
> +------------------------------------------------------------------+
> | ** To reach me write to zoltan in the domain of bendor com au ** |
> +--------------------------------+---------------------------------+
> | Zoltan Kocsi                   |   I don't believe in miracles   |
> | Bendor Research Pty. Ltd.      |   but I rely on them.           |
> +--------------------------------+---------------------------------+
Article: 16462
Subject: Re: Virtex based PCI cards
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 24 May 1999 10:35:32 -0400
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> Austin,
> 
> Unless it is a board for something going into production, I'd rather have the
> PCI in a separate part so that I can get use of the entire virtex part, and so
> I don't have to worry about how the PCI interface is going to affect the
> floorplanning for my stuff.  I only use these type of boards in one-off
> designs and as prototyping platforms.  For the most part, they are way too
> expensive to use in a product that is going to be produced and sold in any
> kind of quantity.
> 
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka

How about a chip where the PCI interface was not done in the
programmable logic, but instead was just added to the chip as a standard
hardwired function? Just like the boundary scan or the DLLs. 

It would seem that there are enough PCI based designs being done that it
would be a high volume product.


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 16463
Subject: Re: Virtex based PCI cards
From: Ray Andraka <randraka@ids.net>
Date: Mon, 24 May 1999 11:51:24 -0400
Links: << >>  << T >>  << A >>
Ask Lucent how many of those they are selling.  They've got an FPGA with a PCI
interface wrapped in.

Rickman wrote:

> Ray Andraka wrote:
> >
> > Austin,
> >
> > Unless it is a board for something going into production, I'd rather have the
> > PCI in a separate part so that I can get use of the entire virtex part, and so
> > I don't have to worry about how the PCI interface is going to affect the
> > floorplanning for my stuff.  I only use these type of boards in one-off
> > designs and as prototyping platforms.  For the most part, they are way too
> > expensive to use in a product that is going to be produced and sold in any
> > kind of quantity.
> >
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email randraka@ids.net
> > http://users.ids.net/~randraka
>
> How about a chip where the PCI interface was not done in the
> programmable logic, but instead was just added to the chip as a standard
> hardwired function? Just like the boundary scan or the DLLs.
>
> It would seem that there are enough PCI based designs being done that it
> would be a high volume product.
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> remove the XY to email me.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 16464
Subject: Re: How synthesize tools concern with size of the design?
From: ems@riverside-machines.com.NOSPAM
Date: Mon, 24 May 1999 18:59:45 GMT
Links: << >>  << T >>  << A >>
On Fri, 21 May 1999 09:41:43 +0100, David Pashley
<David@edasource.com> wrote:

>In article <37446aa8.4459222@news.dial.pipex.com>, ems@riverside-
>machines.com.NOSPAM writes
>>there is absolutely *no way* that fpga express is competitive in terms
>>of vhdl language support, and i'm sure that you know this as well as
>>the rest of us do. true, there have been major advances in both DC and
>>express recently, but you've still got some way to go.
>>
>>on the other hand, there have been some really nice additions in 3.1 -
>>FST/scripting and attribute passing primarily, which would make this a
>>very competitive tool if you got the language support right.
>>
>>evan
>
>As I understand it, and as you suggest, the language support in DC and
>FPGA Express is the same.

i seem to have missed the party - i've been increasing my skills base
in nappy changing... :*)

first, DC and express use different analysers (although they
presumably had a common ancestor at some time). my point was simply
that both analysers have been improving, albeit in different
directions. some obvious differences spring to mind -

(1) DC (since 1998.08) now supports numeric_std
(2) express now supports various language features related to die
placement. some enhancements in express 3.0 appear to have been added
specifically to allow handling of xilinx RPMs (something which i
suspect this NG was largely responsible for).
(3) express has had some token '93 support for at least a year. this
wasn't present in 1998.08 - i don't know what's happened in 99.05.

however, the fact is that both analysers do a very poor job of
supporting the vhdl LRMs, not to mention additional specs such as
numeric_std, in the case of express. this was the major complicating
factor in 1076.6 (the vhdl synthesis interoperability 'standard'), and
has resulted in a spec which has been crippled by the need to address
the lowest common denominator (although, ironically, it didn't even
manage to do this, and the synopsys products aren't compliant, but
that's another story).

>How does the fact that Synopsys goes from strength to strength, and is
>unarguably both successful and competitive (see their website, Q2 sales
>21% up at $190m) square with your comments?

i'm not knocking DC. there's far more to synthesis than a language
front end. but, as far as their revenues go, i suspect that F,U,&D are
significant factors in their success.

>Do you mean that the language requirements for FPGA are totally
>different from those for ASIC?

no; it's the development processes which are different. in an asic
environment, you're much more concerned with the back-end flow, and
the front end entry mechanism is a relatively small part of the flow.

the fpga environment is very different. the vendors have invested in
push-button flows, and implementation is a *much* smaller part of the
process than in the asic world. the net result of this is that the
front-end entry mechanism is, relatively, much more important. this is
why, IMO, the driving force for language improvements has come from
the fpga world, and not the asic world (just look at the example of
'93 'support' in express).

synopsys made the mistake of entering the fpga market without
realising that it was different from the asic market. many users
hadn't even heard of synopsys, and weren't willing to take a hit
simply to buy into the name. ok, they're improving, but they don't
seem to be in a hurry.

evan

Article: 16465
Subject: Re: Virtex based PCI cards
From: "Austin Franklin" <austin@dark9room.com>
Date: 24 May 1999 21:19:55 GMT
Links: << >>  << T >>  << A >>
The problem I have with that, is it locks me into THE interface THEY
provide for the back end.

The pins are used for the back end interface anyway, so why not just
connect them to the PCI bus. Also, the PCI interface is supposedly only
supposed to take up a few 10s of thousands of gates MAX, and that's hardly
anything to worry about in a 300k-800k gate part.  If it is, someone is
doing something wrong.

Austin


Ray Andraka <randraka@ids.net> wrote in article
<3748AE04.BF8B2490@ids.net>...
> Austin,
> 
> Unless it is a board for something going into production, I'd rather have
the
> PCI in a separate part so that I can get use of the entire virtex part,
and so
> I don't have to worry about how the PCI interface is going to affect the
> floorplanning for my stuff.  I only use these type of boards in one-off
> designs and as prototyping platforms.  For the most part, they are way
too
> expensive to use in a product that is going to be produced and sold in
any
> kind of quantity.
> 
> Austin Franklin wrote:
> 
> > Why don't you guys have the PCI interface in the Xilinx?
> >
> > Malachy Devlin <m.devlin@nallatech.com> wrote in article
> > <B4000FE0503ED211864100104B4C66C30972A9@CONTEXT>...
> > > Nallatech has been supplying a Virtex development platform since
> > > February. This is a 32bit 33Mhz PCI card with a 300K - 800K Virtex
> > > device and 2 individual banks of 2MBytes 100Mhz ZBT SRAM.
> > > The PCI card, called the Ballynuey, handles all the PCI issues and
comes
> > > with a pre-configured Spartan that handles the PCI interfacing and
data
> > > buffering between the Virtex and the PC application. PCI drivers,
Virtex
> > > debug tool, FPGA configuration and Application API are included with
the
> > > card.
> > > Additionally the card includes 4 DIME modules for expansion and
custom
> > > I/O. Currently there are modules for Image Capture and Display, a
Dual
> > > XCV1000 module (yes over 2Million gates!) and various other I/O
modules
> > > (e.g. LVDS) with more in the pipeline. The modules can provide over
> > > 2Gbytes/sec bandwidth and has over 200 I/O connections.
> > >
> > > Configuration of the on-board Virtex is configured dynamically over
the
> > > PCI using the tools provided with the card (and is much faster than
> > > Xchecker!) If additional DIME modules are placed on the card their
FPGAs
> > > are also individually configurable via PCI.
> > >
> > >
> > > Check out the web site for more details and new developments soon to
be
> > > announced at http://www.nallatech.com/
> > >
> > >
> > > Malachy Devlin
> > > Nallatech Ltd
> > > m.devlin@nallatech.com
> > >
> > >
> > > > -----Original Message-----
> > > > From: alfred fuchs [mailto:alfred.fuchs@siemens.at]
> > > > Posted At: 12 May 1999 19:09
> > > > Posted To: fpga
> > > > Conversation: Virtex based PCI cards
> > > > Subject: Re: Virtex based PCI cards
> > > >
> > > >
> > > > I've just finished the design of a CompactPCI board (6U) with
> > > > one Virtex1000
> > > > and two synchronous SRAM-modules (2Mx72). It mainly uses
> > > > rear-panel-I/O
> > > > (more than 100 signals) and is therefore open for various
> > > > applications. The
> > > > PCI-IF is a PLX9054, the FPGA is configured by the PCI-master.
> > > > Pricing is TBD, but we tend to be expensive.
> > > >
> > > > Alfred Fuchs
> > > > Siemens Austria
> > > > PSE PRO LMS2
> > > > +43/1/1707-34113
> > > >
> > > > Atif Zafar schrieb:
> > > >
> > > > > Hello:
> > > > >
> > > > >     Does anyone know of any development boards (PCI) that
> > > > use the Virtex
> > > > > FPGA? I am interested in a board with preferably several
> > > > XV800 or XV1000
> > > > > devices along with RAM for prototyping a custom graphics
pipeline. I
> > > > > have heard of the PCI Pamette board, but to my knowledge
> > > > this does not
> > > > > have Virtex silicon. Thanks for any info.
> > > > >
> > > > > Atif Zafar
> > > > > Regenstrief Institute
> > > > > Zafar_A@regenstrief.iupui.edu
> > > >
> > >
> > >
> 
> 
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka
> 
> 
> 
Article: 16466
Subject: Re: Virtex based PCI cards
From: Steven Casselman <sc@vcc.com>
Date: Mon, 24 May 1999 14:20:10 -0700
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> Austin,
>
> Unless it is a board for something going into production, I'd rather have the
> PCI in a separate part so that I can get use of the entire virtex part, and so
> I don't have to worry about how the PCI interface is going to affect the
> floorplanning for my stuff.  I only use these type of boards in one-off
> designs and as prototyping platforms.  For the most part, they are way too
> expensive to use in a product that is going to be produced and sold in any
> kind of quantity.
>

The PCI interface takes so little in a virtex that using another chip
does not much sense. Also with a chip between the BUS (any bus)
and your design you incur latency and expence.  By having the
logic right next to the bus interface you are as close to a "reconfigurable
coprocessor" model as you are going to get.  As for price the HOT2 is
$695 for single units and around $400 in volume.  This makes it viable
for small production runs form 10-100.  I'm sure the econmonics for a
small virtex based system will be simular.

--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 16467
Subject: Re: How synthesize tools concern with size of the design?
From: Jim Kipps <jkipps@viewlogic.com>
Date: Mon, 24 May 1999 20:01:38 -0400
Links: << >>  << T >>  << A >>
Evan-

Thank you for mentioning other features of 3.1 in a good light, but I
stand behind my
statement that FPGA Express is competitive with regard to language.

Synplify and Leonardo both support broader subsets of VHDL and Verilog,
but only
FPGA Express (and FPGA Compiler II) is fully Design Compiler compatible.
While
there are many FPGA designers who never intend to take their designs to
ASICs, there are
also many who use FPGAs for ASIC prototyping.  For this latter group, DC
compatibility
is an important criteria for selecting an FPGA synthesis tool.  (Yes, I
know that Leonardo
can target ASICs for less, but Leonardo does not have the market share
that DC boasts
and most ASIC design centers use DC).

Regards,
-Jim

ems@riverside-machines.com.NOSPAM wrote:

> On Fri, 14 May 1999 22:38:31 -0400, Jim Kipps <jkipps@viewlogic.com>
> wrote:
>
> >What I look for in synthesis is: 1) library coverage
> >(you can't synthesize what you can't target), 2) quality
> >of results, and 3) language support.  There are other
> >things that are important, like ease of use, price, and
> >runtime performance, but these are the three biggies.
> >
> >I've had experience with Leonardo (which also supports
> >user attributes), Synplify, and FPGA Express and can
> >honestly say that all three are competitive with regard
> >to libraries, performance, and language.
>
> there is absolutely *no way* that fpga express is competitive in terms
> of vhdl language support, and i'm sure that you know this as well as
> the rest of us do. true, there have been major advances in both DC and
> express recently, but you've still got some way to go.
>
> on the other hand, there have been some really nice additions in 3.1 -
> FST/scripting and attribute passing primarily, which would make this a
> very competitive tool if you got the language support right.
>
> evan

--
--------------------------------------------------------
James R. Kipps                  FPGA Marketing Manager
jkipps@viewlogic.com            Phone: (508) 303-5246
--------------------------------------------------------


Article: 16468
Subject: Re: High Speed Reconfigurability
From: Jonathan Feifarek <feifarek@ieee.org>
Date: Mon, 24 May 1999 19:00:31 -0600
Links: << >>  << T >>  << A >>

Tim Tyler wrote:
> 
> While I'm all in favour of a portable, universal means of describing
> algorithms that enables them to be implemented efficiently on parallel
> hardware, unfortunately, Java doesn't look /remotely/ like what I
> envisage.

Tim,

I agree, though there seems to be enough work using this as a start
(J-Bits and JHDL are written in Java -- plus check out this cool
product-in-process: http://www.lavalogic.com/products.html ) that I find
it hard to ignore.
I picture some sort of icon oriented language similar to the Khoros
glyphs or the Labview environment.  The designer may even use icon
layout schemes to effectively floorplan.  the "wires" that connect the
icons would represent dataflow and hence causality that a compiler could
use in determining possible time / logic switches, and parallelism with
or without restrictions imposed by the engineer.

> 
> I envisage something like a "rubber circuit" which 'stretches' to fit
> the characteristics of the target hardware, while retaining the relevant
> inter-component distances and ratios, for purposes of retaining correct
> synchronous operation.

This sounds like an interesting concept, but I'm not sure I follow. 
Does the "source design" have any knowledge of the the target hardware,
or is there an intermediate representation?  It sounds like you have in
mind something more sophisticated than an FPGA vendor's macro library
which has the same properties.  Please explain some more about this.

Cheers,

Jonathan
-- 
Jonathan F. Feifarek
Consulting and design
Programmable logic solutions
Article: 16469
Subject: Re: High Speed Reconfigurability
From: Jonathan Feifarek <feifarek@ieee.org>
Date: Mon, 24 May 1999 19:20:14 -0600
Links: << >>  << T >>  << A >>

Michael Schuerig wrote:
> 
> I have no clue about FPGAs, but, I'm wondering, aren't the switching
> times prohibitive? Remember, you not only have to switch the hardware
> around for thread switches in your own process, but also for context
> switches among all the processes running on the hardware. Remember, you
> don't own the processor.
>

Michael,
In a way, you do own the processor with a Reconfigurable Computer,
because the degree of parallelism possible.
In theory, if one process (thread) need more logic than is available,
the logic allotted to that process can be reconfigured to perform the
rest of the thread without affecting the context of the other threads. 
Or "idle" threads could be pre-empted to free logic for the "active"
thread (after saving the internal state of the replaced logic).
In practice the switching times depend on the hardware (usually FPGAs). 
Standard FPGAs require the entire configuration to be loaded (serially
to boot) - a growing problem as the number of configuration bits
increase with larger components.  Some FPGAs (notably Atmel, the defunct
Xilinx 5000, 6000 series, and now the Xilinx Virtex series) allow
partial reconfigurability, which usually reduces switching times. 
On-chip storage of configuration data which can be loaded in a single
clock cycle was the original topic of discussion for this newsgroup
thread.  There was earlier reference to some DARPA funded research aimed
at this goal.
There is a Reconfigurable Computing chip just announced by NEC which
apparently can store multiple configurations and switch between them. 
Check out this link: http://www.edtn.com/story/OEG19990215S0004 .
Maybe the switching time problem has finally been solved. 
Jonathan
-- 
Jonathan F. Feifarek
Consulting and design
Programmable logic solutions
Article: 16470
Subject: Re: High Speed Reconfigurability
From: Jonathan Feifarek <feifarek@ieee.org>
Date: Mon, 24 May 1999 20:06:49 -0600
Links: << >>  << T >>  << A >>
Roland Paterson-Jones wrote:
> >
> > I like to to view the problem as an extension of HotSpot/JIT technologies
> > in virtual machine implementation, most notably lately in Java Virtual
> > Machines. What these technologies do is profile a program on-the-fly (with
> > embedded profiling instructions, or through interpretation, or whatever).
> > When they determine that a certain portion of a program is heavily
> > exercised, then that portion is (re-)compiled with heavy optimisation.
> >
> > Now, why not do the same thing, but right down to the hardware, rather than
> > down to machine code. What you need, however, is a general compiler from a
> > high-level language (Java bytecode?) to fpga gates. According to the empty
> > response to a previous posting, nobody is interested in such a thing.
> >

I believe that BYU has done work on this topic (hardware level on the
fly reconfiguration).  Of course, they've done a heck of a lot, so I
can't recall exactly where I saw the reference.  You may find something
at http://splish.ee.byu.edu/docs/papers1.html .

> > I have dreams of a single multitasked fpga doing all of the stuff that each
> > separate component of a motherboard + cards currently does (or an array of
> > fpga's multi-tasking this). Cheap and fast and simple (once you've
> > implemented the JIT technology!).
> >

Yes!  I have the same dreams!  Basically, System On a Chip - chips are
getting bigger, and with judicious multiplexing reasonably sized systems
can be implemented this way now.  The cheap (and simple) aren't quite
there yet, though, and speed is traded with both these factors.
Of course, interface circuitry is still required to connect to external
systems or subsystems.  The concept of reconfigurability can be extended
to these circuits - work is already being done on reconfigurable analog
and mixed mode circuitry.

Who knows? JIT technology may be the way these systems are made cheaper
and simpler.

Jonathan

-- 
Jonathan F. Feifarek
Consulting and design
Programmable logic solutions
Article: 16471
Subject: virtex vs apex20k family comparison for DSP ?
From: muzok@nospam.pacbell.net (muzo)
Date: 24 May 1999 19:36:28 PDT
Links: << >>  << T >>  << A >>
hi,
has anyone studied virtex vs apex20k for dsp applications and have
postable results ?

thanks for any and all comments.
muzo

Verilog, ASIC/FPGA and NT Driver Development Consulting (remove nospam from email)
Article: 16472
Subject: Re: Xilinx M1.5 Crash
From: Zoltan Kocsi <root@127.0.0.1>
Date: 25 May 1999 16:07:29 +1000
Links: << >>  << T >>  << A >>
Bob Sefton <rsefton@home.com> writes:

> They push their Windows products vs. the Unix competition but I've
> never heard a tool vendor stupid enough to push the OS itself as
> superior to anything.

Well, I didn't say they had said Windows was better. I only said 
they were pushing it. When you can get Windows tools free or very cheap
and the same tool from the same vendor for unix for serious money or 
not at all, then one thinks about the cause. 

On possibility is that Windows is indeed superior and writing a 
synthesis engine or a P&R tool under Windows is a joy while under 
unix it's a nightmare. Along the same lines, Windows tools might be
inherently glitch free while unix tools require very costly customer
support which justifies the cost or abandonment of the platform.

Alternatively, one might form a Conspiracy Theory along the lines
of toolmakers receiving financial compensation or fringe benefits for 
their Windows efforts from some company which is interested in Windows
gaining market share against unix.

Since the first scenario doesn't sound very plausible and the second
is rather malicious, I'm keen on learning the real reasons behind
the apparent Windows orientation of the EDA industry.

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+
Article: 16473
Subject: LUT implementation in XC3000
From: username@dso.org.sg
Date: Tue, 25 May 1999 15:07:30 +0800
Links: << >>  << T >>  << A >>
Hello,

Does anyone know how the LUT is implemented or can be changed in the 
XC3000 ?  For example, I want to implement a Boolean equation, how do 
I know if it is implemented thru a AND-OR  or  AND-NOR  type of LUT?
Please advise.

email: csoolan@dso.org.sg
Article: 16474
Subject: Re: High Speed Reconfigurability
From: "Roland PJ Pipex Account" <rolandpj@bigfoot.com>
Date: Tue, 25 May 1999 08:20:29 +0100
Links: << >>  << T >>  << A >>

Tim Tyler wrote in message <927489612.169709@BITS.bris.ac.uk>...
>In comp.arch.fpga Roland PJ Pipex Account <rolandpj@bigfoot.com> wrote:
>:>Roland Paterson-Jones <rpjones@hursley.ibm.com> wrote:
>

>: ...but this is exactly what any optimising compiler does - evaluating
>: dependencies is quite close to extracting paralellism - you just need to
>: schedule for an infinite-scalar machine, plus conditionals and both their
>: branches can be evaluated simultaneously, plus loops can be unrolled to
the
>: limit of the hardware...
>
>Extracting parallelism from serial code always seems like a dreadful idea
>to me.  Sometimes to get a parallel version of a serial algorithm, you
>have to completely rewrite it from scratch using a completely new
>approach.

I had a look at Paterson and Henessey last night. They had some empirical
results for average no. instructions schedulable on the same clock cycle for
some standard SPEC benchmarks. They ranged from 17 to 150+ !!! They were
motivating superscalar processors, and looking at how close you could come
to this theoretical maximum with realistic processor designs (finite
lookahead window, finite register renaming set, finite memory ports,
imperfect branch prediction etc.) It seems to me that many of these
'realistic' limitations (bar memory ports) don't apply to compilation to
fpga.

But 17 I'd settle for. 150+ is huge. The large numbers tended to be
floating-point tests.

Roland





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
2017JanFebMarApr2017

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