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 100500

Article: 100500
Subject: Re: Distributed Arithmetic
From: "Peter Alfke" <peter@xilinx.com>
Date: 10 Apr 2006 11:42:07 -0700
Links: << >>  << T >>  << A >>
If you use both clock edges, any path between the two clock domains has
less than half a clock period available ( since it also must accomodate
any duty-cycle difference from 50%.)
That's not a smart design decision, if you want to achieve high
performance.
Peter Alfke


Article: 100501
Subject: Re: rather simple gsr Q
From: Brian Philofsky <brian.philofsky@no_xilinx_spam.com>
Date: Mon, 10 Apr 2006 13:47:11 -0600
Links: << >>  << T >>  << A >>

Roger,

    There is not a way to directly view the GSR signal within a design 
but there is a pseudo-way to get it.  If you instantiate an FD, and tie 
the input to Vcc and connect your clock, the FF will reset to zero when 
GSR is asserted and go to one the first clock cycle GSR is deasserted. 
You can invert the polarity by setting the INIT attribute to a one and 
tying a ground to the input.  You may need to place some attributes on 
the FF to make sure the tools do not optimize it away thinking it is a 
constant but in theory, that should give to a look at to when GSR is 
asserted for the rest of your design.  I would not know whey you would 
every try to build memory within and FPGA out of LUTs configured as nand 
and inv gates when you can have much more efficient use of the LUTs when 
configured as memories but to each their own.

--  Brian

Roger Bourne wrote:

> 
> What I meant by the above was:
> Is there a way to insert the FPGA's GSR net in a shematic design?
> 
> The reason I was asking the question was because I was thinking about
> the situation were nand & inv gates are used to constructed a bulky
> (and slow) memory element. (If such a construction is permitted in an
> fpga) . In that situation, the fpga's gsr net would come in handy for
> the memory's element initialization. 
> 
> -Roger
> 

Article: 100502
Subject: Interfacing to DDS v5.0 in System Generator
From: "Ira Thorpe" <ithorpe@backpacker.com>
Date: 10 Apr 2006 12:53:09 -0700
Links: << >>  << T >>  << A >>
I have a system generator model that utilizes the DDS v4.1 block.  I
wish to upgrade to the DDS v5.0 block to take advantage of some of the
new features.  However I have noticed that the interface has changed.
   My specific application utilizes the phase increment register and a
constant phase offset of zero. In my v4.0 design, the accumulator width
is set to 32 bits which configures the data input as a 32.32 unsigned
integer.  The output width is also configurable I use a 16-bit width,
which gives a 16.15 signed output and a signal ranging between +/- 1
peak-to-peak.
   When I try using the v5.0 core with the Frequency set to
programmable, it asks for a signed input at the data port.  That seems
odd because the value should always be positive. The width of this
input seems to be set by the frequency resolution.  Also I see nowhere
where I can set the output resolution or amplitude and the signal is
now between +/- 0.5 rather than +/- 1.  How can I configure the new
core to have the same interfaces as the old ones.? Thanks,
-Ira Thorpe


Article: 100503
Subject: Re: rather simple gsr Q
From: "Roger Bourne" <rover8898@hotmail.com>
Date: 10 Apr 2006 13:20:12 -0700
Links: << >>  << T >>  << A >>

Brian Philofsky wrote:
> Roger,
>
>     There is not a way to directly view the GSR signal within a design
> but there is a pseudo-way to get it.  If you instantiate an FD, and tie
> the input to Vcc and connect your clock, the FF will reset to zero when
> GSR is asserted and go to one the first clock cycle GSR is deasserted.
> You can invert the polarity by setting the INIT attribute to a one and
> tying a ground to the input.  You may need to place some attributes on
> the FF to make sure the tools do not optimize it away thinking it is a
> constant but in theory, that should give to a look at to when GSR is
> asserted for the rest of your design.  I would not know whey you would
> every try to build memory within and FPGA out of LUTs configured as nand
> and inv gates when you can have much more efficient use of the LUTs when
> configured as memories but to each their own.
>

I do not actually plan to build memory elements in the FPGA. I only
cited as a possible academic situation where one migth require the
FPGA's gsr signal.

In regard to your proposd idea: Great idea! It needs a clock and as
such the oscillator startup time is added to the gsr pulse, but that
does not matter. Until the clock shows up, the gsr can be asserted or
negated --> gsr being held or released will will have no impact if
there is no clock! Thx!

-Roger


Article: 100504
Subject: Re: ROM resource sharing
From: "mikel" <mikel262@gmail.com>
Date: 10 Apr 2006 13:51:56 -0700
Links: << >>  << T >>  << A >>
John,

Actually, the LUT/ROM is replicated twice as much as I said before (18
times 1st stage, 22 times 2nd stage). Synthesis tool was smart enough
to reduce size of ROMs memory bits from 35840 bits to 25600 bits (there
are few identical values inside every ROM, synthesis tool placed
additional decoding logic for input address to reduce memory size). But
this is still too much.

> You have 20 different addresses for the 20 replications, correct?

yes, I have different address for every ROM access, and I need to
access all ROMs at the same clock cycle for performance.

> Which FPGA family are you using?

I want design to be generic, though I ordered Virtex 2Pro board from
Digilent so this will be my target.

Michal K


Article: 100505
Subject: Re: C-Compiler for free VHDL controller core ?
From: Peter Winkler <idontwant@totell.com>
Date: Mon, 10 Apr 2006 23:05:52 +0200
Links: << >>  << T >>  << A >>
Thanks for all your input.

I think it makes most sense for me to have a closer look
at PicoBlaze.

Is there a good place for PicoBlaze designs apart from the
Xilinx PicoBlaze home ? I mean some kind of community like
avrfreaks or the piclist ? A place to ask stupid newbie
questions, you know ;)

P.


Article: 100506
Subject: Re: ROM resource sharing
From: "John_H" <johnhandwork@mail.com>
Date: Mon, 10 Apr 2006 21:22:29 GMT
Links: << >>  << T >>  << A >>
"mikel" <mikel262@gmail.com> wrote in message 
news:1144702316.464096.232020@i40g2000cwc.googlegroups.com...
> John,
>
> Actually, the LUT/ROM is replicated twice as much as I said before (18
> times 1st stage, 22 times 2nd stage). Synthesis tool was smart enough
> to reduce size of ROMs memory bits from 35840 bits to 25600 bits (there
> are few identical values inside every ROM, synthesis tool placed
> additional decoding logic for input address to reduce memory size). But
> this is still too much.
>
>> You have 20 different addresses for the 20 replications, correct?
>
> yes, I have different address for every ROM access, and I need to
> access all ROMs at the same clock cycle for performance.
>
>> Which FPGA family are you using?
>
> I want design to be generic, though I ordered Virtex 2Pro board from
> Digilent so this will be my target.
>
> Michal K

If you have 40 different 6-bit addresses for 40 different 64x14 ROMs, I 
don't see how you can do better than 40instances*4LUTs*14bits = 2240 LUTs 
(or 280 CLBs in your current architecture).  Implementing each ROM with 
fewer than 4 LUTs per bit would be possible for some 6-in-1 out functions.

Each ALM in the Stratix-II series (roughly equivalent but twice the LUT size 
as a Xilinx slice) can provide a 64x1 ROM.

You could use a BlockRAM to provide 2 ports of 14 bits each (up to 36 bits 
available) to displace 56 LUTs each.  The 4.5 kbit Altera M4K blocks would 
be more "efficent" since only 64 entries are needed in your application and 
there are typically many more M4K blocks than BlockRAMs in equivalent A vs X 
devices.

It's quite possible you could time-multiplex your 14-bit lookups at 2x, 3x, 
even 4x your main design speed since the ROM lookup time as implemented in 
distributed CLB SelectRAM is one LUT plus MUXF5 plus MUXF6, roughly less 
than 2 levels of logic in a pipelined implementation.

The bottom line is that you have to pull out 40 unique 14-bit values.  If 
there is no convenient way to reduce the uniqueness, the replication has to 
be there.

What does help is that each LUT or LE can give you 16 bits of ROM.  Each ALM 
can give you 64 bits of ROM. 



Article: 100507
Subject: Re: C-Compiler for free VHDL controller core ?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 11 Apr 2006 09:42:13 +1200
Links: << >>  << T >>  << A >>
Peter Winkler wrote:
> Thanks for all your input.
> 
> I think it makes most sense for me to have a closer look
> at PicoBlaze.
> 
> Is there a good place for PicoBlaze designs apart from the
> Xilinx PicoBlaze home ? I mean some kind of community like
> avrfreaks or the piclist ? A place to ask stupid newbie
> questions, you know ;)

You should also look at the extended variant :

http://bleyer.org/pacoblaze/

plus rhere are good links on this page.

-jg


Article: 100508
Subject: Configuration Rate with multiple .bit files
From: "Jeff Brower" <jbrower@signalogic.com>
Date: 10 Apr 2006 15:11:58 -0700
Links: << >>  << T >>  << A >>
All-

I am combining 2 .bit files into one .mcs for an XCF16P (XC3S1500-676
and XC3S1000-456).  In both cases I've set the Configuration Rate
parameterto 50.  It takes 200 msec for DONE to go high -- that sounds
too slow.

Can this be right?  Which .bit file takes precedence?  Is there
something additional that needs to be set?

-Jeff


Article: 100509
Subject: Re: FPGA FAQ and the spam problem
From: ziggy <ziggy@fakedaddress.com>
Date: Mon, 10 Apr 2006 22:23:46 GMT
Links: << >>  << T >>  << A >>
In article <1144487259.825320.212420@i40g2000cwc.googlegroups.com>,
 burn.sir@gmail.com wrote:

> Having seen way too much spam on this newsgroup lately, I have come
> with a possible solution that just might work.
> 
> Add a section to FPGA FAQ where the known names on the newsgroup will
> list the companies they recommend (plus some explanation). Next time
> someone spams the list about "high quality PCB", or what the hell it
> is, we post a polite response saying that no one should support spammer
> companies and we suggest you choose another manufacture from the list
> below (link to FPGA-FAQ follows).Given that spammers only care about
> money, seeing they are loosing customers might stop them from spamming
> the list.
> 
> This way, you will also support the local companies that you think are
> doing a good job ;)
> 
> 
> We could also add another section about newsgroup netiquette, 3leet
> English and what we think about doing other peoples homework. This is
> of course not as big problem as spammer, but it is still a little bit
> annoying sometimes.
> 
> 
> Furthermore, someone should contact Google, notifying them about the
> existence of a group FAQ. I think the biggest problem with the FAQ is
> that the ones that dont know about it are the ones that really need to
> read it :)
> 
> 
> regards
>  - Bruns

Considering they dont read responses, and often its via a 'bot' anyway, 
i dont think it will help..

Though supporting good companies is always a good thing to do.

Article: 100510
Subject: Re: Configuration Rate with multiple .bit files
From: "Alan Nishioka" <alan@nishioka.com>
Date: 10 Apr 2006 16:09:20 -0700
Links: << >>  << T >>  << A >>
Jeff Brower wrote:
> I am combining 2 .bit files into one .mcs for an XCF16P (XC3S1500-676
> and XC3S1000-456).  In both cases I've set the Configuration Rate
> parameterto 50.  It takes 200 msec for DONE to go high -- that sounds
> too slow.

XCS1500 config is 5,214,784 bits
XCS1000 config is 3,223,488 bits

( 5214784+3223488 bits ) / 50 MHz = 169ms (as a lower bound)

How much faster do you expect it to be?

Alan Nishioka


Article: 100511
Subject: Simulating TFT core in EDK
From: "Jon" <jda59@byu.edu>
Date: 10 Apr 2006 17:25:07 -0700
Links: << >>  << T >>  << A >>
I'm trying to use the TFT IP core provided by Xilinx and am unable to
simulate the entire system using ModelSim 6.1e.  I've compiled the EDK
and ISE libraries correctly, and I'm simply trying to find a way to let
my verilog files know where to find the necessary files.  When
compiling the TFT piece, I receive the following error messages:

# ** Error: (vsim-3033)
C:/vga_dcr_ddr/pcores/plb_tft_cntlr_ref_v1_00_d/hdl/verilog/plb_tft_cntlr_ref.v(501):
Instantiation of 'BUFG' failed. The design unit was not found.
#         Region: /system/vga_framebuffer/vga_framebuffer/BUFG_pixclk
#         Searched libraries:
#             plb_tft_cntlr_ref_v1_00_d
# ** Error: (vsim-3033)
C:/vga_dcr_ddr/pcores/plb_tft_cntlr_ref_v1_00_d/hdl/verilog/plb_tft_cntlr_ref.v(526):
Instantiation of 'DCM' failed. The design unit was not found.
#         Region: /system/vga_framebuffer/vga_framebuffer/DCM_pixclk
#         Searched libraries:
#             plb_tft_cntlr_ref_v1_00_d

The only thing I can think to do would be to copy the BUFG and DCM
components from the ISE library into the simulation directory so that
the compiler can find them.  But, in order to do that, I think I need
to modify the _info file that sits in the root directory to indicate
that those files are there.

Are there any other steps that I'm missing?


Article: 100512
Subject: Re: Configuration Rate with multiple .bit files
From: "Jeff Brower" <jbrower@signalogic.com>
Date: 10 Apr 2006 17:27:09 -0700
Links: << >>  << T >>  << A >>
Alan-

Thanks for your reply.

> XCS1500 config is 5,214,784 bits
> XCS1000 config is 3,223,488 bits
>
> ( 5214784+3223488 bits ) / 50 MHz = 169ms (as a lower bound)
>
> How much faster do you expect it to be?

The first FPGA has a PCI core.  We were hoping to boot under 100 msec.
Is there a way to go faster than 50 MHz without resorting to external
clock + INIT gating circuitry?

-Jeff


Article: 100513
Subject: reading vhdl files
From: ace.shikha@gmail.com
Date: 10 Apr 2006 18:10:28 -0700
Links: << >>  << T >>  << A >>
hi

i am working on mp3 decoder in vhdl. i need to read the bitstream and
decode it. the bitstream is in a file so i used the commands for file
reading. but i found that quartus doesn't support the read, readin,
write, writein commands, i.e textio is not supported. what should i do
now to read that bitstream..plz suggest.

regards
shikha


Article: 100514
Subject: Re: Simulating TFT core in EDK
From: "johnp" <johnp3+nospam@probo.com>
Date: 10 Apr 2006 19:01:41 -0700
Links: << >>  << T >>  << A >>
Are you including the unisims directory in the verilog simulation with
a -y option?  You need to tell Verilog where the models for the BUFG
and the DCM live.

John Providenza


Article: 100515
Subject: Re: Configuration Rate with multiple .bit files
From: "Alan Nishioka" <alan@nishioka.com>
Date: 10 Apr 2006 19:17:04 -0700
Links: << >>  << T >>  << A >>
Jeff Brower wrote:
> The first FPGA has a PCI core.  We were hoping to boot under 100 msec.
> Is there a way to go faster than 50 MHz without resorting to external
> clock + INIT gating circuitry?

I don't know.  This is one of the reasons I have always used external
pci bridges.  But I thought there was more time during pci config.

All I can think of is using two config proms or using parallel config
mode.

Alan Nishioka


Article: 100516
Subject: Re: Simulating TFT core in EDK
From: "Jon" <jda59@byu.edu>
Date: 10 Apr 2006 19:17:25 -0700
Links: << >>  << T >>  << A >>
I'm assuming by that I need to put the -y option in the system.do file
that gets generated by the EDK...

If so, I'll try it and see what I can come up with.  Thanks.


Article: 100517
Subject: Re: Configuration Rate with multiple .bit files
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 11 Apr 2006 15:06:36 +1200
Links: << >>  << T >>  << A >>
Alan Nishioka wrote:
> Jeff Brower wrote:
> 
>>The first FPGA has a PCI core.  We were hoping to boot under 100 msec.
>>Is there a way to go faster than 50 MHz without resorting to external
>>clock + INIT gating circuitry?
> 
> 
> I don't know.  This is one of the reasons I have always used external
> pci bridges.  But I thought there was more time during pci config.
> 
> All I can think of is using two config proms or using parallel config
> mode.

On that line, what about one of the 150Mbit Winbond SPI memories, and
a small CPLD to turn it into parallel-config ?

-jg


Article: 100518
Subject: Re: Configuration Rate with multiple .bit files
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 11 Apr 2006 15:07:30 +1200
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> Alan Nishioka wrote:
> 
>> Jeff Brower wrote:
>>
>>> The first FPGA has a PCI core.  We were hoping to boot under 100 msec.
>>> Is there a way to go faster than 50 MHz without resorting to external
>>> clock + INIT gating circuitry?
>>
>>
>>
>> I don't know.  This is one of the reasons I have always used external
>> pci bridges.  But I thought there was more time during pci config.
>>
>> All I can think of is using two config proms or using parallel config
>> mode.
> 
> 
> On that line, what about one of the 150Mbit Winbond SPI memories, and
oops, that should be 150Mbd, of course....


Article: 100519
Subject: very slow pull-up with CPLD design
From: shawnn@gmail.com
Date: 10 Apr 2006 20:19:43 -0700
Links: << >>  << T >>  << A >>
We are using a Lattice LC4256V CPLD for a new design and we're having
some problems with open drain outputs + 5V pullups. We've debuged and
removed items from the system to the point where we have the single
CPLD (pins configured 3.3v CMOS open drain) connected to a 4.7K
resistor to +5V.

We configured the pins to output a 4MHz square wave for testing. When
we hook a scope up to the pins, we see that the voltage rises at a very
slow rate at the high edge of the clock pulse and only makes it to
about 2V before the falling edge takes the output low. When we remove
the pullups and set the pins to normal 3.3V mode we get a clean square
wave, it is only when using pullups that problems are created.

Any ideas on why the pullup is taking so long to bring the pin voltage
to 5V? We have used 4.7K pullups with other FPGA / CPLD designs before
in designs faster than 4 MHz without any problems. Doing the math, it
seems the acting capacitence from the CPLD is something like 15uF to
have the pullup rise so slowly. Am I doing something wrong here?


Article: 100520
Subject: Re: very slow pull-up with CPLD design
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 11 Apr 2006 15:56:55 +1200
Links: << >>  << T >>  << A >>
shawnn@gmail.com wrote:
> We are using a Lattice LC4256V CPLD for a new design and we're having
> some problems with open drain outputs + 5V pullups. We've debuged and
> removed items from the system to the point where we have the single
> CPLD (pins configured 3.3v CMOS open drain) connected to a 4.7K
> resistor to +5V.
> 
> We configured the pins to output a 4MHz square wave for testing. When
> we hook a scope up to the pins, we see that the voltage rises at a very
> slow rate at the high edge of the clock pulse and only makes it to
> about 2V before the falling edge takes the output low. When we remove
> the pullups and set the pins to normal 3.3V mode we get a clean square
> wave, it is only when using pullups that problems are created.
> 
> Any ideas on why the pullup is taking so long to bring the pin voltage
> to 5V? We have used 4.7K pullups with other FPGA / CPLD designs before
> in designs faster than 4 MHz without any problems. Doing the math, it
> seems the acting capacitence from the CPLD is something like 15uF to
> have the pullup rise so slowly. Am I doing something wrong here?

The maths is suspect if you get 15uF.

4MHz is 125ns H/L, and a 125 ns Tau, is 26pF/4K7

So, your symptoms indicate ~26pf system c : That is highish,
but not outlandish. What else is this connected to :
Loads, track etc ?

Simple solution is to lower the pullup...

-jg




Article: 100521
Subject: Re: Distributed Arithmetic
From: "nimayshah" <nimayshah@gmail.com>
Date: 10 Apr 2006 21:03:03 -0700
Links: << >>  << T >>  << A >>
Thank you peter, but do you have any idea about the block ram issue?
That is more important to me right now.
Nimay


Article: 100522
Subject: Re: Very basic question
From: Tommy Thorn <foobar@nowhere.void>
Date: Mon, 10 Apr 2006 21:10:01 -0700
Links: << >>  << T >>  << A >>
John_H wrote:
> "Fizzy" <fpgalearner@gmail.com> wrote in message 
> news:1144690848.814144.204880@t31g2000cwb.googlegroups.com...
> ...
>> Why do we need
>> clock on FPGA when our design does not have any clock input[?]

John is right of course, but to make it perfectly clear: if you have no 
clocked logic, that is, all your output are combinatorial functions of 
the input, then you don't need to provide a clock to your FPGA at all 
and the design will still work as expected.

However, using an FPGA in such a situation would be wasting most of the 
expensive machinery that is an FPGA.  Maybe you only really need a CPLD.

Tommy

Article: 100523
Subject: Area Constraints in Xilinx
From: "ssirowy@gmail.com" <ssirowy@gmail.com>
Date: 10 Apr 2006 21:27:23 -0700
Links: << >>  << T >>  << A >>
Hi,
   Im somewhat new to the ISE and was wondering if there was a way to
give the Xilinx tool an area constraint ( say in number of LUT's used)
for a given VHDL implementation? For instance, I have created a module
that I want to restrict to 500 LUT's if possible, because I will be
having other modules that will need the pending space.  Im not exactly
sure how I would go about this using the PACE tool, and any help would
be appreciated. I am sure there is a trivial way to do it, but I seem
to be overlooking it at the moment


Article: 100524
Subject: Re: Configuration Rate with multiple .bit files
From: "Jeff Brower" <jbrower@signalogic.com>
Date: 10 Apr 2006 22:31:22 -0700
Links: << >>  << T >>  << A >>
Alan-

> I don't know.  This is one of the reasons I have always used external
> pci bridges.  But I thought there was more time during pci config.

I looked up the PCI 2.3 spec, time to first config access is 2^25
clocks, or about 250 msec at 133 MHz.  We have customers though who
prize fast turn-on time, so I'm always looking to get under that 100
msec mark.

> All I can think of is using two config proms or using parallel config
> mode.

2 config proms?  I wish.  The board is jammed -- 16 layers, blind vias,
lots of things like 201s and 2x3 mm oscillators.  Pic of the board is
here:

  http://www.signalogic.com/sigc5561_ptmc.htm

Parallel config maybe... need to think about that.

-Jeff




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