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
2019JanFebMar2019

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 42900

Article: 42900
Subject: Re: PCI-32/Spartan II Pin Outs?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Mon, 06 May 2002 14:14:23 -0500
Links: << >>  << T >>  << A >>
You probably already got the pin out information from Xilinx, but here
is the pin out I got from Insight Electronics Spartan-II PCI Development
Kit's schematics.


NET "CLK" LOC = "P185";
NET "RST_n" LOC = "P199";
NET "AD<31>" LOC = "P203";
NET "AD<30>" LOC = "P204";
NET "AD<29>" LOC = "P205";
NET "AD<28>" LOC = "P206";
NET "AD<27>" LOC = "P3";
NET "AD<26>" LOC = "P4";
NET "AD<25>" LOC = "P5";
NET "AD<24>" LOC = "P6";
NET "AD<23>" LOC = "P10";
NET "AD<22>" LOC = "P14";
NET "AD<21>" LOC = "P15";
NET "AD<20>" LOC = "P16";
NET "AD<19>" LOC = "P17";
NET "AD<18>" LOC = "P18";
NET "AD<17>" LOC = "P20";
NET "AD<16>" LOC = "P21";
NET "AD<15>" LOC = "P36";
NET "AD<14>" LOC = "P37";
NET "AD<13>" LOC = "P41";
NET "AD<12>" LOC = "P42";
NET "AD<11>" LOC = "P43";
NET "AD<10>" LOC = "P45";
NET "AD<9>" LOC = "P46";
NET "AD<8>" LOC = "P47";
NET "AD<7>" LOC = "P49";
NET "AD<6>" LOC = "P57";
NET "AD<5>" LOC = "P58";
NET "AD<4>" LOC = "P59";
NET "AD<3>" LOC = "P61";
NET "AD<2>" LOC = "P62";
NET "AD<1>" LOC = "P63";
NET "AD<0>" LOC = "P67";
NET "C_BE_n<3>" LOC = "P8";
NET "C_BE_n<2>" LOC = "P22";
NET "C_BE_n<1>" LOC = "P35";
NET "C_BE_n<0>" LOC = "P48";
NET "PAR" LOC = "P34";
NET "IDSEL" LOC = "P9";
NET "FRAME_n" LOC = "P23";
NET "IRDY_n" LOC = "P24";
NET "DEVSEL_n" LOC = "P29";
NET "TRDY_n" LOC = "P27";
NET "STOP_n" LOC = "P30";
NET "PERR_n" LOC = "P31";
NET "SERR_n" LOC = "P33";
NET "REQ_n" LOC = "P201";
NET "GNT_n" LOC = "P200";
NET "INTA_n" LOC = "P195";



        The Insight Electronics Spartan-II PCI card used XC2S150-5CPQ208
(208 pin PQFP), but it should be pin compatible with smaller (XC2S30,
XC2S50, XC2S100-5CPQ208) and larger (XC2S200-5CPQ208) ones.
Insight Electronics discontinued the Spartan-II PCI card with
XC2S150-5CPQ208, and now it uses Spartan-II XC2S200-5CFG456 (456 pin
Fine-Pitch BGA) instead.
I know the package is different, but the card itself is very inexpensive
($225), so it might be worth having one.
Note: Unlike some posters of this newsgroup (i.e., Altera employees), I
don't work for PLD vendors or its distributors and use a personal E-mail
address to post here.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)




Anthony Ellis wrote:
> 
> Hi,
> 
> We are developing a PCI system based on Spartan II 208 pin PQFP devices. For
> this we are busy licensing the PCI core but need to finalise our schematic
> designs and hence need some information on the pre-allocated PCI pin numbers
> to use for the 32 bit/33 Mhz PCI core using this device.
> 
> Thanks Anthony.

Article: 42901
Subject: clock multiplication in xilinx
From: nahum_barnea@yahoo.com (Nahum Barnea)
Date: 6 May 2002 12:23:53 -0700
Links: << >>  << T >>  << A >>
Hi.
I need to generate fpga internal clock of 250 MHz in xilinx virtex2 device.

I have 2 possibilities:

1. Use external oscilator of 125 MHz and use the DCM to multiply it by 2.
2. Use external oscilator of 25 MHz and use the DCM to multiply it by 10.

What is expected to give me better results in term of lower jitter
and simplicity ?

ThankX
Nahum.

Article: 42902
Subject: Re: clock multiplication in xilinx
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 06 May 2002 13:18:42 -0700
Links: << >>  << T >>  << A >>
Nahum,

The jitter calculator program yields the following worst case results:

125 X 2 = 0.67 ns P-P, or 16.8% UI

50 X 5 = .61 ns P-P, or 15.2% UI

25 X 10 = violates the min freq in for HF mode, or the max freq out for LF mode
(not allowed).

The jitter calculator is supported through the hotline (email them with your
request), or thru your FAE.

Austin

Nahum Barnea wrote:

> Hi.
> I need to generate fpga internal clock of 250 MHz in xilinx virtex2 device.
>
> I have 2 possibilities:
>
> 1. Use external oscilator of 125 MHz and use the DCM to multiply it by 2.
> 2. Use external oscilator of 25 MHz and use the DCM to multiply it by 10.
>
> What is expected to give me better results in term of lower jitter
> and simplicity ?
>
> ThankX
> Nahum.


Article: 42903
Subject: Re: clock multiplication in xilinx
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 6 May 2002 22:28:05 +0200
Links: << >>  << T >>  << A >>
"Nahum Barnea" <nahum_barnea@yahoo.com> schrieb im Newsbeitrag
news:fc23bdfc.0205061123.5b4b4bfd@posting.google.com...
> Hi.
> I need to generate fpga internal clock of 250 MHz in xilinx virtex2
device.
>
> I have 2 possibilities:
>
> 1. Use external oscilator of 125 MHz and use the DCM to multiply it by 2.
> 2. Use external oscilator of 25 MHz and use the DCM to multiply it by 10.
>
> What is expected to give me better results in term of lower jitter
> and simplicity ?

I would say 1.

--
MfG
Falk





Article: 42904
Subject: Re: virtex2: clk via clk buf to BRAM
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 6 May 2002 22:29:40 +0200
Links: << >>  << T >>  << A >>
"sanjay parekh" <saparekh@nortelnetworks.com> schrieb im Newsbeitrag
news:3CD6CE8F.C86FF7C4@nortelnetworks.com...
> Hi,
> While going through appnotes, I see that clock to the BRAM is always
> sent through a clk buffer.  Why is this?
> In my case I only have one clock that goes to block ram as well as rest
> of the logic.  And synplify, correctly identifies that as a system clock
> and uses global clock lines to route that clock.  I am assuming, that in
> this case I will not necessarily have to route the clock to the bram via
> clk buffer.

No. If the clock for your system is already on a global clock net (driven by
a global clock buffer) all is fine.

--
MfG
Falk





Article: 42905
Subject: max 7000
From: "Roger King" <roger@king.com>
Date: Mon, 06 May 2002 21:16:59 GMT
Links: << >>  << T >>  << A >>
Hi,

Can the MAX7000 chip from altera hold a fairly complex design?



Article: 42906
Subject: Re: max 7000
From: "******" <spam.dump.address@some.phoney.server.net>
Date: Mon, 06 May 2002 21:39:14 GMT
Links: << >>  << T >>  << A >>
Short answer -- Yes.

But to be more specific, you'd have to specify your specific needs (gates,
macrocells).

I've impemented designs using the 7128 and 7160 devices (128 and 160
macrocells) and have found them to be adequate.  One macrocell holds the
equivelant of one flip-flop.  But for larger designs (cpu cores, etc) you
may want to try something larger.



"Roger King" <roger@king.com> wrote in message
news:fpCB8.46513$zk1.12928@news01.bloor.is.net.cable.rogers.com...
> Hi,
>
> Can the MAX7000 chip from altera hold a fairly complex design?
>
>



Article: 42907
Subject: Re: 1000 I/O Pins -- What is cheapest FPGA?
From: Ray Andraka <ray@andraka.com>
Date: Mon, 06 May 2002 22:13:23 GMT
Links: << >>  << T >>  << A >>
Not permanently programmed.  They are tested with your bitstream and guaranteed to work
with THAT bitstream.  Recompile the design, and all bets are off.  Basically it is
writing a custom test for the devices to test only the logic that you use in your
design.

Georg Acher wrote:

> In article <3CC028CE.2CEBCABC@xilinx.com>,
>  Austin Lesea <austin.lesea@xilinx.com> writes:
>
> |> 2.  easy path does not map around 'bad logic'.  You send us your stable
> |> design, and we send you chips marked just as ASICs are marked that are 100%
> |> good at speed for your application.  That is why it is so easy!  Customer does
> |> nothing, except make a committment to buy X units, non-refundable,
> |> non-returnable....hey just like an ASIC.  The big difference?  About a million $
> |> for the NRE for the ASIC, compared with our NRE for the test program, supply
> |> management, and marking.  Oh, and no time delay, and no risk.
>
> I wonder how this can be done (technically)... How do you permanently program
> the chips? I remember vaguely a similar offer for the XC4k-series a while ago...
> --
>          Georg Acher, acher@in.tum.de
>          http://www.in.tum.de/~acher/
>           "Oh no, not again !" The bowl of petunias

--
--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: 42908
Subject: Re: max 7000
From: "Roger King" <roger@king.com>
Date: Mon, 06 May 2002 22:13:55 GMT
Links: << >>  << T >>  << A >>
Hmmm... 128 macrocells.... so for example, one AND gate would take one
macrocell? etc....?


"******" <spam.dump.address@some.phoney.server.net> wrote in message
news:6KCB8.47786$zk1.30670@news01.bloor.is.net.cable.rogers.com...
> Short answer -- Yes.
>
> But to be more specific, you'd have to specify your specific needs (gates,
> macrocells).
>
> I've impemented designs using the 7128 and 7160 devices (128 and 160
> macrocells) and have found them to be adequate.  One macrocell holds the
> equivelant of one flip-flop.  But for larger designs (cpu cores, etc) you
> may want to try something larger.
>
>
>
> "Roger King" <roger@king.com> wrote in message
> news:fpCB8.46513$zk1.12928@news01.bloor.is.net.cable.rogers.com...
> > Hi,
> >
> > Can the MAX7000 chip from altera hold a fairly complex design?
> >
> >
>
>



Article: 42909
Subject: Re: bad experience with Xilinx ISE 4.1i and Xilinx hotline suppot
From: Ray Andraka <ray@andraka.com>
Date: Mon, 06 May 2002 22:20:44 GMT
Links: << >>  << T >>  << A >>
Usually when this happens it is due to another constraint inadvertantly taking
precedence over the intended constraint.  Most likely you had some from:to constraints
(of the multi-cycle variety) that caused a problem with constraints you thought were
on the top level period constraint.  It may have also been an input to or an output
from the FPGA, for which the period constraints don't apply.

Tullio Grassi wrote:

> Believe it or not we have a design strictly sinchronous (ALL flip-flops with the
> same clk),
> the logic simulation and the static timing analysis are fine,
> but the post-P&R simulation reports several timing violation from
> VirtexE dual-port RAMs  (we use ISE4.2).
>
> Also in my case the Xilinx support (Case # 420370 and another one) was not
> satisfactory.
>
> Tullio Grassi
>
> Ray Andraka wrote:
>
> > I don't concur.  It is very, no extremely,  rare that the P&R tools screw up a
> > design.  A post P&R won't tell much of anything that a thorough static timing
> > analysis and functional (pre-PAR) simulation won't tell you.  It can actually be
> > rather dangerous, as it can be very difficult to come up with a set of vectors
> > that cover all paths, especially in a large design.
> >
> > To check on the synthesized results, use the mapped output from the synthesis
> > for a post synthesis functional simulation.  It will run a lot faster than the
> > timing annotated post PAR simulation.

--
--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: 42910
Subject: Opinions on FPGA cores - best for a commercial project?
From: arast@inficom.com (Alex Rast)
Date: Mon, 06 May 2002 22:21:58 GMT
Links: << >>  << T >>  << A >>
OK, I apologize in advance. What I'm asking is virtually guaranteed to start a 
firestorm. I realize that this is a topic about which people will have both 
strong biases and vested interests. So, before starting, I beg everybody: 
Please, let's not turn this question into a battle of opposing polemics.

I'm involved in a commercial project with projected volumes into the 100's of 
thousands if not millions per month. We've got a PCI card, and we've decided 
to implement the PCI interface in an FPGA, along with multiple other 
functions. 

What I would like is opinions as to the best PCI core developers. Let's say 
for the moment that the FPGA brand isn't particularly important, or is open to 
change. I don't care if the core in question comes from the FPGA manufacturer, 
a third-party vendor or consultant, or a freeware download. We'd like people's 
real-world experiences as to which cores work reliably, efficiently, at high 
speed, bug-free, and in full compliance with the spec.

Also, are there any cores where the source code isn't supplied and/or isn't 
modifiable? If so, I'd like to get some perspective on the quality/reliability 
of such "hard-coded" cores as opposed to "soft" cores which the user can 
modify as needed.

I'd also like to know whether the cores that you recommend are 33 MHz, 66 MHz, 
what version of PCI they're compliant with, and whether they're target, 
master, or bridge. If the developer supplies various different types, and if 
you have experience, give me your opinions on each version if possible, so I 
can see how the relative merits stack up for each implementation.

Alex Rast
arast@inficom.com
arast@qwest.net


Article: 42911
Subject: Re: max 7000
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 07 May 2002 10:50:00 +1200
Links: << >>  << T >>  << A >>
Roger King wrote:
> 
> Hi,
> 
> Can the MAX7000 chip from altera hold a fairly complex design?

Yes and no.

 Perhaps you should explain 'fairly complex' better ?

 CPLDs commonly have a Wide AND.OR macrocell structure, 
normally each macrocell can contain one register, and up 
to 5 Ip OR, from Wide AND terms.

 Some CPLDs, like Atmel ATF150x, have dual feedback paths so
you can squeeze two latches into one macrocell, or bury a 
counter and have some OR logic left.

 If you need many registers and little logic, CPLDs are not
efficent.

-jg

Article: 42912
Subject: Re: Opinions on FPGA cores - best for a commercial project?
From: John Larkin <jjlarkin@highlandSNIP_THIStechnology.com>
Date: Mon, 06 May 2002 16:15:00 -0700
Links: << >>  << T >>  << A >>
On Mon, 06 May 2002 22:21:58 GMT, arast@inficom.com (Alex Rast) wrote:

>OK, I apologize in advance. What I'm asking is virtually guaranteed to start a 
>firestorm. I realize that this is a topic about which people will have both 
>strong biases and vested interests. So, before starting, I beg everybody: 
>Please, let's not turn this question into a battle of opposing polemics.
>
>I'm involved in a commercial project with projected volumes into the 100's of 
>thousands if not millions per month. We've got a PCI card, and we've decided 
>to implement the PCI interface in an FPGA, along with multiple other 
>functions. 
>
>What I would like is opinions as to the best PCI core developers. Let's say 
>for the moment that the FPGA brand isn't particularly important, or is open to 
>change. I don't care if the core in question comes from the FPGA manufacturer, 
>a third-party vendor or consultant, or a freeware download. We'd like people's 
>real-world experiences as to which cores work reliably, efficiently, at high 
>speed, bug-free, and in full compliance with the spec.
>
>Also, are there any cores where the source code isn't supplied and/or isn't 
>modifiable? If so, I'd like to get some perspective on the quality/reliability 
>of such "hard-coded" cores as opposed to "soft" cores which the user can 
>modify as needed.
>
>I'd also like to know whether the cores that you recommend are 33 MHz, 66 MHz, 
>what version of PCI they're compliant with, and whether they're target, 
>master, or bridge. If the developer supplies various different types, and if 
>you have experience, give me your opinions on each version if possible, so I 
>can see how the relative merits stack up for each implementation.
>
>Alex Rast
>arast@inficom.com
>arast@qwest.net


Talk to Ray...

http://www.andraka.com/


He knows a *lot* about this stuff.

But at 'millions a month' an FPGA will be an expensive way to go.

John


Article: 42913
Subject: LVPECL clock: which inputs?
From: "Theron Hicks (Terry)" <hicksthe@egr.msu.edu>
Date: Mon, 06 May 2002 21:25:58 -0400
Links: << >>  << T >>  << A >>
Hi,
I am trying to use an LVPECL clock input on a spartan2e.  Which inputs
should I use?  If I recall correctly, there are standard clock inputs,
standard LVPECL inputs and a CLKDLL input that is supposed to be LVPECL
if I recall correctly.  (Sorry, I am asking this from home and I don't
want to wait to download the data sheet over the modem.) Which one is
prefered?  The clock goes immediately into a delay-locked-loop if this
has any importance?  The DLL is just being used to get the 0 degree and
90 degree outputs (freq is ~100 MHz.)  Also, how do I instantiate this
in webpack 4.2?  If I recall correctly, an LVPECL input is just
instantiated as a single input port.  Does the other line show up either
in the pad report or the constraints editor?

Thanks,
Theron Hicks


Article: 42914
Subject: Re: Opinions on FPGA cores - best for a commercial project?
From: assaf_sarfati@yahoo.com (Assaf Sarfati)
Date: 6 May 2002 22:11:25 -0700
Links: << >>  << T >>  << A >>
arast@inficom.com (Alex Rast) wrote in message news:<llDB8.174$vz5.79857@news.uswest.net>...
> OK, I apologize in advance. What I'm asking is virtually guaranteed to start a 
> firestorm. I realize that this is a topic about which people will have both 
> strong biases and vested interests. So, before starting, I beg everybody: 
> Please, let's not turn this question into a battle of opposing polemics.
> 
> I'm involved in a commercial project with projected volumes into the 100's of 
> thousands if not millions per month. We've got a PCI card, and we've decided 
> to implement the PCI interface in an FPGA, along with multiple other 
> functions.

For this volume, why not go for an ASIC? both Altera and Xilinx offer 
"ASIC Replacement" FPGAs, but they are still more expensive than
ASICs...especially if you add the cost of an external configuration-ROM.
 
> 
> What I would like is opinions as to the best PCI core developers. Let's say 
> for the moment that the FPGA brand isn't particularly important, or is open to 
> change. I don't care if the core in question comes from the FPGA manufacturer, 
> a third-party vendor or consultant, or a freeware download. We'd like people's 
> real-world experiences as to which cores work reliably, efficiently, at high 
> speed, bug-free, and in full compliance with the spec.
> 

We've used the Xilinx PCI core. It works OK, but requires 
non-trivial design work around it - the so-called "user
application". This UA requires some state-machine design, 
and (harder to implement, MUCH harder to verify) logic to 
cross clock domains (async FIFOs and other nasty stuff).


> Also, are there any cores where the source code isn't supplied and/or isn't 
> modifiable? If so, I'd like to get some perspective on the quality/reliability 
> of such "hard-coded" cores as opposed to "soft" cores which the user can 
> modify as needed.
> 

The Xilinx core (and AFAIK the Altera core as well) come only 
in net-list format with constraint files. We haven't even been 
able to get source-code price quote from Xilinx (maybe we're too 
small).

> I'd also like to know whether the cores that you recommend are 33 MHz, 66 MHz, 
> what version of PCI they're compliant with, and whether they're target, 
> master, or bridge. If the developer supplies various different types, and if 
> you have experience, give me your opinions on each version if possible, so I 
> can see how the relative merits stack up for each implementation.
> 

We've used the 64-bit/66-MHz Master/Slave configuration. However, 
the absolute majority of PCs use 32-bit/33-MHz PCI. Only Server
boards have 64/66 PCI buses (I am not sure if AMD's 760MPX chipset 
boards are considered server boards). If your design is for standard
workstation PC, use 32/33 PCI.

Master/Target vs. Target only: depends on your application. If your
application moves non-trivial amount of data or accesses a non-trivial
range of memory addresses, Master implementation is much better from
system-design view.


> Alex Rast
> arast@inficom.com
> arast@qwest.net

Some other thoughts:

* Any core that you buy will make it harder to convert to ASIC, unless 
  you get it in source-code format.
* PCI is not too hard to implement. The big problems are verification 
  and, in FPGA, timing compliance. The PCI-bus has some async paths
  (especially around IRDY and TRDY) which makes timing compliance
  tricky.

Regards
Assaf Sarfati
(assaf_sarfati@yahoo.com)

Article: 42915
Subject: FPGA in Storage
From: gauravhazra@yahoo.com (Gaurav)
Date: 6 May 2002 22:14:59 -0700
Links: << >>  << T >>  << A >>
hello 

My name is gaurav & am working as a market analyst in india. I want to
know if anyone of you had implemented a SAN or storage component like
a RAID controller using a FPGA. It would be also encouraging to
understand if there are any other storage / SAN components like HBA ,
SAN switch etc where FPGA implemantation been witnessed.

In case somebody is engaged in such storage compoments design using
FPGA or related design please do let me know your whats are the basic
requiremenst and the kind of device or IPS that were used in such
implementations.

Am available on gauravhazra@yahoo.com I been working in this industry
for about four years in the area of High performance computing , EDA ,
Servers & storage Entreprise newtorking , MCAD  etc.

regards 

gaurav

Article: 42916
Subject: Re: Opinions on FPGA cores - best for a commercial project?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Tue, 07 May 2002 00:29:27 -0500
Links: << >>  << T >>  << A >>
Alex Rast wrote:
> 
> OK, I apologize in advance. What I'm asking is virtually guaranteed to start a
> firestorm. I realize that this is a topic about which people will have both
> strong biases and vested interests. So, before starting, I beg everybody:
> Please, let's not turn this question into a battle of opposing polemics.
> 


        I have seen some Altera employees posting in this newsgroup
using personal E-mail addresses, but almost none of them seem to want to
disclose their affiliation.
At least some Xilinx employees who post here use their work E-mail
address, so I know where their opinions come from.
When people from PLD vendors recommend their own company's products in
this newsgroup (I have seen one Altera employee do that frequently.), I
prefer if they will mention that they work at a PLD vendor, but most of
them don't.
Anyhow, I am not connected to any of those firms, so whatever I say is
my own opinion.




> I'm involved in a commercial project with projected volumes into the 100's of
> thousands if not millions per month. We've got a PCI card, and we've decided
> to implement the PCI interface in an FPGA, along with multiple other
> functions.
> 
> What I would like is opinions as to the best PCI core developers. Let's say
> for the moment that the FPGA brand isn't particularly important, or is open to
> change.


        Sounds like it will be cheaper to do an ASIC or a gate array
rather than using an FPGA, unless there is some kind of advantage using
an FPGA.
If you are doing PCI in an FPGA, my personal preference will be to go
with a Xilinx FPGA if you are planning to use an SRAM-based FPGA.
I don't personally recommend Altera because I have had lots of problems
with Quartus II 2.0's (I used the free Web Edition, not the full
version.) fitter and floorplanner when I tried to port my PCI IP core to
FLEX10KE.
In my opinion, Xilinx's tool gives users much more flexibility on the
backend side compared to Altera's Quartus II, and especially when using
a softcore PCI IP core, that's very important.
If you don't mind using an anti-fuse FPGA, Quicklogic's QuickPCI might
be interesting, but you won't have much flexibility because the PCI
interface will already be there.




> I don't care if the core in question comes from the FPGA manufacturer,
> a third-party vendor or consultant, or a freeware download.
>  We'd like people's
> real-world experiences as to which cores work reliably, efficiently, at high
> speed, bug-free, and in full compliance with the spec.
> 


        First of all, you can try out Opencores.org PCI IP core
(http://www.opencores.org/projects/pci/) since it is free. 
My own biased opinion about Opencores.org PCI IP core will be that the
authors didn't seem to care about readability and maintainability when
they designed it, so I think it will be pretty hard to make
modifications or fix bugs if you have to.
        Of course, Xilinx has their own LogiCORE PCI, but the problem of
using theirs will be that you won't be able to do an ASIC conversion if
you want to.
The only way out will be to use AMI Semiconductor's FPGA to ASIC
conversion service which offers a LogiCORE PCI compatible PCI IP core.
LogiCORE PCI is a hard macro (an encrypted netlist), so other than
parameterizable portion of it, you won't be able to modify it even if
you want to.
Supposedly, there are some customization services, but that will be
extra.
        An independent third party IP core vendor CAST
(http://www.cast-inc.com) also seems to offer a PCI IP core for Xilinx
FPGAs, and seems to let you port it to an ASIC.
They claim it can do 66MHz PCI in Virtex, but I will guess that it will
be with Virtex-E or faster parts. (I will explain that why I think so
later.)
Dark Room Technologies (http://www.darkroom.com/) also has a PCI IP core
done in Viewdraw schematics, but I am not sure if it can be licensed.
I believe there are a few more independent third party IP core vendors
who offer PCI IP cores, but I cannot think of their names.
        I guess mine won't even meet your criteria considering that it
is not fully debugged yet, but I have been working on my own
synthesizable Verilog-based PCI IP core for some time. (> 1 year)
It should be fully debugged at some point, but if you want to be a
guinea pig now, that's possible.
Of course, it won't be free and it will cost something considering the
time and effort I have put into developing it.




> Also, are there any cores where the source code isn't supplied and/or isn't
> modifiable? If so, I'd like to get some perspective on the quality/reliability
> of such "hard-coded" cores as opposed to "soft" cores which the user can
> modify as needed.
> 


        In my opinion, Xilinx and Altera supplied PCI IP cores are there
to pin down the users to their FPGAs, so that users won't even think of
doing an ASIC conversion.
The only way out will be AMI Semiconductor's LogiCORE PCI clone, or
using third-party IP core vendors.
If you are planning to do an ASIC conversion, don't bother with the PCI
IP cores from the PLD vendors.



> I'd also like to know whether the cores that you recommend are 33 MHz, 66 MHz,
> what version of PCI they're compliant with, and whether they're target,
> master, or bridge. If the developer supplies various different types, and if
> you have experience, give me your opinions on each version if possible, so I
> can see how the relative merits stack up for each implementation.
> 
> Alex Rast
> arast@inficom.com
> arast@qwest.net


        First of all, I believe I said several months ago that even in
Spartan-II-5, 33MHz PCI is hard or impossible.
Well, I will take that back, and now I can say that 33MHz PCI is not too
hard in Spartan-II-5.
After several months of try, I got my synthesizable PCI IP core to meet
33MHz PCI 's Tsu < 7ns requirement without having to do too much manual
floorplanning.
However, 66MHz PCI still remains very hard in most FPGAs, and there are
several tricks needed to meet its brutal Tsu < 3ns requirement.
Xilinx resorts to two undocumented features to meet 66MHz PCI's timings,
PCILOGIC and BITGEN's /Gclkdel option, although I was able to figure out
a way to use PCILOGIC in my PCI IP core, and saw it actually working in
a real computer.
Other than the undocumented features, the logic has to be designed
carefully to have any chance of meeting Tsu < 3ns, and even after that,
my PCI IP core didn't meet Tsu < 3ns in Spartan-II-6.
Although it doesn't mean much since mine didn't meet Tsu < 3ns, it came
pretty close: Only 15 or so paths missed timings, and PAR's timing score
was about 1,500.
Because I found it very hard to meet Tsu < 3ns in Spartan-II-6, you
might need Virtex-E or Virtex-II for 66MHz PCI, unless you are using
LogiCORE PCI, but those two parts don't support 5V PCI, so you won't be
able to make a Universal PCI card with them. (A PCI card that supports
3.3V and 5V PCI signaling.)
Although PCISIG is trying to force manufacturers to adopt 3.3V PCI,
almost no one makes motherboards with 3.3V PCI (Only a few expensive
workstation class motherboards have 3.3V PCI slots.), so making a 3.3V
PCI only card will severely restrict its market potential.
To sell your company's card to the mass market (5V PCI), you should use
Virtex/Spartan-II for a Universal card, and not bother with 66MHz PCI if
you are not planning to use LogiCORE PCI. (i.e., Do a Universal card,
but support only 3.3V and 5V 33MHz PCI.)



Regards,



Kevin Brace

Article: 42917
Subject: Re: Opinions on FPGA cores - best for a commercial project?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Tue, 07 May 2002 00:57:42 -0500
Links: << >>  << T >>  << A >>

Assaf Sarfati wrote:
> 
> 
> We've used the Xilinx PCI core. It works OK, but requires
> non-trivial design work around it - the so-called "user
> application". This UA requires some state-machine design,
> and (harder to implement, MUCH harder to verify) logic to
> cross clock domains (async FIFOs and other nasty stuff).
> 


        I think the problem with LogiCORE PCI is that it doesn't let the
backend side insert wait cycles in the middle of a transfer.
Therefore, it seems the use of FIFO buffers becomes near mandatory for
decent performance.



> 
> The Xilinx core (and AFAIK the Altera core as well) come only
> in net-list format with constraint files. We haven't even been
> able to get source-code price quote from Xilinx (maybe we're too
> small).
> 


        I doubt Xilinx or Altera will ever give you the source code
considering their IP cores are there to prevent an ASIC conversion.
I heard that LogiCORE PCI was originally done in Viewdraw schematics,
but I also heard that they are moving towards using Synplify.
I don't how Altera did theirs, and I will be interested to hear that.



> 
> We've used the 64-bit/66-MHz Master/Slave configuration. However,
> the absolute majority of PCs use 32-bit/33-MHz PCI. Only Server
> boards have 64/66 PCI buses (I am not sure if AMD's 760MPX chipset
> boards are considered server boards). If your design is for standard
> workstation PC, use 32/33 PCI.
> 


        I will consider AMD-760MPX a server/workstation class chipset
rather than a desktop chipset considering the cost of making such a
board.
Because there are so many 5V PCI cards, I predict PCISIG's intention to
kill 5V PCI will fail because there are so many 5V PCI cards out there,
it seems impractical to junk that many 5V PCI cards just because PCISIG
doesn't like it.
I will guess that 5V PCI will die when PCI Express (formerly 3GIO)
becomes cheap enough that even a $600 PCs can include it.



> 
> Some other thoughts:
> 
> * Any core that you buy will make it harder to convert to ASIC, unless
>   you get it in source-code format.
> * PCI is not too hard to implement. The big problems are verification
>   and, in FPGA, timing compliance. The PCI-bus has some async paths
>   (especially around IRDY and TRDY) which makes timing compliance
>   tricky.
> 
> Regards
> Assaf Sarfati
> (assaf_sarfati@yahoo.com)


        Timing closure is a problem in FPGAs, but from my own experience
of doing my own PCI IP core, it largely depends on the skill of the
designer.
When I first did mine, I didn't use CE (Clock Enable) in my PCI IP core
at all, so it cost me a lot in terms of timing closure, but after I
figured out how to use CE effectively (Took me 4 months to figure that
out.), the timing problems went away.
Also, knowing the IOB packing rules is equally important, and I didn't
know anything about it when I first did mine. (I was a total newbie of
FPGAs.)
Speaking of the IRDY and TRDY path, if you are using Virtex/Spartan-II,
there is a special undocumented logic called PCILOGIC which solves the
timing problems of the path you are referring to.
I incorporated that into my PCI IP core, and it worked when I tested in
a real computer.


Regards,


Kevin Brace

Article: 42918
Subject: Re: Opinions on FPGA cores - best for a commercial project?
From: "Victor Schutte" <victors@mweb.co.za>
Date: Tue, 7 May 2002 09:09:47 +0200
Links: << >>  << T >>  << A >>
When you start thinking of producing 100s or 1000s it turns more into a
business problem. First ask yourself a few questions:
- What is your profit margin (cost for components, manufacturing, marketing,
storage, shipping etc... +Profit)?
- What is your time to market? If you spend 6 months on development your
market might shrink or disappear, etc...
- Is it very important that you have some control over your market (e.g.
some weird 273.6 point FFT (joke) that will keep your edge). Everybody has
some form of PCI bus interface, so if they want to copy it they can.
- Do you want to play? Do you want your company to fork out $xxx for a nice
new tool to play with FPGAs (I did that about 6 years ago)
- Do you want flexibility? FPGAs gives you this but with PCI you might
design yourself into a corner.
- What is the life cycle of your product?  If you sold millenium watches
during 1999 you would have had less than a year to sell. With a military
product you need to support it for about 15 years.
- Play devils advocate. What if somebody like me saw your product and wanted
to copy it? Would I go for a FPGA or a nicely sorted out hardwired core like
the PCX (at a much lower cost)
- How complex are your other functions? Example: Do you require PCI, with
say a NE2000 network interface, with USB and a small processor? You will
sometimes find that most of these functions can be bought off the shelf for
cheaper than one FPGA.
- What are you views on IP protection? If I see a PCB with a configuration
EPROM  I see something that can be copied and pushed on the grey market.
- Do you have investers? An intelligent invester will recognize that money
has to spent wisely and time/cost effectively. If you start using timescales
like 6 months, but wow then you have your own IP core, as opposed to we buy
it today and use it tomorrow but it might be double the cost I will go for
the latter.
- Do you really understand the complexity of FPGAs? You can whip up a small
state machine in 5 minutes, but ending up debuging it for days. FPGAs are
the technology for the relativily poor electronics guy that cannot affort to
have a silicon processing plant like Intel. Once you have your design ready
then it is clear sailing. Designing a FPGA into a new product, especially
one that you aim to sell zillions of, is very much like investing in the
stock market (you know the ability of performance  but you cannot guarantee
it nor investor confidence). People investing money (or worse your boss)
might not be interested in: "oops, we need one more LUT" or "we cannot
tristate this pin because of .....".  FPGAs are my hobby. I sit and play and
when something works, then I go and market. Many times I have promised a
simple design that ended up using a CPLD/FPGA 4 times the size . Example: 4
years ago I swore by FPGAs and convinced my client to use a FLEX10K10 as a
Dual Port Ram (plus the selling point of adding other functions) and we
could lay out the board before we are even finished with the design.
Result: The FPGA (doing 512 bytes DPR) and config EPROM was about 20%
cheaper than the IDT/Cypress chip doing 16384 bytes. The FPGA design took 30
days longer to track down weird timing problems. The onboard CPU uses this
device for scratch pad RAM but the code had to be seriously optimised to use
only 256 bytes. The client ended up with the added problem that they had to
find a facility to program the EPC1 config IC. The design now works and is
in production, but any small change is still a mountain of a problem for the
client.

PS * I wanted to design my own CPU on FPGA, for several good reasons
(especially cost), and my own C compiler. Instead of that I went and bought
NIOS from Altera (still waiting for the Xilinx guys to get back to me). I
was up and running in about a week.  The new version can do 16/32 bit RISC
code, run up to 125MHz in the newer ICs, includes peripherals like UARTs,
Timers,SPI, DMA  and you can evaluate PCI and USB (or buy) cores that fits
directly into this plus you get a free C/C++ compiler along with it.


My opinion:* If you have money ( or investors), then avoid developing to
much( especially for gazillions of units). You just want to make money.
*If you are flat broke and knows somebody with a PC and CAD software go for
a FPGA. Experience told me that it will turn out into a muckup in any case
( Simple business equations   Your idea(or capability) + someone elses
requirement (and the line "we'll make lots of money) = Screwup+loss in food
investment money+time wasted+wife/husband cheesed-off   as apposed to   Your
capability + INVESTOR + Other people doing the work= Good prototype + happy
investor (more money) + good marketing + real shot in getting it
manufactured and sold)
*If you run a small business and only want to sell about a 100 units then go
for FPGAs.

Don't reinvent the wheel, especially if you don't know it is round.  Rather
go to you nearest car dealer and choose one (with a maintenance plan).

Victor Schutte
Zerksus Engineering CC
ZerTec Engineering  MD



"Alex Rast" <arast@inficom.com> wrote in message
news:llDB8.174$vz5.79857@news.uswest.net...
> OK, I apologize in advance. What I'm asking is virtually guaranteed to
start a
> firestorm. I realize that this is a topic about which people will have
both
> strong biases and vested interests. So, before starting, I beg everybody:
> Please, let's not turn this question into a battle of opposing polemics.
>
> I'm involved in a commercial project with projected volumes into the 100's
of
> thousands if not millions per month. We've got a PCI card, and we've
decided
> to implement the PCI interface in an FPGA, along with multiple other
> functions.
>
> What I would like is opinions as to the best PCI core developers. Let's
say
> for the moment that the FPGA brand isn't particularly important, or is
open to
> change. I don't care if the core in question comes from the FPGA
manufacturer,
> a third-party vendor or consultant, or a freeware download. We'd like
people's
> real-world experiences as to which cores work reliably, efficiently, at
high
> speed, bug-free, and in full compliance with the spec.
>
> Also, are there any cores where the source code isn't supplied and/or
isn't
> modifiable? If so, I'd like to get some perspective on the
quality/reliability
> of such "hard-coded" cores as opposed to "soft" cores which the user can
> modify as needed.
>
> I'd also like to know whether the cores that you recommend are 33 MHz, 66
MHz,
> what version of PCI they're compliant with, and whether they're target,
> master, or bridge. If the developer supplies various different types, and
if
> you have experience, give me your opinions on each version if possible, so
I
> can see how the relative merits stack up for each implementation.
>
> Alex Rast
> arast@inficom.com
> arast@qwest.net
>



Article: 42919
Subject: Timing Scores
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Tue, 7 May 2002 09:33:12 +0200
Links: << >>  << T >>  << A >>
Hi,

How exactly are Xilinx's Foundation timing scores calculated? Write now I
have just been comparing different incarnations of my design, and so things
are relative to each other. But what is a good timing score, say for a 100
000 gate design?

Thanks
adrian




Article: 42920
Subject: Re: Availability of XC2S150E-6FG456I
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 07 May 2002 08:38:51 +0100
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

> I am discussing a spec problem with TI on the C6711B.  Seems that they
> spec'd the C6711 with a shorter hold time (although they lengthened it a
> bit in the errata).  The C6711B has a 2.5 nS hold time which is 1 nS
> longer than the SBSRAM.  But he also explained that "the device returned
> to its standard operating voltage of 1.8V".  So they must have been
> spec'ing it at something higher although I can't find it.  
> 

Hi Rick,

I seem to recall one bit fo the errata for the C6711 (non-B) that
said increasing the core supply to 1.9V allowed you to meet the
datasheet timing - maybe that's what he was referring to?

Cheers,

Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 42921
Subject: Re: Frequency synthesiser
From: "Martin E." <0_0_0_0_@pacbell.net>
Date: Tue, 07 May 2002 08:11:43 GMT
Links: << >>  << T >>  << A >>
"Noddy" <g9731642@campus.ru.ac.za> wrote in message various messages...

> All I want to do is generate a +/- 32 MHz [down to mHz resolution]
...
> The 5 MHz clock is highly stable, generated by a hydrogen maser.
...
> I need to be able to set my 32 MHz frequency down to mHz accuracy ie.
> 32.031 Mhz, and of course there should be no jitter
...
> Sorry, meant to write 32.000000031 MHz...

Not taking a cheap-shot here, just some constructive criticism ... you might
want to consider turning off that maser before you get hurt and go figure
out how to specify/communicate critical parameters like these.  You had
everybody going off in one direction, then you clarify with what was a very,
very different degree of a problem and then you push everyone back in the
abyss.

Which is it?  And, BTW, do you realize how hard it is to read 32.000000031
MHz instead of 32,000,000.031 Hz?.

It seems you need 0.001 Hz resolution with a range from 31,500,000.000 Hz to
32,500,000.000 Hz.

But...

In one of your messages you state that you are trying to design a frequency
synthesizer with 30 bits of precision.  A quick bit of math and it is clear
that you are applying the 30 bits to the 1 MHz range from 31.5 to 32.5.
Now, that translates into a step size of 0.0009313 ... Hz.  This is
different from a 0.001 Hz step specification.  If the 30 bit parameter was
set to 100,000,000 your output frequency would be 31,593,132.2575 Hz, and
not 31,600,000.0000 Hz, a difference of almost 7 KHz.  Is that OK?  Which
one is it you want to synthesize?  Is that significant for "coherent signal
averaging"?

BTW, I think that "no jitter" might not be a good thing to shoot for.
Mother nature kinda works against you there.

Please don't take this post the wrong way.  I had a laugh seeing this go in
a circle over a dozen messages and thought I might point out that the
nomenclature simply didn't help.

What is "coherent signal averaging" anyhow?

Good luck.


--
Martin E.

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 42922
Subject: Xilinx System Generator Simulation Problems
From: Dirk =?iso-8859-1?Q?S=FCtterlin?= <DSuetterlin@KontronMedical.ch>
Date: Tue, 07 May 2002 13:15:35 +0200
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------2BF5B2A9B6C6D0AB840428EF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have following problem:
I tried to import and simulate the testbench of my Simulink model,
generated with Xilinx SysGen 2.1 under Visual HDL.
To get the simulation running properly, one has to adapt all generics
"c_mem_init_file" and "inputfile" to the absolute path manually.
Otherwise the simulator of VisualHDL cannot find the input files.
Is there a possibility to configure SysGen generating its VHDL files
with absolute path strings for these generics?

Here an component example with the above described problem:

  component sysgenmacfir_xlsprom_dist1
    generic (
-- synopsys translate_off
--      c_mem_init_file: string := "MAC_FIR_coef.mif";
      c_mem_init_file: string :=
"D:\Data\SysGenTest\sysgen\MAC_FIR_coef.mif"; -- changed to absolute
path
-- synopsys translate_on
      addr_arith: integer := xlUnsigned;
      addr_bin_pt: integer := 0;
      addr_width: integer := 2;
      c_address_width: integer := 4;
      c_depth: integer := 16;
      c_enable_rlocs: integer := 0;
      c_has_spo: integer := 0;
      c_latency: integer := 1;
      c_width: integer := 8;
      data_arith: integer := xlSigned;
      data_bin_pt: integer := 7;
      data_width: integer := 8;
      init_valid: integer := 0;
      latency: integer := 1;
      uid: integer := 0
    );
    port (
      addr: in std_logic_vector (addr_width - 1 downto 0);
      addr_valid: in std_logic;
      ce: in std_logic;
      clk: in std_logic;
      clr: in std_logic;
      data: out std_logic_vector (data_width - 1 downto 0);
      data_valid: out std_logic
    );

    -- System Generator port information
  end component;

Thanks for any response, (also directly from Xilinx)

Dirk



Article: 42923
Subject: Re: Availability of XC2S150E-6FG456I
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 07 May 2002 08:38:27 -0400
Links: << >>  << T >>  << A >>
Martin Thompson wrote:
> 
> rickman <spamgoeshere4@yahoo.com> writes:
> 
> > I am discussing a spec problem with TI on the C6711B.  Seems that they
> > spec'd the C6711 with a shorter hold time (although they lengthened it a
> > bit in the errata).  The C6711B has a 2.5 nS hold time which is 1 nS
> > longer than the SBSRAM.  But he also explained that "the device returned
> > to its standard operating voltage of 1.8V".  So they must have been
> > spec'ing it at something higher although I can't find it.
> >
> 
> Hi Rick,
> 
> I seem to recall one bit fo the errata for the C6711 (non-B) that
> said increasing the core supply to 1.9V allowed you to meet the
> datasheet timing - maybe that's what he was referring to?
> 
> Cheers,
> 
> Martin

Sometimes I don't know about TI.  I was reading in one of the newsgroups
where TI was compared to the "Intel of DSP".  I think I know what they
meant by that and it was not a complement.  I used Intel products back
in the 8080 days.  They would come out with a new chip and it would not
work right.  There was no errata and it could take hours on the phone
with them before you got someone who would acknowledge the fault in the
chip.  Mostly they did not think these were "faults", they were just
features that required workarounds.  

I guess being incompatible with standard memory products is TI's idea of
a "feature".  It did catch my eye when I noticed that TI does not
include an SBSRAM on the C6711 DSK.  More than a coincidence I think.  

-- 

Rick "rickman" Collins

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

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

Article: 42924
Subject: OP-AMP in FPGA
From: "Roger King" <roger@king.com>
Date: Tue, 07 May 2002 13:37:57 GMT
Links: << >>  << T >>  << A >>
Can one build an OP-AMP in an FPGA?





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
2019JanFebMar2019

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