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 102650

Article: 102650
Subject: Re: Virtex 5 announced and sampling: apologia for FX woes on V4
From: "Paul Leventis" <paul.leventis@gmail.com>
Date: 18 May 2006 13:01:35 -0700
Links: << >>  << T >>  << A >>
Hi Antti,

No comment means that we could be coming out any time.

Max II is pretty awesome in many ways (performance, cost per logic
function, etc.).  There are some applications where non-volatility and
RAM would be handy, and these aren't addressed by Max II.  We've got
that feedback and will factor it into future architecture decisions --
but its always a trade-off of the cost (die-size impact) of adding
additional features vs. the size of the market that those additional
features will open to us.

Regards,

- Paul


Article: 102651
Subject: Output gain adjuster of digital filters
From: "Roger Bourne" <rover8898@hotmail.com>
Date: 18 May 2006 13:08:28 -0700
Links: << >>  << T >>  << A >>
Hello all,

I recently learned/heard  that when implementing a IIR digital filter
of direct form I, the gain has to be finely adjusted with an
additionnal module on the output. Otherwise, the 0dB level will not be
perfectly reached in your passband (filter is low pass) and e.g.
consequently a digital value that is suppose to be 40000.0000 will be
4000.0001.
Essentially, I imagine this output module to be a multiplier of
1.0000000XXXX or 0.99999XXX

I was led to believe this problem does not arise with digital filter
implementations of direct form II.

Is this true ?
Looking over the flow diagrams of the 2 type of filters, I do not
understand why one form would require a gain adjustement and the other
would not.

P.S The filter is being implemented in an FPGA, not in a DSP.
P.S The passband ripple is tiny, below 1e-4dB

All help will be appreciated.
Regards
-Roger


Article: 102652
Subject: Re: Xilinx Platform Cable USB protocol specifications and/or open-source firmware replacement
From: fpga_toys@yahoo.com
Date: 18 May 2006 13:16:47 -0700
Links: << >>  << T >>  << A >>

Ed McGettigan wrote:
> > The bitch ... is that Xilinx requires users to use the Xilinx usb
> > adapter to program, then unplug the Xilinx usb JTAG interface, from a
> > possibly live board, then plug another 3rd party (or home grown) JTAG
> > into the board to do testing or configuration of non-xilinx
> > device/functions on the JTAG buss, then reconnect the Xilinx usb JTAG
> > interface when it's necessary to reprogram a Xilinx part on the JTAG
> > chain.
>
> There is no truth to this assertion.  Our devices can be configured
> by many, many, many different means.  Hundreds, if not thousands, of
> pages are available on www.xilinx.com describing how to take a generated
> bitstream and use it configure a device.

Then where is the documentation which describes the API for the Xilinx
USB JTAG interface/cable/adapter?


Article: 102653
Subject: Re: ADC implementation on FPGA ?
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 18 May 2006 13:20:50 -0700
Links: << >>  << T >>  << A >>
Luc,

-snip-
> Maybe one day someone will be able to build a configurable or
> programmable ADC. (Austin, is this allready patented?

Yes, it is.  I did (for Xilinx).

Since then, I also believe our IC Design Centre (note spelling) in 
Dublin, Ireland has also filed quite a few more on that subject.

You are correct, however.  It is very hard to make everyone happy, so we 
have to see just how many smiles we get for a proposed feature, and 
weigh that against the costs (area, yield, market gained/lost, 
competition, etc).

It really doesn't matter what it is: PCI?  PCIe?  EMAC?  PPC?  PLL? 
DLL?  ECC?  FIFO?  MGT? they are require some study, and we may not get 
them right the first time we do them (since anything new is a real risk).

Quite a balancing act.

Austin

Article: 102654
Subject: Re: Virtex 5 announced and sampling: now we just wait?
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 18 May 2006 13:28:00 -0700
Links: << >>  << T >>  << A >>
Antti,

The heat is really on now.  Since we announced the LX50, LX85 and LX110, 
all sampling (and already sampled), the heat up on North 1st Street has 
got to be intense.

"No comment" could also mean "Oh Crud!"

Three days, 5 hours since V5, and counting .....

Tick, tick, tick, tick ....

No pressure, really.  Take your time.

Tick, tick, tick, tick ....

Austin

Paul Leventis wrote:

> Hi Antti,
> 
> No comment means that we could be coming out any time.
> 

Article: 102655
Subject: DCM and Clock
From: "Fizzy" <fpgalearner@gmail.com>
Date: 18 May 2006 13:32:14 -0700
Links: << >>  << T >>  << A >>
Hi,

Considering me a newcommer to FPGA world. I am trying to use Virtex 4FX
series for a synchronous design, meaning i will be using only one clock
for whole design. Obviously if the main clock is running at 100 MHz, i
would have software components on FPGA running at different clock speed
like 80 Hz or 200 Hz. To acheive this i would have to divide the system
clock. Xilinx suggest to use DCM for this purpose but to me it is
confusing as it is location dependent. Does it mean i have to move my
logic some how to the same area where DCM is or did i interpretate it
wrong. Plus DCM out put clock can drive multiple software components.
is it true?

Thanks


Article: 102656
Subject: Re: DCM and Clock
From: "Peter Alfke" <peter@xilinx.com>
Date: 18 May 2006 13:39:26 -0700
Links: << >>  << T >>  << A >>
You call it "synchronous design" but then you mention 80 MHz and 200
MHz.
Be careful with multiple clock domains. Any domain crossing is fraught
with danger.
A DCM usually drives a global clock line, which -as the name implies-
can drive anywhere on the chip.
Somebody else told you specificlly to do more reading and studying
first, and I concur...
Peter Alfke


Article: 102657
Subject: Re: DCM and Clock
From: "Fizzy" <fpgalearner@gmail.com>
Date: 18 May 2006 14:14:41 -0700
Links: << >>  << T >>  << A >>
Well when i said synchronous, i ment the 80 and 200 Hz clock will be
extracted from the global clock. Now can i use DCM at that point where
i want 80 Hz derived from system clock. Previously i know its been done
by dividing the system clock , Reading DCM i think it can do the same
job without clock skew and jitter. I wanted to know if DCM placment
does have any impact ???


Article: 102658
Subject: V5 and carry lookahead
From: "acd" <acd4usenet@lycos.de>
Date: 18 May 2006 14:25:43 -0700
Links: << >>  << T >>  << A >>
I was axcited when I read "carry lookahead" with respect to V5.
But when looking at the diagrams in the user guide it looks to me like
ripple carry.
I do not want to be picky, but carry lookahead means to me
(poly)logarithmic growth of delay with respect to adder length.
The timing model (as far as I understood it) suggests
that the delay grows linearly with the adder length.
Now what is it, ripple carry or lookahead.

It is clear that FPGAs with linear layout of adders ultimately
approximate linear delay/adder length but if wire delay is
already the dominant problem, then a more compact
arrangement like along a Sierpinsky curve could be used.

There is paper from Hosler, Hauck and Fry from 97
which discusses several adder designs with respect to FPGAs,
but in 65nm wire delay, even with optimal buffering would have to be
considered. 

Andreas


Article: 102659
Subject: Re: DCM and Clock
From: Duane Clark <junkmail@junkmail.com>
Date: Thu, 18 May 2006 21:37:52 GMT
Links: << >>  << T >>  << A >>
Fizzy wrote:
> Hi,
> 
> Considering me a newcommer to FPGA world. I am trying to use Virtex 4FX
> series for a synchronous design, meaning i will be using only one clock
> for whole design. Obviously if the main clock is running at 100 MHz, i
> would have software components on FPGA running at different clock speed
> like 80 Hz or 200 Hz. To acheive this i would have to divide the system
> clock. 

Just to be clear, since you say you are dividing 100MHz to get 200 Hz. 
Are the "80" and "200" really Hz, or MHz? If they are Hz, then a DCM 
won't help.

Article: 102660
Subject: Re: DCM and Clock
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Fri, 19 May 2006 00:04:24 +0200
Links: << >>  << T >>  << A >>
Fizzy schrieb:
> Well when i said synchronous, i ment the 80 and 200 Hz clock will be
> extracted from the global clock. Now can i use DCM at that point where
> i want 80 Hz derived from system clock. Previously i know its been done

DCM ist for "high-speed stuff" only. 24 MHz++. Ok, there are few 
exceptions. But to cut this story short. Use ordinary counters to get 80 
Hz and 200Hz.

Regards
Falk

Article: 102661
Subject: Re: DCM and Clock
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 18 May 2006 15:43:41 -0700
Links: << >>  << T >>  << A >>
Duane,

Location (in this case) doesn't matter.  The tools take care of the 
timing through the use of the global clocks.

In your case, your divider will have to divide by a very large number, 
to get to 80 Hz.  DCMs can not do that.  The CLKDV is good for 1.5, 2, 
2.5, 3, 4, 5 ....15.

The CLKFX is good for M and D ranging from 2, to 31.

The input frequency must be greater than 24 MHz, or if using the DFS 
only, greater than 1 MHz - and the CLKFX must then be greater than 24 MHz.

Austin

Duane Clark wrote:

> Fizzy wrote:
> 
>> Hi,
>>
>> Considering me a newcommer to FPGA world. I am trying to use Virtex 4FX
>> series for a synchronous design, meaning i will be using only one clock
>> for whole design. Obviously if the main clock is running at 100 MHz, i
>> would have software components on FPGA running at different clock speed
>> like 80 Hz or 200 Hz. To acheive this i would have to divide the system
>> clock. 
> 
> 
> Just to be clear, since you say you are dividing 100MHz to get 200 Hz. 
> Are the "80" and "200" really Hz, or MHz? If they are Hz, then a DCM 
> won't help.

Article: 102662
Subject: Re: DCM and Clock
From: "Fizzy" <fpgalearner@gmail.com>
Date: 18 May 2006 15:44:55 -0700
Links: << >>  << T >>  << A >>
Then if that's the case DCM is only for high frequency what are my
option to have low skew and jitter on clock. Actually let me explain a
little bit so i can ask the question properly. I am designing an
application which will run on 200 Hz (Hertz just). I ahve system clock
running at 100 MHz. I have PowerPC405 running at 100 Mhz. The custom
design is connected to PPC405 through PLB. What is the best way to
clock now. What i was thinking earlier is to have on chip clock comming
to DCM and extract the required clock from it (200 Hz) but you guys
saying its not possible so waht are my options?


Article: 102663
Subject: Re: DCM and Clock
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 18 May 2006 15:50:39 -0700
Links: << >>  << T >>  << A >>
Fizzy,

Divide it down using CLB's which implement a synchronous counter.

Use the output as a clock.

Or use the carry output as a clock enable.

Austin

Fizzy wrote:

> Then if that's the case DCM is only for high frequency what are my
> option to have low skew and jitter on clock. Actually let me explain a
> little bit so i can ask the question properly. I am designing an
> application which will run on 200 Hz (Hertz just). I ahve system clock
> running at 100 MHz. I have PowerPC405 running at 100 Mhz. The custom
> design is connected to PPC405 through PLB. What is the best way to
> clock now. What i was thinking earlier is to have on chip clock comming
> to DCM and extract the required clock from it (200 Hz) but you guys
> saying its not possible so waht are my options?
> 

Article: 102664
Subject: Re: V5 and carry lookahead
From: "Peter Alfke" <peter@xilinx.com>
Date: 18 May 2006 15:56:43 -0700
Links: << >>  << T >>  << A >>
It is carry-look-ahead over 4 bits, ripple-carry between these 4-bit
slices.
The "effective ripple" delay is 21 ps per bit, and that's what counts.
And it includes the wire-delay.
Yes, the carry delay grows linearily with the bit-length, but it is a
very short delay per bit.
Peter Alfke, Xilinx Applications


Article: 102665
Subject: Re: DCM and Clock
From: "Fizzy" <fpgalearner@gmail.com>
Date: 18 May 2006 16:09:30 -0700
Links: << >>  << T >>  << A >>
Can i use multiple DCM to extract the required frequency ?? like Dasiy
chain


Article: 102666
Subject: Re: Virtex 5 announced and sampling: apologia for FX woes on V4
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 19 May 2006 11:15:27 +1200
Links: << >>  << T >>  << A >>
Paul Leventis wrote:
> Hi Antti,
> 
> No comment means that we could be coming out any time.
> 
> Max II is pretty awesome in many ways (performance, cost per logic
> function, etc.)  

  Yes, cost/FF is ok, but the 'cost/size of the smallest device' have 
taken quite a hike with this family.
  So it missed quite a large chunk of 7000 and 3000 markets.

Leaves AnaChip, Atmel, Lattice, Xilinx in the low power, small package 
arena.


> There are some applications where non-volatility and
> RAM would be handy, and these aren't addressed by Max II.  We've got
> that feedback and will factor it into future architecture decisions --
> but its always a trade-off of the cost (die-size impact) of adding
> additional features vs. the size of the market that those additional
> features will open to us.

You could always just admit it was an oversight, instead of using 40 odd
words to say the same thing... :)

-jg


Article: 102667
Subject: Re: Spartan 3 Readback
From: pbdelete@spamnuke.ludd.luthdelete.se.invalid
Date: 18 May 2006 23:29:10 GMT
Links: << >>  << T >>  << A >>
dand2k <dand@oz.net> wrote:
>Which Spartan3 device are you using? There is an eratta for the
>XC3S1500 stating that some of the engineering sample parts have a
>readback bug in them. You might want to search the Xilinx support
>website for readback failures, or consult the eratta pages for the
>device you are using.

Is there a workaround .. ?


Article: 102668
Subject: Re: DCM and Clock
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 18 May 2006 16:30:04 -0700
Links: << >>  << T >>  << A >>
Fizzy,

No, you can not (cascade DCMs to get 80Hz).

The DCM internal structures must be able to fit an entire clock period 
in the delay lines to operate.

The largest delay line will hold a 24 MHz period (~ 40 ns).

To hold an 80 Hz period would take far too large a structure.

That is what counters are made for.

Austin

Fizzy wrote:

> Can i use multiple DCM to extract the required frequency ?? like Dasiy
> chain
> 

Article: 102669
Subject: Processing DVI signals with an FPGA
From: patches11@gmail.com
Date: 18 May 2006 21:51:14 -0700
Links: << >>  << T >>  << A >>
A friend and I have come up with some interesting ideas that involve
messing around with DVI interfaces, and we'd like to physically
implement them. Neither of us has a whole lot of knowledge in the way
of FPGAs, just that they're faster for low-level tasks than a
firmware-based controller would be.

We have the basic resources for board production and schematic design,
but we need some direction, especially what to look for in the way of
FPGA selection (some microcontroller-like functionality is desired,
multiple hardware I2C interfaces are needed), and where we can get TMDS
transmitters and receivers.

We're going to be pushing the limits of DVI. Dual link, high frequency
(more than the single link limit of 165 MHz). The ability to buffer
rows of pixel data is likely needed, depending on how critical timing
is for TMDS transmitters.

Since we have so little knowledge of FPGA technology, we're looking for
someone to work with us on this project. Experience with generating DVI
signals is needed. We'd like this project to go commercial, but until
we build up some momentum (hope of a working prototype, working
prototype, working prototype that works...) it's just a neat thing to
work on.


Article: 102670
Subject: Spartan 3e sample: pack power control with M(1)?
From: "radarman" <jshamlet@gmail.com>
Date: 18 May 2006 22:14:17 -0700
Links: << >>  << T >>  << A >>
Guys/Gals,
I was lucky enough to score a Digilent Spartan 3e sample pack board.
This board is interesting in that it can only (generally) boot from
JTAG or NOR FLASH (BPI). It also is interesting because it has a
push-button power switch, instead of a normal switch or jumper.

On an unrelated note, I modded my board by routing four unused inputs
and CCLK to the unused 5 pins on the 40-pin connector. At first, I
thougth I could use CCLK to drive the pushbutton, but the datasheet
indicates that a clock is present during configuration for BPI mode.
That would most assuredly cause problems for the LTC 2950 power control
chip.

So, I started looking around on the board, and noticed that the
configuration mode pins were fairly clear, and become GPIO (except for
M2) after configuration. I also noticed that both BPI UP/DOWN and JTAG
require M1 to be high, or unconnected (since the pins have internal
pull-ups).

I figure it should be a cince to run M1 to the pushbutton - since the
pullup will keep the pin high during configuration. After
configuration, the design would be able to turn its own power off.
After configuration, the design could turn itself off by driving the
line low.

Next, with a bit of careful design, and use of tri-states, it should be
possible to emulate an open-collector output, and run the M1 pin
offboard to allow the power to be controlled by both the onboard
Spartan FPGA and offboard logic on a remote board. This would
essentially entail running a cable between the M1 jumper position and
the remote board.

The first problem with this idea is possible contention between the
FPGA and the remote logic. This is solveable by bringing up the
external board first and having it briefly drive the signal low to
begin the power up sequence on the sample back board, then tri-state
its output. To make sure the signal is solidly high - and because
during operation, both will be tri-stated, an external pull-up is added
on the Spartan board's Vcc.

Once configuration of the Spartan is complete, both devices switch
between low and tri-state to control power. The remote board can sense
when the Spartan board is powered by looking at the I/O pin, allowing
status to be read dynamically, rather than stored in a FF.

This should work, as it will take several hundreds of nanoseconds, or
even microseconds, for the power supplies to stabilize enough that the
Spartan 3E can begin configuration. So long as the control signal is
brief enough trigger the LTC 2950, but not so long as to confuse the
Spartan 3E (since we are manipulating a mode control pin), I don't see
why this shouldn't work.

Another problem would be that the remote board would, during it's own
configuration, pull-up the GPIO line to its own Vccio - which would
drive M1 while the Spartan is unpowered, causing latchup. I think that
a diode circuit could be used to prevent this, but I'm still not sure
how to wire it.

Is this a doable circuit, or am I risking damage to the Spartan 3e
board doing this? What would be a good way to handle the potential
latch-up problem, or is there one?

Thanks,
-Seth


Article: 102671
Subject: Re: V5 and carry lookahead
From: fpga_toys@yahoo.com
Date: 18 May 2006 23:24:05 -0700
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> It is carry-look-ahead over 4 bits, ripple-carry between these 4-bit
> slices.
> The "effective ripple" delay is 21 ps per bit, and that's what counts.
> And it includes the wire-delay.
> Yes, the carry delay grows linearily with the bit-length, but it is a
> very short delay per bit.
> Peter Alfke, Xilinx Applications

Hi Peter,

Any of the Xilinx guys do a performance study for wider adders with
this new carry architecture in relation to carry select or Brent-Kung
FPGA implementations, or maybe able to offer revised versions of those
for the V5 given new tradeoffs with the 6-LUT and carry changes?

Have fun!
John


Article: 102672
Subject: Re: Where can i get "Quartus II Device Information for UNIX & Linux CD"
From: "huymEmail@gmail.com" <huymEmail@gmail.com>
Date: 18 May 2006 23:24:43 -0700
Links: << >>  << T >>  << A >>
thank you.
I got it.


Article: 102673
Subject: Re: Xilinx Platform Cable USB protocol specifications and/or open-source firmware replacement
From: Eric Smith <eric@brouhaha.com>
Date: 18 May 2006 23:55:17 -0700
Links: << >>  << T >>  << A >>
Ed McGettigan <ed.mcgettigan@xilinx.com> writes:
> Xilinx software is designed to work with Xilinx communication cables
> and some selected 3rd party equipment.  Our software is tightly
> coupled to the communication hardware and we do not provide general
> access to the driver/software APIs.

That's the part that we're questioning.  If you had a publicly
documented API for the interface between Impact and the driver, you
could get two main benefits:

1)  Third party hardware that came with drivers supporting your API,
    so they could work with Impact.

2)  Third party software (e.g., JTAG debuggers for various soft core
    processors and the like) that could work with Xilinx cables (or with
    the third party hardware in part 1).

Cost:  A few weeks of an engineer's time to document the API.  I suspect
that there's already an API document which would simply need to be
sanitized for public release.

Drawbacks:

1)  Availability of third-party cables that work with Impact might
    slightly reduce sales of PCIV and PCUSB.  Presumably Xilinx doesn't
    view PCIV and PCUSB as a major profit center, and it would overall
    be of greater benefit to Xilinx's bottom line to have more third
    party support even if it might slightly reduce the sales of PCIV and
    PCUSB.

2) The API would be semi-frozen.  Xilinx could change it with future
    software releases, but then the third-party drivers and software
    would have to be revised by those third parties.  However, since
    JTAG seems to be a reasonably mature interface, and Xilinx
    presumably understands their own requirements for the JTAG API, it
    seems unlikely that the API would need to be revised very often.

Eric

Article: 102674
Subject: Error in XPS 7.1 mb_opb_wrapper
From: "savs" <vidyutg@gmail.com>
Date: 18 May 2006 23:56:33 -0700
Links: << >>  << T >>  << A >>
Hey,
We are facing this error in generating the bitstream in XPS 7.1.

NgdBuild:76 - File "C:/ledplease/implementation/mb_opb_wrapper.ngc"
cannot
be merged into block "mb_opb" (TYPE="mb_opb_wrapper") because one or
more
pins on the block, including pin "Sl_DBusEn<3>", were not found in the
file.
Please make sure that all pins on the instantiated component match pins
in
the lower-level design block (irrespective of case).  If there are
bussed
pins on this block, make sure that the upper-level and lower-level
netlists
use the same bus-naming convention.
NgdBuild:604 - logical block 'mb_opb' with type 'mb_opb_wrapper' could
not
be resolved. A pin name misspelling can cause this, a missing edif or
ngc
file, or the misspelling of a type name. Symbol 'mb_opb_wrapper' is not
supported in target 'spartan3'.

please help us out.. wt do these errors mean?? how to get rid of them??
thanks in advance..

SAVS




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