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 139475

Article: 139475
Subject: Re: Silicon Blue Warm-Boot not working properly
From: Prevailing over Technology <steve.knapp@prevailing-technology.com>
Date: Tue, 31 Mar 2009 08:07:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 24, 9:32=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:

[... snip ...]

> from your comments it was not so sure, did you actually got it to work
> with real hardware? (with older tools)?

[... snip ...]

Hi Antti,

Unfortunately, I'm travelling at the moment so I don't have access to
all my files.  However, here are the modifications to the
configuration image that I made before it was supported in software.
From testing, there are separate controls to enable ColdBoot and
WarmBoot images.   I think that the current software release enables
both ColdBoot and WarmBoot (i.e., I don't see any way to individually
enable or disable the controls).

Here is an annotated bitstream snippet that shows some of the control
bits.  This is the =93control=94 header loaded at the start of the
configuration image and must be located at address 0.  It contains the
ColdBoot and WarmBoot controls plus the start vector addresses for
each of the four possible configuration images.  WARNING:  These are
old notes so it=92s probably worth re-testing.

7e aa 99 7e  ; Synchronization word
92 00 30     ; "30" enables both ColdBoot and WarmBoot, "20" enables
just ColdBoot, "10" enables just WarmBoot
01 08
00 00 00 00 00 00 00  ; zero fill to align to 32 bytes boundary
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

7e aa 99 7e  ; Synchronization word starts a 32-byte boundary, Image 0
vector address
92 00 00
44 0b 10 00 00 ; "0b" is the SPI fast read command.  The next six hex
digits (10 00 00) are the 24-bit starting byte address
01 08
00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

7e aa 99 7e  ; Image 1 vector address
92 00 00
44 0b 20 00 00
01 08
00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

7e aa 99 7e  ; Image 2 vector address
92 00 00
44 0b 30 00 00
01 08
00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

7e aa 99 7e  ; Image 3 vector address
92 00 00
44 0b 30 00 00  ; NOTE:  Jumps to same address as Image 2 in this
example
01 08
00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

Load the following images at the following starting byte addresses
(the actual addresses are specified in the control header).

0x10000:  Image 0
0x20000:  Image 1
0x30000:  Image 2 (Image 3 vector also points to this location)

I hope this helps.  I can try more when I'm back in the office later
this week.

-- Steve Knapp
   Prevailing Technology, Inc.
   www.prevailing-technology.com

Article: 139476
Subject: Re: initialize BRAM contents
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 31 Mar 2009 08:22:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 31, 4:41=A0pm, hassen.kar...@gmail.com wrote:
> Hi,
>
> 1- Hardware : Generate you bit file whatever how . --->
> system_stub_download.bit
> 2- Software : Compile you application ---> application.elf
> 3- Use Data2me to put software into bitsream.
> Example :
> data2mem -bm "system/implementation/system_bd" -bt
> "system_stub_download.bit" -bd "system\SDK_projects\application\Debug
> \application.elf" tag microblaze_0 =A0-o b system_bram_initialised.bit

you did not read the OP, same as me.

he only concern is COREGEN related memories
not those made with EDK or hand crafted

there are no problems with EDK
there are no problems when memories are used with ISE (no EDK flow) as
long as they are not done with Coregen

as per Xilinx AR, ISE 8.1 was the last version of ISE that supported
coregen generated memories and data2mem

Antti






Article: 139477
Subject: Re: best soft core(s) that have C compiler support
From: Andy Peters <google@latke.net>
Date: Tue, 31 Mar 2009 11:18:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 10:45=A0pm, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> let me explain in more detail:
>
> if I use LatticeMico32 for commercial product targetting Xilinx,
> Altera..
> or
> if I use MicroBlaze(tm) clone on Altera, Lattice
>
> then I suppose it may get unwanted attention, or if not it will get
> absolute nil support from the vendors where soft-core marketed
> by direct competitor is used.

How does anyone know what's inside your FPGA if you don't advertise
it? Who's to know that you've ported Mico32 to Xilinx? Sssssh, don't
tell anyone.

As for support, well, that's always an issue.

> C- Compiler for PicoBlaze, well it can be used for some test to prove
> it generates code, but PicoBlaze is so crippled that the solution is
> not much useable. Just too small code space.

PicoBlaze was meant to be small. If you exceed the 1k code space, then
you might wish to consider a different "processor." For small state-
machine things, PicoBlaze actually works quite well. Maybe one day Ken
Chapman will update his compiler, though. Things like hard-coded name/
path for the template really suck. Yes, I've complained on the Xilinx
forum, but that complaint is ignored. So I use the pBlaze IDE instead.
Works well enough.

-a

Article: 139478
Subject: Re: Fiber optics protocols for mid range speed
From: czam <csaturn@gmail.com>
Date: Tue, 31 Mar 2009 12:34:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 31, 10:29=A0am, Oliver Faust <oliver.fa...@gmail.com> wrote:
> On Mar 30, 9:09=A0pm, czam <csat...@gmail.com> wrote:
>
>
>
> > On Mar 30, 4:27=A0pm, Oliver Faust <oliver.fa...@gmail.com> wrote:
>
> > > Hi,
> > > I want to network multiple embedded processors using optical fiber as
> > > physical layer. This network is realised with point to point
> > > connections. At the moment, the network is established using RS232. T=
o
> > > get higher data rates (around 100Mb/s) and better protection against
> > > EMI the electrical RS232 should be exchanged with optical data
> > > transfer.
> > > In order to realise this change, I'm searching for a technology
> > > similar to Fiber Channel (FC). The only, difficulty with FC is that
> > > the speed is too high, the slowest speed for fiber channel is 1Gb/s.
> > > Furthermore, fiber channels use sophisticated IO (Xilinx rocket IO) ,
> > > for cost effectiveness I don't want to invest in these expensive IOs.
> > > I looked around on the net for some possible solutions, but fiber
> > > channel was the closest solution to my problem I could find. My
> > > question is therefore:
> > > Did I overlook something? Is there an IP-core or external chip which
> > > allows me to establish a 100Mb/s data communication link between two
> > > embedded processors using fiber optic.
>
> > > Thank you in advance for your help.
> > > Oliver Faust
>
> > You can check the TLK family of transceivers from Texas Instruments;
> > they exist in different speeds. Apart from a couple of these you will
> > need a photodiode and a laser (of course).
>
> > The chip uses 8b/10b to encode the data, but it is all transparent for
> > the user.
>
> > hope it helps,
> > Christos
>
> Dear Christos,
> Thank you for the suggestion. However, a brief glance over the TLK
> family of transceivers from Texas Instruments showed me that these are
> converters Gbit Ethernet to Fiber Channel. Unless I missed something,
> this is too fast for my application.
>
> Oliver Faust

Check the TLK1501. To interface it in an FPGA is really trivial. 1
clock signal, 16 I/Os (for your data) and 2 control pins.

Some questions for you to consider:
What is the distance you'll need to cover?
What is the number of links you'll need to establish?
Is reliability a major issue (i.e. protection system)?

Regards,
Christos

Article: 139479
Subject: XST removes duplicate logic no matter what
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 31 Mar 2009 17:10:22 -0400
Links: << >>  << T >>  << A >>
I've been fighting XST not to remove duplicate logic I put on purpose to 
decrease fanout on some nets and I can't find a set of attributes, which 
would work... I tried "keep" and "noreduce" in combination with MAX_FANOUT, 
but XST(8.2.03i) seems to just ignore them all. Does anyone know how to 
force the damn thing to keep the duplicate logic?


Thanks,
/Mikhail 



Article: 139480
Subject: Re: XST removes duplicate logic no matter what
From: gabor <gabor@alacron.com>
Date: Tue, 31 Mar 2009 14:28:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 31, 5:10=A0pm, "MM" <mb...@yahoo.com> wrote:
> I've been fighting XST not to remove duplicate logic I put on purpose to
> decrease fanout on some nets and I can't find a set of attributes, which
> would work... I tried "keep" and "noreduce" in combination with MAX_FANOU=
T,
> but XST(8.2.03i) seems to just ignore them all. Does anyone know how to
> force the damn thing to keep the duplicate logic?
>
> Thanks,
> /Mikhail

If you run from the ISE GUI, set the following in the Xilinx-specific
options tab of the Synthesis properties:

Register Duplication: checked
Equivalent Register Removal: unchecked

Then in the HDL Options tab uncheck "Resource Sharing".

This should allow XST to duplicate registers as necessary to
reduce fanout as well as to push registers into IOBs if
requested.

Regards,
Gabor

Article: 139481
Subject: Re: XST removes duplicate logic no matter what
From: Mike Treseler <mtreseler@gmail.com>
Date: Tue, 31 Mar 2009 14:31:15 -0700
Links: << >>  << T >>  << A >>
MM wrote:
> I've been fighting XST not to remove duplicate logic I put on purpose to 
> decrease fanout on some nets

There is a max_fanout constraint,
but I would just constrain Fmax
and let synthesis work out the details.

     -- Mike Treseler

Article: 139482
Subject: Re: XST removes duplicate logic no matter what
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 31 Mar 2009 17:38:04 -0400
Links: << >>  << T >>  << A >>
"Mike Treseler" <mtreseler@gmail.com> wrote in message 
news:49D28BA3.2060601@gmail.com...
>
> There is a max_fanout constraint,
> but I would just constrain Fmax
> and let synthesis work out the details.

I am in the fine tuning mode. The design is big and I am trying to achieve 
closure on just a few last nets.

/Mikhail




Article: 139483
Subject: Re: XST removes duplicate logic no matter what
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 31 Mar 2009 17:53:08 -0400
Links: << >>  << T >>  << A >>
"gabor" <gabor@alacron.com> wrote in message 
news:0b1d4f4e-1a41-4b89-af04-f01fc08ee36a@v6g2000vbb.googlegroups.com...

>If you run from the ISE GUI, set the following in the Xilinx-specific
>options tab of the Synthesis properties:
>
>Register Duplication: checked
>Equivalent Register Removal: unchecked
>
>Then in the HDL Options tab uncheck "Resource Sharing".


Thanks. Giving this a try. It must have been Equivalent Register Removal 
setting! I wish the tools would produce meaningful warnings about the user 
constraints been overridden!

/Mikhail 



Article: 139484
Subject: Re: MIG 2.0 for DDR - Spartan3E
From: =?ISO-8859-1?Q?Jaime_Andr=E9s_Aranguren_Cardona?= <jaime.aranguren@gmail.com>
Date: Tue, 31 Mar 2009 16:13:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 17 Mrz., 09:58, Jaime Andr=E9s Aranguren Cardona
<jaime.arangu...@gmail.com> wrote:
> On 16 Mrz., 17:18, Jaime Andr=E9sArangurenCardona
>
>
>
>
>
> <jaime.arangu...@gmail.com> wrote:
> > On 26 Feb., 23:02, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> > > gabor wrote:
>
> > > (snip)
>
> > > > For Spartan 3 MIG, which is primitive compared to the Virtex 5
> > > > MIG, the order of row vs. bank addressing is not important.
> > > > This is due to the fact that the MIG code only leaves one
> > > > row of one bank active at any time. =A0The column address should
> > > > be your low order address bits for linear addressing. =A0This
> > > > will prevent unnecessary row precharge / activate sequences
> > > > when performing linear access to memory.
>
> > > One that I might try is a video display that also refreshes
> > > the RAM. =A0That is an old trick that might still work.
>
> > > > Also note that
> > > > the least significant bits of the column address are
> > > > incremented inside the memory chip during a burst operation.
> > > > There is no carry out to the upper address bits, so when
> > > > starting a burst you should normally begin at a burst
> > > > boundary to avoid rapping back to previous addresses.
>
> > > I don't expect any burst operations. =A0My first system will
> > > be 8080 based, and I don't believe that the 8080 does bursts.
>
> > > > Be careful when using the MIG top level interface with
> > > > "linear" address. =A0It may be using the least significant
> > > > bits for the bank address (depends on which interface
> > > > typeDDR, DDR2, etc.).
>
> > > -- glen
>
> > Hi guys,
>
> > Going further with the thread, I want to "report" that it seems to be
> > working, but partially. In simulation everything goes fine, both for
> > writing and reading data. I generate a sequence of numbers, fill the
> > memory with it, and then read all the positions back, comparing with
> > the sequence of numbers written. If an error is found, a counter is
> > incremented. At the end of the read sequence, if everything goes fine,
> > one led should glow, if not (even a single mismatch was found, which
> > means the error counter is different to zero) then 6 leds glow.
>
> > I am testing my stuff on an S3E Kit. If I just run the test for a very
> > few rows (say 3), then most of the times the test passes, others it
> > does not. If I run for higher number of rows, then at all times it
> > fails. So, it seems to me that I am getting timing problems. Besides,
> > I have to add that I am not using an external 133 MHz clock to SMA
> > connector, I am using the onboard 50Mhz clock instead and a couple
> > DCMs, one for generating a 100 MHz clock and another one to generate
> > the 90 degree phase shifted clock.
>
> > Reviewing the implementation reports (ISE 10.1 and ISE 9.2), I see
> > that the signal rst_dqs_div does not meet timing (MAX_DELAY 460 ps).
> > Looking into the details of the UCF, I see that this signal, which for
> > the S3E Starter kit is implemented as a loopback, has an assigment to
> > pin P13. I suppose that that is needed because of packaging to IOBs,
> > which is one of the project options for the MIG generated project. Is
> > there a way to make the signal always internal and not look for a
> > physical pin?
>
> > The only way I have found to meet timing constraints was to remove
> > that constraint in the UCF (the one that assigns rst_dqs_div signal to
> > pin P13), but now another problem arises: when generating the
> > bitstream, it fails because DRC is not passed, saying that the signal
> > rst_dqs_div was assigned to bank3 which uses impedance controlled
> > buffers or has Vref requeriments, which rst_dqs_div does not meet.
>
> > How can it be got to work reliably? Even the original project
> > generated by MIG (ver 2.1, ver 2.3) for the S3E Kit, without
> > modifications, fails to meet the timing constraints for signal
> > rst_dqs_div, which is supposed to be a critical timing signal
> > necessary to get the controller working correctly.
>
> > All your comments and suggestion are very welcome.
>
> > Kind regards.
>
> Hi,
>
> I bypassed the DRC test for bitstream generation, but results are even
> worse: now, most of the times it fails.... very seldom passes, even
> for just 3 rows.
>
> Any hint?
>
> Kind regards.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

Hi,



I am sorry to say that this is FAR from solved... My "checker" does
not work, simply because the cntrl0_data_valid_out signal does not
show valid data in a Post-Translate simulation, whereas in the
Behavioral Simulation it works perfect.



Examining the code in the file (generated from MIG2.3)
xxx_data_read_controller_0.vhd one can see this code:



-- User data valid output signal from data path.

  fifo_0_empty          <=3D '1' when (fifo0_rd_addr(3 downto 0) =3D
fifo_0_wr_addr_3d(3 downto 0)) else '0';
  fifo_1_empty          <=3D '1' when (fifo1_rd_addr(3 downto 0) =3D
fifo_1_wr_addr_3d(3 downto 0)) else '0';
  read_valid_data_0_1   <=3D ((not fifo_0_empty) and (not
fifo_1_empty));
  read_valid_data_1_val <=3D (read_valid_data_0_1);

  process(clk90)
  begin
    if clk90'event and clk90 =3D '1' then
      if reset90_r =3D '1' then
        u_data_val         <=3D '0';
        read_valid_data_r  <=3D '0';
        read_valid_data_r1 <=3D '0';
      else
        read_valid_data_r  <=3D read_valid_data_0_1;
        read_valid_data_r1 <=3D read_valid_data_r;
        u_data_val         <=3D read_valid_data_r1;
      end if;
    end if;
  end process;



There is where the signal is actually generated, the other things are
merely structural connections. However, in the synthesis one get the
following warnings:



WARNING:Xst:2677 - Node <reset90_r> of sequential type is unconnected
in block <data_read0>.
WARNING:Xst:2677 - Node <read_valid_data_1_r> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <read_valid_data_1_r1> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_0> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_1> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_2> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_3> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_4> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_5> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_6> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_7> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_8> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_9> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_10> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_11> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_12> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_13> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_14> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_0_data_out_r_15> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_0> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_1> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_2> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_3> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_4> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_5> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_6> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_7> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_8> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_9> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_10> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_11> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_12> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_13> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_14> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <fifo_1_data_out_r_15> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_0> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_1> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_2> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_3> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_4> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_5> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_6> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_7> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_8> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_9> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_10> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_11> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_12> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_13> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_14> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_15> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_16> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_17> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_18> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_19> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_20> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_21> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_22> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_23> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_24> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_25> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_26> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_27> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_28> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_29> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_30> of sequential type is
unconnected in block <data_read0>.
WARNING:Xst:2677 - Node <first_sdr_data_31> of sequential type is
unconnected in block <data_read0>.


It looks like all what I needed is stripped down from the netlist.
Does someone know how to get rid of this, and make the MIG2.3 DDR
Controller work????



Thanks!

Article: 139485
Subject: Re: Programming Digilent Nexys 2 from Linux
From: emeb <ebrombaugh@gmail.com>
Date: Tue, 31 Mar 2009 16:42:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 30, 4:46=A0pm, Andy Ross <andy.ross...@gmail.com> wrote:
> I recently bought a Digilent Nexys 2 board, and after a few days of
> research got to the point where I can successfully program it over USB
> from a Linux host without the use of a separate (and expensive!) JTAG
> interface. =A0Google told me even before I purchased the board that this
> is a very common requirement; it seems that I'm not the only one
> interested in linux-hosted FPGA development. =A0The pieces to make this
> work were all there, happily (see the README in the download below for
> details -- the chain of responsibility here is long); it just took
> work to assemble them correctly.
>
> For those interested, I wrote a quick perl script to automate the
> process, available at: [url]http://plausible.org/andy/nexys2prog.tar.gz
> [/url]
>
> This wraps the multi-step mess (device detection/configuration, SVF
> generation, and JTAG download) as fully as possible, most importantly
> by doing the USB bus enumeration and dynamically reprogramming the
> Nexys 2 with a patched usb_jtag firmware blob in the script itself.
> The user just specifies the Xilinx bitstream file as the sole
> argument.
>
> Installation is as simple as I could make it, requiring only Xilinx
> ISE, two binary packages (fxload and libftdi -- both available via apt-
> get on Ubuntu Intrepid) and one source install (UrJTAG -- just a
> simple "./configure;make;make install" will do).
>
> Hopefully this will help other newbies with the learning curve. =A0Let
> me know if something doesn't work, or if there are questions.

Thanks for putting that together! I've been googling unsuccessfully
for all that info since buying my Nexsys 2 a few months ago. derp derp
derp.

Eric

Article: 139486
Subject: Digital design references for timing, etc.
From: wondering.gnome@gmail.com
Date: Tue, 31 Mar 2009 16:45:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi, all.

I'm relatively new to the field of digital design, and have completed
a few FPGA-based designs, successfully integrated and debugged them.
Writing HDL, using vendor tools and performing simulations have been
fairly straightforward and within my comfort zone. But now I'm faced
with the foreign task of debugging some nasty timing problems, and I'm
realizing how little I understand about some fundamental digital
design principles, like setup and hold timing, clock skew and jitter,
and the like.

What books and other resources would you recommend for someone who
needs a better understanding of digital design principles, with a
special focus on timing concerns?

Thanks,
The Wondering Gnome

Article: 139487
Subject: Re: Fiber optics protocols for mid range speed
From: "Marty Ryba" <martin.ryba.nospam@verizon.net>
Date: Wed, 01 Apr 2009 02:58:34 GMT
Links: << >>  << T >>  << A >>
"Oliver Faust" <oliver.faust@gmail.com> wrote in message 
news:2f957410-1e66-440f-ac70-ae0e5d83cf1c@k41g2000yqh.googlegroups.com...
On Mar 30, 6:55 pm, Tommy Thorn <tommy.th...@gmail.com> wrote:
> > You know, the simplest, best tested, _widely_ available, and likely
> > cheapest solution is ... (drumroll) 100 Mbps Ethernet. Ethernet is
> > very tolerant of EMI, and with Cat 6 cables I seriously doubt you
> > could have an issue.
> > Fiber is fun (and healthy in your diet), but it just isn't mainsteam
> > enough which translates into either high cost or lots of custom
> > development.
> > Tommy
> Dear Tommy,
> At the moment I'm in the discovery phase of the project. Slowly, I
> understand the point that fiber optics are not mainstream. Fiber
> optics are only considered for applications where weight is an issue
> and / or EMI resilience.
> Oliver Faust

There is a 100 Mbps fiber optic Ethernet standard, 100BASE-FX that still 
exists (of course Gigabit Ethernet gets all the attention these days). I 
remember we used it to replace FDDI (ugh!) on an aircraft platform that 
needed fiber optic networking for EMI reasons. Of course we made that change 
something like 8 years ago but I don't think they've changed it again yet. A 
quick Google brought up a Broadcom BCM5248 transceiver chip with 8 ports.

Marty 



Article: 139488
Subject: Xilinx partitions vs. smartguide
From: "stephen.craven@gmail.com" <stephen.craven@gmail.com>
Date: Tue, 31 Mar 2009 20:05:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
All,

Though a long-time Xilinx user, I have yet to try partitions or the
updated smartguide feature.  I would appreciate your thoughts on these
features.  Which is best at reducing runtime?  Does partitioning
really, truly lock the placement and routing?  Are there reasons not
to use them that aren't at first obvious?

Thanks,
Stephen

Article: 139489
Subject: Re: clock distribution on VITA 57 (FMC)
From: "Marty Ryba" <martin.ryba.nospam@verizon.net>
Date: Wed, 01 Apr 2009 03:19:16 GMT
Links: << >>  << T >>  << A >>
"palvarez" <pabloalvarezsanchez@gmail.com> wrote in message 
news:cc81f482-560b-4641-8ade-e322a71113c8@37g2000yqp.googlegroups.com...
> I received recently the Vita 57 standard. I would like to congratulate
> the Vita team that has written it. It is a beautiful standard that
> many people have been waiting for since a long time. On the first page
> there is a warning stating that the dedicated clock distribution pins
> from Carrier to Mezzanine (C2M) were going to be replaced by Mezzanine
> to Carrier (M2C) pins. This means that if you ever want to feed a
> clean, stable, low jitter you will have to pass through the FPGA using
> standard differential IOs.
>
> Adding more M2C pairs is not really helpful as standard FPGA IOs can
> already be routed to the DCM reference clock input without major
> problems (please correct me if I am wrong). On the other hand the
> added jitter by the FPGA will be a liming factor for high accuracy
> data acquisition applications that do not receive their reference
> clock directly on the FMC front panel.
>
> I would like to know the FPGA community opinion. Who knows? If we give
> the right reasons perhaps the Vita 57 working group could change their
> mind after all.

As a systems engineer, I can't speak to all the details and I'm just getting 
familiar with some of the discussion on FMC. I can say that clock 
synchronization and time distribution is a pet concern of mine. Considering 
the front panel, I'm not sure how the vendors are going to implement the 
granddaughter cards regarding clocking...I'm interested in high speed DACs 
versus ADCs and I haven't seen any announced in FMC yet. Right now, I have a 
group of 8 boards each with a PMC card that has an FPGA and a couple DACs on 
them. The initialization and synchronization process on the DACs (Analog 
Devices AD9857s) is such that I can't get much better than 40 ns alignment 
between the multiple boards (grr!). I'd like to see a solution that wrings 
this out better; the 8 boards are fed a 1PPS discrete from a distribution 
amplifier that should provide less than 0.5 ns skew across the multiple 
boards. There are also separate phase locked 10 MHz signals going into all 
of them. All kinds of opportunities for mischief (i.e., 8 independent PLL 
chips running 409.6 MHz clocks off the 10 MHz). On the other hand, reliably 
routing 200 MHz clocks from one PMC to multiple others across a VME P2 
connections sounds like trouble as well.

So, even when you get your clocks from the front panel (losing precious real 
estate) there can be issues. A good standardized solution would benefit a 
lot of us. Can the FPGAs possibly run IEEE 1588 to at least get rid of the 
1PPS discretes? What's the transmission quality on those M2C and C2M pins? 
Could they send 10MHz sine waves without adding too much noise?

Sorry if this is too much churn and not enough solution...it's just nice to 
vent to a group that understands some of this.

Marty 



Article: 139490
Subject: Re: Altera's free ColdFire v1 IP core anybody used it?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Tue, 31 Mar 2009 21:57:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 23, 4:45=A0pm, Antti <Antti.Luk...@googlemail.com> wrote:
> I just wonder ;)
>
> the FREE is not so free actually... all infos say theColdFirecore is
> free, and no royalties
> but the free license is only for Cyclone III, for all other devices
> the license is 10k + 0.02 royalty
>
> also what is strange there seems to be no download for the free
> version :(
>
> Antti

ok, I no longer wonder

New project
New SOPC component
Select ColdFire processor
Close
Set toplevel ports
Click run flow

no errors, configuration file for CIII generated

unfortunatly this almost all I can say, the agreements I had to
sign to get the free core prohibit almost everything except breathing.

Antti






Article: 139491
Subject: Re: Silicon Blue Warm-Boot not working properly
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 1 Apr 2009 01:19:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 31, 6:07=A0pm, Prevailing over Technology <steve.kn...@prevailing-
technology.com> wrote:
> On Mar 24, 9:32=A0am, "Antti.Luk...@googlemail.com"
>
> <Antti.Luk...@googlemail.com> wrote:
>
> [... snip ...]
>
> > from your comments it was not so sure, did you actually got it to work
> > with real hardware? (with older tools)?
>
> [... snip ...]
>
> Hi Antti,
>
> Unfortunately, I'm travelling at the moment so I don't have access to
> all my files. =A0However, here are the modifications to the
> configuration image that I made before it was supported in software.
> From testing, there are separate controls to enable ColdBoot and
> WarmBoot images. =A0 I think that the current software release enables
> both ColdBoot and WarmBoot (i.e., I don't see any way to individually
> enable or disable the controls).
>
> Here is an annotated bitstream snippet that shows some of the control
> bits. =A0This is the =93control=94 header loaded at the start of the
> configuration image and must be located at address 0. =A0It contains the
> ColdBoot and WarmBoot controls plus the start vector addresses for
> each of the four possible configuration images. =A0WARNING: =A0These are
> old notes so it=92s probably worth re-testing.
>
> 7e aa 99 7e =A0; Synchronization word
> 92 00 30 =A0 =A0 ; "30" enables both ColdBoot and WarmBoot, "20" enables
> just ColdBoot, "10" enables just WarmBoot

Hi Steve
thanks a lot for the reply, unfortunatly my testing show different
results:

92 00 30 Cold+Warm enabled
92 00 10 Cold+Warm enabled
92 00 20 -- DOES NOT CONFIGURE

Antti





Article: 139492
Subject: Re: clock distribution on VITA 57 (FMC)
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 1 Apr 2009 01:44:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 1, 6:19=A0am, "Marty Ryba" <martin.ryba.nos...@verizon.net>
wrote:
> "palvarez" <pabloalvarezsanc...@gmail.com> wrote in message
>
> news:cc81f482-560b-4641-8ade-e322a71113c8@37g2000yqp.googlegroups.com...
>
>
>
> > I received recently the Vita 57 standard. I would like to congratulate
> > the Vita team that has written it. It is a beautiful standard that
> > many people have been waiting for since a long time. On the first page
> > there is a warning stating that the dedicated clock distribution pins
> > from Carrier to Mezzanine (C2M) were going to be replaced by Mezzanine
> > to Carrier (M2C) pins. This means that if you ever want to feed a
> > clean, stable, low jitter you will have to pass through the FPGA using
> > standard differential IOs.
>
> > Adding more M2C pairs is not really helpful as standard FPGA IOs can
> > already be routed to the DCM reference clock input without major
> > problems (please correct me if I am wrong). On the other hand the
> > added jitter by the FPGA will be a liming factor for high accuracy
> > data acquisition applications that do not receive their reference
> > clock directly on the FMC front panel.
>
> > I would like to know the FPGA community opinion. Who knows? If we give
> > the right reasons perhaps the Vita 57 working group could change their
> > mind after all.
>
> As a systems engineer, I can't speak to all the details and I'm just gett=
ing
> familiar with some of the discussion on FMC. I can say that clock
> synchronization and time distribution is a pet concern of mine. Consideri=
ng
> the front panel, I'm not sure how the vendors are going to implement the
> granddaughter cards regarding clocking...I'm interested in high speed DAC=
s
> versus ADCs and I haven't seen any announced in FMC yet. Right now, I hav=
e a
> group of 8 boards each with a PMC card that has an FPGA and a couple DACs=
 on
> them. The initialization and synchronization process on the DACs (Analog
> Devices AD9857s) is such that I can't get much better than 40 ns alignmen=
t
> between the multiple boards (grr!). I'd like to see a solution that wring=
s
> this out better; the 8 boards are fed a 1PPS discrete from a distribution
> amplifier that should provide less than 0.5 ns skew across the multiple
> boards. There are also separate phase locked 10 MHz signals going into al=
l
> of them. All kinds of opportunities for mischief (i.e., 8 independent PLL
> chips running 409.6 MHz clocks off the 10 MHz). On the other hand, reliab=
ly
> routing 200 MHz clocks from one PMC to multiple others across a VME P2
> connections sounds like trouble as well.
>
> So, even when you get your clocks from the front panel (losing precious r=
eal
> estate) there can be issues. A good standardized solution would benefit a
> lot of us. Can the FPGAs possibly run IEEE 1588 to at least get rid of th=
e
> 1PPS discretes? What's the transmission quality on those M2C and C2M pins=
?
> Could they send 10MHz sine waves without adding too much noise?
>
> Sorry if this is too much churn and not enough solution...it's just nice =
to
> vent to a group that understands some of this.
>
> Marty

there was 3GS/S FMC ADC board at Embedded

Antti

Article: 139493
Subject: 8b10b encoding + line encoding
From: Sharan <sharan.basappa@gmail.com>
Date: Wed, 1 Apr 2009 02:08:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

In few of the protocols (e.g. USB), there is an 8b10b and then there
is line encoding. Since one of the purpose of 8b10b is to create
enough 1&0 transitions, why is there a separate line encoding after
8b10b? Am I missing something

Regards

Article: 139494
Subject: Altera flash FPGA with ColdFire hard core
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 1 Apr 2009 02:58:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
there will be no MAX-III, and how the "followup" Flash FPGA/CPLD from
Altera would be is something mr B from Altera didnt really want to
reveal at Embedded...

But after checking out the FREE ColdFire v1 core that can be fully
integrated with SOPC, and is completly free for Cyclone III, I can now
belive that that the new Altera Flash FPGA will really have hardened
ColdFire core. I just hope they have learned from the mistakes with
MAX-II, and will include user writeable flash blocks like they are
available in Lattice XP2.

Antti

Article: 139495
Subject: DCM vs PLL
From: Sharan <sharan.basappa@gmail.com>
Date: Wed, 1 Apr 2009 07:01:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

From the datasheets, it is looks like the only major difference
between DCM and PLL is that PLL additionally does jitter filtering.
Rest of the features are present in both these macros. So what decides
whether one should use a PLL or DCM in FPGA.

The following are the common features present in both DCM and PLL:
1) frequency synth
2) deskew
3) frequency div

Additionally DCM can also do phase shift.

Regards,
Sharan

Article: 139496
Subject: Re: DCM vs PLL
From: filter001@desinformation.de
Date: Wed, 1 Apr 2009 07:42:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 1 Apr., 16:01, Sharan <sharan.basa...@gmail.com> wrote:
> Hi,
>
> From the datasheets, it is looks like the only major difference
> between DCM and PLL is that PLL additionally does jitter filtering.
> Rest of the features are present in both these macros. So what decides
> whether one should use a PLL or DCM in FPGA.
>
> The following are the common features present in both DCM and PLL:
> 1) frequency synth
> 2) deskew
> 3) frequency div
>
> Additionally DCM can also do phase shift.

PLL's do that too.

DCM's have a higher potential for failures due tu their state-machine
behaviour.

For Example EMI could disturb some clocks getting into a DCM locking
up and you need a systen reset.

Analog PLL's are more tolerant about that and especially if you want
to have deterministic jitter-fitering you are lost with the DCM.

I would always chose a good analog PLL over DCM.

Article: 139497
Subject: Re: DCM vs PLL
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 1 Apr 2009 16:36:29 +0100
Links: << >>  << T >>  << A >>

"Sharan" <sharan.basappa@gmail.com> wrote in message 
news:6374ea0e-4cdb-474a-9cd6-df68f8252302@v15g2000yqn.googlegroups.com...
> Hi,
>
> From the datasheets, it is looks like the only major difference
> between DCM and PLL is that PLL additionally does jitter filtering.
> Rest of the features are present in both these macros. So what decides
> whether one should use a PLL or DCM in FPGA.
>
> The following are the common features present in both DCM and PLL:
> 1) frequency synth
> 2) deskew
> 3) frequency div
>
> Additionally DCM can also do phase shift.
>
> Regards,
> Sharan

PLL's have a higher potential for failures due tu their non-state-machine
behaviour.

For Example EMI could disturb some clocks getting into a PLL phase
detector and you get a lock loss.

Digital DCM's are more tolerant about that and especially if you want
to have deterministic operation that is not component value dependent you 
are lost with the PLL.

I would always chose a good DCM over analog PLL. 



Article: 139498
Subject: Re: Digital design references for timing, etc.
From: Koorndyk <kris.koorndyk@gmail.com>
Date: Wed, 1 Apr 2009 08:44:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 31, 7:45=A0pm, wondering.gn...@gmail.com wrote:
> Hi, all.
>
> I'm relatively new to the field of digital design, and have completed
> a few FPGA-based designs, successfully integrated and debugged them.
> Writing HDL, using vendor tools and performing simulations have been
> fairly straightforward and within my comfort zone. But now I'm faced
> with the foreign task of debugging some nasty timing problems, and I'm
> realizing how little I understand about some fundamental digital
> design principles, like setup and hold timing, clock skew and jitter,
> and the like.
>
> What books and other resources would you recommend for someone who
> needs a better understanding of digital design principles, with a
> special focus on timing concerns?
>
> Thanks,
> The Wondering Gnome

I've found the latest Xilinx Timing Constraints User Guide to be
invaluable.

www.xilinx.com/itp/xilinx10/books/docs/timing_constraints_ug/timing_constra=
ints_ug.pdf

Article: 139499
Subject: Re: DCM vs PLL
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 01 Apr 2009 15:49:16 GMT
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote:

>
>"Sharan" <sharan.basappa@gmail.com> wrote in message 
>news:6374ea0e-4cdb-474a-9cd6-df68f8252302@v15g2000yqn.googlegroups.com...
>> Hi,
>>
>> From the datasheets, it is looks like the only major difference
>> between DCM and PLL is that PLL additionally does jitter filtering.
>> Rest of the features are present in both these macros. So what decides
>> whether one should use a PLL or DCM in FPGA.
>>
>> The following are the common features present in both DCM and PLL:
>> 1) frequency synth
>> 2) deskew
>> 3) frequency div
>>
>> Additionally DCM can also do phase shift.
>>
>> Regards,
>> Sharan
>
>PLL's have a higher potential for failures due tu their non-state-machine
>behaviour.
>
>For Example EMI could disturb some clocks getting into a PLL phase
>detector and you get a lock loss.
>
>Digital DCM's are more tolerant about that and especially if you want
>to have deterministic operation that is not component value dependent you 
>are lost with the PLL.
>
>I would always chose a good DCM over analog PLL. 

Now I'm confused :-)


-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------



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