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 150625

Article: 150625
Subject: Re: ISE 12.4
From: "Steve Ravet" <steve.ravet@arm.com>
Date: Fri, 28 Jan 2011 09:45:00 -0600
Links: << >>  << T >>  << A >>
Thanks for the suggestions Michael.

The point is that when ISE runs out of disk space it does not, in my 
experience, say "no space available on device" or something like that.  It 
usually says something like "internal error".

--steve

"Michael" <michael_laajanen@yahoo.com> wrote in message 
news:8qe1ohF3lmU1@mid.individual.net...
> Dont top post on Usenet. http://www.caliburn.nl/topposting.html
>
> Then you should have a better control of your server I think and keep 
> track of usage per day or so.
>
> There are tools that can monitor diskuage and alert when you are reaching 
> a critical level.



Article: 150626
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: Mike Perkins <spam@spam.com>
Date: Fri, 28 Jan 2011 15:49:49 +0000
Links: << >>  << T >>  << A >>
On 26/01/2011 12:52, Nial Stewart wrote:
>> With a sync reset, if it meets timing, it should run ok.
>
>
> I have had it confirmed that if you generate a reset synchronously then use it
> 'asynchronously' in the standard process template (VHDL) that Quartus knows it's
> a synchronous signal and all timing analysis is correctly handled.
>
>
> Nial.
>
>

Rick is correct, where generic code loses its portability, and not all 
devices or manufacturers may have this property.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 150627
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: Mike Perkins <spam@spam.com>
Date: Fri, 28 Jan 2011 16:11:07 +0000
Links: << >>  << T >>  << A >>
On 26/01/2011 14:09, Emanuele83 wrote:
> On Jan 26, 8:45 am, Emanuele83<emanuele83katam...@googlemail.com>
> wrote:
>> On Jan 26, 6:44 am, rickman<gnu...@gmail.com>  wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Jan 25, 9:48 am, n...@puntnl.niks (Nico Coesel) wrote:
>>
>>>> Emanuele83<emanuele83katam...@googlemail.com>  wrote:
>>>>> Good day to everybody,
>>
>>>>> Chipscope core to debug my modifications, the design was no more able
>>>>> to perform correct operations nor to communicate with some external
>>>>> chips creating corrupted data. Even if ALL the constraints at 40MHz
>>
>>>> IMHO this is a problem with unconstrained paths. Did you constrain
>>>> input to ff and ff to output paths? Did you constrain paths between
>>>> unrelated clock domains?
>>
>>>>> Some info:
>>>>> 1_I have no possibility to check if the FPGA HW is broken or not. X-
>>>>> ray or what else. I just wait for a new board which should be backed
>>>>> carefully
>>>>> 2_I have no chances to perform post route simulations for the whole
>>>>> project (I am in a hurry) and with my old design I did not do it
>>>>> (SPARTAN 2) and everything was perfectly working (also without setting
>>>>> any constraint over PERIOD or OFFSET)
>>>>> 3_I have 3 boards, when I program them with the same bitstream they
>>>>> behave sometimes differently.
>>
>>>> This may be due to FPGA variations. I'd get the constraints sorted out
>>>> first. Perhaps you could buy a development board and verify your
>>>> design on that so you have a proper reference.
>>
>>> That is one of the things I have always felt was lacking, a way to
>>> verify timing constraints.  I've talked to FPGA vendors and their
>>> attitude is just that an engineer should be able to write the
>>> constraints correctly, period.  No need to verify!  Boy, that goes
>>> against everything I've ever learned about engineering.  You can have
>>> problems with ANY part of a design.  Being able to verify all aspects
>>> of your design is much better than "testing".  Testing can prove the
>>> existence of faults, but it can't prove the absence... at least not
>>> without a LOT of effort and analysis.  In fact, testing is a lot like
>>> constraints, you have to do it "right" and how do you prove that you
>>> have done the testing "right"?
>>
>>> Rick
>>
>> Holy words, fellow, holy words! :) We use more time to writing the
>> correct test (that must be done carefully) than to design the logic...
>>
>> I am going to test the power supply section, but I've already tested
>> yesterday that compiling the same code, setting the drive strength of
>> I/Os to a safer value (from 6 to 2) the behaviour of the system is no
>> more consistent. I left all the timing constraints unchanged, always
>> met, @40Mhz speed, but it does not work....
>
>
> 1_ I checked the power supply of the board. I fixed some minor stuff,
> and I checked the layout. My colleague has forgot to split the power
> plan for VCCAUX and VCC_0 so I thought that maybe the noise introduced
> by switching I/Os on the VCCAUX could create problems with the DCMs
> that I was using. take a look to the clock architecture:
>
> http://forums.xilinx.com/xlnx/attachments/xlnx/Spartan/8738/1/dcm_arch.jpg
>
> this was the one at the very beginning (at 80MHz) and now I changed
> using the same DCM structure but with 40MHz (output of first DCM is
> not clk_2x anymore) and everything now works with 40Mhz.
> The second DCM has the only purpose to deskew the RAM chips (which
> work at 40MHz now)
>
> Thinking that the problem was on DCM's noisy power supply I just
> removed the DCM and bypassed the 40 MHz clock input directly to the
> ram output, the external feedback is no more used and the logic is
> clocked directly with the external clock.
> it seems better, but if I change the compiling settings (optimizing
> for area and not for speed for example) the system does not work...
> The design seems less affected from the settings modifications but it
> is not yet stable, and the goal of 80Mhz is still far away :(
>
> 2_ I find sometimes this WARNING in the map log:
> Pack:266 - The function generator inst_arbiter_core/hist_box_ch_0/
> state_m_1_FSM_Out21 failed to merge with F5 multiplexer
> inst_arbiter_core/hist_box_ch_0/i_FSM_FFd2-In21_f5.  There is a
> conflict for the FXMUX.  The design will exhibit suboptimal timing.
> I am not able to link it to the abnormal behaviour yet, but i found no
> explanation in the Xilinx website. Does somebody know something about
> it?
> I usually use some VARIABLES in my processes, also in the state
> machine which gives the PACK:266 error. they are not SHARED VARIABLES
> and are modified only synchronously, but sometimes i use them as a
> trick to save some clock cycles of latency (implementing real
> instantaneous assignments). Is a practice that should be avoided in a
> good VHDL code?
>
>
> Thanks,
> Emanuele

If the power supply is marginal in terms of noise, it may be worth 
fixing the location of the DCM to a site on a quieter side of the FPGA. 
  It is something I've had to do when decoupling was not ideal, where 
different compilations gave very different results similar to your 
experience.

Have you looked at the 80MHz output pin using a 'scope?  Is it clean?

When interfacing the logic from your "Rest of Logic" to the "Ext 40MHz 
chip", how are you qualifying which edge of the 80 MHz clock the data 
changes on?

I don't see any issue with using variables, shared or otherwise.  I 
would have thought synthesis would take out common logic where it feels 
it can.  One consequence of using variables in the manner you describe 
would be more levels of logic, leading to a slower design.  If timing 
constraints are set correctly, then this ought not be an issue.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 150628
Subject: Re: Simple clock question
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 28 Jan 2011 15:06:15 -0600
Links: << >>  << T >>  << A >>
On 01/27/2011 09:12 PM, KK6GM wrote:
> Newb question: suppose I want to create a shift register that's
> clocked from an external source (like an SPI slave device).  My
> impression (correct me if I'm confused) is that if the external clock
> is slow WRT some other clock on the FPGA (e.g. a 1MHz external clock
> and a 50MHz fast clock), I can sync both clock and data to the fast
> clock and proceed from there, using the fast clock along with an edge
> detected signal for further processing.  The fast clock is mapped to
> low-skew clock lines which are designed for the purpose, so things are
> good.
>
> But what if the clock is not slow WRT the fast clock?  What if the
> external clock is too fast to reliably sync with the fast clock?  e.g.
> a 20MHz clock and a 50MHz fast clock.  In that case it seems that the
> external clock needs to be used directly, but won't there be potential
> clock skew problems using a regular input as a clock?  I'd appreciate
> insight on how such problems are dealt with, if indeed they are even
> problems at all.
That's why Xilinx provides multiple low-skew clock nets on their FPGAs.
In some cases it is necessary to run significant amounts of logic from 
different clocks, and then have some synchronizing mechanism somewhere 
in the middle.  That can be hard or easy, depending on a number of 
circumstances.

Jon

Article: 150629
Subject: Re: Simple clock question
From: "jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Fri, 28 Jan 2011 15:44:18 -0600
Links: << >>  << T >>  << A >>

>
>When it happens that a design really needs some clock routed trough
>ordinary routing ressources, the problems you mentioned apply.
>So the designer has to make sure that the net stays as small as
>possible, and tries to controll it with tight timing constraints.
>

This is where the ability the lock flops into place and hand route is
handy.

Shift registers on high skew clocks are always dicey because you don't have
any next state logic to help ensure that you meet hold time requirements so
you might get "shoot through". Some things that you can try:


1) Counter flow your clock.  Route the clock to the very last flop in the
chain and then from there go to the next to last until you get to the first
flop. That way you are always sending data to a flop on an earlier clock
and that delay helps meet hold time.

2) Split your clock in two.  Create a clock and clock_n and double the
number of flops in the chain. Alternate clocks on the chain with the rising
one going to the input flop that then feeds a falling clock flop. 


	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 150630
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: comp arch <comparchfpga@gmail.com>
Date: Sat, 29 Jan 2011 04:48:15 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 27, 7:42=A0am, Emanuele83 <emanuele83katam...@googlemail.com>
wrote:
> all the I/Os are constrained.
>
> the point is:
> same VHDL code+same constrains --> changing synthesis/mapping/PAR options=
 --> CONSTRAINTS ALWAYS MET @40MHz --> the behaviour changes.
>
>
>
>
>
> >In general computers do what they are told not what you expect them to
> do.
>
> Exactly what I do with my code that has been simulated and the algorithm =
results correct.

It is very unlikely that if you have constraints on the design (and it
sounds like you have), that the behaviour changes from run to run, and
that the reason is the implementation tool's fault.
It sounds like an asynchronous/clock domain issue. Do you have more
than one clock in the design? How are all crossings handled? Are any
of the external inputs/internal signals async to the clock at all?

As for process size - the tools themselves have no limitations in this
regard - other posters were only pointing out that for the engineer to
be able to keep a clear idea in his head, and to be able to quickly
visually verify that a process is correct, it helps to keep the code
split up into smaller more functional processes. It's not required,
but it makes the engineers life at design time, and for any later
modifications much easier. This is what was meant my maintainability.
Splitting a process up does not necessarily add latency - in fact, it
can help you discover and separate the more critical parts.
In a way it is like doing a schematic, it helps to know logically how
it should be separated in a schematic, and then code that.

good luck

Article: 150631
Subject: Re: Verilog Book for VHDL Users
From: rickman <gnuarm@gmail.com>
Date: Sat, 29 Jan 2011 11:57:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 16, 4:36 pm, Mike Treseler <mtrese...@gmail.com> wrote:
> On 1/15/2011 12:09 PM, rickman wrote:
>
> > This is starting to sound like VHDL...!  I don't mind being explicit.
> > It is just that in VHDL it can get rather confusing as to what you
> > need to be explicit about or how exactly to be explicit.
>
> > I find it hard to believe that there are no good texts on this.
>
> It is true.
> I found this one slightly useful:http://www.google.com/search?q=botros+isbn+1584508558
>
> It's the only book of side by side vhdl|verilog examples in print.
> But that is all it is -- simple synthesis examples and a short
> explanation. No language reference or simulation examples.
> But it's a quick way for a vhdl guy to get started
> on verilog synthesis, and the price is right.
>
>         -- Mike Treseler

Why do you say this is the "only" text?  I know of at least two others
that cover both VHDL and Verilog.  One is Ben Cohen's book, "Real Chip
Design and Verification Using Verilog and VHDL".  The other I have,
Douglas J. Smith, "HDL Chip Design".  The Smith book has side by side
examples of both like you describe for the Botros book, but I can't
say about the Cohen book since I haven't seen it.

I will say this is the only affordable one of the three.  The other
two are $167 and $135!  Thats just too rich for my blood.

Rick

Article: 150632
Subject: Discrete time PID control
From: "Andrew Holme" <ah@nospam.com>
Date: Sun, 30 Jan 2011 17:53:06 -0000
Links: << >>  << T >>  << A >>
I've implemented a DSSS receiver in an FPGA.  The code rate NCO is 
controlled by an early/late detector.  The carrier NCO is controlled by a 
Costas Loop.  I chose PI gain constants for the control loops by trial and 
error but would like to do it more scientifically by analysing stability 
using a Bode plot of open loop gain.  I always do it this way for analogue 
PLLs; but I'm new to z-domain stability analysis.

TimW - I bought your book; but, to be honest, found it quite heavy going. 
Nevertheless, adapting some code from the accompanying CD, I came up with 
this Scilab script:

kPD = 2^20;
kP = 2^(41-64);
kI = 2^(15-64);
kNCO = 10000;
G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1);
G.dt = 1e-3;
scf(0);
clf;
bode(G);

The resulting Bode plot never even passes through unity gain!  So is the 
system unconditionally stable?  Here's a simplified version of the FPGA 
code:

`define KP 41
`define KI 15

reg [63:0] phase, rate; // 64 places after the binary point
reg signed [31:0] err; // = Early - Late

always @ (posedge clk) // 10 MHz
    if (millisecond) begin
        phase <= phase + rate + (err << `KP);
        rate <= rate + (err << `KI);
    end else
        phase <= phase + rate;

It clocks at 10 MHz and applies corrections every millisecond; hence dt=1e-3 
and kNCO = 10000.

Is the Bode plot correct?

TIA



Article: 150633
Subject: Re: Discrete time PID control
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sun, 30 Jan 2011 10:02:40 -0800
Links: << >>  << T >>  << A >>
On Sun, 30 Jan 2011 17:53:06 -0000, "Andrew Holme" <ah@nospam.com>
wrote:

>I've implemented a DSSS receiver in an FPGA.  The code rate NCO is 
>controlled by an early/late detector.  The carrier NCO is controlled by a 
>Costas Loop.  I chose PI gain constants for the control loops by trial and 
>error but would like to do it more scientifically by analysing stability 
>using a Bode plot of open loop gain.  I always do it this way for analogue 
>PLLs; but I'm new to z-domain stability analysis.
>
>TimW - I bought your book; but, to be honest, found it quite heavy going. 
>Nevertheless, adapting some code from the accompanying CD, I came up with 
>this Scilab script:
>
>kPD = 2^20;
>kP = 2^(41-64);
>kI = 2^(15-64);
>kNCO = 10000;
>G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1);
>G.dt = 1e-3;
>scf(0);
>clf;
>bode(G);
>
>The resulting Bode plot never even passes through unity gain!  So is the 
>system unconditionally stable?  Here's a simplified version of the FPGA 
>code:
>
>`define KP 41
>`define KI 15
>
>reg [63:0] phase, rate; // 64 places after the binary point
>reg signed [31:0] err; // = Early - Late
>
>always @ (posedge clk) // 10 MHz
>    if (millisecond) begin
>        phase <= phase + rate + (err << `KP);
>        rate <= rate + (err << `KI);
>    end else
>        phase <= phase + rate;
>
>It clocks at 10 MHz and applies corrections every millisecond; hence dt=1e-3 
>and kNCO = 10000.
>
>Is the Bode plot correct?
>
>TIA
>


Is 'err' quantized to two values, early or late bang-bang style, or is
it some finer-grain time error signal? 

John


Article: 150634
Subject: Re: Discrete time PID control
From: "Andrew Holme" <ah@nospam.com>
Date: Sun, 30 Jan 2011 18:16:26 -0000
Links: << >>  << T >>  << A >>

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
news:3p9bk6tm0uqf4ol2kdbm95a3en7g8b0acn@4ax.com...
> On Sun, 30 Jan 2011 17:53:06 -0000, "Andrew Holme" <ah@nospam.com>
> wrote:
>
>>I've implemented a DSSS receiver in an FPGA.  The code rate NCO is
>>controlled by an early/late detector.  The carrier NCO is controlled by a
>>Costas Loop.  I chose PI gain constants for the control loops by trial and
>>error but would like to do it more scientifically by analysing stability
>>using a Bode plot of open loop gain.  I always do it this way for analogue
>>PLLs; but I'm new to z-domain stability analysis.
>>
>>TimW - I bought your book; but, to be honest, found it quite heavy going.
>>Nevertheless, adapting some code from the accompanying CD, I came up with
>>this Scilab script:
>>
>>kPD = 2^20;
>>kP = 2^(41-64);
>>kI = 2^(15-64);
>>kNCO = 10000;
>>G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1);
>>G.dt = 1e-3;
>>scf(0);
>>clf;
>>bode(G);
>>
>>The resulting Bode plot never even passes through unity gain!  So is the
>>system unconditionally stable?  Here's a simplified version of the FPGA
>>code:
>>
>>`define KP 41
>>`define KI 15
>>
>>reg [63:0] phase, rate; // 64 places after the binary point
>>reg signed [31:0] err; // = Early - Late
>>
>>always @ (posedge clk) // 10 MHz
>>    if (millisecond) begin
>>        phase <= phase + rate + (err << `KP);
>>        rate <= rate + (err << `KI);
>>    end else
>>        phase <= phase + rate;
>>
>>It clocks at 10 MHz and applies corrections every millisecond; hence 
>>dt=1e-3
>>and kNCO = 10000.
>>
>>Is the Bode plot correct?
>>
>>TIA
>>
>
>
> Is 'err' quantized to two values, early or late bang-bang style, or is
> it some finer-grain time error signal?
>
> John
>

err is fine-grained: approx +/- 2^20

Actually, kPD slope should be 2*(2^20) per chip.




Article: 150635
Subject: Re: Discrete time PID control
From: Tim Wescott <tim@seemywebsite.com>
Date: Sun, 30 Jan 2011 12:41:15 -0800
Links: << >>  << T >>  << A >>
On 01/30/2011 09:53 AM, Andrew Holme wrote:
> I've implemented a DSSS receiver in an FPGA.  The code rate NCO is
> controlled by an early/late detector.  The carrier NCO is controlled by a
> Costas Loop.  I chose PI gain constants for the control loops by trial and
> error but would like to do it more scientifically by analysing stability
> using a Bode plot of open loop gain.  I always do it this way for analogue
> PLLs; but I'm new to z-domain stability analysis.
>
> TimW - I bought your book; but, to be honest, found it quite heavy going.
> Nevertheless, adapting some code from the accompanying CD, I came up with
> this Scilab script:
>
> kPD = 2^20;
> kP = 2^(41-64);
> kI = 2^(15-64);
> kNCO = 10000;
> G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1);
> G.dt = 1e-3;
> scf(0);
> clf;
> bode(G);
>
> The resulting Bode plot never even passes through unity gain!  So is the
> system unconditionally stable?  Here's a simplified version of the FPGA
> code:

There's several things wrong with this -- does the loop actually work?

Your gain is HUGE -- I'm seeing nearly 60dB of gain at Fs/2, which 
should guarantee wild Fs/2 oscillations.

kP / kI is 67 million some odd, which means your integrator doesn't 
start doing anything until Fs/67000000 or so -- that's a pretty low 
frequency for an integrator to kick in.

As a minor point, you're including the subtraction in the phase 
comparator, meaning that your phase shift criterion is 0 rather than 180 
-- that's not how most folks do it, but there's a significant enough 
minority that do that I can't quibble _too_ much.

As another minor point, Scilab (and anything that uses polynomials for 
this sort of analysis) is vulnerable to numerical errors when the order 
of the system gets high.  Using

-->G = kPD * tf2ss(kP + kI / (%z - 1)) * tf2ss(kNCO / (%z - 1));

dodges this (note that I'm using my preferred sign convention).  It's 
not the issue here.

>
> `define KP 41
> `define KI 15
>
> reg [63:0] phase, rate; // 64 places after the binary point
> reg signed [31:0] err; // = Early - Late
>
> always @ (posedge clk) // 10 MHz
>      if (millisecond) begin
>          phase<= phase + rate + (err<<  `KP);
>          rate<= rate + (err<<  `KI);
>      end else
>          phase<= phase + rate;
>
> It clocks at 10 MHz and applies corrections every millisecond; hence dt=1e-3
> and kNCO = 10000.
>
> Is the Bode plot correct?

I'm not going to pick through that Verilog code for a complete model 
unless you pay me, but I know it's not matching the transfer function 
that you give.  Here's some points that I can pick out:

* If KP were 0, then phase <= phase + rate + (err << 'KP) would
   give an effective kP of 1, or if you're viewing your variables
   as fractional, then kP of 2^-32.  Not 2^-64.

* You are only applying your proportional term, and updating your
   integrator, on the millisecond intervals.  But you are applying
   your integrator state to the phase every NCO sampling interval.
   This gives your integrator an extra gain of 10MHz * 1ms.

   It would arguably be much better style (and it would certainly
   give you smoother operation) if you calculated a frequency
   increment command separately from your controller update.  You
   may not want the slowness that comes with smoothness, and you
   may not want to carry the extra storage -- which is where the
   arguing comes in.

So: kP is off by 2^-32, kI is off by 10000 * 2^-32, and the gains in 
your model are already way too high.  If things work, this makes me 
suspect that your kPD _must_ be wrong somehow (maybe it's really 2^(20-64)?)

If I make the factor of 10000 correction to kI I get an integrator zero 
at around 0.04Hz, which is not terribly unreasonable, if a bit slow. 
I'm still not getting a gain of 1 in the region of 90 degrees phase 
shift, but I'll leave that part to you.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 150636
Subject: Can't program Spartan3A with JTAG
From: aleksa <aleksazr@gmail.com>
Date: Sun, 30 Jan 2011 13:06:11 -0800 (PST)
Links: << >>  << T >>  << A >>
Impact reports something like "device not recognized" and then I point
it to the .bit file.
Reading ID / signature shows that all bits are zeros.

Using the scope I can see that all signals (TMS, TCK, TDI, TDO) change
states.
I have an old analog scope and the time period is very short (for me,
human),
but I can see that signals are valid (0 and 3V3, nothing strange
happening).

Can I make Impact talk to the fpga more often, so I can better see the
signals?
(If not, I could make a prog to toggle the port pins...)

I've used the same JTAG programming board for Spartan 2, and it works.
Spartan2, Spartan3A and parallel port JTAG boards were all done by me.

I have the PROG pin HIGH, the rest are floating.
Then I've connected M0-M2 and PUDC HIGH, but its the same.

Any thoughts?

Article: 150637
Subject: Re: Can't program Spartan3A with JTAG
From: aleksa <aleksazr@gmail.com>
Date: Sun, 30 Jan 2011 13:19:55 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 30, 10:06=A0pm, aleksa <aleks...@gmail.com> wrote:

> the rest are floating.

i.e. CCLK, DIN, CS, INIT, all clocks.
Power pins are connected :)

Article: 150638
Subject: Re: Can't program Spartan3A with JTAG
From: aleksa <aleksazr@gmail.com>
Date: Sun, 30 Jan 2011 13:51:38 -0800 (PST)
Links: << >>  << T >>  << A >>
VCCAUX is at 3V3, and constraint is in the UCF, also.

Article: 150639
Subject: Re: Can't program Spartan3A with JTAG
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Sun, 30 Jan 2011 14:31:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 30, 1:06=A0pm, aleksa <aleks...@gmail.com> wrote:
> Impact reports something like "device not recognized" and then I point
> it to the .bit file.
> Reading ID / signature shows that all bits are zeros.
>
> Using the scope I can see that all signals (TMS, TCK, TDI, TDO) change
> states.
> I have an old analog scope and the time period is very short (for me,
> human),
> but I can see that signals are valid (0 and 3V3, nothing strange
> happening).
>
> Can I make Impact talk to the fpga more often, so I can better see the
> signals?
> (If not, I could make a prog to toggle the port pins...)
>
> I've used the same JTAG programming board for Spartan 2, and it works.
> Spartan2, Spartan3A and parallel port JTAG boards were all done by me.
>
> I have the PROG pin HIGH, the rest are floating.
> Then I've connected M0-M2 and PUDC HIGH, but its the same.
>
> Any thoughts?

Having the IDCODE reported as all zeros indicates that the JTAG is
broken somewhere or the TAP controller is being held in reset.

1) You indicated the PROGRAM_B was high (was this measured?), but what
about INIT_B?
2) Have you confirm that TCK is getting to the TCK pin of the
Spartan-3A device?
3) Have you probed the TDO at the Spartan-3A device for any activity?

Ed McGettigan
--
Xilinx Inc.

Article: 150640
Subject: Re: Discrete time PID control
From: "Andrew Holme" <ah@nospam.com>
Date: Mon, 31 Jan 2011 00:19:53 -0000
Links: << >>  << T >>  << A >>

"Tim Wescott" <tim@seemywebsite.com> wrote in message 
news:D8Wdnfpn6tJmUdjQnZ2dnUVZ_gKdnZ2d@web-ster.com...
> On 01/30/2011 09:53 AM, Andrew Holme wrote:
>> I've implemented a DSSS receiver in an FPGA.  The code rate NCO is
>> controlled by an early/late detector.  The carrier NCO is controlled by a
>> Costas Loop.  I chose PI gain constants for the control loops by trial 
>> and
>> error but would like to do it more scientifically by analysing stability
>> using a Bode plot of open loop gain.  I always do it this way for 
>> analogue
>> PLLs; but I'm new to z-domain stability analysis.
>>
>> TimW - I bought your book; but, to be honest, found it quite heavy going.
>> Nevertheless, adapting some code from the accompanying CD, I came up with
>> this Scilab script:
>>
>> kPD = 2^20;
>> kP = 2^(41-64);
>> kI = 2^(15-64);
>> kNCO = 10000;
>> G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1);
>> G.dt = 1e-3;
>> scf(0);
>> clf;
>> bode(G);
>>
>> The resulting Bode plot never even passes through unity gain!  So is the
>> system unconditionally stable?  Here's a simplified version of the FPGA
>> code:
>
> There's several things wrong with this -- does the loop actually work?
>
> Your gain is HUGE -- I'm seeing nearly 60dB of gain at Fs/2, which should 
> guarantee wild Fs/2 oscillations.
>
> kP / kI is 67 million some odd, which means your integrator doesn't start 
> doing anything until Fs/67000000 or so -- that's a pretty low frequency 
> for an integrator to kick in.
>
> As a minor point, you're including the subtraction in the phase 
> comparator, meaning that your phase shift criterion is 0 rather than 
> 180 -- that's not how most folks do it, but there's a significant enough 
> minority that do that I can't quibble _too_ much.
>
> As another minor point, Scilab (and anything that uses polynomials for 
> this sort of analysis) is vulnerable to numerical errors when the order of 
> the system gets high.  Using
>
> -->G = kPD * tf2ss(kP + kI / (%z - 1)) * tf2ss(kNCO / (%z - 1));
>
> dodges this (note that I'm using my preferred sign convention).  It's not 
> the issue here.
>
>>
>> `define KP 41
>> `define KI 15
>>
>> reg [63:0] phase, rate; // 64 places after the binary point
>> reg signed [31:0] err; // = Early - Late
>>
>> always @ (posedge clk) // 10 MHz
>>      if (millisecond) begin
>>          phase<= phase + rate + (err<<  `KP);
>>          rate<= rate + (err<<  `KI);
>>      end else
>>          phase<= phase + rate;
>>
>> It clocks at 10 MHz and applies corrections every millisecond; hence 
>> dt=1e-3
>> and kNCO = 10000.
>>
>> Is the Bode plot correct?
>
> I'm not going to pick through that Verilog code for a complete model 
> unless you pay me, but I know it's not matching the transfer function that 
> you give.  Here's some points that I can pick out:
>
> * If KP were 0, then phase <= phase + rate + (err << 'KP) would
>   give an effective kP of 1, or if you're viewing your variables
>   as fractional, then kP of 2^-32.  Not 2^-64.
>
> * You are only applying your proportional term, and updating your
>   integrator, on the millisecond intervals.  But you are applying
>   your integrator state to the phase every NCO sampling interval.
>   This gives your integrator an extra gain of 10MHz * 1ms.
>
>   It would arguably be much better style (and it would certainly
>   give you smoother operation) if you calculated a frequency
>   increment command separately from your controller update.  You
>   may not want the slowness that comes with smoothness, and you
>   may not want to carry the extra storage -- which is where the
>   arguing comes in.
>
> So: kP is off by 2^-32, kI is off by 10000 * 2^-32, and the gains in your 
> model are already way too high.  If things work, this makes me suspect 
> that your kPD _must_ be wrong somehow (maybe it's really 2^(20-64)?)
>
> If I make the factor of 10000 correction to kI I get an integrator zero at 
> around 0.04Hz, which is not terribly unreasonable, if a bit slow. I'm 
> still not getting a gain of 1 in the region of 90 degrees phase shift, but 
> I'll leave that part to you.
>
> -- 
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com
>
> Do you need to implement control loops in software?
> "Applied Control Theory for Embedded Systems" was written for you.
> See details at http://www.wescottdesign.com/actfes/actfes.html


Tim, thank you.  I had applied that kNCO=10000 multiplier to both kI and kP. 
It should only be applied to kI for exactly the reason you have pointed out.

The following code is giving me a sensible looking Bode plot:

kPD = 2^20;
kP = 2^(41-64);
kI = 10000 * 2^(18-64);
G = -kPD * (kP + kI/(%z-1)) / (%z-1);
G.dt = 1e-3;
scf(0);
clf;
bode(G);

I'm using `KI=18 in the latest FPGA.  The rate was taking several seconds to 
settle.

Thanks for the free consultancy :-)    I will study the book.




Article: 150641
Subject: Re: Discrete time PID control
From: Tim Wescott <tim@seemywebsite.com>
Date: Sun, 30 Jan 2011 16:27:51 -0800
Links: << >>  << T >>  << A >>
On 01/30/2011 04:19 PM, Andrew Holme wrote:
> "Tim Wescott"<tim@seemywebsite.com>  wrote in message
> news:D8Wdnfpn6tJmUdjQnZ2dnUVZ_gKdnZ2d@web-ster.com...
>> On 01/30/2011 09:53 AM, Andrew Holme wrote:
>>> I've implemented a DSSS receiver in an FPGA.  The code rate NCO is
>>> controlled by an early/late detector.  The carrier NCO is controlled by a
>>> Costas Loop.  I chose PI gain constants for the control loops by trial
>>> and
>>> error but would like to do it more scientifically by analysing stability
>>> using a Bode plot of open loop gain.  I always do it this way for
>>> analogue
>>> PLLs; but I'm new to z-domain stability analysis.
>>>
>>> TimW - I bought your book; but, to be honest, found it quite heavy going.
>>> Nevertheless, adapting some code from the accompanying CD, I came up with
>>> this Scilab script:
>>>
>>> kPD = 2^20;
>>> kP = 2^(41-64);
>>> kI = 2^(15-64);
>>> kNCO = 10000;
>>> G = -kPD * (kP + kI/(%z-1)) * kNCO / (%z-1);
>>> G.dt = 1e-3;
>>> scf(0);
>>> clf;
>>> bode(G);
>>>
>>> The resulting Bode plot never even passes through unity gain!  So is the
>>> system unconditionally stable?  Here's a simplified version of the FPGA
>>> code:
>>
>> There's several things wrong with this -- does the loop actually work?
>>
>> Your gain is HUGE -- I'm seeing nearly 60dB of gain at Fs/2, which should
>> guarantee wild Fs/2 oscillations.
>>
>> kP / kI is 67 million some odd, which means your integrator doesn't start
>> doing anything until Fs/67000000 or so -- that's a pretty low frequency
>> for an integrator to kick in.
>>
>> As a minor point, you're including the subtraction in the phase
>> comparator, meaning that your phase shift criterion is 0 rather than
>> 180 -- that's not how most folks do it, but there's a significant enough
>> minority that do that I can't quibble _too_ much.
>>
>> As another minor point, Scilab (and anything that uses polynomials for
>> this sort of analysis) is vulnerable to numerical errors when the order of
>> the system gets high.  Using
>>
>> -->G = kPD * tf2ss(kP + kI / (%z - 1)) * tf2ss(kNCO / (%z - 1));
>>
>> dodges this (note that I'm using my preferred sign convention).  It's not
>> the issue here.
>>
>>>
>>> `define KP 41
>>> `define KI 15
>>>
>>> reg [63:0] phase, rate; // 64 places after the binary point
>>> reg signed [31:0] err; // = Early - Late
>>>
>>> always @ (posedge clk) // 10 MHz
>>>       if (millisecond) begin
>>>           phase<= phase + rate + (err<<   `KP);
>>>           rate<= rate + (err<<   `KI);
>>>       end else
>>>           phase<= phase + rate;
>>>
>>> It clocks at 10 MHz and applies corrections every millisecond; hence
>>> dt=1e-3
>>> and kNCO = 10000.
>>>
>>> Is the Bode plot correct?
>>
>> I'm not going to pick through that Verilog code for a complete model
>> unless you pay me, but I know it's not matching the transfer function that
>> you give.  Here's some points that I can pick out:
>>
>> * If KP were 0, then phase<= phase + rate + (err<<  'KP) would
>>    give an effective kP of 1, or if you're viewing your variables
>>    as fractional, then kP of 2^-32.  Not 2^-64.
>>
>> * You are only applying your proportional term, and updating your
>>    integrator, on the millisecond intervals.  But you are applying
>>    your integrator state to the phase every NCO sampling interval.
>>    This gives your integrator an extra gain of 10MHz * 1ms.
>>
>>    It would arguably be much better style (and it would certainly
>>    give you smoother operation) if you calculated a frequency
>>    increment command separately from your controller update.  You
>>    may not want the slowness that comes with smoothness, and you
>>    may not want to carry the extra storage -- which is where the
>>    arguing comes in.
>>
>> So: kP is off by 2^-32, kI is off by 10000 * 2^-32, and the gains in your
>> model are already way too high.  If things work, this makes me suspect
>> that your kPD _must_ be wrong somehow (maybe it's really 2^(20-64)?)
>>
>> If I make the factor of 10000 correction to kI I get an integrator zero at
>> around 0.04Hz, which is not terribly unreasonable, if a bit slow. I'm
>> still not getting a gain of 1 in the region of 90 degrees phase shift, but
>> I'll leave that part to you.
>>
>> --
>>
>> Tim Wescott
>> Wescott Design Services
>> http://www.wescottdesign.com
>>
>> Do you need to implement control loops in software?
>> "Applied Control Theory for Embedded Systems" was written for you.
>> See details at http://www.wescottdesign.com/actfes/actfes.html
>
>
> Tim, thank you.  I had applied that kNCO=10000 multiplier to both kI and kP.
> It should only be applied to kI for exactly the reason you have pointed out.
>
> The following code is giving me a sensible looking Bode plot:
>
> kPD = 2^20;
> kP = 2^(41-64);
> kI = 10000 * 2^(18-64);
> G = -kPD * (kP + kI/(%z-1)) / (%z-1);
> G.dt = 1e-3;
> scf(0);
> clf;
> bode(G);
>
> I'm using `KI=18 in the latest FPGA.  The rate was taking several seconds to
> settle.
>
> Thanks for the free consultancy :-)    I will study the book.

The integrator shift of 15 certainly showed in the Bode plot as being 
insufficient for fast settling.

Note that with all-digital systems like this you can often push your 
system much harder than you would if you have physical components -- you 
don't have such inconveniences as unknown dynamics or gains that change. 
  On the other hand, you have to make sure that your model really does 
match reality!!

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Article: 150642
Subject: Re: Can't program Spartan3A with JTAG
From: aleksa <aleksazr@gmail.com>
Date: Mon, 31 Jan 2011 03:00:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 30, 11:31=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Jan 30, 1:06=A0pm, aleksa <aleks...@gmail.com> wrote:
>
>
>
>
>
> > Impact reports something like "device not recognized" and then I point
> > it to the .bit file.
> > Reading ID / signature shows that all bits are zeros.
>
> > Using the scope I can see that all signals (TMS, TCK, TDI, TDO) change
> > states.
> > I have an old analog scope and the time period is very short (for me,
> > human),
> > but I can see that signals are valid (0 and 3V3, nothing strange
> > happening).
>
> > Can I make Impact talk to the fpga more often, so I can better see the
> > signals?
> > (If not, I could make a prog to toggle the port pins...)
>
> > I've used the same JTAG programming board for Spartan 2, and it works.
> > Spartan2, Spartan3A and parallel port JTAG boards were all done by me.
>
> > I have the PROG pin HIGH, the rest are floating.
> > Then I've connected M0-M2 and PUDC HIGH, but its the same.
>
> > Any thoughts?
>
> Having the IDCODE reported as all zeros indicates that the JTAG is
> broken somewhere or the TAP controller is being held in reset.
>
> 1) You indicated the PROGRAM_B was high (was this measured?), but what
> about INIT_B?
> 2) Have you confirm that TCK is getting to the TCK pin of the
> Spartan-3A device?
> 3) Have you probed the TDO at the Spartan-3A device for any activity?
>
> Ed McGettigan
> --
> Xilinx Inc.

Yes, PROG is HIGH.
INIT_B was floating. I've pulled it up now, but no change.

TDO does show activity.

I've made a prog to pulse (500 kHz) the TMS, TCK and TDI signals,
and they all get to FPGA, nice and clean.

Article: 150643
Subject: Re: Can't program Spartan3A with JTAG
From: aleksa <aleksazr@gmail.com>
Date: Mon, 31 Jan 2011 04:46:57 -0800 (PST)
Links: << >>  << T >>  << A >>
some tests I did:

1. started iMPACT.
2. double click on Boundary scan.
3. right click, Initialize Chain.

I get blue text "Identify succeeded"
The part is already shown as unknown.

I'm asked "Do you want to cont. and assign conf. files?" YES
"Do you have a BSDL or BIT file?" YES (xc3s50a.bsd)

4. Debug, Chain integrity test = OK.

Everything else fails.

Article: 150644
Subject: Xilinx tool options
From: "Roger" <rogerwilson@hotmail.com>
Date: Mon, 31 Jan 2011 14:43:52 -0000
Links: << >>  << T >>  << A >>
Is it possible to simply add the EDK (which includes the SDK) to ISE WebPack 
OR is it necessary to get the ISE Embedded suite please?

Thanks,

Rog. 


Article: 150645
Subject: Re: Can't program Spartan3A with JTAG
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 31 Jan 2011 07:25:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 31, 4:46=A0am, aleksa <aleks...@gmail.com> wrote:
> some tests I did:
>
> 1. started iMPACT.
> 2. double click on Boundary scan.
> 3. right click, Initialize Chain.
>
> I get blue text "Identify succeeded"
> The part is already shown as unknown.
>
> I'm asked "Do you want to cont. and assign conf. files?" YES
> "Do you have a BSDL or BIT file?" YES (xc3s50a.bsd)
>
> 4. Debug, Chain integrity test =3D OK.
>
> Everything else fails.

What was the IDCODE reported by iMPACT?
When you put the oscilloscope on the TDO output what voltage levels
did you see?
Is the TDO of the part connected to the TDO of the cable?
Are there any other devices in the JTAG chain?

Ed McGettigan
--
Xilinx Inc.

Article: 150646
Subject: Re: Xilinx tool options
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Mon, 31 Jan 2011 07:33:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 31, 6:43=A0am, "Roger" <rogerwil...@hotmail.com> wrote:
> Is it possible to simply add the EDK (which includes the SDK) to ISE WebP=
ack
> OR is it necessary to get the ISE Embedded suite please?
>
> Thanks,
>
> Rog.

If all of the devices that you need are in the WebPack then you can
just add the EDK tools.

Ed McGettigan
--
Xilinx Inc.

Article: 150647
Subject: Re: Can't program Spartan3A with JTAG
From: aleksa <aleksazr@gmail.com>
Date: Mon, 31 Jan 2011 07:44:25 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 31, 4:25=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Jan 31, 4:46=A0am, aleksa <aleks...@gmail.com> wrote:
>
> > some tests I did:
>
> > 1. started iMPACT.
> > 2. double click on Boundary scan.
> > 3. right click, Initialize Chain.
>
> > I get blue text "Identify succeeded"
> > The part is already shown as unknown.
>
> > I'm asked "Do you want to cont. and assign conf. files?" YES
> > "Do you have a BSDL or BIT file?" YES (xc3s50a.bsd)
>
> > 4. Debug, Chain integrity test =3D OK.
>
> > Everything else fails.
>
> What was the IDCODE reported by iMPACT?

IDCODE =3D all zeros


> When you put the oscilloscope on the TDO output what voltage levels
> did you see?

0 and 3.2V


> Is the TDO of the part connected to the TDO of the cable?

Yes, I've placed a JTAG gif here
http://www60.zippyshare.com/v/18748688/file.html


> Are there any other devices in the JTAG chain?

No

Article: 150648
Subject: Re: FPGA changes behaviour when the resource's usage percentage changes
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Mon, 31 Jan 2011 16:54:31 -0000
Links: << >>  << T >>  << A >>
>> I have had it confirmed that if you generate a reset synchronously then use it
>> 'asynchronously' in the standard process template (VHDL) that Quartus knows it's
>> a synchronous signal and all timing analysis is correctly handled.
>>
> Rick is correct, where generic code loses its portability, and not all devices or manufacturers 
> may have this property.


Fair enough if the logic you're designing might be targeted at any manufacturers
devices.

I'm just confirming the case with the Altera tools that a synchronously
generated reset that's implemented as an apparently asycnchronous reset
is treated synchronously. Ie the reset trees are used instead of wasting
a valuable logic input to implement the reset.


Nial. 



Article: 150649
Subject: Looking for contractor for FPGA-based multiUART
From: Axel Mammes <fpgausenet@gmail.com>
Date: Mon, 31 Jan 2011 09:08:02 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi everyone,

I'm looking for someone that can develop an FPGA based multiUART with
32 UARTs for me.

My software will run on this board: h**p://www.andahammer.com/mini35-
sdk.

The mini2440 ARM board has 40 pin system expansion bus connector that
will connect to the multiuart PCB you develop.

Each UART in the multiUART will connect to a gasoline dispenser using
optoisolated 20mA, 30 mA, 45mA current loop. I will provide schematics
for the TTL-current loop conversion.

I was thinking the UARTs could be the 16750 from opencores.org. It's
supposed to be stable and it works with standard Linux drivers. h**p://
opencores.org/project,uart16750

Check out the schematics of a mini2440 expansion card that Eric
Brombaugh already developed.
h**p://members.cox.net/ebrombaugh1/synth/mini_2440_fpga/index.html



Regards
Axel



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