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 58000

Article: 58000
Subject: Re: From one clock domain to another
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 11 Jul 2003 17:07:49 GMT
Links: << >>  << T >>  << A >>
I am sorry to say this design will not work reliably. I assume
that OLDCLK is slower than NEWCLK by at least a factor of 2.
I am also assuming that the two clocks are asynchronous to each
other.

On Fri, 11 Jul 2003 14:24:36 +0200, "Morten Leikvoll" <mleikvol@online.nospam> wrote:
>Does anyone see a weakness in this circuit? (inputs,outputs in capital)
>What if I put a timing ignore attribute on restrig?
>It should create a one clock pulse in the NEWCLK domain when OLDCLK rises.
>
>-----
>signal trig,restrig,delrestrig,
>
>if(restrig='1') then
>    trig<='0';
>elsif(OLDCLK'event and OLDCLK='1') then
>    trig<='1';
>end if;

So trig is in the OLDCLK domain.

The following is all synchronous in the NEWCLK domain.

>if(NEWCLK'event and NEWCLK='1') then
>    restrig<=trig;

The restrig FF D input is comming from the OLDCLK domain, so you
will have setup and hold violations. This FF WILL go metastable.

This signal can not be used to asynchronously clear a FF, which
you are doing on trig.

>    delrestrig<=restrig;

Depending on the cycle time of NEWCLK, the amount of settling time
for restrig (going metastable) till it is loaded on the following
cycle into delrestrig, the probability of delrestrig also going
metastable may be higher than desired.

>    if(delrestrig='0' and restrig='1') then    --Positive edge detector
>        OUTTRIG='1';
>    else
>        OUTTRIG='0';
>    end if

Depending on the cycle time of NEWCLK, the amount of settling time
for restrig (going metastable) till it is used to create OUTTRIG
may not be sufficient to give you a sufficiently reliable OUTTRIG.

>end if;
>---------

This is a classic metastability problem. I suggest you read
the following:

   http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm

and

   (Crossing a clock domain)

   http://www.fpga-faq.com/archives/37175.html#37176
   http://www.fpga-faq.com/archives/37250.html#37250
   http://www.fpga-faq.com/archives/37250.html#37252   <<< especially this one



The solution to your requirements is to put a 2 or 3 FF synchronizer
in the NEWCLK domain, and use the output to generate your OUTTRIG and
restrig signals.



Philip Freidin


Philip Freidin
Fliptronics

Article: 58001
Subject: Re: Fpga design with multiple audio rate (44, 48khz ...)
From: "David" <gretzteam@hotmail.com>
Date: Fri, 11 Jul 2003 13:09:47 -0400
Links: << >>  << T >>  << A >>
I think I understand what you're saying but I'm not sure it would work in my
situation. I understand that if my master clock is much faster than any
possible input sample rate, I should be able to perform the necessary
calculations on each input sample. However, the output sample rate is also
important (this is for a 1-bit sigma-delta modulator).

For example, if the audio sample rate is 44.1khz, and I oversample 64 times,
the output data rate is 2.8224Mhz. My master clock has to be a multiple of
2.8224Mhz (I think...).
Now if I change the audio sample rate to 48khz, and I still oversample 64
times, the output data rate should be 3.072Mhz. This is not a multiple of
the previous output data rate. The only solution I see would be to
oversample the 48khz signal only 58.8 times, so that the output data rate
would be the same for both input rate. I don't think this make any sense
practically though.

Am I complicating this thing? Are there any other workaround except using
the 256Fs clock provided by the CS8416 (see first post)?

Thank you very much
David


> It depends on exactly what you are doing with the data.  If you are
> processing word samples, then you only need a clock as fast as the
> fastest sample rate you expect to see.  If you are doing work at a
> multiple rate then you need a clock at that multiple rate of your
> highest sample rate.
>
> When a sample comes in, your interface circuit provides an enable for
> that clock cycle.  The next stage of logic will process the data and
> pass the enable on to the next stage.  On any clock cycle where there is
> no data from the interface, no enable should be provided and the data
> and enable are not clocked through to the next stage.
>
> The only tricky part is generating the enable since that will have to
> cross clock domains.  But since the sample rate is much slower than the
> clock rate, if I understand what you are doing, then you will be passing
> one enable pulse every 256 clocks (at the most) and the circuit in the
> high speed clock domain will generate how ever many enables are needed
> to complete the processing.
>
> Depending on the exact nature of your processing and clocks, you may
> need a double register or possibly a FIFO if the clock rate is close to
> the sample rate.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX



Article: 58002
Subject: Re: Quartus warning in NUMERIC_STD.vhd
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 11 Jul 2003 13:10:24 -0400
Links: << >>  << T >>  << A >>
Alan Nishioka wrote:
> 
> > "rickman" <spamgoeshere4@yahoo.com> wrote in message
> > news:3F0DC966.43F838F6@yahoo.com...
> > > When I compile my program I get a warning on the range of these two
> > > constants under Quartus 3.0 web edition.  I checked some other
> >  copies of
> > > NUMERIC_STD that I have on my hard drive and found them all to be
> >  the
> > > same.  What is this about?  What are these constants for and why are
> > > they defined this way?  Should this report as a warning?
> > >
> > > package body NUMERIC_STD is
> > >
> > >   -- null range array constants
> > >
> > >   constant NAU: UNSIGNED(0 downto 1) := (others => '0');
> > >   constant NAS: SIGNED(0 downto 1) := (others => '0');
> > >
> 
> "Alan Fitch" <alan.fitch@doulos.com> wrote in message
> news:<belqfe$rna$1$8300dec7@news.demon.co.uk>...
> > I personally don't think it should be a warning, as it's quite legal
> > to declare null vectors - however I guess it would require more
> > careful
> > perusal of the standard to be absolutely sure,
> >
> 
> The compiler is complaining because of the range (0 downto 1) and 0 is
> less than 1, right?

Yes, it is a warning because it is most likely that the user goofed up. 
How many times have you used a NULL vector?  I just got an email from
Altera that said they would no longer provide this warning when such an
issue is found in a library (or something like that).  Either way, this
is a very small issue.  

-- 

Rick "rickman" Collins

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

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

Article: 58003
Subject: Re: Spartan XL Prom Selection
From: Ashok Chotai <Ashok.Chotai@xilinx.com>
Date: Fri, 11 Jul 2003 10:43:07 -0700
Links: << >>  << T >>  << A >>


Hello Anup,
For existing designs, we would suggest you to keep using the Spartan-XL
PROM(OTP) or the XC18V(ISP) PROMs. If it's a new design, then use the
Platform Flash ISP PROMs. See here for more info on Flash PROMs.
Ashok


Spam Hater wrote:

> If the little XC18V's will do it, the big ones will too.  Just ignore
> the extra bits.  The Spartan will stop clocking when it's done.
>
> What you're really looking for doesn't exist, and won't.  The Spartan
> and the SpartanXL are dead parts (in Xilinx's view).
>
> Sorry,
> SH
>
> On Thu, 10 Jul 2003 12:36:57 +0930, Anup Kumar Raghavan
> <> wrote:
>
> >I need to select a Configuration solution for programming the Spartan XL
> >XCS10XL device. I have chosen to use the Master Serial Mode
> >configuration using the PROM XC17S10XL, which is OTP. I havent found any
> >reference to ISP (EPROM) solutions for the Spartan XL and hence need
> >some advice on this. I know there is this device XC18V256PC20C, but
> >Xilinx mentions that this is not supported anymore.
> >
> >Thanks and regards
> >Anup



Article: 58004
Subject: Re: Xilinx ISE drops support for more parts
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Fri, 11 Jul 2003 13:54:20 -0400
Links: << >>  << T >>  << A >>
On Fri, 11 Jul 2003 10:15:33 -0400, rickman wrote:

> hamish@cloud.net.au wrote:
>> 
>> lecroy <lecroy7200@chek.com> wrote:
>> > If the code were structured, supporting the older devices would not
>> > be a problem.
>> 
>> Can you tell us why it's such a hardship to use an older tool version?
>> 
>> Don't say they don't co-exist, because that's not true.
> 
> There are a lot of issues concerning co-compatibility.  I have seen
> older software that won't run under the newer OS and the newer software
> is not supported under the older OS.
> 
> Even those issues aside, it is hard to maintain proficiency on the older
> tools since they change the GUI and even the synthesis tool every few
> years.  This can make it very hard to maintain an older design since
> under a newer tool a design can get much larger.  But if you try to run
> the older tools, they require different tweeks to get a design to run at
> all. Of cource this can be dealt with by good documentation of each
> design, but often there are a number of little quirks that no one thinks
> of putting in the documentation at the time since it is just part of
> running the tool at the time.  I have been there, done that!  Try
> getting an answer from FPGA support on a five year old tool!

I can see why we've been talking at cross purposes, this is the difference
between the perspective of a Windows user and a Linux/Unix user. Windows
makes it difficult, and sometimes impossible, to keep multiple copies of
an application on a single system. There is likely to be all sorts of
registry conflicts as well as search path problems because Windows
manipulates it's search paths behind your back. In addition Windows users
tend to do everything from a GUI which means that they have to remember
how everything works. On *NIX systems the only limit to how many versions
of a program you can have is disk space. To switch from one version to
another all you have to do is change an environment variable or two and
set a path, all of which can be put into a script. We also tend to drive
tools from scripts not from GUIs. Scripts can be archived along with the
source code and constraint files so you don't have to remember anything.
It's for these reasons that ASIC designs are always done on *NIX systems,
the only application of Windows systems that I've ever seen in ASIC design
environments is to act as X terminals and to do documentation.


Article: 58005
Subject: Re: From one clock domain to another
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 11 Jul 2003 14:13:57 -0400
Links: << >>  << T >>  << A >>
Philip Freidin wrote:
> 
> I am sorry to say this design will not work reliably. I assume
> that OLDCLK is slower than NEWCLK by at least a factor of 2.
> I am also assuming that the two clocks are asynchronous to each
> other.

Actually, that is not a bad assumption since OLDCLK is really a signal,
not a clock.  OLDCLK is a poor choice of names perhaps.  


> On Fri, 11 Jul 2003 14:24:36 +0200, "Morten Leikvoll" <mleikvol@online.nospam> wrote:
> >Does anyone see a weakness in this circuit? (inputs,outputs in capital)
> >What if I put a timing ignore attribute on restrig?
> >It should create a one clock pulse in the NEWCLK domain when OLDCLK rises.
> >
> >-----
> >signal trig,restrig,delrestrig,
> >
> >if(restrig='1') then
> >    trig<='0';
> >elsif(OLDCLK'event and OLDCLK='1') then
> >    trig<='1';
> >end if;
> 
> So trig is in the OLDCLK domain.
> 
> The following is all synchronous in the NEWCLK domain.
> 
> >if(NEWCLK'event and NEWCLK='1') then
> >    restrig<=trig;
> 
> The restrig FF D input is comming from the OLDCLK domain, so you
> will have setup and hold violations. This FF WILL go metastable.
> 
> This signal can not be used to asynchronously clear a FF, which
> you are doing on trig.
> 
> >    delrestrig<=restrig;
> 
> Depending on the cycle time of NEWCLK, the amount of settling time
> for restrig (going metastable) till it is loaded on the following
> cycle into delrestrig, the probability of delrestrig also going
> metastable may be higher than desired.
> 
> >    if(delrestrig='0' and restrig='1') then    --Positive edge detector
> >        OUTTRIG='1';
> >    else
> >        OUTTRIG='0';
> >    end if
> 
> Depending on the cycle time of NEWCLK, the amount of settling time
> for restrig (going metastable) till it is used to create OUTTRIG
> may not be sufficient to give you a sufficiently reliable OUTTRIG.

The restrig signal is done poorly in my opinion.  You should check out
my modified example.  It gets around all the metastable issues, I
beieve.  



> >end if;
> >---------
> 
> This is a classic metastability problem. I suggest you read
> the following:
> 
>    http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htm
> 
> and
> 
>    (Crossing a clock domain)
> 
>    http://www.fpga-faq.com/archives/37175.html#37176
>    http://www.fpga-faq.com/archives/37250.html#37250
>    http://www.fpga-faq.com/archives/37250.html#37252   <<< especially this one
> 
> The solution to your requirements is to put a 2 or 3 FF synchronizer
> in the NEWCLK domain, and use the output to generate your OUTTRIG and
> restrig signals.

He is generating the OUTTRIG signal correctly.  As to the restrig
signal, all he needs to do is change the way he uses it in the other
clock domain.  

-- 

Rick "rickman" Collins

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

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

Article: 58006
Subject: Re: Fpga design with multiple audio rate (44, 48khz ...)
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 11 Jul 2003 20:14:31 +0200
Links: << >>  << T >>  << A >>

"David" <gretzteam@hotmail.com> schrieb im Newsbeitrag
news:BbCPa.21428$Pe2.654126@wagner.videotron.net...

> For example, if the audio sample rate is 44.1khz, and I oversample 64
times,
> the output data rate is 2.8224Mhz. My master clock has to be a multiple of
> 2.8224Mhz (I think...).
> Now if I change the audio sample rate to 48khz, and I still oversample 64
> times, the output data rate should be 3.072Mhz. This is not a multiple of
> the previous output data rate. The only solution I see would be to
> oversample the 48khz signal only 58.8 times, so that the output data rate
> would be the same for both input rate. I don't think this make any sense
> practically though.
>
> Am I complicating this thing? Are there any other workaround except using
> the 256Fs clock provided by the CS8416 (see first post)?

Do a prime factor analysis of the two sample rates and find the smallest
common multiple.

dumdidum

44100 Hz = 2^2 * 3^2 * 5^2 *7^2  Hz
48000 Hz = 2^7 * 3^1 * 5^3 Hz

multiplying this with 64 = 2^6 gives

44100 * 64 = 2^8 *3^2 * 5^2 *7^2
48000 * 64 = 2^13 * 3^1 *5^3

the smallest common multiple is so

2*13 * 3^2 * 5^3 * 7^2 = 451.58 Mhz

Huhhh, quite fast, so this simple straight forward approach will most
possible not be practical.

Nevertheless, you may need some kind of clock alignment /PLL stuff, since
the Xtal clock on the FPGA is not phase locked to the incomming datastream,
so they will drift away from eah other. So you will possible end up be using
the 256 times oversampled clock from the CS8416.

--
Regards
Falk




Article: 58007
Subject: Re: Quartus warning in NUMERIC_STD.vhd
From: sdatta@altera.com (Subroto Datta)
Date: 11 Jul 2003 11:18:01 -0700
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F0DC966.43F838F6@yahoo.com>...
> When I compile my program I get a warning on the range of these two
> constants under Quartus 3.0 web edition.  I checked some other copies of
> NUMERIC_STD that I have on my hard drive and found them all to be the
> same.  What is this about?  What are these constants for and why are
> they defined this way?  Should this report as a warning?  
> 
> package body NUMERIC_STD is
> 
>   -- null range array constants
> 
>   constant NAU: UNSIGNED(0 downto 1) := (others => '0');
>   constant NAS: SIGNED(0 downto 1) := (others => '0');
> 
> From my days of C programming, I am uncomfortable with warning
> statements.  If there are warnings, even if they are not problems, I get
> rid of them so that they don't obscure warnings about *real* problems.  
> 
> -- 
> 
> Rick "rickman" Collins
> 

NAU and NAS are constants that are used to return error conditions in
the arithmetic packages, and are deliberately declared to be a NULL
range.

The warning is there to give information to users about a possible
typo -- in the same spirit as the C warning "assignment in conditional
expression". It is perfectly legal VHDL, but is quite likely to
indicate a user error.

Obviously, these warnings are not useful when they occur in the
standard package numeric_std.vhd, and they will be not be issued for
null ranges in the standard packages in the next release of Quartus
(3.1).

- Subroto Datta
Altera Corp.

Article: 58008
Subject: Re: DDS theory of operation
From: Ray Andraka <ray@andraka.com>
Date: Fri, 11 Jul 2003 14:54:11 -0400
Links: << >>  << T >>  << A >>
It takes more real-estate to get more performance.  In most cases, the DDS is
coupled either with a DAC or an ADC, and those devices already have a noise
floor associated with them.  With that in mind, there is not much incentive to
throw excess real-estate at reducing the DDS noise much below the noise floor
established by the converter in the system.

Sasa Bremec wrote:

> Hi !
>
> I have a question about DDS. I discovered that most of DDS application in
> SDR use the SFDR factor around 60dBc and frequency resolution around 1 Hz.
> Why is so, and Why don't use SFDR around 120 dBc and freq. resolution about
> 0.02 Hz. Yes I know there is a space trade-off and I wan to know how to
> decide parameters I  need for my specific application.
>
> Thanks, Sasa

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

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



Article: 58009
Subject: Re: Seminar: Digital Signal Processing, Programmable Device
From: Ray Andraka <ray@andraka.com>
Date: Fri, 11 Jul 2003 14:57:46 -0400
Links: << >>  << T >>  << A >>
For what it is worth, I'll be presenting that seminar, and at the conference
pricing it is well below the pricing for my 2 day seminar, plus you get to
go to a decent conference on FPGAs.  Hope to see ya'll there.

"Richard B. Katz" wrote:

> A seminar on "Digital Signal Processing, Programmable Device
> Architecture, and Military/Aerospace Applications" will be presented at
> the 2003 MAPLD International conference on September 8th, 2003, in
> Washington, D.C.
>
>    http://www.klabs.org/richcontent/MAPLDCon03/tutorials/
>
> Abstract
> ========
>
> Digital signal processing has traditionally been done using Von-Neuman
> or Harvard type processors with enhancements such as single cycle
> multiplies. Recent advances in speed, density, and features have made
> Field Programmable Gate Arrays (FPGAs) very attractive for digital
> signal processing applications, particularly when performance
> requirements are beyond the capability of microprocessors.
> Unfortunately, the majority of signal processing work over the last
> quarter century has been implemented as software on computers.
> Consequently,  there is currently very little overlap between hardware
> design and DSP expertise. Algorithms developed for software platforms
> are usually very inefficient for direct hardware implementation, and
> without the overlapping areas of expertise, the resulting FPGA
> realization is bound to disappoint.
>
> This seminar helps to bridge the gap between DSP and FPGA design, aiding
> the designer in achieving the performance potential of FPGAs. This
> seminar will first review computer arithmetic and then look in detail at
> efficient FPGA implementations of common DSP elements such as
> multipliers, filters, and mixers. Tradeoffs between clock rate and
> performance will be discussed along with several design examples.
>
> Conference home page:  http://klabs.org/mapld03
>
> Additional info: Richard B. Katz, NASA Office of Logic Design
>                  richard.b.katz@nasa.gov

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

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



Article: 58010
Subject: Re: Fixed point signed multiplication algorithm
From: Ray Andraka <ray@andraka.com>
Date: Fri, 11 Jul 2003 15:02:52 -0400
Links: << >>  << T >>  << A >>
Praveen,

have a look at the multipliers page on my website.  I cover several ways
to do multiplication there.  The fastest in-the-fabric multipliers in
Xilinx use 2xN partial products combined in an adder tree.  The embedded
multiplier blocks aren't constrained by the FPGA LUT structure, so they
use a modified booth design that is appropriate to ASICs, but not to
multipliers done using FPGA LUTs.

praveen wrote:

> Hello,
> I am implementating Fixed point signed multiplication. Is there a
> algorithm to implement it. I have done the usual method of
> multiplication i.e partial products ...shift and add method. But its
> very slow. If you know any algorithm which will faster do mention. Any
> reference will be great. How does the signed multipliers in xilinx
> that fast. what algorithm do they use. I need to first implement in on
> MATLAB and see the result.
>
> waiting for reply
> praveen

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

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



Article: 58011
Subject: Re: Leonardo changes name of lpm megafunction
From: jen_junk@hotmail.com (Jen)
Date: 11 Jul 2003 12:16:38 -0700
Links: << >>  << T >>  << A >>
Jared,

If you add the LPM_TYPE parameter to your megafunction, that should
also allow it to be recognized in the MAX+PLUS II software, even with
the other generics appended to the name in the EDIF.  The parameter is
listed as optional in the documentation but you need it for
third-party synthesis.  The MAX+PLUS II MegaWizard doesn't add the
parameter because it assumes you'll be compiling the function natively
in MAX+PLUS II (the Quartus II MegaWizard now adds it automatically,
BTW).  In MAX+PLUS II Help you should see the syntax for LPM_TYPE; you
set it to the string name for your megafunction.

Hope that helps!


jaz_shnat@hotmail.com (Jared) wrote in message news:<98bc4967.0307082238.2879b984@posting.google.com>...

> I'm trying to create a 20-bit pipelined adder using the lpm_add_sub
> megafunction, but when I try and compile my project in leonardo it
> changes the name in the .edf file from lpm_add_sub to
> lpm_add_sub_20_add_no_5 which Altera Max+PLUS does not recognize. In
> order for it to place and route correctly, I have to manually change
> the name back to lpm_add_sub. Does anybody know if there is a way to
> prevent this from happening. I've already tried setting the noopt and
> dont_touch attribute in the architecture block.

Article: 58012
Subject: Re: Graduation Day: My first 4-layer PCB
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Fri, 11 Jul 2003 14:49:27 -0500
Links: << >>  << T >>  << A >>


..:: Gabster ::.. wrote:

>Hi,
>
>I'm made many 2-layer PCB's in the past years, but I'm about to start the
>desgin of my first 4-layer PCB. The board is basically a FPGA (Xilinx
>Spartan IIE XC2S300 in PQ208 package running at 12MHz), 3 power supply
>regulators, an oscillator block, a PROM and a logic IC.
>
>In addition to other literature, I read the following document:
>http://www.xilinx.com/xapp/xapp623.pdf
>but it is rather complicated and not straight foward for a rookie like me in
>FPGA design! So here's a few direct questions:
>
>1) 4-layer, why is it so important?
>  
>
It allows you to have wide power and ground planes, which drastically 
reduces
inductance.  I have successfully made some boards with 5 V Spartan FPGAs
with just 2 layers, but I had to pay a lot of attention to providing 
wide ground and
power nets in a manner that was likely to keep impedance low.  Having layers
dedicated to power and ground frees up routing area for the signal traces.

>2) In what order should I stack the layers (TOP/GND/POWER/BOTTOM or
>TOP/POWER/GND/BOTTOM), why?
>  
>
For lowest power impedance, either of these are fine.  For best shielding,
power/signal1/signal2/ground is used in a lot of mil-spec gear.

>3) Decoupling caps surroung the FPGA: I figured out I needed one 0.1F per
>power pin (1.8V and 3.3V) + one 10F per power supply (1.8V and 3.3V). Is
>that accurate? Should I do more? What should I avoid?
>  
>
That is most likely fine.  Especially if Xilinx recommends that, it 
should be OK.

>4) What is the concept surrounding islands on the power plane? What should
>that plane look like? What should I avoid? What the hell about it, this
>plane is a mystery for me!!!
>  
>
Well, you need to carve the power plane regions based on the geometry of the
power pins on each net.  If you can get it so that a net is a simple 
rectangle, that's
nice, but it often comes out as a very convoluted region.  There isn't 
much you
can do about it in some cases.  But, it is best to avoid having one net 
made up
of lots of thin fingers, as that raises impedance.  Also, (been there, 
done that)
board manufacturers may alter the clearance around holes in the inner 
layers,
causing regions that were connected by ample copper in your Gerber plots to
become isolated in the finished board!  Not a good situation, then you 
have to
argue whether it is a manufacturing defect or whether your original design
violated their manufacturing specs on inner-plane clearance.

Jon


Article: 58013
Subject: Graduation Day: My first 4-layer PCB
From: "..:: Gabster ::.." <gabsterblue@hotmail.com>
Date: Fri, 11 Jul 2003 15:51:01 -0400
Links: << >>  << T >>  << A >>
Hi,

I'm made many 2-layer PCB's in the past years, but I'm about to start the
desgin of my first 4-layer PCB. The board is basically a FPGA (Xilinx
Spartan IIE XC2S300 in PQ208 package running at 12MHz), 3 power supply
regulators, an oscillator block, a PROM and a logic IC.

In addition to other literature, I read the following document:
http://www.xilinx.com/xapp/xapp623.pdf
but it is rather complicated and not straight foward for a rookie like me in
FPGA design! So here's a few direct questions:

1) 4-layer, why is it so important?

2) In what order should I stack the layers (TOP/GND/POWER/BOTTOM or
TOP/POWER/GND/BOTTOM), why?

3) Decoupling caps surroung the FPGA: I figured out I needed one 0.1F per
power pin (1.8V and 3.3V) + one 10F per power supply (1.8V and 3.3V). Is
that accurate? Should I do more? What should I avoid?

4) What is the concept surrounding islands on the power plane? What should
that plane look like? What should I avoid? What the hell about it, this
plane is a mystery for me!!!

In order to avoid asking 1000's other questions, I wonder if someone could
also direct me toward a complete document talking about PCB design
guidelines for PQ package FPGA's. I found that for the BGA packages on
xilinx website, but it didn't help me much.

Thanks a lot,
Gabriel



Article: 58014
Subject: Re: Graduation Day: My first 4-layer PCB
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 11 Jul 2003 17:16:48 -0400
Links: << >>  << T >>  << A >>
Power design is one of those things that is full of mysterious
incatations and voodoo.  That is because even though the science behind
it is not hard to understand, it is very difficult to apply and then
verify that what you have done works the way you think it will. 
Basically either your board will work or it won't and you won't have the
time to figure out exactly what was wrong.  If it fails due to noise you
will throw the kitchen sink at it to make sure it works the next time. 
Not much learning involved there.  

I think there is a lot that people agree on and much that they don't. 
Based on everything I have read and my personal experience, your board
will not be a tough one to design with quiet power.  

"..:: Gabster ::.." wrote:
> 
> Hi,
> 
> I'm made many 2-layer PCB's in the past years, but I'm about to start the
> desgin of my first 4-layer PCB. The board is basically a FPGA (Xilinx
> Spartan IIE XC2S300 in PQ208 package running at 12MHz), 3 power supply
> regulators, an oscillator block, a PROM and a logic IC.

I would advise using an isolated region of the ground plane for each
switching regulator with a single connection to the rest of the ground
plane.  They tend to create very large ground currents.  Also pay close
attention to the design notes for that device.  The key to minimizing
EMI as well as the voltage spikes is to minimize the area of high
current loops.  This is a common theme in power supply design and
distribution. 

It may also help to provide an isolated power to the oscillator using a
ferrite bead or filter.  Many PLLs require this.  


> In addition to other literature, I read the following document:
> http://www.xilinx.com/xapp/xapp623.pdf
> but it is rather complicated and not straight foward for a rookie like me in
> FPGA design! So here's a few direct questions:

I would also recommend that you check with the capacitor manufacturers. 
I believe AVX has some good notes on this. 


> 1) 4-layer, why is it so important?

The important part is using two layers for the power and ground.  This
reduces the resistance to nearly zero and provides a well defined
impedance for the high frequency noise.  The two planes should be very
close together (10 mil) to maximize the capacitance and reduce the
impedance.  


> 2) In what order should I stack the layers (TOP/GND/POWER/BOTTOM or
> TOP/POWER/GND/BOTTOM), why?

I have never heard anyone say one is preferred over the other.  I would
say pick one based on any logistical issues you may have.  


> 3) Decoupling caps surroung the FPGA: I figured out I needed one 0.1F per
> power pin (1.8V and 3.3V) + one 10F per power supply (1.8V and 3.3V). Is
> that accurate? Should I do more? What should I avoid?

If you can get a cap on each pin you will be doing fine.  The main point
is to minimize the total loop area from a power pin, through the cap and
back to a ground pin.  So more than just lead length, you need to
optimize cap placement.  


> 4) What is the concept surrounding islands on the power plane? What should
> that plane look like? What should I avoid? What the hell about it, this
> plane is a mystery for me!!!

I have heard about the island theory, but never tried it myself.  Your
board is not going to be a critcal one, so just stick to one large power
plane, divided up for each power region of course.  If the board is
really as simple as you describe above you don't really have any big
issues.  


> In order to avoid asking 1000's other questions, I wonder if someone could
> also direct me toward a complete document talking about PCB design
> guidelines for PQ package FPGA's. I found that for the BGA packages on
> xilinx website, but it didn't help me much.

The quad flat packages are inherently more noisy for the chip inside due
to the longer leads.  So your board design can only do so much.  A big
help will be to drive your outputs as lightly as possible and as slow as
possible.  The SpartanIIE's have several variations in drive strength
and speed.  Also if you are concerned about a lot of outputs switching
at the same time, you can try to stagger them a bit.  But this is not
normally needed except in extreme cases.  

-- 

Rick "rickman" Collins

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

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

Article: 58015
Subject: Re: Graduation Day: My first 4-layer PCB
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 11 Jul 2003 17:21:39 -0400
Links: << >>  << T >>  << A >>
One other point I would like to make.  A lot of people will tell you to
use multiple Tantalum caps, including the Xilinx app notes.  But
Tantalum caps are inherently slow compared to the noise on the board. 
So you can get away with a single cap anywhere on each power plane it
will fit.  But 10 uF may be a bit small.  I build a board with a 10 uF
cap and found that the power line impedance coming to the board created
voltage spikes enough to show up in the analog circuits.   A larger
Tantalum cap on the board would have prevented this.  Of course better
power conductors solved the problem as well.  

-- 

Rick "rickman" Collins

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

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

Article: 58016
Subject: Re: Graduation Day: My first 4-layer PCB
From: "..:: Gabster ::.." <gabsterblue@hotmail.com>
Date: Fri, 11 Jul 2003 17:45:45 -0400
Links: << >>  << T >>  << A >>
This is really an appropriate reply and I feel confident to start the design
of my board.

Thanks, this is really appreciated.
Gabriel

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3F0F2A63.C758E3FE@yahoo.com...
> One other point I would like to make.  A lot of people will tell you to
> use multiple Tantalum caps, including the Xilinx app notes.  But
> Tantalum caps are inherently slow compared to the noise on the board.
> So you can get away with a single cap anywhere on each power plane it
> will fit.  But 10 uF may be a bit small.  I build a board with a 10 uF
> cap and found that the power line impedance coming to the board created
> voltage spikes enough to show up in the analog circuits.   A larger
> Tantalum cap on the board would have prevented this.  Of course better
> power conductors solved the problem as well.
>
> -- 
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX



Article: 58017
Subject: Quartus VHDL problem with aggregate and type cast
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 11 Jul 2003 18:00:28 -0400
Links: << >>  << T >>  << A >>
Here is some code showing a problem I am having with Quartus.  Seems
using a type cast with an aggregate throws it all off.  This is just a
simple test case which uses a 16 bit bidir bus to write to an 8 bit
register and read it back.  


-- VHDL created by Rick Collins
Library ieee;
Use ieee.std_logic_1164.all;
Use ieee.numeric_std.all;

ENTITY Test1 is
	PORT (
	Data		: INOUT STD_LOGIC_VECTOR (15 DOWNTO 0);
	Addr		: IN  STD_LOGIC_VECTOR (7 DOWNTO 0);
	CSN		: IN  STD_LOGIC;
	RDN		: IN  STD_LOGIC;
	WRN		: IN  STD_LOGIC;

	LED		: OUT STD_LOGIC;

	Reset		: IN STD_LOGIC;
	SysClk		: IN STD_LOGIC); -- 50 MHz Clock
END Test1;

ARCHITECTURE behavior OF Test1 IS

	constant SysClkRate	: real := 50000.0; -- Rate in KHz
	signal ScratchReg	: STD_LOGIC_VECTOR (7 downto 0);
	signal DataOut		: STD_LOGIC_VECTOR (15 downto 0);
	signal ReadScratchReg : STD_LOGIC;


BEGIN

  ReadScratchReg <= (not RDN) WHEN (Addr="00001000") and (CSN='0')  
    ELSE '0';

-- VERSION 1
-- These lines work correctly
--  Data (15 downto 8) <=  (others => '0')  WHEN  (ReadScratchReg = '1') 
--    ELSE  (others => 'Z');
--  Data (7 downto 0) <=  ScratchReg  WHEN  (ReadScratchReg = '1') 
--    ELSE  (others => 'Z');

--  VERSION 2
--  This line fails by disabling the tristate buffers
--    Data  <=  STD_LOGIC_VECTOR (15 downto 8)'(others => '0') &
ScratchReg  WHEN  (ReadScratchReg = '1') 
--      ELSE  (others => 'Z');
-- The difference seems to be the use of the type cast.  
-- Using a type cast with the (others => aggregate seems to fail in
other cases as well.  

--  VERSION 3
--  This version produces open drain outputs
    Data  <=  DataOut  WHEN  (ReadScratchReg = '1') 
      ELSE  (others => 'Z');
--  This seems to work ok
--    DataOut <= "00000000" & ScratchReg; 
--  This produces no register and open drain drivers
    DataOut <= STD_LOGIC_VECTOR (15 downto 8)'(others => '0') &
ScratchReg; 


  ScratchRegister: process (SysClk, Reset) begin
    if (Reset = '1') then 
	  ScratchReg <= (others => '0');
    elsif (rising_edge(SysClk)) then
	  if (Addr = "00001000") THEN
	    if (WRN = '0' and CSN = '0') THEN
	      ScratchReg <= Data (7 downto 0);
		end if;
	  end if;
	end if;
  end process ScratchRegister;

  LED <= ScratchReg(0) AND ReadScratchReg;

END behavior;


As seen under VERSION 3, using the type cast on an aggregate produces a
design with the register not driving the bidir output pins.  I don't see
any messages saying the registers were deleted, but the only bit that
remains is the zero bit which drives the LED output.  All of the DataOut
nets are listed as undriven and tied to ground.  

Using a fixed size vector seems to work ok.  It also works ok if I
separate the two halves of the bus and don't use a type cast on the
aggregates.  Is this a Quartus bug?  

I tried contacting Altera support, but after waiting on hold to talk to
someone, I got put on hold again and then cut off.  


-- 

Rick "rickman" Collins

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

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

Article: 58018
Subject: Re: Cyclone vs Spartan-3
From: "Pete Fraser" <pete@rgb.com>
Date: Fri, 11 Jul 2003 15:04:28 -0700
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F01F99B.94B76799@xilinx.com...

> Spartan3 is not the fastest, in some areas it is slower than Virtex-II,
> since the priorities for Spartan3 were: 1. low cost, 2. low cost, and 3.
> low cost. We don't throw away speed, but we did not increase the chip
> size to gain performance.

So the rep who told me that the slowest speed grade 3S was
always faster than the slowest speed grade 2VP was mistaken?



Article: 58019
Subject: Re: Cyclone vs Spartan-3
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Fri, 11 Jul 2003 15:57:47 -0700
Links: << >>  << T >>  << A >>
Pete,

I believe so.  90nm is not faster than 130 nm per se.  In order to get faster
transistors, you need to also reduce Vt (threshold voltage), and that
increases leakage (by a LOT).  With the change from 150 nm to 130 nm we begin
to see successive generations without any performance increases due to the raw
transistors.  Now performance comes only with architectual improvements, or
new designs, or with "hardening" soft IP.

To make a future transistor faster and not accure undo leakage, we (and
everyone else on the planet) need a hi-k gate dielectric process (yet to be
invented and proven to be robust).

Smaller is less cost per die, but not necessarily better performance like we
have been used to in the past.  Perfomance now comes at a greater cost!

Spartan 3 had to meet the 311 MHz "magic number" for DDR 622 MHz data
applications, but did not have to be any faster than that to meet 99% of its
intended applications.

The raw speed of the transistors is only one factor.  There is also the speed
of the interconnect (smaller in 90 nm means slightly faster), as well as
architectual differences in Spartan 3 that actually yield some improvements.

So to say "is S3 faster than V2P?" requires a lot of definitions, and caveats
to answer.  But basically, the transistors are no faster in S3 than they are
in V2P.

Austin

Pete Fraser wrote:

> "Peter Alfke" <peter@xilinx.com> wrote in message
> news:3F01F99B.94B76799@xilinx.com...
>
> > Spartan3 is not the fastest, in some areas it is slower than Virtex-II,
> > since the priorities for Spartan3 were: 1. low cost, 2. low cost, and 3.
> > low cost. We don't throw away speed, but we did not increase the chip
> > size to gain performance.
>
> So the rep who told me that the slowest speed grade 3S was
> always faster than the slowest speed grade 2VP was mistaken?


Article: 58020
Subject: Post-fit simulation question
From: brad@tinyboot.com (Brad Eckert)
Date: 11 Jul 2003 16:52:56 -0700
Links: << >>  << T >>  << A >>
I have a CPU core and testbench in synthesizable VHDL. I can
synthesize using Xilinx ISE 5.1 and it will tell me such-and-such
maximum frequency. However, the CPU won't exercise all datapath
combinations and it does different things in different cycles so I
don't really trust the fitter's max frequency estimate.

My plan is to run the post-fit simulation model through my testbench
with different clock frequencies until the CPU fails. Then I'll add a
little overhead to meet minimum register setup times and that will be
my minimum clock period.

Am I being too pessimistic about XST's timing estimating capability,
and if not, does this sound like a reasonable approach?

--
Brad Eckert

Article: 58021
Subject: Re: From one clock domain to another
From: "Morten Leikvoll" <mleikvol@online.nospam>
Date: Sat, 12 Jul 2003 02:10:54 +0200
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3F0EFE65.6E432EF8@yahoo.com...
> Philip Freidin wrote:
> >
> > I am sorry to say this design will not work reliably. I assume
> > that OLDCLK is slower than NEWCLK by at least a factor of 2.
> > I am also assuming that the two clocks are asynchronous to each
> > other.
>
> Actually, that is not a bad assumption since OLDCLK is really a signal,
> not a clock.  OLDCLK is a poor choice of names perhaps.
>

True, but the oldclk(signal) will just last for one oldclk cycle. But I
guess the period of this clock doesn't matter as it is positive edge
triggered.



Article: 58022
Subject: Re: From one clock domain to another
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 11 Jul 2003 22:30:09 -0400
Links: << >>  << T >>  << A >>
Morten Leikvoll wrote:
> 
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:3F0EFE65.6E432EF8@yahoo.com...
> > Philip Freidin wrote:
> > >
> > > I am sorry to say this design will not work reliably. I assume
> > > that OLDCLK is slower than NEWCLK by at least a factor of 2.
> > > I am also assuming that the two clocks are asynchronous to each
> > > other.
> >
> > Actually, that is not a bad assumption since OLDCLK is really a signal,
> > not a clock.  OLDCLK is a poor choice of names perhaps.
> >
> 
> True, but the oldclk(signal) will just last for one oldclk cycle. But I
> guess the period of this clock doesn't matter as it is positive edge
> triggered.

Yes, that is the point of the circuit the way I provided it.  A coworker
showed it to me and explained how it had many uses in different forms. 
I don't remember all the applications, but it works so well because it
deals with the metastable issues and is very simple.  

You can even shave a FF off the newclk side by xoring the output of the
oldclk FF and the output of the newclk FF and clocking that signal
before use.  This final FF should remove any metastability in either the
newclk FF or the oldclk FF.  The only trick with that circuit is to make
sure the delay from the oldclk FF through the XOR to the final FF is
longer than the path from the oldclk FF to the first newclk FF.  If not,
you can miss an edge.  So it is not worth the trouble unless you are
really counting your FFs or you are using a lot of these circuits.  

-- 

Rick "rickman" Collins

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

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

Article: 58023
Subject: Re: VIRTEX switching IO voltage 3.3V / 2.5V
From: John_H <johnhandwork@mail.com>
Date: Sat, 12 Jul 2003 02:37:19 GMT
Links: << >>  << T >>  << A >>
Unfortunately the I/O compliance isn't selectable when the part is 
configured - it's a constraint used to define the configuration file.

You can have the different supplies accommodated by reconfiguring the 
Virtex-II with the other voltage if necessary.  I expect that having 
3.3V on 2.5V defined rails (or vice-versa) won't damage the part though 
logic thresholds might be confused.

If the 3.3V logic you're interfacing to can accept 2.5V levels from the 
Xilinx device, just adding 100 ohm series resistors - as is used to 
interface 5V logic with 3.3V inputs - may also give you a design that 
interfaces to both voltages while being powered from 2.5 only.



Krzysztof Szczepanski wrote:
> Hello,
> 
> I have a design for the VIRTEX -II chip with two I/O standards (3.3V and
> 2.5V). Selected banks have switching I/O voltage after configuration. The
> voltage depends on project type. One VIRTEX configuration has 3.3V standard
> and other configuration has 2.5V standard. I have to switch the appropriate
> voltage after configuration of the VIRTEX.
> 
> My problem is if I can switch the I/O voltage form 3.3V to 2.5V after
> configuration of the VIRTEX with I/O (input, output and input-output) pasd's
> standard set to 2.5V?
> In this case selected VCCO power pins will have 3.3V for several mil.
> seconds.
> 
> Is the opposite situation possible when I have default 2.5V VCCO? Then I
> switch form 2.5V to 3.3V after configuration (project have 3.3V I/O standard
> and VIRTEX pins are connected to other system pins with 3.3V).
> 
> Regards,
> Krzysiek
> 
> 
> 


Article: 58024
Subject: Re: Cyclone vs Spartan-3
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Sat, 12 Jul 2003 02:43:52 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3F0F40EB.946703FB@xilinx.com>,
Austin Lesea  <Austin.Lesea@xilinx.com> wrote:
>To make a future transistor faster and not accure undo leakage, we (and
>everyone else on the planet) need a hi-k gate dielectric process (yet to be
>invented and proven to be robust).
>
>Smaller is less cost per die, but not necessarily better performance like we
>have been used to in the past.  Perfomance now comes at a greater cost!

Fortunatly, many of the interesting FPGA applications benefit from
effectively arbitrary fine pipelining, which means they can always
benefit from replication.  Thus reducing size, and thereby getting
more gates/$, results in higher performance even if the gates still
run at the same speed.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu



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