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 17200

Article: 17200
Subject: Re: Programming Xilinx without Foundation
From: mel@cix...co...uk (mel)
Date: Thu, 8 Jul 1999 08:53 +0100 (BST)
Links: << >>  << T >>  << A >>
michel.lemer@ago.fr (Le mer Michel) wrote:

> > So, I'm wondering if there's an easy way to embed the jedec file and
> > programming algorithm into a DOS program. This would provide the 
> > simplest
> > possible way of programming an on-board device via the PC printer port
> > programmer.
> 
> You can just install the software part for downloading. If the 
> parameters
> are saved, they will only need to open the icon and click the run 
> button.

Yeah, I did that, but when I say that our production dept are 
pc-illiterate, I mean /seriously/ pc illiterate. However, as brianp 
pointed out there's a dos programmer, so I can set up a batch file and 
they can just type the name of it in. No more "what's an icon again?"


--

    /Mel/ (at work)
Article: 17201
Subject: IEEE1394 core
From: Jan Vermaete <jan.vermaete@alcatel.be>
Date: Thu, 08 Jul 1999 10:55:12 +0200
Links: << >>  << T >>  << A >>
I'm looking after a firewire (IEEE1394) core for a xilinx virtex and  a
speed of 400Mbps.  Xilinx only offers one with a speed of 200Mbps.
Is there someone with experience on that stuff?

Thanks

Article: 17202
Subject: Re: 100 Billion operations per sec.!
From: Tom Kean <tom@algotronix.com>
Date: Thu, 08 Jul 1999 15:34:39 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------7E5AB6FB5A578287925C9999
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Austin Franklin wrote:
> 
> > "Modern reconfigurable computing could not begin
> > untill Ross Freeman invented the FPGA." With the
> > thought that "Modren" distinguishes the current
> > type (FPGA based) of reconfigurable computers from
> > projects that came before the FPGA.
> 
> I even disagree with that.  We were doing re-configurable computing in the
> early and mid 70's with bit-slice processors, that had writeable control
> stores.  We even used the term 'reconfigurable compute engine'.
> Specifically, we were developing systems for vision processing.
> 

...and if you want to be argue even more 'FPGA' was a term that was
invented by
Actel's marketing people as far as I know.  Ross Freeman used the term
'configurable
logic array' in his patent.

But 'reconfigurable computing' is the term most people use *today* for
computing
with FPGA's even though it has other meanings as well and 'FPGA' is the
accepted
term *today* for the kind of chip that Ross Freeman invented so I think
Steve
is correct in what he says.

> The IBM 370 had a writeable control store...and, was also a
> 'reconfigurable' computer.
> 
> Using a writeable 'memory' (RAM) as generic loadable/programmable logic has
> been a standard hardware technique since I started in Engineering in the
> mid 70's.  Using ROMs as PLDs has been too.
> 

There is a difference between microprogramming and 'reconfigurable
computing as the
term is used *today*.  Xilinx FPGA's may use Look Up Tables but that is
not what
Ross Freeman claims to have invented in his patent.

As a general point lots of engineers get excited too fast with
statements like
"Mr. X has patented Y", when in fact they mean "Mr. X has a patent in
field Y".
What Mr. X has actually patented is what is stated in the claims of that
patent
and is usually a lot smaller than the whole field.  Just because Mr.
Gilson or Intel 
or whoever has a patent about reconfigurable computing does not mean to
say they own the whole field.

Tom.
--------------7E5AB6FB5A578287925C9999
Content-Type: text/x-vcard; charset=us-ascii;
 name="tom.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Tom Kean
Content-Disposition: attachment;
 filename="tom.vcf"

begin:vcard 
n:Kean;Tom
tel;fax:UK +44 131 556 9247
tel;work:UK +44 131 556 9242
x-mozilla-html:TRUE
org:Algotronix Ltd.
adr:;;P.O. Box 23116;Edinburgh;;EH8 8YB;Scotland
version:2.1
email;internet:tom@algotronix.com
title:Director
note:Web Site: www.algotronix.com
x-mozilla-cpt:;4768
fn:Tom Kean
end:vcard

--------------7E5AB6FB5A578287925C9999--

Article: 17203
Subject: Re: 100 Billion operations per sec.!
From: "Brad L. Hutchings" <hutch@ee.byu.edu>
Date: Thu, 08 Jul 1999 08:36:43 -0600
Links: << >>  << T >>  << A >>
In article <01bec8d4$d6b3c480$3bab15d1@drt4> , "Austin Franklin"
<austin@dark88room.com> wrote:

>
>> "Modern reconfigurable computing could not begin
>> untill Ross Freeman invented the FPGA." With the
>> thought that "Modren" distinguishes the current
>> type (FPGA based) of reconfigurable computers from
>> projects that came before the FPGA.
>
>I even disagree with that.  We were doing re-configurable computing in the
>early and mid 70's with bit-slice processors, that had writeable control
>stores.  We even used the term 'reconfigurable compute engine'. 
>Specifically, we were developing systems for vision processing.
>
>The IBM 370 had a writeable control store...and, was also a
>'reconfigurable' computer.
>
>Using a writeable 'memory' (RAM) as generic loadable/programmable logic has
>been a standard hardware technique since I started in Engineering in the
>mid 70's.  Using ROMs as PLDs has been too.
>

But there is something quite different about being able to
*structurally* reconfigure something as opposed to updating
a writeable control store (which does nothing to change the
structure of a system). Although bit-slice devices and
systems with writeable control stores have some interesting
properties, they are not nearly as flexible as the FPGA-based
systems we have today. I can take a single FPGA platform
and turn it into a high-performance image-processing platform,
and then use the exact same hardware to perform a completely
different task (like sonar beamforming, for example). I would
argue that systems with writeable control stores are not nearly
so flexible. *Using the same hardware*, FPGA systems allow you 
to implement a completely custom datapath and control strategy 
for each new algorithm you are interested in, something that is 
only possible today with FPGA technology. This is enabling the 
production of reusable, generic hardware. The unprecedented 
flexibility of today's FPGA systems makes them fundamentally 
different than earlier flexible systems such as those based on 
writeable control stores (for example).

Brad Hutchings
Brigham Young University


Article: 17204
Subject: CHES Conference Preliminary Program
From: Jorge Guajardo <guajardo@ece.wpi.edu>
Date: Thu, 8 Jul 1999 17:01:25 -0400
Links: << >>  << T >>  << A >>

Please find below the prelinarary program of the CHES workshop. For
registration information, please see

    http://ece.wpi.edu/Research/crypt/ches 


-------------------------------------------------------
               PRELIMINARY PROGRAM

Workshop on Cryptographic Hardware and Embedded Systems
     Worcester, Massachusetts, August 12-13, 1999
-------------------------------------------------------

           --- THURSDAY, AUGUST 12 ---

Welcome by Ed Parrish (President, WPI)

Introductory remarks by Cetin Koc and Christof Paar


Invited Talk: Brian Snow, National Security Agency, USA
              We Need Assurance


Session: CRYPTANALYTICAL HARDWARE

A. Shamir
Factoring large numbers with the TWINKLE device

I. Hamer and P. Chow
DES cracking on the Transmogrifier 2a

        --- break --- 

Session: HARDWARE ARCHITECTURES 

W.P. Choi and L.M. Cheng
Modeling the crypto-processor from design to synthesis

D.C. Wilcox, L.G. Pierson, P.J. Robertson, E.L. Witzke, and  K. Gass
A DES ASIC suitable for network encryption at 10 Gbps and beyond

E. Hong, J.-H. Chung, and C.H. Lim
Hardware design and performance estimation of the 128-bit block
cipher CRYPTON

Session: SMART CARDS AND EMBEDDED SYSTEMS

K. Itoh, M. Takenaka, N. Torii, S. Temma, and Y. Kurihara
Fast implementation of public-key cryptography on a DSP TMS320C6201

P.J. Lee, E.J. Lee, and Y.D. Kim 
How to implement cost-effective and secure public key cryptosystems

       --- lunch break ---

Invited Talk: Colin D. Walter, Computation Department - UMIST, U.K.
              An Overview of Montgomery's Multiplication Technique:
              How to make it Smaller and Faster


Session: ARITHMETIC ALGORITHMS

A.F. Tenca and C.K. Koc
A scalable architecture for Montgomery multiplication

J.H. Silverman.
Fast multiplication in finite fields GF(2^N)

B. Kaliski and M. Liskov
Efficient finite field basis conversion involving dual bases

        --- break ---

Invited Talk: Eberhard von Faber, Debis IT Security Services, Germany
              Security Evaluation Schemes for the Public and Private
              Market with a Focus on Smart Card Systems

Session: POWER ATTACKS I

T.S. Messerges, E.A. Dabbish, and R.H. Sloan 
Power analysis attacks of modular exponentiation in smartcards

L. Goubin and J. Patarin
DES and differential power analysis

P. Fahn and P. Pearson
IPA: A new class of power attacks


--- CHES Banquet on the WPI Campus, sponsored by Technical ---
---            Communications Corporation, MA              ---


         --- FRIDAY, AUGUST 13 ---

Invited Talk: Dale Hopkins, Compaq - Atalla, USA
              Design of Hardware Encryption Systems for 
              e-Commerce Applications

Session: TRUE RANDOM GENERATORS

V. Bagini and M. Bucci
A design of reliable true random number generator for 
cryptographic applications

D. Maher and B. Rance
Random number generators founded on signal and information theory

       --- break ---

Session: CRYPTOGRAPHIC ALGORITHMS ON FPGAS

R.R. Taylor and S.C. Goldstein
A high-performance flexible architecture for cryptography

E. Mosanya, C. Teuscher, H.F. Restrepo, P. Galley, and E. Sanchez
CryptoBooster: A reconfigurable and modular cryptographic coprocessor

L. Gao, S. Shrivastava, and G.E. Sobelman
Elliptic curve scalar multiplier design using FPGAs


Session: GALOIS FIELD ARCHITECTURES

H. Wu, M.A. Hasan, and I.F. Blake.
Highly regular architectures for finite field computation using
redundant basis

H. Wu
Low complexity bit-parallel finite field arithmetic using polynomial
basis

       --- lunch break --- 

Invited Talk: David Naccache, Gemplus, France
Significance Tests and Hardware Leakage


Session: POWER ATTACKS II

J.-S. Coron
Resistance against differential power analysis attacks for 
elliptic curve cryptosystems

H. Handschuh, P. Paillier, and J. Stern
Probing attacks on tamper-resistant devices

       --- break --- 

Session: ELLIPTIC CURVE IMPLEMENTATIONS

J. Lopez and R. Dahab
Fast multiplication on elliptic curves over GF(2^m) without
precomputation

Y. Han, J. Zhang, and P.-C. Tan
Direct computation for elliptic curve cryptosystems


Session: NEW CRYPTOGRAPHIC SCHEMES AND MODES OF OPERATION

M. Hartmann, S. Paulus, and T. Takagi
NICE - New Ideal Coset Encryption -

T. Horvath
Arithmetic design for permutation groups

O. Jung and C. Ruland
Encryption with statistical self-synchronization in synchronous 
broadband networks

-----------------------------------------------------------
Invited talks are 40 min, regular presentations 20 min long

The Thursday program is from 9:00 am - 6:00 pm,
the Friday program is from   8:30 am - 4:30 pm

--------------------------------------------------------
Workshop on Cryptographic Hardware and Embedded Systems
     Worcester, Massachusetts, August 12-13, 1999
-------------------------------------------------------
Information:    http://ece.wpi.edu/Research/crypt/ches
E-Mail:         ches@ece.orst.edu
Program Chairs: Cetin Kaya Koc   & Christof Paar
                koc@ece.orst.edu & christof@ece.wpi.edu
-------------------------------------------------------






Article: 17205
Subject: fpga 10k50 and up prototype with a/d d/a
From: "Abraham Roth" <s3279466@techst02.technion.ac.il>
Date: Thu, 8 Jul 1999 23:52:14 +0200
Links: << >>  << T >>  << A >>
Hi
I am looking for a prototype board with altera 10k50 and up,
some memory, and  4 analog in (12b a/d 150 khz each) 2 analog out(12 b
d/a),
some interfacing vhdl/ahdl drivers.
download with at least byteblaster.




Article: 17206
Subject: Re: Benchmark circuits - in VHDL for FPGA
From: "Wade D. Peterson" <peter299@maroon.tc.umn.edu>
Date: Thu, 8 Jul 1999 17:40:54 -0500
Links: << >>  << T >>  << A >>
<csoolan@dso.org.sg> wrote in message news:3781BA2A.74B1@dso.org.sg...
> Hello,
>
> Does anyone have recommendations to find benchmark circuits for
> FPGA - preferrably in VHDL ?
>
> Thanks in advance.
>
> email:  csoolan@dso.org.sg

I've been thinking about this for sometime myself.  Gate counts and speed are
two areas where it's hard to get *OBJECTIVE* data on FPGA devices.

The problem with benchmarks is that most circuits seem to specialize in certain
types of logic (gates, multiplexors, three-state buses, RAM, etc.).  No matter
what you use, somebody will complain that it doesn't represent what they're
trying to benchmark.  The same thing happens with computer benchmarks.

I was talking to guy from the Bank of Boston about this at the DAC conference in
New Orleans this month.  They are also confused about FPGA gate counts and
speed.  We've got an 8-bit RISC processor (VHDL IP Core) that will run on most
of the popular FPGA parts, and it occurs to me that would be an excellent
benchmark circuit because it has a large variety of circuits inside of it (RAM,
ROM, multiplexors, random logic, ALU, etc.).  I suggested that the Bank of
Boston develop a benchmark to compare FPGA gate counts and speeds, and offered
him a core license to do that.

It occurs to me that the same approach would work to benchmark VHDL synthesis
tools too.

--
Wade D. Peterson
Silicore Corporation
3525 E. 27th St. No. 301, Minneapolis, MN USA 55406
TEL: (612) 722-3815, FAX: (612) 722-5841
URL: http://www.silicore.net/  E-MAIL: peter299@maroon.tc.umn.edu



Article: 17207
Subject: Re: PCI interface
From: Jim McManus <jim.mcmanus@xilinx.com>
Date: Thu, 08 Jul 1999 23:15:44 -0700
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> The PLX has the best DMA (burst master) system of the three.  If you use
> the Xilinx core, you will have to develop your own burst master, which is a
> difficult task at best.  The old AMCC chips were dogs, and I haven't tried
> any of the new ones.

Xilinx supplies with the LogiCORE PCI design a reference synthesizable
bridge design that simplifies this task. The synthesizable bridge design
gives you an example of how to do a DMA with R/W FIFOs, doorbells,
mailboxes, target transaction ordering, etc.

> Be careful with the latest PLX chip though (9054) if you need to use 5V
> PCI.  It does not provide any VCCIO pins, and that is in direct violation
> with the PCI spec, especially since it is a 3.3V chip, used in a 5V PCI
> system.  If your PCI voltage is the same as the voltage of the chip, that
> is fine.
> 
> Technically, the Xilinx part doesn't meet PCI VCCIO spec either....but at
> least you can choose a technology part (3.3 or 5V) that meets your
> application.

Technically we do. Allow me to explain.

The problem that is plaguing some universal PCI devices is the
requirement for upper clamp diodes in the 3.3 V environment. If these
clamps are missing, the device may not be compliant in a 3.3 V
environment. If they are tied permanently to the 3.3 V rail, then they
lose 5 V tolerance. In traditional ASIC thinking, since the devices
aren't configurable, the solution is to bondout the upper clamp diode
and the system designer then ties this to Vio. If Vio is at 5 V, the 5 V
overshoot (as much as 11 V for 11 ns!) is clamped to something less than
what would damage the device. If Vio is 3.3 V, the clamps for signal
integrity are there as required by the spec. And the drive strength of
the I/O buffer would be derived from this "Vccio". WIth FPGAs, we do
thing differently, but still achieve compliance. 

From the PCI V2.2 Spec, page 114:
> While the primary goal of the PCI 5V to 3.3V transition strategy is 
> to spare vendors the burden and expense of implementing 3.3V parts 
> that are "5V tolerant," such parts are not excluded. If a PCI 
> component of this type is used on the Universal board, its I/O buffers 
> may optionally be connected to the 3.3V rail rather than the "I/O" 
> designated power pins; but high clamp diodes must still be connected 
> to the "I/O" designated power pins. (Refer to the last paragraph of 
> Section 4.2.1.2. - "Clamping directly to the 3.3V rail with a simple 
> diode must never be used in the 5V signaling environment.") Since the 
> effective operation of these high clamp diodes may be critical to both 
> signal quality and device reliability, the designer must provide enough 
> extra "I/O" designated power pins on a component to handle the current 
> spikes associated with the 5V maximum AC waveforms (Section 4.2.1.3.).

Several things to note here:
1. 3.3 V devices that are 5 V tolerant are allowed. This would include
Xilinx FPGAs that supply 3.3 V to the I/O cells. The Xilinx XLA,
SpartanXL, and Virtex families fall into this category. 
2. Connecting the I/O cell to the 3.3 V rail is allowed. 
3. The upper (high) clamp diode has to be tied to the I/O power. Xilinx
handles this through a bitstream configuration; either the upper diode
is tied to the 3.3 V rail, or it's floating. Since not using the upper
clamps is allowed in a 5 V environment, this meets the PCI spec. We
don't lose 5 V tolerance because the diode can be disconnected.   
4. The overshoot for 5 V PCI has to be handled so that the device is not
damaged. In 3.3 V devices, the thinner oxide layers can't withstand the
11 V overshoot. We handle this by a zener diode in the I/O structure
that clamps the voltage to an acceptable level. 

So the real question here is how would one handle, in a compliant
manner, the requirements for a universal PCI card with an FPGA? To do a
universal PCI card, Xilinx requires loading of a different bitstream
depending on the bus signaling level. 

When plugged into a 5 V PCI bus, a 5 V bitstream must be loaded. This
will have the clamps disconnected and the 5 V drive strength enabled.
This is fully 5 V PCI compliant. 

Likewise, when plugged into a 3.3 V PCI bus, a 3.3 V bitstream must be
loaded. This will have the clamps enabled and the 3.3 V drive strength
enabled. This is fully 3.3 V PCI compliant. 

While this is not a universal card in the usual sense of the term, it is
completely compliant in either environment. The user does have the
responsibility of insuring that his design loads appropriate bitstream.
This is done by monitoring the PCI bus Vio pin with a comparator and
some external logic. This could be as simple as using the comparator to
drive an address line on a parallel PROM. 

And while we're discussing universal PCI cards, here is something to be
aware of. As we go to smaller device geometries, specifically 0.18u, 5 V
PCI tolerance will start to disappear. Since FPGAs tend to be produced
for upwards of ten years and standard chips only 2-4 years, shortly the
only way to do a 5 V or universal PCI card may be an FPGA (at 0.22u or
larger). If you are planning on extended production of your 5 V or
universal PCI card, this should be considered.


Jim McManus
Xilinx PCI Applications Engineer
Article: 17208
Subject: Re: Altera 10K prices
From: "Karim LIMAM" <klimam@ensem.u-nancy.fr>
Date: Fri, 9 Jul 1999 09:10:38 +0200
Links: << >>  << T >>  << A >>
Hi,

10  x 10K40
10  x  10K50E
10  x  10K130E

with almost 240 pin

The country is France

Thanks for the time.


                                                    kerim el imem.



lewis chen <lewis@galaxyfareast.com.tw> a écrit dans le message :
7lqj53$ro6@netnews.hinet.net...
> How many quantity for your order and which your country
>                         Lewis
> Karim LIMAM ¼¶¼g©ó¤å³¹ <7lfnhf$oa1$1@arcturus.ciril.fr>...
> >Hi,
> >
> >I'm looking for the prices of the Altera Flex 10K (10K40 .. 10K130E). Has
> >somebody an idea ?
> >
> >Thanks.
> >
> >
> >kerim el imem
> >
> >
>
>


Article: 17209
Subject: how to choose only a set of pins
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Fri, 09 Jul 1999 13:50:12 +0300
Links: << >>  << T >>  << A >>
Target is XC41050XV and has dedicated pins. Some new pins can
be added, and we want the program to choose the free pads we want,
not all the unused (free) pads. Is this possible in Design Manager?

Utku
Article: 17210
Subject: Re: Benchmark circuits - in VHDL for FPGA
From: "Alasdair MacLean" <alasdair.maclean@gecm.com>
Date: Fri, 9 Jul 1999 12:56:12 +0100
Links: << >>  << T >>  << A >>

Wade D. Peterson wrote in message <7m39ct$e0i$1@news1.tc.umn.edu>...
><csoolan@dso.org.sg> wrote in message news:3781BA2A.74B1@dso.org.sg...
>> Hello,
>>
>> Does anyone have recommendations to find benchmark circuits for
>> FPGA - preferably in VHDL ?
>>
>> Thanks in advance.
>>
>> email:  csoolan@dso.org.sg
>
>I've been thinking about this for sometime myself.  Gate counts and speed
are
>two areas where it's hard to get *OBJECTIVE* data on FPGA devices.
>

snip...


>
>--
>Wade D. Peterson
>Silicore Corporation
>3525 E. 27th St. No. 301, Minneapolis, MN USA 55406
>TEL: (612) 722-3815, FAX: (612) 722-5841
>URL: http://www.silicore.net/  E-MAIL: peter299@maroon.tc.umn.edu
>
>
>

There used to be an organisation by the name of PREP (PRogrammable
Electronics Performance Corporation) who published a set of benchmark
circuits for FPGAs in VHDL on their web pages at http://www.prep.org/ ,
however the company and the web page both now appear to be defunct.
Other contributors to the newsgroup will be able to fill in the details, but
I believe a combination of vendors trying to bend the rules to suit their
own marketing claims, combined with a lack of general acceptance eventually
lead to PREP's failure.
If you're interested, I have some of the benchmark circuits but if you want
details on how the tests were performed, try to get hold of a copy of
Actel's 1995 Data Book - it has a chapter devoted to the subject.

            -- Alasdair

Alasdair MacLean, Senior Development Engineer,
Marconi Electronic Systems, Electro Optic Systems Division,
4 Ferry Road, Silverknowes, Edinburgh EH4 4AD
Telephone: 0131-343-5711, GNET: 709 5711
email: alasdair.maclean@gecm.com





Article: 17211
Subject: Re: how to choose only a set of pins
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Fri, 9 Jul 1999 10:05:30 -0400
Links: << >>  << T >>  << A >>
Using constraints, you can tell M1 to assign a set of signals to a set of
pins. This is especially simple when the signals have a common prefix. For
example, I once used the following constraint to assign all signals for an
external memory interface to a set of pins.

NET mem* LOC =
Y19, W18, V17, U16, Y18, W17, V16, Y17, W16, V15,
Y16, W15, V14, Y15, Y14, V13, U12, V12, W12, Y12,
U11, V11, W11, Y11, Y10, V10, W10, Y9, U9, Y8,
W8, V8, Y7, W7, Y6, W6, V6, Y5 ;

This would go into your ".ucf", or user constraints file. If your signals
don't have the same prefix, you simply repeat the preceding command for each
of the signals.

Regards,
Jamie

Utku Ozcan wrote in message <3785D3E4.44731ACD@netas.com.tr>...
>Target is XC41050XV and has dedicated pins. Some new pins can
>be added, and we want the program to choose the free pads we want,
>not all the unused (free) pads. Is this possible in Design Manager?
>
>Utku


Article: 17212
Subject: Re: how to get money surfing the net...
From: Lasse Langwadt Christensen <fuz@kom.auc.dk>
Date: Fri, 09 Jul 1999 14:08:52 GMT
Links: << >>  << T >>  << A >>
"Semenov V.N." wrote:
> 
> Hi, All!
> 
> Today, I signed up for a membership at what
> appears to be one of the most amazing sites on the Net.
> It's basically a
> vast consumer community service, which will soon be offering its members
> substantial discounts on consumer merchandise as well as other various
> community services (like forums, on-line shopping malls and a targeted
> internet consumer index). They seem to be pretty serious!
snip
> 
> With best wishes, Mike.

Mike, please read the rules 
...
2. You will not use any method which could be viewed as 'SPAM' 
(unsolicited postings or e-mails) to refer people to TargetShop.
 Spamming is strictly prohibited by TargetShop, and you understand 
you may be subject to fines and/or imprisonment for disobeying laws 
or rules of certain network providers or jurisdictions regarding the
 use of  'SPAM' messages. The only acceptable methods of referring 
someone to Targetshop are sending e-mail to a friend, or posting a 
link to our main page (www.targetshop.com) on your own website. You 
will immediately lose your subscription to TargetShop, as well as 
any referral bonus you may have earned if this rule is disobeyed.
                    
 
--L2C                 
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE 
Aalborg University, Department of communication tech.    
Applied Signal Processing and Implementation (ASPI)      
http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org
Article: 17213
Subject: Re: how to choose only a set of pins
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Fri, 09 Jul 1999 18:07:56 +0300
Links: << >>  << T >>  << A >>
Jamie Sanderson wrote:
> 
> Using constraints, you can tell M1 to assign a set of signals to a set of
> pins. This is especially simple when the signals have a common prefix. For
> example, I once used the following constraint to assign all signals for an
> external memory interface to a set of pins.
> 
> NET mem* LOC =
> Y19, W18, V17, U16, Y18, W17, V16, Y17, W16, V15,
> Y16, W15, V14, Y15, Y14, V13, U12, V12, W12, Y12,
> U11, V11, W11, Y11, Y10, V10, W10, Y9, U9, Y8,
> W8, V8, Y7, W7, Y6, W6, V6, Y5 ;
> 
> This would go into your ".ucf", or user constraints file. If your signals
> don't have the same prefix, you simply repeat the preceding command for each
> of the signals.
> 
> Regards,
> Jamie

  I stated my problem inadequately. I have a design, it already has
  dedicated pins. Now when I add 4 pins, for example, normally,
  Design Manager will choose ANY of the unused pins. But I want to
  restrict the choose range of the Design Manager, for example, when
  I add a new pin, I want the Design Manager to choose not ANY of the
  unused pins but one among AA25, AA23, Y4, A26. Is this applicable?

-- 
I feel better than James Brown.
Article: 17214
Subject: Re: how to choose only a set of pins
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Fri, 09 Jul 1999 12:28:44 -0400
Links: << >>  << T >>  << A >>
Utku Ozcan wrote:
> 
>   I stated my problem inadequately. I have a design, it already has
>   dedicated pins. Now when I add 4 pins, for example, normally,
>   Design Manager will choose ANY of the unused pins. But I want to
>   restrict the choose range of the Design Manager, for example, when
>   I add a new pin, I want the Design Manager to choose not ANY of the
>   unused pins but one among AA25, AA23, Y4, A26. Is this applicable?
> 

Why not just choose them yourself? It probably won't make a bit of
difference in your routability.
-- 
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>
Article: 17215
Subject: Re: how to choose only a set of pins
From: Brian Philofsky <brianp@xilinx.com>
Date: Fri, 09 Jul 1999 10:18:00 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------4BA9E6687849D3D5C213C8C9
Content-Type: multipart/alternative;
 boundary="------------C56277CD46AE9EB76D74D356"


--------------C56277CD46AE9EB76D74D356
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Unless I am mis-understanding what you are asking, Jamie explanation is
essentially correct but I will try it a different way.

You say you have added 4 new ports which you want to constrain to four specific
pads but you don't care which one of the four pads the new port lands on.  This
can be done with one LOC constraint as Jamie pointed out if they have a common
name that can be wild-carded but if not, it can be done in four LOC constarints
within your UCF file as follows:

NET port_1_name LOC = AA25, AA23, Y4, A26 ;
NET port_2_name LOC = AA25, AA23, Y4, A26 ;
NET port_3_name LOC = AA25, AA23, Y4, A26 ;
NET port_4_name LOC = AA25, AA23, Y4, A26 ;

You can overlap the port definitions as I have done so above as long as there is
enough pads to go around to each port.

If this sounds like what you are looking for, try it out.  If this is not what
you want to do or you have any other questions about Xilinx constraints, I
suggest you look at the Timing and Contraints Journal on our website at
http://support.xilinx.com/support/techsup/journals/timing/index.htm .  It has
concise information on ways to constrain your design.  I also suggest looking
through the docs (i.e. Libraries Guide) if you would like more detailed
inormation on the constraint language.

Good Luck,

--  Brian




Utku Ozcan wrote:

> Jamie Sanderson wrote:
> >
> > Using constraints, you can tell M1 to assign a set of signals to a set of
> > pins. This is especially simple when the signals have a common prefix. For
> > example, I once used the following constraint to assign all signals for an
> > external memory interface to a set of pins.
> >
> > NET mem* LOC =
> > Y19, W18, V17, U16, Y18, W17, V16, Y17, W16, V15,
> > Y16, W15, V14, Y15, Y14, V13, U12, V12, W12, Y12,
> > U11, V11, W11, Y11, Y10, V10, W10, Y9, U9, Y8,
> > W8, V8, Y7, W7, Y6, W6, V6, Y5 ;
> >
> > This would go into your ".ucf", or user constraints file. If your signals
> > don't have the same prefix, you simply repeat the preceding command for each
> > of the signals.
> >
> > Regards,
> > Jamie
>
>   I stated my problem inadequately. I have a design, it already has
>   dedicated pins. Now when I add 4 pins, for example, normally,
>   Design Manager will choose ANY of the unused pins. But I want to
>   restrict the choose range of the Design Manager, for example, when
>   I add a new pin, I want the Design Manager to choose not ANY of the
>   unused pins but one among AA25, AA23, Y4, A26. Is this applicable?
>
> --
> I feel better than James Brown.

--
-------------------------------------------------------------------
 / 7\'7 Brian Philofsky   (brian.philofsky@xilinx.com)
 \ \ `  Xilinx Applications Engineer             hotline@xilinx.com
 / /    2100 Logic Drive                         1-800-255-7778
 \_\/.\ San Jose, California 95124-3450          1-408-879-5199
-------------------------------------------------------------------



--------------C56277CD46AE9EB76D74D356
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Unless I am mis-understanding what you are asking, Jamie explanation
is essentially correct but I will try it a different way.
<p>You say you have added 4 new ports which you want to constrain to four
specific pads but you don't care which one of the four pads the new port
lands on.&nbsp; This can be done with one LOC constraint as Jamie pointed
out if they have a common name that can be wild-carded but if not, it can
be done in four LOC constarints within your UCF file as follows:
<p>NET port_1_name LOC = AA25, AA23, Y4, A26 ;
<br>NET port_2_name LOC = AA25, AA23, Y4, A26 ;
<br>NET port_3_name LOC = AA25, AA23, Y4, A26 ;
<br>NET port_4_name LOC = AA25, AA23, Y4, A26 ;
<p>You can overlap the port definitions as I have done so above as long
as there is enough pads to go around to each port.
<p>If this sounds like what you are looking for, try it out.&nbsp; If this
is not what you want to do or you have any other questions about Xilinx
constraints, I suggest you look at the Timing and Contraints Journal on
our website at <A HREF="http://support.xilinx.com/support/techsup/journals/timing/index.htm">http://support.xilinx.com/support/techsup/journals/timing/index.htm</A>
.&nbsp; It has concise information on ways to constrain your design.&nbsp;
I also suggest looking through the docs (i.e. Libraries Guide) if you would
like more detailed inormation on the constraint language.
<p>Good Luck,
<p>--&nbsp; Brian
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>Utku Ozcan wrote:
<blockquote TYPE=CITE>Jamie Sanderson wrote:
<br>>
<br>> Using constraints, you can tell M1 to assign a set of signals to
a set of
<br>> pins. This is especially simple when the signals have a common prefix.
For
<br>> example, I once used the following constraint to assign all signals
for an
<br>> external memory interface to a set of pins.
<br>>
<br>> NET mem* LOC =
<br>> Y19, W18, V17, U16, Y18, W17, V16, Y17, W16, V15,
<br>> Y16, W15, V14, Y15, Y14, V13, U12, V12, W12, Y12,
<br>> U11, V11, W11, Y11, Y10, V10, W10, Y9, U9, Y8,
<br>> W8, V8, Y7, W7, Y6, W6, V6, Y5 ;
<br>>
<br>> This would go into your ".ucf", or user constraints file. If your
signals
<br>> don't have the same prefix, you simply repeat the preceding command
for each
<br>> of the signals.
<br>>
<br>> Regards,
<br>> Jamie
<p>&nbsp; I stated my problem inadequately. I have a design, it already
has
<br>&nbsp; dedicated pins. Now when I add 4 pins, for example, normally,
<br>&nbsp; Design Manager will choose ANY of the unused pins. But I want
to
<br>&nbsp; restrict the choose range of the Design Manager, for example,
when
<br>&nbsp; I add a new pin, I want the Design Manager to choose not ANY
of the
<br>&nbsp; unused pins but one among AA25, AA23, Y4, A26. Is this applicable?
<p>--
<br>I feel better than James Brown.</blockquote>

<pre>--&nbsp;
-------------------------------------------------------------------
&nbsp;/ 7\'7 Brian Philofsky&nbsp;&nbsp; (brian.philofsky@xilinx.com)
&nbsp;\ \ `&nbsp; Xilinx Applications Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hotline@xilinx.com
&nbsp;/ /&nbsp;&nbsp;&nbsp; 2100 Logic Drive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1-800-255-7778&nbsp;
&nbsp;\_\/.\ San Jose, California 95124-3450&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1-408-879-5199&nbsp;
-------------------------------------------------------------------</pre>
&nbsp;</html>

--------------C56277CD46AE9EB76D74D356--

--------------4BA9E6687849D3D5C213C8C9
Content-Type: text/x-vcard; charset=us-ascii;
 name="brianp.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brian Philofsky
Content-Disposition: attachment;
 filename="brianp.vcf"

begin:vcard 
n:Philofsky;Brian
tel;fax:(408) 879-4442
tel;work:1-800-255-7778
x-mozilla-html:TRUE
org:<BR><H1 ALIGN="CENTER"><img src="http://www.xilinx.com/images/xlogoc.gif" alt="Xilinx" ALIGN="CENTER">  Design Center
version:2.1
email;internet:brianp@xilinx.com
title:<H3 ALIGN="CENTER"><img src="http://bennyhills.fortunecity.com/deadparrot/108/homer.gif" alt="Homer" align="center"> Application Engineer 
adr;quoted-printable:;;2100 Logic Drive=0D=0ADept. 2510;San Jose;CA;95124-3450;USA
x-mozilla-cpt:;15200
fn:<H3 ALIGN="CENTER">Brian Philofsky
end:vcard

--------------4BA9E6687849D3D5C213C8C9--

Article: 17216
Subject: Re: PCI interface
From: "Austin Franklin" <austin@dark88room.com>
Date: 9 Jul 1999 17:52:55 GMT
Links: << >>  << T >>  << A >>
....sorry if this ends up being posted twice.  My regular ISP has bad news
service, so I tried posting it though DejaNews...which is convoluted at
best...and it hasn't shown up yet...

> > Technically, the Xilinx part doesn't meet PCI VCCIO spec either....but
at
> > least you can choose a technology part (3.3 or 5V) that meets your
> > application.
> 
> Technically we do. Allow me to explain.

This is from PCI-Spec 2.2:

“While there are multible buffer implementations that can achieve this dual
environment compliance, it  is intended that they be dual voltage buffers;
i.e., capable of operating from either power rail. They should be powered
from “I/O” designated power pins on PCI connectors that will always be
connected to the power rail associated with the signaling environment in
use.”

I'm not saying it wouldn't work just fine, but technically, according to
this quote from the PCI spec, if you don't provide clamp diodes (under any
voltage) and I/O designated power pins, I believe that would not meet this
part of the spec.

Austin
Article: 17217
Subject: Re: how to choose only a set of pins
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Fri, 09 Jul 1999 21:11:53 +0300
Links: << >>  << T >>  << A >>
Brian Boorman wrote:
> 
> Utku Ozcan wrote:
> >
> >   I stated my problem inadequately. I have a design, it already has
> >   dedicated pins. Now when I add 4 pins, for example, normally,
> >   Design Manager will choose ANY of the unused pins. But I want to
> >   restrict the choose range of the Design Manager, for example, when
> >   I add a new pin, I want the Design Manager to choose not ANY of the
> >   unused pins but one among AA25, AA23, Y4, A26. Is this applicable?
> >
> 
> Why not just choose them yourself? It probably won't make a bit of
> difference in your routability.

  Pardon me for the misunderstanding. Thank you very much for the helpful
  answers.

  I had to pass test pins to board designers for the chip, but our P&R
  results missed the deadline. Therefore I had to pass some arbitrary
  unused pins. Now I have to choose them but not other pins.

  Utku
Article: 17218
Subject: Re: FW: Xilinx Acquisition of CoolRunners
From: z80@ds2.com (Peter)
Date: Fri, 09 Jul 1999 23:00:40 GMT
Links: << >>  << T >>  << A >>

> Does anyone have a number for the Sales of Coolrunner - one press
>release
>mentioned $10M - sounded low ?

Given that Philips Component Marketing could not sell a Mars Bar to a
starving man, this might not be far off.

I reckon Xilinx bought it because they could see competition coming up
- the Philips PLDs are extremely low power.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.
Article: 17219
Subject: Designers wanted
From: "Margaret Dailey" <margaret@cyberhighway.net>
Date: Fri, 9 Jul 1999 17:42:53 -0700
Links: << >>  << T >>  << A >>
The Portland, Oregon office of Oxford and Associates is helping a local
client search for an FPGA designer with experience using Altera.  Experience
working with telephony applications is highly desirable.  The work is to be
done at the client's site.  It's a 6+ month contract, with 40 hours a week
plus overtime.

Please respond to margaret@cyberhighway.net.  Principals only, please.


Article: 17220
Subject: MayanSports Sportsbook offers NASCAR & Golf betting
From: johnsimpson@postmaster.co.uk
Date: Sat, 10 Jul 1999 02:13:21 GMT
Links: << >>  << T >>  << A >>
alt.binaries.pictures.drag-racing
alt.games.microsoft.cart-racing
alt.sport.adv-racing
alt.sport.adventure-racing
alt.sport.dragracing
alt.sport.horse-racing
alt.sport.horse-racing.systems
hk.rec.horse-racing
msen.reuters.racing-results
rec.autos.sport.nascar
rec.gambling.racing
.oval-racing
uk.sport.horseracing


Article: 17221
Subject: IEEE P1532
From: "Alvin E. Toda" <aet@lava.net>
Date: Fri, 9 Jul 1999 18:27:52 -1000
Links: << >>  << T >>  << A >>
Hi all. I just heard of a new standard for 1149.1-based 
in-system programming of programmable devices. And I was 
wondering why I hadn't noticed any discussion of this
lately? Perhaps few parts use the TAP port for programming??

--al toda

###########################################################
Alvin E. Toda              aet@lava.net
sr. engineer               Phone: 1-808-455-1331
2-Sigma          WEB: http://www.lava.net/~aet/2-sigma.html
1363-A Hoowali St.
Pearl City, Hawaii, USA

Article: 17222
Subject: Re: PCI interface
From: Jim McManus <jim.mcmanus@xilinx.com>
Date: Sat, 10 Jul 1999 00:15:24 -0700
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> > > Technically, the Xilinx part doesn't meet PCI VCCIO spec either....but
> at
> > > least you can choose a technology part (3.3 or 5V) that meets your
> > > application.
> >
> > Technically we do. Allow me to explain.
> 
> This is from PCI-Spec 2.2:
> 
> “While there are multible buffer implementations that can achieve this dual
> environment compliance, it  is intended that they be dual voltage buffers;
> i.e., capable of operating from either power rail. They should be powered
> from “I/O” designated power pins on PCI connectors that will always be
> connected to the power rail associated with the signaling environment in
> use.”
> 
> I'm not saying it wouldn't work just fine, but technically, according to
> this quote from the PCI spec, if you don't provide clamp diodes (under any
> voltage) and I/O designated power pins, I believe that would not meet this
> part of the spec.

Allow me to further elaborate on this subject. My PCI spec quotation
from yesterday was the footnote to this section you just mentioned. But
let's dig a little deeper into this: 

From the V2.2 PCI Spec, page 120 (5 V signaling):
"Inputs are required to be clamped to ground. Clamps to the 5V rail are
optional, but may be needed to protect 3.3V input devices."

We don't need this upper clamp to protect our newer 3.3 V devices; the
zener diode handles the protection aspect in XLA, SpartanXL, and Virtex
families. We did need additional protection in older XL family since it
lacked the zener diode. Xilinx's solution for this was the XLT family,
which was an XL device with these upper clamps bonded out directly. The
key issue here is to protect the device from the high overshoots seen on
the unterminated 5 V PCI bus. We do this in every 3.3 V (and 2.5 V)
family we support with PCI. 

Since upper clamps are optional, we can be compliant to the 5 V PCI spec
without them. The complaint lodged against some of the PCI devices was
the lack of a clamp diode in a 3.3 V environment, not the lack of a
clamp in a 5 V environment. Remember the upper clamps serve a different
purpose depending on the environment:

5 V - device protection
3.3 V - signal integrity

Keep in mind that we are not a universal PCI device as most people think
of universal PCI devices; we are either a 5 V PCI device or a 3.3 V PCI
device, but not both at the same time. We will never need to be both at
the same time, since we can only be plugged into one bus at a time. We
are fully 5 V compliant when a 5 V bitstream is loaded and we are
plugged into a 5 V PCI bus, and we are a fully compliant 3.3 V PCI
device when a 3.3 V bitstream is loaded and we are plugged into a 3.3 V
bus. As I mentioned, the user is responsible for loading the appropriate
bitstream. If he does not do this (e.g. loads a 3.3 V bitstream while
plugged into a 5 V PCI) then it will fall out of compliance. 

If the user does this as recommended, his board will be
indistinguishable from a board that has a device that can be both 3.3 V
and 5 V at the same time. If looked at from this point of view, the
board really is universal, and will pass any tests that a universal
device can pass. The signaling environment will never change on the fly;
the card must be removed from the bus and plugged into another bus to
change the environment. The card will always have the chance to load the
correct bitstream. 


Jim McManus
Xilinx PCI Applications Engineer
Article: 17223
Subject: FPGA Eng(s) interested in an excellent opportunity
From: mjd@nesnet.com (Mike DeLaney)
Date: Sun, 11 Jul 1999 18:38:24 -0500
Links: << >>  << T >>  << A >>
Interested in enhancing your career or just curious to what the market
could offer. CAll me....800.248.7020  x260 

SEEKING: Jr & Sr. FPGA/Digital Design Engineers   
   
REF #: FPGA-610-99            **  Candidates MUST reside in the US  or CN **

LOCATION: MA/TX/VA/MD/IL, other areas available too...call me to find out more.
OTHER opportunities available...permanent hire positions.

REQUIREMENTS:   Design/develop products for a cutting edge product;
communitions  and computer.  Extensive design exp in SCSI & RISC
microprocessors, board level design, programmable logic design including
FPGAs, PLDs, ASIC and analog design. Hands-on system architecture, board
and chip level hardware design necessary.  5+ yrs exp.    GREAT benefits +
salary + Sign-on  
___________________________________________________________

Call:      Mike DeLaney   
        800-248-7020  x260      
      Fax 800-838-8789 ATTN: Mike
      
  Email: mdelaney@servtech.com

     National Engineering Search   
        http://www.nesnet.com    

    "Engineers placing Engineers"
____________________________________________________________
See what your skills are worth...CALL for a FREE salary survey.
____________________________________________________________

National Engineering Search (http://www.nesnet.com) is a technical
recruiting firm, staffed with degreed engineers, dedicated exclusively to
placing Engineers nationwide.  If this position doesn't fit your
requirements, call me with your specific search criteria.
 
€ NES can identify  SELECT  engineering opportunities based on your
background, interests, and geographic requirements.  

€ What makes us better...We are Engineers placing Engineers.
Article: 17224
Subject: Re: how to choose only a set of pins
From: Le mer Michel <michel.lemer@ago.fr>
Date: Mon, 12 Jul 1999 10:26:19 +0200
Links: << >>  << T >>  << A >>
Utku Ozcan wrote:

> Target is XC41050XV and has dedicated pins. Some new pins can
> be added, and we want the program to choose the free pads we want,
> not all the unused (free) pads. Is this possible in Design Manager?
>
> Utku

Hello

To prohibit IO pin, you can use this exemple :
To prohibit pin P26:
CONFIG PROHIBIT = P26


Hope this helps,

Michel Le Mer
Gerpi sa (Xilinx Xpert)
3, rue du Bosphore
Alma city
35000 Rennes (France)
(02 99 51 17 18)
http://www.xilinx.com/company/consultants/partdatabase/europedatabase/gerpi.htm



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