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 116475

Article: 116475
Subject: Re: Altera PowerPlay Power estimation
From: mvaria@gmail.com
Date: 9 Mar 2007 11:26:18 -0800
Links: << >>  << T >>  << A >>
On Feb 27, 1:02 pm, "AG" <a...@tb.fr> wrote:
> Hi,
>
> I am trying to evaluate the power consumption of one of my design. But
> the powerplay power analyser keeps telling me that the metric
> confidency is low, because much of the toggle rates are vectorless
> estimated (not computed based on real signal activities).
> Though, all the toggle rates should come from my VCD file (value
> change dump file) that I fill with Modelsim simulation. In the
> powerplay power analyser's report, I can see each signal, and wether
> its toggle rate has been estimated, or computed using the vcd file.
> Here is an exemple of what I can read :
>
> mat_correl:matcorrel|mul_mgc_mul_pipe_1_z_oreg[0]
> Combinational cell        Simulation file1mat_correl:matcorrel|mul_mgc_mul_pipe_1_z_oreg[0]~feeder
> Combinational cell        Vectorless estimation
>
> I can trace back the first signal in my design, even in modelsim with
> a
>
> find signals *pipe_1_z_oreg*
>
> But I don't find any signal with "feeder" in the name. If someone
> could explain me why Quartus adds "ghost" signals with ~feeder at the
> end, it would help. I have the same problem with RTL or gate level
> simulation. Quartus 6.0 or 6.1.
>
> many thanks in advance,
>
> Alexandre.

Hi Alexandre,

The ~feeder cells are wire LUTs that Quartus introduces to allow
either faster delivery of the data to the register or extra routing
flexibility.  In a gate level simulation, these extra node will be
simulated, and you should get high confidence from the Quartus
PowerPlay Power Analyzer.

You should be able to see both the original signal and the ~feeder
signals in the ModelSim simulation if you have compiled the gate level
netlist (.vo or .vho).  This netlist is output by the Quartus EDA
Netlist Writer.  In this gate-level flow, if all of the appropriate
simulation signals are dumped to the VCD file (and you can use the
Quartus generated TCL script for this purpose), you should obtain a
high confidence rating in the PowerPlay Power Analyzer.

If you are using RTL level simulation (where you are compiling your
source code in ModelSim as opposed to using the gate-level netlist
produced by Quartus), then these ~feeder signals will not be
simulated.  Actually, in an RTL level simulation, the Quartus
PowerPlay Power Analyzer will only retrieve register and I/O signal
activities, and the signal activities for the remaining combinational
nodes will be filled in by vectorless estimation.  This may be the
issue you are having.

I hope this helps, and please let me know if you have further
questions,
Meghal


Article: 116476
Subject: Re: Xilinx Platform cable USB and impact on linux without windrvr
From: "Grant Likely" <glikely@gmail.com>
Date: 9 Mar 2007 11:27:17 -0800
Links: << >>  << T >>  << A >>
On Feb 24, 6:22 pm, Michael Gernoth <m...@gernoth.net> wrote:
> Hello,
> Please report back if this library is useful and works for you.
> Maybe this helpsXILINXto decide that they do not need to use windrvr
> for easy USB access, as most parts of my library are only there to
> provide a compatible replacement for windrvr functions and are not
> needed when directly accessing libusb from within an application
> program.

Brilliant!  Seems to work for me.  I can't test it fully right now
because impact complains with "ERROR:iMPACT:583 - '2': The idcode read
from the device does not match the idcode in the bsdl File." when I
try to download to my ml403 board (which happens when I use the kernel
driver too).  But it correctly scans the JTAG chain and reports back
the number/type of devices.

I wasn't able to get it to work on an x86_64 system, but in a i386
chroot I had no problems.

Have you passed on your utility to anyone at Xilinx?

Cheers,
g.


Article: 116477
Subject: XST 9.1 hates VHDL character types
From: "Andy Peters" <google@latke.net>
Date: 9 Mar 2007 11:53:10 -0800
Links: << >>  << T >>  << A >>
Under ISE 7.1, I did a simple UART module that has a "terminating
character" generic, which is of type character.  (When the receiver
sees that terminating character, it asserts a "got terminator" output
flag.)  XST compiled it and the design works well.

I moved to 9.1, and now XST hates the code and craps out:

=========================================================================
*                     Design Hierarchy
Analysis                         *
=========================================================================
Analyzing hierarchy for entity <atesttop> in library <work>
(architecture <toplevel>) with generics.
	BAUDDIV = 27

Analyzing hierarchy for entity <processor> in library <work>
(architecture <proc>) with generics.
	BAUDDIV = 27
ERROR:Xst - Xst_HdlConst_Utility::BitVector2Const : invalid type
(char).
ERROR:Xst - Xst_Graph2Hdl::CreateConstSource : not implemented yet for
no-type.
ERROR:Xst:2683 - Unexpected error found while building hierarchy.
-->
=========================================================================

So ... why the step backwards?

Arrrrrrgh.

-a


Article: 116478
Subject: Re: XST 9.1 hates VHDL character types
From: "Andy Peters" <google@latke.net>
Date: 9 Mar 2007 12:01:38 -0800
Links: << >>  << T >>  << A >>
On Mar 9, 12:53 pm, "Andy Peters" <goo...@latke.net> wrote:
> Under ISE 7.1, I did a simple UART module that has a "terminating
> character" generic, which is of type character.  (When the receiver
> sees that terminating character, it asserts a "got terminator" output
> flag.)  XST compiled it and the design works well.
>
> I moved to 9.1, and now XST hates the code and craps out:
>
> =========================================================================
> *                     Design Hierarchy
> Analysis                         *
> =========================================================================
> Analyzing hierarchy for entity <atesttop> in library <work>
> (architecture <toplevel>) with generics.
>         BAUDDIV = 27
>
> Analyzing hierarchy for entity <processor> in library <work>
> (architecture <proc>) with generics.
>         BAUDDIV = 27
> ERROR:Xst - Xst_HdlConst_Utility::BitVector2Const : invalid type
> (char).
> ERROR:Xst - Xst_Graph2Hdl::CreateConstSource : not implemented yet for
> no-type.
> ERROR:Xst:2683 - Unexpected error found while building hierarchy.
> -->
> =========================================================================
>
> So ... why the step backwards?
>
> Arrrrrrgh.
>
> -a

Replying to myself:

OK, so I went through and removed all of the generics of type
character, and in the module where the generic is actually used, I
created a constant of type character.  XST accepts that and the code
built.

So, once upon a time (7.1i) you could use a character type as a
generic.  Now (9.1i), you can't.  Still a step backwards.  Arrrrgh.

-a



Article: 116479
Subject: Re: Xilin X-Fest Lunacy
From: "Peter Alfke" <peter@xilinx.com>
Date: 9 Mar 2007 12:03:58 -0800
Links: << >>  << T >>  << A >>
Not being able to find the silly text on the Avnet website, I googled
and found this "Model Release"
MODEL RELEASE
      For good and valuable consideration, receipt of which I hereby
acknowledge, I grant Avnet, Inc. ("Avnet"), its affiliates,
subsidiaries, assigns, licensees, and designees, the irrevocable right
to use my name, picture, likeness and/or photograph, and biographical
information (collectively the "Materials") in all forms and media now
known or hereafter developed, and in all manners, including composite
or distorted representations,
........and so on, ad nauseam.

I believe this has nothing to do with the seminar, but I cannot attack
the issue unless I can pinpoint it to the registration.
Which I have been unable to do.
Peter Alfke

On Mar 9, 10:56 am, "Peter Alfke" <p...@xilinx.com> wrote:
> As the Bard of Avon wrote in Henry VI:
> "JACK CADE.
> I thank you, good people:- there shall be no money; all shall eat and
> drink on my score; and I will apparel them all in one livery, that
> they may agree like brothers, and worship me their lord.
>
> DICK.
> The first thing we do, let's kill all the lawyers."
>
> Peter Alfke, speaking for himself  ;-)
> =============================
> On Mar 9, 5:04 am, "MK" <nos...@please.com> wrote:
>
> > I just got an invitation to this years SIlica/Xilinx X-fest.
>
> > I've been to these before and found them useful so I was registering to
> > attend until I came to this bit:
>
> > I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns,
> > licensees, and design irrevocable right to use my name, picture, likeness
> > and/or photograph, and biography information ( collectively the "materials")
> > in all forms and media now known or hereby developed, and in all manners,
> > including composite or distorted representations, for marketing, trade,
> > editorial, and any other purposes whatsoever. I waive any right to approve
> > any uses that may be created in connection therewith, or the use to which
> > Materials may be applied. I agree that the Materials, the negatives, and
> > other originals shall constitute Avnet's sole property, with full right of
> > disposition in any manner whatsoever. I hereby release, discharge, and agree
> > to hold harmless Avnet, its affiliates, subsidiaries, assigns, licensees,
> > and designees, and all persons acting under its permission or anyone from
> > any and all claims whatsoever in connection with the use of the materials. I
> > have read the release and am fully familiar with its contents.
>
> > I choked on that so I'll stick with Lattice for another design or two.
>
> > Michael Kellett
>
> >www.mkesc.co.uk



Article: 116480
Subject: Re: Routing problem of DCM
From: "Rebecca" <pang.dudu.pang@hotmail.com>
Date: 9 Mar 2007 12:06:57 -0800
Links: << >>  << T >>  << A >>
Thanks for all your help.
The problem has been fixed. The reason is that EDK didn't take the
modified VHDL code. I need to remove the content in synthesis or
implementation directory ( i removed both, but probably we just remove
the content under the implementation directory).
And another thing is the EDK won't copy the files under the
directory.. user defined core....-> netlist to the implementation
directory automatically as said in the manual. I
I have to copy them manually. Probably I made another stupid mistake?
Bill, I added the BUFG for the locked signal because I found in the
Modelsim simulation, sometimes the generated clocks can't sample the
locked signal at its first rising edge but sometimes they can. I used
the following code in my program:

NextStateProc : Process(ClkX3, DCMLocked) is
begin
	if(DCMLocked='0') then
		CLKState <= CLK0;
	elsif(rising_edge(ClkX3)) then
			CLKState <= NextClkState;
	end if;
end process NextStateProc;

There are other DCMs in my system to generated different clock
frequency and use such kinds of code for different states. They are
all synchronized. Although the generated clock shouldn't be able to
sample locked as high at its first rising edge because locked signal
is also synchronized with the input clock as said in the manual,
sometime they can. So I add the global buffer to solve the problem and
it worked.

Daniel said something about "instantiating costs a few extra lines but
after that, you'll
never have to worry about them mysteriously disappearing again.".  I
am sorry I don't understand how to do the instantiation, so I just set
up the environment variables. Would you please talk more about that?

Again, Thanks for all your response,
Rebecca




Article: 116481
Subject: Any Western NC VHDL Designers?
From: Hawker <Hawker{removethispart}@ashevillecommunity.org>
Date: Fri, 09 Mar 2007 17:06:25 -0500
Links: << >>  << T >>  << A >>
Is there anyone on this list looking for side work who lives in Western 
NC or possibly Eastern TN, North Western SC?

Please enquirer directly to Rick at ashevillecommunity dot org. Include 
resume' and salary requirements.  If you can't make a drive to Asheville 
in a few hours then I am not interested and you need not reply.

This will be contract work as needed. There currently is a CPLD project 
that needs to be done and others are coming up this year.

Rick

Article: 116482
Subject: Re: Xilin X-Fest Lunacy
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: 9 Mar 2007 15:09:02 -0800
Links: << >>  << T >>  << A >>
I can confirm that.

Click on "register now", "EMEA", "register now" and enter your name
and email and select "Wiesbaden".

I can also confirm that selecting the button is required to register.

Kolja Sulimma

On Mar 9, 9:03 pm, "Peter Alfke" <p...@xilinx.com> wrote:
> Not being able to find the silly text on the Avnet website, I googled
> and found this "Model Release"
> MODEL RELEASE
>       For good and valuable consideration, receipt of which I hereby
> acknowledge, I grant Avnet, Inc. ("Avnet"), its affiliates,
> subsidiaries, assigns, licensees, and designees, the irrevocable right
> to use my name, picture, likeness and/or photograph, and biographical
> information (collectively the "Materials") in all forms and media now
> known or hereafter developed, and in all manners, including composite
> or distorted representations,
> ........and so on, ad nauseam.
>
> I believe this has nothing to do with the seminar, but I cannot attack
> the issue unless I can pinpoint it to the registration.
> Which I have been unable to do.
> Peter Alfke
>
> On Mar 9, 10:56 am, "Peter Alfke" <p...@xilinx.com> wrote:
>
> > As the Bard of Avon wrote in Henry VI:
> > "JACK CADE.
> > I thank you, good people:- there shall be no money; all shall eat and
> > drink on my score; and I will apparel them all in one livery, that
> > they may agree like brothers, and worship me their lord.
>
> > DICK.
> > The first thing we do, let's kill all the lawyers."
>
> > Peter Alfke, speaking for himself  ;-)
> > =============================
> > On Mar 9, 5:04 am, "MK" <nos...@please.com> wrote:
>
> > > I just got an invitation to this years SIlica/Xilinx X-fest.
>
> > > I've been to these before and found them useful so I was registering to
> > > attend until I came to this bit:
>
> > > I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns,
> > > licensees, and design irrevocable right to use my name, picture, likeness
> > > and/or photograph, and biography information ( collectively the "materials")
> > > in all forms and media now known or hereby developed, and in all manners,
> > > including composite or distorted representations, for marketing, trade,
> > > editorial, and any other purposes whatsoever. I waive any right to approve
> > > any uses that may be created in connection therewith, or the use to which
> > > Materials may be applied. I agree that the Materials, the negatives, and
> > > other originals shall constitute Avnet's sole property, with full right of
> > > disposition in any manner whatsoever. I hereby release, discharge, and agree
> > > to hold harmless Avnet, its affiliates, subsidiaries, assigns, licensees,
> > > and designees, and all persons acting under its permission or anyone from
> > > any and all claims whatsoever in connection with the use of the materials. I
> > > have read the release and am fully familiar with its contents.
>
> > > I choked on that so I'll stick with Lattice for another design or two.
>
> > > Michael Kellett
>
> > >www.mkesc.co.uk



Article: 116483
Subject: Re: Xilin X-Fest Lunacy
From: "Peter Alfke" <peter@xilinx.com>
Date: 9 Mar 2007 15:43:21 -0800
Links: << >>  << T >>  << A >>
Thanks, I found it, and I have sent a very strong letter (including
the word "crazy") to three layers of Xilinx management. Let's see
whether it helps. This is not only silly, it is stupid.
Let's assume that it gets removed, pronto!
Shakespeare was right.
Peter Alfke
P.S. See you in Wiesbaden, Kolja.
=========================================================
On Mar 9, 3:09 pm, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> I can confirm that.
>
> Click on "register now", "EMEA", "register now" and enter your name
> and email and select "Wiesbaden".
>
> I can also confirm that selecting the button is required to register.
>
> Kolja Sulimma
>
> On Mar 9, 9:03 pm, "Peter Alfke" <p...@xilinx.com> wrote:
>
> > Not being able to find the silly text on the Avnet website, I googled
> > and found this "Model Release"
> > MODEL RELEASE
> >       For good and valuable consideration, receipt of which I hereby
> > acknowledge, I grant Avnet, Inc. ("Avnet"), its affiliates,
> > subsidiaries, assigns, licensees, and designees, the irrevocable right
> > to use my name, picture, likeness and/or photograph, and biographical
> > information (collectively the "Materials") in all forms and media now
> > known or hereafter developed, and in all manners, including composite
> > or distorted representations,
> > ........and so on, ad nauseam.
>
> > I believe this has nothing to do with the seminar, but I cannot attack
> > the issue unless I can pinpoint it to the registration.
> > Which I have been unable to do.
> > Peter Alfke
>
> > On Mar 9, 10:56 am, "Peter Alfke" <p...@xilinx.com> wrote:
>
> > > As the Bard of Avon wrote in Henry VI:
> > > "JACK CADE.
> > > I thank you, good people:- there shall be no money; all shall eat and
> > > drink on my score; and I will apparel them all in one livery, that
> > > they may agree like brothers, and worship me their lord.
>
> > > DICK.
> > > The first thing we do, let's kill all the lawyers."
>
> > > Peter Alfke, speaking for himself  ;-)
> > > =============================
> > > On Mar 9, 5:04 am, "MK" <nos...@please.com> wrote:
>
> > > > I just got an invitation to this years SIlica/Xilinx X-fest.
>
> > > > I've been to these before and found them useful so I was registering to
> > > > attend until I came to this bit:
>
> > > > I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns,
> > > > licensees, and design irrevocable right to use my name, picture, likeness
> > > > and/or photograph, and biography information ( collectively the "materials")
> > > > in all forms and media now known or hereby developed, and in all manners,
> > > > including composite or distorted representations, for marketing, trade,
> > > > editorial, and any other purposes whatsoever. I waive any right to approve
> > > > any uses that may be created in connection therewith, or the use to which
> > > > Materials may be applied. I agree that the Materials, the negatives, and
> > > > other originals shall constitute Avnet's sole property, with full right of
> > > > disposition in any manner whatsoever. I hereby release, discharge, and agree
> > > > to hold harmless Avnet, its affiliates, subsidiaries, assigns, licensees,
> > > > and designees, and all persons acting under its permission or anyone from
> > > > any and all claims whatsoever in connection with the use of the materials. I
> > > > have read the release and am fully familiar with its contents.
>
> > > > I choked on that so I'll stick with Lattice for another design or two.
>
> > > > Michael Kellett
>
> > > >www.mkesc.co.uk



Article: 116484
Subject: Re: Spartan3AN - Roadmap - bigger questions may prevail...
From: Eric Smith <eric@brouhaha.com>
Date: 09 Mar 2007 17:28:32 -0800
Links: << >>  << T >>  << A >>
John McCaskill wrote:
> After all, hafnium is only half as good as unobtanium

Sure, but it's considerably less than half as expensive.

Article: 116485
Subject: Addressing scheme in Block RAM
From: "Venu" <get2venu@gmail.com>
Date: 9 Mar 2007 22:44:24 -0800
Links: << >>  << T >>  << A >>
Hi People,

I have generated a duap port RAM using a Xilinx Core generator .
Port A is 32 x 32 and Port B is 8 x 128

The 32 bit port , Port A , is interpreting the addresses in the row
order
00
01
02
.
.
.
1F


I had expected the 8 bit port to also interpret the addresses in the
row order. I have done the simulation of the DPRAM and this was it
responded as expected.

03    02    01    00
07    06    05    04
.........................
7F    7E    7D   7C


But now comes the weird part . I implemented my design on a Xilinx
Virtex - 2 Pro FPGA , the 8 bit port is interpreting the addresses in
the column order ,. I have observed this using debug data as well as
using Chip Scope Pro,  i.e.

60    40    20    00
61    41    21    01
62    42    22    02
63    43    23    03
.
7F    5F    3F   1F

Are there any synthesis constraints that can prevent this from
happening . All the documents and application notes say that the 8 bit
port also should be addressed in the row ordering fashion. Could any
one suggest why I might be having this problem


Thank You
Venu


Article: 116486
Subject: Re: Driving PLL from general I/O in Altera Cyclone
From: "Rob" <robnstef@frontiernet.net>
Date: Sat, 10 Mar 2007 15:57:22 GMT
Links: << >>  << T >>  << A >>
Have you read chapter 10 in the Cyclone Device Handbook?  "Implementing 
Double Data Rate I/O Signaling Cyclone Devices" You are using a Cyclone and 
not Cyclone2, correct?


"nfirtaps" <lloyd.rochester@gmail.com> wrote in message 
news:1173457175.663323.155840@j27g2000cwj.googlegroups.com...
> On Mar 8, 9:27 pm, "Rob" <robns...@frontiernet.net> wrote:
>> If your input clock is not on the global clock network you will be 
>> fighting
>> with clock skew to the flops.  When your clock edges are happening with
>> respect to the data at the flops becomes an utmost concern for you.
>>
>> "nfirtaps" <lloyd.roches...@gmail.com> wrote in message
>
>
>
>>
>> news:1173383894.763347.110110@64g2000cwx.googlegroups.com...
>>
>> >I am trying to deserialize a DDR signal in my Cyclone.  For reasons I
>> > won't go into the DDR clock comes in off a general purpose I/O pin.  I
>> > need a way of deserializing this signal, and want to increase the
>> > frequency of the DDR clock by 2 so I can use rising edge flip-flops.
>>
>> > 1.) Can I somehow drive a PLL with a general purpose I/O
>> > 2.) Is there another way of deserializing the DDR signal.
>>
>> > Currently I have a the DDR clock coming in my fpga and I not the clock
>> > so I can sample the DDR signal on the rising egde.
>>
>> > Thanks
>
> As for the clock not being part of the global clock network, Quartus
> gives me the following message "Info: Automatically promoted signal
> "dco" to use Global clock in PIN 29"  so I guess my clock is put into
> the global network.
> 



Article: 116487
Subject: Re: Addressing scheme in Block RAM
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 10 Mar 2007 09:42:16 -0800
Links: << >>  << T >>  << A >>
Venu, on a single-port memory you can scramble the address lines
anyway you want.
But with two ports you must be more careful in order to be consistent.
Look at Table 2-12 in the BlockRAM section, it's on page 210 in my
printed copy.
That should help you untangle the address lines.
Peter Alfke, from home.
==============================
On Mar 9, 10:44 pm, "Venu" <get2v...@gmail.com> wrote:
> Hi People,
>
> I have generated a duap port RAM using a Xilinx Core generator .
> Port A is 32 x 32 and Port B is 8 x 128
>
> The 32 bit port , Port A , is interpreting the addresses in the row
> order
> 00
> 01
> 02
> .
> .
> .
> 1F
>
> I had expected the 8 bit port to also interpret the addresses in the
> row order. I have done the simulation of the DPRAM and this was it
> responded as expected.
>
> 03    02    01    00
> 07    06    05    04
> .........................
> 7F    7E    7D   7C
>
> But now comes the weird part . I implemented my design on a Xilinx
> Virtex - 2 Pro FPGA , the 8 bit port is interpreting the addresses in
> the column order ,. I have observed this using debug data as well as
> using Chip Scope Pro,  i.e.
>
> 60    40    20    00
> 61    41    21    01
> 62    42    22    02
> 63    43    23    03
> .
> 7F    5F    3F   1F
>
> Are there any synthesis constraints that can prevent this from
> happening . All the documents and application notes say that the 8 bit
> port also should be addressed in the row ordering fashion. Could any
> one suggest why I might be having this problem
>
> Thank You
> Venu



Article: 116488
Subject: Re: Addressing scheme in Block RAM
From: John_H <newsgroup@johnhandwork.com>
Date: Sat, 10 Mar 2007 19:39:14 GMT
Links: << >>  << T >>  << A >>
Peter's reference may point you to the same conclusion you started with. 
  The only thing I could see as a problem would show up in simulation as 
well: using bit-reversed addresses such as "reg [0:10] Addr8;" with 
confusion for bits 0,1.  (The sample dimensions are for an 18 kbit 
BlockRAM.)

If you use [10:0] style addressing, you're correct that a write to 
address 9'h0 on the 32-bit side of 32'h12345678 should give you read 
values on the first 4 addresses on the 8-bit side of

address 11'h0: 8'h78
address 11'h1: 8'h56
address 11'h2: 8'h34
address 11'h3: 8'h12

If your target is BlockRAM, consider instantiating the BlockRAM 
primitive rather than the Coregen module to see if the problem clears 
up.  The RAMB16_S9_S36 primitive would give you the aspect ratios you need.

If your target is distributed memory, there's a slight chance that the 
Coregen isn't "doing the right thing" since the asymmetric ports may be 
rarely used with the CLB SelectRAM.

You could also check the post-route simulation to see if it matches the 
live silicon.

- John_H


Venu wrote:
> Hi People,
> 
> I have generated a dual port RAM using a Xilinx Core generator .
> Port A is 32 x 32 and Port B is 8 x 128
> 
> The 32 bit port , Port A , is interpreting the addresses in the row
> order
> 00
> 01
> 02
> .
> .
> .
> 1F
> 
> 
> I had expected the 8 bit port to also interpret the addresses in the
> row order. I have done the simulation of the DPRAM and this was it
> responded as expected.
> 
> 03    02    01    00
> 07    06    05    04
> .........................
> 7F    7E    7D   7C
> 
> 
> But now comes the weird part . I implemented my design on a Xilinx
> Virtex - 2 Pro FPGA , the 8 bit port is interpreting the addresses in
> the column order ,. I have observed this using debug data as well as
> using Chip Scope Pro,  i.e.
> 
> 60    40    20    00
> 61    41    21    01
> 62    42    22    02
> 63    43    23    03
> .
> 7F    5F    3F   1F
> 
> Are there any synthesis constraints that can prevent this from
> happening . All the documents and application notes say that the 8 bit
> port also should be addressed in the row ordering fashion. Could any
> one suggest why I might be having this problem
> 
> 
> Thank You
> Venu

Article: 116489
Subject: ddr sdram controller
From: dhruvakshad@gmail.com
Date: 10 Mar 2007 12:44:35 -0800
Links: << >>  << T >>  << A >>
How can I get a ddr sdram  controller for the MT46V16M16TG -75 micron
chip.
I want a controller without  the plb or opb interface. I tried open
cores.org but it says that the repository is empty with no files
pertaining to the ddrsdram controller core.
Could someone give me right pointers?
Thanks,
D.


Article: 116490
Subject: Re: ddr sdram controller
From: "Icky Thwacket" <it@it.it>
Date: Sat, 10 Mar 2007 21:32:07 -0000
Links: << >>  << T >>  << A >>

<dhruvakshad@gmail.com> wrote in message 
news:1173559475.001130.307290@v33g2000cwv.googlegroups.com...
> How can I get a ddr sdram  controller for the MT46V16M16TG -75 micron
> chip.
> I want a controller without  the plb or opb interface. I tried open
> cores.org but it says that the repository is empty with no files
> pertaining to the ddrsdram controller core.
> Could someone give me right pointers?
> Thanks,
> D.
>

Easiest way is to download data sheet from Micron site and put it together 
yourself. I recently put together a controller for the Micron MT48H4M16LF 
mobile SDRAM which will be similar. Took about a day to put together via 
schematics and simulated. I imagine a Verilog/VHDL whizz could do it a lot 
quicker. 



Article: 116491
Subject: Re: Xilin X-Fest Lunacy
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 10 Mar 2007 16:09:43 -0800
Links: << >>  << T >>  << A >>
Rest assured that the offensive paragraph will be killed.
I don't know what happens to the offending lawyer...  ;-)
Peter Alfke, from home



On Mar 9, 3:43 pm, "Peter Alfke" <p...@xilinx.com> wrote:
> Thanks, I found it, and I have sent a very strong letter (including
> the word "crazy") to three layers of Xilinx management. Let's see
> whether it helps. This is not only silly, it is stupid.
> Let's assume that it gets removed, pronto!
> Shakespeare was right.
> Peter Alfke
> P.S. See you in Wiesbaden, Kolja.
> =========================================================
> On Mar 9, 3:09 pm, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
>
> > I can confirm that.
>
> > Click on "register now", "EMEA", "register now" and enter your name
> > and email and select "Wiesbaden".
>
> > I can also confirm that selecting the button is required to register.
>
> > Kolja Sulimma
>
> > On Mar 9, 9:03 pm, "Peter Alfke" <p...@xilinx.com> wrote:
>
> > > Not being able to find the silly text on the Avnet website, I googled
> > > and found this "Model Release"
> > > MODEL RELEASE
> > >       For good and valuable consideration, receipt of which I hereby
> > > acknowledge, I grant Avnet, Inc. ("Avnet"), its affiliates,
> > > subsidiaries, assigns, licensees, and designees, the irrevocable right
> > > to use my name, picture, likeness and/or photograph, and biographical
> > > information (collectively the "Materials") in all forms and media now
> > > known or hereafter developed, and in all manners, including composite
> > > or distorted representations,
> > > ........and so on, ad nauseam.
>
> > > I believe this has nothing to do with the seminar, but I cannot attack
> > > the issue unless I can pinpoint it to the registration.
> > > Which I have been unable to do.
> > > Peter Alfke
>
> > > On Mar 9, 10:56 am, "Peter Alfke" <p...@xilinx.com> wrote:
>
> > > > As the Bard of Avon wrote in Henry VI:
> > > > "JACK CADE.
> > > > I thank you, good people:- there shall be no money; all shall eat and
> > > > drink on my score; and I will apparel them all in one livery, that
> > > > they may agree like brothers, and worship me their lord.
>
> > > > DICK.
> > > > The first thing we do, let's kill all the lawyers."
>
> > > > Peter Alfke, speaking for himself  ;-)
> > > > =============================
> > > > On Mar 9, 5:04 am, "MK" <nos...@please.com> wrote:
>
> > > > > I just got an invitation to this years SIlica/Xilinx X-fest.
>
> > > > > I've been to these before and found them useful so I was registering to
> > > > > attend until I came to this bit:
>
> > > > > I grant Avnet, Inc. (avnet), its affiliates, subsidiaries, assigns,
> > > > > licensees, and design irrevocable right to use my name, picture, likeness
> > > > > and/or photograph, and biography information ( collectively the "materials")
> > > > > in all forms and media now known or hereby developed, and in all manners,
> > > > > including composite or distorted representations, for marketing, trade,
> > > > > editorial, and any other purposes whatsoever. I waive any right to approve
> > > > > any uses that may be created in connection therewith, or the use to which
> > > > > Materials may be applied. I agree that the Materials, the negatives, and
> > > > > other originals shall constitute Avnet's sole property, with full right of
> > > > > disposition in any manner whatsoever. I hereby release, discharge, and agree
> > > > > to hold harmless Avnet, its affiliates, subsidiaries, assigns, licensees,
> > > > > and designees, and all persons acting under its permission or anyone from
> > > > > any and all claims whatsoever in connection with the use of the materials. I
> > > > > have read the release and am fully familiar with its contents.
>
> > > > > I choked on that so I'll stick with Lattice for another design or two.
>
> > > > > Michael Kellett
>
> > > > >www.mkesc.co.uk



Article: 116492
Subject: Re: Addressing scheme in Block RAM
From: Ben Jackson <ben@ben.com>
Date: Sat, 10 Mar 2007 19:02:50 -0600
Links: << >>  << T >>  << A >>
On 2007-03-10, Venu <get2venu@gmail.com> wrote:
>
> I have generated a duap port RAM using a Xilinx Core generator .
> Port A is 32 x 32 and Port B is 8 x 128

I saw a problem recently where the behavior of the narrower port
changed depending on which coregen was used.  I know one of the IP
modules was called "Dual Port something" and the other was more general
and included dual port support.  If that's not enough to put you on
the trail I can try to find the exact names.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 116493
Subject: Re: Addressing scheme in Block RAM
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 10 Mar 2007 18:21:11 -0800
Links: << >>  << T >>  << A >>
It looks to me that you use the second bit position in the upper
nibble (you call it 20) as your least significant bit... I am sure
this is just an address-bit ordering problem.
Please tell us when you got this straightened out.
Peter Alfke, from home
==========
On Mar 9, 10:44 pm, "Venu" <get2v...@gmail.com> wrote:
> Hi People,
>
> I have generated a duap port RAM using a Xilinx Core generator .
> Port A is 32 x 32 and Port B is 8 x 128
>
> The 32 bit port , Port A , is interpreting the addresses in the row
> order
> 00
> 01
> 02
> .
> .
> .
> 1F
>
> I had expected the 8 bit port to also interpret the addresses in the
> row order. I have done the simulation of the DPRAM and this was it
> responded as expected.
>
> 03    02    01    00
> 07    06    05    04
> .........................
> 7F    7E    7D   7C
>
> But now comes the weird part . I implemented my design on a Xilinx
> Virtex - 2 Pro FPGA , the 8 bit port is interpreting the addresses in
> the column order ,. I have observed this using debug data as well as
> using Chip Scope Pro,  i.e.
>
> 60    40    20    00
> 61    41    21    01
> 62    42    22    02
> 63    43    23    03
> .
> 7F    5F    3F   1F
>
> Are there any synthesis constraints that can prevent this from
> happening . All the documents and application notes say that the 8 bit
> port also should be addressed in the row ordering fashion. Could any
> one suggest why I might be having this problem
>
> Thank You
> Venu



Article: 116494
Subject: Re: ddr sdram controller
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Sat, 10 Mar 2007 22:42:13 -0500
Links: << >>  << T >>  << A >>
dhruvakshad@gmail.com wrote:
> How can I get a ddr sdram  controller for the MT46V16M16TG -75 micron
> chip.
> I want a controller without  the plb or opb interface. I tried open
> cores.org but it says that the repository is empty with no files
> pertaining to the ddrsdram controller core.
> Could someone give me right pointers?
> Thanks,
> D.

I read a few reports about that controller, it seemed to be a rather low-performance 
option. You could look into Xilinx's MIG, that could help to get you started - I started 
building my own 200MHz DDR controller to interface with a 256MB PC3200 DIMM and I use an 
MIG design as a reference when I need inspiration. Again, I am not using the MIG either 
since I have seen mixed feedback about it. I too would be interested in hearing about 
existing open-source, preferably high-bandwidth, DDR controllers.

Right now, I am expecting the my controller to consume about 44 of 144 BRAMs (ouch!) and 
at least 3000 of 13.6k slices on my XC2VP30-7. Things would be much simpler if I had V5s 
instead. I am doing this mostly because I have always been pretty far from IOBs in my 
previous FPGA/ASIC jobs. Since knowledge of DDR/DDR2 is often a must for the jobs I am 
interested in, I decided to try building a full-blown DDR controller - I'll most likely 
downscale it for actual use though.

Since your device is only 16bits wide, things should be much simpler and you should have 
many more options than I do. If you browse OpenCore's CVS directory, you will find many 
SDR-SDRAM controllers that may be nearly suitable for your application - you should be 
able to modify one of the many SDR controllers for DDR operation by doing little more than 
changing the IOB FFs and widening data buses as necessary. Note: they appear to all be 
verilog.

BTW, all DDR-SDRAM devices are pretty much the same, there should be no need to request 
one for a specific device. All you need to do is connect a generic DDR controller to a 
suitable clock and modify the controller to match the CAS/RAS and other latency 
requirements of your specific device for the selected operating frequency.

Article: 116495
Subject: Re: odd warning in Xilinx ISE webpack
From: None <none@nowhere.net>
Date: Sat, 10 Mar 2007 23:01:56 -0500
Links: << >>  << T >>  << A >>
On Thu, 8 Mar 2007 10:42:14 -0800, "davide" <davide@xilinx.com> wrote:

>Steve,
>
>Can you tell me a little bit more about what device you are targeting and 
>the version of WebPACK you are using.  Are you using any multiplier blocks 
>or doing any multiplication operations and pipelining the output?
>
>-David


I just installed 9.1 (was using 7.1).  I got the same warning.
Spartan II, no multipliers, no pipelining.

Dan



>
>
>
>"Steve Battazzo" <thesteveman_ice9@yahoo.co.jp> wrote in message 
>news:m6KdnZIfoIUuVnLYnZ2dnUVZ_rmdnZ2d@comcast.com...
>> At the XST-synthesize stage, I'm getting this weird warning:
>> "Property use_dsp48" is not applicable for this technology.
>> I don't have anything in my code that I know of that calls for any such 
>> thing.. it doesn't affect the program actually running on my board, but 
>> I'm curious anyway.
>>
>> Anyone know what this means?
>>
>> Thanks,
>>
>> Steve 
>


Article: 116496
Subject: Are FPGAs go enough for clock dstribution
From: Ben Popoola <ben.popoola@REMOVE.recontech.co.uk>
Date: Sun, 11 Mar 2007 05:15:04 GMT
Links: << >>  << T >>  << A >>
Hi,
I have a PCB design with a FPGA and other devices that require a clock 
input. Is it a good idea to first feed a single clock into the FPGA and 
then through the FPGA distribute this clock to the other devices?

Ben

Article: 116497
Subject: Re: Are FPGAs go enough for clock dstribution
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sun, 11 Mar 2007 18:34:07 +1300
Links: << >>  << T >>  << A >>
Ben Popoola wrote:
> Hi,
> I have a PCB design with a FPGA and other devices that require a clock 
> input. Is it a good idea to first feed a single clock into the FPGA and 
> then through the FPGA distribute this clock to the other devices?

a) Do the other devices need their clocks before the FPGA is finished 
Config ?
b) Is added jitter on the clock a significant concern ?
c) Do you have power save modes, where the FPGA is deprecated ?

If not, then is _is_ nice and flexible to route the clocks thru the 
FPGA, as ytou can do what you like with them later....

-jg


Article: 116498
Subject: Re: How best do I implement routing boxes in RTL?
From: "jtw" <wrightjt @hotmail.invalid>
Date: Sun, 11 Mar 2007 05:44:56 GMT
Links: << >>  << T >>  << A >>
I have had similar requirements (updating state variables, or some such) 
where I used dual-port RAM; I use one port for the read, and the other 
(delayed a clock) for the modify-write.

The pipeline needs to be managed properly, but it can save tremendously on 
registers (assuming that only one index needs to be updated at a time.  If 
all entries need concurrent access--well, a memory won't cut it.  For my 
application(s), typically TDM processing of multiple channels, it works 
well.)

JTW

"news reader" <newsreader@google.com> wrote in message 
news:esrs16$anh$1@reader01.singnet.com.sg...
>
> "Utku Özcan" <utku.ozcan@gmail.com> wrote in message 
> news:1173384869.194349.20140@q40g2000cwq.googlegroups.com...
>>
>> Hi "news reader", my humble perls in between..
>>
>> news reader schrieb:
>>
>>> In the design I have 256 3-bit registers, every time I need to read or
>>> write 16 of them (data_o0, 1, ...15).
>>> The read/write address is not totally random.
>>
>> It seems that you have an algorithm that handles a deterministic
>> distribution of the values to be accessed. Therefore you think you can
>> implement it with logic only.
>>
>> I assume you are modeling an algorithm for a special matrix operation.
>>
>
> It's not matrix, but the memory access is intensive, must accomplish r/w 
> in
> single clock cycle, so register is used instead of memory.
>
>
>>> For example, assuming that I arrange the register into a 16X16 matrix,
>>> data_o0 accesses among the zeros row or column. data_o1 may access from 
>>> 20 of the
>>>  registers, but not 256, data_o2 may access from 30 of the variables, 
>>> etc.
>>
>> The values do not give us much info. data_ox (x = 1, 2, ...) is
>> accessing which elements and in which distribution?
>>
>
> In each clock cycle, 16 addresses are generated, and 16 data are 
> read/written. However,
> each of the 16 data is read/written only to n/256 addresses (0<n<255).
>
>
>>> If I code such that every output reads from the 256 registers, the final
>>> logic will be overkill and highly redundant.
>>
>> You think that the distribution of elements can be accessed with pure
>> logic.
>> Therefore you tried to model your logic to cover every case, or you
>> want to do it so.
>>
>>> If I use case statements to list each of the senarios, the RTL code may 
>>> end
>>> up 500 kilobyte.
>>
>> This is reasonable then.
>>
>
>
> By means of case statement, I use 32 case statements, in each case 
> statement there
> are less than 256 choices. Some have only 20, 30 choices, etc.
>
>
>>> Will design compiler synthesize a 500KB design efficiently?
>>
>> What means "efficience" for you? Speed or minimum logic?
>> If minimum logic, then please share with us the algorithm you are
>> trying to implement.
>>
>>> Will NCVerilog compile and simulate it efficiently?
>>
>> NCVerilog does not care about logic implementation. It defines the
>> behaviour of the system, no matter how the objects are linked.
>>
>
>
> For example in read operation,
> --------------------- implementation A------------------
> input [7:0] addr_i0, addr_r1, ...addr_r15;
> output [2:0] dat_o0, dat_o1, ...dat_o15;
>
> reg [2:0] mymemory[0:255];    // Main memory
>
> dat_o0 <= mymemory[addr_i0];
> dat_o1 <= mymemory[addr_i1];
> ....
> dat_o15 <= mymemory[addr_i15];
> --------------------- End A------------------
>
> --------------------- implementation B------------------
>
> case (addr_i0)    // I can calculate these options through simulations.
> 8'd0  :    dat_o0 <= mymemory[0  ];
> 8'd5  :    dat_o0 <= mymemory[5  ];
> 8'd54 :    dat_o0 <= mymemory[54 ];
> 8'd122:    dat_o0 <= mymemory[122];
> 8'd125:    dat_o0 <= mymemory[125];
> ...
> 8'd166:    dat_o0 <= mymemory[166];
> 8'd233:    dat_o0 <= mymemory[233];
> default: dat_o0 <= mymemory[0  ];
> endcase
>
>
>
> case (addr_i1)
> 8'd0  :    dat_o1 <= mymemory[0  ];
> 8'd7  :    dat_o1 <= mymemory[7  ];
> 8'd9  :    dat_o1 <= mymemory[9  ];
> 8'd13 :    dat_o1 <= mymemory[13 ];
> 8'd25 :    dat_o1 <= mymemory[25 ];
> 8'd57 :    dat_o1 <= mymemory[57 ];
> 8'd124:    dat_o1 <= mymemory[124];
> ...
> 8'd133:    dat_o1 <= mymemory[133];
> 8'd155:    dat_o1 <= mymemory[155];
> 8'd277:    dat_o1 <= mymemory[277];
> default: dat_o1 <= mymemory[0  ];
> endcase
>
> ...
> case (addr_i15)
> ...
> --------------------- End B------------------
>
> In terms of hardware implementation, is it certain that implementation B 
> saves hardware
> compared to A? Will the large chunks of RTL codes causes a DC or NCVerilog 
> to
> choke up?
>
>
>
>>> Are there any neater techniques to attack this problem?
>>
>> Since you have not given much data, I think you can implement this
>> stuff with a RAM.
>> Why don't you use a RAM? Then you can define the RAM addresses to
>> model your matrix. You will generate addresses to define the positions
>> for your matrix which mimics your algorithm.
>>
>
> I used registers instead of RAM due to the memory throughput.
>
>
>
>> Utku.
>>
>
> 



Article: 116499
Subject: Re: ddr sdram controller
From: PeteS <peter.smith8380@ntlworld.com>
Date: Sun, 11 Mar 2007 09:38:12 GMT
Links: << >>  << T >>  << A >>
Daniel S. wrote:
> dhruvakshad@gmail.com wrote:
>> How can I get a ddr sdram  controller for the MT46V16M16TG -75 micron
>> chip.
>> I want a controller without  the plb or opb interface. I tried open
>> cores.org but it says that the repository is empty with no files
>> pertaining to the ddrsdram controller core.
>> Could someone give me right pointers?
>> Thanks,
>> D.
> 
> I read a few reports about that controller, it seemed to be a rather 
> low-performance option. You could look into Xilinx's MIG, that could 
> help to get you started - I started building my own 200MHz DDR 
> controller to interface with a 256MB PC3200 DIMM and I use an MIG design 
> as a reference when I need inspiration. Again, I am not using the MIG 
> either since I have seen mixed feedback about it. I too would be 
> interested in hearing about existing open-source, preferably 
> high-bandwidth, DDR controllers.
> 
> Right now, I am expecting the my controller to consume about 44 of 144 
> BRAMs (ouch!) and at least 3000 of 13.6k slices on my XC2VP30-7. Things 
> would be much simpler if I had V5s instead. I am doing this mostly 
> because I have always been pretty far from IOBs in my previous FPGA/ASIC 
> jobs. Since knowledge of DDR/DDR2 is often a must for the jobs I am 
> interested in, I decided to try building a full-blown DDR controller - 
> I'll most likely downscale it for actual use though.
> 
> Since your device is only 16bits wide, things should be much simpler and 
> you should have many more options than I do. If you browse OpenCore's 
> CVS directory, you will find many SDR-SDRAM controllers that may be 
> nearly suitable for your application - you should be able to modify one 
> of the many SDR controllers for DDR operation by doing little more than 
> changing the IOB FFs and widening data buses as necessary. Note: they 
> appear to all be verilog.
> 
> BTW, all DDR-SDRAM devices are pretty much the same, there should be no 
> need to request one for a specific device. All you need to do is connect 
> a generic DDR controller to a suitable clock and modify the controller 
> to match the CAS/RAS and other latency requirements of your specific 
> device for the selected operating frequency.

DDR controllers should simply meet the requirements of the JEDEC spec 
(you can find it at Micron). As you want to get faster things get more 
complex of course.

There are two primary differences between SDR and DDR:

1. The clock is complementary and should have very low skew between the 
pair. In addition, clocking at the SDRAM is based on the differential 
voltage between the clock pair rather than VIL/VIH.

2. The strobes (DQS rather than DQM) are driven by the SDRAM during 
reads (with interesting timing that has to be accounted for at the 
controller).i.e. the strobes are bidirectional.

The interesting timing is that the strobes are driven coincidentally 
with the data during reads, and that has to be offset at the controller 
to capture the data successfully. Most controllers assert the strobe 
during writes at roughly 50% of the data window. Delay units in the FPGA 
are a godsend for this sort of thing.

Starting with a SDR controller, the spec and a typical device data sheet 
it shouldn't be too hard a task to do a DDR controller.

How well it performs depends on the device and implementation, of course.

Cheers

PeteS



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