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 120200

Article: 120200
Subject: Raggedstone1 Brackets
From: John Adair <g1@enterpoint.co.uk>
Date: Sun, 03 Jun 2007 02:20:45 -0700
Links: << >>  << T >>  << A >>
For those of you that were desperate for Raggedstone1 brackets we
finally have them in stock. They won't show as stock on the shop
website for a week or so due to staff holidays but we do have a lot of
them available so contact us on our board sales email if you need one
in a hurry. Apologies for the delay in having these available but we
got caught out again by demand of the Raggedstone1 + bracket.

To improve our mechanical supply issues we have added to our
manufacturing operation a limited mechanical processing capability for
producing brackets and small metalwork as part of what we now do. As a
side benefit of this we can for OEM customers we can now produce
fairly small run custom brackets for any of our PCI / PCI-E boards
etc. at what we consider a reasonable cost.

John Adair
Enterpoint Ltd.


Article: 120201
Subject: Re: Weekend pop quiz
From: "Symon" <symon_brewer@hotmail.com>
Date: Sun, 3 Jun 2007 11:49:00 +0100
Links: << >>  << T >>  << A >>
"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message 
news:1180762018.504484.139350@i38g2000prf.googlegroups.com...
> On Jun 1, 6:38 pm, Marlboro <cco...@netscape.net> wrote:
>> A memory block has been told having "read latency of 3", assume the
>> read pointer has been reset
>>
>> How many read clocks does it take to read out the first 10 bytes?
>
> As many as it has too, gosh!!
>
> Tommy (applogies to Napoleon)
>
I thought the answer to pop quizzes was to 'shoot the hostage'? i.e. Jeff 
Daniels?
Whatever, don't let the answer be below 50 or the memory will blow up.
Syms. 



Article: 120202
Subject: Re: FIFO : Synchronous WRITE, Asynchronous READ ?
From: "Symon" <symon_brewer@hotmail.com>
Date: Sun, 3 Jun 2007 12:20:34 +0100
Links: << >>  << T >>  << A >>
"Pasacco" <pasacco@gmail.com> wrote in message 
news:1180790373.677725.6920@q66g2000hsg.googlegroups.com...
>
> I am not finding a way to implement "Asynchronous READ" in BRAM.
>
The bodgers way to do this is to use the falling edge of the clock on the 
read section. Nasty though!
HTH, Syms. 



Article: 120203
Subject: Re: 180 differential inputs each 800Mbps using V5
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sun, 03 Jun 2007 13:06:30 +0100
Links: << >>  << T >>  << A >>
On Sat, 02 Jun 2007 08:45:17 -0700, austin <austin@xilinx.com> wrote:

>Test01,
>

>PCB layout will be a real challenge, as you will need to make all traces 
>the same length (including the traces in the package to the die).

Where do you find the package internal trace lengths documented, so that
you can allow for them in your PCB trace length calculations?

Answer Record 18078 says
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iCountryID=1&iLanguageID=1&getPagePath=18078&BV_SessionID=@@@@1060307370.1180870386@@@@&BV_EngineID=ccchaddklgmehljcefeceihdffhdfkf.0

with respect to the common FG or BG packages,
"since these package structures do not lend themselves to this kind of
analysis, Xilinx does not have this information available."

For other packages it refers to AR15321, where you find that for
Virtex-II era devices (in unspecified packages) the information IS
available but you have to open a webcase to get it.

- Brian

Article: 120204
Subject: Re: FIFO : Synchronous WRITE, Asynchronous READ ?
From: Marlboro <ccon67@netscape.net>
Date: Sun, 03 Jun 2007 05:31:26 -0700
Links: << >>  << T >>  << A >>
On Jun 3, 6:20 am, "Symon" <symon_bre...@hotmail.com> wrote:
> "Pasacco" <pasa...@gmail.com> wrote in message
>
> news:1180790373.677725.6920@q66g2000hsg.googlegroups.com...
>
> > I am not finding a way to implement "Asynchronous READ" in BRAM.
>
> The bodgers way to do this is to use the falling edge of the clock on the
> read section. Nasty though!
> HTH, Syms.

If there's clock in the FIFO output domain, just don't see why he
needs Async read ???

Don't let me guess it correct, the reason he wanna do this because
there's no read clock at all.  If that's true, another nasty way to do
this is to generate a "glitch" from any changing in the address bits.
Make sure it meets the BRAM setup time then the glitch can be used as
the read clock











Article: 120205
Subject: Microcontrollers have a better predictable time behaviour than FPGAs
From: jidan1@hotmail.com
Date: Sun, 03 Jun 2007 06:35:36 -0700
Links: << >>  << T >>  << A >>
"Microcontrollers have a better predictable time behaviour, because
their circuit is integrated in silicon and is unchangeable; unlike
FPGAs which have variable timing performances."

Is this statement correct?

Jidan


Article: 120206
Subject: Re: Microcontrollers have a better predictable time behaviour than FPGAs
From: "Symon" <symon_brewer@hotmail.com>
Date: Sun, 3 Jun 2007 15:19:50 +0100
Links: << >>  << T >>  << A >>
<jidan1@hotmail.com> wrote in message 
news:1180877736.514050.260890@g4g2000hsf.googlegroups.com...
> "Microcontrollers have a better predictable time behaviour, because
> their circuit is integrated in silicon and is unchangeable; unlike
> FPGAs which have variable timing performances."
>
> Is this statement correct?
>
> Jidan
>
Jidan,
If you're gonna post your homework questions, please do us the courtesy of 
posting from somewhere else other than tuwien.ac.at.
Thanks, Symon. 



Article: 120207
Subject: Re: Microcontrollers have a better predictable time behaviour than
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Mon, 04 Jun 2007 03:15:14 +1200
Links: << >>  << T >>  << A >>
jidan1@hotmail.com wrote:
> "Microcontrollers have a better predictable time behaviour, because
> their circuit is integrated in silicon and is unchangeable; unlike
> FPGAs which have variable timing performances."
> 
> Is this statement correct?

Of course : One is Hard, and one is Soft, how can something
that is soft have "a better predictable time behaviour" ?

You can find other examples to prove this in the data sheets too:

Look at the uC with 1-2% OnChipOsc Specs, and then look
for any tolerance specs on the FPGA on chip Osc.

Again, uC clearly have "a better predictable time behaviour".

You should win this debate easily.

-jg


Article: 120208
Subject: Re: FIFO : Synchronous WRITE, Asynchronous READ ?
From: Duane Clark <junkmail@junkmail.com>
Date: Sun, 03 Jun 2007 15:22:08 GMT
Links: << >>  << T >>  << A >>
Marlboro wrote:
> On Jun 3, 6:20 am, "Symon" <symon_bre...@hotmail.com> wrote:
>> "Pasacco" <pasa...@gmail.com> wrote in message
>>
>> news:1180790373.677725.6920@q66g2000hsg.googlegroups.com...
>>
>>> I am not finding a way to implement "Asynchronous READ" in BRAM.
>> The bodgers way to do this is to use the falling edge of the clock on the
>> read section. Nasty though!
>> HTH, Syms.
> 
> If there's clock in the FIFO output domain, just don't see why he
> needs Async read ???
> 

By "Async read", he means that he doesn't want to wait one clock after 
applying the read address before getting the data out.

Article: 120209
Subject: Re: 180 differential inputs each 800Mbps using V5
From: Test01 <cpandya@yahoo.com>
Date: Sun, 3 Jun 2007 08:39:36 -0700
Links: << >>  << T >>  << A >>
Brian,

Thanks for sharing this information. Certiainly when doing the PCB layout, we will need to take the internal trace length of high speed (800Mbps) signals.

Article: 120210
Subject: Re: Microcontrollers have a better predictable time behaviour than FPGAs
From: mk <kal*@dspia.*comdelete>
Date: Sun, 03 Jun 2007 15:48:47 GMT
Links: << >>  << T >>  << A >>
On Mon, 04 Jun 2007 03:15:14 +1200, Jim Granville
<no.spam@designtools.maps.co.nz> wrote:
>
>Again, uC clearly have "a better predictable time behaviour".
>
>You should win this debate easily.
>
>-jg

Please don't feed the monkeys. They're getting a balanced diet from
the zoo-keeper already.

Article: 120211
Subject: Re: Microcontrollers have a better predictable time behaviour than FPGAs
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: 3 Jun 2007 16:03:52 GMT
Links: << >>  << T >>  << A >>
In news:4662dab4$1@clear.net.nz timestamped Mon, 04 Jun 2007 03:15:14
+1200, Jim Granville <no.spam@designtools.maps.co.nz> posted:
     "jidan1@hotmail.com wrote:
     > "Microcontrollers have a better predictable time behaviour, because
     > their circuit is integrated in silicon and is unchangeable; unlike
     > FPGAs which have variable timing performances."
     >
     > Is this statement correct?
     
     Of course : One is Hard, and one is Soft, how can something
     that is soft have "a better predictable time behaviour" ?
     
     You can find other examples to prove this in the data sheets too:
     
     Look at the uC with 1-2% OnChipOsc Specs, and then look
     for any tolerance specs on the FPGA on chip Osc.
     
     Again, uC clearly have "a better predictable time behaviour".
     
     You should win this debate easily."


Though not necessarily about microcontrollers, it was argued that
newer processors are less predictable than FPGAs in M. Ward;
N. C. Audsley, "Hardware Compilation of Sequential Ada", CASES 2001.

Article: 120212
Subject: Re: Microcontrollers have a better predictable time behaviour than
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Sun, 03 Jun 2007 18:16:19 +0200
Links: << >>  << T >>  << A >>
jidan1@hotmail.com schrieb:
> "Microcontrollers have a better predictable time behaviour, because
> their circuit is integrated in silicon and is unchangeable; unlike
> FPGAs which have variable timing performances."
> 
> Is this statement correct?

You could also try to compare a house with bricks. Yes, you can build a
house out of bricks (but also out of something else, like timber). And
yes - if bricks are fixed to a structure, that we call a house you can
compare it with a house made of timber - or even with a brick-wall.

A FPGA is like bricks and a microcontroller is like a house in this
comparison.

Ralf

Article: 120213
Subject: Re: ngdbuild error : multiple drivers and driving non buffer primitives
From: motty <mottoblatto@yahoo.com>
Date: Sun, 03 Jun 2007 09:24:35 -0700
Links: << >>  << T >>  << A >>
> ERROR:NgdBuild:924 - input pad net 'myclk' is driving non-buffer
> primitives:
>      pin C on block my_user_command_register_1 with type FDE,

I think it looks like your clock input it directly connected from the
input pad to logic.  You need to first connect it to some type of
global clock buffer or other clock resource before using it in the
fabric.

And it looks like you have placed constraints incorrectly for the
led_error_output.  It should be an ouput signal at your top level.
Then the syntax in the UCF is:

NET "led_error_output" LOC = "whatever" | IOSTANDARD = "whatever" ;






Article: 120214
Subject: Altera Serial Flash Loader (SFL) question
From: Ben Jackson <ben@ben.com>
Date: Sun, 03 Jun 2007 14:27:36 -0500
Links: << >>  << T >>  << A >>
I just found the Serial Flash Loader (SFL) which allows you to program
an Active Serial (AS) part (EPCSx) using the JTAG port, sparing you the
need for a dedicated serial config header.

According to AN370:

	http://www.altera.com/literature/an/an370.pdf

this is made possible by a megawizard function which can be in your
design or a stub design which is loaded expressly for doing the update.
The programming tool in Quartus recognizes the "JIC" files and selects
a "factory default SFL image" to accomplish the loading.  There are two
rows and thus two "program" checkboxes, and I assumed you could simply
un-check the FPGA part if you included SFL in your design, but the
boxes are locked together.

What is the trick for using the SFL embedded in your design instead of
"factory default SFL image"?

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 120215
Subject: Synchronization of instruction with clock
From: rajiv <kahnani@gmail.com>
Date: Sun, 03 Jun 2007 12:37:06 -0700
Links: << >>  << T >>  << A >>
we are making bram controller which takes instruction from microblaze
processor.we have to write a c program giving
read and write request to bram controller.could anyone can tell us a
way to synchronize our instruction with clock pulse ?


Article: 120216
Subject: Re: Microcontrollers have a better predictable time behaviour than FPGAs
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sun, 03 Jun 2007 16:09:41 -0700
Links: << >>  << T >>  << A >>
On Sun, 03 Jun 2007 06:35:36 -0700, jidan1@hotmail.com wrote:

>"Microcontrollers have a better predictable time behaviour, because
>their circuit is integrated in silicon and is unchangeable; unlike
>FPGAs which have variable timing performances."
>
>Is this statement correct?

I don't know, because it's nearly meaningless.

What I *do* know is this:  Once you've successfully implemented
a given function or circuit on an FPGA, its timing is entirely
predictable in the sense that every copy of that FPGA will meet
the same timing spec - maximum clock frequency, input setup time,
output delay, etc.  In a rather similar way, every microprocessor
chip of the same type that you buy will meet its data sheet 
timing spec.  So in that sense, the statement is nonsense because
FPGA implementations and microprocessors are equally predictable
at meeting their timing specs.

I also know that a typical microcontroller represents a large
investment in design and verification work by the manufacturer,
work that I would have to do myself if I wished to implement
exactly that microcontroller in an FPGA.  So I'm not going
to bother to do that.  I'll buy the uC chip, thanks - unless
the uC function can be trivially integrated into my FPGA 
using the nice system-builder tools currently on offer.

I also know that I can design things in an FPGA that will
outrun a microcontroller by many orders of magnitude in
speed.  And here we perhaps get to the nub of your statement,
because until I embark on the FPGA design I can't know 
exactly how fast it will run - what its Fmax will be.  In
that sense, and only in that sense, the FPGA is "unpredictable".
However, modern timing analysis tools, combined with my own 
engineering intuition about which parts of the design are
most likely to be timing-critical, will quickly lead me
to a good estimate of the speed that I will ultimately 
achieve, and therefore will guide my design strategy so
that I can meet my application's requirements.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 120217
Subject: Re: Weekend pop quiz
From: Eric Smith <eric@brouhaha.com>
Date: 03 Jun 2007 16:24:40 -0700
Links: << >>  << T >>  << A >>
Marlboro <ccon67@netscape.net> writes:
> A memory block has been told having "read latency of 3", assume the
> read pointer has been reset
> 
> How many read clocks does it take to read out the first 10 bytes?

How long is a piece of string?

Your posting is missing key details of the problem.  If you want us to
do your homework for you, you'll have to do a better job of typing in
the problem.

Note that free homework answers are worth as much as you pay for them,
as an upper bound.  They may be worth even less.


Article: 120218
Subject: Create and Import Peripheral in EDK
From: Koustav <koustav79@gmail.com>
Date: Sun, 03 Jun 2007 17:22:20 -0700
Links: << >>  << T >>  << A >>
Hello everybody,

I am trying to interface my user logic ip_inv through the OPB in EDK
using a register like this:

the c code in my test_application to access the ipcore is :

IP_INV_mWriteReg(0x00000010, 0, read_val);
read_val2=IP_INV_mReadReg(0x00000010, 0);

My user logic is just a not operation. How do we make sure that the
value is written from the IPIF register into the user logic and then
back to the IPIF register ? I am expecting a inverted value in
"read_value2" but I am getting the same value as "read_value".


Thanks,
KOustav


Article: 120219
Subject: Re: Regarding multiple write problem in opencores pci bridge
From: Mark McDougall <markm@vl.com.au>
Date: Mon, 04 Jun 2007 10:48:16 +1000
Links: << >>  << T >>  << A >>
Adnan wrote:

> Now the problem is that sata controllers successfully reads all the
> data from memory and transfer it to hard disk but once its writes data
> back to sram I get mismatches. I have used chipscope pro and I confirm
> that signal terminates properly with exact expected data on PCI bus
> but once wishbone master module outputs address and data it contains
> few errors. Can you help me with this.

Are you sure the timing on the SRAM controller in your FPGA is correct?
You need to account for register-to-pin and pin-to-register delays when
calculating the SRAM read/write cycle times. As well as considering tco
you need to put constraints on the aforementioned delays and factor them
into your timing...

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 120220
Subject: Re: Altera Serial Flash Loader (SFL) question
From: Mark McDougall <markm@vl.com.au>
Date: Mon, 04 Jun 2007 10:51:58 +1000
Links: << >>  << T >>  << A >>
Ben Jackson wrote:

> The programming tool in Quartus recognizes the "JIC" files and selects
> a "factory default SFL image" to accomplish the loading.  There are two
> rows and thus two "program" checkboxes, and I assumed you could simply
> un-check the FPGA part if you included SFL in your design, but the
> boxes are locked together.
> 
> What is the trick for using the SFL embedded in your design instead of
> "factory default SFL image"?

What you see is exactly what you want. It works for me. I assume the
'factory default SFL image' is simply a 'bootstrap' image for programming SFL.

BTW once you've programmed your JIC image you need to power-cycle your
board. Your custom FPGA image should then be configured as usual whilst
allowing subsequent JIC programming.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 120221
Subject: Re: Altera Serial Flash Loader (SFL) question
From: Mark McDougall <markm@vl.com.au>
Date: Mon, 04 Jun 2007 10:58:04 +1000
Links: << >>  << T >>  << A >>
Mark McDougall wrote:

I should clarify - you simply need to instantiate the SFL mega-function in
your design. Once you've built your image, use Convert Programming Files
to produce a .JIC file which includes your .SOF. You can then program the
FPGA via JTAG with your new .SOF, then re-program with the .JIC which
configures your EPCS device. Then power-cycle your board.

Subsequent updates require reproducing the JIC from the SOF and
re-configuring with the JIC.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 120222
Subject: Problem with System ACE
From: Philipp Hachtmann <hachti@hachti.de>
Date: Mon, 04 Jun 2007 03:38:42 +0200
Links: << >>  << T >>  << A >>
Hi folks,

I am desperately trying to load a design via System ACE onto a ML403 board.

What I use:

ISE 8.2i
ML403
Linux

What I did:

Synthesized a very small design (some led blinking).

Then generated System ACE with my .bit file.
Added my bitstream to all config addresses.

I formatted the CF dos partition with:
mkdosfs -s 64 -F 16 -R /dev/sda1
- using the original partition table that came on the card.

Mounted with -ofat=16 - also tried without

Now I tried to move all generated files to the CF -> Red light

Picked .ace file and used as standalone system.ace -> Red light

Copied the original contents of the DOS partition into the CF (by copy, 
not the image!!) -> Green light

Copied my .ace file into the designated position for an own ace -> Green 
light, after selection from the menu -> Red light

Copied bootloader .ace file from the original image as system.ace into 
my CF -> Green light

So I think that my DOS FS generation is ok as I can make a working CF.

But my .ace file doesn't seem to work.

I have tried all that several times, thinking over and over and over again.
My bitfile works when I upload it directly via JTAG.

Has anyone an idea what I have done wrong? I don't have any further ideas.

Thank you all very much!!!


Best regards,

Philipp :-)

Article: 120223
Subject: TBUF and modular design flow on spartan
From: javaguy11111@gmail.com
Date: Sun, 03 Jun 2007 21:09:21 -0700
Links: << >>  << T >>  << A >>
I have a project where I am trying to use modular design flow. When I
do synthesis of one of my modules I see the message in the log.

Number of TBUFs:                       61  out of      0        (*)

I think this is causing me problems when I try to do the assemble,
because those modules get dropped from the design.

Any suggestions on what I am doing wrong or how to work around it.


Article: 120224
Subject: Re: Xilinx CIC core in Spartan 3?
From: "John Retta" <jretta@rtc-inc.com>
Date: Mon, 04 Jun 2007 04:16:33 GMT
Links: << >>  << T >>  << A >>
You will need to select the device type in coregen as a spartan IIE,
generate the core, and use the resulting .edn netlist in your S3 design.

CICs use basic, non-device specific primitives (adders, counters,
registers etc ....).

When I first ported my first DSP FPGA from a SIIE to S3 two years
ago, there was a moment of panic when I saw CICs were not supported.
I think this is just a deficiency in the GUI that has never been resolved.

-- 
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.

email : jretta@rtc-inc.com
web :  www.rtc-inc.com


<cs_posting@hotmail.com> wrote in message 
news:1180536814.626509.110470@p47g2000hsd.googlegroups.com...
> Does anyone know if the Xilinx CIC core will work in the Spartan 3?
> It's not listed as a target (only Spartan IIE) but then the data sheet
> is dated 2002, wheras S3 apparently was announced in 2003...
> 





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