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 61950

Article: 61950
Subject: Re: PCI-X bridge from Xilinx LogiCORE and half bridge
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Wed, 15 Oct 2003 09:11:39 -0700
Links: << >>  << T >>  << A >>

Hello,

> How will the core behave if the host will issue a type 1
> config cycle while selecting the xilinx device with IDSEL?

It will ignore the cycle, because it was designed to do so.

> Can my internal logic sniff configuration transaction
> on the PCI bus?

Not really.  The v3.0 core has some provision to do things like
this, but the v5.0 core does not.  Plus, even if you could, the
configuration mechanism will not work properly.  What if you
need to do a config read?  Snooping won't help, because you
need to actively participate in the transaction.

If you contact your Xilinx FAE, and indicate you need to do a
PCI bridging application, they can help you.

Eric

Article: 61951
Subject: To our future engineers, smart and otherwise...
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 15 Oct 2003 09:34:01 -0700
Links: << >>  << T >>  << A >>
If your homework is too tough,
and the time just flies away,
thinking hard is not enough,
click: comp.arch.fpga.

There you find those friendly souls,
Austin, Philip, Peter, Ray
filling in your mental holes, 
making problems go away.

But learning is for you to do, 
even if it hurts the brain.
The one that has to learn is you.
There's no substitute for pain.

If you want to learn design
don't treat homework just as play.
Real life is not benign,
and you'll have to earn your pay!

sooner or later...

These lines were triggered by the endless dice discussion.
Peter Alfke, Xilinx Applications

Article: 61952
Subject: ICAP Virtex2
From: panjuhwa_fpga@yahoo.com (PanJuHwa)
Date: 15 Oct 2003 09:53:19 -0700
Links: << >>  << T >>  << A >>
Hi,

  I am very interested in exploring the use of ICAP for
self-reconfiguration of the Virtex2 fpga. XAPP 662 describes the
in-system reconfiguration of RocketIO attributes, and I have been
trying to understand the process of self-reconfiguration through this
application note as well as the reference design that comes with it.

  It seems that we need to configure the FPGA with a bitstream
generated from hdl that includes an PLB bus arbitrator and controller,
as well as ICAP IPIF to the PLB. Does this mean the ICAP, possessing
access the configuration memory, would actually have access to parts
of the configuration memory that defines the arbitrator and ICAP IPIF
as well? Or are is the information used to configure the arbitrator
and IPIF somewhere else? Say for instance the fpga is to be configured
with a jpeg encoder. Would the configuration memory accessed by the
ICAP be solely occupied by the jpeg encoder configuration, or by the
ipif etc as well? If in the latter case, then ICAP should never modify
areas defining the IPIF, is this correct?

  I would appreciate too if someone who has done this before can
provide some guidelines on how I can set the system up to use the
ICAP. Thanks in advance!:)

Ju Hwa

Article: 61953
Subject: Ph.inisheD.
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 15 Oct 2003 17:34:19 +0000 (UTC)
Links: << >>  << T >>  << A >>
Well, I FINALLY finished my PhD.

For those who are exceedingly bored, my dissrtation is online (The
SFRA: A Fixed-Frequency FPGA Architecture) at
http://www.cs.berkeley.edu/~nweaver/nweaver_thesis.pdf

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 61954
Subject: Re: Electronic Dice ( 3 die ) In VHDL
From: Ray Andraka <ray@andraka.com>
Date: Wed, 15 Oct 2003 13:43:55 -0400
Links: << >>  << T >>  << A >>
You could either use 3 copies of a  long LFSR with unique
seeds that are placed sufficiently far apart to produce
uncorrelated sequences *within the observation period*, or
you could use LFSRs with 3 different relatively prime
lengths.  There is a very limited set of polynomials that
will produce an LFSR of a given length, and the resulting
sequence is usually a permutation of the same sequence, so
it does not provide much randomness.

PO Laprise wrote:

> How about using one LFSR per die pip? Using the SRL16s in
> Xilinx chips (don't know A, sorry), that would mean
> somewhere around 9 slices (for 3x6 pips), plus overhead,
> decoding logic, etc..., if I'm not mistaken? Incidentally,
> would using different polynomials effectively (as far as
> the human is concerned) decorrelate the LFSRs? Or would
> varying lengths (16, 32, etc...) do the trick? Or even,
> would different seeds be enough? I've never gotten around
> to studying the math, and never been great with statistics
> anyway...
>
> Pierre-Olivier
>
> -- to contact me directly, remove the obvious from my
> email --

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin
Franklin, 1759



Article: 61955
Subject: Re: Electronic Dice ( 3 die ) In VHDL
From: Ray Andraka <ray@andraka.com>
Date: Wed, 15 Oct 2003 13:49:17 -0400
Links: << >>  << T >>  << A >>
Well, not really an adder.  It is an XOR or XNOR combination of the terms in the
polynomial.  In either case, grabbing adjacent bits will give a random as long
as you let N clocks go by between successive samples (N is the number of bits
taken from  the LFSR).  Note that this is the same as taking one bit at a time
and filling a shift register.  The restriction is that you get one new bit for
each time you clock the LFSR, the remaining bits are shifted copies of the first
bit.  If you take more bits out per sample than you have clocks per sample, you
will get a correlation between successive samples.

Vinh Pham wrote:

> > An LFSR output is only "random" for a single bit out per clock.  The
> > remaining bits are delayed copies of the first bit.  In order to use an
>
> There are two forms of an LFSR.  One where the bits are just delayed
> versions and you have a huge adder that feeds the chain (good ol' Google
> says this is called the Fibonacci form).  And there's another one where
> there are adders inbetween the registers so that the bits are not delayed
> versions of each other (called the Galois form).
>
> Even in the case of the Fibonacci form, I have a feeling that grabbing a few
> adjacent bits will still produce a "random" number.  Of course it depends on
> what you consider random, and I don't know much about the measurements they
> use for that.
>
> > it 3x per die.  If you go further to reject 'illegal' combinations, then
> > you are skewing the probabilities of the legal combinations so that they
> > are  no longer uniform.
>
> Rejecting illegal combinations should be okay.  The legal combinations will
> remain uniform.  Unfortunately I don't know a good way to explain this.  But
> you can take a six sided dice, reject values of 5 and 6, and have it act
> like a uniform four sided dice.
>
> The only problem with the rejection method is you're not guaranteed a valid
> value every clock cycle, which is no big deal in this human operated push
> button application, but for some deterministic applications, you can't
> afford to wait for a "reroll" of the number.
>
> --Vinh

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 61956
Subject: Re: Electronic Dice ( 3 die ) In VHDL
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Wed, 15 Oct 2003 19:02:57 GMT
Links: << >>  << T >>  << A >>
On Tue, 14 Oct 2003 17:56:31 +0100, "Jonathan Bromley"
<jonathan.bromley@doulos.com> wrote:

>"Amstel" <lange360@hotmail.com> wrote in message
>news:56f7756d.0310140824.7d8fe744@posting.google.com...
>> I'm trying to make an electronic dice (3 die). Basically the dice has
>> 3 seven-segment displays and the 3 dice values will run randomly so
>> that we would always get different values combinations. However I
>> tried and was unable to write the program in VHDL .
>
>Do you have any idea how incredibly hard this is?
>
><Mind-boggling detailed discussion snipped>

Superb answer, Jonathan.  I suspect that, even as you read this,
someone is talking to their dean about transferring from electrical
engineering to political science or animal husbandry.

And should you need it, I can give you the name of an excellent
removing-tongue-from-cheek surgeon.

Take care,
Bob Perlman
Cambrian Design Works


Article: 61957
Subject: Re: Electronic Dice ( 3 die ) In VHDL
From: jetmarc@hotmail.com (jetmarc)
Date: 15 Oct 2003 12:09:07 -0700
Links: << >>  << T >>  << A >>
> An LFSR output is only "random" for a single bit out per clock.  The
> remaining bits are delayed copies of the first bit.  In order to use an
> LFSR and really have a random stream of 3 bit numbers you'd need to clock
> it 3x per die.  If you go further to reject 'illegal' combinations, then
> you are skewing the probabilities of the legal combinations so that they
> are  no longer uniform.

I agree that you have to implement the full PRNG and not just use some
bits of the LFSR, to get the full quality of the PRNG.

However, rejecting illegal values is IMHO a "good" thing to do, meaning
that it doesn't bias.  After all, each and every output value of the
PRNG is "unpredictable" (within the quality limits of the PRNG).  Thus,
rejecting all 0x6 and 0x7 doesn't reveal more information than that the
final output won't ever be 0x6 or 0x7.  Still, an attacker can't predict
any output value, given that he couldn't predict them already before we
added the reject circuit.

It's a consequence of the lack of feedback into the PRNG.  The PRNGs
internal state is only changed through the intended means - by going
from state n to n+1 (next value) etc.  All cryptographic study that
the PRNG design has received, inherently also applies to the
combination of PRNG and rejection circuit.

The only disadvantage of this method is that the execution time is not
predictable.  Although highly unprobable, the PRNG could output 0x6 / 0x7
for a lot of cycles in sequence.  Thus you don't know how long it takes
to get an acceptable (legal) output.  In this particular application
(dice) however, I don't think that it will be a problem of significance.

Marc

Article: 61958
Subject: Re: SpartanXL
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 15 Oct 2003 15:35:23 -0400
Links: << >>  << T >>  << A >>
Tim wrote:
> 
> rickman wrote:
> > No, the requirement only dropped from 2.0 Amps to 1.5 Amps at the
> > industrial temp range.  This would require the power converter to be
> > larger than the chip!  This section of the board is our "low power"
> > section and the power converter will supply a *total* of 250 mA at 2.5
> > volts.
> 
> Did you see Austin Lesea's cunning trick of cycling the
> chip until it warms up and starts on lower power?

I am selling boards to OEM customers.  Do you really think it will look
good to recommend that they continue to cycle the FPGA until it warms
up?  That could easily take seconds when the board should be ready to
come up in milliseconds.  If the user is running on battery and needs to
process for a few ms, this will drain the battery very quickly.  

Xilinx has a pattern of building problems into their chips which they
claim is the inevitable price of progress and expecting the users to
deal with them.  In this case it turned out that it was not inevitable
since they fixed the problem with later, more advanced families.  

Another issue that is being touted as "inevitable" is the increase in
static Icc to becoming greater than the dynamic current.  But I can
assure you that this will be licked.  Advances in transistor design are
being made that will allow 65 nm chips to maintain an acceptable level
of static Icc.  If you don't believe me ask Intel about double and
triple gates.   

Thanks for the warm up idea, but it is not workable in this situation.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 61959
Subject: Re: Powersupply virtex 2 and spartan 3
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 15 Oct 2003 15:42:25 -0400
Links: << >>  << T >>  << A >>
I am not sure what your current requirements are since they greatly
depend on the design you put in the FPGA.  You also don't say if you
want a linear or a switching regulator.  But I can recommend the TI
Swift line of switchers if that suits your needs.  They have 3 Amp parts
and 6 Amp parts.  We are designing a module that uses the 3 Amp part and
will provide up to 3 Amps in a 0.3 sq in foot print.  The module may not
be able to supply 3 Amps continuously due to heat issues.  With such a
small module we don't have the copper the data sheet recommends for
cooling.  We will be testing this next month to see what the limits are
over 0C to 70C and -40C to 85C.  

If you are interested in a module this small I can keep you informed on
our results.  


Bram van de Kerkhof wrote:
> 
> Hi,
> 
> Im looking for a regulator for the 1.5 and 1.2 Volt.
> 
> I have a insight board as reference which has 2 times a 1.5 amps regulators
> for the 1.5 V.
> 
> I would like to have one regulator on my own design.
> 
> I'm going to use the following components: xc2v1000 and xc3s400 later.
> 
> Yours Bram

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 61960
Subject: Re: Partial Reconfiguration
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 15 Oct 2003 15:54:25 -0400
Links: << >>  << T >>  << A >>
Steve Lass wrote:
> 
> ram wrote:
> 
> >Hi all,
> > I am interested in doing partial reconfiguration using Xilinx Virtex
> >2 pro, i am having a HW AFX xilinx prototype baord.
> >I tried the small bit manipulation method defined in Xilinx
> >application note
> >xapp290, with the simple example , Example 1 simple system desing from
> >xilinx EDK examples web page.
> >Ok , my desing is this,
> >  I am using PPC405, and uartlite and gpio with uart continiously
> >writing some data in Hyper terminal and gpio is connected to four leds
> >and writing '1' to it
> >I tried to change the routing for the LEDs , I do have to mention
> >here, my board has 8 user LEDS, i changed the routing from upper half
> >to lower half and generated the partial bit stream.
> >
> The configuration frames are columns, so if the routing you are changing
> is in the same column
> as the PPC, UART, or any of their routing, they will probably stop.

I am looking at using this feature, although not while the chip is
running.  One problem I foresee is that with a column alignment, a
module might be very hard to route if it is restricted to just a small
number of columns.  

In my application there are 5 modules with one being constant and four
being changed according to the hardware that is connected.  Some of the
planned modules are much larger than others, so I don't see them mapping
to a fixed footprint.  Some may be as narrow as two or even one column
in an XC3S400.  

So I have been thinking about partitioning the designs differently. 
Instead of mapping modules to columns, I would divide the columns in
half and map the designs to half columns.  This won't be an issue as
long as none of the logic (or interconnect) in the column is being used
by running circuitry.  But it will require that the bit files be
assembled from partial bit files.  Each column will need to be made of
two halves glued together.  As long as there is no routing between them,
this should be a simple matter of concatenating two separate streams for
each column.  

Anyone know if this might be practical?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 61961
Subject: Re: Ph.inisheD.
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 15 Oct 2003 16:08:28 -0400
Links: << >>  << T >>  << A >>
"Nicholas C. Weaver" wrote:
> 
> Well, I FINALLY finished my PhD.
> 
> For those who are exceedingly bored, my dissrtation is online (The
> SFRA: A Fixed-Frequency FPGA Architecture) at
> http://www.cs.berkeley.edu/~nweaver/nweaver_thesis.pdf

Congrats...  I am sure it was a lot of work.  :)

Since you are in that lofty group and must have a much better view than
the rest of us, are you aware of much research in FPGAs about
partial/modular configuration?  

Just curious.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 61962
Subject: Re: SpartanXL
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 15 Oct 2003 13:15:27 -0700
Links: << >>  << T >>  << A >>
Rick,

Hey, we admit the high POS current in Virtex, Virtex E, Spartan II, and
Sparatan IIE, and we are proud that we got rid of it in subsequent families.
It is not "inevitable."

If you want to have a 200 MHz Fmax part instead of a 500 MHz Fmax part, we can
make the leakage much, much lower.  No one seems to want a slower part, even
though it may costs a whole lot less.

As for transistor design techniques that reduce leakage, no one has found one
that works yet.

Hi_K gate oxide does not reduce d-s leakage, SOI does not reduce d-s leakage,
so about the only thing to do is to raise the Vt (relative to the Vcc), which
makes things slower.  Anyone can do that.

Austin

rickman wrote:

> Tim wrote:
> >
> > rickman wrote:
> > > No, the requirement only dropped from 2.0 Amps to 1.5 Amps at the
> > > industrial temp range.  This would require the power converter to be
> > > larger than the chip!  This section of the board is our "low power"
> > > section and the power converter will supply a *total* of 250 mA at 2.5
> > > volts.
> >
> > Did you see Austin Lesea's cunning trick of cycling the
> > chip until it warms up and starts on lower power?
>
> I am selling boards to OEM customers.  Do you really think it will look
> good to recommend that they continue to cycle the FPGA until it warms
> up?  That could easily take seconds when the board should be ready to
> come up in milliseconds.  If the user is running on battery and needs to
> process for a few ms, this will drain the battery very quickly.
>
> Xilinx has a pattern of building problems into their chips which they
> claim is the inevitable price of progress and expecting the users to
> deal with them.  In this case it turned out that it was not inevitable
> since they fixed the problem with later, more advanced families.
>
> Another issue that is being touted as "inevitable" is the increase in
> static Icc to becoming greater than the dynamic current.  But I can
> assure you that this will be licked.  Advances in transistor design are
> being made that will allow 65 nm chips to maintain an acceptable level
> of static Icc.  If you don't believe me ask Intel about double and
> triple gates.
>
> Thanks for the warm up idea, but it is not workable in this situation.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 61963
Subject: Re: USB Core (Japanese Version) Revisited ;o(
From: "SneakerNet" <nospam@nospam.org>
Date: Thu, 16 Oct 2003 09:20:48 +1300
Links: << >>  << T >>  << A >>
"Antti Lukats" <antti@case2000.com> wrote in message
news:80a3aea5.0310150300.79f98bbd@posting.google.com...
> "SneakerNet" <nospam@nospam.org> wrote in message
news:<Qf%ib.178724$JA5.4476502@news.xtra.co.nz>...
> > Hi All
> >
> > Has anyone got this going fully (using the VB code from the site)? I'm
still
> > stuck *wawawa*
> > Pls reply to this post..
>
> how far did you get?
> is the USB device enumerated?
>
> I only did verify that the synthesis is ok 'out of box' so I assume the
> the VB project should also be OK, but I had no reasons to check the
> project in more detail.
>
> antti

Hi Antti

1. Japanese Version USB
* VHDL code => I agree with you on this. I adapted the code from his site
for Altera Cyclone chip and did the pin assignments, assigned some of the
outputs to leds (where would we be without LEDs) and uploaded the program.
The code was doing something. This was futher verified when I plugged the
usb cable in the pc and the light pattern changed for about a sec. it was
like pc was trying to communicate and tell pc what driver to use, but
because no drivers are loaded, the original led sequence resumed (meaning
still waiting for a valid connection).
* VB Code => First I thought that this would be a straight process, however
when running the vb program it doesn't seem to be doing anything as the vb
program keeps reporting that no device found. So what i did was i went back
to the site and asked one of our team members to translate the whole
japanese stuff (http://member.nifty.ne.jp/fpga/freeip/usb/) into english.
When this was done, i read the stuff atleast 10 times. one of the paras
after traslation is as follows (PS: If you want a copy of full translation,
just reply back to this post. I'll post it - it's a professional translation
as we have a translations manager in our company):
"In order to test its operation, I simply changed to a Morphy Planning
USB-I0 on the hardware. I have not completed the application software yet.
It is a VB extra, but the functionality is inadequate. When I have more
time, I will work more on this."

This got me thinking.. So I did a search on Morphy Planning USB-IO and i
came across this site (http://csx.jp/~fex/usbio/index-en.html and
http://www.morphyplanning.co.jp/). I went back to the original page of the
usb (http://member.nifty.ne.jp/fpga/freeip/usb/) and if you look carefully
at the pic on that site you will notice that the person is using a micro
(right hand side half way thr the board). So it looks like the person has
used some extra hardware to connect the pc to fpga. This is verified by the
fact that if you go to this site (http://csx.jp/~fex/usbio/spec-en.html) and
if you open the vb program, you will see ditto commands being used, so dat's
verfied.

So the bottom line is that extra hardware is still required to write to usb
and the fact i can't seem to find out what chip is being used on micr
planning usb-io site as i can't find any schematic, etc.. So i'm stuck.

2. Opencores v1.1 usb_phy and PDIUSBP11A transcever chip.
As i'm stuck with the japanese version, I started building the circuit for
this version. So lets see how this goes. I'm sure this will work though once
again how do I acess the usb through windows. I'll need help again.

I hope I have been able to explain what I have investigated. So what do you
say Antti?
Pls Advice

Regards ;o)





Article: 61964
Subject: Coredump on partial reconfig...
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 15 Oct 2003 20:46:52 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3F8DA93C.C2C16FF3@yahoo.com>,
rickman  <spamgoeshere4@yahoo.com> wrote:

>Since you are in that lofty group and must have a much better view than
>the rest of us, are you aware of much research in FPGAs about
>partial/modular configuration?  

Quick coredump from memory.


There was a lot of stuff on the old 6200 a few years back, because it
was relatively friendly for it.  Satnam had some stuff, among others.

Also there was the many-years-back time-multiplexed 4K Xilinx research
project, which virtualized circuits with fine-grained multiplexing
(project never went anywhere because of the power consumption of
context switching every cycle).


There's some on programming model to allow virtualization (eg, SCORE
here at berkeley), these target abstract FPGAs, not current silicon.



There's a lot of interest today internally in Xilinx and elsewhere on
the possibility, but not sure HOW much research is going on, and in
many ways limited by both the silicon (can only reconfigure
column-at-a-time, a feature largely for testing not user design) and
the tools (how do you swap out bits?  Represent the swapping?  Etc?).

I think if there is some conceptual breakthrough on how to treat the
silicon, the other stuff will probably fall into place, as the
detailed routing (eg, insuring modules don't interfear etc) could be
faked up with Jbits (do a ripup and reroute, and run things 10% slower
to give a margin for simplicity), and "make this change and now these
things run a lot faster" on the silicon could happen in later
egnerations.

But I think its largely awaiting the conceptual breakthrough.  How do
you treat this blob which is different things at different points in
time?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 61965
Subject: tektronix 308 data analyzer
From: "blisca" <blisca@tiscalinet.it>
Date: Wed, 15 Oct 2003 20:48:02 GMT
Links: << >>  << T >>  << A >>
hello,someone in this group did use it?i have the machine but no probes,is
it possible to diy?thanks



Article: 61966
Subject: Re: Debugging software in an ACEX device with Nios 32 via JTAG
From: kempaj@yahoo.com (Jesse Kempa)
Date: 15 Oct 2003 13:48:56 -0700
Links: << >>  << T >>  << A >>
jsabater@dimat.es (Joe Sabater) wrote in message news:<b80681f7.0310130832.78646141@posting.google.com>...
> Hi,
> 
> I have been debugging a software application running in an Altera APEX
> device with Nios 32 (including OCI-Core) via JTAG with no problem at
> all. Now, I am trying to do the same with an ACEX (EP1K100FC256-2)
> with no success. The problem seems to be when the debugger tries to
> connect to the remote target via JTAG. After issuing a "nios-debug"
> command under SOPC Builder shell I get the following error: "mdi
> error: found 0 devices instead of 1".
> 
> It seems as the "nios-debug" script supplied by Altera doesn't
> recognize ACEX devices, but not quite sure about.
> 
> Any idea? What is more, any of you have ever debugged software via
> JTAG with an ACEX?
> 
> Thank you very much in advance.
> 
> Joe

Hi Joe,

Using an ACEX device is the cause of this issue. The OCI debug core
(via JTAG) relies on some enhanced connectivity to JTAG implemented
with APEX (and subsequent) FPGA families. The same limitation applies
for use of the SignalTap on-chip logic analyzer (in fact, the
SignalTap app note lists which device families can be used). Going
back to the Nios kit, this means that the older device families that
Nios supports (ACEX 1K & FLEX 10KE) will not support the OCI core via
JTAG.

Because of your report I put in a request that we provide a more
explicit warning (or error) message in SOPC Builder if you try to
activate OCI and are targeting FLEX or ACEX (in addition to updating
relevant documentation). As it is now, I noticed that there are a
number of warning messages in Quartus that say that the OCI logic is
being synthesized away because of this device limitation -- so this is
really the only warning of this limitation.

In Nios versions prior to 3.0, we had a different debug solution that
operated over serial port rather than JTAG. While I don't recommend
going backwards in terms of Nios CPU version, if its absolutely
essential that you use the GDB debugger with your ACEX device, you
might consider (temporarily) going back to Nios v2.2 to use the
non-JTAG debugging... this method operates over UART, and therefore
does not require the special JTAG enhancements which came out after
ACEX. If its possible to debug with your APEX device and then move to
a final test of your ACEX-based product with OCI turned off, this
would be the easiest solution.

Jesse Kempa
Altera Corp.
jkempa at altera dot com

Article: 61967
Subject: Re: SpartanXL
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 16 Oct 2003 10:17:05 +1300
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Rick,
> 
> Hey, we admit the high POS current in Virtex, Virtex E, Spartan II, and
> Sparatan IIE, and we are proud that we got rid of it in subsequent families.
> It is not "inevitable."
> 
> If you want to have a 200 MHz Fmax part instead of a 500 MHz Fmax part, we can
> make the leakage much, much lower.  No one seems to want a slower part, even
> though it may costs a whole lot less.

 Wow -  Who have you asked ?

 In the CPLD sector, the 'bragging rights slugfests' are over uA
standby, 
not MHz. ( see lattice web site - I did note they pitch uA only, 
and avoid uA/MHz, so perhaps they come (close) second on that one :)

> 
> As for transistor design techniques that reduce leakage, no one has found one
> that works yet.

A sweeping, and thus rather brave, statement ?

I assume Xilinx is already using mixed threshold design, at least ?

> 
> Hi_K gate oxide does not reduce d-s leakage, SOI does not reduce d-s leakage,
> so about the only thing to do is to raise the Vt (relative to the Vcc), which
> makes things slower.  Anyone can do that.

 Look at the latest Transmeta processor. Extremely MHz focused company,
but
they can get to 2mW I think ?
 Press release mentions something about licensing the IP...

-jg

Article: 61968
Subject: Re: Electronic Dice ( 3 die ) In VHDL
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 16 Oct 2003 10:32:02 +1300
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> 
> Why seven segment LEDs though?  It would be more appropriate to use 7 LEDs arranged 
> like the 'six' and 'one' sides of the die superimposed.

 Correct - and the design also does not have to have Mod 6 counting ->
Decoder;
it is possible to count directly in either 7 segment Font patterns, or
in Ray's Dice-Font pattern.

 I have actually done a design that counts directly in 7 
segment Font patterns (0..9) - the student can explain why that 
might be a good idea. 

-jg

Article: 61969
Subject: Re: Power on problems
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 16 Oct 2003 10:42:03 +1300
Links: << >>  << T >>  << A >>
etrac wrote:
> 
> Hi,
> We have found the problem and this might interest somebody here so I
> explain the reasons of the voltage falling : It was simply because we
> put too many bypassing capacitors around the FPGA ! The virtex II
> datasheet is asking for many capacitors to have good linearity in the
> fpga voltages, but our power supply was not enough strong to support
> the current when we power on the board.
> 
> Etrac.
> > > etrac wrote:
> > >
> > > > We want to power on a Virtex II xc2v3000 FPGA (Xilinx). The core power
> > > > seems to work correctly (VccInt = 1.5V ; I<100mA), but VccAux and VccO
> > > > are asking too much current (> 1.5A) for a long time. This occurs
> > > > approximatively 1 second after the power is on.
> > > > We have a current limitation power supply, so the VccAux/VccO voltage
> > > > fall at nearly 1.5V, that is to say that the FPGA needs very much than
> > > > 1.5A ..

 This does not quite 'gel' - you are saying lowering the Total C alone 
solved the issue ?

 That suggests a dV/dT limit, but times in the order of 1 second ?
It may be a power-sequencing effect, which total C would affect.

-jg

Article: 61970
Subject: Re: Counting ones
From: john.l.smith@titan.com (John)
Date: 15 Oct 2003 14:52:07 -0700
Links: << >>  << T >>  << A >>
My final answer (until someone asks an interesting
variation on the question...)
OP asked about VHDL implementation, John_H and I gave
graphs, so the code below is illustration of how to
build the graphs in VHDL, for both the other John's
tree (simple tree), and mine (modified tree), for 30 bits.
Some observations on synthesis results using XST:

LUT utilization (from map report)...
Simple   - 44 LUTs
Modified - 43 LUTs

This is a trivial difference. Because the code for the simple
tree is, well, simpler, it is preferred. Smart folk should be
able to genericize it so that the tree structure is built
automatically for arbitrary input size, by a synthesis tool
that accepts unconstrained bus inputs and outputs. (Does XST
do this yet?)

Timing (from par report smallest Spartan3)...
Pad to Pad delay...
Simple   - 17+ ns
Modified - 17+ ns
Clock period (with the FFs at the end commented back in,
so as to take the pad delay out of the equation)...
Simple   - 10+ ns ( 6 levels )
Modified - 10+ ns ( 6 levels )

No pin assignment or other attempts to map logic used.

Timing can be pushed around a little by playing with
map/par options, but not necessarily the way you'd expect
(who called it 'pushing the rope'? Great metaphor!)
The keep attribute, trying to force the tool, may
backfire. 

So there it is. I like this one, because it is such a
neat example of how even the simplest of operations
( Counting ones!!?!?! ) may not be so simple. You need
to be aware of what the compiler actually does with a
behavioural model, and how to push it, and how not to
push it.

Regards,
John
p.s. thanks to Dan C., local X-FAE, for helping me
get this thing through XST. Like the OP, I'm not a big
VHDL guy either (just don't like the wordiness/aesthetics
of it), I am liking Handel-C more and more.

p.p.s the code (un-simulated, you get what you pay for):

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity TestAddBits_Top is
   generic (UseFA3 : boolean := FALSE );
   Port (   Clock: in std_logic;
            InBits : in std_logic_vector(29 downto 0);
            SumOut : out std_logic_vector(4 downto 0));
end TestAddBits_Top;

architecture VirtexII of TestAddBits_Top is
subtype TwoBit is std_logic_vector(1 downto 0);
subtype ThreeBit is std_logic_vector(2 downto 0);
subtype FourBit is std_logic_vector(3 downto 0);
type Leaf is array (0 to 8) of TwoBit;
type Level1 is array (0 to 3) of ThreeBit;
type Level2 is array (0 to 1) of FourBit;
type Level1A is array (0 to 5) of TwoBit;
signal LeafSum: Leaf ;
signal L1Sum: Level1;
signal L2Sum: Level2;
signal L1SumA: Level1A;
signal FA3: std_logic_vector(1 downto 0);
signal SumBits:  std_logic_vector(4 downto 0);
signal Bits: std_logic_vector(29 downto 0);
--attribute keep : string;
--attribute keep of LeafSum: signal is "true";
--attribute keep of L1Sum: signal is "true";
--attribute keep of L2Sum: signal is "true";
begin
-- Simple adder tree to count 30 bits. Uses 44 LUTs
T1: if ( UseFA3 = FALSE ) generate
      addleaf: for I in 0 to 7 generate        -- Add 8 leafs
         LeafSum(I) <= ('0' & Bits(3*I)  )
                     + ('0' & Bits(3*I+1))
                     + ('0' & Bits(3*I+2));
      end generate;
      addlevel1: for J in 0 to 3 generate      -- Add Level1
         L1Sum(J) <= ( '0' & LeafSum(2*J)  )
                   + ( '0' & LeafSum(2*J+1))
                   + ("00" & Bits(24+J)    );
      end generate;
      addlevel2:for K in 0 to 1 generate       -- Add Level2
         L2Sum(K) <= ( '0' & L1Sum(2*K)    )
                   + ( '0' & L1Sum(2*K+1)  )
                   + ("000" & Bits(28+K)   );
      end generate;
      SumBits <= ('0' & L2Sum(0))              -- Final Answer
               + ('0' & L2Sum(1));
   end generate;
-- Modified adder tree to count 30 bits. Uses 43 LUTs,
-- 1 less LUT than simple adder tree
T2: if ( UseFA3 = TRUE ) generate              -- Use FA3 = True
   addleafsA: for I in 0 to 8 generate         -- Add 9 leafs
      LeafSum(I) <= ('0' & Bits(3*I)  )
                  + ('0' & Bits(3*I+1))
                  + ('0' & Bits(3*I+2));
   end generate;
   addlevel1A: for J in 0 to 2 generate        -- Add Level1A
      inner: for K in 0 to 1 generate
         L1SumA(2*J+K) <= ( '0' & LeafSum(3*J)(K)   )
                        + ( '0' & LeafSum(3*J+1)(K) )
                        + ( '0' & LeafSum(3*J+2)(K) );
      end generate;
   end generate;
   FA3    <=   ( '0' & L1SumA(0)(1) )          -- Add weight 1 bits
             + ( '0' & L1SumA(2)(1) )
             + ( '0' & L1SumA(4)(1) );
   L2Sum(0) <= ( "00" & Bits(27) )             -- Add Level2
             + ( '0' & L1SumA(1) & L1SumA(0)(0) )
             + ( '0' & L1SumA(3) & L1SumA(2)(0) );
   L2Sum(1) <= ( '0' & L1SumA(5) & L1SumA(4)(0) )
             + ( '0' & FA3       & Bits(28)     );
   SumBits  <= ( '0' & L2Sum(0))            -- Final Answer
             + ( '0' & L2Sum(1))
             + ( "0000" & Bits(29));
   end generate;
process ( Clock ) begin
   if RISING_EDGE( Clock ) then
      Bits <= InBits;
      SumOut <= SumBits;
   end if;
end process;
end VirtexII;
 
"John_H" <johnhandwork@mail.com> wrote in message news:<whGhb.24$jU3.10392@news-west.eli.net>...
> Peter's:  solution for 48 bits:
>   2 BlockRAMs, 16 LUTs
>   BlockRAM  tcko + 2 levels carry chain
> John's solution for 30 bits:
>   Resources:  46 LUTs (giving him 1 LUT per CYAdd bit)
>   Delay:  2 levels LUTs + 3 levels carry chain
> John_H's solution for 31 bits (mine, at end):
>   Resources:  41 LUTs
>   Delay: 3 levels LUTs + 2 levels carry chain
>

Article: 61971
Subject: Re: FPGA/CPLD With Analog Functions?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 16 Oct 2003 11:13:01 +1300
Links: << >>  << T >>  << A >>
rickman wrote:
> 
> Jim Granville wrote:
> >
> > rickman wrote:
> > > There are two devices you might be interested in.  One is an MCU with
> > > programmable digital and analog blocks made by Cypress Semi.  This is
> > > not really an FPGA since they don't make it easy for you to design your
> > > own digital functions.  They used to, but they seem to have gone to a
> > > canned module approach where you have lots of standard functions to
> > > choose from.
> >
> >  Did you see info that documented this ? - all I ever saw was 'marketing
> > arm waving'
> > and I was looking for better detail, on just what was SFR based, and
> > what was programmable logic in the true sense.
> 
> I don't understand.  What are you looking for documentation on; the
> chips being ready or being programmable?  Originally, when they first
> came out, you could program the digital and analog blocks yourself.  But
> I think the rules were very complex and people objected to the limited
> amount of logic and capability for a single block.  

 I looked a few times for any under-the-bonnet stuff, as to just
how programmable these blocks _really_ are. A few muxes does 
not quite rank as programmable, merely configurable, and all uC
have configurable peripherals....

 Did you ever see the complex rules - or the tools themselves ? 

 Comments from someone who has seen this, and is 
FPGA tool/flow literate (like yourself) would be interesting.

> So they went to a
> marketing approach where they predesign function blocks and you pick the
> ones you need.

Makes sense, of course. In doing do they morph more to an IP company,
and
their PSoC morphs to a CSoC... 
 
> BTW, I don't know what SFR means.

Special Function Register == Standard Peripheral access/configure 
scheme in microcontrollers.
-jg

Article: 61972
Subject: Re: SpartanXL
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 15 Oct 2003 15:15:32 -0700
Links: << >>  << T >>  << A >>
Jim,

The easy ways are all taken.  To use more than one oxide or more than one threshold
vt is just using last years technology where you can squeeze it in.  There are no
new physical transistors that have been made that look like anything other than PhD
projects....

I don't speak CPLDs, so uA is something I have no understanding of.....

as for the "Ef-fishy-on" they are using a back well bias technique (already patented
by us and also separately by IBM, among others) that makes things slower where one
can get away with it (under programmable cell controls).

If you use a standard CMOS process, you are only able to bias up the nmos, or the
pmos wells, (not both), so unless you have a triple well process you can't really
push this technique as far as one would like.

Making the FPGA slower where you can get away with it is a far more difficult task
than a uP.  I can just see the software tool error message now:  "unknown constraint
- can not apply 'slow' attribute to this block"

Not brave, but not stupid either,

Austin



Jim Granville wrote:

> Austin Lesea wrote:
> >
> > Rick,
> >
> > Hey, we admit the high POS current in Virtex, Virtex E, Spartan II, and
> > Sparatan IIE, and we are proud that we got rid of it in subsequent families.
> > It is not "inevitable."
> >
> > If you want to have a 200 MHz Fmax part instead of a 500 MHz Fmax part, we can
> > make the leakage much, much lower.  No one seems to want a slower part, even
> > though it may costs a whole lot less.
>
>  Wow -  Who have you asked ?
>
>  In the CPLD sector, the 'bragging rights slugfests' are over uA
> standby,
> not MHz. ( see lattice web site - I did note they pitch uA only,
> and avoid uA/MHz, so perhaps they come (close) second on that one :)
>
> >
> > As for transistor design techniques that reduce leakage, no one has found one
> > that works yet.
>
> A sweeping, and thus rather brave, statement ?
>
> I assume Xilinx is already using mixed threshold design, at least ?
>
> >
> > Hi_K gate oxide does not reduce d-s leakage, SOI does not reduce d-s leakage,
> > so about the only thing to do is to raise the Vt (relative to the Vcc), which
> > makes things slower.  Anyone can do that.
>
>  Look at the latest Transmeta processor. Extremely MHz focused company,
> but
> they can get to 2mW I think ?
>  Press release mentions something about licensing the IP...
>
> -jg


Article: 61973
Subject: Re: To our future engineers, smart and otherwise...
From: jakespambox@yahoo.com (Jake Janovetz)
Date: 15 Oct 2003 15:36:33 -0700
Links: << >>  << T >>  << A >>
I expected to see this entitled: "XAPP 998" or something similar...

Peter Alfke <peter@xilinx.com> wrote in message news:<3F8D76F9.416635DF@xilinx.com>...
> If your homework is too tough,
> and the time just flies away,
> thinking hard is not enough,
> click: comp.arch.fpga.
...

Article: 61974
Subject: Re: FPGA/CPLD With Analog Functions?
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 15 Oct 2003 18:56:18 -0400
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> 
> rickman wrote:
> >
> > Jim Granville wrote:
> > >
> > > rickman wrote:
> > > > There are two devices you might be interested in.  One is an MCU with
> > > > programmable digital and analog blocks made by Cypress Semi.  This is
> > > > not really an FPGA since they don't make it easy for you to design your
> > > > own digital functions.  They used to, but they seem to have gone to a
> > > > canned module approach where you have lots of standard functions to
> > > > choose from.
> > >
> > >  Did you see info that documented this ? - all I ever saw was 'marketing
> > > arm waving'
> > > and I was looking for better detail, on just what was SFR based, and
> > > what was programmable logic in the true sense.
> >
> > I don't understand.  What are you looking for documentation on; the
> > chips being ready or being programmable?  Originally, when they first
> > came out, you could program the digital and analog blocks yourself.  But
> > I think the rules were very complex and people objected to the limited
> > amount of logic and capability for a single block.
> 
>  I looked a few times for any under-the-bonnet stuff, as to just
> how programmable these blocks _really_ are. A few muxes does
> not quite rank as programmable, merely configurable, and all uC
> have configurable peripherals....
> 
>  Did you ever see the complex rules - or the tools themselves ?
> 
>  Comments from someone who has seen this, and is
> FPGA tool/flow literate (like yourself) would be interesting.

I have seen some info on this.  But it seems they have removed this from
the web site and have changed to a prepackaged module design approach. 
They provide a menu of what is available and you pick what you will
download to the programmable blocks.  

They are not just using a "few muxes".  The digital blocks contain
various elements that they configure.  For example, digital blocks can
be a serial shift register that can be used as a (rather crude) UART. 
Combine analog blocks and you can get a SAR ADC.  The list of functions
that can be programmed are listed on their web site.  

Here is a definition of one field in a register that configures a
digital block.  

Bit [2:0]: Function [2:0] The Function [2:0] bits select the block
function which determines the basic hardware configuration
0 0 0 = Timer (chainable)
0 0 1 = Counter (chainable)
0 1 0 = CRC/ PRS (Cyclical Redundancy Checker or Psuedo Random
Sequencer) (chainable)
0 1 1 = Reserved
1 0 0 = Deadband for Pulse Width Modulator
1 0 1 = UART (function only available on DCA type blocs)
1 1 0 = SPI (function only available on DCA type blocs)
1 1 0 = Reserved
1 1 1 = Reserved

Clearly this is not a LUT type FPGA.  But it is a programmable block,
even if it is only programmable by them.  This was taken from a 2000
data sheet I have.  


> > So they went to a
> > marketing approach where they predesign function blocks and you pick the
> > ones you need.
> 
> Makes sense, of course. In doing do they morph more to an IP company,
> and
> their PSoC morphs to a CSoC...

Yes, but I don't think they did it because they wanted to be an "IP"
company.  I think they realized that programming the blocks was not very
simple and would never be supported by the type of tools that FPGAs and
CPLDs are.  The laundry list is just a more practical way of getting
this to work.  If you are a company wanting to buy millions, I am sure
they will design any block you would like to see that can be supported. 
After all, they have already come up the learning curve. 


> > BTW, I don't know what SFR means.
> 
> Special Function Register == Standard Peripheral access/configure
> scheme in microcontrollers.


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX



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