Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 47325

Article: 47325
Subject: writing across a column in an SDRAM
From: "A. Nelson" <anelson@NS.lumenera.com>
Date: Mon, 23 Sep 2002 18:24:54 -0400
Links: << >>  << T >>  << A >>
I have an odd problem that I'd like anyone's opinion on.

I have a data stream, that I'd like to write into SDRAM (I'm writing my own
controller, so I can do it any way I'd like).  However, I don't want to
write across a row (like you're supposed to do, so you can take advantage of
bursting), but rather across a column.

This means that every word would go to a different row.  So, every word
would require a full write cycle (active, write, precharge).  This is far
too slow.

So, I got the idea of "bursting" across the banks (which allows for 4
writes, before a precharge), like this:

(A=Active, W= write, P = precharge, r=row, b=bank, c=column)

A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W (c
0, b 2), A (r 0, b 3), W (c 0, b 3), P

then

A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W (c
0, b 2), A (r 1, b 3), W (c 0, b 3), P

and so on (with the required NOPs, to meet timing).

I was also considering doing all the actives, then writes, then precharge
(A, A, A, A, W, W, W, W, P).

Any other suggestions?



Article: 47326
Subject: Re: Fast serial interconnect bus using spartan-II
From: fpgaguy@aedinc.net (Jason Daughenbaugh)
Date: 23 Sep 2002 15:56:08 -0700
Links: << >>  << T >>  << A >>
Markus,

We use LVDS with a spartan-2 to transmit data at 160 Mbps reliably
over 100ft + (30m) of CAT-5 cable.  I am using parts from National and
TI for the LVDS, but I am ready to try the spartan2e's built-in LVDS.

I use a 8b/10b encoding and have enough protocol to detect errors and
resend packets.  It works great.  I believe that much higher speeds
are possible (the parts are 400 Mbps), especially with shorter cables.
 I am running synchronous, with one pair as a clock and another pair
as data, but you should be able to build a high-speed UART to receive
this without a clock.  Xilinx has some good app notes on this design. 
National also has some good app notes on LVDS over cat-5.

Jason Daughenbaugh
http://www.aedinc.net

meng.engineering@bluewin.ch (Markus Meng) wrote in message news:<aaaee51b.0209230623.700eae42@posting.google.com>...
> hi all,
> 
> has anybody done this using spartan-ii with - for example -
> an LVDS interface?
> 
> What I require is a fast serial - bus like - connection between
> 3 or 4 electronic modules. Those modules are close to each other
> but in separate cabinets. I would like to use - let's say - RJ11
> connector and cabling, the speed should be ~ 100 Mbps
> 
> markus

Article: 47327
Subject: Re: writing across a column in an SDRAM
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 23 Sep 2002 19:06:30 -0400
Links: << >>  << T >>  << A >>
"A. Nelson" wrote:
> 
> I have an odd problem that I'd like anyone's opinion on.
> 
> I have a data stream, that I'd like to write into SDRAM (I'm writing my own
> controller, so I can do it any way I'd like).  However, I don't want to
> write across a row (like you're supposed to do, so you can take advantage of
> bursting), but rather across a column.
> 
> This means that every word would go to a different row.  So, every word
> would require a full write cycle (active, write, precharge).  This is far
> too slow.
> 
> So, I got the idea of "bursting" across the banks (which allows for 4
> writes, before a precharge), like this:
> 
> (A=Active, W= write, P = precharge, r=row, b=bank, c=column)
> 
> A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W (c
> 0, b 2), A (r 0, b 3), W (c 0, b 3), P
> 
> then
> 
> A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W (c
> 0, b 2), A (r 1, b 3), W (c 0, b 3), P
> 
> and so on (with the required NOPs, to meet timing).
> 
> I was also considering doing all the actives, then writes, then precharge
> (A, A, A, A, W, W, W, W, P).
> 
> Any other suggestions?

I think you have the right idea.  By doing all the activates
sequentially, you will minimize the number of noops.  It has been awhile
since I have done any work with SDRAMs, but I think you can do a
precharge on one bank at a time.  Not knowing how fast you are planning
to clock the part, I can't say which way would be faster.  

I believe you would have to put noops before and after the single
precharge.  If you use four bank precharge commands you may not need
noops at all.  You will need to work out the details based on your clock
speed and the parts you choose.  

Just curious about why you want to write across the columns.  Does it
have to do with how you are reading the data out?  Are you using the
SDRAM to permute the data?  

-- 

Rick "rickman" Collins

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

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

Article: 47328
Subject: Re: writing across a column in an SDRAM
From: Ray Andraka <ray@andraka.com>
Date: Mon, 23 Sep 2002 23:17:27 GMT
Links: << >>  << T >>  << A >>
since you are not bursting at all, you could use the auto precharge and save
yourself some steps in the controller.  Also, if you can buffer up a few of the
writes, you can use short bursts on each row so that you can totally hide the
actives and precharges except where you switch between read and write.

I am assuming you are doing this because of the way you are reading the data back
out, otherwise switch the row and column and do things with normal bursts.

rickman wrote:

> "A. Nelson" wrote:
> >
> > I have an odd problem that I'd like anyone's opinion on.
> >
> > I have a data stream, that I'd like to write into SDRAM (I'm writing my own
> > controller, so I can do it any way I'd like).  However, I don't want to
> > write across a row (like you're supposed to do, so you can take advantage of
> > bursting), but rather across a column.
> >
> > This means that every word would go to a different row.  So, every word
> > would require a full write cycle (active, write, precharge).  This is far
> > too slow.
> >
> > So, I got the idea of "bursting" across the banks (which allows for 4
> > writes, before a precharge), like this:
> >
> > (A=Active, W= write, P = precharge, r=row, b=bank, c=column)
> >
> > A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W (c
> > 0, b 2), A (r 0, b 3), W (c 0, b 3), P
> >
> > then
> >
> > A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W (c
> > 0, b 2), A (r 1, b 3), W (c 0, b 3), P
> >
> > and so on (with the required NOPs, to meet timing).
> >
> > I was also considering doing all the actives, then writes, then precharge
> > (A, A, A, A, W, W, W, W, P).
> >
> > Any other suggestions?
>
> I think you have the right idea.  By doing all the activates
> sequentially, you will minimize the number of noops.  It has been awhile
> since I have done any work with SDRAMs, but I think you can do a
> precharge on one bank at a time.  Not knowing how fast you are planning
> to clock the part, I can't say which way would be faster.
>
> I believe you would have to put noops before and after the single
> precharge.  If you use four bank precharge commands you may not need
> noops at all.  You will need to work out the details based on your clock
> speed and the parts you choose.
>
> Just curious about why you want to write across the columns.  Does it
> have to do with how you are reading the data out?  Are you using the
> SDRAM to permute the data?
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 47329
Subject: Re: MAP problem: Trivial RPM fails
From: Bret Wade <bret.wade@xilinx.com>
Date: Mon, 23 Sep 2002 18:50:53 -0600
Links: << >>  << T >>  << A >>
This RPM pack error has been investigated and found to be a bug in the mappers
pack code. A fix is scheduled for 5.1i service Pack 3 which will become
available in December, 2002.

Regards,
Bret Wade
Xilinx Product Applications

Jan Gray wrote:

> Following up on my earlier article, "RAM32X1S, Virtex-II, 4.1i PAR travails"
> (
> http://groups.google.com/groups?selm=a5j91k%24akt%241%40slb3.atl.mindspring.
> net ), I am now trying to make a trivial RPM, consisting of a RAM32X1S and a
> DFF, RLOC'd to the same slice.
>
> No matter what I try (including adding BELs), no joy.
>
> I get a variant of:
>
> ERROR:Pack:679 - Unable to obey design constraints (MACRONAME=r/hset,
> RLOC=X0Y0)
> which require the combination of the following symbols into a single slice
> component:
> FLOP symbol "r/dff" (Output Signal = q)
> RAM symbol "r/ram/F" (Output Signal = r/ram/F)
> RAM symbol "r/ram/G" (Output Signal = r/ram/G)
> WEDECODE symbol "r/ram/WEDECODE" (Output Signal = r/ram/WEDECODE)
> BUF symbol "r/ram/BXBUF" (Output Signal = r/ram/A4')
> Unable to pack the register r/dff because of connectivity restrictions.
> Please correct the design constraints accordingly.
>
> I happen to know this is a perfectly legal packing of the slice, because if
> I DELETE the RLOC constraint on the DFF, the placer is quite happy to place
> the DFF in the same slice as the RAM32X1S on its own initiative.
> Specifically, the two 4-LUT RAM outputs go through the F5MUX, the F5 input
> of the FXMUX, and out onto output X, then back in on input DX, through the
> DXMUX and into the D input of FFX.
>
> This problem occurs in 4.1i, so I thought I'd try it under 4.2i.  So I
> installed 4.2i. And 4.2i SP3.  See following message for my blue screen of
> death travails there.
>
> Nope, not even 4.2i SP3 will accept my RAM32X1S and my DFF RLOC'd to the
> same slice.
>
> Can anyone offer any workarounds short of hard LOCs or XDL?  I use RPMs to
> get repeatable datapath placements and timings so that I can tune up my
> design in a methodical way. Anything else is playing whack-a-mole on the
> critical paths.
>
> Quick and dirty Synplicity example:
>
> module tramq(clk, i, o);
>  input clk, i;
>  output o;
>  reg o;
>  reg we;
>  reg [4:0] ad;
>  reg d;
>  ramq r(clk, we, ad, d, q);
>  always @(posedge clk) begin
>   {we, ad, d} <= {ad, d, i};
>   o <= q;
>  end
> endmodule
>
> module ramq(clk, we, ad, d, q)
>    /* synthesis syn_hier="hard"*/;
>   input  clk, we, d;
>   input  [4:0] ad;
>   output q;
>   wire o;
>   RAM32X1S ram(.A0(ad[0]), .A1(ad[1]), .A2(ad[2]), .A3(ad[3]), .A4(ad[4]),
> .D(d), .O(o), .WCLK(clk), .WE(we))
>     /* synthesis RLOC="X0Y0" */;
>   FD dff(.C(clk), .D(o), .Q(q))
>    /* synthesis RLOC="X0Y0" */;
> endmodule
>
> Thanks.
> Jan Gray, Gray Research LLC


Article: 47330
Subject: Re: MTBF
From: Peter Alfke <palfke@earthlink.net>
Date: Tue, 24 Sep 2002 03:30:20 GMT
Links: << >>  << T >>  << A >>
Read the report. It describes how we tested in parallel thousands (!) of
devices for many months at 125 degrees C, in order to achieve any
statistically meaningful failure rate.
Then we (like everybody else) use the Arrhenius model to calculate MTBF at
more reasonable temperatures.
This kind of testing is not fast, and is not cheap. But it has to be done...
Boring reading, but important facts.

Peter Alfke
====================
Simon wrote:

> Millions of hours ? A million hours is ~114 years... I thought there was
> generally an "acceleration" involved in the calculation. If so, what are
> the systematic error-bars on those estimates ?
>
> Actually, I don't really care :-) I was just a bit taken aback by the
> apparent centuries of testing already performed by Xilinx <grin>
>


Article: 47331
Subject: Re: IC layout
From: Veli-Matti Karppinen <veli-matti.karppinen@rem_obvious.pigroup.fi>
Date: Tue, 24 Sep 2002 08:08:28 +0300
Links: << >>  << T >>  << A >>
Blackie Beard wrote:
> 
> There ought to be a comp.arch.asic group.  There
> are some groups if you search on 'chip'.  But I don't
> know how relevant they are to you.
> 
> "Reala" <-> wrote in message news:amdu7m$gar17@imsp212.netvigator.com...
> > Hi,
> >
> > Sorry that I ask the question about IC layout, but I cannot find any
> > newsgroup about IC layout.
> > Sorry for any inconvinence.
> >
> > Anyone can tell me some homepage or newsgroup talk about IC layout?
> > Thank you.
> >
> > Reala
> >
> >
> >

Hi,

I think You could take a look at http://www.deepchip.com and 
subscribe John Cooley's ESNUG newsletter. IC layout is one of 
the many interesting subjects there.

Regards,

Veli-Matti

Article: 47332
Subject: Re: Unused pins in Apex20KE
From: Daryl <e-engineer@eastday.com>
Date: 24 Sep 2002 05:21:10 GMT
Links: << >>  << T >>  << A >>

But, how about the unused pins on Xilinx device?

default to drive grand or be left floating?

SpartanII and Virtex device.

--
Daryl

Article: 47333
Subject: querries regarding cpld
From: rahulprakash_j@yahoo.com (rahul joshi)
Date: 24 Sep 2002 00:55:16 -0700
Links: << >>  << T >>  << A >>
Hello,

      I,m new to CPLD/FPGA and have few questions?
#How to transfer a VHDL code on cpld/fpga?
#How much a single cpld cost?
#Is it really economical to use cpld/fpga for a dedicated purpose
equipment
 with limited scope?e.g. a harness tester,a handheld banking system  
machine,billing machine on any counter etc.
If it is really not economical,is there any other alternative to
develop/design chips for such limited scope machines(where mass
production may not be possible).

Thanking in advance.
rahul

Article: 47334
Subject: Re: MAP problem: Trivial RPM fails
From: muthu_nano@yahoo.co.in (Muthu)
Date: 24 Sep 2002 00:59:40 -0700
Links: << >>  << T >>  << A >>
Bret Wade <bret.wade@xilinx.com> wrote in message news:<3D8FB6EC.A33F615F@xilinx.com>...
> This RPM pack error has been investigated and found to be a bug in the mappers
> pack code. A fix is scheduled for 5.1i service Pack 3 which will become
> available in December, 2002.
> 
> Regards,
> Bret Wade
> Xilinx Product Applications
> 
> Jan Gray wrote:
> 
> > Following up on my earlier article, "RAM32X1S, Virtex-II, 4.1i PAR travails"
> > (
> > http://groups.google.com/groups?selm=a5j91k%24akt%241%40slb3.atl.mindspring.
> > net ), I am now trying to make a trivial RPM, consisting of a RAM32X1S and a
> > DFF, RLOC'd to the same slice.
> >
> > No matter what I try (including adding BELs), no joy.
> >
> > I get a variant of:
> >
> > ERROR:Pack:679 - Unable to obey design constraints (MACRONAME=r/hset,
> > RLOC=X0Y0)
> > which require the combination of the following symbols into a single slice
> > component:
> > FLOP symbol "r/dff" (Output Signal = q)
> > RAM symbol "r/ram/F" (Output Signal = r/ram/F)
> > RAM symbol "r/ram/G" (Output Signal = r/ram/G)
> > WEDECODE symbol "r/ram/WEDECODE" (Output Signal = r/ram/WEDECODE)
> > BUF symbol "r/ram/BXBUF" (Output Signal = r/ram/A4')
> > Unable to pack the register r/dff because of connectivity restrictions.
> > Please correct the design constraints accordingly.
> >
> > I happen to know this is a perfectly legal packing of the slice, because if
> > I DELETE the RLOC constraint on the DFF, the placer is quite happy to place
> > the DFF in the same slice as the RAM32X1S on its own initiative.
> > Specifically, the two 4-LUT RAM outputs go through the F5MUX, the F5 input
> > of the FXMUX, and out onto output X, then back in on input DX, through the
> > DXMUX and into the D input of FFX.
> >
> > This problem occurs in 4.1i, so I thought I'd try it under 4.2i.  So I
> > installed 4.2i. And 4.2i SP3.  See following message for my blue screen of
> > death travails there.
> >
> > Nope, not even 4.2i SP3 will accept my RAM32X1S and my DFF RLOC'd to the
> > same slice.
> >
> > Can anyone offer any workarounds short of hard LOCs or XDL?  I use RPMs to
> > get repeatable datapath placements and timings so that I can tune up my
> > design in a methodical way. Anything else is playing whack-a-mole on the
> > critical paths.
> >
> > Quick and dirty Synplicity example:
> >
> > module tramq(clk, i, o);
> >  input clk, i;
> >  output o;
> >  reg o;
> >  reg we;
> >  reg [4:0] ad;
> >  reg d;
> >  ramq r(clk, we, ad, d, q);
> >  always @(posedge clk) begin
> >   {we, ad, d} <= {ad, d, i};
> >   o <= q;
> >  end
> > endmodule
> >
> > module ramq(clk, we, ad, d, q)
> >    /* synthesis syn_hier="hard"*/;
> >   input  clk, we, d;
> >   input  [4:0] ad;
> >   output q;
> >   wire o;
> >   RAM32X1S ram(.A0(ad[0]), .A1(ad[1]), .A2(ad[2]), .A3(ad[3]), .A4(ad[4]),
> > .D(d), .O(o), .WCLK(clk), .WE(we))
> >     /* synthesis RLOC="X0Y0" */;
> >   FD dff(.C(clk), .D(o), .Q(q))
> >    /* synthesis RLOC="X0Y0" */;
> > endmodule
> >
> > Thanks.
> > Jan Gray, Gray Research LLC

Hi all,

I have a doubt. if we give the RLOC = "X0Y0", it will be passed to the
xilinx's PAR tool through the edif file. is that right?

Is this a Permenet location of the FF or module whatever may be? or
the PAR tool can move the module or FF location if timing is not
acheived.

How it will become, Relative Positional Macro.?

Best regards,
Muthu

Article: 47335
Subject: Re: Xilinx ISE5.1 and Windows NT
From: Petter Gustad <newsmailcomp3@gustad.com>
Date: 24 Sep 2002 10:07:24 +0200
Links: << >>  << T >>  << A >>
Stephen Williams <db6jn001@sneakemail.com> writes:

> If you want a stable work environment, start getting used to the
> idea of moving to Linux.

I just can't see *why* Xilinx doesn't provide a native Linux version
of their tools? I would expect it would be as easy to port the Solaris
version to native Linux as it would be to use Wine and the Windows
version.

You would then get the multinode place and route (PAR) feature found
in the Solaris version. I have access to large clusters of Linux based
PC where I wish I could run multiple iterations of PAR jobs in
parallel.

Also some of the new Virtex II Pro PowerPC processor model and Gigabit
serial interface models are provided as SWIFT models. This means that
you need access to a simulator like Synopsys VCS or Cadence Verilog (I
don't know if Modeltech supports SWIFT under Windows?).

I can imagine running PAR and simulation jobs on the large Virtex II
Pro devices and future device families will require a large amount of
RAM. Running on a 64-bit X86 (http://www.x86-64.org) would result in a
high performance low cost solution.


Petter
BTW. Steve: Thank you for providing Icarus Verilog.
-- 
________________________________________________________________________
Petter Gustad         8'h2B | ~8'h2B        http://www.gustad.com/petter

Article: 47336
Subject: Re: MAP problem: Trivial RPM fails
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Tue, 24 Sep 2002 08:11:53 GMT
Links: << >>  << T >>  << A >>
On 24 Sep 2002 00:59:40 -0700, muthu_nano@yahoo.co.in (Muthu) wrote:

>Bret Wade <bret.wade@xilinx.com> wrote in message news:<3D8FB6EC.A33F615F@xilinx.com>...
>> This RPM pack error has been investigated and found to be a bug in the mappers
>> pack code. A fix is scheduled for 5.1i service Pack 3 which will become
>> available in December, 2002.
>> 
>> Regards,
>> Bret Wade
>> Xilinx Product Applications
>> 
>> Jan Gray wrote:
>> 
>> > Following up on my earlier article, "RAM32X1S, Virtex-II, 4.1i PAR travails"
>> > (
>> > http://groups.google.com/groups?selm=a5j91k%24akt%241%40slb3.atl.mindspring.
>> > net ), I am now trying to make a trivial RPM, consisting of a RAM32X1S and a
>> > DFF, RLOC'd to the same slice.
>> >
>> > No matter what I try (including adding BELs), no joy.
>> >
>> > I get a variant of:
>> >
>> > ERROR:Pack:679 - Unable to obey design constraints (MACRONAME=r/hset,
>> > RLOC=X0Y0)
>> > which require the combination of the following symbols into a single slice
>> > component:
>> > FLOP symbol "r/dff" (Output Signal = q)
>> > RAM symbol "r/ram/F" (Output Signal = r/ram/F)
>> > RAM symbol "r/ram/G" (Output Signal = r/ram/G)
>> > WEDECODE symbol "r/ram/WEDECODE" (Output Signal = r/ram/WEDECODE)
>> > BUF symbol "r/ram/BXBUF" (Output Signal = r/ram/A4')
>> > Unable to pack the register r/dff because of connectivity restrictions.
>> > Please correct the design constraints accordingly.
>> >
>> > I happen to know this is a perfectly legal packing of the slice, because if
>> > I DELETE the RLOC constraint on the DFF, the placer is quite happy to place
>> > the DFF in the same slice as the RAM32X1S on its own initiative.
>> > Specifically, the two 4-LUT RAM outputs go through the F5MUX, the F5 input
>> > of the FXMUX, and out onto output X, then back in on input DX, through the
>> > DXMUX and into the D input of FFX.
>> >
>> > This problem occurs in 4.1i, so I thought I'd try it under 4.2i.  So I
>> > installed 4.2i. And 4.2i SP3.  See following message for my blue screen of
>> > death travails there.
>> >
>> > Nope, not even 4.2i SP3 will accept my RAM32X1S and my DFF RLOC'd to the
>> > same slice.
>> >
>> > Can anyone offer any workarounds short of hard LOCs or XDL?  I use RPMs to
>> > get repeatable datapath placements and timings so that I can tune up my
>> > design in a methodical way. Anything else is playing whack-a-mole on the
>> > critical paths.
>> >
>> > Quick and dirty Synplicity example:
>> >
>> > module tramq(clk, i, o);
>> >  input clk, i;
>> >  output o;
>> >  reg o;
>> >  reg we;
>> >  reg [4:0] ad;
>> >  reg d;
>> >  ramq r(clk, we, ad, d, q);
>> >  always @(posedge clk) begin
>> >   {we, ad, d} <= {ad, d, i};
>> >   o <= q;
>> >  end
>> > endmodule
>> >
>> > module ramq(clk, we, ad, d, q)
>> >    /* synthesis syn_hier="hard"*/;
>> >   input  clk, we, d;
>> >   input  [4:0] ad;
>> >   output q;
>> >   wire o;
>> >   RAM32X1S ram(.A0(ad[0]), .A1(ad[1]), .A2(ad[2]), .A3(ad[3]), .A4(ad[4]),
>> > .D(d), .O(o), .WCLK(clk), .WE(we))
>> >     /* synthesis RLOC="X0Y0" */;
>> >   FD dff(.C(clk), .D(o), .Q(q))
>> >    /* synthesis RLOC="X0Y0" */;
>> > endmodule
>> >
>> > Thanks.
>> > Jan Gray, Gray Research LLC
>
>Hi all,
>
>I have a doubt. if we give the RLOC = "X0Y0", it will be passed to the
>xilinx's PAR tool through the edif file. is that right?

Yes, that is right.

>Is this a Permenet location of the FF or module whatever may be? or
>the PAR tool can move the module or FF location if timing is not
>acheived.
>
>How it will become, Relative Positional Macro.?

RLOC = *relative* location.  This ff is located with respect to other
flip flops in this module.  The entire module may be located (relative
or absolute) in the higher level module that instantiates this one, or
if not, the placer can put it anywhere, but the relative locations
*within this module* remain the same.

LOC = *absolute* location.  This ff is located at a fixed location on
the die.

Regards,
Allan.

Article: 47337
Subject: Re: querries regarding cpld
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 24 Sep 2002 20:19:00 +1200
Links: << >>  << T >>  << A >>
rahul joshi wrote:
> 
> Hello,
> 
>       I,m new to CPLD/FPGA and have few questions?
> #How to transfer a VHDL code on cpld/fpga?

You need to compile the HDL source, and place/route/fit the
intermediate file ( typ EDIF or PLA ), to create 
the a binary device file.
This is then loaded into the target device, either serially,
or using a device programmer.

So, flow wise, it's very similar to HLL -> ASM -> HEX -> uC

> #How much a single cpld cost?

Typical med volume price curve is ~ $1/32Mcells

> #Is it really economical to use cpld/fpga for a dedicated purpose
> equipment
>  with limited scope?e.g. a harness tester,a handheld banking system
> machine,billing machine on any counter etc.
> If it is really not economical,is there any other alternative to
> develop/design chips for such limited scope machines(where mass
> production may not be possible).

 CPLD/FPGA  are well suited to those tasks beyond typical
embedded controllers - so for harness testing, a uC could do this,
but a CPLD will do it much faster.
 Same applies to Serial IO, RAM data pumps, state engines....

-jg

Article: 47338
Subject: Re: writing across a column in an SDRAM
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Tue, 24 Sep 2002 08:26:37 GMT
Links: << >>  << T >>  << A >>
On Mon, 23 Sep 2002 18:24:54 -0400, "A. Nelson"
<anelson@NS.lumenera.com> wrote:

>I have an odd problem that I'd like anyone's opinion on.
>
>I have a data stream, that I'd like to write into SDRAM (I'm writing my own
>controller, so I can do it any way I'd like).  However, I don't want to
>write across a row (like you're supposed to do, so you can take advantage of
>bursting), but rather across a column.
>
>This means that every word would go to a different row.  So, every word
>would require a full write cycle (active, write, precharge).  This is far
>too slow.
>
>So, I got the idea of "bursting" across the banks (which allows for 4
>writes, before a precharge), like this:
>
>(A=Active, W= write, P = precharge, r=row, b=bank, c=column)
>
>A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W (c
>0, b 2), A (r 0, b 3), W (c 0, b 3), P
>
>then
>
>A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W (c
>0, b 2), A (r 1, b 3), W (c 0, b 3), P
>
>and so on (with the required NOPs, to meet timing).
>
>I was also considering doing all the actives, then writes, then precharge
>(A, A, A, A, W, W, W, W, P).
>
>Any other suggestions?

You could use a small SRAM (e.g. xilinx block ram) as a reorder
buffer.  Collect N rows worth of columns in the SRAM then do bursts of
length N into the SDRAM.  Even N as small as 2 would give you a
significant speedup.

Regards,
Allan.

Article: 47339
Subject: Re: Xilinx ISE5.1 and Windows NT
From: Petter Gustad <newsmailcomp3@gustad.com>
Date: 24 Sep 2002 10:30:42 +0200
Links: << >>  << T >>  << A >>
 writes:

[Stephen Williams]
> > If you want a stable work environment, start getting used to the
> > idea of moving to Linux.

[Rick "rickman" Collins]
> That sounds like a great concept, but in the real world, Linux is hardly
> supported.  Xilinx only supports it running with WINE IIRC and they have

I guess it depends upon your world :-) 

I've been using Chronologic VCS (now Synopsys), Design Acceleration
Signalscan (now Cadence), Cadence Verilog, Finsim, Synopsys Design
Compiler etc. for many years under Linux.

Petter
-- 
________________________________________________________________________
Petter Gustad         8'h2B | ~8'h2B        http://www.gustad.com/petter

Article: 47340
Subject: upcoming trened: analogue Fpga's?
From: Dennis Sneijers <qdsn@oce.nl>
Date: Tue, 24 Sep 2002 10:47:09 +0200
Links: << >>  << T >>  << A >>
Hello,

Looking to the market we see an upcoming trend in programmable analogue
fpga based devices. At this moment i'm researching these devices.
Devices like the FPAA - Anadigm, Trac - Zetex, ispPAC - Lattice, PSoC -
Cypress and the FIPSOC - SIDSA are good examples of these. 

I wanna know if anyone knows something more about other devices fitting
in this category? And maybe there is someone who got more experience
with applications where these devices are used. Tell me please more
about that i'm very interested in it. And does anyone knows something
more about the FIPSOC? It seems a very unknow device to me...

Thanx Dennis Sneijers, 

Oce Technologies BV Venlo, Netherland

Article: 47341
Subject: Re: upcoming trened: analogue Fpga's?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 24 Sep 2002 21:23:31 +1200
Links: << >>  << T >>  << A >>
Dennis Sneijers wrote:
> 
> Hello,
> 
> Looking to the market we see an upcoming trend in programmable analogue
> fpga based devices. At this moment i'm researching these devices.
> Devices like the FPAA - Anadigm, Trac - Zetex, ispPAC - Lattice, PSoC -
> Cypress and the FIPSOC - SIDSA are good examples of these.
> 
> I wanna know if anyone knows something more about other devices fitting
> in this category? And maybe there is someone who got more experience
> with applications where these devices are used. Tell me please more
> about that i'm very interested in it. And does anyone knows something
> more about the FIPSOC? It seems a very unknow device to me...

 We put a link to this on our web site, but the PDF for FIPSOC1 is dated 
June 99, and nothing more recent shows in the press info, so I would say
it
is 'paused' :)

 On "Analog FPGA" generally, their biggest drawback is the very poor
and narrow-use analog performance - besides being single-sourced 
in the worst sense, they cannot compete with the leading edge
analog companies, which are leaving them behind in specs.
 Dynamic range, distortion and noise are commonly so mediocre, they
are left off the 'Overview' promo materials entirely (eg ispPAC)

 They look nice to play with, and look good in press releases, but
do you know anyone who has actually used one in a real product ?

-jg

Article: 47342
Subject: Re: Timing accuracy with Modelsim
From: christopher.saunter@durham.ac.uk (Christopher Saunter)
Date: Tue, 24 Sep 2002 10:28:59 +0000 (UTC)
Links: << >>  << T >>  << A >>

: P.S. Which books (either online and not) do you suggest as a
: beginner/intermediate VHDL reference focused on programmable logic
: syntesis? I am reading some generic VHDL books like the "VHDL Cookbook",
: but they are very abstract and obsolete.

: --
: Lorenzo

Hi Lorenzo,

	I have also been learning (to tolerate ;-) VHDL recently.
I've got "Introductory VHDL, From Simulation to Synthesis" by Sudhakar
Yalamanchili.  It's aimed at the old Foundation bassed Xilinx stuff, not
the new ISE series, but most of the book can be taken as standallone VHDL
for PLDs.  I found the book worked very well when taken in conjunction
with all the VHDL code I could lay my hands on, and using the book to
understand how the code works.

Having spent a lot of time with the foundation simulator craating
waveforms in the past, the chapter on creating VHDL testbenches
was particularly invaliable!  


some grumbles (common to a lot of VHDL books I've looked at):

1) Why are code snippets printed in a proportional font?

2) Indentation.  I know VHDL does not have any inbuilt indentation
   standards, but I am a firm believer than sensibly used indentation
   makes readability, and therefore the ease of spotting / preventing
   errors soars.  The indentation in the code snippets is pretty
   arbitrary.

If you are starting out with Modlesim, I can highly recomend the following
text (or there abouts) I saw somewhere, then forgot about, then remembered
after half an hour of wondering why a simulation was going wrong...

"Simulators and Synthesis tools attatch different importances to a
process' sensitivy list.  An incomplete sensitivy list will probably not
affect the results of synthesis, but will cause a simulator limit the
conditions under which the process is executed beyond those you wish."

Modelsim doesn't seem to raise an eyebrow to an incomplete sensitivity
list (after all, as far as modelsim is concerned, the code might never be
destined for a PLD, so perhaps you meant it that way) - however XST raises
warnings when synthesising such code.  I can highly recomend 

1) Writing your VHDL, whilst remembering to check for the above
2) Synthesising the VHDL, or running it through a validator (anyone got
   any good pointers for such things?)
3) grepping the synthesiser logs for the word 'incomplete'
4) Checking and fixing the VHDL
4) Repearing 2-4 till you are satisfied
5) Simulating.

After a while doing it the right way becomes second nature.

---

cheers
cds

Article: 47343
Subject: FPGA fail when Electrostatic discharge Occurs
From: "Jérémie WEBER" <j.weber@digigram.com>
Date: Tue, 24 Sep 2002 14:21:16 +0200
Links: << >>  << T >>  << A >>

I have a problem with a design ( 200k spartan II E ) that fail when an
Electrostatic discharge occurs.

I presume that some flip-flop are reseted but not all. That means that my
design fail and is unstable.

I have set some hardware things to avoid a large part of this problems but
when it occurs I always fail.

Have you got any Idea to secure the FPGA design itself ?

Regards.

Jérémie WEBER



Article: 47344
Subject: Re: Altera Cyclone 'FPGA'
From: "Xanatos" <fpsbb98@yahoo.com>
Date: Tue, 24 Sep 2002 12:21:19 GMT
Links: << >>  << T >>  << A >>
IIRC, the Altera-Xilinx deal that allowed cross-patents means Altera can use
the term FPGA instead of CPLD.

-Xanatos

"Leon Heller" <leon_heller@hotmail.com> wrote in message
news:amnbbe$abf$1@paris.btinternet.com...
> I see that Altera is referring to the new Cyclone devices as 'FPGAs'. I
> don't recall them using the term FPGA, before. Is this a new marketing
ploy?
>
> Leon
> --
> Leon Heller, G1HSM
> leon_heller@hotmail.com
> http://www.geocities.com/leon_heller
>
>



Article: 47345
Subject: Re: Handel-C: a bit of a funny 'for loop'
From: "Ashley" <ashley.sutcliffe@celoxica.com>
Date: Tue, 24 Sep 2002 14:13:32 +0100
Links: << >>  << T >>  << A >>
Hi guys,

I tried to post the other day via Google but it failed.

Take a look at the application note that I wrote about loops in Handel-C at
http://www.celoxica.com/products/technical_papers/application_notes/71%20-%2
0Optimisation%20-%20Efficient%20Loops.pdf.

This gives a good explanation of how to write decent loops.

While loops are the way to go as they are more versatile and easier to
understand IMHO.

Cheers

Ashley

"Govind Kharbanda" <govind.kharbanda@sli-institute.ac.uk> wrote in message
news:2f5db38d.0209180701.777672ae@posting.google.com...
> "Alan Fitch" <alan.fitch@doulos.com> wrote in message
news:<k0pFl7kWCHA.4780@lucy.doulos.com>...
> > Firstly, you might want to try this option.
> >
> > A for loop
> >
> >    for (i = 0; i<10; i++)
> >   {
> >      statements;
> >   }
> >
> > can be replaced with
> >
> >   for (i = 0; i < 10) par {
> >     i++;
> >     statements;
> >  }
> >
> > which speeds up the execution of a for loop.
>
> That's something I didn't know... I was always recoding as a 'while'
> loop.  Your solution is much easier to follow.
>
> > Secondly, if you use the value of i inside a nested loop, you need
> > to be very
> > careful to make sure that if you use the outer loop variable in an
> > inner loop,
> > you are using the correct value (because in Handel-C the variables
> > may update
> > in parallel rather than sequentially as in C).
> >
> > <snip complicated code>
> >
>
> I solved this by recoding the loop so a shift is performed on each
> iteration instead of an increment.
>
> I am getting a new problem though concerning calling a macro procedure
> within this complicated loop: see new thread.
>
> > > Also the compiler is throwing up width errors, for instance
> >  width '8'
> > > doesn't match width '4'.  For instance
> > >
> > > while (j<(1<<i))
> > >
>
> I solved this by recoding the loop so a shift is performed on each
> iteration instead of an increment.
>
> > However the value '1' is not known. Try using
> >
> >   while (j < (unsigned 8)(1 << i))
> >
> > or declaring a constant to represent the number 1 of the correct
> > width, e.g.
> >
> > static const unsigned 8 ONE = 1;
> >
> > and then using
> >
> >    ONE << i
> >
>
> I like this idea though - will try and make use of it.
>
> Govind



Article: 47346
Subject: Re: writing across a column in an SDRAM
From: "A. Nelson" <anelson@NS.lumenera.com>
Date: Tue, 24 Sep 2002 09:24:26 -0400
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3D8F9E76.79972BE5@yahoo.com...
> "A. Nelson" wrote:
> >
> > I have an odd problem that I'd like anyone's opinion on.
> >
> > I have a data stream, that I'd like to write into SDRAM (I'm writing my
own
> > controller, so I can do it any way I'd like).  However, I don't want to
> > write across a row (like you're supposed to do, so you can take
advantage of
> > bursting), but rather across a column.
> >
> > This means that every word would go to a different row.  So, every word
> > would require a full write cycle (active, write, precharge).  This is
far
> > too slow.
> >
> > So, I got the idea of "bursting" across the banks (which allows for 4
> > writes, before a precharge), like this:
> >
> > (A=Active, W= write, P = precharge, r=row, b=bank, c=column)
> >
> > A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W
(c
> > 0, b 2), A (r 0, b 3), W (c 0, b 3), P
> >
> > then
> >
> > A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W
(c
> > 0, b 2), A (r 1, b 3), W (c 0, b 3), P
> >
> > and so on (with the required NOPs, to meet timing).
> >
> > I was also considering doing all the actives, then writes, then
precharge
> > (A, A, A, A, W, W, W, W, P).
> >
> > Any other suggestions?
>
> I think you have the right idea.  By doing all the activates
> sequentially, you will minimize the number of noops.  It has been awhile
> since I have done any work with SDRAMs, but I think you can do a
> precharge on one bank at a time.  Not knowing how fast you are planning
> to clock the part, I can't say which way would be faster.
>
> I believe you would have to put noops before and after the single
> precharge.  If you use four bank precharge commands you may not need
> noops at all.  You will need to work out the details based on your clock
> speed and the parts you choose.
>
> Just curious about why you want to write across the columns.  Does it
> have to do with how you are reading the data out?  Are you using the
> SDRAM to permute the data?
>

Why am I writing across the columns?  I'm trying to rotate a rather large
image, 90 degrees.  This way, when the data is read out of the RAM, it can
be read out "normally", and will be rotated.

Because the image is large, I really don't have the space to buffer even a
couple of lines (I could probalby buffer one, but I really don't want to).

Just one more question about SDRAMs:
Trcd is listed as the minimum time between Active and Read/Write.  Now, is
this between ANY Active and Write, or between Active for a specific row/bank
and a write to that same row/bank?  For example, if I do the 4 consecutive
Acitves (which would be for banks 0 to 3 consectutively), followed by 4
writes (again, for banks 0 to 3 consectutively), do I have to wait Trcd
between the LAST Active and the FIRST Write, or Trcd between the FIRST
Active and FIRST Write?

Thanks for everyone's input,
A.

> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX



Article: 47347
Subject: Xilinx: Marking some latches for pass-thru timing
From: Derek Wallace <derek.wallace@s3group.com>
Date: Tue, 24 Sep 2002 14:33:58 +0100
Links: << >>  << T >>  << A >>
Hi All,
I am struggling to define some timing constraints for
a latch based design.

In my design i have a number of latches that i want to mark as "feed thru"
i.e. Xilinx will not use them as an endpoint for timing analysis.

E.g Latch1 -> Latch2 -> Latch3
By default Xilinx timing analysis all treat all 3 Latches as end points.
In my design i want to mark Latch2 as pass-thru so that i can 
apply a constraint from Latch1 THRU Latch2 TO Latch3.

I have tried/observed the following.
1. the ucf supports the following path tracing constraint for Latches
ENABLE = lat_d_q;

This makes ALL latches in the design as pass thru. Not what i want.

2. the COnstraints guide, hints that this ENABLE can be applied to a timegroup.
However it only gives an example for the PCF file
TIMEGRP "name" ENABLE = lat_d_q;

I tried this by changing the PCF, and running the trce engine. It complained 
that the timegroup did not contain any "components"

3. Xilinx supports a FROM THRU TO constraint.
However the THRU points can only be nets or TBUFs.

4. In the Timing Analyzer, when you do a timing analysis,
you can specify individual Latches as been pass thru.

Therefore it should be possible to apply these Path Tracing constraints 
in the UCF.

HAs anyone come across this or have any suggestions?

PS. I cannot analyse Latch1 to Latch2 and Latch2 to Latch3 seperatly.

Thanks
Derek

Article: 47348
Subject: Re: Question about IOB, BUFG, IBUF and IBUG.
From: John <john@tritec.biz>
Date: Tue, 24 Sep 2002 08:35:43 -0700
Links: << >>  << T >>  << A >>
Are the GCLK pins fixed to IBUFG's or can they be directed to IBUF's if GCLK pins are required for inputs instead of clocks?

Article: 47349
Subject: Re: Xilinx: Marking some latches for pass-thru timing
From: John_H <johnhandwork@mail.com>
Date: Tue, 24 Sep 2002 15:38:34 GMT
Links: << >>  << T >>  << A >>
I was trying a latch-based approach recently but luckily found a different way to
use standard registered logic so I didn't have to rely on this troublesome
technique.

First, I thought the lat_d_q was a PCF only constraint.  If it's now available for
use in the UCF then you don't have to partially compile, edit the generated PCF,
and finish the job.  I would've loved that.

WIth the lat_d_q in place, you have the ability to do FROM / TO analysis based on
groups of latches.  You can specify

TIMEGRP TG_LatchesLo = TRASLO LATCHES;
TIMEGRP TG_LatchesHi = TRASHI LATCHES;
TIMESPEC TS_LoHi = FROM TG_LatchesLo TO TG_LatchesHi 5 ns;
TIMESPEC TS_HiLo = FROM TG_LatchesHi TO TG_LatchesLo 5 ns;
TIMESPEC TS_LoLo = FROM TG_LatchesLo TO TG_LatchesLo 10 ns;

I used these before and had good success.  You could specify "LATCHES( Latch1
Latch3 )" instead of just "LATCHES" or in place of the transition selection.  You
should find more on those constraints in the online Constraints Guide.

Good luck.  Latches are great but they're not fun.



Derek Wallace wrote:

> Hi All,
> I am struggling to define some timing constraints for
> a latch based design.
>
> In my design i have a number of latches that i want to mark as "feed thru"
> i.e. Xilinx will not use them as an endpoint for timing analysis.
>
> E.g Latch1 -> Latch2 -> Latch3
> By default Xilinx timing analysis all treat all 3 Latches as end points.
> In my design i want to mark Latch2 as pass-thru so that i can
> apply a constraint from Latch1 THRU Latch2 TO Latch3.
>
> I have tried/observed the following.
> 1. the ucf supports the following path tracing constraint for Latches
> ENABLE = lat_d_q;
>
> This makes ALL latches in the design as pass thru. Not what i want.
>
> 2. the COnstraints guide, hints that this ENABLE can be applied to a timegroup.
> However it only gives an example for the PCF file
> TIMEGRP "name" ENABLE = lat_d_q;
>
> I tried this by changing the PCF, and running the trce engine. It complained
> that the timegroup did not contain any "components"
>
> 3. Xilinx supports a FROM THRU TO constraint.
> However the THRU points can only be nets or TBUFs.
>
> 4. In the Timing Analyzer, when you do a timing analysis,
> you can specify individual Latches as been pass thru.
>
> Therefore it should be possible to apply these Path Tracing constraints
> in the UCF.
>
> HAs anyone come across this or have any suggestions?
>
> PS. I cannot analyse Latch1 to Latch2 and Latch2 to Latch3 seperatly.
>
> Thanks
> Derek




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search