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 86675

Article: 86675
Subject: Re: Cant' make SignalTap works...
From: "Vaughn Betz" <no_spam@altera.com>
Date: Sun, 3 Jul 2005 22:58:56 -0400
Links: << >>  << T >>  << A >>
The "waiting for clock" status indicates that your acquisition clock is not 
active. As other posters indicated, you should check that your acquisition 
clock is active and specified correctly in your SignalTap II file.  You can 
select your acquisition clock by browsing to your clock input from the 
Signal Configuration Pane of the SignalTap II file (.stp).

When the acquisition clock is active and the trigger condition is met, the 
status of the ELA changes to "Acquiring post-trigger data", indicating that 
the Embedded Logic Analyzer (ELA) is acquiring data and filling your 
circular buffer.  When the buffer is full, the status will change to 
"Offloading acquired data" and then to "Ready to acquire".  So I don't think 
you're overwriting your own data, as your first post asked.

When you say you reset the device, what do you mean?  Toggling a reset 
signal on your logic that enables a gated clock would be strange, and I'd 
recommend you switch to using a non-gated clock for your acquisition clock. 
If you are asserting the DEVCLRn pin to do a hardware reset of the device, 
you will have trouble. DEVCLRn clears all registers in the device including 
the ELA registers.  When the ELA registers are cleared, the SignalTap II 
file will not display the correct status until you re-run the analysis by 
choosing Stop Analysis followed by Run Analysis (Processing menu).

It seems most likely that your acquisition clock is incorrectly set in the 
SignalTap II file (.stp), or has strange logic on the clock path, given your 
recent posting.  Hence cleaning up this clock / using another clock would be 
a good idea.

For more info and details, see the SignalTap chapter of the Quartus 
reference manual at http://www.altera.com/literature/hb/qts/qts_qii53009.pdf

Hope this helps,

Vaughn

Altera

[v b e t z (at) altera.com]



Article: 86676
Subject: ModelSim Timing Simulation Signal Names
From: peter@geckoaudio.com
Date: 3 Jul 2005 20:58:03 -0700
Links: << >>  << T >>  << A >>
First time post...

Quick question regarding post PAR simulation. What can be done to
retain sensible signal names when doing post place-and-route (timing)
simulation in ModelSim?

Behavioural simulation retains the nice hierarchical structure of all
instances and their respective signal names, and I would like to find
out whether this is possible for timing simulation, or what is the
closest setup that can be achieved. I have "Retain Hierarchy"
selected under the Simulation Model Properties, and my Simulation Model
Target is ModelSimXE (VHDL). Am using Xilinx ISE 7.1 (SP2) and MXE6.0.


Article: 86677
Subject: Re: interpolation in FPGA
From: peter@geckoaudio.com
Date: 3 Jul 2005 21:06:00 -0700
Links: << >>  << T >>  << A >>

Take a look at the paper writte by Julius Smith from Stanford centre
for computer/music research (google it). It is THE definitive paper on
arbitrary sample rate conversion of band-limited signals.

I'd be intererested to hear if anyone has attempted an FPGA
implementation of sample rate conversion based on his algorithm...

Good luck,
PeterC.


Article: 86678
Subject: xapp 482 and add custom function
From: "im.de" <im.de@gmx.de>
Date: 3 Jul 2005 21:59:25 -0700
Links: << >>  << T >>  << A >>
Hi, there

I am a newbie in fpga area.
I have a question about xps 6.3 mapper
I am creating a project file based on xapp 482 which has a bootloader
function and one can load application code( in C ) to the SRAM.

>From the hardware aspect, I wanna add custom function using FSL.
But as XPS goes through the xflow. It stopped at the map phase.
It has two suggestions came from the tool.

Now the questions
1. I dont know where can change this parameter "-r" and
2. if the "-r" doesnot work, must I change to another board?

actually the user function core has only 1 int array with 40 elements
as input, and 1 int array with 1 element as output.

can somebody tell me why the size turn to so big.
coz i checked the usage of "Number of 4 input LUTs:"
without using the user function is 50%.

#############################
Release 6.3i Map G.38
Xilinx Mapping Report File for Design 'system'

Design Information
------------------
Command Line   : map -o system_map.ncd -pr b system.ngd system.pcf
Target Device  : 3s200
Target Package : ft256
Target Speed   : -4
Mapper Version : spartan3 -- $Revision: 1.16.8.2 $
Mapped Date    : Mon Jul 04 00:44:16 2005

Design Summary
--------------
Number of errors:      0
Number of warnings:   71
Logic Utilization:
  Number of Slice Flip Flops:       1,521 out of   3,840   39%
  Number of 4 input LUTs:           1,924 out of   3,840   50%

   Number of RPM macros:            5
Total equivalent gate count for design:  130,923
Additional JTAG gate count for IOBs:  3,744


project with user function

#########################################
ERROR:Pack:18 - The design is too large for the given device and
package.

If the slice count exceeds device resources you might try to disable
   register ordering (-r).  Also if your design contains AREA_GROUPs,
you may be
   able to improve density by adding COMPRESSION to your AREA_GROUPs if
you
   haven't done so already.


NOTE: An NCD file will still be generated to allow you to examine the
mapped
   design.  This file is intended for evaluation use only, and will not
process
   successfully through PAR.


This mapped NCD file can be used to evaluate how the design's logic has
been
   mapped into FPGA logic resources.  It can also be used to analyze
   preliminary, logic-level (pre-route) timing with one of the Xilinx
static
   timing analysis tools (TRCE or Timing Analyzer).

Design Summary:
Number of errors:      1
Number of warnings:   75
Logic Utilization:
  Number of Slice Flip Flops:       1,793 out of   3,840   46%
  Number of 4 input LUTs:          11,925 out of   3,840  310%
(OVERMAPPED)
Logic Distribution:
  Number of occupied Slices:                        6,580 out of
1,920  342%
(OVERMAPPED)
    Number of Slices containing only related logic:   6,123 out of
6,580   93%
    Number of Slices containing unrelated logic:        457 out of
6,580    6%
      *See NOTES below for an explanation of the effects of unrelated
logic
Total Number 4 input LUTs:         12,929 out of   3,840  336%
(OVERMAPPED)
  Number used as logic:             11,925
  Number used as a route-thru:         579
  Number used for Dual Port RAMs:      264
    (Two LUTs used per Dual Port RAM)
  Number used as Shift registers:      161
  Number of bonded IOBs:               78 out of     173   45%
    IOB Flip Flops:                    74
  Number of Block RAMs:                1 out of      12    8%
  Number of MULT18X18s:                3 out of      12   25%
  Number of GCLKs:                     2 out of       8   25%
  Number of BSCANs:                    1 out of       1  100%

   Number of RPM macros:            5
Total equivalent gate count for design:  226,883
Additional JTAG gate count for IOBs:  3,744
Peak Memory Usage:  163 MB


Thanks for any kinds of tips and helps


Article: 86679
Subject: Re: Hex files in simulation
From: ALuPin@web.de
Date: 3 Jul 2005 23:44:20 -0700
Links: << >>  << T >>  << A >>
Any further suggestions ?

Rgds
Andr=E9


Article: 86680
Subject: DDR controller : problems about burst access
From: "virtex II pro ddr controller(xapp608)" <>
Date: Mon, 4 Jul 2005 01:15:12 -0700
Links: << >>  << T >>  << A >>
I recently tried out DDR controller design from Xilinx(xapp608), and found it does not work properly during simulation when I tried to use full burst read and write. I want to burst for one full row, but the controller always stops after it reaches column 508, I wonder why? Has anybody used this before?

Regards Hongtu

Article: 86681
Subject: Re: ModelSim Timing Simulation Signal Names
From: Jonathan Bromley <jonathan.bromley@doulos.com>
Date: Mon, 04 Jul 2005 09:18:34 +0100
Links: << >>  << T >>  << A >>
On 3 Jul 2005 20:58:03 -0700, peter@geckoaudio.com wrote:

>Quick question regarding post PAR simulation. What can be done to
>retain sensible signal names when doing post place-and-route (timing)
>simulation in ModelSim?

It ain't ModelSim's fault.  The simulator is simulating the signal
names it found in the code it was given.  Synthesis typically 
builds lots of new signals, changes the names of things, optimises
things away and so forth.  Sometimes you can control some of this.
Most times, most of it will change :-)

>Behavioural simulation retains the nice hierarchical structure of all
>instances and their respective signal names

It hardly "retains" it - as I said, the simulator simulates what
it's given.  In the case of behavioural (pre-synthesis) simulation,
what it's given is exactly your source code.

> and I would like to find
>out whether this is possible for timing simulation, or what is the
>closest setup that can be achieved. I have "Retain Hierarchy"
>selected under the Simulation Model Properties, and my Simulation Model
>Target is ModelSimXE (VHDL). Am using Xilinx ISE 7.1 (SP2) and MXE6.0.

Now I'm a little out of my depth, as I don't know ISE all that
well.  It sounds as though you are doing all the sensible things.

Sometimes you can set "don't touch" or similar attributes on objects
such as registers.

Note that synthesis usually flattens all VHDL structures to either
single bit std_logics or to one-dimensional std_logic_vectors,
so if you've used any records or two-dimensional arrays then
their names will almost certainly disappear.  Also, if you have
made any parameterised entities using VHDL generics, the actual
instances after synthesis will probably have component names that
are in some way decorated with the actual values of the generic -
so, for example,

  MyInstance : MyComponent generic map (N=>5) port map...

might appear after synthesis as an instance of a component called
"MyComponent_5" or suchlike.

Sorry to be so unhelpful, but it's a problem!  I guess some ISE
experts will chime in to give you some more specific suggestions.
-- 
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, 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: 86682
Subject: Re: vhdl source code cross reference tool
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 04 Jul 2005 09:38:09 +0100
Links: << >>  << T >>  << A >>
"geoffrey wall" <wallge@eng.fsu.edu> writes:

> Is anyone aware of a software package that can cross reference vhdl language 
> components and
> instantiations of those components?

VHDL-mode of Emacs can do this (if I understand you correctly).

Alternatively, VHDLDoc generates hyperlinked html of your source
files, showing what is instantiated where.  Maybe that helps?  The
manual is here:
http://schwick.home.cern.ch/schwick/vhdldoc/doc/vhdldoc-manual.html

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 86683
Subject: Re: Clock buffering in VirtexE FPGA
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 4 Jul 2005 02:25:23 -0700
Links: << >>  << T >>  << A >>
Thanks alfek for your suggestion.


Article: 86684
Subject: Re: read & write on SDRAM speed with PPC 300 MHz
From: "Pierre" <pierre.detrentinian@cnam.fr>
Date: Mon, 4 Jul 2005 11:47:46 +0200
Links: << >>  << T >>  << A >>
More informations about my configuration:

I use a Virtex-II PRO XC2VP7 FG456-6 development board . The SDRAM is 100
MHz 32 bits ( so I was expecting a speed around 400 MB/s ?)

For testing the writing speed, the programme is :

XGpio_mSetDataReg(XPAR_CARTE_DLP_OUT_BASEADDR, 0x2);// led on
     for(j=0;j<10;j++)
     {
     position_ecriture = START_SDRAM; // start adress of the 32 MB SDRAM
      for (i=0;i<0x7FFFFF;i++){
              *position_ecriture = 1; // writing test
      // k = *position_ecriture;  // reading test
       position_ecriture ++;
       }
     }
 XGpio_mSetDataReg(XPAR_CARTE_DLP_OUT_BASEADDR, 0x3);// led off

I calculate the time between the led turn ON and OFF. When I use memcopy,
it's the same time.  When the INCLUDE_BURST_CACHELN_SUPPORT is activated,
the writing speed is 53 MB/s (and 33 MB/s when not)

2 questions about what was said:
- How can I activate the cache?
- a 64 bits mode exists for the SDRAM ?

Pierre



Article: 86685
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Mon, 04 Jul 2005 14:40:20 +0200
Links: << >>  << T >>  << A >>
Hi,

When you enabled the line, the signal cur_address_r2 is assigned.
But I can't find any uses of the signal, so XST will in any case remove the 
assignment.

Could you also explain more on what the failure is when you enabled the line?
The error condition can explain what the problem is.

Göran


Sidney Cadot wrote:
> Dear all,
> 
> Lately I have been trying to design and implement a synchronous FIFO 
> using a cyclic buffer, that can be synthesized by XST to use Block RAMs.
> 
> I now have a version that works (it does so in simulation using GHDL). I 
> have attached it below. However, since it doesn't follow the prescribed 
> pattern for BLOCK RAM inference, the code as shown synthesizes to an 
> implementation that uses "distributed RAM" instead.
> 
> Fortunately, I can easily get it in a form where BRAM can be inferred by 
> enabling the currently-commented-out line marked "ENABLE FOR BRAM", 
> around line 70.
> 
> The thing is that if I do this, the entity stops functioning as 
> intended. This is particularly strange since (as far as I can tell) the 
> change shouldn't affect the architecture's semantics in any way!
> 
> Any help/pointers by one of the VHDL gurus here would be much appreciated.
> 
> Best regards,
> 
>   Sidney
> 
> ------------- ramfifo.vhdl
> 
> 
> library ieee;
> 
> use ieee.std_logic_1164.all,
>     ieee.numeric_std.all;
> 
> entity RAMFIFO is
>     port(
>         CLK       : in  std_logic;
>         data_in   : in  std_logic_vector(7 downto 0);
>         data_out  : out std_logic_vector(7 downto 0);
>         status    : out std_logic_vector(7 downto 0);
>         reset     : in  std_logic;
>         shift_in  : in  std_logic;
>         shift_out : in  std_logic
>     );
> end entity RAMFIFO;
> 
> architecture arch of RAMFIFO is
> 
>     signal cur_address_r   : unsigned(3 downto 0) := "0000";
>     signal cur_address_r2  : unsigned(3 downto 0) := "0000";
>     signal cur_num_entries : unsigned(3 downto 0) := "0000";
>     signal cur_address_w   : unsigned(3 downto 0);
> 
>     signal nxt_address_r   : unsigned(3 downto 0);
>     signal nxt_num_entries : unsigned(3 downto 0);
> 
>     signal sig_data_r      : std_logic_vector(7 downto 0);
> 
>     type RAMType is array(0 to 15) of std_logic_vector(7 downto 0);
> 
>     -- initialize the ram below with sensible ascii values for debugging
>     signal ram : RAMType := (
>         x"30", x"31", x"32", x"33", x"34", x"35", x"36", x"37",
>         x"38", x"39", x"41", x"42", x"43", x"44", x"45", x"46"
>     );
> 
>     signal shift_in_possible     : std_logic;
>     signal shift_out_possible    : std_logic;
>     signal shift_in_will_happen  : std_logic;
>     signal shift_out_will_happen : std_logic;
> 
> begin
> 
>     status <= std_logic_vector(cur_address_r) & 
> std_logic_vector(cur_num_entries);
> 
>     process (CLK) is
>     begin
>         if rising_edge(CLK) then
>             if reset = '1' then
>                 cur_num_entries <= "0000";
>             else
>                 if shift_in_will_happen = '1' then
>                     ram(to_integer(cur_address_w)) <= data_in;
>                 end if;
>                 cur_address_r   <= nxt_address_r;
>                 cur_num_entries <= nxt_num_entries;
> 
>                 -- if the line below is commented out,
>                 --       XST generates DISTRIBUTED RAM,
>                 --       and the FIFO works properly.
>                 --
>                 -- if the line below is enabled,
>                 --       XST generates BLOCK RAM,
>                 --       and the fifo does not work properly.
> 
>                 -- cur_address_r2  <= nxt_address_r; -- ENABLE FOR BRAM
> 
>             end if;
>         end if;
>     end process;
> 
>     sig_data_r <= ram(to_integer(cur_address_r));
> 
>     with cur_num_entries select
>         data_out <= x"00"      when "0000",
>                     sig_data_r when others;
> 
>     nxt_address_r <= cur_address_r + 1 when shift_out_will_happen = '1'
>                 else cur_address_r;
> 
>     nxt_num_entries <= cur_num_entries + 1 when shift_in_will_happen = 
> '1' and shift_out_will_happen = '0'
>                   else cur_num_entries - 1 when shift_in_will_happen = 
> '0' and shift_out_will_happen = '1'
>                   else cur_num_entries;
> 
>     cur_address_w <= cur_address_r + cur_num_entries;
> 
>     shift_in_will_happen  <= shift_in and shift_in_possible;
>     shift_out_will_happen <= shift_out and shift_out_possible;
> 
>     shift_in_possible  <= '1' when (cur_num_entries /= "1111") or 
> shift_out = '1' else '0';
>     shift_out_possible <= '1' when (cur_num_entries /= "0000") else '0';
> 
> end architecture arch;

Article: 86686
Subject: Re: Clock buffering in VirtexE FPGA
From: "bobrics" <bobrics@gmail.com>
Date: 4 Jul 2005 08:18:34 -0700
Links: << >>  << T >>  << A >>
Hi Ben,

I am just curious how does it work, what you've mentioned above. You
sample a pushbutton signal that bounces, then edge-detect it and make
sure that edge is one system clock wide. As a resullt you have several
SYSTEM_CLK wide edges following push/release. Which one should be
counted as actual push signal? Could you please explain it a bit more.

I've heard of another way to fight with switch bouncing. The trick lies
in using a shift register to input pushbutton signal and an AND gate to
detect all-ones case, which is equivalent to pushed button state.

Regards


Article: 86687
Subject: Xilinx IOB flop mapping vs. -bp switch
From: "schellho" <schellho@yahoo.com>
Date: 4 Jul 2005 08:28:25 -0700
Links: << >>  << T >>  << A >>
A question for the Xilinx guru's out there:

I am experimenting with the map -bp switch (map slice logic) in order
to make better use of device resources.

I am constraining my outputs with IOB = TRUE so that the mapper maps
them to IOB flops. When I use the -bp switch, however, I have an output
flop that is mapped to a block RAM despite the IOB constraint. The
clk-to-out timing specification is unreachable so the map fails with an
error message. I have tried applying the IOB constraint in the verilog
and in the UCF file.

Is there a way to force the mapper to ignore the -bp switch for certain
flops (other than creating and maintaining a mapping file), or am I
stuck with having to choose between IOB packed flops and block RAM
mapping?

I am using ISE6.1i.

Thanks in advance!

    Mark


Article: 86688
Subject: Re: Clock buffering in VirtexE FPGA
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Mon, 4 Jul 2005 17:14:45 +0100
Links: << >>  << T >>  << A >>
Hi bobrics,

> I am just curious how does it work, what you've mentioned above. You
> sample a pushbutton signal that bounces, then edge-detect it and make
> sure that edge is one system clock wide. As a resullt you have several
> SYSTEM_CLK wide edges following push/release. Which one should be
> counted as actual push signal? Could you please explain it a bit more.

Actually, I wasn't giving advice on how to de-bounce a switch, but on how
generally it's a bad idea to clock a register from something that isn't a
clock. However, the circuit I (sort-of) described will work quite well if
you sample at some very slow rate, 1ms or so. That is, the edge-detector
should work on samples from the PBswitch line that are 1ms apart.

For level-detection, your AND-gate-and-shift-register circuit will also
work, but again you should sample (i.e. shift) at a much lower rate than
your system clock. This under-sampling is just a crude low-pass filter on
the input signal.

I'd never bother with an external debounce circuit (not even RC) - in an
FPGA, the simple digital filter is so close to being free it makes no
difference... :-)

        -Ben-



Article: 86689
Subject: Call for FPGAworld 2005
From: david@fpgaworld.com
Date: 4 Jul 2005 09:46:53 -0700
Links: << >>  << T >>  << A >>
The FPGAworld Conference addresses all aspects of digital and
hardware/software system engineering on FPGA technology. It is a
discussion and network forum for researchers and engineers working on
industrial and research projects, state-of-the-art investigations,
development, and applications.

The programme for this year's event will soon be made public. Our
committees are currently in the process of selecting the most
intersting papers.

The number of registered visitors are increasing and the number of
seats are limited so be shure to register in time!

We are also proud to announce that Xilinx, Synplicity and Vinova have
decided to sponsor the conference.

Swedish electronics publication, Elektroniktidningen, is our media
partner for this year's event. More information is available at
http://www.fpgaworld.com/conference


Article: 86690
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: "Unbeliever" <alfkatz@remove.the.bleedin.obvious.ieee.org>
Date: Tue, 5 Jul 2005 04:06:46 +1000
Links: << >>  << T >>  << A >>

"Sidney Cadot" <sidney@jigsaw.nl> wrote in message
news:b9e71$42c80b47$915e9a26$2732@news1.tudelft.nl...
> Dear all,
>
> Lately I have been trying to design and implement a synchronous FIFO
> using a cyclic buffer, that can be synthesized by XST to use Block RAMs.
>
> I now have a version that works (it does so in simulation using GHDL). I
> have attached it below. However, since it doesn't follow the prescribed
> pattern for BLOCK RAM inference, the code as shown synthesizes to an
> implementation that uses "distributed RAM" instead.
>
> Fortunately, I can easily get it in a form where BRAM can be inferred by
> enabling the currently-commented-out line marked "ENABLE FOR BRAM",
> around line 70.
>
/SNIP/
>      process (CLK) is
>      begin
/SNIP/
>      end process;
>
>      sig_data_r <= ram(to_integer(cur_address_r));
>
/SNIP/

Hi Sidney,
    I'm not a guru.  I haven't taken the time to read every line of your
code and  I don't understand how it *ever* infers BRAM.

    It seems to me with my limited knowledge that you need to both write the
FIFO and read the FIFO inside clocked processes.  Looks here, like you're
reading it asynchronously.  If you just put the line:

      sig_data_r <= ram(to_integer(cur_address_r));

after the "else" in your process, I might expect it to infer a BRAM.

Cheers,

--
Alf Katz
alfkatz@remove.the.obvious.ieee.org



Article: 86691
Subject: EDK 6.3, Xilinx ML40x ML402, XBD files
From: "Allan Willcox" <allan@willcox.prodigynet.co.uk>
Date: 4 Jul 2005 12:36:59 -0700
Links: << >>  << T >>  << A >>
Hi All

Does anybody know if an XBD file is available for the Xilinx ML402
board?  I'm currently using EDK6.3 - I'd also be grateful if someone
could tell me whether a BSP for this board comes with EDK7.1.

I've been adding my own plb peripherals to the Xilinx ML402 reference
design, but I've reached a stage now where I really need to start
afresh with a smaller design.  Synthesis and implementation are taking
too long, and aside from my own peripherals, I only really need an
opb2plb_bridge, plb_ddr and perhaps a uart for debugging.


Best regards


Allan Willcox


Article: 86692
Subject: nios2 toolchain sources...
From: Jedi <me@aol.com>
Date: Mon, 04 Jul 2005 20:21:42 GMT
Links: << >>  << T >>  << A >>
Evening...


The NIOS2 sources are only available on the shipped CD's..right?

So...then the downloadble NIOS2 evaluation version breaks the GPL
since it only contains gcc/binutils binaries?


rick

Article: 86693
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: "Alvin Andries" <Alvin_Andries.no_spam@no.spam.versateladsl.be>
Date: Tue, 5 Jul 2005 00:41:46 +0200
Links: << >>  << T >>  << A >>

"Sidney Cadot" <sidney@jigsaw.nl> wrote in message
news:b9e71$42c80b47$915e9a26$2732@news1.tudelft.nl...
> Dear all,
>
> Lately I have been trying to design and implement a synchronous FIFO
> using a cyclic buffer, that can be synthesized by XST to use Block RAMs.
>
> I now have a version that works (it does so in simulation using GHDL). I
> have attached it below. However, since it doesn't follow the prescribed
> pattern for BLOCK RAM inference, the code as shown synthesizes to an
> implementation that uses "distributed RAM" instead.
>
> Fortunately, I can easily get it in a form where BRAM can be inferred by
> enabling the currently-commented-out line marked "ENABLE FOR BRAM",
> around line 70.
>
> The thing is that if I do this, the entity stops functioning as
> intended. This is particularly strange since (as far as I can tell) the
> change shouldn't affect the architecture's semantics in any way!
>
> Any help/pointers by one of the VHDL gurus here would be much appreciated.
>
> Best regards,
>
>    Sidney
>
> ------------- ramfifo.vhdl
>
>
> library ieee;
>
> use ieee.std_logic_1164.all,
>      ieee.numeric_std.all;
>
> entity RAMFIFO is
>      port(
>          CLK       : in  std_logic;
>          data_in   : in  std_logic_vector(7 downto 0);
>          data_out  : out std_logic_vector(7 downto 0);
>          status    : out std_logic_vector(7 downto 0);
>          reset     : in  std_logic;
>          shift_in  : in  std_logic;
>          shift_out : in  std_logic
>      );
> end entity RAMFIFO;
>
> architecture arch of RAMFIFO is
>
>      signal cur_address_r   : unsigned(3 downto 0) := "0000";
>      signal cur_address_r2  : unsigned(3 downto 0) := "0000";
>      signal cur_num_entries : unsigned(3 downto 0) := "0000";
>      signal cur_address_w   : unsigned(3 downto 0);
>
>      signal nxt_address_r   : unsigned(3 downto 0);
>      signal nxt_num_entries : unsigned(3 downto 0);
>
>      signal sig_data_r      : std_logic_vector(7 downto 0);
>
>      type RAMType is array(0 to 15) of std_logic_vector(7 downto 0);
>
>      -- initialize the ram below with sensible ascii values for debugging
>      signal ram : RAMType := (
>          x"30", x"31", x"32", x"33", x"34", x"35", x"36", x"37",
>          x"38", x"39", x"41", x"42", x"43", x"44", x"45", x"46"
>      );
>
>      signal shift_in_possible     : std_logic;
>      signal shift_out_possible    : std_logic;
>      signal shift_in_will_happen  : std_logic;
>      signal shift_out_will_happen : std_logic;
>
> begin
>
>      status <= std_logic_vector(cur_address_r) &
> std_logic_vector(cur_num_entries);
>
>      process (CLK) is
>      begin
>          if rising_edge(CLK) then
>              if reset = '1' then
>                  cur_num_entries <= "0000";
>              else
>                  if shift_in_will_happen = '1' then
>                      ram(to_integer(cur_address_w)) <= data_in;
>                  end if;
>                  cur_address_r   <= nxt_address_r;
>                  cur_num_entries <= nxt_num_entries;
>
>                  -- if the line below is commented out,
>                  --       XST generates DISTRIBUTED RAM,
>                  --       and the FIFO works properly.
>                  --
>                  -- if the line below is enabled,
>                  --       XST generates BLOCK RAM,
>                  --       and the fifo does not work properly.
>
>                  -- cur_address_r2  <= nxt_address_r; -- ENABLE FOR BRAM
>
>              end if;
>          end if;
>      end process;
>
>      sig_data_r <= ram(to_integer(cur_address_r));
>
>      with cur_num_entries select
>          data_out <= x"00"      when "0000",
>                      sig_data_r when others;
>
>      nxt_address_r <= cur_address_r + 1 when shift_out_will_happen = '1'
>                  else cur_address_r;
>
>      nxt_num_entries <= cur_num_entries + 1 when shift_in_will_happen =
> '1' and shift_out_will_happen = '0'
>                    else cur_num_entries - 1 when shift_in_will_happen =
> '0' and shift_out_will_happen = '1'
>                    else cur_num_entries;
>
>      cur_address_w <= cur_address_r + cur_num_entries;
>
>      shift_in_will_happen  <= shift_in and shift_in_possible;
>      shift_out_will_happen <= shift_out and shift_out_possible;
>
>      shift_in_possible  <= '1' when (cur_num_entries /= "1111") or
> shift_out = '1' else '0';
>      shift_out_possible <= '1' when (cur_num_entries /= "0000") else '0';
>
> end architecture arch;

Hi Sidney,

There is one serious flaw in your code: you don't reset the pointers, so
resetting your fifo after some usage will actually bring it in a non-working
state. In my follow-up post, I'll dump some code (entity + lbram and bram
architectures + package + testbench). It does simulate, but I didn't try to
synthesize it. Feel free to use and improve it (you can dump the fifo count
by using the pointers and sacrificing 1 entry).

Regards,
Alvin.



Article: 86694
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: "Alvin Andries" <Alvin_Andries.no_spam@no.spam.versateladsl.be>
Date: Tue, 5 Jul 2005 00:45:20 +0200
Links: << >>  << T >>  << A >>
Here's the code.

Alvin.

-----------------------------------------------------------
-- RAMFIFO.vhd
-----------------------------------------------------------
library ieee;

use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity RAMFIFO is
    generic (
        address_width : POSITIVE := 4
    );
    port (
        CLK       : in  std_logic;
        data_in   : in  std_logic_vector(7 downto 0);
        data_out  : out std_logic_vector(7 downto 0);
        status    : out std_logic_vector(2 * address_width downto 0);
        reset     : in  std_logic;
        shift_in  : in  std_logic;
        shift_out : in  std_logic
    );
end entity RAMFIFO;

-----------------------------------------------------------
-- RAMFIFO_LBRAM.vhd
-----------------------------------------------------------
architecture LBRAM of RAMFIFO is

    signal rd_addr   : unsigned(address_width - 1 downto 0) := (others =>
'0');
    signal wr_addr   : unsigned(address_width - 1 downto 0) := (others =>
'0');
    signal has_data  : boolean := false;

    signal count     : unsigned(address_width downto 0) := (others => '0');

    signal read_data : std_logic_vector(7 downto 0);

    type RAMType is array(0 to 2**address_width - 1) of std_logic_vector(7
downto 0);

    signal ram       : RAMType := (others => (others => '0'));

    signal full      : boolean;
    signal empty     : boolean;
    signal push      : boolean;
    signal pop       : boolean;

begin

    empty <= not has_data;
    full  <= has_data and (rd_addr = wr_addr);
    push  <= not full and (shift_in = '1');
    pop   <= not empty and (shift_out = '1');

    state: process (CLK) is
    begin
        if rising_edge(CLK) then
            if (reset = '1') then
                rd_addr <= (others => '0');
                wr_addr <= (others => '0');
                has_data <= false;
                count <= (others => '0');
            else
                if push then
                    wr_addr <= wr_addr + 1;
                end if;
                if pop then
                    rd_addr <= rd_addr + 1;
                end if;
                if (push and not pop) then
                    count <= count + 1;
                    has_data <= true;
                elsif (not push and pop) then
                    count <= count - 1;
                    has_data <= (count /= 1);
                end if;
            end if;
        end if;
    end process;

    -- LBRAM
    ramdesc: process (CLK) is
    begin
        if rising_edge(CLK) then
            if push then
                ram(to_integer(wr_addr)) <= data_in;
            end if;
        end if;
    end process;
    read_data <= ram(to_integer(rd_addr));

    -- delay by one cycle, clear the data when no pop
    ram_if: process (CLK) is
    begin
        if rising_edge(CLK) then
            if pop then
                data_out <= read_data;
            else
                data_out <= (others => '0');
            end if;
        end if;
    end process;

    status <= std_logic_vector(rd_addr) & std_logic_vector(count);

end architecture LBRAM;

-----------------------------------------------------------
-- RAMFIFO_BRAM.vhd
-----------------------------------------------------------
architecture BRAM of RAMFIFO is

    signal rd_addr   : unsigned(address_width - 1 downto 0) := (others =>
'0');
    signal wr_addr   : unsigned(address_width - 1 downto 0) := (others =>
'0');
    signal has_data  : boolean := false;

    signal count     : unsigned(address_width downto 0) := (others => '0');

    signal read_data : std_logic_vector(7 downto 0);

    type RAMType is array(0 to 2**address_width - 1) of std_logic_vector(7
downto 0);

    signal ram       : RAMType := (others => (others => '0'));

    signal full      : boolean;
    signal empty     : boolean;
    signal push      : boolean;
    signal pop       : boolean;

begin

    empty <= not has_data;
    full  <= has_data and (rd_addr = wr_addr);
    push  <= not full and (shift_in = '1');
    pop   <= not empty and (shift_out = '1');

    state: process (CLK) is
    begin
        if rising_edge(CLK) then
            if (reset = '1') then
                rd_addr <= (others => '0');
                wr_addr <= (others => '0');
                has_data <= false;
                count <= (others => '0');
            else
                if push then
                    wr_addr <= wr_addr + 1;
                end if;
                if pop then
                    rd_addr <= rd_addr + 1;
                end if;
                if (push and not pop) then
                    count <= count + 1;
                    has_data <= true;
                elsif (not push and pop) then
                    count <= count - 1;
                    has_data <= (count /= 1);
                end if;
            end if;
        end if;
    end process;

    -- BRAM
    ramwrdesc: process (CLK) is
    begin
        if rising_edge(CLK) then
            if push then
                ram(to_integer(wr_addr)) <= data_in;
            end if;
        end if;
    end process;

    ramrddesc: process (CLK) is
    begin
        if rising_edge(CLK) then
            if not pop then
                read_data <= (others => '0');  -- reset happens in RAM too
            else
                read_data <= ram(to_integer(rd_addr));
            end if;
        end if;
    end process;

    -- copy bram output
    data_out <= read_data;

    status <= std_logic_vector(rd_addr) & std_logic_vector(count);

end architecture BRAM;

-----------------------------------------------------------
-- RAMFIFO_PCK.vhd
-----------------------------------------------------------
library ieee;

use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

package RAMFIFO_PCK is

    component RAMFIFO
        generic (
            address_width : POSITIVE := 4
        );
        port (
            CLK       : in  std_logic;
            data_in   : in  std_logic_vector(7 downto 0);
            data_out  : out std_logic_vector(7 downto 0);
            status    : out std_logic_vector(2 * address_width downto 0);
            reset     : in  std_logic;
            shift_in  : in  std_logic;
            shift_out : in  std_logic
        );
    end component;

end package RAMFIFO_PCK;

package body RAMFIFO_PCK is
    -- Empty
end package body RAMFIFO_PCK;

-----------------------------------------------------------
-- RAMFIFO_TB.vhd
-----------------------------------------------------------
library ieee;

use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.ramfifo_pck.all;

entity RAMFIFO_TB is
end entity RAMFIFO_TB;

architecture TB1 of RAMFIFO_TB is
    signal clk : std_logic := '0';
    signal reset : std_logic := '0';
    signal data_in : std_logic_vector(7 downto 0) := (others => '1');
    signal shift_in : std_logic := '0';
    signal shift_out : std_logic := '0';
    signal data_out : std_logic_vector(7 downto 0);
    signal status : std_logic_vector(4 + 5 - 1 downto 0);

    type stimulus is record
        reset : std_logic;
        data_in : std_logic_vector(7 downto 0);
        shift_in : std_logic;
        shift_out : std_logic;
    end record;
    type stimuli is array (natural range <>) of stimulus;

    constant max_vector : natural := 68;
    constant vector : stimuli(1 to max_vector) := (
        ('1', x"fe", '0', '0'),          -- reset fifo
        ('0', x"fd", '0', '1'),          -- pop empty
        ('0', x"01", '1', '0'),          -- push 01
        ('0', x"02", '1', '0'),          -- push 02
        ('0', x"03", '1', '0'),          -- push 03
        ('0', x"04", '1', '0'),          -- push 04
        ('0', x"05", '1', '0'),          -- push 05
        ('0', x"06", '1', '0'),          -- push 06
        ('0', x"07", '1', '0'),          -- push 07
        ('0', x"08", '1', '0'),          -- push 08
        ('0', x"09", '1', '0'),          -- push 09
        ('0', x"0a", '1', '0'),          -- push 0A
        ('0', x"0b", '1', '0'),          -- push 0B
        ('0', x"fc", '0', '1'),          -- pop 01
        ('0', x"fb", '0', '1'),          -- pop 02
        ('0', x"fa", '0', '1'),          -- pop 03
        ('0', x"f9", '0', '1'),          -- pop 04
        ('0', x"f8", '0', '1'),          -- pop 05
        ('0', x"f7", '0', '1'),          -- pop 06
        ('0', x"f6", '0', '1'),          -- pop 07
        ('0', x"f5", '0', '1'),          -- pop 08
        ('0', x"f4", '0', '1'),          -- pop 09
        ('0', x"f3", '0', '1'),          -- pop 0a
        ('0', x"f2", '0', '1'),          -- pop 0b
        ('0', x"f1", '0', '1'),          -- pop empty
        ('0', x"10", '1', '0'),          -- push 10
        ('0', x"11", '1', '0'),          -- push 11
        ('0', x"12", '1', '0'),          -- push 12
        ('0', x"13", '1', '0'),          -- push 13
        ('0', x"14", '1', '0'),          -- push 14
        ('0', x"15", '1', '0'),          -- push 15
        ('0', x"16", '1', '0'),          -- push 16
        ('0', x"17", '1', '0'),          -- push 17
        ('0', x"18", '1', '0'),          -- push 18
        ('0', x"19", '1', '0'),          -- push 19
        ('0', x"1a", '1', '0'),          -- push 1a
        ('0', x"1b", '1', '0'),          -- push 1b
        ('0', x"1c", '1', '0'),          -- push 1c
        ('0', x"1d", '1', '0'),          -- push 1d
        ('0', x"1e", '1', '0'),          -- push 1e
        ('0', x"1f", '1', '0'),          -- push 1f
        ('0', x"20", '1', '0'),          -- push 20 -- overflow garanteed
        ('0', x"f0", '0', '1'),          -- pop 10
        ('0', x"ef", '0', '1'),          -- pop 11
        ('0', x"ee", '0', '1'),          -- pop 12
        ('0', x"ed", '0', '1'),          -- pop 13
        ('0', x"ec", '0', '1'),          -- pop 14
        ('0', x"eb", '0', '1'),          -- pop 15
        ('0', x"ea", '0', '1'),          -- pop 16
        ('0', x"e9", '0', '1'),          -- pop 17
        ('0', x"e8", '0', '1'),          -- pop 18
        ('0', x"e7", '0', '1'),          -- pop 19
        ('0', x"e6", '0', '1'),          -- pop 1a
        ('0', x"e5", '0', '1'),          -- pop 1b
        ('0', x"e4", '0', '1'),          -- pop 1c
        ('0', x"e3", '0', '1'),          -- pop 1d
        ('0', x"e2", '0', '1'),          -- pop 1e
        ('0', x"e1", '0', '1'),          -- pop 1f?
        ('0', x"e0", '0', '1'),          -- pop empty (overflow 20)
        ('0', x"30", '1', '1'),          -- Mixed push/pop
        ('0', x"31", '1', '0'),
        ('0', x"df", '0', '1'),
        ('0', x"32", '1', '0'),
        ('0', x"de", '0', '0'),
        ('0', x"33", '1', '0'),
        ('0', x"34", '1', '1'),
        ('0', x"dd", '0', '1'),
        ('0', x"35", '1', '1')
    );

    signal ptr : integer range 1 to max_vector := 1;

begin

    clk <= not clk after 5 ns; -- 100 MHz

    sel: process (clk) is
    begin
        if rising_edge(clk) then
            if (ptr /= max_vector) then
                ptr <= ptr + 1;
            else
                ptr <= 1;
            end if;
        end if;
    end process;

    reset <= vector(ptr).reset;
    data_in <= vector(ptr).data_in;
    shift_in <= vector(ptr).shift_in;
    shift_out <= vector(ptr).shift_out;

    dut : RAMFIFO
        generic map (
            address_width => 4
        )
        port map (
            CLK       => clk,
            data_in   => data_in,
            data_out  => data_out,
            status    => status,
            reset     => reset,
            shift_in  => shift_in,
            shift_out => shift_out
        );
end architecture TB1;



Article: 86695
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: sidney@jigsaw.nl
Date: 4 Jul 2005 16:11:23 -0700
Links: << >>  << T >>  << A >>


G=F6ran Bilski wrote:

> When you enabled the line, the signal cur_address_r2 is assigned.
> But I can't find any uses of the signal, so XST will in any case remove t=
he
> assignment.

No, it will not simply remove the assignment. It will detect
cur_address_r2 as a register that can be used as a BRAM register (in
contrast to cur_address_r, that is used as an expression to calculate
cur_address_w, and cannot therefore be internal to the BRAM). This
explains, I think, why enabling the line makes XST infer BRAMS instead
of distributed RAM.

> Could you also explain more on what the failure is when you enabled the l=
ine?
> The error condition can explain what the problem is.

If I enable the line, the code still compiles perfectly but the
resulting FIFO (now implemented by XST using BRAM) doesn't work as
intended. As you see, I initialize the RAM to "0123456789ABCDEF". When
I hook up the FIFO to a simple RS232-output component, and try to emit
"abcdefghij...." (etc.), I will actually get:

"0123456789ABCDEFabcdefghij......."

So, the bytes I put into the FIFO actually get stored, but they are not
made available on time.

Regards, Sidney


Article: 86696
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: sidney@jigsaw.nl
Date: 4 Jul 2005 16:19:05 -0700
Links: << >>  << T >>  << A >>

>     I'm not a guru.  I haven't taken the time to read every line of your
> code and  I don't understand how it *ever* infers BRAM.

Well, if you remove the comment line, it does :)

>     It seems to me with my limited knowledge that you need to both write the
> FIFO and read the FIFO inside clocked processes.

No, that is not the case. The code is loosely modelled after the sample
VHDL code given in the "XST User's Guide" for a dual-ported,
synchronous BRAM inference. You will see the same pattern there.
Basically, the BRAM is registered; one needs to set the address for
both ports synchronously and the contents will then be available on the
next clock cycle.

> Looks here, like you're
> reading it asynchronously.  If you just put the line:
>
>       sig_data_r <= ram(to_integer(cur_address_r));
>
> after the "else" in your process, I might expect it to infer a BRAM.

It does also when the indicated line is uncommented. Try it! :)

Regards, Sidney


Article: 86697
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: sidney@jigsaw.nl
Date: 4 Jul 2005 16:24:24 -0700
Links: << >>  << T >>  << A >>
Hi Alvin,

> There is one serious flaw in your code: you don't reset the pointers, so
> resetting your fifo after some usage will actually bring it in a non-working
> state.

Why so? I synchronously set only the counter to zero upon reset (this
is by design); there is no reason why "cur_address_r" would need to be
zero as well upon reset. The location "cur_address_r" points to is
immaterial- a FIFO is empty iff cur_num_entries is zero.

> In my follow-up post, I'll dump some code (entity + lbram and bram
> architectures + package + testbench). It does simulate, but I didn't try to
> synthesize it. Feel free to use and improve it (you can dump the fifo count
> by using the pointers and sacrificing 1 entry).

Thanks a lot, I will test this for sure - but I am still curious to
know what goes wrong with my code.

Best regards, Sidney


Article: 86698
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: sidney@jigsaw.nl
Date: 4 Jul 2005 16:32:24 -0700
Links: << >>  << T >>  << A >>

> Here's the code.

Thanks. I hope this was something you had made already and not
something you did specially for me- I'd feel all guilty. :)

One small nit: your line:

push  <= not full and (shift_in = '1');

Couldn't this be replaced by

push  <= (not full or shift_out = '1') and (shift_in = '1');

This would allow shifting into an already full buffer, iff in the same
cycle you are shifting data out.

Regards, Sidney


Article: 86699
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: "Alvin Andries" <Alvin_Andries.no_spam@no.spam.versateladsl.be>
Date: Tue, 5 Jul 2005 01:39:52 +0200
Links: << >>  << T >>  << A >>

<sidney@jigsaw.nl> wrote in message
news:1120519464.755269.123880@z14g2000cwz.googlegroups.com...
> Hi Alvin,
>
> > There is one serious flaw in your code: you don't reset the pointers, so
> > resetting your fifo after some usage will actually bring it in a
non-working
> > state.
>
> Why so? I synchronously set only the counter to zero upon reset (this
> is by design); there is no reason why "cur_address_r" would need to be
> zero as well upon reset. The location "cur_address_r" points to is
> immaterial- a FIFO is empty iff cur_num_entries is zero.
>
> > In my follow-up post, I'll dump some code (entity + lbram and bram
> > architectures + package + testbench). It does simulate, but I didn't try
to
> > synthesize it. Feel free to use and improve it (you can dump the fifo
count
> > by using the pointers and sacrificing 1 entry).
>
> Thanks a lot, I will test this for sure - but I am still curious to
> know what goes wrong with my code.
>
> Best regards, Sidney

Oops,

I was too fast. Normally, I'd create a read and write pointer (because it's
faster than what you're doing). In that case, not resetting both would kill
the fifo. you're using the number of words for address calculation. This
inferes a full adder, which is slower than an increment.

Regards,
Alvin.





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