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 52550

Article: 52550
Subject: Re: Generating EDIF from HandelC
From: dullrabbit@hotmail.com (James)
Date: 13 Feb 2003 01:41:49 -0800
Links: << >>  << T >>  << A >>
The optimiser strips out all redundant logic in EDIF mode. It sounds
like you have a design with no external ports or interfaces declared.
Make sure your design is connected up to something external using the
'interface' command.

e.g.
unsigned 4 x;
interface bus_out() OutBus(unsigned 4 out = x) with pins = 
{ "p1", "p2", "p3", "p4"} 


James

Thomas Buerner <buerner@lrs.eei.uni-erlangen.de> wrote in message news:<3E281AD7.1AE43249@lrs.eei.uni-erlangen.de>...
> I generated a VHDL output from a HandelC project,
> synthesized it and used the Xilinx tools to map and place and
> route for a XC4010XL. This works fine.
> Then I tried to generate a EDIF netlist with DK1
> but the mapper tells me:
> 
>  NCD was not produced. All logic was removed from design.
> 
> I checked the EDIF and found that no clock port is present.
> Instead a IPAD is the source of the clock signal in the netlist,
> which is removed by the mapper.
> 
> 
> any hints
> 
> thanx
> Thomas

Article: 52551
Subject: Re: Causing Modelsim to break using VHDL code
From: Ray Andraka <ray@andraka.com>
Date: Thu, 13 Feb 2003 12:52:05 GMT
Links: << >>  << T >>  << A >>
This comes up from time to time.  As long as you don't have processes inside
your UUT that go without a clock from the outside (such as some pll models), you
can stop simulation by causing all the processes to wait indefinitely.  Stop the
clocks, and you will stop all clock dependent processes.  Here is how to stop
them


process (
    begin
        if end_sim then
            wait;
        end if;
        clk<='1';
        wait for 5 ns;
        clk<='0';
        wait for 5 ns;
    end ;

Then in your stimulus process
      if stop_condition
        end_sim<=true;
      end if;





Frederic Bastenaire wrote:

> Hello,
>
> I am trying to cause a break to occur by executing a  VHDL statement, in
> Modelsim (I do not want to use breakpoints, they are not convenient/flexible
> enough IMHO).
> Assert statements are supposed to do something like this, but using severity
> ERROR just prints a message, without stopping, while FAILURE really kills
> Modelsim.
> Are there other ways?
>
> Thank you for your help,
>
> Frederic
>  (fba@free.fr)

--
--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: 52552
Subject: Re: Virtex-II Pro PowerPC cache memory as main program/data storage?
From: serebr@mailandnews.com (Valeri Serebrianski)
Date: 13 Feb 2003 05:18:00 -0800
Links: << >>  << T >>  << A >>
Hi Peter,

Thanks a lot for your detailed answer.
 
Solution with JTAG port using for caches content loading seems too
overcomplicated for the tiny board with only one XC2VP4 installed.
Nevertheless information concerning how both data and program caches
might be mapped in the PowerPC address space is very important and
helpful. I will think further how to use this feature to reduce
SelectRAM occupation.

Valeri Serebrianski.

Article: 52553
Subject: Designware Components and Modelsim
From: Salman Sheikh <sheikh@pop500.gsfc.nasa.gov>
Date: Thu, 13 Feb 2003 09:01:18 -0500
Links: << >>  << T >>  << A >>
Hello,

My Synopsys VSS license has expired. Is it possible to use the designware
components (which my design eventual ASIC design contains) with Modelsim
for simulating my design?  I still have the license for Synopsys DC
compiler for the synthesis but can I use modelsim for the simulation?

Salman


Article: 52554
Subject: Re: Coolrunner II I/O speeds?
From: Brian <usenet@carlsonclan.com>
Date: Thu, 13 Feb 2003 09:33:35 -0500
Links: << >>  << T >>  << A >>
On Thu, 13 Feb 2003 10:02:11 +1300, Jim Granville
<jim.granville@designtools.co.nz> wrote:

>Brian wrote:
<snip>
>> Does anyone know if a Coolrunner II (-5 speed grade 2C64VQ100) outputs
>> should be able to work at this frequency?  (The rise and fall times in
>> the data sheet seem to indicate that it should.)   Given the symptoms
>> I describe, what might the problem be?  Some sort of power issue?
>
> CPLDs typically have a SLEW control bit, so you could check that ?
>
> The simplest test for what you describe is to lower the 155MHz IP clock
>-
>if the waveform appears/improves below a certain freq, then yes, you
>can confirm that with your settings the CR-II cannot output 155MHz.
>
> Most chips can clock faster than they can output.
>
> -jg

Jim, thanks for the suggestions.   

I do have the slew rate set to fast.

Also, the waveform does indeed improve as I slow down the clock rate.
At about 77 MHz, it's swinging across the full voltage range, but
looks horrible (about a 10 percent duty cycle).   Once I get the
frequency down to around 50 MHz, it looks fine.

I was really hoping that someone who's using a Coolrunner II would
either tell me that the push-pull I/O just won't go that fast, or that
their's works fine at the I/O rates I'm trying.   If it just won't go
that fast, then I'll use the open drain output or change the rest of
my system to accept a lower voltage swing.  If others are having no
problems outputing signals that fast, then I'll know that I have
something fundamentally wrong with my layout and know that I won't be
wasting my time trying to debug it....


Article: 52555
Subject: Re: Coolrunner II I/O speeds?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 13 Feb 2003 08:11:17 -0800
Links: << >>  << T >>  << A >>
Brian,

From the IBIS sim, it goes that fast (we verify IBIS with silicon).

It is possible that you have a early part from the fab, and that it might be
in the slow corner of the process.  I would open a case on the hotline, as
there is no reason why it could not do what you want it to do.

One obvious question:  you are measuring this with a >1GHz scope and probe,
right?

Austin

Brian wrote:

> On Thu, 13 Feb 2003 10:02:11 +1300, Jim Granville
> <jim.granville@designtools.co.nz> wrote:
>
> >Brian wrote:
> <snip>
> >> Does anyone know if a Coolrunner II (-5 speed grade 2C64VQ100) outputs
> >> should be able to work at this frequency?  (The rise and fall times in
> >> the data sheet seem to indicate that it should.)   Given the symptoms
> >> I describe, what might the problem be?  Some sort of power issue?
> >
> > CPLDs typically have a SLEW control bit, so you could check that ?
> >
> > The simplest test for what you describe is to lower the 155MHz IP clock
> >-
> >if the waveform appears/improves below a certain freq, then yes, you
> >can confirm that with your settings the CR-II cannot output 155MHz.
> >
> > Most chips can clock faster than they can output.
> >
> > -jg
>
> Jim, thanks for the suggestions.
>
> I do have the slew rate set to fast.
>
> Also, the waveform does indeed improve as I slow down the clock rate.
> At about 77 MHz, it's swinging across the full voltage range, but
> looks horrible (about a 10 percent duty cycle).   Once I get the
> frequency down to around 50 MHz, it looks fine.
>
> I was really hoping that someone who's using a Coolrunner II would
> either tell me that the push-pull I/O just won't go that fast, or that
> their's works fine at the I/O rates I'm trying.   If it just won't go
> that fast, then I'll use the open drain output or change the rest of
> my system to accept a lower voltage swing.  If others are having no
> problems outputing signals that fast, then I'll know that I have
> something fundamentally wrong with my layout and know that I won't be
> wasting my time trying to debug it....


Article: 52556
Subject: BLACK BOX
From: cvmnk@yahoo.com (naveen)
Date: 13 Feb 2003 08:27:22 -0800
Links: << >>  << T >>  << A >>
hi guys,
      iam workin on 32 bit alu design using vertex2 fpga chip. in this
i have to design a 16 BY 32 ROM USING "INIT" function. im comin across
lots of warnings indicatin "BLACK BOX".
    Wats this "black box".
   and how do i remove these warnings and how they affect my design.

thankin u
 naveen

Article: 52557
Subject: Re: Multicontext FPGA
From: Kuan Zhou <zhouk@rpi.edu>
Date: Thu, 13 Feb 2003 11:41:07 -0500
Links: << >>  << T >>  << A >>


   How can you reconfig the parts of Virtex II without any current issue?
Are you using serial programming or parallel programming?With the
configuration data changed in the RAM,you surely have some switching
current.I am not sure whether you still have the short current.But seems
it will be there too.

On Wed, 12 Feb 2003, Austin Lesea wrote:

> Rudy,
> 
> It is sure amusing to read all of the conjectures.....
> 
> Now that we are designing our 12th generation FPGA, we are able to control current quite well,
> thank you.
> 
> Note:  that is 12 successful FPGA designs.  You get pretty good at something when you work on
> it for that long (and do some experimentation along the way).
> 
> Virtex II and Virtex II Pro have no current surge on power ON, as we found what causes that,
> and addressed it.
> 
> As for multi-context FPGAs, they were simply killed by FPGAs with million+ "gates" (who needs
> to switch?).  As well, with partial reconfiguration in Virtex II and II Pro, you can at any
> time reconfigure parts and pieces (with no current issue).
> 
> Austin
> 
> 
> Rudolf Usselmann wrote:
> 
> > Christian Plessl <plessl@tik.ee.ethz.ch> wrote in message news:<3e47e49e@pfaff.ethz.ch>...
> > > Nicholas C. Weaver wrote:
> > >
> > > > In article <b235lh$n01$03$1@news.t-online.com>,
> > > > Florian-Wolfgang Stock  <f.stock@tu-bs.de> wrote:
> > > >>S. Trimberger, D. Carberry, A. Johnson, J. Wong: A time-multiplexed
> > > >>FPGA. In "Proceedings of IEEE Workshop on FPGAs for Custom Computing
> > > >>Machines" (April 1997), pp. 22-28
> > > >
> > > > This one, a Xilinx design for a multicontext XC4000, was basically
> > > > killed as a potential product because context switching draws a LOT of
> > > > power, especially in all the interconnect bits, and they envisionsed
> > > > multicontext being used to virtualize larger circuits.
> > >
> > > Do you have any idea, why some multi-context devices are seem to consume a
> > > lot of power when context switching?
> > >
> > > Any idea how the power dissipation related to context switching relates to
> > > the power consumed by a 'typical' user application? I understand that a
> > > context switch can potentially cause a lot of elements to switch at once,
> > > but also a user application might generate quit a lot of signal toggling.
> >
> > The problem lies in changing the interconnect configuration during
> > a "context switch". To fully understand the details you need to look
> > at how those switches are implemented: typically some combination of
> > pass-gates and buffers. The characteristics are typically so, that
> > the actual signal propagation is quick (e.g. low resistance pass-gates
> > and very quick buffers), however the turn on and off time are relatively
> > slow. So what happens when you change the configuration ? Multiple pass
> > gates can be closed at the same time and drive different logic values
> > on the bus, creating a short. Count the nuber of interconnects and
> > possible shorts, even in the smallest FPGA, and it becomes clear why
> > you can cook coffee on them if constantly context switching. (I suspect
> > this is the same reason why the "power-on-current" requirement is so
> > high.)
> >
> > Of course the idea of context switching programmable logic is not new,
> > I have worked on a proprietary "processor" that had 64 "time slices".
> > This was basically an FPGA type of structure with its inputs and outputs
> > going through a multilevel register file as well as to an IO ring. It
> > was meant to be used as the hart in a Hardware Accelerator, and burned
> > about 20 Watts each. (This was in 1995)
> >
> > Regards,
> > rudi
> > ------------------------------------------------
> > www.asics.ws   - Solutions for your ASIC needs -
> > FREE IP Cores  -->   http://www.asics.ws/  <---
> > -----  ALL SPAM forwarded to: UCE@FTC.GOV  -----
> >
> > > Regrads,
> > >  Christian
> 


Article: 52558
Subject: Re: Multicontext FPGA
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Thu, 13 Feb 2003 16:50:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <Pine.SOL.3.96.1030213113821.24078A-100000@vcmr-86.server.rpi.edu>,
Kuan Zhou  <zhouk@rpi.edu> wrote:
>   How can you reconfig the parts of Virtex II without any current issue?
>Are you using serial programming or parallel programming?With the
>configuration data changed in the RAM,you surely have some switching
>current.I am not sure whether you still have the short current.But seems
>it will be there too.

If I recall (note I may be horribyl wrong) the Xilinx reconfig since
Virtex operates by having a shift-chain shift the data down and then
the data from the shift-chain is loaded into a column of config bits.

Since you are only shifting one chain at a time, even though it can be
rather long, the power is not much.

The power people were refering to is the "Power on surge", the power
required on startup on the Virtex and before, which was a fairly
nontrivial amount of current for a short period of time.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 52559
Subject: Re: Multicontext FPGA
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 13 Feb 2003 08:51:26 -0800
Links: << >>  << T >>  << A >>
Kuan,

That is why we are the leader.  We know how to do this (among other things) and others do not.

Austin

Kuan Zhou wrote:

>    How can you reconfig the parts of Virtex II without any current issue?
> Are you using serial programming or parallel programming?With the
> configuration data changed in the RAM,you surely have some switching
> current.I am not sure whether you still have the short current.But seems
> it will be there too.
>
> On Wed, 12 Feb 2003, Austin Lesea wrote:
>
> > Rudy,
> >
> > It is sure amusing to read all of the conjectures.....
> >
> > Now that we are designing our 12th generation FPGA, we are able to control current quite well,
> > thank you.
> >
> > Note:  that is 12 successful FPGA designs.  You get pretty good at something when you work on
> > it for that long (and do some experimentation along the way).
> >
> > Virtex II and Virtex II Pro have no current surge on power ON, as we found what causes that,
> > and addressed it.
> >
> > As for multi-context FPGAs, they were simply killed by FPGAs with million+ "gates" (who needs
> > to switch?).  As well, with partial reconfiguration in Virtex II and II Pro, you can at any
> > time reconfigure parts and pieces (with no current issue).
> >
> > Austin
> >
> >
> > Rudolf Usselmann wrote:
> >
> > > Christian Plessl <plessl@tik.ee.ethz.ch> wrote in message news:<3e47e49e@pfaff.ethz.ch>...
> > > > Nicholas C. Weaver wrote:
> > > >
> > > > > In article <b235lh$n01$03$1@news.t-online.com>,
> > > > > Florian-Wolfgang Stock  <f.stock@tu-bs.de> wrote:
> > > > >>S. Trimberger, D. Carberry, A. Johnson, J. Wong: A time-multiplexed
> > > > >>FPGA. In "Proceedings of IEEE Workshop on FPGAs for Custom Computing
> > > > >>Machines" (April 1997), pp. 22-28
> > > > >
> > > > > This one, a Xilinx design for a multicontext XC4000, was basically
> > > > > killed as a potential product because context switching draws a LOT of
> > > > > power, especially in all the interconnect bits, and they envisionsed
> > > > > multicontext being used to virtualize larger circuits.
> > > >
> > > > Do you have any idea, why some multi-context devices are seem to consume a
> > > > lot of power when context switching?
> > > >
> > > > Any idea how the power dissipation related to context switching relates to
> > > > the power consumed by a 'typical' user application? I understand that a
> > > > context switch can potentially cause a lot of elements to switch at once,
> > > > but also a user application might generate quit a lot of signal toggling.
> > >
> > > The problem lies in changing the interconnect configuration during
> > > a "context switch". To fully understand the details you need to look
> > > at how those switches are implemented: typically some combination of
> > > pass-gates and buffers. The characteristics are typically so, that
> > > the actual signal propagation is quick (e.g. low resistance pass-gates
> > > and very quick buffers), however the turn on and off time are relatively
> > > slow. So what happens when you change the configuration ? Multiple pass
> > > gates can be closed at the same time and drive different logic values
> > > on the bus, creating a short. Count the nuber of interconnects and
> > > possible shorts, even in the smallest FPGA, and it becomes clear why
> > > you can cook coffee on them if constantly context switching. (I suspect
> > > this is the same reason why the "power-on-current" requirement is so
> > > high.)
> > >
> > > Of course the idea of context switching programmable logic is not new,
> > > I have worked on a proprietary "processor" that had 64 "time slices".
> > > This was basically an FPGA type of structure with its inputs and outputs
> > > going through a multilevel register file as well as to an IO ring. It
> > > was meant to be used as the hart in a Hardware Accelerator, and burned
> > > about 20 Watts each. (This was in 1995)
> > >
> > > Regards,
> > > rudi
> > > ------------------------------------------------
> > > www.asics.ws   - Solutions for your ASIC needs -
> > > FREE IP Cores  -->   http://www.asics.ws/  <---
> > > -----  ALL SPAM forwarded to: UCE@FTC.GOV  -----
> > >
> > > > Regrads,
> > > >  Christian
> >


Article: 52560
Subject: Re: Coolrunner II I/O speeds?
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 13 Feb 2003 17:18:09 GMT
Links: << >>  << T >>  << A >>
One chart in the Coolrunner 2C64 datasheet shows current versus frequency up
to 240MHz in the -5 and -7 but the maximum external frequency (for Tsu and
Tcko) is 159 or 169 MHz for the -5 device (Two values given).

If you have real 155M NRZ data and not a CMI electrical interface (effective
311 MHz NRZ data rate) you should be good with your I/O but keep in mind
that the numbers are specified for TTL with extra time required for LVCMOS.

I'd look at the timing report generated in the Xilinx design flow (or
analyzed separately) to make sure everything looks fine from that
perspective.  Just one pterm delay can tak up a lot of your clock cycle so
those timing analysis numbers are important.

The fluctuation around 3.3V is what I'd expect to see for a TTL style signal
in a CPDL - the drivers are a little weak at the high voltage so what you're
probably seeing is an output that thinks it should be logic high and the
noise is feedthrough from the internal voltage rails for your I/O.

If you can, try running the device at half speed and see if you still have
the logic high.  If you're playing with your clock internally, make sure the
duty cycle will stay clean.  The global clock pulse width high or low is
specified for 1.5 ns so you should have plenty of margin.  If you're using
the internal clock doubling feature (using both clock edges, more
precisely), make sure the duty cycle of the clock going in is clean.

Good luck!

"Brian" <usenet@carlsonclan.com> wrote in message
news:rari4vcbt4ldgu3gl16n5hv4tdrf20d6lf@4ax.com...
> I'm working on a design that needs to output signals up to 155 MHz.
> I'm trying to use a Coolrunner II, but the output doesn't seem fast
> enough.
>
> I'm using 3.3V I/O and when I try to simply output my 155 MHz input
> clock, I get a waveform that stays up around 3.3V.  It sort of wiggles
> a few tenths of a volt at the right frequency, but never even makes it
> below 3 V.   I've uploaded a crude sketch showing the waveform here:
> http://www.fastclan.com/members/griz/155MHz.gif
>
> I've played around with adding a BUFG and/or an OBUF, but the output
> still looks the same.  I've also tried using the LVTTL and 33LVCMOS
> output types, but again, it always looks the same.   The only way I
> can get a more or less acceptable output is to us an open drain output
> with a *strong* pullup resistor (like 200 Ohms).
>
> I'm fairly sure that the clock is making it into the part OK, because
> I tried putting in a counter to divide down the clock, and those
> outputs looked OK.
>
> Does anyone know if a Coolrunner II (-5 speed grade 2C64VQ100) outputs
> should be able to work at this frequency?  (The rise and fall times in
> the data sheet seem to indicate that it should.)   Given the symptoms
> I describe, what might the problem be?  Some sort of power issue?
>
> TIA
> -Brian
>



Article: 52561
Subject: Easy links to Xilinx documentation
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 13 Feb 2003 09:28:00 -0800
Links: << >>  << T >>  << A >>


This might save you some time and effort:

App. Notes
http://www.xilinx.com/apps/xapp.htm

TechXclusives
http://www.xilinx.com/support/techxclusives/techX-home.htm

Software Manuals
http://toolbox.xilinx.com/docsan/xilinx4/manuals.htm

V2 Data Sheet
http://www.xilinx.com/partinfo/ds031.htm

V2 Users Guide (i.e. Handbook)
http://www.xilinx.com/publications/products/v2/ug_pdf/index.htm

V2 Pro Data Sheet
http://www.xilinx.com/publications/products/v2pro/ds_pdf/ds083.htm

V2 Pro Users Guide (i.e. Handbook)
http://www.xilinx.com/publications/products/v2pro/ug_pdf/index.htm






Article: 52562
Subject: Re: Switching synthesis tools
From: hereisjunk@yahoo.com (Nicholas Girde)
Date: 13 Feb 2003 10:09:26 -0800
Links: << >>  << T >>  << A >>
Hi,

Has anybody used the newest version of FC2 (3.7.2)?? I just got to try
it the other day and its much much faster compared to its earlier
versions (compared to 3.6.0). Also looks like retiming has been fixed,
I could run a few designs through it which were complaining
earlier....I was also surprised that it supported a few vhdl
constructs for which the earlier versions used to error out. I'm yet
to try it out fully though....

-Nick


"Jonathan Bromley" <jonathan@oxfordbromley.u-net.com> wrote in message news:<b1t8of$50p$1$8302bc10@news.demon.co.uk>...
> "Ray Andraka" <ray@andraka.com> wrote:
> > Synplify does a much  better job at mapping RTL to the special features of
> > the FPGA.  Xilinx's XST does well in that regard too, but it is restricted
> > to Xilinx only.
> 
> I don't in any way disagree, but to try to keep the discussion
> balanced it might be worth mentioning my experience that Leonardo
> Spectrum seems to have the widest understanding of VHDL language
> constructs of any synthesis tool.  Not necessarily the best quality
> of results, though - that's a "your mileage may vary" issue that
> you will need to evaluate case-by-case.
> 
> Also, don't try to evaluate these tools just by throwing one
> standard piece of "benchmark" code at them to see which gives
> the densest/fastest/prettiest result.  Each of the major tools
> has specific HDL coding styles that it doesn't like and won't
> optimise effectively;  details differ for each tool.
> --
> Jonathan Bromley, Consultant
> 
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
> 
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
> Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573                           Web: http://www.doulos.com
> 
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

Article: 52563
Subject: Re: Coolrunner II I/O speeds?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 14 Feb 2003 07:24:03 +1300
Links: << >>  << T >>  << A >>
Brian wrote:
> 
> On Thu, 13 Feb 2003 10:02:11 +1300, Jim Granville
> <jim.granville@designtools.co.nz> wrote:
> 
> >Brian wrote:
> <snip>
> >> Does anyone know if a Coolrunner II (-5 speed grade 2C64VQ100) outputs
> >> should be able to work at this frequency?  (The rise and fall times in
> >> the data sheet seem to indicate that it should.)   Given the symptoms
> >> I describe, what might the problem be?  Some sort of power issue?
> >
> > CPLDs typically have a SLEW control bit, so you could check that ?
> >
> > The simplest test for what you describe is to lower the 155MHz IP clock
> >-
> >if the waveform appears/improves below a certain freq, then yes, you
> >can confirm that with your settings the CR-II cannot output 155MHz.
> >
> > Most chips can clock faster than they can output.
> >
> > -jg
> 
> Jim, thanks for the suggestions.
> 
> I do have the slew rate set to fast.
> 
> Also, the waveform does indeed improve as I slow down the clock rate.
> At about 77 MHz, it's swinging across the full voltage range, but
> looks horrible (about a 10 percent duty cycle).   Once I get the
> frequency down to around 50 MHz, it looks fine.

 Interesting - That's consistant with a quite different Tplh from Tphl.
at appx 80MHz corner, that's ~6ns of skew to 'remove' a whole half
cycle.

 ( Almost like the slew controls are only half working... )

 Certainly not normal for a device of that speed class, 
and I'd go with Austin's suggestion of 'an early part from the fab' :)

 Have you tried other samples ( even other pins ) ? 

 Tried enabling the slow option, to see it really does get slower again
?

 I can't see the Pullup helping a sticky hi problem, so it
sounds like the open drain bypasses whatever is causing the skew,
which again points to an output cell issue .....

-jg

Article: 52564
Subject: Re: JBits
From: "Steve Casselman" <sc@vcc.com>
Date: Thu, 13 Feb 2003 20:15:53 GMT
Links: << >>  << T >>  << A >>
> more useful were focused on
> shortening reconfiguration times.

As devices sizes go into the 10 - 100 million gate range you will want to
think more along the line of a complete system with OS and other resources.
Even in full applications most of the code stays around and just subroutines
and processes are swapped in and out. It would be nice to have a 32 bit
configuration interface. Todays systems are 8-bit external and 32-bit
internal (or 100s of bits if you count a frame as the internal bit length).

> Algorithmic programming of fpga's for wild-a$$ genetic search
> machines is a great application, but it seems a ways off before
> its ready for the masses of programmers writing software that manipulates
> hardware in realtime.

No I don't believe so.  The way it is starting to look is: take an algorithm
and a data set and generate a custom piece of hardware for that combination.
So take a picture or image and generate a correlator based on that image
http://www.doc.ic.ac.uk/~wl/papers/fccm02jg.pdf . This really shows you
where reconfigurable computing systems and methodes are headed.

> I can see your vision, but with the Xilinx 6000 demise, (too early to
market?)
> as an example, potential backers of open bitstream fpga architectures
> should think long and hard. There is perceived value in having your
hardware
> designs distributed in a traditional confusticated form, produced and
verified
> by commodity toolchains (sim,syn,par, and timing).
>

The real problem with the 6200 was logic size and performance. Someday I
believe that we will look at hardware designs as programming and accept that
fact that you can disassemble a program if you really want to. While I'm not
saying FPGA companies should abandon their current business models they
should think about designing a device that is supposed to be programmed and
understood by programmers. Some device that understands that it will have to
fetch pieces of hardware over and over an OS that understands that computing
is both changing hardware and changing software.

It seems like every 20 years we start to have break throughs of this kind.
In the 60's real computers were programmed by real programmers that
programmed in assembly. In the 80's power DSP programmers programmed power
applications using only assembly. In the '00's we have creative engineers
creating magic using hardware programming tools. In the end clever people
found how to capture that expertise and interpret computer languages so
average people could do what use to take the top 5% burning the candle at
both ends to accomplish.

To really do this you need to publish the data so you can have 1000's of
people working on it instead of just the people you pay. Imagine if there
were no published data on a processor and the tool that company C made only
had encrypted files so there was no way someone out side the company could
make a compiler. Even if company C produced a great processor, competitor
company D that published all the data would win in the market place. This is
because other companies and individuals would work to provide tools and
might do things company D or C did not think of (like timing driven place
and route) and that would make a difference.

But of course I'm just one dude with a dream. This kind of stuff will only
come around when companies C and D have customers that want this and
customers won't want it till it is proven and .... Opps I 'm back where I
started..

Cheers

Steve



Steve



Article: 52565
Subject: Re: Easy links to Xilinx documentation
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Thu, 13 Feb 2003 20:56:39 -0000
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> This might save you some time and effort:
>
> App. Notes
> http://www.xilinx.com/apps/xapp.htm
>

<snip>

Thanks.  Maybe not as tech as

  http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Platform+FPGAs

but much, much more useful.  (The above URL is for the V-II home page)



Article: 52566
Subject: Re: Altera Stratix terminator technology
From: gregs@altera.com (Greg Steinke)
Date: 13 Feb 2003 13:42:29 -0800
Links: << >>  << T >>  << A >>
Paul,
We have performed testing on the Terminator Technology feature and
found it to offer robust performance even in a noisy environment. For
example, we have tested it with various I/O standards and found that
even with high numbers of switching I/Os, the device met the I/O
specifications (VIL, VIH, and so forth).

The reference resistor is 10x the termination value to minimize the DC
current consumption of the circuit that controls the actual impedance
level. As mentioned above, this solution offers good resistance to
noisy environments.

Greg Steinke
gregs@altera.com



Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3E3EC447.14A10F9A@xilinx.com>...
> Paul,
> 
> Since they chose a reference value of 10X, it makes their solution 10
> times more sensitive to noise, cross talk, ground bounce, and vcc
> bounce.  I would be interested to hear if their solution is fussy, or
> difficult to use.
> 
> Even if the rumor is unconfirmed, we can say that we chose reference
> resistors of 1X to prevent just such problems.
> 
> Austin
> 
> Paul Martek wrote:
> 
> > Has anyone used the terminator technology in Altera Stratix FPGA's?
> > Did it work? Was it reliable? I had heard some third hand news
> > describing a problem configuring the terminator resistance value from
> > the RUP/RDN pins.
> >
> > Paul

Article: 52567
Subject: Re: Altera Cyclone EP1C12 pins changed in Quartus 2.2 from 2.1
From: gregs@altera.com (Greg Steinke)
Date: 13 Feb 2003 14:08:17 -0800
Links: << >>  << T >>  << A >>
Wayne,
Here is what has happened. 
The problem is that dual-purpose IO/VREF pins (whose primary function
in the pin table is I/O) that are unused in the design are listed as
GND in the pin file generated by Quartus II.  The asterisk to mark it
as an unused I/O pin is missing, therefore, it appears to be a
dedicated GND pin. But in fact it is not a dedicated GND pin. A future
version of Quartus II will add the asterisk to denote that it is an
unused I/O pin, to be connected to ground since it is unused, and not
a real GND pin.

Please note that the actual VCC and GND pins on the device are shown
correctly. You would only have a problem here if you had connected the
IO/VREF pin to GND but later wanted to use it as an IO in your design.

Sincerely,
Greg Steinke
gregs@altera.com




"Wayne" <bigwayne@techie.com> wrote in message news:<b0s1fs$27h@netnews.proxy.lucent.com>...
> FYI,
> 
> Has anyone started designing with Altera Cyclone?
> 
> I just learned that there are some pin changes made between
> what was in Quartus 2.1 and Quartus 2.2 for the EP1C12 device.
> 
> Regards,
> Wayne

Article: 52568
Subject: Re: which microprocessor core?
From: "Josh Pfrimmer" <yeah_spam_me@thisaddress.com>
Date: Thu, 13 Feb 2003 14:23:23 -0800
Links: << >>  << T >>  << A >>
Regarding LEON-2, can anybody tell me the differences between versions
1.0.10 and 1.0.11-XST?

Obviously the 1.0.11 version is intended for synthesis with Xilinx XST, but
what are the specific differences that that necessitates?

Thanks!

JoshP


"Ray Andraka" <ray@andraka.com> wrote in message
news:3E3EAD37.7C89ABD0@andraka.com...
> There is also a free 68HC11 core from green  mountain  and a PIC 5x
compatible
> core on opencores.com.  There are links to both on my website.
>
> "Nicholas C. Weaver" wrote:
>
> > In article <3E3E8826.5070208@agh.edu.pl>,
> > Ernest Jamro  <jamro@agh.edu.pl> wrote:
> > >I am interested in implementing a (soft) microprocessor core on Virtex
> > >just for education purposes (and latter on maybe, to use it in some
> > >applications). There are a lot of them available (e.g. OPENCORES).
> > >I do not know which one is the best choice.
> > >
> > >  The microprocessor core should:
> > >1) be free and open - its architecture should be well described so it
> > >would be easy to learn how it works and allows to simulate each part
of
> > >the microprocessor or even observe the real time microprocessor's
> > >signals by ChipScope or Internal Logic Analyser (OpenCores). (It would
> > >be nice if the microprocessor has a WISHBONE compatible external bus)
> > >
> > >2) Rather quick - to show the modern microprocessor architectures -
> > >pipelining, possible branch prediction, VLIW and superscalar
execution,
> > >and working with high frequency (comparable to e.g. microBlaze)
> >
> > You won't get this, especially in an opencore.  Microblaze is very
> > highly optimized and finely pipelined, so it operates in a much higher
> > frequency when compared with other options.
> >
> > >Is it better to use a free core or to buy a commersial one (e.g.
> > >microBlaze), as free cores are not well tested and described and/or
> > >analysising their internal structure might take too much time.
> >
> > If you want free, look at Leon, its a GPLed synthesized sparc.  Not
> > that fast (~20-25 MHz on a Virtex), and not that small (~6000 LUTs),
> > but free and fully synthesized.
> >
> > --
> > Nicholas C. Weaver
nweaver@cs.berkeley.edu
>
> --
> --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: 52569
Subject: Re: Coolrunner II I/O speeds?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 13 Feb 2003 14:45:49 -0800
Links: << >>  << T >>  << A >>
All,

I have it on good authority (ie the folks who know!) that early fab lots had
slower than allowed IO transistor performance.  Please open the case on the
hotline for prompt resolution.

Austin

Jim Granville wrote:

> Brian wrote:
> >
> > On Thu, 13 Feb 2003 10:02:11 +1300, Jim Granville
> > <jim.granville@designtools.co.nz> wrote:
> >
> > >Brian wrote:
> > <snip>
> > >> Does anyone know if a Coolrunner II (-5 speed grade 2C64VQ100) outputs
> > >> should be able to work at this frequency?  (The rise and fall times in
> > >> the data sheet seem to indicate that it should.)   Given the symptoms
> > >> I describe, what might the problem be?  Some sort of power issue?
> > >
> > > CPLDs typically have a SLEW control bit, so you could check that ?
> > >
> > > The simplest test for what you describe is to lower the 155MHz IP clock
> > >-
> > >if the waveform appears/improves below a certain freq, then yes, you
> > >can confirm that with your settings the CR-II cannot output 155MHz.
> > >
> > > Most chips can clock faster than they can output.
> > >
> > > -jg
> >
> > Jim, thanks for the suggestions.
> >
> > I do have the slew rate set to fast.
> >
> > Also, the waveform does indeed improve as I slow down the clock rate.
> > At about 77 MHz, it's swinging across the full voltage range, but
> > looks horrible (about a 10 percent duty cycle).   Once I get the
> > frequency down to around 50 MHz, it looks fine.
>
>  Interesting - That's consistant with a quite different Tplh from Tphl.
> at appx 80MHz corner, that's ~6ns of skew to 'remove' a whole half
> cycle.
>
>  ( Almost like the slew controls are only half working... )
>
>  Certainly not normal for a device of that speed class,
> and I'd go with Austin's suggestion of 'an early part from the fab' :)
>
>  Have you tried other samples ( even other pins ) ?
>
>  Tried enabling the slow option, to see it really does get slower again
> ?
>
>  I can't see the Pullup helping a sticky hi problem, so it
> sounds like the open drain bypasses whatever is causing the skew,
> which again points to an output cell issue .....
>
> -jg


Article: 52570
Subject: Re: Altera Stratix terminator technology
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 13 Feb 2003 14:47:59 -0800
Links: << >>  << T >>  << A >>
Ahh, good.

But did you check to see how much jitter is introduced into a signal when the feature is used in
the presence of noise?

I hope you did, and found that the jitter added was small.

Austin

Greg Steinke wrote:

> Paul,
> We have performed testing on the Terminator Technology feature and
> found it to offer robust performance even in a noisy environment. For
> example, we have tested it with various I/O standards and found that
> even with high numbers of switching I/Os, the device met the I/O
> specifications (VIL, VIH, and so forth).
>
> The reference resistor is 10x the termination value to minimize the DC
> current consumption of the circuit that controls the actual impedance
> level. As mentioned above, this solution offers good resistance to
> noisy environments.
>
> Greg Steinke
> gregs@altera.com
>
> Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3E3EC447.14A10F9A@xilinx.com>...
> > Paul,
> >
> > Since they chose a reference value of 10X, it makes their solution 10
> > times more sensitive to noise, cross talk, ground bounce, and vcc
> > bounce.  I would be interested to hear if their solution is fussy, or
> > difficult to use.
> >
> > Even if the rumor is unconfirmed, we can say that we chose reference
> > resistors of 1X to prevent just such problems.
> >
> > Austin
> >
> > Paul Martek wrote:
> >
> > > Has anyone used the terminator technology in Altera Stratix FPGA's?
> > > Did it work? Was it reliable? I had heard some third hand news
> > > describing a problem configuring the terminator resistance value from
> > > the RUP/RDN pins.
> > >
> > > Paul


Article: 52571
Subject: Re: Ip core pricing info
From: "gary" <theoldgeezer@hotmail.com>
Date: Fri, 14 Feb 2003 03:48:07 GMT
Links: << >>  << T >>  << A >>
http://www.aldec.com/IP_Services/available_cores.htm



"TI" <anglomont@yahoo.com> wrote in message
news:18a34598.0302021646.308dc61c@posting.google.com...
> Can smbdy please point me to a link or just give and estimate
> how much does the stuff like :rake receiver, 8051 core, costs?
> regards
> TI



Article: 52572
Subject: Re: Multicontext FPGA
From: Kuan Zhou <zhouk@rpi.edu>
Date: Fri, 14 Feb 2003 00:53:14 -0500
Links: << >>  << T >>  << A >>
Hi,
    Are you shifting one bit into the column per cycle or shift the
whole chain into the column per cycle?
    Anyway, this kind of programming is slow.What if the people needs fast
reconfiguration?
    Does "power on surge" means when start up the Virtex part needs more
power?

sincerely
-------------
Kuan Zhou
ECSE department


On Thu, 13 Feb 2003, Nicholas C. Weaver wrote:

> In article <Pine.SOL.3.96.1030213113821.24078A-100000@vcmr-86.server.rpi.edu>,
> Kuan Zhou  <zhouk@rpi.edu> wrote:
> >   How can you reconfig the parts of Virtex II without any current issue?
> >Are you using serial programming or parallel programming?With the
> >configuration data changed in the RAM,you surely have some switching
> >current.I am not sure whether you still have the short current.But seems
> >it will be there too.
> 
> If I recall (note I may be horribyl wrong) the Xilinx reconfig since
> Virtex operates by having a shift-chain shift the data down and then
> the data from the shift-chain is loaded into a column of config bits.
> 
> Since you are only shifting one chain at a time, even though it can be
> rather long, the power is not much.
> 
> The power people were refering to is the "Power on surge", the power
> required on startup on the Virtex and before, which was a fairly
> nontrivial amount of current for a short period of time.
> -- 
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
> 
> 


Article: 52573
Subject: Re: Multicontext FPGA
From: Kuan Zhou <zhouk@rpi.edu>
Date: Fri, 14 Feb 2003 00:58:02 -0500
Links: << >>  << T >>  << A >>
Hi,
   I know Xilinx is the leader in the FPGA field.But I can't attend the
FPGA 2003 conference.I got a poster accepted.Otherwise I may talk to you
in the conference.
   What causes "power on surge"?I guess it's because the pass gates are
not powered up simultaneouly.

sincerely
-------------
Kuan Zhou
ECSE department


On Thu, 13 Feb 2003, Austin Lesea wrote:

> Kuan,
> 
> That is why we are the leader.  We know how to do this (among other things) and others do not.
> 
> Austin
> 
> Kuan Zhou wrote:
> 
> >    How can you reconfig the parts of Virtex II without any current issue?
> > Are you using serial programming or parallel programming?With the
> > configuration data changed in the RAM,you surely have some switching
> > current.I am not sure whether you still have the short current.But seems
> > it will be there too.
> >
> > On Wed, 12 Feb 2003, Austin Lesea wrote:
> >
> > > Rudy,
> > >
> > > It is sure amusing to read all of the conjectures.....
> > >
> > > Now that we are designing our 12th generation FPGA, we are able to control current quite well,
> > > thank you.
> > >
> > > Note:  that is 12 successful FPGA designs.  You get pretty good at something when you work on
> > > it for that long (and do some experimentation along the way).
> > >
> > > Virtex II and Virtex II Pro have no current surge on power ON, as we found what causes that,
> > > and addressed it.
> > >
> > > As for multi-context FPGAs, they were simply killed by FPGAs with million+ "gates" (who needs
> > > to switch?).  As well, with partial reconfiguration in Virtex II and II Pro, you can at any
> > > time reconfigure parts and pieces (with no current issue).
> > >
> > > Austin
> > >
> > >
> > > Rudolf Usselmann wrote:
> > >
> > > > Christian Plessl <plessl@tik.ee.ethz.ch> wrote in message news:<3e47e49e@pfaff.ethz.ch>...
> > > > > Nicholas C. Weaver wrote:
> > > > >
> > > > > > In article <b235lh$n01$03$1@news.t-online.com>,
> > > > > > Florian-Wolfgang Stock  <f.stock@tu-bs.de> wrote:
> > > > > >>S. Trimberger, D. Carberry, A. Johnson, J. Wong: A time-multiplexed
> > > > > >>FPGA. In "Proceedings of IEEE Workshop on FPGAs for Custom Computing
> > > > > >>Machines" (April 1997), pp. 22-28
> > > > > >
> > > > > > This one, a Xilinx design for a multicontext XC4000, was basically
> > > > > > killed as a potential product because context switching draws a LOT of
> > > > > > power, especially in all the interconnect bits, and they envisionsed
> > > > > > multicontext being used to virtualize larger circuits.
> > > > >
> > > > > Do you have any idea, why some multi-context devices are seem to consume a
> > > > > lot of power when context switching?
> > > > >
> > > > > Any idea how the power dissipation related to context switching relates to
> > > > > the power consumed by a 'typical' user application? I understand that a
> > > > > context switch can potentially cause a lot of elements to switch at once,
> > > > > but also a user application might generate quit a lot of signal toggling.
> > > >
> > > > The problem lies in changing the interconnect configuration during
> > > > a "context switch". To fully understand the details you need to look
> > > > at how those switches are implemented: typically some combination of
> > > > pass-gates and buffers. The characteristics are typically so, that
> > > > the actual signal propagation is quick (e.g. low resistance pass-gates
> > > > and very quick buffers), however the turn on and off time are relatively
> > > > slow. So what happens when you change the configuration ? Multiple pass
> > > > gates can be closed at the same time and drive different logic values
> > > > on the bus, creating a short. Count the nuber of interconnects and
> > > > possible shorts, even in the smallest FPGA, and it becomes clear why
> > > > you can cook coffee on them if constantly context switching. (I suspect
> > > > this is the same reason why the "power-on-current" requirement is so
> > > > high.)
> > > >
> > > > Of course the idea of context switching programmable logic is not new,
> > > > I have worked on a proprietary "processor" that had 64 "time slices".
> > > > This was basically an FPGA type of structure with its inputs and outputs
> > > > going through a multilevel register file as well as to an IO ring. It
> > > > was meant to be used as the hart in a Hardware Accelerator, and burned
> > > > about 20 Watts each. (This was in 1995)
> > > >
> > > > Regards,
> > > > rudi
> > > > ------------------------------------------------
> > > > www.asics.ws   - Solutions for your ASIC needs -
> > > > FREE IP Cores  -->   http://www.asics.ws/  <---
> > > > -----  ALL SPAM forwarded to: UCE@FTC.GOV  -----
> > > >
> > > > > Regrads,
> > > > >  Christian
> > >
> 
> 
> 


Article: 52574
Subject: Re: Multicontext FPGA
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Fri, 14 Feb 2003 06:18:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <Pine.SOL.3.96.1030214004835.24511A-100000@vcmr-86.server.rpi.edu>,
Kuan Zhou  <zhouk@rpi.edu> wrote:
>Hi,
>    Are you shifting one bit into the column per cycle or shift the
>whole chain into the column per cycle?

It's a shift chain, so the addition is however many bits/bytes per
clock cycle.  Once the chain is full, it is transfered to config
bits.  Again, this is just what I recall.

>    Anyway, this kind of programming is slow.What if the people needs fast
>reconfiguration?

You don't use Xilinx or Altera.

Or you limit your reconfiguration to just LUT contents and use SRL16
mode.

>    Does "power on surge" means when start up the Virtex part needs more
>power?

	power-on surge is the problem the Virtex 1 had where the
startup required a conisderable amount of current to properly start up
when first powered.  This power is only required during startup, not
during normal operation.  Virtex II fixed this problem.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu



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