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 149625

Article: 149625
Subject: Re: cool BGA pattern
From: Gabor <gabor@alacron.com>
Date: Fri, 12 Nov 2010 05:54:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 11, 6:34=A0pm, "k...@att.bizzzzzzzzzzzz"
<k...@att.bizzzzzzzzzzzz> wrote:
> On Thu, 11 Nov 2010 07:03:29 -0800, John Larkin
>
>
>
> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> >On Thu, 11 Nov 2010 08:45:56 -0000, "Michael Kellett"
> ><nos...@nospam.com> wrote:
>
> >>"John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in mes=
sage
> >>news:iq5jd6t8vpelg53n1e1e5hdkqs7f0deu90@4ax.com...
>
> >>>http://www.theregister.co.uk/2010/11/09/marvell_armada_xp_arm_chip/
>
> >>> All that beautiful room for vias.
>
> >>> John
>
> >>Very nice (the pattern - I don't have any use for the chip !). I wish m=
ore
> >>semi compnaies would think a bit more about the cost of using BGAs befo=
re
> >>connecting evey possible ball.
>
> >>Michael Kellett
>
> >The Altera chip we're going to use [1] is a solid rectangle of balls.
> >Yuk.
>
> They're not all that bad. =A0Most of the center are power/ground so easie=
r to
> wire. =A0The problem is that without the doughnut hole there is no conven=
ient
> place to put decoupling and terminators (on the back). =A0The coarse pitc=
hed
> parts (1mm and .8mm) aren't hard to fan out, either. =A0We're stuck with =
them
> because of our SMT process anyway. =A0My problem is that no one makes
> low-pincount parts with a coarse pitch. =A0They insist on .5 or even .4mm=
!
>
> >John
>
> >[1] We're migrating away from Xilinx. Great silicon, insanely broken
> >software.
>
> I didn't have a lot of problems with Xilinx, other than it constantly wan=
ted
> to rebuild my libraries in a new location. =A0I like Altera's software mu=
ch
> better, though.


There's a HUGE difference in package design for consumer products like
mass-market microprocessors and PC chip sets, and embedded products
like FPGA's and microcontrollers.  For the consumer stuff the overall
package size isn't as important as the ability to lay out the circuit
on
as few layers as possible.  For embedded components its ALL about
package size.  The boards just keep getting smaller (look at cell
phones).
On a board the size of a PC motherboard, you don't want 12 layers, or
fine pitch routing, or blind vias...  Much better to have a 12-layer
BGA substrate that brings out signals to 1.27mm spaced pads in
an order that matches the surrounding chips so that the entire bus
routes
in one or two layers.  But you can clearly see that these BGA packages
are significantly larger than the silicon devices they support.

On a cell phone sized board adding a couple layers or using blind
vias or microvias won't increase the product price significantly.  But
having a chip that takes up the entire board would be a design
killer.

Regards,
Gabor

Article: 149626
Subject: Re: cool BGA pattern
From: 2cents <web@sharonmccormack.com>
Date: Fri, 12 Nov 2010 06:19:16 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 11, 3:03=A0pm, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Thu, 11 Nov 2010 08:45:56 -0000, "Michael Kellett"
>
>
>
>
>
> <nos...@nospam.com> wrote:
>
> >"John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in mess=
age
> >news:iq5jd6t8vpelg53n1e1e5hdkqs7f0deu90@4ax.com...
>
> >>http://www.theregister.co.uk/2010/11/09/marvell_armada_xp_arm_chip/
>
> >> All that beautiful room for vias.
>
> >> John
>
> >Very nice (the pattern - I don't have any use for the chip !). I wish mo=
re
> >semi compnaies would think a bit more about the cost of using BGAs befor=
e
> >connecting evey possible ball.
>
> >Michael Kellett
>
> The Altera chip we're going to use [1] is a solid rectangle of balls.
> Yuk.
>
> John
>
> [1] We're migrating away from Xilinx. Great silicon, insanely broken
> software.

I wouldn't rush a decision like that - especially when I know from a
very good source that there is a major effort underway to improve the
SW at Xilinx.
I hear there is a upcoming version of the SW that will be a big step
forward in terms of quality, speed, etc. So might be worth waiting a
while, especially if you are familiar with the silicon already.

Article: 149627
Subject: Re: Statemachine debugging with Chipscope
From: jc <jcappello@optimal-design.com>
Date: Fri, 12 Nov 2010 06:28:50 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 11, 5:29=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
> On Nov 11, 7:58=A0am, jc <jcappe...@optimal-design.com> wrote:
>
> > In summary, registering state bits and doing binary conversion allows
>
> Maybe I'm missing something here, and just need a clearer
> explanation...
>
> What is the output of the binary conversion when the input is an
> illegal state value? (Example: =A0Three bit one hot that ends up at
> "111")
>
> How do you specify the binary conversion function when the input is an
> enumerate type? =A0The t_my_type'pos(xyz) won't do it. =A0In the previous
> example it would return a number from 0 to 2. =A0Even allowing that the
> implementation of the function would compute two bits and therefore be
> capable of returning 0 to 3, it does not cover the case that I
> mentioned "111". =A0The fact that there are three bits implementing the
> one hot encoding means that there are 8 possibilities, most of which
> can not be specified in any fashion.
>
> Kevin

Kevin, I suspect (as others pointed out here) that using the OTHERS
clause in a case statement for the binary conversion of a non-2^n
number of states isn't enough to ensure safe mode, i.e. if more than
one one-hot flop goes high, go to recovery state. In which case it
would be up to the user to flip the safe mode switch for the original
fsm flops, or apply custom logic on the binary conversion side to
detect the condition, if this detection is desired. Otherwise, I
believe the binary conversion will 'mask' such invalid conditions. If
I get time soon, I'm going to analyze a set of gates for such a binary
conversion process to see exactly what it does for invalid
conditions.

Having said that, I'm confident that a binary conversion using the
CASE statement after registering the one-hot flops is a valid way to
follow the sequence of the fsm in an expected order. I've done this
many times via chipscope.
John

Article: 149628
Subject: Re: cool BGA pattern
From: Jeroen Belleman <jeroen@nospam.please>
Date: Fri, 12 Nov 2010 16:06:47 +0100
Links: << >>  << T >>  << A >>
2cents wrote:
> On Nov 11, 3:03 pm, John Larkin
> [...]
>> [1] We're migrating away from Xilinx. Great silicon, insanely broken
>> software.
> 
> I wouldn't rush a decision like that - especially when I know from a
> very good source that there is a major effort underway to improve the
> SW at Xilinx.
> I hear there is a upcoming version of the SW that will be a big step
> forward in terms of quality, speed, etc. So might be worth waiting a
> while, especially if you are familiar with the silicon already.

Do you still believe in Father Christmas and the Easter Bunny too?

Jeroen Belleman

Article: 149629
Subject: Re: Statemachine debugging with Chipscope
From: Jeff Cunningham <jcc@sover.net>
Date: Fri, 12 Nov 2010 10:18:19 -0500
Links: << >>  << T >>  << A >>
On 11/12/10 9:28 AM, jc wrote:
> Kevin, I suspect (as others pointed out here) that using the OTHERS
> clause in a case statement for the binary conversion of a non-2^n
> number of states isn't enough to ensure safe mode, i.e. if more than
> one one-hot flop goes high, go to recovery state. In which case it
> would be up to the user to flip the safe mode switch for the original
> fsm flops, or apply custom logic on the binary conversion side to
> detect the condition, if this detection is desired. Otherwise, I
> believe the binary conversion will 'mask' such invalid conditions. If
> I get time soon, I'm going to analyze a set of gates for such a binary
> conversion process to see exactly what it does for invalid
> conditions.

I've tested this and verified the XST produces identical CPLD jedec 
files whether or not the "when OTHERS" is present in a state machine.

> Having said that, I'm confident that a binary conversion using the
> CASE statement after registering the one-hot flops is a valid way to
> follow the sequence of the fsm in an expected order. I've done this
> many times via chipscope.
> John

But doesn't this only work if the state machine doesn't go to an illegal 
state? Otherwise, if it goes 2-hot for example, the binary conversion 
can't indicate both states, and will be in effect a priority encoder.

I've found that providing an independent decode for each state, i.e. 
make 4 registered debug bits for a 4-state enum is a pretty bullet proof 
way of catching illegal states without having to delve into low level 
state signal names post synthesis:

process(clk)
begin
   if state = s0 then
     state0_debugbit <= '1';
   else
     state0_debugbit <= '0';
   end if;
end process;

process(clk)
begin
   if state = s1 then
     state1_debugbit <= '1';
   else
     state1_debugbit <= '0';
   end if;
end process;

and so on...
So state0_debugbit will be identical (after a register delay) to the 
1-hot state bit.

I think it should be possible to wrap this up in a loop like this:

type state_t is (s0,s1,s2,s3);
signal state: state_t;
signal state_debugbits(3 downto 0);

process(clk)
begin
   for i in 0 to 3 loop
     if state = state_t'val(i) then
       state_debugbits(i) <= '1';
     else
       state_debugbits(i) <= '0';
     end if;
   end loop;
end process;

-Jeff

Article: 149630
Subject: Re: cool BGA pattern
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 12 Nov 2010 07:20:34 -0800
Links: << >>  << T >>  << A >>
On Fri, 12 Nov 2010 06:19:16 -0800 (PST), 2cents
<web@sharonmccormack.com> wrote:

>On Nov 11, 3:03†pm, John Larkin
><jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>> On Thu, 11 Nov 2010 08:45:56 -0000, "Michael Kellett"
>>
>>
>>
>>
>>
>> <nos...@nospam.com> wrote:
>>
>> >"John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in message
>> >news:iq5jd6t8vpelg53n1e1e5hdkqs7f0deu90@4ax.com...
>>
>> >>http://www.theregister.co.uk/2010/11/09/marvell_armada_xp_arm_chip/
>>
>> >> All that beautiful room for vias.
>>
>> >> John
>>
>> >Very nice (the pattern - I don't have any use for the chip !). I wish more
>> >semi compnaies would think a bit more about the cost of using BGAs before
>> >connecting evey possible ball.
>>
>> >Michael Kellett
>>
>> The Altera chip we're going to use [1] is a solid rectangle of balls.
>> Yuk.
>>
>> John
>>
>> [1] We're migrating away from Xilinx. Great silicon, insanely broken
>> software.
>
>I wouldn't rush a decision like that - especially when I know from a
>very good source that there is a major effort underway to improve the
>SW at Xilinx.

That's not surprising. You could say the same about Microsoft. The
issue is that software, and software culture, can be so broken that it
can't be fixed.

>I hear there is a upcoming version of the SW that will be a big step
>forward in terms of quality, speed, etc. So might be worth waiting a
>while, especially if you are familiar with the silicon already.

Then why aren't our FAEs telling us about it? Maybe because Xilinx
fired all of them not so long ago.

John


Article: 149631
Subject: Re: cool BGA pattern
From: 2cents <web@sharonmccormack.com>
Date: Fri, 12 Nov 2010 08:23:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 12, 3:06=A0pm, Jeroen Belleman <jer...@nospam.please> wrote:
> 2cents wrote:
> > On Nov 11, 3:03 pm, John Larkin
> > [...]
> >> [1] We're migrating away from Xilinx. Great silicon, insanely broken
> >> software.
>
> > I wouldn't rush a decision like that - especially when I know from a
> > very good source that there is a major effort underway to improve the
> > SW at Xilinx.
> > I hear there is a upcoming version of the SW that will be a big step
> > forward in terms of quality, speed, etc. So might be worth waiting a
> > while, especially if you are familiar with the silicon already.
>
> Do you still believe in Father Christmas and the Easter Bunny too?
>
> Jeroen Belleman

It's easy to be dismissive - but believe it or not, Xilinx has been
doing something about customer complaints regarding the SW tools.
They have been working on the problem for a number of years. Have you
seen PlanAhead? That's a taste of things to come, or so I'm told.

Article: 149632
Subject: Re: cool BGA pattern
From: Muzaffer Kal <kal@dspia.com>
Date: Fri, 12 Nov 2010 09:22:39 -0800
Links: << >>  << T >>  << A >>
On Fri, 12 Nov 2010 08:23:02 -0800 (PST), 2cents
<web@sharonmccormack.com> wrote:

>On Nov 12, 3:06†pm, Jeroen Belleman <jer...@nospam.please> wrote:
>> 2cents wrote:
>> > On Nov 11, 3:03 pm, John Larkin
>> > [...]
>> >> [1] We're migrating away from Xilinx. Great silicon, insanely broken
>> >> software.
>>
>> > I wouldn't rush a decision like that - especially when I know from a
>> > very good source that there is a major effort underway to improve the
>> > SW at Xilinx.
>> > I hear there is a upcoming version of the SW that will be a big step
>> > forward in terms of quality, speed, etc. So might be worth waiting a
>> > while, especially if you are familiar with the silicon already.
>>
>> Do you still believe in Father Christmas and the Easter Bunny too?
>>
>> Jeroen Belleman
>
>It's easy to be dismissive - but believe it or not, Xilinx has been
>doing something about customer complaints regarding the SW tools.
>They have been working on the problem for a number of years. Have you
>seen PlanAhead? That's a taste of things to come, or so I'm told.

Planahead is a tool which they've acquired. If the same group is
developing ISE 13, it would probably be an good improvement. The main
problem with the tools is timing engine and constraint management. If
the timing engine under trace & par is replaced with something which
supports SDC that would solve most of the problems are having.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 149633
Subject: Re: Statemachine debugging with Chipscope
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 12 Nov 2010 09:38:45 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 12, 9:28=A0am, jc <jcappe...@optimal-design.com> wrote:
>
> Kevin, I suspect (as others pointed out here) that using the OTHERS
> clause in a case statement for the binary conversion of a non-2^n
> number of states isn't enough to ensure safe mode

I fully understand that "when others" does not necessarily generate
recovery logic.  Altera (and I suspect other tools) require a specific
synthesis tool setting in order to enable 'safe state machines'.  With
Quartus, the setting is called "Safe State Machine" and is defined as
"Tells the compiler to implement state machines that can recover
gracefully from an illegal state."

>, i.e. if more than
> one one-hot flop goes high, go to recovery state. In which case it
> would be up to the user to flip the safe mode switch for the original
> fsm flops, or apply custom logic on the binary conversion side to
> detect the condition, if this detection is desired.

I agree that this logic can be manually added and also that allowing
an extra clock cycle to recover might be acceptable also but I'm not
seeing how your suggestion of a binary conversion function can be
specified in the source code.  For example, the three bit 'one hot'
encoded example will have three bits and therefore 8 states (3 legal,
5 not legal).  In order to 'know' that there are 5 illegal states in
the final implementation, one would have to know ahead of time that it
would be one-hot encoded.  If the implementation was binary encoded
there would only be one illegal state.

Now ask yourself,
1. For a given enumeration type of 'n' values, what is the range of
the integer value that is the output of your function?  Is it '0 to n
- 1'?  Is it '0 to 2^n - 1'?
2. Using your answer to #1, explain why your answer is correct and why
the other suggested answer is wrong.  Does the 'pos() VHDL attribute
have the same range as the answer that you think is correct?
3. Explain how you guarantee that the implementation of the final
synthesized result has the encoding that matches the assumption that
went into your answer to #1 and how the wrong answer from #2 will
never be synthesized.
4. Explain how your answer to #3 is portable across multiple tools.
Or, to view it a different way, which recognized standard provides the
basis for your guarantee on #3?  Hint:  Since #1 said enumerated type,
the basis for any guarantee to #3 will not be the VHDL language
standard.

In the end, there is probably no way to use an enumerated type and
make it through all of the above questions.  Using Quartus, the only
way to get a safe state machine is to use a tool specific
setting...but on the other hand, the only reason that the tool
specific setting is required is because the tool also decided it was
OK to ignore the "when others" in the source code in the first place.

>
> Having said that, I'm confident that a binary conversion using the
> CASE statement after registering the one-hot flops is a valid way to
> follow the sequence of the fsm in an expected order. I've done this
> many times via chipscope.

Debug in chipscope may have been the OP's original question, but this
sub-topic has to do with recovery from illegal states and being able
to specify something that gets implemented.

Kevin Jennings

Article: 149634
Subject: Re: Statemachine debugging with Chipscope
From: jc <jcappello@optimal-design.com>
Date: Fri, 12 Nov 2010 09:59:29 -0800 (PST)
Links: << >>  << T >>  << A >>
Allow me to clarify. I now consider the issues of illegal state
detection and binary conversion as two separate points of discussion.
In the latter, all I'm suggesting now is that here is a means for
translating an fsm into a format better understood through chipscope
and/or status regs, regardless of how that fsm is ultimately coded. I
take the blame for suggesting originally that using the "OTHERS"
clause in this binary conversion takes care of illegal states. I now
agree that this is not the case.

For illegal state detection, it's up to the designer to either use a
synthesis switch so that the tools can add the overhead logic into the
original fsm code--which is completely separate from the binary
conversion part--or build in this detection/recovery manually. I
suggested that doing this within the binary conversion realm could
alleviate performance issues that could occur with safe mode built
within the original fsm.

Sorry for the confusion.
John

KJ wrote:
> I fully understand that "when others" does not necessarily generate
> recovery logic.  Altera (and I suspect other tools) require a specific
> synthesis tool setting in order to enable 'safe state machines'.  With
> Quartus, the setting is called "Safe State Machine" and is defined as
> "Tells the compiler to implement state machines that can recover
> gracefully from an illegal state."
>
>

Article: 149635
Subject: Re: Statemachine debugging with Chipscope
From: jc <jcappello@optimal-design.com>
Date: Fri, 12 Nov 2010 10:02:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 12, 10:18=A0am, Jeff Cunningham <j...@sover.net> wrote:
> On 11/12/10 9:28 AM, jc wrote:
>
> But doesn't this only work if the state machine doesn't go to an illegal
> state? Otherwise, if it goes 2-hot for example, the binary conversion
> can't indicate both states, and will be in effect a priority encoder.
>

Yes, I agree that this works only for legal state transitions, and
that the binary conversion for illegal states is not well defined
(mainly because it depends on how the synthesis tool implements the
said case statement. It's up to the designer to monitor and flag
illegal states some other way, if necessary.
John


Article: 149636
Subject: Re: cool BGA pattern
From: John McCaskill <jhmccaskill@gmail.com>
Date: Fri, 12 Nov 2010 10:03:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 12, 11:22=A0am, Muzaffer Kal <k...@dspia.com> wrote:
> On Fri, 12 Nov 2010 08:23:02 -0800 (PST), 2cents
>
>
>
> <w...@sharonmccormack.com> wrote:
> >On Nov 12, 3:06=A0pm, Jeroen Belleman <jer...@nospam.please> wrote:
> >> 2cents wrote:
> >> > On Nov 11, 3:03 pm, John Larkin
> >> > [...]
> >> >> [1] We're migrating away from Xilinx. Great silicon, insanely broke=
n
> >> >> software.
>
> >> > I wouldn't rush a decision like that - especially when I know from a
> >> > very good source that there is a major effort underway to improve th=
e
> >> > SW at Xilinx.
> >> > I hear there is a upcoming version of the SW that will be a big step
> >> > forward in terms of quality, speed, etc. So might be worth waiting a
> >> > while, especially if you are familiar with the silicon already.
>
> >> Do you still believe in Father Christmas and the Easter Bunny too?
>
> >> Jeroen Belleman
>
> >It's easy to be dismissive - but believe it or not, Xilinx has been
> >doing something about customer complaints regarding the SW tools.
> >They have been working on the problem for a number of years. Have you
> >seen PlanAhead? That's a taste of things to come, or so I'm told.
>
> Planahead is a tool which they've acquired. If the same group is
> developing ISE 13, it would probably be an good improvement. The main
> problem with the tools is timing engine and constraint management. If
> the timing engine under trace & par is replaced with something which
> supports SDC that would solve most of the problems are having.
> --
> Muzaffer Kal
>
> DSPIA INC.
> ASIC/FPGA Design Services
>
> http://www.dspia.com

>From page 26 of :

http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_3/Whats_New=
_PlanAhead.pdf


Adoption of Synopsys Design Constraint Tcl Infrastructure

In the 12 release, the Tcl infrastructure in PlanAhead changed to
accommodate the long-term plans for
Xilinx to migrate toward Synopsys Design Constraints (SDC) for timing
constraints.


Regards,

John McCaskill
www.FasterTechnology.com

Article: 149637
Subject: Re: Design chaos
From: John Adair <g1@enterpoint.co.uk>
Date: Fri, 12 Nov 2010 10:42:20 -0800 (PST)
Links: << >>  << T >>  << A >>
Do your modules operate using different clocks? If so you may have
clock boundary crossing problems.

John Adair
Enterpoint Ltd. - Home of Drigmorn3. The Spartan-6 Development Board.


On Nov 12, 12:54=A0pm, "sridar" <srisridar@n_o_s_p_a_m.gmail.com> wrote:
> Hi all,
>
> I am working on a design, where there are n modules. Each module is
> connected with next module in sequential fashion.
>
> like, =A0data generator -> encoder 1 -> encoder 2-> modulator -> demodula=
tor
> -> decoder2 -> decoder1
>
> The output of decoder1 should be same as data generator. I have tested ea=
ch
> module in FPGA =A0and also the following configurations
>
> data generator -> encoder 1 -> encoder 2-> =A0decoder2 ->decoder1 =A0 =A0=
 =A0 =A0 =A0 =A0
> =A0 ----------Works fine
>
> data generator -> encoder 2 -> =A0modulator -> demodulator =A0-> decoder2=
 =A0 =A0 =A0
> =A0----------Works fine
>
> But, when I integrate the all the modules, the design is not working as
> expected. I need to reset the board for 5,6 times for the output to come
> correctly. The timing analyzer reported no error.
>
> BTW, I designed all the modules using VHDL in ISE 12.3 and tried in two
> hardware boards 1. Spartan-6 sp601 kit =A02. Spartan-3 based baord
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com


Article: 149638
Subject: Re: cool BGA pattern
From: 2cents <web@sharonmccormack.com>
Date: Fri, 12 Nov 2010 10:47:52 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 12, 6:03=A0pm, John McCaskill <jhmccask...@gmail.com> wrote:
> On Nov 12, 11:22=A0am, Muzaffer Kal <k...@dspia.com> wrote:
>
>
>
>
>
> > On Fri, 12 Nov 2010 08:23:02 -0800 (PST), 2cents
>
> > <w...@sharonmccormack.com> wrote:
> > >On Nov 12, 3:06=A0pm, Jeroen Belleman <jer...@nospam.please> wrote:
> > >> 2cents wrote:
> > >> > On Nov 11, 3:03 pm, John Larkin
> > >> > [...]
> > >> >> [1] We're migrating away from Xilinx. Great silicon, insanely bro=
ken
> > >> >> software.
>
> > >> > I wouldn't rush a decision like that - especially when I know from=
 a
> > >> > very good source that there is a major effort underway to improve =
the
> > >> > SW at Xilinx.
> > >> > I hear there is a upcoming version of the SW that will be a big st=
ep
> > >> > forward in terms of quality, speed, etc. So might be worth waiting=
 a
> > >> > while, especially if you are familiar with the silicon already.
>
> > >> Do you still believe in Father Christmas and the Easter Bunny too?
>
> > >> Jeroen Belleman
>
> > >It's easy to be dismissive - but believe it or not, Xilinx has been
> > >doing something about customer complaints regarding the SW tools.
> > >They have been working on the problem for a number of years. Have you
> > >seen PlanAhead? That's a taste of things to come, or so I'm told.
>
> > Planahead is a tool which they've acquired. If the same group is
> > developing ISE 13, it would probably be an good improvement. The main
> > problem with the tools is timing engine and constraint management. If
> > the timing engine under trace & par is replaced with something which
> > supports SDC that would solve most of the problems are having.
> > --
> > Muzaffer Kal
>
> > DSPIA INC.
> > ASIC/FPGA Design Services
>
> >http://www.dspia.com
>
> From page 26 of :
>
> http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_3/Wha...
>
> Adoption of Synopsys Design Constraint Tcl Infrastructure
>
> In the 12 release, the Tcl infrastructure in PlanAhead changed to
> accommodate the long-term plans for
> Xilinx to migrate toward Synopsys Design Constraints (SDC) for timing
> constraints.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

I guess we can say "There is a Father Christmas after all ....."
I think we'll all be much happier with ISE 13. Big companies can do
great things when motivated, and from what I hear, Xilinx are very
motivated in this area.

Article: 149639
Subject: Re: cool BGA pattern
From: d_s_klein <d_s_klein@yahoo.com>
Date: Fri, 12 Nov 2010 14:20:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 12, 6:19=A0am, 2cents <w...@sharonmccormack.com> wrote:
>
> I wouldn't rush a decision like that - especially when I know from a
> very good source that there is a major effort underway to improve the
> SW at Xilinx.
> I hear there is a upcoming version of the SW that will be a big step
> forward in terms of quality, speed, etc. So might be worth waiting a
> while, especially if you are familiar with the silicon already.

This grumpy old man says "Harrumph".

Version 11 was NOT an improvement from version 10.  I know of at least
one design that works "just fine" when built with ISE-10, and fails to
run with ISE-12.

Version 12 is NOT an improvement over version 11.  My current project
works "just fine" with ISE-11, but ISE-12 fails to build a bit-stream.

After two steps backward like this, I find your claim hard to believe.

For what it's worth:  I find it to be about the same level of
difficulty to switch ISE<->Quartus as I find it to switch ISE-(n)<-
>ISE-(n+1).  And (with very few exceptions) by the time you get a
feature out of Coregen/Megawizard, they all look the same.

Back to the OP's original topic:  Yeah, these new packages are tough.
Good thing itty-bitty ceramics come in large values, and thank the
heavens for 'via in pad'.

RK



Article: 149640
Subject: Re: cool BGA pattern
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 12 Nov 2010 15:27:27 -0800
Links: << >>  << T >>  << A >>
On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein
<d_s_klein@yahoo.com> wrote:

>On Nov 12, 6:19†am, 2cents <w...@sharonmccormack.com> wrote:
>>
>> I wouldn't rush a decision like that - especially when I know from a
>> very good source that there is a major effort underway to improve the
>> SW at Xilinx.
>> I hear there is a upcoming version of the SW that will be a big step
>> forward in terms of quality, speed, etc. So might be worth waiting a
>> while, especially if you are familiar with the silicon already.
>
>This grumpy old man says "Harrumph".
>
>Version 11 was NOT an improvement from version 10.  I know of at least
>one design that works "just fine" when built with ISE-10, and fails to
>run with ISE-12.
>
>Version 12 is NOT an improvement over version 11.  My current project
>works "just fine" with ISE-11, but ISE-12 fails to build a bit-stream.
>
>After two steps backward like this, I find your claim hard to believe.
>
>For what it's worth:  I find it to be about the same level of
>difficulty to switch ISE<->Quartus as I find it to switch ISE-(n)<-
>>ISE-(n+1).  And (with very few exceptions) by the time you get a
>feature out of Coregen/Megawizard, they all look the same.
>
>Back to the OP's original topic:  Yeah, these new packages are tough.
>Good thing itty-bitty ceramics come in large values, and thank the
>heavens for 'via in pad'.

We just splatter a few 0603 caps on the top side of the board, far
enough from the FPGA that production can get their little optical
inspection gidget in there. Works fine.

Is via in pad safe? Is solder slurping a serious issue? I'd sure like
to eliminate those dogbone things.

John


Article: 149641
Subject: Re: cool BGA pattern
From: "krw@att.bizzzzzzzzzzzz" <krw@att.bizzzzzzzzzzzz>
Date: Fri, 12 Nov 2010 19:13:06 -0600
Links: << >>  << T >>  << A >>
On Fri, 12 Nov 2010 05:54:03 -0800 (PST), Gabor <gabor@alacron.com> wrote:

>On Nov 11, 6:34†pm, "k...@att.bizzzzzzzzzzzz"
><k...@att.bizzzzzzzzzzzz> wrote:
>> On Thu, 11 Nov 2010 07:03:29 -0800, John Larkin
>>
>>
>>
>> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>> >On Thu, 11 Nov 2010 08:45:56 -0000, "Michael Kellett"
>> ><nos...@nospam.com> wrote:
>>
>> >>"John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in message
>> >>news:iq5jd6t8vpelg53n1e1e5hdkqs7f0deu90@4ax.com...
>>
>> >>>http://www.theregister.co.uk/2010/11/09/marvell_armada_xp_arm_chip/
>>
>> >>> All that beautiful room for vias.
>>
>> >>> John
>>
>> >>Very nice (the pattern - I don't have any use for the chip !). I wish more
>> >>semi compnaies would think a bit more about the cost of using BGAs before
>> >>connecting evey possible ball.
>>
>> >>Michael Kellett
>>
>> >The Altera chip we're going to use [1] is a solid rectangle of balls.
>> >Yuk.
>>
>> They're not all that bad. †Most of the center are power/ground so easier to
>> wire. †The problem is that without the doughnut hole there is no convenient
>> place to put decoupling and terminators (on the back). †The coarse pitched
>> parts (1mm and .8mm) aren't hard to fan out, either. †We're stuck with them
>> because of our SMT process anyway. †My problem is that no one makes
>> low-pincount parts with a coarse pitch. †They insist on .5 or even .4mm!
>>
>> >John
>>
>> >[1] We're migrating away from Xilinx. Great silicon, insanely broken
>> >software.
>>
>> I didn't have a lot of problems with Xilinx, other than it constantly wanted
>> to rebuild my libraries in a new location. †I like Altera's software much
>> better, though.
>
>
>There's a HUGE difference in package design for consumer products like
>mass-market microprocessors and PC chip sets, and embedded products
>like FPGA's and microcontrollers.  For the consumer stuff the overall
>package size isn't as important as the ability to lay out the circuit
>on
>as few layers as possible. 

Nonsense.  There are many places where large packages aren't useful.  Think:
cell phones.  

>For embedded components its ALL about
>package size.  The boards just keep getting smaller (look at cell
>phones).

Cell phones aren't "consumer stuff"?  You're confused.

>On a board the size of a PC motherboard, you don't want 12 layers, or
>fine pitch routing, or blind vias...  Much better to have a 12-layer
>BGA substrate that brings out signals to 1.27mm spaced pads in
>an order that matches the surrounding chips so that the entire bus
>routes
>in one or two layers.  But you can clearly see that these BGA packages
>are significantly larger than the silicon devices they support.

>On a cell phone sized board adding a couple layers or using blind
>vias or microvias won't increase the product price significantly.  But
>having a chip that takes up the entire board would be a design
>killer.

I have no idea what you're talking about.  You have it all inside out.  

Article: 149642
Subject: Re: Spartan3 bidirectional 3.3V 5V level shifter
From: Allan Herriman <allanherriman@hotmail.com>
Date: 13 Nov 2010 02:05:23 GMT
Links: << >>  << T >>  << A >>
On Fri, 12 Nov 2010 04:02:20 -0800, Socrates wrote:

> On Nov 11, 4:45 pm, "noob13"
> <matija.draganovic@n_o_s_p_a_m.hotmail.com> wrote:
>> Hi,
>>
>> I'm developing a certain controller using Spartan3 FPGA. Since I have
>> to communicate with another circuit that is using 5V signaling (similar
>> to TTL, but HV level is above 3.5V) I was wondering if someone could
>> recommend a good solution in a form of a "level shifter" circuit (I
>> searched the internet and found a few ICs that could do the job.
>> However, I could use a good recomendation though :) ).
>>
>> Tnx in advance..
> 
> I use SN74LVC8T245, which can be used to interface any voltage bus
> (either 3.3V <-> 5V or 3.3V <-> 1.8V possible afaik). There are two
> separate power pins for buffer sides: VccA and VccB. However, You will
> need to switch direction pin for full IO. Also I had other part ADM3304
> afaik, can't remember exactly, but I am sure it was ADMxxxx.

I used a 74ALVC164245 on my last project, which also has two supplies and 
direction inputs.  The OP should look for parts with numbers matching the 
patters 74xxx3245 and 74xxx4245.

One must read the datasheet carefully as some parts have restrictions on 
supply sequencing, yet others (with almost identical part numbers) don't 
have such restrictions.

Regards,
Allan

Article: 149643
Subject: Re: Spartan3 bidirectional 3.3V 5V level shifter
From: "AMDyer@gmail.com" <amdyer@gmail.com>
Date: Fri, 12 Nov 2010 18:57:04 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 11, 8:45=A0am, "noob13"
<matija.draganovic@n_o_s_p_a_m.hotmail.com> wrote:
> Hi,
>
> I'm developing a certain controller using Spartan3 FPGA. Since I have to
> communicate with another circuit that is using 5V signaling (similar to
> TTL, but HV level is above 3.5V) I was wondering if someone could recomme=
nd
> a good solution in a form of a "level shifter" circuit (I searched the
> internet and found a few ICs that could do the job. However, I could use =
a
> good recomendation though :) ).
>

check out the TI TXB0102 and other parts in the series.  They're very
versatile covering a lot of voltage levels, no need to deal with
direction like on the 74LVC8T245 and similar parts.  They have good
ESD protection, support powering down one side without loading down
the other, and come in microscopic packages if you need that sort of
thing.  There is also a TXS010x series that is similar, but used for
open-drain type interfaces like I2C.

Article: 149644
Subject: Re: Design chaos
From: Newman <newman5382@yahoo.com>
Date: Fri, 12 Nov 2010 19:11:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 12, 7:54=A0am, "sridar" <srisridar@n_o_s_p_a_m.gmail.com> wrote:
> Hi all,
>
> I am working on a design, where there are n modules. Each module is
> connected with next module in sequential fashion.
>
> like, =A0data generator -> encoder 1 -> encoder 2-> modulator -> demodula=
tor
> -> decoder2 -> decoder1
>
> The output of decoder1 should be same as data generator. I have tested ea=
ch
> module in FPGA =A0and also the following configurations
>
> data generator -> encoder 1 -> encoder 2-> =A0decoder2 ->decoder1 =A0 =A0=
 =A0 =A0 =A0 =A0
> =A0 ----------Works fine
>
> data generator -> encoder 2 -> =A0modulator -> demodulator =A0-> decoder2=
 =A0 =A0 =A0
> =A0----------Works fine
>
> But, when I integrate the all the modules, the design is not working as
> expected. I need to reset the board for 5,6 times for the output to come
> correctly. The timing analyzer reported no error.
>
> BTW, I designed all the modules using VHDL in ISE 12.3 and tried in two
> hardware boards 1. Spartan-6 sp601 kit =A02. Spartan-3 based baord
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com
How about an occasional bit error between the modulator and
demodulator causes the decoder1 to get lost where as decoder2 is more
robust.

Article: 149645
Subject: Re: cool BGA pattern
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Nov 2010 20:11:09 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 12, 6:27=A0pm, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein
>
> >Back to the OP's original topic: =A0Yeah, these new packages are tough.
> >Good thing itty-bitty ceramics come in large values, and thank the
> >heavens for 'via in pad'.
>
> We just splatter a few 0603 caps on the top side of the board, far
> enough from the FPGA that production can get their little optical
> inspection gidget in there. Works fine.
>
> Is via in pad safe? Is solder slurping a serious issue? I'd sure like
> to eliminate those dogbone things.
>
> John

No first hand experience, but I'm told if the vias are plated shut
there is no solder slurping.

More interesting to me is the decoupling capacitor issue.  I took a
class on high speed digital design once and the instructor claimed
decoupling caps do not need to be as close as possible to the chip to
be effective when power and ground planes are used.  In essence the
planes provide the current the chip needs as the wave front propagates
to the cap.  Certainly the trace from the via to the cap should be as
short as possible.  I believe that is what you are saying works for
your dense BGAs.

He did also make a case for using multiple values of caps to minimize
resonances in the power decoupling circuits.  BTW, he didn't just hand
wave this stuff.  Everything he told us in class was analyzed in
theory, simulated in software and then tested in hardware.  Lee
Ritchey of Speeding Edge consultants.

Rick

Article: 149646
Subject: Re: cool BGA pattern
From: rickman <gnuarm@gmail.com>
Date: Fri, 12 Nov 2010 20:14:35 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 12, 6:27 pm, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein
>
> >Back to the OP's original topic:  Yeah, these new packages are tough.
> >Good thing itty-bitty ceramics come in large values, and thank the
> >heavens for 'via in pad'.
>
> We just splatter a few 0603 caps on the top side of the board, far
> enough from the FPGA that production can get their little optical
> inspection gidget in there. Works fine.
>
> Is via in pad safe? Is solder slurping a serious issue? I'd sure like
> to eliminate those dogbone things.
>
> John

No first hand experience, but I'm told if the vias are plated shut
there is no solder slurping.

More interesting to me is the decoupling capacitor issue.  I took a
class on high speed digital design once and the instructor claimed
decoupling caps do not need to be as close as possible to the chip to
be effective when power and ground planes are used.  In essence the
planes provide the current the chip needs as the wave front propagates
to the cap.  Certainly the trace from the via to the cap should be as
short as possible.  I believe that is what you are saying works for
your dense BGAs.

He did also make a case for using multiple values of caps to minimize
resonances in the power decoupling circuits.  BTW, he didn't just hand
wave this stuff.  Everything he told us in class was analyzed in
theory, simulated in software and then tested in hardware.  Lee
Ritchey of Speeding Edge consultants.

Rick

Article: 149647
Subject: Re: cool BGA pattern
From: Rob <nothear@nowhere.com>
Date: Fri, 12 Nov 2010 23:47:51 -0500
Links: << >>  << T >>  << A >>
On 11/12/2010 6:27 PM, John Larkin wrote:
> On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein
> <d_s_klein@yahoo.com>  wrote:
>
>> On Nov 12, 6:19 am, 2cents<w...@sharonmccormack.com>  wrote:
>>>
>>> I wouldn't rush a decision like that - especially when I know from a
>>> very good source that there is a major effort underway to improve the
>>> SW at Xilinx.
>>> I hear there is a upcoming version of the SW that will be a big step
>>> forward in terms of quality, speed, etc. So might be worth waiting a
>>> while, especially if you are familiar with the silicon already.
>>
>> This grumpy old man says "Harrumph".
>>
>> Version 11 was NOT an improvement from version 10.  I know of at least
>> one design that works "just fine" when built with ISE-10, and fails to
>> run with ISE-12.
>>
>> Version 12 is NOT an improvement over version 11.  My current project
>> works "just fine" with ISE-11, but ISE-12 fails to build a bit-stream.
>>
>> After two steps backward like this, I find your claim hard to believe.
>>
>> For what it's worth:  I find it to be about the same level of
>> difficulty to switch ISE<->Quartus as I find it to switch ISE-(n)<-
>>> ISE-(n+1).  And (with very few exceptions) by the time you get a
>> feature out of Coregen/Megawizard, they all look the same.
>>
>> Back to the OP's original topic:  Yeah, these new packages are tough.
>> Good thing itty-bitty ceramics come in large values, and thank the
>> heavens for 'via in pad'.
>
> We just splatter a few 0603 caps on the top side of the board, far
> enough from the FPGA that production can get their little optical
> inspection gidget in there. Works fine.
>
> Is via in pad safe? Is solder slurping a serious issue? I'd sure like
> to eliminate those dogbone things.
>
> John
>

I've used via-in-pad (for fine pitch bga's you really don't have many 
choices) and haven't had a problem as long as you adhere to the 
guidelines and choose your fabricator and assembler wisely.

Here is a nice white paper done by a fabricator we often use.

http://www.sanmina-sci.com/Solutions/pdfs/pcbres/Impact_of_Microvia-in-pad_Design_on_Void_Formation.pdf








Article: 149648
Subject: Re: cool BGA pattern
From: TheGlimmerMan <justaglimmer@thebarattheendoftheuniverse.org>
Date: Fri, 12 Nov 2010 20:51:41 -0800
Links: << >>  << T >>  << A >>
On Fri, 12 Nov 2010 20:14:35 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:

>No first hand experience, but I'm told if the vias are plated shut
>there is no solder slurping.


  Duh.  Basic capillary attraction is the engine, so if the capillary is
already filled, there will be no (less) attraction.

Article: 149649
Subject: Re: cool BGA pattern
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Fri, 12 Nov 2010 21:29:57 -0800
Links: << >>  << T >>  << A >>
On Fri, 12 Nov 2010 20:11:09 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:

>On Nov 12, 6:27†pm, John Larkin
><jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>> On Fri, 12 Nov 2010 14:20:19 -0800 (PST), d_s_klein
>>
>> >Back to the OP's original topic: †Yeah, these new packages are tough.
>> >Good thing itty-bitty ceramics come in large values, and thank the
>> >heavens for 'via in pad'.
>>
>> We just splatter a few 0603 caps on the top side of the board, far
>> enough from the FPGA that production can get their little optical
>> inspection gidget in there. Works fine.
>>
>> Is via in pad safe? Is solder slurping a serious issue? I'd sure like
>> to eliminate those dogbone things.
>>
>> John
>
>No first hand experience, but I'm told if the vias are plated shut
>there is no solder slurping.
>
>More interesting to me is the decoupling capacitor issue.  I took a
>class on high speed digital design once and the instructor claimed
>decoupling caps do not need to be as close as possible to the chip to
>be effective when power and ground planes are used.  In essence the
>planes provide the current the chip needs as the wave front propagates
>to the cap.  Certainly the trace from the via to the cap should be as
>short as possible.  I believe that is what you are saying works for
>your dense BGAs.

Right. The plane sandwich is a great high-speed bypassing system. It
needs help at lower frequencies, which is what the caps do. The caps
don't need to be especially close the the FPGA.

I know one guy who doesn't use bypass caps at all, and his stuff
works.

>
>He did also make a case for using multiple values of caps to minimize
>resonances in the power decoupling circuits.  BTW, he didn't just hand
>wave this stuff.  Everything he told us in class was analyzed in
>theory, simulated in software and then tested in hardware.  Lee
>Ritchey of Speeding Edge consultants.

I do a lot of TDR testing on board traces and planes. 

Simulation is OK if you can model the planes accurately. A lot of what
I've seen doesn't. All I use is 0.33 uF 0603s, a few per FPGA per
supply voltage. And every board has worked fine so far, including
digital delay generators that pass a signal in/out of an FPGA three or
four times and pick up under 30 ps RMS jitter.


John




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