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 27975

Article: 27975
Subject: Re: dual port ram for altera
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 18 Dec 2000 09:08:09 -0800
Links: << >>  << T >>  << A >>

--------------E6B47E90B30980877899DDDE
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit



bobdittmar@my-deja.com wrote:

>
> Be aware that Xilinx does not offer "true" dual port. They offer
> bi-directional dual port. You still must arbitrate conflict access
> to same addresses.
>
>

Well, how far can we drive the definition of "true dual port RAM".
Bob Dittmar thinks it should include an arbiter that resolves the
case when both ports access the same location "kind of
simultaneously".
That sort of arbitration should be left to the user to define and
implement, because a dedicated "fix" would interfere with the normal
operation of the RAM.

Virtex BlockRAM has two totally independent ports accessing a common
storage array.
Both might access the same location.
If one writes and the other one reads, it depends on the relative
clock timing whether the reader gets the old or the new data. Note
that read is a synchronous, clocked operation. Each port has its own
clock.
If both ports write, the one with the later clock wins. Definitely no
damage.
This operation is clear and unambiguous. Solving the contention in
dedicated hardware would not be in the user's best interest.

Peter Alfke, Xilinx Applications




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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>bobdittmar@my-deja.com wrote:
<blockquote TYPE=CITE>&nbsp;
<br>Be aware that Xilinx does not offer "true" dual port. They offer
<br>bi-directional dual port. You still must arbitrate conflict access
<br>to same addresses.
<br>&nbsp;
<br><a href="http://www.deja.com/"></a>&nbsp;</blockquote>
Well, how far can we drive the definition of "true dual port RAM".
<br>Bob Dittmar thinks it should include an arbiter that resolves the case
when both ports access the same location "kind of simultaneously".
<br>That sort of arbitration should be left to the user to define and implement,
because a dedicated "fix" would interfere with the normal operation of
the RAM.
<p>Virtex BlockRAM has two totally independent ports accessing a common
storage array.
<br>Both might access the same location.
<br>If one writes and the other one reads, it depends on the relative clock
timing whether the reader gets the old or the new data. Note that read
is a synchronous, clocked operation. Each port has its own clock.
<br>If both ports write, the one with the later clock wins. Definitely
no damage.
<br>This operation is clear and unambiguous. Solving the contention in
dedicated hardware would not be in the user's best interest.
<p>Peter Alfke, Xilinx Applications
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;</html>

--------------E6B47E90B30980877899DDDE--


Article: 27976
Subject: Re: JTAG protocol
From: "Alain Cloet" <nospam@tijd.com>
Date: Mon, 18 Dec 2000 19:02:57 +0100
Links: << >>  << T >>  << A >>
"Daniel Hańczewski" <danhan@wp.pl> wrote in message
news:3A3DD507.F7214EBF@wp.pl...

> Is it possible to handle JTAG protocol with 4-bit IO port (I have such a
> port and I would like to connect it to JTAG)? Can I connect it directly
> or should I use any glue logic? Where can I find JTAG protocol?

I'm not 100% sure of what you mean exactly, but at least 4-bit should do  (3
out: TDI, TMS, TCK, 1 in: TDO).  Some extra buffer can be usefull (but this
won't be necessary if you use the parallel cable from Xilinx).

The protocol (as user) itself is IMHO not that difficult, certainly if you
only want to implement it to 1 type of element;  (the protocol doesn't get
more difficult as the number of elements grow,  but I guess it's a pain if
you want to program it)

'Play' a little with the demo-program of TI (It used to be at
http://www.ti.com/sc/data/jtag/scanedu.exe ), and take a detailed look at
the XC9572-bsdl file, and you probably get where you want to be.

HTH,
Alain



Article: 27977
Subject: Re: Verilog or VHDL
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Mon, 18 Dec 2000 13:13:58 -0500
Links: << >>  << T >>  << A >>
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3A39605A.80319943@algor.co.uk...
> Jamie Sanderson wrote:
> > Still, I recommend VHDL for beginners. As someone else pointed out,
Verilog
> > is easier to make mistakes in. For example, you can assign one signal to
> > another, even if they aren't of the same width. VHDL considers this a
> > mistake, and won't compile.
>
> Its interesting that this width thing is always the difference first
mentioned
> in this VHDL/Verilog discussion and its actually misleading.

I imagine it's mentioned first because it causes much confusion, a fact
attested to by a number of the other posts in this thread (and
comp.lang.verilog, for that matter).

> Verilog, at least
> at the synthesisable level, really only has three data types and no
ability for
> creating any form of structure.

Many VHDL designs use nothing more than std_logic and std_logic_vector. The
difference is that you are forced to connect things such that each line
matches one-for-one, rather than having the compiler "fill in the blanks".

> wire: Only has a value when driven, defaults to 'z' when not driven
> reg: retains the last value assigned to it.
> integer

While I distinctly didn't want to start a big argument, I guess it's
inevitable. The "reg" declaration in Verilog has always been a thorn in my
side. To the novice, it implies that it will be a register, typically with a
clock input. Actually, all it means is that the assignment must occur within
an "always" block. Therefore, some regs are "registers", while others are
combinational. However, the combinational variety can typically be done as a
wire outside of an "always" block. Confusing... In VHDL, a signal becomes a
register by virtue of being assigned on a rising or falling clock edge.

I'm also philosophically opposed to the "always @ (posedge clock or negedge
reset)" terminology. You typically want level sensitivity, not edge
sensitivity on your reset. In fact, that's what you get once this code is
synthesized. VHDL is much more clear in this aspect. The process is
sensitive to the clock and reset, but the "if" statement indicates that only
the clock has an edge sensitivity.

> Because Verilog's types are restricted these sort of issues can mostly be
taken
> care of by some careful self-discipline or formal coding styles. If
necessary
> you could invest in one of the `lint' style tools [Anyone know if there's
a
> shareware or GPL'ed one ?].

Or you could use VHDL and get much of the checking for free with the
compiler.

> The **big** thing that bites people with Verilog esp those brought up on
VHDL is
> the blocking/non-blocking assignment thing on which whole tomes have been
> written. Without care & attention to this its perfectly possible to write
> Verilog that simulates fine at RTL, synthesises o.k., but whose synth
results
> don't actually match the RTL. Ultimately its not that hard to grasp but it
does
> expose the actions of the simulator, basically the way different classes
of
> event are scheduled becomes visible at the HDL level.

I always thought the problem was that simulation didn't match the designer's
intentions, as opposed to the synthesized results. At least, this has been
my experience with the blocking/non-blocking mix-ups.

Anyhow, I'm using Verilog now, and will be for the foreseeable future. It's
a fine language to use, and I would love it if we could all just agree to
disagree (while being sure that each language steals the best aspects from
the other, while building on its own strengths, a la Windows and MacOS).

Cheers,
Jamie



Article: 27978
Subject: Re: Virtex and metastability
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 18 Dec 2000 10:18:09 -0800
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote:

> Peter A - any comments ? I seem to remember you saying on this NG some
> while back that the problem with Virtexes is that metastab events are so
> rare that the figures are hard to measure. This would imply a small N
> say 3-4.
>

We will soon ( a matter of weeks ) publish metastable delay curves for
VirtexII in a style similar to good old XAPP094, i.e. MTBF as a function of
acceptable extra delay, for a given clock and data frequency.

We had problems measuring recent devices because our method used the
half-period of the clock to determine the critical extra delay that gives a
measurably short MTBF. But our flip-flops got better than our clocking
scheme, so the testing fell apart.
In Virtex-II, we can walk around that problem...

In general, FPGAs have an advantage with respect to metastability:
Our flip-flops are constrained only by circuit design and processing
technology, and in these two areas we are as good as the best in the
industry, microprocessors and ASICs included.
When it comes to system clock rates, FPGAs are not the fastest, due to the
extra programmable interconnect delay.
That combination of ultra-fast flip-flops and more moderate system clock
rates alleviates most metastable problems in the newer FPGAs.

But let's do the measurements first, before we celebrate.

Peter Alfke




Article: 27979
Subject: Re: Setup violation
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 18 Dec 2000 11:29:25 -0800
Links: << >>  << T >>  << A >>
Ray,
the master latch in a TTL circuit is a multi-stage amplifier, thus the possibility
of oscillation.
The master latch in modern CMOS is just a cross-coupled single-stage inverter.
I have never heard of metastable oscillations in CMOS latches.
Perhaps somebody else can enlighten us...
Peter Alfke

Ray Andraka wrote:

> Peter,
>
> It isn't jsut a delay issue in all cases.  I have a photograph somewhere around
> here of
> a 54LS374 output oscillating rail to rail at about 100MHz due to a metastable
> event.  That
> one rang until the next clock.  I've also seen mateastability cause a
> flip-flop's output
> meander about between 1/4 and 3/4 vcc for several ns before settling on high or
> low.
>
> Peter Alfke wrote:
> >
> > If you violate the set-up time requirement, the flip-flop will usually work
> > fine and respond in time with either a 1 or a 0, and you obviously don't
> > care which one.
> > Sometimes, when your D input changes right within the fractional-picosecond
> > window where the master latch stops looking at the D input, the flip-flop
> > goes metastable. That does not mean that the output goes to a half-voltage.
> > It means that the flip-flop has a hard time deciding what to do, and will
> > take a while to make up its mind. That means an output change that is later
> > than the specified clock-to-Q delay. For the probability of such a delay,
> > see teh Xilinx App Note XAPP094.
> >
> > It is "only" this timing uncertainty that is the curse of metastability.
> > The 1-or-0 uncertainty is obviously acceptable.
> >
> > The Florida election fiasco is a perfect example of metastability. Just
> > because the result was so very close, the "mechanism" (or lack thereof)
> > caused a >4 week delay before deciding on one of the two choices.  But
> > let's not get into politics...
> >
> > Peter Alfke, Xilinx Applications
> > ============================================
> > Nicolas Matringe wrote:
> >
> > > Hi
> > > I was thinking about setup violation in real world (not simulation).
> > > If the setup time is not respected, the simulation result will be an 'X'
> > > on the output of the FF, but in the real world, will it be "either 0 or
> > > 1, can't say", or can it be an intermediate, metastable value?
> > > As long as it's 0 or 1, I don't mind
> > > --
> > > Nicolas MATRINGE           IPricot European Headquarters
> > > Conception electronique    10-12 Avenue de Verdun
> > > Tel +33 1 46 52 53 00      F-92250 LA GARENNE-COLOMBES - FRANCE
> > > Fax +33 1 46 52 53 01      http://www.IPricot.com/
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com  or http://www.fpga-guru.com


Article: 27980
Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ?
From: z80@ds2.com (Peter)
Date: Mon, 18 Dec 2000 19:59:19 +0000
Links: << >>  << T >>  << A >>

>>This is a very basic and general FPGA question:
>
>Basic, and general, and extremely important.
>
>>How do I assure that an externally supplied reset signal connected to some
>>sort of GSR (global set/reset) net releases all registers simultaneously (in
>>the same clock cycle) and reliably (no metastability) ?

[excellent post snipped]

This sort of thing is pretty scary - most people just assume that a
global reset will reset everything. In retrospect this is pretty
obvious but it would explain some weird FPGA power-up problems I have
seen in the past.


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: 27981
Subject: Re: Setup violation
From: Ray Andraka <ray@andraka.com>
Date: Mon, 18 Dec 2000 20:57:13 GMT
Links: << >>  << T >>  << A >>
Good point.  I wasn't considering the structure of the flip-flops, just noting
that 
I had seen other behavior other than an unpredictable propagation delay in other
technologies.  Still (as you know), when a metastable event occurs, the time to 
resolution is probabilistic, so however unlikely, it is possible to have a
metastable
event last until the next clock no matter how long the clock period is (that
probability 
decreases with the clock frequency).

Peter Alfke wrote:
> 
> Ray,
> the master latch in a TTL circuit is a multi-stage amplifier, thus the possibility
> of oscillation.
> The master latch in modern CMOS is just a cross-coupled single-stage inverter.
> I have never heard of metastable oscillations in CMOS latches.
> Perhaps somebody else can enlighten us...
> Peter Alfke
> 
> Ray Andraka wrote:
> 
> > Peter,
> >
> > It isn't jsut a delay issue in all cases.  I have a photograph somewhere around
> > here of
> > a 54LS374 output oscillating rail to rail at about 100MHz due to a metastable
> > event.  That
> > one rang until the next clock.  I've also seen mateastability cause a
> > flip-flop's output
> > meander about between 1/4 and 3/4 vcc for several ns before settling on high or
> > low.
> >
> > Peter Alfke wrote:
> > >
> > > If you violate the set-up time requirement, the flip-flop will usually work
> > > fine and respond in time with either a 1 or a 0, and you obviously don't
> > > care which one.
> > > Sometimes, when your D input changes right within the fractional-picosecond
> > > window where the master latch stops looking at the D input, the flip-flop
> > > goes metastable. That does not mean that the output goes to a half-voltage.
> > > It means that the flip-flop has a hard time deciding what to do, and will
> > > take a while to make up its mind. That means an output change that is later
> > > than the specified clock-to-Q delay. For the probability of such a delay,
> > > see teh Xilinx App Note XAPP094.
> > >
> > > It is "only" this timing uncertainty that is the curse of metastability.
> > > The 1-or-0 uncertainty is obviously acceptable.
> > >
> > > The Florida election fiasco is a perfect example of metastability. Just
> > > because the result was so very close, the "mechanism" (or lack thereof)
> > > caused a >4 week delay before deciding on one of the two choices.  But
> > > let's not get into politics...
> > >
> > > Peter Alfke, Xilinx Applications
> > > ============================================
> > > Nicolas Matringe wrote:
> > >
> > > > Hi
> > > > I was thinking about setup violation in real world (not simulation).
> > > > If the setup time is not respected, the simulation result will be an 'X'
> > > > on the output of the FF, but in the real world, will it be "either 0 or
> > > > 1, can't say", or can it be an intermediate, metastable value?
> > > > As long as it's 0 or 1, I don't mind
> > > > --
> > > > Nicolas MATRINGE           IPricot European Headquarters
> > > > Conception electronique    10-12 Avenue de Verdun
> > > > Tel +33 1 46 52 53 00      F-92250 LA GARENNE-COLOMBES - FRANCE
> > > > Fax +33 1 46 52 53 01      http://www.IPricot.com/
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com  or http://www.fpga-guru.com

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 27982
Subject: Re: Setup violation
From: murray@pa.dec.com (Hal Murray)
Date: 18 Dec 2000 21:52:13 GMT
Links: << >>  << T >>  << A >>

In article <3A3D988B.383D3682@andraka.com>,
 Ray Andraka <ray@andraka.com> writes:
> Peter, 
> 
> It isn't jsut a delay issue in all cases.  I have a photograph somewhere around
> here of 
> a 54LS374 output oscillating rail to rail at about 100MHz due to a metastable
> event.  That 
> one rang until the next clock.  I've also seen mateastability cause a
> flip-flop's output 
> meander about between 1/4 and 3/4 vcc for several ns before settling on high or
> low.

Page 130 of Johnson and Graham has a scope picture of a 74F174
making a runt pulse.  Really ugly.



-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 27983
Subject: Reconfigurable Technology CFP
From: "John Schewel" <jas@vcc.com>
Date: Mon, 18 Dec 2000 14:06:15 -0800
Links: << >>  << T >>  << A >>
                         ITCOM 2001 Call for Papers and Announcement
*********************************************************************

                                               (6th annual conference)
   RECONFIGURABLE TECHNOLOGY: FPGAs and Reconfigurable Processors
                              for Computing and Communications (IT303)

                                                         ITCOM
                              SPIE sponsored International Symposium on
             The Convergence of Information Technologies and Communications
                                               20-24 August 2001
                           Colorado Convention Center Denver, Colorado USA
                                             www.spie.org/info/itcom
*********************************************************************
Conference Chairs: John Schewel, Virtual Computer Corp.
Peter M. Athanas, Virginia Polytechnic Institute and State Univ.
Philip B. James-Roxby, Xilinx Inc.
John T. McHenry, National Security Agency

INTRODUCTION
In the late 1980's, when a few adventurers pointed to Reconfigurable
Computing (RC) as the next step in computing architectures, the
largest programmable logic devices (FPGAs) had 2K gates of
reconfigurable logic. Far from enough logic real-estate to build
computing systems. By the mid-90's, the size of reconfigurable
devices increased to 50K gates of reconfigurable logic; but the
continued low gate count, poor programming architectures, lack of
partial reconfigurablity and high cost of these devices restricted
the use of RC computing architectures to the research and
experimentation communities. Recent advances in the manufacturing
process promises 50 million gates of reconfigurable logic by 2005 at
substantially lower costs. The increased gate count along with richer
feature sets (such as greater internal I/O support, multiple
independent clocks and increased pins) have greatly improved the
economics for using RC technology in the general marketplace. With
the arrival of million plus gates of reconfigurable logic on a chip
(year 2001) and the integration of processor IP, these and other
hybrid reconfigurable devices are closer than ever to the classic
computing processor.

In the past two years, a number of application specific processors
with hard processing cores coupled to reconfigurable logic have
entered the marketplace. Software toolmakers are actively building
high-level compilers for hardware design implementation based upon C
and Java programming languages to make system programming easier.
These factors have added to the acceleration of commercial use for
reconfigurable or adaptive systems and applications.

PURPOSE:
The purpose of this conference is to bring together researchers,
manufacturers and users of reconfigurable technology for computing
systems and applications. Contributions are solicited on all aspects
of reconfigurable computing, including but not limited to:

     * new devices and systems
     * tools and techniques
     * applications and commercial implementations

The conference will present papers that illustrate applications and
techniques for using reconfigurable technology in both design and
production cycles. Papers relating to the following areas are also
solicited:

     * field programmable devices and reconfigurable processors
     * adaptive computing systems and architectures
     * programming tools and methodologies
     * applications utilizing RC technologies


              ------ IMPORTANT DATES ------

            Abstract Due Date: 19 February 2001
             Manuscript Due Date: 28 May 2001

Proceedings of this conference will be published by SPIE and
will be available at the meeting. Authors must make an oral
presentation. Authors are accorded a reduced symposium
registration fee.

THE ABSTRACT AND MANUSCRIPT DUE DATES MUST BE STRICTLY OBSERVED.

                 ------ SUBMISSION ------

Your abstract must include the following:

1. SUBMIT TO:SCHEWEL, ATHANAS, JAMES-ROXBY, MCHENRY
2. SUBMIT EACH ABSTRACT TO ONE CONFERENCE ONLY
   Reconfigurable Technology: FPGAs and Recofigurable Processors
   for Computing and Communications III
3. ABSTRACT TITLE
4. AUTHOR LISTING (principal author first)
   For all authors: First (given) name (initials not acceptable),
   Last (family) name, Affiliation, Mailing address, Telephone,
   Fax, and Email address.
5. PRESENTATION  Oral Presentation
6. ABSTRACT TEXT Approximately 250 words.
7. KEYWORDS List a maximum of five keywords.
8. BRIEF BIOGRAPHY ( principal/presenting author)

All authors are STRONGLY ENCOURAGED to submit their abstracts by
the due date using the Web form located at URL:
                                         www.spie.org/info/itcom

OR/ EMAIL each Abstract seperately to: abstracts@spie.org
in ASCII text (not encoded) format. IMPORTANT to ensure receipt
and proper processing of your abstract, the SUBJECT line must
include only ther following:

 IT303, SCHEWEL, ATHANAS,JAMES-ROXBY, MCHENRY

OR/ MAIL three copies of abstract to:

THE CONVERGENCE OF INFORMATION TECHNOLOGIES AND COMMUNICATIONS
SPIE, PO Box 10, Bellingham, WA 98225 USA

OR/ FAX on copy to SPIE at +1 (360) 647-1445 Send each Fax seperately.


Any Questions Contact:  John Schewel    jas@vcc.com



Article: 27984
Subject: Re: Setup violation
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 18 Dec 2000 22:59:14 +0000
Links: << >>  << T >>  << A >>


Hal Murray wrote:

> In article <3A3D988B.383D3682@andraka.com>,
>  Ray Andraka <ray@andraka.com> writes:
> > Peter,
> >
> > It isn't jsut a delay issue in all cases.  I have a photograph somewhere around
> > here of
> > a 54LS374 output oscillating rail to rail at about 100MHz due to a metastable
> > event.  That
> > one rang until the next clock.  I've also seen mateastability cause a
> > flip-flop's output
> > meander about between 1/4 and 3/4 vcc for several ns before settling on high or
> > low.
>
> Page 130 of Johnson and Graham has a scope picture of a 74F174
> making a runt pulse.  Really ugly.
>

I can remember this & also seem to remember that Lattice when they brought out the
GALs (~ '85 ?) claimed that this was one type of metastable event they had
eliminated.


Article: 27985
Subject: Re: Setup violation
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 18 Dec 2000 15:25:28 -0800
Links: << >>  << T >>  << A >>
Yes, I know. But this was again a TTL device with multiple stages of gain in the
latch.
Also, does it really matter whether there is an oscillation or not? I assume these
are data, not clock lines. So the only problem is that there might be a
"last-minute" change that in turn violates the next-stage set-up time.

To stay with the Florida analogy: Did the legal hick-ups before Dec 12 really
matter, except as media fodder and a national embarrassment? All that counts is
that, at the latest acceptable moment, there was a stable decision. In that respect,
the Florida metastability was successfully resolved.

Peter Alfke
==================================
Hal Murray wrote:

>
> Page 130 of Johnson and Graham has a scope picture of a 74F174
> making a runt pulse.  Really ugly.
>


Article: 27986
Subject: Re: Help configuring Spartan II using processor
From: "Andy Krumel" <andy@krumel.com>
Date: Mon, 18 Dec 2000 15:41:07 -0800
Links: << >>  << T >>  << A >>
Thanks for the insights.

An RBT (Rawbits) file is coded in ASCII - one bit for each config bit.
A .bit file is a binary coded file - one bit for each config bit.

We are space constrained on storage so we want the most compact format. The
.bit files compact well with ZIP utilities but they require too much
processing power. For now we will just take what we get with the binary
format.

> Andy,
>
> we program Xilinx chips from a 68332 uP. We wrote a program that
> builds a ROM image from an S28 (motorola hex) file and one or more
> Xilinx .RBT files. The RBT files are ascii 1's and 0's (with some
> header lines) and include all the bits (fill, CRC etc) you need.
>
> Is a .bit file the same as a .rbt?
>
> John
>



Article: 27987
Subject: Re: Help configuring Spartan II using processor
From: "Andy Krumel" <andy@krumel.com>
Date: Mon, 18 Dec 2000 15:45:16 -0800
Links: << >>  << T >>  << A >>
Great info.

I wrote a utility to strip the header out and split the bitstream file into
sections for programming paged flash. Try it out in a bit. Sorry for the
pun.

Thanks,
Andy


Joel Kolstad <JoelKolstad@Earthlink.Net> wrote in message
news:9T__5.16017$h67.1140850@newsread1.prod.itd.earthlink.net...
> > On Fri, 15 Dec 2000 12:03:28 -0800, "Andy Krumel" <andy@krumel.com>
> > wrote:
> >
> > >To date I have programmed the Spartan II using the MultiLinx cable in
> > >slave-serial mode. We are now cutting over to program it using a
> > >microcontroller. Can the .bit file generated by bitgen be fed directly
> into
> > >the chip?
>
> Certainly -- with one minor caveat.  At least in my (limited) experience,
> the .Bit file consists of a header followed by the raw bitstream itself.
We
> have a PCI card with an XCV400 on it as well as a PLX 9054 for the PCI
> interface, and we slightly abuse the '9054's EEPROM and LED lines to
> serially program the FPGA when the board wakes up.  The C code to do it
> seeks into the .Bit file to the correct magic offset (you have just look
at
> a hex dump in the file to find this offset, since you know what the
> bitstream's preamble is) and then starts shifting bits serially through
the
> '9054 to the FPGA.
>
> You can, of course, run the PROM formatter utility to generate a .Hex or
> .MCS or whatever file, but in our case, this was just an added step that
> didn't provide any utility.  On the other hand, if you have funny
> programming requirements, the PROM formatter can prove useful -- we did a
4K
> design a couple years back where a DSP's serial port shifted out the
> configuration bitstream to the FPGA, and it was easier to let the PROM
> formatter do the bit swapping (due to the endianess of the serial port)
than
> to write our own software to do it.
>
> Xilinx probably officially grumbles at the "hack the .Bit file directly"
> approach, since they can argue with complete validity than the format
might
> change in the future, and only guarantee that the new PROM formatter
utility
> would then know the correct interpretation of that new .Bit file format.
> We're not the only guys doing this, however -- we have a supplier whose
> boards do it as well.
>
> ---Joel Kolstad
>
>
>



Article: 27988
Subject: Re: Setup violation
From: Greg Neff <gregneff@my-deja.com>
Date: Tue, 19 Dec 2000 00:06:24 GMT
Links: << >>  << T >>  << A >>
In article <3A3E6594.F2516621@xilinx.com>,
  peter.alfke@xilinx.com wrote:
(snip)
> The master latch in modern CMOS is just a cross-coupled single-stage
inverter.
> I have never heard of metastable oscillations in CMOS latches.
> Perhaps somebody else can enlighten us...
> Peter Alfke
>
(snip)

I know nothing about Xilinx chip-level implementation of flip-flops,
but you say that they are cross-coupled inverter structures.  Thinking
about this, it seems to me that the only way that they can be
metastable is if they are stuck in the middle of their analog operating
areas.  IOW, they are both functioning as high gain inverting
amplifiers, with VOUT=VIN.  In this case, I would not be surprised to
see some brief oscillation before the inverter pair snaps back to
stable digital operating area states.

In an earlier post you said something about the FF output always being
at a valid level, but taking longer to switch.  It seems to me that
cross-coupled inverters are inherently stable if they are at valid
logic levels.  Using the test in XAPP094 you wouldn't see the actual
output voltage because the output is buried on the chip, so maybe the
output voltage is stuck at Vth until the latch stabilizes.  What do you
think?


--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com
http://www.deja.com/

Article: 27989
Subject: Re: ActiveHDL 4.1?
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Tue, 19 Dec 2000 00:26:00 GMT
Links: << >>  << T >>  << A >>
Swift,
    I have and use Aldec's Active-HDL 4.1 simulator for all Verilog and VHDL
designs, except when a client company insists that I use their simulator
tool.  Some of these tools have sign-off capability; however, I don't need
anyone signing off on my FPGAs!
    Of all of the simulators, it has a great Windows GUI, and it seems to be
the only simulator with a Windows GUI designed from the ground up.  Other
simulators seem to be "Windows-like," i.e., they seem to be adapted from
Unix or DOS based designs.
     I have used it to do simple to complex designs with relatively little
problem.  I had a problem once with 4.0, and their support department jumped
right on it.  Problems are normal for all products, it seems, and the true
differentiator, is tech support.
     You will not go wrong with Active-HDL 4.1 and Synplicity.  Those are
the tools I use, and they are great!
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL, USA


"Swift" <jboss@wxs.nl> wrote in message
news:91iv1c$1jh9f$1@reader2.wxs.nl...
> Does anyone use this tool for simulating VHDL-stuff for a FPGA? What's
your
> opinion? Any other suggestions? We need a tool only to simulate a
> VHDL-design. We already use Synplicity to synthesize.
>
> THX,
>
> JB



Article: 27990
Subject: Re: Verilog or VHDL
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Tue, 19 Dec 2000 00:56:38 GMT
Links: << >>  << T >>  << A >>
Ray,
    I said it wrong below ("better control of synthesis..).  What I meant to
say is that VHDL has better control of placement (you know, the RLOCing
thing).  Thanks for pointing this out, you very un-average bear!
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL


"Ray Andraka" <ray@andraka.com> wrote in message
news:3A3D96A4.1C325B92@andraka.com...
> It depends on what level you are coding at too.  VHDL makes it fairly easy
to
> embed placement (you know, RLOCs) in your code.  I haven't figured out how
to do
> that with verilog yet.  Granted, I do much mure structural coding than
your
> average bear, but the truth of the matter is that I can't do what I need
to do
> in verilog, at least not yet.
>
> "S. Ramirez" wrote:
> > truth is that both languages will do the job.  VHDL will do some things
> > better (e.g. better control of synthesis, error checking, etc.); Verilog
> > will do other things better (e.g. faster quicky jobs, PLI, etc.).  But
both
> > will do the job, and both are supported by most tools today.  If you are
an




Article: 27991
Subject: Re: dual port ram for altera
From: bobdittmar@my-deja.com
Date: Tue, 19 Dec 2000 00:58:42 GMT
Links: << >>  << T >>  << A >>
In article <3A3E4478.F8F3E02E@xilinx.com>,
  peter.alfke@xilinx.com wrote:
>
> --------------E6B47E90B30980877899DDDE
> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854";
x-mac-creator="4D4F5353"
> Content-Transfer-Encoding: 7bit
>
> bobdittmar@my-deja.com wrote:
>
> >
> > Be aware that Xilinx does not offer "true" dual port. They offer
> > bi-directional dual port. You still must arbitrate conflict access
> > to same addresses.
> >
> >
>
> Well, how far can we drive the definition of "true dual port RAM".
> Bob Dittmar thinks it should include an arbiter that resolves the
> case when both ports access the same location "kind of
> simultaneously".
> That sort of arbitration should be left to the user to define and
> implement, because a dedicated "fix" would interfere with the normal
> operation of the RAM.
>
> Virtex BlockRAM has two totally independent ports accessing a common
> storage array.
> Both might access the same location.
> If one writes and the other one reads, it depends on the relative
> clock timing whether the reader gets the old or the new data. Note
> that read is a synchronous, clocked operation. Each port has its own
> clock.
> If both ports write, the one with the later clock wins. Definitely no
> damage.
> This operation is clear and unambiguous. Solving the contention in
> dedicated hardware would not be in the user's best interest.
>
> Peter Alfke, Xilinx Applications
>
> --------------E6B47E90B30980877899DDDE
> Content-Type: text/html; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> &nbsp;
> <p>bobdittmar@my-deja.com wrote:
> <blockquote TYPE=CITE>&nbsp;
> <br>Be aware that Xilinx does not offer "true" dual port. They offer
> <br>bi-directional dual port. You still must arbitrate conflict access
> <br>to same addresses.
> <br>&nbsp;
> <br><a href="http://www.deja.com/"></a>&nbsp;</blockquote>
> Well, how far can we drive the definition of "true dual port RAM".
> <br>Bob Dittmar thinks it should include an arbiter that resolves the
case
> when both ports access the same location "kind of simultaneously".
> <br>That sort of arbitration should be left to the user to define and
implement,
> because a dedicated "fix" would interfere with the normal operation of
> the RAM.
> <p>Virtex BlockRAM has two totally independent ports accessing a
common
> storage array.
> <br>Both might access the same location.
> <br>If one writes and the other one reads, it depends on the relative
clock
> timing whether the reader gets the old or the new data. Note that read
> is a synchronous, clocked operation. Each port has its own clock.
> <br>If both ports write, the one with the later clock wins. Definitely
> no damage.
> <br>This operation is clear and unambiguous. Solving the contention in
> dedicated hardware would not be in the user's best interest.
> <p>Peter Alfke, Xilinx Applications
> <br>&nbsp;
> <br>&nbsp;
> <br>&nbsp;</html>
>
> --------------E6B47E90B30980877899DDDE--
>
>
Hey Guy, don't get your panties in wad!
What I said is true.

I did not say anything negative about Xilinx, I prefer Xilinx over
Brand A anyday. So take some prozac.

I was just letting this guy know what Xilinx advertises in their data
sheets what is somewhat contrary to what you had to say.

According to SpartanII datasheet DS001 (v1.1) april 7, 2000 pg 28

If both ports write to the same memory cell simultaneously, violating
the clock to clock setup requirement, consider the data stored as
invalid.

If one port attempts a read of the same memory cell the other
simultaneously writes violating the clock-to-clock setup
requirement, the following occurs:
   - The write succeeds
   - The data out on the writing port accurately reflects the data
written
   - The data out on the read port is invalid


Of course I don't work for Xilinx applications so I can only go by what
they publish. Obviously you have better information and I'm more than
open to listen to someone who knows more than me.

You don't have to get all upset that I indicate that the user must
implement arbitartion. I think it is somewhat understood. I was just
letting this guy know that it would need to be done and not to take
the term "true dual port" to heart.

Bob Dittmar, not Xilinx Applications (but I do like their parts)
Xtera Communications


Sent via Deja.com
http://www.deja.com/

Article: 27992
Subject: FPGA and Board for Microprocessor Design?
From: hoyte@ucsu.colorado.edu
Date: Tue, 19 Dec 2000 01:29:39 GMT
Links: << >>  << T >>  << A >>
I recently worked on a senior project where we designed a 16-bit RISC
microprocessor, and implemented the design in an FPGA. I'd like to be
able to do something similar on my own, and I'm trying to find a good
FPGA/board combination that is (relatively) affordable, and compatible
with the Xilinx student edition software. If anyone has any suggestions,
they would be greatly appreciated.

Thanks,
Eric Hoyt


Sent via Deja.com
http://www.deja.com/

Article: 27993
Subject: simulation with ActiveHDL
From: xiaoqiang@my-deja.com
Date: Tue, 19 Dec 2000 01:31:15 GMT
Links: << >>  << T >>  << A >>
I'm a newbie for activeHDL. I need help on timing simulation.

Tools:
FPGA express + xilinx foundation 2.li + activeHDL 4.1
Input:
verilog testbench and verilog source code.

(1)
When i configure flow setting in design flow for selecting device,
the console said:

Design: Warning: Library XC3000 required for the selected device family
has not been installed.

(2)
I do the function simulation successfully, but can't do timing
simulation.

Message from activeHDL console when execute timing simulation:

Warning: VCP2515 TIME_SIM.V : (81, 1): Undefined module: X_IPAD was
used. Port connection rules will not be checked at such instantiations.

ELBREAD: Error: No design unit found (library add1b_timing, name X_BUF).
etc..

Can anyone help me ? Or tell me where can find some basic tutorial or
demo for timing simulation with activeHDL?

Regards
Frank


Sent via Deja.com
http://www.deja.com/

Article: 27994
Subject: Re: Setup violation
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 18 Dec 2000 17:41:08 -0800
Links: << >>  << T >>  << A >>


Greg Neff wrote:

> II know nothing about Xilinx chip-level implementation of flip-flops,
> but you say that they are cross-coupled inverter structures.  Thinking
> about this, it seems to me that the only way that they can be
> metastable is if they are stuck in the middle of their analog operating
> areas.

Yes, agreed

> IOW, they are both functioning as high gain inverting
> amplifiers, with VOUT=VIN.  In this case, I would not be surprised to
> see some brief oscillation before the inverter pair snaps back to
> stable digital operating area states.

No, I don't see how such a prmitive structure can sustain an oscillation.
Once it leaves its metastable balanced state, there is no way to return
back to or through it. ( As is possible in multi-stage structures popular
with TTL technology)

>
>
> In an earlier post you said something about the FF output always being
> at a valid level, but taking longer to switch.  It seems to me that
> cross-coupled inverters are inherently stable if they are at valid
> logic levels.

Well, the master latch ( the only one that can go metastable) is not
brought out even from the flip-flop ( let alone the chip ). So you always
have the gain of the slave latch in series. That's why ( I think) the
flip-flop Q will never stay in the middle.

> Using the test in XAPP094 you wouldn't see the actual
> output voltage because the output is buried on the chip, so maybe the
> output voltage is stuck at Vth until the latch stabilizes.  What do you
> think?

As I said, the gain of the slave latch makes that (almost) impossible.
But I also question the importance of the question.
For data, it is irrelevant whether it oscillates or not.
And anybody using a metastable-prone signal as a clock should have his/her
head examined.

Peter Alfke

>
>
> --
> Greg Neff
> VP Engineering
> *Microsym* Computers Inc.
> greg@guesswhichwordgoeshere.com
>
> Sent via Deja.com
> http://www.deja.com/


Article: 27995
Subject: Re: dual port ram for altera
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 18 Dec 2000 17:59:32 -0800
Links: << >>  << T >>  << A >>


bobdittmar@my-deja.com wrote:

>
> Hey Guy, don't get your panties in wad!

Must be some Britishism. Dangerous in the US of A.  :-)

>
> What I said is true.
>
> I did not say anything negative about Xilinx, I prefer Xilinx over
> Brand A anyday. So take some prozac.

Thanks. I am cool. I was just clarifying terminology.

>
>
> I was just letting this guy know what Xilinx advertises in their data
> sheets what is somewhat contrary to what you had to say.

I really do not see the difference or contradiction

>
>
> According to SpartanII datasheet DS001 (v1.1) april 7, 2000 pg 28
>
> If both ports write to the same memory cell simultaneously, violating
> the clock to clock setup requirement, consider the data stored as
> invalid.

I said: The last clock wins. Same thing.
But if you don't know who is last, the data is "invalid".
This is just the usual cautious, worst-case, lawyer-inspired data sheet
lingo.

>
>
> If one port attempts a read of the same memory cell the other
> simultaneously writes violating the clock-to-clock setup
> requirement, the following occurs:
>    - The write succeeds
>    - The data out on the writing port accurately reflects the data
> written
>    - The data out on the read port is invalid

Again, data sheet lingo.
If you know which clock is (significantly) early or late, it's
deterministic as I said.

>
>
> Of course I don't work for Xilinx applications so I can only go by what
> they publish. Obviously you have better information and I'm more than
> open to listen to someone who knows more than me.

Thanks. It's mostly common sense.
But I do have the advantage of being able to check with the chip
designer...

>
>
> You don't have to get all upset

I am not upset, sorry if you got that impression. Just trying to explain
:-)

> that I indicate that the user must
> implement arbitartion. I think it is somewhat understood. I was just
> letting this guy know that it would need to be done and not to take
> the term "true dual port" to heart.

It is "true dual port", because both ports are fully functional and
independent of each other.
But you are right, simultaneous access needs some attention by the user.
We could have designed in arbitration, and we discussed that, but we saw
immediately that it would mess up the design, would be impossible to
explain for borderline cases, and thus would make nobody happy.

>
>
> Bob Dittmar, not Xilinx Applications (but I do like their parts)

Thanks!  So we have a lot in common.
But I don't know about the panties...

Peter Alfke



Article: 27996
Subject: Re: dual port ram for altera
From: Jamie Lokier <spamfilter.dec2000@tantalophile.demon.co.uk>
Date: 19 Dec 2000 04:58:26 +0100
Links: << >>  << T >>  << A >>
Peter Alfke writes:
>> If both ports write to the same memory cell simultaneously, violating
>> the clock to clock setup requirement, consider the data stored as
>> invalid.

> I said: The last clock wins. Same thing.
> But if you don't know who is last, the data is "invalid".
> This is just the usual cautious, worst-case, lawyer-inspired data sheet
> lingo.

May the "last clock" vary bit by bit due to timing variance?

>> If one port attempts a read of the same memory cell the other
>> simultaneously writes violating the clock-to-clock setup
>> requirement, the following occurs:
>> - The write succeeds
>> - The data out on the writing port accurately reflects the data
>> written
>> - The data out on the read port is invalid

> Again, data sheet lingo.
> If you know which clock is (significantly) early or late, it's
> deterministic as I said.

Common case: identical clocks.  What will you read?

thanks,
-- Jamie

Article: 27997
Subject: Re: JTAG protocol
From: kfalser@durst.it (Klaus Falser)
Date: Tue, 19 Dec 2000 08:34:12 GMT
Links: << >>  << T >>  << A >>
On Mon, 18 Dec 2000 10:12:39 +0100, Daniel
=?iso-8859-1?Q?Ha=F1czewski?= <danhan@wp.pl> wrote:

>Dear all,
>
>I'm developing a PCI card with Xilinx's XC9572 on board and I have a
>problem. I would like to use PCI bus to program XC9572 via JTAG
>interface. This solution would allow me to program the card without
>opening computer case and in the future remotely with a use of a modem.
>Is it possible to handle JTAG protocol with 4-bit IO port (I have such a
>port and I would like to connect it to JTAG)? Can I connect it directly
>or should I use any glue logic? Where can I find JTAG protocol?
>More: to allow our service people to update XC9572's configuration at
>customer site I need to have a configuration file for CPLD and a simple
>downloader. It must fit on a 3,5" diskette. Some kind of batch - "run &
>forget". In this case let's assume that downloading will be done via
>standard Xilinx's parallel cable. Is there any kind of such a
>downloader? Which file is a configuration file for XC9572?
>
>Note: I'm a beginner in CPLD's.
>
>Best regards
>Daniel
>

Hello,
Xilinx has some application note on how to program the CPLDs through a
embedded micro processor (source included). Maybe you could adapt this
to steer the pins of the PC parallel port.
You will have to look at the schematics of the Xilinx programmer cable
do determine how the pins are connected.

Personally I would use the Webpack Device Programmer program. It is
free, it is proven to work, will save you a lot of work, and can be
used (with a little training) by everyone which can use Windows.

If you plan to program the CPLD through the PCI-controller you need at
least 3 outputs (TDI, TMS, TCLK) and one input (TDO). You can use the
same information from above to drive the pins.
If you decide to drive the JTAG bus either by the PCI (controller ??)
AND by the download cable you have to pay attention that the two
drivers do not collide. Use open collector drivers and pullup
resistors.
Information on the JTAG protocoll can be found at the Texas
Instruments Home page.
Best regards
	Klaus

  
Falser Klaus
R&D Electronics Department
Company	: Durst Phototechnik AG
	Vittorio Veneto Str. 59
	I-39042 Brixen
Voice	: +0472/810235
	: +0472/810111
FAX	: +0472/830980
Email	: kfalser@durst.it 

Article: 27998
Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ?
From: murray@pa.dec.com (Hal Murray)
Date: 19 Dec 2000 08:39:20 GMT
Links: << >>  << T >>  << A >>

> Read the documentation for your FPGA and you should be able to find numbers
> for the global reset routing skew. If the skew is larger than your clock
> period, then you will potentially have registers coming out of reset two
> clock cycles before others.

That one set off my alarm bells.

Even if the skew is low, you are in trouble if the delay matches
a clock cycle.  Or rather any integer number of clock cycles.

If the delay on the global-reset path is less than your clock period,
you still have to make sure that the reset gets clocked (cleanly)
on your system clock.  That's impossible to do if you have several
different clocks driving your chip.  (Obviously, clocks that are
multiples of eachother are not "different" in this context.)


This gets hashed over here occasionally.  Consensus seems to be
to do the reset logic yourself.

I got burned by this many years ago.  I haven't forgotten yet.



Speaking of global-reset, how does GSR work on a Virtex?  If I look
with the FPGA Editor, I don't see any place where GSR connects up
to a CLB or IOB.

  If I specify an explicit set/reset term, does that replace what GSR
  does or does it get ORed in with GSR?

  Is there an extra input on some SR mux that isn't shown?  Or does GSR
  get wired up outside the CLB on some path that isn't shown?  Or am I
  just not looking in the right place?

  The SR input to a CLB is also used as a write-enable when the LUT
  memory is used as a RAM or shift-register.  Do the FFs still get
  reset by GSR?

-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 27999
Subject: 3V -> 5V clock signal level conversion
From: Nial Stewart <nials@sqf.hp.com>
Date: Tue, 19 Dec 2000 10:06:49 +0000
Links: << >>  << T >>  << A >>
I'm looking at a problem where we need to drive a 
couple of 5V CMOS clock inputs from a SpartanII
3v output.

There are data lines being driven from the 3V output,
we can get away with the 'tristate and pull high
for logic high' trick, but I don't want to do this with
the clock signals. The active (rising) edges are 
_very_ slow and the risk of double clocking etc
would be too high.


Space is fairly tight so my immediate thought was
to use an 8 pin soic dual comparator with the -ve
input tied to 1.8V (power plane). 

My only concern with this is that I think I read a
while ago that comparators shouldn't be used for this
sort of application, I can't remember where I read this
so I can't check if I'm right. It might have been 
because of the lask of hysteresis on the input,
but if the -ve input is set to a 'clean' part
of the waveform I don't think we should see 
any problems.

Can anyone think of any drawbacks of using a fast 
comparator for this conversion?

Nial.



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