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 159250

Article: 159250
Subject: Re: eliminating a DDS
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Wed, 07 Sep 2016 16:38:28 -0700
Links: << >>  << T >>  << A >>
On Wed, 7 Sep 2016 15:45:26 -0700 (PDT),
lasselangwadtchristensen@gmail.com wrote:

>Den onsdag den 7. september 2016 kl. 23.49.29 UTC+2 skrev John Larkin:
>> On Wed, 7 Sep 2016 12:55:12 -0700 (PDT),
>> lasselangwadtchristensen@gmail.com wrote:
>> 
>> >Den søndag den 4. september 2016 kl. 20.11.40 UTC+2 skrev John Larkin:
>> >> I have a design that will use a DDS synthesizer to generate an
>> >> internal trigger rate for a pulse generator. The chip will be a ZYNQ
>> >> 7020. The required upper frequency limit is maybe 20 MHz. The FPGA
>> >> will have the usual, 48 bit or so, phase accumulator and sine lookup
>> >> stuff clocked at maybe 100 MHz. The FPGA drives a fast DAC which in
>> >> turn drives an LC lowpass filter and a comparator. Standard stuff.
>> >> 
>> >> But could such a clock be generated entirely inside the FPGA?
>> >> 
>> >> Just using the MSB of the DDS phase accumulator works, but it will
>> >> have one full clock, 10 ns p-p, of jitter. That will be ugly at 20
>> >> MHz. I've got to look into some sort of outboard analog filtering to
>> >> clean up that single-bit clock, but I'm not optimistic. DDS is just
>> >> too weird.
>> >> 
>> >> Do you suppose that one of the FPGA PLLs be used to clean up the DDS
>> >> clock, scrub the jitter somehow? That could maybe be used over a
>> >> modest range, octave maybe, followed by some dividers.
>> >> 
>> >> Any other ideas for making a programmable-frequency clock with DDS
>> >> sort of resolution, but without all that outboard analog stuff?
>> >> 
>> >> I've been playing with sorta DDS in LT Spice, using a quantizer to
>> >> approximate the DDS accumulator and DAC, but that's obviously not the
>> >> best tool for this.
>> >> 
>> >
>> >https://www.dropbox.com/s/h4qdwm9dllgiivh/dds_pll.jpg
>> >
>> >ch1, MSB from 100MHz, 32 bit accumulator with some random increment to get ~20MHz
>> >ch2, through a PLL in jitter filtermode 
>> 
>> Looks like classic DDS squirmies. The PLL is not filtering the jitter
>> much. With a clock/Fout ratio of 5:1, 0.4 x Nyquist, a DDS and an LC
>> lowpass filter usually looks pretty good.
>
>maybe it's possible to have the filter and then run it back in to the FPGA and through fpga PLL? though lowest BW for the PLL is 1MHz


Yeah, there is jitter cleanup, but it only lasts about 100 ns. The PLL
is pretty fast.


-- 

John Larkin         Highland Technology, Inc
picosecond timing   precision measurement 

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com


Article: 159251
Subject: Re: eliminating a DDS
From: rickman <gnuarm@gmail.com>
Date: Wed, 7 Sep 2016 22:44:04 -0400
Links: << >>  << T >>  << A >>
On 9/7/2016 6:45 PM, lasselangwadtchristensen@gmail.com wrote:
> Den onsdag den 7. september 2016 kl. 23.49.29 UTC+2 skrev John Larkin:
>> On Wed, 7 Sep 2016 12:55:12 -0700 (PDT),
>> lasselangwadtchristensen@gmail.com wrote:
>>
>>> Den søndag den 4. september 2016 kl. 20.11.40 UTC+2 skrev John Larkin:
>>>> I have a design that will use a DDS synthesizer to generate an
>>>> internal trigger rate for a pulse generator. The chip will be a ZYNQ
>>>> 7020. The required upper frequency limit is maybe 20 MHz. The FPGA
>>>> will have the usual, 48 bit or so, phase accumulator and sine lookup
>>>> stuff clocked at maybe 100 MHz. The FPGA drives a fast DAC which in
>>>> turn drives an LC lowpass filter and a comparator. Standard stuff.
>>>>
>>>> But could such a clock be generated entirely inside the FPGA?
>>>>
>>>> Just using the MSB of the DDS phase accumulator works, but it will
>>>> have one full clock, 10 ns p-p, of jitter. That will be ugly at 20
>>>> MHz. I've got to look into some sort of outboard analog filtering to
>>>> clean up that single-bit clock, but I'm not optimistic. DDS is just
>>>> too weird.
>>>>
>>>> Do you suppose that one of the FPGA PLLs be used to clean up the DDS
>>>> clock, scrub the jitter somehow? That could maybe be used over a
>>>> modest range, octave maybe, followed by some dividers.
>>>>
>>>> Any other ideas for making a programmable-frequency clock with DDS
>>>> sort of resolution, but without all that outboard analog stuff?
>>>>
>>>> I've been playing with sorta DDS in LT Spice, using a quantizer to
>>>> approximate the DDS accumulator and DAC, but that's obviously not the
>>>> best tool for this.
>>>>
>>>
>>> https://www.dropbox.com/s/h4qdwm9dllgiivh/dds_pll.jpg
>>>
>>> ch1, MSB from 100MHz, 32 bit accumulator with some random increment to get ~20MHz
>>> ch2, through a PLL in jitter filtermode
>>
>> Looks like classic DDS squirmies. The PLL is not filtering the jitter
>> much. With a clock/Fout ratio of 5:1, 0.4 x Nyquist, a DDS and an LC
>> lowpass filter usually looks pretty good.
>
> maybe it's possible to have the filter and then run it back in to the FPGA and through fpga PLL? though lowest BW for the PLL is 1MHz
>
> I tried upping the clock to 400MHz and it got quite a lot better, but I've only got a TDS210 scope here so it's hard to tell how much better
>
>
>>
>> A PLL, considered as a tracking bandpass filter, could potentially be
>> a good DDS cleanup.
>
> put the DDS inside the loop ?

I don't see how that can matter.  The DDS will in general create jitter 
of one clock period in regardless of what that clock is.  If the PLL 
doesn't filter jitter in the reference, is it likely to filter jitter in 
the feed back clock?

-- 

Rick C

Article: 159252
Subject: Re: Altera USB Blaster clone driver for STM32F1xx
From: qustchenqiang@gmail.com
Date: Thu, 8 Sep 2016 02:03:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi=EF=BC=8CI'm doing a same thing with a STM32F072 NUCLUE board .Now PC can=
 operate the USB blaster driver when  connected via USB .But it can't be id=
entified  in Quartus ii .
May be you did't send the right pid &vid and descriptors to  PC,so the mach=
ine reboot with a blue screen .
Do you solve the problem  ?

Article: 159253
Subject: Re: Low End FPGAs
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Thu, 8 Sep 2016 02:15:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
Am Freitag, 26. August 2016 02:04:34 UTC+2 schrieb Rob Gaddi:
> So I'm looking at various platforms for general purpose, fairly low-end
> FPGAs, and it looks like the Lattice ECP5, Xilinx Artix-7, and Altera
> Cyclone V E all have options in the sort of
> 
>   * 170ish IO
>   * Enough logic to do PLDy sort of tasks
>   * $20ish in ~100p quantity.

You might also consider Microsemi (former known as Actel) Igloo FPGAs. 

Those have their configuration flash on die and are live at power-up without image loading time, which is typically good for PLD like applications.

regards,

Thomas

Article: 159254
Subject: Re: eliminating a DDS
From: Tim <tim@bugblat.invalid>
Date: Thu, 8 Sep 2016 15:53:36 +0100
Links: << >>  << T >>  << A >>
Several FPGAs contain PLLs. The PLLs in the Lattice XO2/XO3 FPGAs have a 
zillion dynamically programmable (Wishbone bus) parameters, including 
the various dividers and multiplexers, and a spiffy fractional divider 
in the feedback path.



On 04/09/2016 19:11, John Larkin wrote:
>
>
> I have a design that will use a DDS synthesizer to generate an
> internal trigger rate for a pulse generator. The chip will be a ZYNQ
> 7020. The required upper frequency limit is maybe 20 MHz. The FPGA
> will have the usual, 48 bit or so, phase accumulator and sine lookup
> stuff clocked at maybe 100 MHz. The FPGA drives a fast DAC which in
> turn drives an LC lowpass filter and a comparator. Standard stuff.
>
> But could such a clock be generated entirely inside the FPGA?



Article: 159255
Subject: Re: Low End FPGAs
From: Jon Elson <jmelson@wustl.edu>
Date: Thu, 08 Sep 2016 15:25:10 -0500
Links: << >>  << T >>  << A >>
thomas.entner99@gmail.com wrote:

> Am Samstag, 27. August 2016 04:05:02 UTC+2 schrieb Jon Elson:
>> Emilian Miron wrote:
>> 
>> > I've heard that Xilinx charges for the logic
>> > analyzer part which swayed me in Altera's direction.
>> > 
>> No, I don't think that is true.  I'm pretty sure ChipScope is included
>> even
>> in the WebPack, although it probably has size limits or something.  At
>> least for the versions I'm using.
>> 
>> Jon
> 
> This has changed recently, luckily... Unfortunately, the user experience
> of ChipScope is in no way comparable with SignalTap, at least IMHO.
My few experiences with ChipScope have not been great, but it does work to 
figure out what is going wrong.  Best to do the best simulations you can do 
first, then maybe try to come up with likely scenarios for the failure and 
check your FPGA code would handle them properly.  If you can't solve it that 
way, then go to ChipScope and maybe you can trap the condition.  No need to 
ever use it for entirely within the FPGA logic, only when interaction with 
something outside is going astray.

Jon

Article: 159256
Subject: iCE40: I/O toggle rate, hard numbers needed
From: Aleksandar Kuktin <akuktin@gmail.com>
Date: Sat, 10 Sep 2016 12:06:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi all.

Can someone please make my life easier by solving a dilemma? How many 
signal transitions per second can iCE40's I/O handle? HX devices.

The datasheet has a table called "Maximum sysIO Buffer Performance" which 
lists numbers in MHz. Are these numbers full-cycle (two transitions) or 
half-cycle (one transition)?

There is also a table called "iCE40 External Switching Characteristics - 
HX Devices" which has some numbers on what appear to be signal setup and 
hold times, plus skew. Working these numbers out, one gets an estimate 
that does not conform to the other table (it is lower).

So what is it? How many times can I toggle or be toggled?

FWIW, I'm trying to figure out how big a screen I can drive with it. I'm 
hoping for B101AW03-V1 which is a 1024x800 @60Hz, uses a three+one FSD-
Link but needs to be driven at ~383.6 Mts (million signal transitions per 
second). I also want to figure out if I can interface to a DDR2 memory 
interface at 166 MHz, or if I'm stuck with 125 MHz.

Article: 159257
Subject: Re: iCE40: I/O toggle rate, hard numbers needed
From: rickman <gnuarm@gmail.com>
Date: Sun, 11 Sep 2016 04:36:23 -0400
Links: << >>  << T >>  << A >>
On 9/10/2016 8:06 AM, Aleksandar Kuktin wrote:
> Hi all.
>
> Can someone please make my life easier by solving a dilemma? How many
> signal transitions per second can iCE40's I/O handle? HX devices.
>
> The datasheet has a table called "Maximum sysIO Buffer Performance" which
> lists numbers in MHz. Are these numbers full-cycle (two transitions) or
> half-cycle (one transition)?
>
> There is also a table called "iCE40 External Switching Characteristics -
> HX Devices" which has some numbers on what appear to be signal setup and
> hold times, plus skew. Working these numbers out, one gets an estimate
> that does not conform to the other table (it is lower).
>
> So what is it? How many times can I toggle or be toggled?
>
> FWIW, I'm trying to figure out how big a screen I can drive with it. I'm
> hoping for B101AW03-V1 which is a 1024x800 @60Hz, uses a three+one FSD-
> Link but needs to be driven at ~383.6 Mts (million signal transitions per
> second). I also want to figure out if I can interface to a DDR2 memory
> interface at 166 MHz, or if I'm stuck with 125 MHz.

I see what you mean.  I'm not familiar with the video you are 
describing, but DDR2 uses a clock at the same max toggle rate as the 
data.  This is usually done with a pair of FFs in the IOB which can 
multiplex the double rate data into a pair of single rate data streams 
using the same clock rate in either direction.  But then you likely know 
all that.

I found an older version of an app note about LVDS I/O in the iCE40 
parts.  Bottom of page 1 shows a table with input and output frequencies 
of 525 and 480 MHz respectively.  Is that fast enough?  Although they 
don't say the iCE40 will work at those speeds, lol.  The newer rev of 
the document doesn't include this table and makes no mention of the data 
rates possible.

http://www.prevailing-technology.com/publications/TN1253.pdf

-- 

Rick C

Article: 159258
Subject: Re: Ob Screen Display from video coming from OV7670
From: eliintertel@gmail.com
Date: Mon, 12 Sep 2016 23:52:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dear all , no one can help ? I also have same problem

Article: 159259
Subject: Re: Ob Screen Display from video coming from OV7670
From: Emilian Miron <emilian.miron@gmail.com>
Date: Tue, 13 Sep 2016 09:04:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, September 13, 2016 at 2:52:37 AM UTC-4, eliin...@gmail.com wrote:
> Dear all , no one can help ? I also have same problem

You can try playing with "vga.vhd" from the URL you posted.
http://hamsterworks.co.nz/mediawiki/index.php/OV7670_camera

This site could help you learn something related that you could then adapt to VHDL and your situation.
http://www.fpga4fun.com/PongGame.html

I'm just guessing that your question was very broad and that's why nobody answered. Perhaps it was not clear whether you wanted to hire someone to do this or get some learning resources so you can do it yourself.

Article: 159260
Subject: Re: Ob Screen Display from video coming from OV7670
From: Robert Walczyk <robertwalczyk@gmail.com>
Date: Wed, 14 Sep 2016 08:40:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, 13 September 2016 17:05:02 UTC+1, Emilian Miron  wrote:
> On Tuesday, September 13, 2016 at 2:52:37 AM UTC-4, eliin...@gmail.com wrote:
> > Dear all , no one can help ? I also have same problem
> 
> You can try playing with "vga.vhd" from the URL you posted.
> http://hamsterworks.co.nz/mediawiki/index.php/OV7670_camera
> 
> This site could help you learn something related that you could then adapt to VHDL and your situation.
> http://www.fpga4fun.com/PongGame.html
> 
> I'm just guessing that your question was very broad and that's why nobody answered. Perhaps it was not clear whether you wanted to hire someone to do this or get some learning resources so you can do it yourself.

If you would like to understand how it works refer to this book: 
https://www.amazon.co.uk/FPGA-Prototyping-Using-VHDL-Examples/dp/0470185317


Article: 159261
Subject: Lattice JED File Formats and Device Type ID Code
From: rickman <gnuarm@gmail.com>
Date: Wed, 14 Sep 2016 14:39:16 -0400
Links: << >>  << T >>  << A >>
I have a .jed file for a design in an XP device.  These devices have 
gone EOL and I am trying to extend my options.  The .jed file is for a C 
type device, specifically the LFXP3C-3TQFP100.  I need to adapt this 
file to use with the LFXP3E-3TQFP100.

My understanding is that the same die is used for both devices with a 
pad bonded to ground or something to indicate the internal voltage 
regulators should be bypassed in the E version.  It also flips one bit 
in the device ID code to 0x01254043 from 0x01255043 for the C version. 
A Lattice FAE told me this although he didn't seem to want to be 
considered authoritative.

The .jed file does not seem to contain the ID code value anywhere in hex 
or in binary.  It is possible this is split over two lines which would 
be very hard to search for without writing a program to read it in and 
do the search.

I do see where the device name is listed in the "NOTE" section of the 
file.  Otherwise there is no mention of the device this goes into.  As a 
first attempt, I tried changing the part name in the NOTE field but that 
didn't seem to work.  The error reported is

Device#1 LFXP3C: Failed to verify the ID
(Expected: 0x01255043 Read: 0x01254043).

Any idea where the programmer is getting the device ID code it is using 
to compare to the ID code read from the part?  Is it possible it is 
getting this from some other file that is in this directory?  I should 
try copying the JED file to a separate directory.

Any other ideas?

Just so you know, if I absolutely have to, I can recreate the .jed file 
by compiling from sources.  But this will be a new "design" according to 
my customer and it will require the board to go through certification 
again and possibly EMI testing.  If I just program the E version of the 
FPGA I think we can bypass all that.

-- 

Rick C

Article: 159262
Subject: Re: Lattice JED File Formats and Device Type ID Code
From: thomas.entner99@gmail.com
Date: Wed, 14 Sep 2016 13:04:45 -0700 (PDT)
Links: << >>  << T >>  << A >>

> Just so you know, if I absolutely have to, I can recreate the .jed file 
> by compiling from sources.

Just some thoughts from my side (I have not used Lattice for quite some time myself):;

If you have still the same version of the compiler, you should be able to get the same bitfile (for the same device).

Then you can compile it for the new device - hopefully you get again the same bitfile with only the device ID different (and possible some checksum).

Otherwise you can still try to figure out the changes in the header of both files, as this is where I would expect this ID info.

Or as you already suggested, maybe the programmer is using some "programmer config file" and the ID is not in the bit-file at all...

Regards,

Thomas

www.entner-electronics.com - Home of EEBlaster and JPEG-Codec

Article: 159263
Subject: Re: Lattice JED File Formats and Device Type ID Code
From: rickman <gnuarm@gmail.com>
Date: Wed, 14 Sep 2016 16:15:31 -0400
Links: << >>  << T >>  << A >>
On 9/14/2016 4:04 PM, thomas.entner99@gmail.com wrote:
>
>> Just so you know, if I absolutely have to, I can recreate the .jed
>> file by compiling from sources.
>
> Just some thoughts from my side (I have not used Lattice for quite
> some time myself):;
>
> If you have still the same version of the compiler, you should be
> able to get the same bitfile (for the same device).
>
> Then you can compile it for the new device - hopefully you get again
> the same bitfile with only the device ID different (and possible some
> checksum).
>
> Otherwise you can still try to figure out the changes in the header
> of both files, as this is where I would expect this ID info.
>
> Or as you already suggested, maybe the programmer is using some
> "programmer config file" and the ID is not in the bit-file at all...

Yes, if I had the tools from 8 years ago on a running machine I would 
try that.  But I don't.

I've looked at the .JED file header.  That's where I found the device 
name.  But changing that does not affect the programmer.

Lattice has a Programming File Utility which lets you compare two .JED 
files.  When I compare the original file to one with the part number 
changed in the Note field, it reports the two as identical and does not 
list anything in the Notes section.  So I assume that is ignored.  The 
device specification must be in the .XCF file which I believe can be 
changed.  The test fixture is 150 miles away so I have to wait for the 
factory to try the things I come up with.

-- 

Rick C

Article: 159264
Subject: Re: Lattice JED File Formats and Device Type ID Code
From: rickman <gnuarm@gmail.com>
Date: Wed, 14 Sep 2016 17:02:10 -0400
Links: << >>  << T >>  << A >>
On 9/14/2016 4:15 PM, rickman wrote:
> On 9/14/2016 4:04 PM, thomas.entner99@gmail.com wrote:
>>
>>> Just so you know, if I absolutely have to, I can recreate the .jed
>>> file by compiling from sources.
>>
>> Just some thoughts from my side (I have not used Lattice for quite
>> some time myself):;
>>
>> If you have still the same version of the compiler, you should be
>> able to get the same bitfile (for the same device).
>>
>> Then you can compile it for the new device - hopefully you get again
>> the same bitfile with only the device ID different (and possible some
>> checksum).
>>
>> Otherwise you can still try to figure out the changes in the header
>> of both files, as this is where I would expect this ID info.
>>
>> Or as you already suggested, maybe the programmer is using some
>> "programmer config file" and the ID is not in the bit-file at all...
>
> Yes, if I had the tools from 8 years ago on a running machine I would
> try that.  But I don't.
>
> I've looked at the .JED file header.  That's where I found the device
> name.  But changing that does not affect the programmer.
>
> Lattice has a Programming File Utility which lets you compare two .JED
> files.  When I compare the original file to one with the part number
> changed in the Note field, it reports the two as identical and does not
> list anything in the Notes section.  So I assume that is ignored.  The
> device specification must be in the .XCF file which I believe can be
> changed.  The test fixture is 150 miles away so I have to wait for the
> factory to try the things I come up with.

That was it.  The JED file was fine, the tech was using the same .XCF 
file which specifies the part number to the programming tool.  Once that 
was changed it worked like a champ!

-- 

Rick C

Article: 159265
Subject: requirement for PC for VHDL design
From: kristoff <kristoff@skypro.be>
Date: Sun, 18 Sep 2016 16:17:32 +0200
Links: << >>  << T >>  << A >>
Hi all,


I am thinking to buy a new PC (laptop, ubuntu).


One of the things I want to do more in the future is FPGA design. I 
currently do very simple projects and I notice that with the 4 GB of RAM 
I have in the laptop I currently use, that is already an issue.

And I want to try out soft-cores in the future.


What would one see as requirements for a PC for FPGA design for a hobbyist?
I guess memory is the main issue. Or not?



Kristoff



Article: 159266
Subject: Re: requirement for PC for VHDL design
From: Cecil Bayona <cbayona@cbayona.com>
Date: Sun, 18 Sep 2016 11:05:04 -0500
Links: << >>  << T >>  << A >>
On 9/18/2016 9:17 AM, kristoff wrote:
> Hi all,
>
>
> I am thinking to buy a new PC (laptop, ubuntu).
>
>
> One of the things I want to do more in the future is FPGA design. I
> currently do very simple projects and I notice that with the 4 GB of RAM
> I have in the laptop I currently use, that is already an issue.
>
> And I want to try out soft-cores in the future.
>
>
> What would one see as requirements for a PC for FPGA design for a hobbyist?
> I guess memory is the main issue. Or not?
>
>
>
> Kristoff
>
>
You can get some very powerful machines for not too much money. I would 
get a decent I7 machine with lots of memory, that way it will be useful 
for a long time. If you are low on money, there are some choices 
available for a lot less, but get the fastest high memory machine you 
can afford and you won't suffer from regret.

Although a lesser machine might do, in the long run one ends regretting 
the choice. As an example I was recently working on the ep32 CPU a zero 
address CPU and found  that with Windows 10 64 bit some of the older 
software used to generate programs for it would not work right, what 
ended working right was when I used VMware virtual CPU running Windows 7 
32 bits then everything worked flawlessly. Had my machine been not 
capable of running VMware well the issues would not have been resolved.

My FPGA machine uses an I7 at 3.4GHz, 24GB of RAM, and a 512GB SSD drive 
for the OS and virtual partitions, it can handle anything I throw at it.

-- 
Cecil - k5nwa

Article: 159267
Subject: Re: requirement for PC for VHDL design
From: David Brown <david.brown@hesbynett.no>
Date: Sun, 18 Sep 2016 19:24:10 +0200
Links: << >>  << T >>  << A >>
On 18/09/16 18:05, Cecil Bayona wrote:
> On 9/18/2016 9:17 AM, kristoff wrote:
>> Hi all,
>>
>>
>> I am thinking to buy a new PC (laptop, ubuntu).
>>
>>
>> One of the things I want to do more in the future is FPGA design. I
>> currently do very simple projects and I notice that with the 4 GB of RAM
>> I have in the laptop I currently use, that is already an issue.
>>

If you can get a stationary machine, do so - it will be much more 
cost-effective when you need a powerful system.

Modern FPGA tools should be quite good at using multiple cores.  And 
they are /very/ good at using memory - get as much as you can afford. 
Portables are often very limited in their memory - these days I see a 
lot of laptops that come with 4, 6 or 8 GB and don't let you upgrade at 
all.  And laptops all have tiny little screens - even the biggest ones 
are tiny.  A nice big monitor at 2560x1440 is pretty cheap these days, 
and a lot better to work with than a laptop screen.

>> And I want to try out soft-cores in the future.
>>
>>
>> What would one see as requirements for a PC for FPGA design for a
>> hobbyist?
>> I guess memory is the main issue. Or not?
>>
>>
>>
>> Kristoff
>>
>>
> You can get some very powerful machines for not too much money. I would
> get a decent I7 machine with lots of memory, that way it will be useful
> for a long time. If you are low on money, there are some choices
> available for a lot less, but get the fastest high memory machine you
> can afford and you won't suffer from regret.
>
> Although a lesser machine might do, in the long run one ends regretting
> the choice. As an example I was recently working on the ep32 CPU a zero
> address CPU and found  that with Windows 10 64 bit some of the older
> software used to generate programs for it would not work right, what
> ended working right was when I used VMware virtual CPU running Windows 7
> 32 bits then everything worked flawlessly. Had my machine been not
> capable of running VMware well the issues would not have been resolved.

He is running Ubuntu, so will have different issues (some things will be 
easier, some things harder).  But having plenty of memory for running 
virtual machines is definitely a good idea (though I'd recommend 
VirtualBox over VMware).

>
> My FPGA machine uses an I7 at 3.4GHz, 24GB of RAM, and a 512GB SSD drive
> for the OS and virtual partitions, it can handle anything I throw at it.
>

Don't bother with the SSD unless you have more money left over, or need 
to boot the machine regularly.  He is running Linux - with enough memory 
(in comparison to file sizes), disk speed is of little relevance as the 
OS uses memory for cache.  If you are getting an SSD, though, make sure 
it is at least 200 GB - below that size, most of them are quite poor.



Article: 159268
Subject: Re: requirement for PC for VHDL design
From: Cecil Bayona <cbayona@cbayona.com>
Date: Sun, 18 Sep 2016 13:44:54 -0500
Links: << >>  << T >>  << A >>
On 9/18/2016 12:24 PM, David Brown wrote:
> On 18/09/16 18:05, Cecil Bayona wrote:
>> On 9/18/2016 9:17 AM, kristoff wrote:
>>> Hi all,
>>>
>>>
>>> I am thinking to buy a new PC (laptop, ubuntu).
>>>
>>>
>>> One of the things I want to do more in the future is FPGA design. I
>>> currently do very simple projects and I notice that with the 4 GB of RAM
>>> I have in the laptop I currently use, that is already an issue.
>>>
>
> If you can get a stationary machine, do so - it will be much more
> cost-effective when you need a powerful system.
>
> Modern FPGA tools should be quite good at using multiple cores.  And
> they are /very/ good at using memory - get as much as you can afford.
> Portables are often very limited in their memory - these days I see a
> lot of laptops that come with 4, 6 or 8 GB and don't let you upgrade at
> all.  And laptops all have tiny little screens - even the biggest ones
> are tiny.  A nice big monitor at 2560x1440 is pretty cheap these days,
> and a lot better to work with than a laptop screen.
>
>>> And I want to try out soft-cores in the future.
>>>
>>>
>>> What would one see as requirements for a PC for FPGA design for a
>>> hobbyist?
>>> I guess memory is the main issue. Or not?
>>>
>>>
>>>
>>> Kristoff
>>>
>>>
>> You can get some very powerful machines for not too much money. I would
>> get a decent I7 machine with lots of memory, that way it will be useful
>> for a long time. If you are low on money, there are some choices
>> available for a lot less, but get the fastest high memory machine you
>> can afford and you won't suffer from regret.
>>
>> Although a lesser machine might do, in the long run one ends regretting
>> the choice. As an example I was recently working on the ep32 CPU a zero
>> address CPU and found  that with Windows 10 64 bit some of the older
>> software used to generate programs for it would not work right, what
>> ended working right was when I used VMware virtual CPU running Windows 7
>> 32 bits then everything worked flawlessly. Had my machine been not
>> capable of running VMware well the issues would not have been resolved.
>
> He is running Ubuntu, so will have different issues (some things will be
> easier, some things harder).  But having plenty of memory for running
> virtual machines is definitely a good idea (though I'd recommend
> VirtualBox over VMware).

That is the beauty of having options, I used to use VirtualBox myself 
but after a bout where VirtualBox removed the licenses to Windows 10 out 
of the blue I switched to VMware.

I installed Windows 7 and used up a license, then upgraded it to Windows 
10 and all was fine for a while, then on one of the upgrades to 
VirtualBox it removed the licenses to Windows 10 and several Partitions 
that had Windows Server that I used for school also lost their licenses, 
that was it, and away it went.

>
>>
>> My FPGA machine uses an I7 at 3.4GHz, 24GB of RAM, and a 512GB SSD drive
>> for the OS and virtual partitions, it can handle anything I throw at it.
>>
>
> Don't bother with the SSD unless you have more money left over, or need
> to boot the machine regularly.  He is running Linux - with enough memory
> (in comparison to file sizes), disk speed is of little relevance as the
> OS uses memory for cache.  If you are getting an SSD, though, make sure
> it is at least 200 GB - below that size, most of them are quite poor.
>
>
SSD makes a huge improvement in OS booting, application startup, and 
Virtual Partition speed, they are cheap now you can get a 256GB  SSD for 
$50 when on sale.

Myself I'm pondering about switching to Linux myself, I have 2 PCs 
running Mint Linux and I have not had any problems with them in years, 
the same cannot be said of Windows.

-- 
Cecil - k5nwa

Article: 159269
Subject: Re: requirement for PC for VHDL design
From: David Brown <david.brown@hesbynett.no>
Date: Sun, 18 Sep 2016 21:30:03 +0200
Links: << >>  << T >>  << A >>
On 18/09/16 20:44, Cecil Bayona wrote:
> On 9/18/2016 12:24 PM, David Brown wrote:
>> On 18/09/16 18:05, Cecil Bayona wrote:
>>> On 9/18/2016 9:17 AM, kristoff wrote:
>>>> Hi all,
>>>>
>>>>
>>>> I am thinking to buy a new PC (laptop, ubuntu).
>>>>
>>>>
>>>> One of the things I want to do more in the future is FPGA design. I
>>>> currently do very simple projects and I notice that with the 4 GB of
>>>> RAM
>>>> I have in the laptop I currently use, that is already an issue.
>>>>
>>
>> If you can get a stationary machine, do so - it will be much more
>> cost-effective when you need a powerful system.
>>
>> Modern FPGA tools should be quite good at using multiple cores.  And
>> they are /very/ good at using memory - get as much as you can afford.
>> Portables are often very limited in their memory - these days I see a
>> lot of laptops that come with 4, 6 or 8 GB and don't let you upgrade at
>> all.  And laptops all have tiny little screens - even the biggest ones
>> are tiny.  A nice big monitor at 2560x1440 is pretty cheap these days,
>> and a lot better to work with than a laptop screen.
>>
>>>> And I want to try out soft-cores in the future.
>>>>
>>>>
>>>> What would one see as requirements for a PC for FPGA design for a
>>>> hobbyist?
>>>> I guess memory is the main issue. Or not?
>>>>
>>>>
>>>>
>>>> Kristoff
>>>>
>>>>
>>> You can get some very powerful machines for not too much money. I would
>>> get a decent I7 machine with lots of memory, that way it will be useful
>>> for a long time. If you are low on money, there are some choices
>>> available for a lot less, but get the fastest high memory machine you
>>> can afford and you won't suffer from regret.
>>>
>>> Although a lesser machine might do, in the long run one ends regretting
>>> the choice. As an example I was recently working on the ep32 CPU a zero
>>> address CPU and found  that with Windows 10 64 bit some of the older
>>> software used to generate programs for it would not work right, what
>>> ended working right was when I used VMware virtual CPU running Windows 7
>>> 32 bits then everything worked flawlessly. Had my machine been not
>>> capable of running VMware well the issues would not have been resolved.
>>
>> He is running Ubuntu, so will have different issues (some things will be
>> easier, some things harder).  But having plenty of memory for running
>> virtual machines is definitely a good idea (though I'd recommend
>> VirtualBox over VMware).
>
> That is the beauty of having options, I used to use VirtualBox myself
> but after a bout where VirtualBox removed the licenses to Windows 10 out
> of the blue I switched to VMware.
>
> I installed Windows 7 and used up a license, then upgraded it to Windows
> 10 and all was fine for a while, then on one of the upgrades to
> VirtualBox it removed the licenses to Windows 10 and several Partitions
> that had Windows Server that I used for school also lost their licenses,
> that was it, and away it went.
>

I have little experience with Windows 10, and none of it using virtual 
machines - so I can't help you here.

But you are right about the beauty of choice.

>>
>>>
>>> My FPGA machine uses an I7 at 3.4GHz, 24GB of RAM, and a 512GB SSD drive
>>> for the OS and virtual partitions, it can handle anything I throw at it.
>>>
>>
>> Don't bother with the SSD unless you have more money left over, or need
>> to boot the machine regularly.  He is running Linux - with enough memory
>> (in comparison to file sizes), disk speed is of little relevance as the
>> OS uses memory for cache.  If you are getting an SSD, though, make sure
>> it is at least 200 GB - below that size, most of them are quite poor.
>>
>>
> SSD makes a huge improvement in OS booting, application startup, and
> Virtual Partition speed, they are cheap now you can get a 256GB  SSD for
> $50 when on sale.

It makes a difference to booting - but I boot my machines perhaps once 
every two months, and if it takes 2 minutes instead of 1 minute, I don't 
mind.  And on Linux, which is hugely more efficient than Windows in the 
way it caches files, it might make a slight difference to the first time 
you start an application - but not after that.

If you have a very large working set (i.e., a lot of big files that you 
are reading and writing at once), so that the data can't be cached in 
your ram, then an SSD will often be faster.  But even then, a couple of 
decent HD's in raid (Linux supports top-class software raid) will often 
give you similar speed.

Of course, an SSD is never a /bad/ thing - but if you have a choice of 
an SSD or more ram, then more ram is usually the best use of your money.

It is different on a laptop, where the low power and robustness of the 
SSD helps, and where you do want to reboot regularly and move ram data 
onto disk for hibernation.

And on Windows, where the OS loads entire application exe's and dll's 
rather than just the bits you need, and keeps re-loading the files it 
has just read, then an SSD can make a significant difference.  (To be 
fair on Windows, Win 10 is better than previous generations at using 
memory for cache.)

>
> Myself I'm pondering about switching to Linux myself, I have 2 PCs
> running Mint Linux and I have not had any problems with them in years,
> the same cannot be said of Windows.
>


Article: 159270
Subject: HW-130 Adapters
From: Tim Regeant <TimRegeant@gmail.com>
Date: Mon, 19 Sep 2016 00:49:57 -0400
Links: << >>  << T >>  << A >>
Bump.  Still looking for these adapters.  Please contact me if you have 
any.  Thanks.


On 8/31/2016 12:10 AM, Tim Regeant wrote:
 > My project needs to program a Xilinx XC7336 44PLCC.
 >
 > I have the software now and the HW-130 programming unit.
 >
 > Also have the HW-137-PC44/VQ44 adapter which I assumed would work with
 > the XC7336, but as it turns out it does not.
 >
 > So I need to find the adapter(s) below.  If anyone can help out please
 > let me know.
 >
 > HW-133-PC44
 > HW-133-PC68
 > HW-133-PC84
 >
 > For reference here is webpage showing the HW-133-PC68 adapter (middle
 > image):  http://www.digital-circuitry.com/MyLAB_IC_PROG_HW-130.htm
 >
 > Also at this Xilinx support page
 > http://www.xilinx.com/support/answers/961.html it mentions the HW-120
 > adapters are mostly compatible with the HW-130 programmer.
 >
 > So I could alternatively use these adapters if anyone has them:
 >
 > HW-126-PC44
 > HW-126-PC68
 > HW-126-PC84
 >
 > Thanks for any help you may offer!

Article: 159271
Subject: Re: requirement for PC for VHDL design
From: rickman <gnuarm@gmail.com>
Date: Mon, 19 Sep 2016 01:02:28 -0400
Links: << >>  << T >>  << A >>
On 9/18/2016 10:17 AM, kristoff wrote:
> Hi all,
>
>
> I am thinking to buy a new PC (laptop, ubuntu).
>
>
> One of the things I want to do more in the future is FPGA design. I
> currently do very simple projects and I notice that with the 4 GB of RAM
> I have in the laptop I currently use, that is already an issue.
>
> And I want to try out soft-cores in the future.
>
>
> What would one see as requirements for a PC for FPGA design for a hobbyist?
> I guess memory is the main issue. Or not?

My main concern when it comes to FPGAs is simulation time.  I spend much 
more time simulating than I do creating a bit stream.  Simulators are 
speed crippled unless you pay for a faster version.  So I'm not sure how 
much the speed of your CPU matters.

Memory is always important.  I have 16 GB in my laptop and tend to push 
that limit just by keeping many browser windows and tabs open.  So at a 
minimum get 16 GB and more if you want.

Otherwise I think you will never notice the difference between the 
various processor speeds, at least not as much difference as the price 
would seem to indicate.

Don't sweat it.  Before you spend any money on a new laptop, just get 
familiar with the tools and the process.  Then figure out if you want to 
pay for new hardware.

-- 

Rick C

Article: 159272
Subject: Re: Help me choose an FPGA to design network protocols
From: PM X <pinaki2@gmail.com>
Date: Mon, 19 Sep 2016 00:29:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, September 3, 2016 at 8:37:44 AM UTC-7, Michael Kellett wrote:
> PM X:
> > On Monday, August 29, 2016 at 11:38:27 AM UTC-7, Cecil Bayona wrote:
> >> On 8/29/2016 1:32 PM, rickman wrote:
> >> > On 8/29/2016 4:58 AM, PM X wrote:
> >> >>>
> >> >>> UDP/IP is much simpler the TCP/IP. It is commonly done in FPGAs.
> >> >>>
> >> >>> For example:
> >> >>>
> >> >>> http://www.fpga4fun.com/10BASE-T.html
> >> >>>
> >> >>> OK. It is only 10Base-T. But it's not that different than the
> 10GbE that
> >> >>> we do.
> >> >>>
> >> >>> You can get a crappy NIC and Basys 3 Artix 7 board for less than
> $200.00
> >> >>>
> >> >>>
> http://store.digilentinc.com/pmodnic100-network-interface-controller/
> >> >>>
> >> >>> It won't be low latency (the NIC has an SPI serial interface) but
> it
> >> >>> will teach concepts.
> >> >>>
> >> >>> Rob.
> >> >>
> >> >> Thanks. Is this the board you are referring to?
> >> >>
> http://store.digilentinc.com/basys-3-artix-7-fpga-trainer-board-recommend=
ed-for-introductory-users/
> >> >>
> >> >>
> >> >> If so, this board doesn't seem to have SPI (at least no listed in
> the
> >> >> description). Also, do you think this board has enough capacity
> (in
> >> >> terms of logic elements, etc.) to support a fairly complicated
> design
> >> >> like UDP/IP?
> >> >
> >> > What do you mean it doesn't have SPI?  SPI is a simple shift
> register
> >> > interface which can *easily* be implemented in an FPGA (or MCU)
> using
> >> > the GPIOs.
> >> >
> >> > Do you mean ISP, in system programming?  If it doesn't have ISP how
> do
> >> > you load your design?
> >> >
> >>
> >> It's a FPGA, you can add SPI easily, there are IPs for free to allow
> >> that to happen.
> >>
> >> In my post I was also going to mention the BASYS-3  board, I left it
> out
> >> because the Arty Board has a ton of memory available that this one
> >> doesn't but this on has a lot of switches and LED which can be
> handy.
> >> --
> >> Cecil - k5nwa
> >=20
> > OK, thanks. I will check out both of them. What is the largest design
> you (or someone you know) have implemented on these boards? The Artix
> line seems to be lower end than Virtex line, so trying to get an idea if
> they can support somewhat complicated designs.
>=20
> I haven't used the Arty except on a 1 day Xilinx "get to know Vivado"
> jolly. It's quite anice board. We are looking at alternatives to Lattice
> (no big reason, just due diligence) with a design currently running on a
> Lattice ECP3-35. The FPGA on the Arty could easily do Ethernet trispeed
> MAC, IP, ARP, UDP and some more. (We do this on the Lattice (about 20%
> of it) so I know of what I speak (at least that far)) TCP on the FPGA
> would be bigger (could be much bigger).
>=20
> As an aside - why does HF trading use TCP - (think of this as an
> interview question :-)
>=20
> Our UDP support is good at transmitting, poor at receiving ('coz that's
> what we need) - it does support an in-house protocol for re-transmission
> and message integrity - much simpler than TCP and faster.
>=20
> By the time you've outgrown the Arty you've either done the career shift
> or it isn't going happen.
>=20
> Michael Kellett

Since many people have suggested Arty, I was giving it a serious thought. B=
ut although it does have ethernet (which I need), it does not have any kind=
 of video output like VGA (I would strongly prefer to get a board with some=
 kind of video output as well besides ethernet). I do not want to try and a=
dd VGA to it as I have no experience with that stuff. Another Digilent boar=
d that I really liked is the Nexys 4 DDR, which has both ethernet and VGA. =
But the price is a little over my budget at $320. I am trying to do this wi=
thin $200, although I it can go up a bit (to maybe $300) if I don't find an=
y good option in the "< $200" range.

To re-iterate, I am looking for a board with a Xilinx FPGA (preferably Arti=
x-7) that uses the Vivado software. And as stated above, I want ethernet an=
d video output connectivity support. So now that I have a clearer idea than=
 before, if somebody can suggest a board meeting the above requirements (in=
 the $200 range), that will be great.

So far I had only been looking at boards from Digilent, but I just came acr=
oss another company called Avnet which also sells Xilinx boards. They seem =
to have a lot more choices when I search for a board with Artix-7 (while Di=
gilent has only 3 or 4). I didn't understand very clearly what type of boar=
ds they sell. Do they make them or do they just distribute the boards made =
by Xilinx? Which one would be a better option - Digilent or Avnet? Or somet=
hing else?

Thanks.

Article: 159273
Subject: Re: Help me choose an FPGA to design network protocols
From: lasselangwadtchristensen@gmail.com
Date: Mon, 19 Sep 2016 10:49:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den s=C3=B8ndag den 28. august 2016 kl. 08.09.26 UTC+2 skrev rickman:
>=20
> As you may have figured out, I'm not a big fan of Xilinx.  I keep=20
> hearing about all manner of issues with their in house tool, Vivaldo.=20
> It used to be XST, but the scrapped that.  In fact, my very first FPGA=20
> design was a Xilinx and during a four month project (or maybe six, I=20
> don't recall exactly) I had to ditch tools twice.  The first time was to=
=20
> drop the Orcad VHDL tool as it was largely non-functional, switching to=
=20
> the Xilinx tool.  Then a second time when Xilinx dropped their earlier=20
> tool and only supported a new one.  Later they came out with XST and now=
=20
> Vivaldo.  I don't get that they have to keep tossing tools.  It makes it=
=20
> hard to maintain lifetime support for your product.
>=20
> On the other hand Lattice ditched the chip I have designed on a board I=
=20
> am still making good money from, *very* good money.  Fortunately there=20
> is sufficient inventory that I won't have to redesign the board for a=20
> number of years.  At least they use third party synthesis so it isn't a=
=20
> problem to keep supporting products over their lifetime.
>=20

if you had any current experience you would know that the name is Vivado=20
and that Xilinx have all versions of design tools going back something like=
=20
15 years still available=20


-Lasse

Article: 159274
Subject: Re: requirement for PC for VHDL design
From: already5chosen@yahoo.com
Date: Tue, 20 Sep 2016 02:36:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, September 18, 2016 at 8:24:14 PM UTC+3, David Brown wrote:
>=20
> Modern FPGA tools should be quite good at using multiple cores.  And=20
> they are /very/ good at using memory - get as much as you can afford.=20

Both of the statements above are wrong.

Modern FPGA tools can occupy multiple cores, but it does not translate into=
 significant improvements in synthesis or P&R speed.
Two cores are at best 15% faster than one core. Four cores over two - hardl=
y noticeable at all.
As to memory, each FPGA device requires certain amount of memory for P&R. W=
hen you have that much then getting more does not help. If you have less - =
you better don't start, it would be too slow. The said "certain amount" is =
typically specified in the documentation of your tools.

For example, Altera Quartus 15.1 (devices that are likely to matter for hob=
byist):
Cyclone IV E - 512 MB to 1.5 GB
Cyclone IV GX - 512 MB to 2 GB
Cyclone V - 6-8 GB=20
MAX II/MAX V - 512 MB
MAX 10 - 512 MB - 2 GB

So, >2 cores and >8 GB of RAM matter *only* if one wants to run several com=
pilations simultaneously.

In money-limited situation the choice between=20
a) 8 GB of RAM + HDD
b) 16 GB of RAM + 256 GB SSD
is very obvious - take b)
That assumes that you are also buying external HDD for backups and for rare=
ly used staff, but you'll want it anyway, don't you?





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