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
2017JanFebMarApr2017

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 38100

Article: 38100
Subject: Re: asic vs. fpga
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 04 Jan 2002 12:24:10 -0800
Links: << >>  << T >>  << A >>
Now there are two good stories to choose from.
Both are fundamentally correct, but each overstates its case.
I think your budget will make the decision for you.

Peter Alfke
=======================================
Richard Iachetta wrote:

> In article <3C353149.1A7CDD1A@earthlink.net>, palfke@earthlink.net says...
> > If you have infinite amounts of money and time, and never make a mistake
> > and never intend to change your design, then ASICs are great ( Low price
> > per chip, high performance, low power).  But this comes at a high price
> > in non-recurring engineering charges ( $1 000 000 for a state-of-the art
> > big circuit ) and it takes months to get the first chip.  And you must
> > always order and pay for a specific quantity, and never make a mistake
> > or a change.
> >
> > That's why more and more designers prefer the FPGA solution that does
> > not have these high up-front costs and long waiting time, and can be
> > bought in any quantity at any time, and be modified ad infinitum.
>
> All of this seems a bit overstated.  Here's another perspective perhaps
> overstated in the other direction.  You don't need infinite time and money to do
> an ASIC (I'll address mistakes in a minute).  ASICs generally cost less per part
> but have an upfront NRE cost and longer lead time.  So if your volume is large
> and you can afford the lead time, it often makes economic sense to go with an
> ASIC.  There is typically a volume crossover point where on one side an FPGA is
> cheaper and on the other side an ASIC is cheaper.
>
> As you mentioned, state of the art ASICs perform better than state of the art
> FPGAs and can be much lower power so performance or power may require you to use
> an ASIC.  ASICs offer much more flexability with regard to what you can do;
> while FPGAs have gotten very flexible, they are no where near as flexible as an
> ASIC with respect to different kinds of I/O drivers, pin placement, multiple
> PLLs, DLLs and clock domains, varieties of internal memories, etc.  Custom ASICs
> offer even more flexibility and performance than standard ASICs allowing you
> construct your circuits at the transistor level.  Even standard ASICs allow you
> map to just about any set of gates that you want for your circuit whereas
> designs in FPGAs must be mapped into whichever lookup tables, cells and math-
> assist resources are available in the target FPGA.  Floorplanning is important
> for both ASICs and FPGAs but there can be more floorplanning headaches in FPGAs
> which pay a higher penalty if logic feeds other logic that is not close by ("off
> row" or whatever).  In ASICs a slightly longer wire is just slightly more delay
> -- it scales much better.
>
> I would also argue that design source written for ASICs is much more portable
> and reusable than design source written for FPGAs.  This is because FPGA designs
> (especially math functions) must be structured to map well to the particular
> FPGA architecture it is targeted for or a performance penalty (sometimes severe)
> will be paid.  When porting the design to a different FPGA, the design may have
> to be rearchitected.  Targeting an ASIC design to another ASIC technology is
> often just a case of resynthesis to the new library.  Sometimes the netlist can
> be ported avoiding even the resynthesis.
>
> With regard to not being able to make a mistake when designing an ASIC and
> FPGA's being able to "be modified ad infinitum":  Being able to modify an FPGA
> is great during product development but doesn't do as much good after a product
> has shipped.  If people buy a video card with an FPGA on it and that FPGA has a
> bug, those people are usually in the same boat that they would be in if the card
> had used an ASIC instead.  They are (usually) not going to be able to reprogram
> that FPGA at home so both the FPGA designer and the ASIC designer need to get
> the design right by ship time.  During development time, mistakes are worse for
> ASICs but they are not as bad as some FPGA proponents would have you believe.
> ASICs commonly go through two or three passes and each pass is not a full respin
> of all the work, time and money needed to make the first part.  In fact many
> second passes are ECs to the existing mask which preserve all of the design,
> synthesis, floorplanning, layout, wiring and timing work that has already been
> done.
>
> --
> Rich Iachetta
> iachetta@us.ibm.com
> I do not speak for IBM.


Article: 38101
Subject: ASIC faster than VirtexII FPGA?
From: yujun@huawei.com (Yu Jun)
Date: 4 Jan 2002 17:07:50 -0800
Links: << >>  << T >>  << A >>
We are planning to develop a ASIC chips for a highspeed router. The
majoy frequency may be 125M. Now at a verification stage, we made a
FPGA version to check if the basic functions can work properly. But
the FOUNDATION(virtex-II 4000-5) reports a timing contraints
failure--the maximum logical delay is up to 9.7ns. After a very
long-time optimization, the result is improved to 8.7ns, still not
meet the timing requirement(8ns).

we wonder if this problem exists when it goes to ASIC. I have no idea
about ASIC's speed. I was told ASIC is faster than FPGA, if yes, how
much faster? Seems VirtexII is already much faster than the old virtex
or virtexE. I also notice somebody declare ASIC is NOT inherently
faster than FPGA. Who is right?

Your suggestion is very appreciated if you can help me or point me to
the right direction to learn some basic ASIC knowledge. Thank you very
much.

-----------------------
Yu Jun
yujun@huawei.com

Article: 38102
Subject: Re: ASIC faster than VirtexII FPGA?
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Sat, 5 Jan 2002 01:34:57 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <651e62f3.0201041707.4039dced@posting.google.com>,
Yu Jun <yujun@huawei.com> wrote:
>We are planning to develop a ASIC chips for a highspeed router. The
>majoy frequency may be 125M. Now at a verification stage, we made a
>FPGA version to check if the basic functions can work properly. But
>the FOUNDATION(virtex-II 4000-5) reports a timing contraints
>failure--the maximum logical delay is up to 9.7ns. After a very
>long-time optimization, the result is improved to 8.7ns, still not
>meet the timing requirement(8ns).
>
>we wonder if this problem exists when it goes to ASIC. I have no idea
>about ASIC's speed. I was told ASIC is faster than FPGA, if yes, how
>much faster? Seems VirtexII is already much faster than the old virtex
>or virtexE. I also notice somebody declare ASIC is NOT inherently
>faster than FPGA. Who is right?

ASICs done in a comparable process will be faster.  But the NRE cost
of doing an asic on a .12? uM process is substantial.

Question:  Could you simply add a couple more pipeline stages?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 38103
Subject: Re: ASIC faster than VirtexII FPGA?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 04 Jan 2002 17:43:56 -0800
Links: << >>  << T >>  << A >>
Have you used enough pipelining? A logic delay of 9.7 ns indicates that a
signal   passed through many combinatorial blocks before it got re-clocked. Just
stick a flip-flop in the middle of that path ( and compensate in other parallel
branches )

The abundance of flip-flops in the FPGA architecture makes it very easy to
increase throughput (clock frequency) by using extensive pipelining, albeit with
increased latency.
In many designs, pipelining can perforrm miracles...


Peter Alfke, Xilinx Applications
==============================
Yu Jun wrote:

> We are planning to develop a ASIC chips for a highspeed router. The
> majoy frequency may be 125M. Now at a verification stage, we made a
> FPGA version to check if the basic functions can work properly. But
> the FOUNDATION(virtex-II 4000-5) reports a timing contraints
> failure--the maximum logical delay is up to 9.7ns. After a very
> long-time optimization, the result is improved to 8.7ns, still not
> meet the timing requirement(8ns).
>
> we wonder if this problem exists when it goes to ASIC. I have no idea
> about ASIC's speed. I was told ASIC is faster than FPGA, if yes, how
> much faster? Seems VirtexII is already much faster than the old virtex
> or virtexE. I also notice somebody declare ASIC is NOT inherently
> faster than FPGA. Who is right?
>
> Your suggestion is very appreciated if you can help me or point me to
> the right direction to learn some basic ASIC knowledge. Thank you very
> much.
>
> -----------------------
> Yu Jun
> yujun@huawei.com


Article: 38104
Subject: Re: asic vs. fpga
From: hamish@cloud.net.au
Date: 05 Jan 2002 05:35:53 GMT
Links: << >>  << T >>  << A >>
Richard Iachetta <iachetta@us.ibm.com> wrote:
> With regard to not being able to make a mistake when designing an ASIC and 
> FPGA's being able to "be modified ad infinitum":  Being able to modify an FPGA 
> is great during product development but doesn't do as much good after a product 
> has shipped.  If people buy a video card with an FPGA on it and that FPGA has a 
> bug, those people are usually in the same boat that they would be in if the card 
> had used an ASIC instead.  They are (usually) not going to be able to reprogram 

True. But there are plenty of applications where it is easy to
change the programming. Most FPGAs have to be programmed every
time at power up anyway, which helps too.

FPGA not only gives you the opportunity to correct mistakes but
also the ability to add new features. In some applications that
is invaluable.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 38105
Subject: Re: ASIC faster than VirtexII FPGA?
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Sat, 05 Jan 2002 07:57:56 GMT
Links: << >>  << T >>  << A >>
On 4 Jan 2002 17:07:50 -0800, yujun@huawei.com (Yu Jun) wrote:

>We are planning to develop a ASIC chips for a highspeed router. The
>majoy frequency may be 125M. Now at a verification stage, we made a
>FPGA version to check if the basic functions can work properly. But
>the FOUNDATION(virtex-II 4000-5) reports a timing contraints
>failure--the maximum logical delay is up to 9.7ns. After a very
>long-time optimization, the result is improved to 8.7ns, still not
>meet the timing requirement(8ns).
>
>we wonder if this problem exists when it goes to ASIC. I have no idea
>about ASIC's speed. I was told ASIC is faster than FPGA, if yes, how
>much faster? Seems VirtexII is already much faster than the old virtex
>or virtexE. I also notice somebody declare ASIC is NOT inherently
>faster than FPGA. Who is right?
>
>Your suggestion is very appreciated if you can help me or point me to
>the right direction to learn some basic ASIC knowledge. Thank you very
>much.
>
>-----------------------
>Yu Jun
>yujun@huawei.com

In my experience with three designs which have seen both standard cell
and FPGA implementations, I have observed a 3 to 5 times speed up with
the ASIC implementation. The context was .25u standard cell desing and
maximum frequency in the designs was 500 MHz. One design was an 8 bit
microcontroller with lots of memory, one a 16 bit processor with
embedded 10bt implementation and the last one a small block in  a
mixed signal design. These were all mostly control logic dominant
designs and the ASIC implementations were done using static cmos, DFF
registers. I think the 3-5 speed up only goes up to 500~600 MHz (i.e.
if your design times 100 MHz on an FPGA you can expect 300 to 500 MHz)
because above that speed, the clocking overhead with static cmos
becomes too high. In my latest .25u design, the worst case
setup+clk->q is around 1.5 ns so anything nearing 500 MHz leaves you
only 500 ps to work with. With domino circuit techniques you can go
much higher with a full custom design.

Muzaffer Kal

http://www.dspia.com
DSP algorithm implementations for FPGA systems

Article: 38106
Subject: Re: ASIC faster than VirtexII FPGA?
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Sat, 05 Jan 2002 08:12:43 GMT
Links: << >>  << T >>  << A >>
On Sat, 5 Jan 2002 01:34:57 +0000 (UTC), nweaver@CSUA.Berkeley.EDU
(Nicholas Weaver) wrote:

>Question:  Could you simply add a couple more pipeline stages?

In a control logic dominated design, it can be very difficult to
pipeline the design if existing interblock timing needs to be
preserved. For datapath oriented designs, pipelining is easier
usually.

Muzaffer Kal

http://www.dspia.com
DSP algorithm implementations for FPGA systems

Article: 38107
Subject: RNS
From: jacky Renaux <renaux.jacky@wanadoo.fr>
Date: 05 Jan 2002 08:21:24 GMT
Links: << >>  << T >>  << A >>

I 

DOes any body already working on Residue Number Systems , a kind of arithmetic 
which handle large numbers avoiding large carry propagation (a locations 
constraints ) 
I would like to share advices from you 

thanks 

jacky 

-- 
Use our news server 'news.foorum.com' from anywhere.
More details at: http://nnrpinfo.go.foorum.com/

Article: 38108
Subject: Re: asic vs. fpga
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 05 Jan 2002 09:25:22 +0000
Links: << >>  << T >>  << A >>


hamish@cloud.net.au wrote:

>
> True. But there are plenty of applications where it is easy to
> change the programming. Most FPGAs have to be programmed every
> time at power up anyway, which helps too.
>
> FPGA not only gives you the opportunity to correct mistakes but
> also the ability to add new features. In some applications that
> is invaluable.
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

In many ways its even better than that since FPGAs allow an evolutionary approach to
design. This has some big benefits in allowing s/w development to start earlier. You
can even apply the evolutionary thing to the device's timing - in some cases.

There's also something on the budgetary side that's been missed out. ASIC design tools
(synthesisers, simulators, layout tools, etc.) are MUCH more expensive than the
corresponding ones for FPGAs. I believe its normal in ASIC design to have several
"seats" for each of these wich is going to burn another couple of $100K of investment.

There's this nice quote I read from the head of NKK's Telecom? division that seems to
be right up the FPGA's street (approx)

``Innovate radically, implement steadily''


Article: 38109
Subject: full custom design
From: Matthias Weber <msweber@onlinehome.de>
Date: Sat, 05 Jan 2002 16:15:11 GMT
Links: << >>  << T >>  << A >>
hi,

i have read in a document about full custom design. explaining why the nre costs are high it is written 
"..each primitive logic function or transistor is manually designed and optimized. ... the designer must manipulate
the individual geometric shape wich represent the features of each transistor on the chip; hence the often applied term for
full custom design: "polygon pushing". a relative simple 3000 gate design might require the handling of 300k rectangles per chip..."

i guess this statement refers to an cad tool, but i don't understand the role of rectangles and the term "polygon pushing".
maybe somebody could explain me a little bit  in more detail?

thanks,

matthias weber



Article: 38110
Subject: Re: full custom design
From: Phil Hays <spampostmaster@home.com>
Date: Sat, 05 Jan 2002 18:02:26 GMT
Links: << >>  << T >>  << A >>
Matthias Weber wrote:

> i have read in a document about full custom design. explaining why the nre costs are high it is written
> "..each primitive logic function or transistor is manually designed and optimized. ... the designer must manipulate
> the individual geometric shape wich represent the features of each transistor on the chip; hence the often applied term for
> full custom design: "polygon pushing". a relative simple 3000 gate design might require the handling of 300k rectangles per chip..."

CAD for full custom design makes transistors and interconnect by drawing out the
shapes needed at each layer.  As an example, layers might be: 1) well implants
(for CMOS), 2) active (defines source+drain), 3) poly to active contact, 4)
polysilicon (makes the gates), 5) P source drain, 6) N Source drain, 7) metal
one contact, 8) first level metal, and so on.  To define a transistor in full
custom, the designer draws out polygons (mostly rectangles) to describe each
layer.  This allows the designer freedom to size and position each transistor,
which can lead to a slightly higher performance design, both smaller die size
and faster than the "cell library" or "gate array" versions of the same design,
at a cost of vastly higher designer time.

               P  P
               P  P
  WWWWWWWWWWWWWPWWPWWWWWWWWWWWWWWWW
  W            P  P               W
  W            P  P               W
  W   AAAAAAAAAPAAPAAAAAAAAA      W
  W   A        P  P        A      W
  W   A        P  P        A      W
  W   A        P  P        A      W
  W   A  CCC   P  P   CCC  A      W
  W   A  C C   P  P   C C  A      W
  W   A  CCC   P  P   CCC  A      W
  W   A        P  P        A      W
  W   A        P  P        A      W
  W   AAAAAAAAAPAAPAAAAAAAAA      W
  W            P  P               W
  W            PPPP               W
  WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW

Above is a transister.  The layers shown are "W" for well,  "A" for active, "P"
for polysilicon and "C" for first level contacts.


-- 
Phil Hays

Article: 38111
Subject: Re: full custom design
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Sat, 05 Jan 2002 18:51:32 GMT
Links: << >>  << T >>  << A >>
On Sat, 05 Jan 2002 16:15:11 GMT, Matthias Weber
<msweber@onlinehome.de> wrote:

>hi,
>
>i have read in a document about full custom design. explaining why the nre costs are high it is written 
>"..each primitive logic function or transistor is manually designed and optimized. ... the designer must manipulate
>the individual geometric shape wich represent the features of each transistor on the chip; hence the often applied term for
>full custom design: "polygon pushing". a relative simple 3000 gate design might require the handling of 300k rectangles per chip..."
>
>i guess this statement refers to an cad tool, but i don't understand the role of rectangles and the term "polygon pushing".
>maybe somebody could explain me a little bit  in more detail?

On silicon the transistors are manufactured by placing multiple layers
on top of each other. Each layer is described by multiple polygons and
the devices are generated by the overlaps of the layers. It is not
completely unlike PCB design especially when you look at connectivity.
Some of the layers are for device generation (nwell, pwell, active,
oxide, etc) and some layers are for connectivity (mostly metal layers,
contacts etc). Here is a picture
http://argon.eecs.berkeley.edu:8080/~ee143/Chip_Layout/figures/device.14.html

In full custom design, the devices are designed manually. But there is
still some automation for layout. One designs small scripts which take
a transistor level schematic and generate all the transistors
according to the W/L sizes in it and if annotated can even generate
the cross-coupled and multi-leg devices. Almost no one generates all
the polygons by hand. 

In standard cell or gate array designs, the gates are already
designed, all the polygons pushed and the behaviour is characterized
and a synthesis tool can use the library to infer gates and the P&R
tool is used to place the gates and route the connectivity.

hth,

Muzaffer Kal

http://www.dspia.com
DSP algorithm implementations for FPGA systems

Article: 38112
Subject: Re: RNS
From: Ray Andraka <ray@andraka.com>
Date: Sun, 06 Jan 2002 00:35:09 GMT
Links: << >>  << T >>  << A >>
The difficulty with RNS lies in converting to and from RNS so that you can use
inputs from other parts of the system and be able to use the outputs.  The fast
carry chain in the Xilinx parts gives you all the carry logic for free (no
additional LUTs are needed), and is considerably faster and smaller than
conventional arithmetic done with other carry structures.  As it turns out, the
built in fast carry chains make it so that RNS has little to offer in terms of
both performance and area in FPGAs that have the fast carry structures.

jacky Renaux wrote:

> I
>
> DOes any body already working on Residue Number Systems , a kind of arithmetic
> which handle large numbers avoiding large carry propagation (a locations
> constraints )
> I would like to share advices from you
>
> thanks
>
> jacky
>
> --
> Use our news server 'news.foorum.com' from anywhere.
> More details at: http://nnrpinfo.go.foorum.com/

--
--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: 38113
Subject: Re: A Fast counter in VHDL?
From: Ray Andraka <ray@andraka.com>
Date: Sun, 06 Jan 2002 01:09:51 GMT
Links: << >>  << T >>  << A >>
32 bit carry chains at 100MHz is possible in a SpartanII-5, but you do have to
watch the loading of the input signals as well as the placement of the
flip-flops driving the inputs relative to the carry chain.  For this performance
you don't want any combinatorial logic driving the LUTs which feed the carry
chain, and you want the flip-flops driving the carry chain immediately adjacent
to the least signficant luts they are driving.  In your case, you have two reset
signals OR'd together.  These may or may not be connecting directly to the
flip-flop reset pins (check it in the FPGA editor or if you have an edif to
schematic converter or equivalent you can check it there).  Quite often, the
reset logic, when specified like this will result in an additional layer of
logic between the carry chain and the flip-flops.

Also check the count enable connections, which ideally should connect to the
flip-flop CE input.  With 32 bits, your loading of the clock enable or reset
signals can significantly slow the propagation of those signals.  If they are
feeding into the LUT before the carry chain, that prop delay adds to the 5+ ns
delay for the carry chain.  For best performance, you should duplicate the
control signals so that each copy only drives a few bits.  Finally, the routing
delay has to be minimized, which is done by floorplanning so that the registers
driving inputs in your counter are immediately adjacent to the counter bits
where they are used.

A 32 bit non-loadable counter is alot easier than more complicated carry chain
functions, as it can be arranged so that the controls are all after the carry
chain.  The ideal construction (for maximum performance) for this counter uses
FDRE primitives with the combined reset signal fed to the FDRE R pin, the count
enable to the CE pin.  The carry chain luts are simply buffers to feedback the
counter's current value.  THe MUxcy D inputs are all '0' and the LSB's CIN is
hardwired to '1'.  This avoids any high fanout signals having to propagate
through the carry, and has all the carry chain inputs coming from the same slice
that they drive.  The last remaining thing here would be to register the
combined reset and use that instead of using the OR directly.  It may mean
changing the logic that produces the reset signals to make them happen a clock
earlier to compensate for the addtional clock delay.

I have found that frequently, it is less effort to go ahead and instantiate the
components in a generate statement rather than trying to coax the synthesizer
into inferring the correct construction for things like this.  That has the
added benefit of allowing you to put the floorplanning in the code too.  Here is
the generate code for the instantiated and placed counter:


    signal cy:std_logic_vector(32 downto 0);

begin

cy(0)<='1';
CNTR:for i in 0 to 31 generate
     constant rloc_str : string := "R" & itoa( ((width-1)/2)-(i/2))  & "C0" &
".S" & itoa(slice mod 2);
    signal s:std_logic;
    attribute RLOC   of U1 : label is rloc_str;
    attribute RLOC   of U2 : label is rloc_str;
    attribute RLOC   of U3 : label is rloc_str;
begin
  U2: MUXCY port map (
   O  => cy(i+1),
   CI => cy(i),
   DI => '0',
   S  => q(i) );

  U3: XORCY port map (
   O  => s,
   CI => cy(i),
   LI => q(i) );

   U1: FDRE port map (
    Q  => q(i),
    D  => s,
   R => Reset,
   CE => ce,
   C  => clk );
end generate CNTR;

Falk Brunner wrote:

> "Jason Berringer" <jberringer@trace-logic.com> schrieb im Newsbeitrag
> news:IJ5Z7.12027$A67.3131096@news20.bellglobal.com...
>
> >
> > library ieee;
> > use ieee.std_logic_1164.all;
> > use ieee.std_logic_unsigned.all;
> >
> > entity counter is
> >  generic(width : integer := 32);
> >  port(
> >   clk   : in  std_logic;
> >   cnt_clr  : in  std_logic;
> >   cnt_enable : in  std_logic;
> >   reset  : in  std_logic;
> >   cnt_out  :   out std_logic_vector(width-1 downto 0)
> >   );
> > end counter;
> >
> > architecture RTL_counter of counter is
> >
> > signal countL : std_logic_vector(cnt_out'range);
> >
> > begin
> >
> > P1: process (reset, cnt_clr, clk, cnt_enable) begin
> >  if (reset = '1' or cnt_clr = '0') then
> >   countL <= (others => '0');
> >  elsif (rising_edge(clk)) then
> >   if (cnt_enable = '1') then
> >    countL <= countL + 1;
> >   end if;
> >  end if;
> > end process;
> >
> > cnt_out <= countL;
> >
> > end RTL_counter;
>
> As far as I can see, this simple  ce'ed counter should run @100 Mhz, even in
> a Spartan-II-5. Just compile the counter alone and look at the timing
> report. It should clearly say tha clk can be faster than 10ns. Often, the
> timing analyzer is doing wiered things (not at all, false paths are more the
> problem here) and it looks like the circuit is too slow.
>
> --
> MfG
> Falk

--
--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: 38114
Subject: Q:where can I find an indepth manual about P&R in Quartus II ?
From: shengyu_shen@hotmail.com (ssy)
Date: 5 Jan 2002 20:22:19 -0800
Links: << >>  << T >>  << A >>
Hi everyone

where can I find an indepth manual about P&R in Quartus II ?

thank in advance

Article: 38115
Subject: simprims_ver/xilinxcorelib_ver /unisims_ver
From: Orlls <maodahrng@sina.com.cn>
Date: Sat, 5 Jan 2002 21:23:35 -0800
Links: << >>  << T >>  << A >>
when i simulate with modelsim5.5e,it says: 
# testbench
# vsim -lib work -t 1ps -L xilinxcorelib_ver -L unisims_ver -L simprims_ver -foreign {hdsInit f:/eda_tools/resources/downstream/modelsim/ModelSim_32Bit.dll} -pli f:/eda_tools/resources/downstream/modelsim/ModelSim_32Bit.dll testbench glbl 
# Loading f:/eda_tools/resources/downstream/modelsim/ModelSim_32Bit.dll
# Loading work.testbench

# ERROR: Could not open library xilinxcorelib_ver at xilinxcorelib_ver: No such file or directory
# ERROR: Could not open library unisims_ver at unisims_ver: No such file or directory
# ERROR: Could not open library simprims_ver at simprims_ver: No such file or directory
# Loading work.NA_Message_Generate
# ERROR: Could not open library xilinxcorelib_ver at xilinxcorelib_ver: No such file or directory
# ERROR: Could not open library unisims_ver at unisims_ver: No such file or directory
# ERROR: Could not open library simprims_ver at simprims_ver: No such file or directory
# Loading work.NA_Message_Receive
# ERROR: Could not open library xilinxcorelib_ver at xilinxcorelib_ver: No such file or directory
# ERROR: Could not open library unisims_ver at unisims_ver: No such file or directory
# ERROR: Could not open library simprims_ver at simprims_ver: No such file or directory
# Loading work.na_fifo16_256
# ERROR: Could not open library xilinxcorelib_ver at xilinxcorelib_ver: No such file or directory
# ERROR: Could not open library unisims_ver at unisims_ver: No such file or directory
# ERROR: Could not open library simprims_ver at simprims_ver: No such file or directory
# Loading work.SYNC_FIFO_V3_0
# ERROR: Could not open library xilinxcorelib_ver at xilinxcorelib_ver: No such file or directory
# ERROR: Could not open library unisims_ver at unisims_ver: No such file or directory
# ERROR: Could not open library simprims_ver at simprims_ver: No such file or directory
# Loading work.MEM_BLK
# Loading work.glbl

after i compile xilinx lib,there is not simprims_ver/xilinxcorelib_ver /unisims_ver directory.why?

Article: 38116
Subject: Re: Q:where can I find an indepth manual about P&R in Quartus II ?
From: Kevin Brace <nospamtomekevinbraceusenet@nospamtomehotmail.com>
Date: Sun, 06 Jan 2002 00:03:08 -0600
Links: << >>  << T >>  << A >>
Did you read through the Quartus II tutorial?
Altera's device datasheets should give you some insight into device
architectures.


 
Kevin Brace (don't respond to me directly, respond within the newsgroup)




ssy wrote:
> 
> Hi everyone
> 
> where can I find an indepth manual about P&R in Quartus II ?
> 
> thank in advance

Article: 38117
Subject: how do i program a Spartan FPGA
From: nachikap@yahoo.com (Nachiket Kapre)
Date: 5 Jan 2002 22:13:16 -0800
Links: << >>  << T >>  << A >>
Hello,
 I am currently in a project which uses Spartan FPGA and need to know
how to program it. Can I make my own version of the Parallel Cable III
and use it to program via the JTAG pins(i have a schematic from the
xilinx website). Or if I decide to use a Serial PROM ,how can i get it
programmed?...is a ciruit schematic avaiable for the same? Or are
there any other programming options that i havent considered?

Reply soon.

Article: 38118
Subject: Re: FLOORPLANNING IN XILINX
From: Kevin Brace <nospamtomekevinbraceusenet@nospamtomehotmail.com>
Date: Sun, 06 Jan 2002 00:18:46 -0600
Links: << >>  << T >>  << A >>
divya wrote:
> 
> HI,
> I WANT TO KNOW WHERE I CAN GET INFORMATION ON HOW TO DO FLOORPLANNING
> IF POSSIBLE WITH EXAMPLES.
> DIVYA


        I don't claim to be some kind of expert of Xilinx floorplanner,
but no one else seems to comment on it, so I will throw in my two cents.
Before you start floorplanning your design, you probably should ask
yourself if it is really necessary to floorplan your design.
It is possible that it might still be possible to improve timings of
your design by modifying your RTL code.
What I learned from doing manual floorplanning is that floorplanner is
not a magic tool like the synthesis tool (Does anyone still believe that
synthesis tool is a magic tool that generates optimized circuit? I used
to think that way, but ever since I got into floorplanning, I no longer
think so.), and only potentially reduces routing delays if done
correctly, but won't reduce LUT delays at all.
Modifying your RTL code, using different synthesis options, or using a
different synthesis tool is the only way you can reduce LUT delays, and
sometimes, it is better modifying your RTL code first before
floorplanning because sometimes it is just impossible to meet specified
timings only by manual placement, and some LUT delays also has to be
eliminated.
        As far as I know (I haven't checked Xilinx website in detail),
Xilinx doesn't seem to really have a nice application note explaining
how to do floorplanning.
It seems to me that the Floorplanner manual is the only source of
information, but Floorplanner manual only covers how to use the tool,
and not the floorplanning strategies on how to do it.
First of all, having no experience using Floorplanner or any similar
tool, what I first did was reading the Floorplanner manual.
I guess the trick I learned here is not trying to learn every features
when you read the manual for the first time.
Just get to know how to place a LUT or a FF to a desired location, how
to constrain LUTs and FFs to certain area, and learn more features as
you get more familiar with the tool.
Use .UCF flow if you are using the tool for the first time, because I
found .UCF flow easier to use than the regular flow.
       Assuming that you are targeting a Virtex architecture device
(Virtex/Virtex-E/Spartan-II/Spartan-IIE. Virtex-II architecture is
similar to Virtex, but has 4 Slices per CLB), the first thing you should
do is to download or order the device datasheet.
In the device datasheet, Xilinx gives you some idea of what the chip's
routing structure is like, but in my opinion, they should provide more
diagrams of the internal routing structure and routing delay numbers
(Altera's manuals are far better in this area).
Although, I suppose if I had access to FPGA Editor, I probably can see
what the internal routing structure is like . . . (I am a poor ISE
WebPACK 4.1 user).
A report generated by TRACE or Timing Analyzer should give you a picture
of what the routing delay numbers are in a Virtex architecture.
        From the routing delay numbers I saw in a Timing Analyzer
report, LUT connections within the same Slice is the fastest (worst case
0.222ns for Spartan-II XC2S150-5CPQ208 at 85 degrees Celsius) for a LUT
to LUT routing delay.
Then the second fastest routing delay will be LUT connections between
Slices within the same CLB (I believe it is about 0.385ns).
The third fastest will be routing delay between horizontally adjacent
CLBs, and I thought it was about 0.456ns.
After that, if I am correct, all routings will go out to the GRM
(General Routing Matrix) which I understand is generally called a switch
matrix or a switch box.
Routing delay starts to get large when an interconnect has to go out to
a switch matrix.
I think a LUT to LUT interconnect delay is about 0.8ns to 0.9ns between
vertically adjacent CLBs.
Going to a LUT a few CLBs away horizontally or vertically can take 1.2ns
to 1.4ns, but this can depend on how the routing congestion is like.
If you read a Timing Analyzer report carefully, you might notice that
when a signal has to travel long distance, for example, from near an
input pin to an IOB output FF or tri-state control FF, it doesn't take
"that" much of time compared to moving a signal from one LUT to another
LUT a few CLBs away horizontally or vertically.
I don't have access to FPGA Editor, so I don't know for sure, but it
seems like P&R (Place & Route) tool automatically selects a long wire
which can transfer a signal fast when that signal has to travel long
distance.
So, summarizing what I say, here are the strategies on how to floorplan
a design for Virtex architecture.

* Keep LUTs as close as possible. Keep them within a CLB if possible,
and if that is not, place them horizontally adjacent to each other.

* Avoid placing LUTs a few CLBs away.

* If two LUTs cannot be placed closed to each other because a signal has
to travel from near an input pin to an IOB output FF or tri-state
control FF, place one of the 
LUT closer to the IOB FF near the IOB.


I think the key of improving performance in Virtex architecture is to
keep relevant LUTs as close as possible to each other, however, MAP
doesn't seem to do a good job of finding the right combination of LUTs
to merge within a CLB.
A designer with some knowledge of Virtex architecture can do a better
job than MAP in my opinion.
I suppose a tool like Synplicity's Amplify perhaps finds the right
combination of LUTs to merge within a CLB, but I will rather see Xilinx
implementing a feature that will use the previous place and route
information to find a better combination of LUTs to merge in MAP.
Currently, I don't believe such a feature is implemented, but if
implemented, I am sure that full automatic design (no handplacing was
used) should get at least 10% improvement in timings by just
recompiling.
Also, another feature I will like to see added is priority mapping,
placement, and routing for user specified critical path signals (like
for signals entering the chip unregistered that goes towards IOB FF).
        I am sure there are other people out there who know better than
me regarding floorplanning, so if someone else know better ways to do
floorplanning, let me know.




Kevin Brace (don't respond to me directly, respond within the newsgroup)

Article: 38119
Subject: Re: floorplanning
From: Kevin Brace <nospamtomekevinbraceusenet@nospamtomehotmail.com>
Date: Sun, 06 Jan 2002 00:18:49 -0600
Links: << >>  << T >>  << A >>
renjini wrote:
> 
> Hi
> i want some information on xilinx floorplanning .i will be glad if u
> could get me some information on this
> renjini.k


        I don't claim to be some kind of expert of Xilinx floorplanner,
but no one else seems to comment on it, so I will throw in my two cents.
Before you start floorplanning your design, you probably should ask
yourself if it is really necessary to floorplan your design.
It is possible that it might still be possible to improve timings of
your design by modifying your RTL code.
What I learned from doing manual floorplanning is that floorplanner is
not a magic tool like the synthesis tool (Does anyone still believe that
synthesis tool is a magic tool that generates optimized circuit? I used
to think that way, but ever since I got into floorplanning, I no longer
think so.), and only potentially reduces routing delays if done
correctly, but won't reduce LUT delays at all.
Modifying your RTL code, using different synthesis options, or using a
different synthesis tool is the only way you can reduce LUT delays, and
sometimes, it is better modifying your RTL code first before
floorplanning because sometimes it is just impossible to meet specified
timings only by manual placement, and some LUT delays also has to be
eliminated.
        As far as I know (I haven't checked Xilinx website in detail),
Xilinx doesn't seem to really have a nice application note explaining
how to do floorplanning.
It seems to me that the Floorplanner manual is the only source of
information, but Floorplanner manual only covers how to use the tool,
and not the floorplanning strategies on how to do it.
First of all, having no experience using Floorplanner or any similar
tool, what I first did was reading the Floorplanner manual.
I guess the trick I learned here is not trying to learn every features
when you read the manual for the first time.
Just get to know how to place a LUT or a FF to a desired location, how
to constrain LUTs and FFs to certain area, and learn more features as
you get more familiar with the tool.
Use .UCF flow if you are using the tool for the first time, because I
found .UCF flow easier to use than the regular flow.
       Assuming that you are targeting a Virtex architecture device
(Virtex/Virtex-E/Spartan-II/Spartan-IIE. Virtex-II architecture is
similar to Virtex, but has 4 Slices per CLB), the first thing you should
do is to download or order the device datasheet.
In the device datasheet, Xilinx gives you some idea of what the chip's
routing structure is like, but in my opinion, they should provide more
diagrams of the internal routing structure and routing delay numbers
(Altera's manuals are far better in this area).
Although, I suppose if I had access to FPGA Editor, I probably can see
what the internal routing structure is like . . . (I am a poor ISE
WebPACK 4.1 user).
A report generated by TRACE or Timing Analyzer should give you a picture
of what the routing delay numbers are in a Virtex architecture.
        From the routing delay numbers I saw in a Timing Analyzer
report, LUT connections within the same Slice is the fastest (worst case
0.222ns for Spartan-II XC2S150-5CPQ208 at 85 degrees Celsius) for a LUT
to LUT routing delay.
Then the second fastest routing delay will be LUT connections between
Slices within the same CLB (I believe it is about 0.385ns).
The third fastest will be routing delay between horizontally adjacent
CLBs, and I thought it was about 0.456ns.
After that, if I am correct, all routings will go out to the GRM
(General Routing Matrix) which I understand is generally called a switch
matrix or a switch box.
Routing delay starts to get large when an interconnect has to go out to
a switch matrix.
I think a LUT to LUT interconnect delay is about 0.8ns to 0.9ns between
vertically adjacent CLBs.
Going to a LUT a few CLBs away horizontally or vertically can take 1.2ns
to 1.4ns, but this can depend on how the routing congestion is like.
If you read a Timing Analyzer report carefully, you might notice that
when a signal has to travel long distance, for example, from near an
input pin to an IOB output FF or tri-state control FF, it doesn't take
"that" much of time compared to moving a signal from one LUT to another
LUT a few CLBs away horizontally or vertically.
I don't have access to FPGA Editor, so I don't know for sure, but it
seems like P&R (Place & Route) tool automatically selects a long wire
which can transfer a signal fast when that signal has to travel long
distance.
So, summarizing what I say, here are the strategies on how to floorplan
a design for Virtex architecture.

* Keep LUTs as close as possible. Keep them within a CLB if possible,
and if that is not, place them horizontally adjacent to each other.

* Avoid placing LUTs a few CLBs away.

* If two LUTs cannot be placed closed to each other because a signal has
to travel from near an input pin to an IOB output FF or tri-state
control FF, place one of the 
LUT closer to the IOB FF near the IOB.


I think the key of improving performance in Virtex architecture is to
keep relevant LUTs as close as possible to each other, however, MAP
doesn't seem to do a good job of finding the right combination of LUTs
to merge within a CLB.
A designer with some knowledge of Virtex architecture can do a better
job than MAP in my opinion.
I suppose a tool like Synplicity's Amplify perhaps finds the right
combination of LUTs to merge within a CLB, but I will rather see Xilinx
implementing a feature that will use the previous place and route
information to find a better combination of LUTs to merge in MAP.
Currently, I don't believe such a feature is implemented, but if
implemented, I am sure that full automatic design (no handplacing was
used) should get at least 10% improvement in timings by just
recompiling.
Also, another feature I will like to see added is priority mapping,
placement, and routing for user specified critical path signals (like
for signals entering the chip unregistered that goes towards IOB FF).
        I am sure there are other people out there who know better than
me regarding floorplanning, so if someone else know better ways to do
floorplanning, let me know.




Kevin Brace (don't respond to me directly, respond within the newsgroup)

Article: 38120
Subject: Suitability of Atmel for project?
From: i_never_check_this@hotmail.com (Stout)
Date: 5 Jan 2002 22:19:18 -0800
Links: << >>  << T >>  << A >>
My company has a large inventory of boards that have a 40 pin DIP
socket that was originally meant for another chip.  My new need is to
run an equivalent (opcode compatable) 8051 @ 5 Mhz plus some glue and
a couple of other oddball things.  Ideally I would like to use a
device that is also a 40 pin DIP so that I can use the boards.

I am brand-new to the PLD/FPGA arena but have about 20 years of EE
experience.

After a quick search around the web I found the Atmel ATV2500, a 40
pin DIP PLD (data sheet is at
http://www.atmel.com/atmel/acrobat/doc0249.pdf).  Since I'm so new to
this I have no idea of how to estimate if this thing is remotely
capable of meeting my logic requirements.  Any input, URLs, etc. is
appreciated.  TIA.

- Stout

Article: 38121
Subject: Re: Suitability of Atmel for project?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sun, 06 Jan 2002 22:07:42 +1300
Links: << >>  << T >>  << A >>
Stout wrote:
> 
> My company has a large inventory of boards that have a 40 pin DIP
> socket that was originally meant for another chip.  My new need is to
> run an equivalent (opcode compatable) 8051 @ 5 Mhz plus some glue and
> a couple of other oddball things.  Ideally I would like to use a
> device that is also a 40 pin DIP so that I can use the boards.
> 
> I am brand-new to the PLD/FPGA arena but have about 20 years of EE
> experience.
> 
> After a quick search around the web I found the Atmel ATV2500, a 40
> pin DIP PLD (data sheet is at
> http://www.atmel.com/atmel/acrobat/doc0249.pdf).  Since I'm so new to
> this I have no idea of how to estimate if this thing is remotely
> capable of meeting my logic requirements.  Any input, URLs, etc. is
> appreciated.  TIA.
> 
> - Stout

 A strange target, this one :-)

 What chip did the 40 pin socket target ?

 Do you mean you hope to Implement a 8051 SoftCore+Other things 
in a ATF2500 ?
The answer is NO. ( not by a long shot :)

 If you already have the 8051 on the board and want the 2500 to do
'some glue and a couple of other oddball things', then yes,
that becomes possible.

 You will see the 2500 does come in DIP40, and has centre Vcc.Gnd, but
appart 
from that, the 24IO and 14IP are very 'swapable'.
 The Flash ATF2500 is 'advance information', but the ATV2500 is 
available, and we have used them.

 So, you could worm the PCB, or make a daughter PCB.

 If you don't have the 8051, and these PCBs are 'really expensive', then
I'd look at a daughter PCB using TQFP44 89S52/53 (& up) + TQFP ATF1502 
- both are In System Programmable, and low cost.

 We have done PCB's like this, and if you make SOME of the DIP40 pins
single sided ( not thru hole ), then there is room on the top for
TQFP44's
and it keeps small mechanically.

-jg

-- 
======= 80x51 Tools & IP Specialists  =========
= http://www.DesignTools.co.nz

Article: 38122
Subject: Re: Q:where can I find an indepth manual about P&R in Quartus II ?
From: shengyu_shen@hotmail.com (ssy)
Date: 6 Jan 2002 03:15:43 -0800
Links: << >>  << T >>  << A >>
Hi Kevin

I look at the tour of Quartus II

it contain the following info:
1 view fit in floorplan editor
2 editng assignment

but these is not enough
I want to know the methodology, not only the operations,

that is to say, not only how to perform these operations, but also why
and how to use all these operations

thank you in advance

Kevin Brace <nospamtomekevinbraceusenet@nospamtomehotmail.com> wrote in message news:<a18oti$4q7$1@newsreader.mailgate.org>...
> Did you read through the Quartus II tutorial?
> Altera's device datasheets should give you some insight into device
> architectures.
> 
> 
>  
> Kevin Brace (don't respond to me directly, respond within the newsgroup)
> 
> 
> 
> 
> ssy wrote:
> > 
> > Hi everyone
> > 
> > where can I find an indepth manual about P&R in Quartus II ?
> > 
> > thank in advance

Article: 38123
Subject: Re: how do i program a Spartan FPGA
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sun, 6 Jan 2002 12:23:22 +0100
Links: << >>  << T >>  << A >>
"Nachiket Kapre" <nachikap@yahoo.com> schrieb im Newsbeitrag
news:eadce17c.0201052213.146ca927@posting.google.com...
> Hello,
>  I am currently in a project which uses Spartan FPGA and need to know
> how to program it. Can I make my own version of the Parallel Cable III
> and use it to program via the JTAG pins(i have a schematic from the
> xilinx website). Or if I decide to use a Serial PROM ,how can i get it

Yes, this is one option.

> programmed?...is a ciruit schematic avaiable for the same? Or are

This is the second one. The circuit is available in the datasheets.

> there any other programming options that i havent considered?

You can use an embedded microcontroller to configure the FPGA. Dont let
Xapp58 confuse you, doing a simple slave serial mode configuration is MUCH
simpler and faster. All you have to do is to clock in the data bit by bit
(or byte by byte) and thats almost all. The configuratio sequence is
described in the datasheets and some Xapps.

--
MfG
Falk




Article: 38124
Subject: Re: asic vs. fpga
From: kim.enkovaara@iki.fi (Kim Enkovaara)
Date: 6 Jan 2002 11:35:00 GMT
Links: << >>  << T >>  << A >>
In article <3C36C682.3D6F4035@algor.co.uk>, Rick Filipkiewicz wrote:

> There's also something on the budgetary side that's been missed out. ASIC design tools
> (synthesisers, simulators, layout tools, etc.) are MUCH more expensive than the
> corresponding ones for FPGAs. I believe its normal in ASIC design to have several
> "seats" for each of these wich is going to burn another couple of $100K of investment.

The price difference is going smaller all the time as FPGA designs are
getting bigger and bigger and actually require same tools as the ASIC
design. Physical synthesis tools for FPGAs are not cheap. And I don't
understand how simulators are chaper for FPGA, they are the same as
with ASICs. Logic simulators don't care wheter it is FPGA or
ASIC. Also layout tools are not necessary in ASIC design, many layouts
are done by the vendor and the signoff is netlist based. Of course
this costs more than just buying silicon process, but also reduces the
risks, there is no need to do own test silicons to test special blocks
etc.

I think the main reason to go with ASIC is speed and capacity (and
price also that is connected to the capacity). It's quite easy to get
3-5x more speed with ASICs compared to even fastest FPGAs. In
reality some structures are very bad for FPGAs, for example complex
multiplexer structures kill FPGAs (even if you use tricks like 3-state
busses etc.). Sometimes the gates needed in ASIC is 10x less even if
you count with "real" FPGA gates. Also the internal memories of FPGAs
are very small compared to what you can create with ASICs. And FPGA
price is a huge problem if any volume is planned without reduced
functionality. VirtexII 6000 for example is very expensive chip, and
you need quite big pile (~10) of them to replace big 0.13u
ASIC. And think about the power consumption of those 10 FPGAs and the
problems to do PCB layout for 10 big chips.



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
2017JanFebMarApr2017

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