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 70050

Article: 70050
Subject: Re: Tool to help detecting race conditions with asych inputs?
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Mon, 31 May 2004 17:54:12 +1000
Links: << >>  << T >>  << A >>
On 27 May 2004 23:50:12 -0700, usenet_10@stanka-web.de (Thomas Stanka)
wrote:

>Hello,
>
>do you know any tool, that would help detecting race conditions due to
>asynchronous inputs?

I used to use a tool like this when I was at Agilent.  It was written
in-house (Hi Mark!).

[snip]
>Are there tools, that would help in such cases? I don't like the idea
>to spend hours and days inspecting netlists for asynchronous inputs I
>use to ensure, that this failure won't happen a second time.

Note that a synthesis tool will sometimes *create* races or glitches
(e.g. when a ff used in a sychroniser gets replicated due to fanout -
yes, this happened in real-world designs).
Such problems *cannot* be caught by inspecting the RTL source; the
only way is to look at the post-synth netlist.  We ended up using the
post-PAR back-annotated VHDL netlist (although I guess Verilog would
do just as well).

If you try, you could probably write such a tool in a few days,
assuming you already know how to program in a text processing language
such as Perl.  (I suppose you could use C if you must.)
It is a fairly simple matter to trace all signals in the netlist back
(via combinatorial logic) to either the output of something that is
clocked (which Mark called a synchronous element, e.g. ff, bram, SRL),
or to a pin.

By the time all the feature creep had ended, the tool we used checked
for:

1.  Any clock gating (i.e. if the clock input of any synchronous
element is driven by combinatorial logic).

2.  A list of all clocks used.  You'd be suprised how often extra
clocks turn up, particularly in code written by less experienced
engineers.

3.  Glitches, which we defined as a synchronous element with data
input(s) that could be traced back to more than one source in another
clock domain (including pins).

4.  Races, which we defined as a synchronous element which feeds more
than one synchronous element in a different clock domain.

[Note: I don't think this is quite the same as the classic definition
of glitch and race, but it was ok for our purposes.]

5.  Any use of async set or reset.  It would trace all of these back
to their ultimate source.  (Ideally, this would just be a single pin
called "reset" or something similar.)


We had the problem of integrating large chunks of design written at
multiple sites, and this tool saved lots of time by finding problems
that couldn't be found in simulation and would only show up in the lab
intermittently (e.g. it crashes once every 500 boots).  Indeed, it
found several problems before we even had an inkling a problem
existed!

The majority of our problems were due to cross-clock domain paths
inside a single FPGA, but the same issues could apply to signals
coming from pins.
Prior to the creation of this tool, I estimated about half the debug
time on some projects was due to improperly handled cross clock domain
signals.  Many of the bugs were in "proven" legacy code that had been
"working fine" for years.
There weren't that many bugs, it's just that they took a long time to
find compared with straighforward functional bugs.

Regards,
Allan.

Article: 70051
Subject: Re: Propogation delays and setup times
From: LC Geldenhuys <lcgeldenhuysNOSPAM@mecalc.co.za>
Date: Mon, 31 May 2004 10:00:25 +0200
Links: << >>  << T >>  << A >>
On Sun, 30 May 2004 01:11:09 GMT, Philip Freidin
<philip@fliptronics.com> wrote:

>If you dont' have either the address valid signal, or the address
>does not stay stable for at least 2 cycles, then you have some real
>tough problems to solve.

Philip,

Thank you, your explanations have made a lot of things clear to me. As
this decoder is for the VMEbus, I do indeed have an address valid
strobe, and the solution is now actually quite obvious.

Regards,
  Lourens



Article: 70052
Subject: VHDL warning " Feedback mux " from synplify pro ...thx
From: "Jimmy" <mljiang@eee.hku.hk>
Date: Mon, 31 May 2004 17:18:57 +0800
Links: << >>  << T >>  << A >>
Hi, all ,
        I use syplify to synthesize the following vhdl.  it comes out with
warnings for signal BitSync_temp, pnt.   It seems from the coding logic it
can't have the mux problem since the assignment conditions exclude each
other...(to my understanding), could you give me some comments , thanks
first.

Warning:
@W: CL113 : Feedback mux created for signal BitSync_temp.
@W: CL113 :  Feedback mux created for signal pnt[6:0].

process(Clk, Reset,MaxSearchEn)
variable  pnt  : std_logic_vector(6 downto 0);  -- integer range 87 downto
0;   88= 101 1000
begin
    if (Reset = '1') then
       pnt  :=  (others => '0');
       BitSync_temp <= '0';
                                 ....
   elsif  (Clk'event and Clk = '1' and MaxSearchEn = '1')  then

                                 ....

         if (pnt < "1011000") then
             pnt := pnt + '1';
         else
             pnt := (others => '0');

            if (PeakValue(BitWidth+6 downto 3) >= "011111111111" ) then
                 BitSync_temp <= '1';
            else
                BitSync_temp <= '0';
            end if;

         end  if;

  end if;
end process;

regards,
Jimmy



Article: 70053
Subject: EDK 6.1
From: pankaj537@yahoo.co.in (Pankaj Sharma)
Date: 31 May 2004 02:45:39 -0700
Links: << >>  << T >>  << A >>
I'm trying to integrate a custom IP peripheral
in MicroBlaze based system.
I am facing a problem. I've added the custom peripheral in my design
using import peripheral wizard. But i am not able to associate an
interrupt handler for it. The following error is appearing.

ERROR:MDT - Y:\Sum-term-proj\Test\try6\ctr.mss_temp:50 -
interrupt_handler is not a configurable parameter for driver generic

I've tried to change mdd file of driver generic. 

Could someone tell me how i can add any dummy driver other than
generic?(The GUI by default shows generic or <NONE> as the drivers)

Adding the following line in mdd file of driver generic does not help.
PARAMETER int_handler = ctr_int_handler, int_port = ovrfl

Neither do the following:
PARAM name = int_handler, default = ctr_int_handler, desc = "Name of
Interrupt Handler", type = string;
PARAM name = int_port, default = ovrfl, desc = "Interrupt pin
associated with the interrupt handler", permit = none;

Thanks,
Pankaj Sharma.

Article: 70054
Subject: Re: VHDL warning " Feedback mux " from synplify pro ...thx
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Mon, 31 May 2004 19:53:44 +1000
Links: << >>  << T >>  << A >>
On Mon, 31 May 2004 17:18:57 +0800, "Jimmy" <mljiang@eee.hku.hk>
wrote:

>process(Clk, Reset,MaxSearchEn)

change to 

>process(Clk, Reset)

You don't really want the process sensitive to events on MaxSearchEn,
I assume that signal is meant to be a clock enable.

Regards,
Allan.

Article: 70055
Subject: Re: VHDL warning " Feedback mux " from synplify pro ...thx
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Mon, 31 May 2004 21:16:55 +1000
Links: << >>  << T >>  << A >>
On Mon, 31 May 2004 19:53:44 +1000, Allan Herriman
<allan.herriman.hates.spam@ctam.com.au.invalid> wrote:

>On Mon, 31 May 2004 17:18:57 +0800, "Jimmy" <mljiang@eee.hku.hk>
>wrote:
>
>>process(Clk, Reset,MaxSearchEn)
>
>change to 
>
>>process(Clk, Reset)
>
>You don't really want the process sensitive to events on MaxSearchEn,
>I assume that signal is meant to be a clock enable.

Also, your clock enabled processes should look something like:

label : process(clk, reset)
begin
  if reset = '1' then
    ...
  elsif rising_edge(clk) then
    if clk_enable = '1' then
      ...
    end if;
  end if;
end process;

Comments:
1.  You don't need () around the condition in an IF statement.  You're
not writing C (or Verilog)!

2.  rising_edge(clk) is a lot clearer than clk'event and clk='1'.
There are some minor semantic differences that probably won't worry
you.

3.  Use separate IF statements for the rising_edge and clk_enable
parts.  It's easier to read, and some synthesisers may have problems
if they're combined into the one condition.

4.  VHDL doesn't force you to label processes, but I find it makes it
easier to read the code if they are labeled, assuming you choose
labels sensibly.

Regards,
Allan.

Article: 70056
Subject: Serial I/O Standards
From: vbishtei@hotmail.com (vadim)
Date: 31 May 2004 07:45:17 -0700
Links: << >>  << T >>  << A >>
Anybody knows a good reference with all the 
specs for the various I/O standards such as:

SSTL, HST, GTL, CTT, LVCMOS, LVPCML, LVTTL and others ?

I tried everywhere but couldn't find much. Is there some 
book like Electrical Engineering Reference Book that has
these standards ???

Article: 70057
Subject: Re: Serial I/O Standards
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Tue, 01 Jun 2004 01:32:17 +1000
Links: << >>  << T >>  << A >>
On 31 May 2004 07:45:17 -0700, vbishtei@hotmail.com (vadim) wrote:

>Anybody knows a good reference with all the 
>specs for the various I/O standards such as:
>
>SSTL, HST, GTL, CTT, LVCMOS, LVPCML, LVTTL and others ?
>
>I tried everywhere but couldn't find much. Is there some 
>book like Electrical Engineering Reference Book that has
>these standards ???

http://www.jedec.org/ might be a good place to start.

It also defines things like pinouts on ram modules, etc.

Allan.

Article: 70058
Subject: solderless breadboard + fpga + smt-adaptable socket?
From: Adam Megacz <adam@megacz.com>
Date: Mon, 31 May 2004 16:07:35 -0700
Links: << >>  << T >>  << A >>

Please forgive me if I screw up some of the terminology here, I'm new
to actual physical manipulation of hardware...

I'm looking for a quick, cheap solution that will give me some
solderless breadboard space, a socket that I can put an SMT chip into
(probably via some sort of adapter, which is okay), and a Xilinx or
Altera low-end FPGA.  A cyclone would probably be ideal since I need
very few gates -- "no FPGA too small" and I'm trying to keep costs
down.

Basically I'm looking for this with an FPGA already on it:

  http://www.axman.com/education/edc_hc11.html

I'm looking for this because I just stumbled across a supply of very
cheap (but somewhat nonstandard) GPS chips, and I need to test out the
samples I got before I order more.  I'd also like to reuse this board
later for other similar projects.

I'll also need some way of programming the FPGA from a computer; JTAG
or serial is fine, USB would be even better.

Thanks!

  - a

-- 
"The first time I read this book I felt what I could only explain as a
 great disturbance in the Force: it was as if a billion washing
 machinces all became unbalanced at once and were suddenly silenced."

                             -- anonymous book reviewer on Amazon.com

Article: 70059
Subject: Is this a bug in ISE 6.1?
From: "Kelvin" <student@nowhere.com>
Date: Tue, 1 Jun 2004 09:20:14 +0800
Links: << >>  << T >>  << A >>
It seems to me, the NGDBuild can't differentiate two XCF constraints
which are brought in by the NGC files...

I put a clock period of 14.58ns in XCF for XST synthesis.
Then I put a UCF constraint of 23.085ns for partially P&R
on two sides of my XC2V6000...When I started to assemble
them, the NGDBuild gave me this error:

ERROR:XdmHelpers:682 - Second definition of specification "TS_clk_in" found:
   first definition: PERIOD:clk_in:14580.000000:pS:HIGH:50.000000%
   second definition: PERIOD "clk_in" 14580.000000 pS HIGH 50.000000 %
WARNING:XdmHelpers:681 - UCF definition of specification "TS_clk_in"
overrides
   the definition found in the netlist or NCF file:
   UCF: PERIOD "clk_in" 23085.000000 pS HIGH 50.000000 %
   netlist/NCF: PERIOD:clk_in:14580.000000:pS:HIGH:50.000000%


How may I handle this sort of awkward situation?

Kelvin





Article: 70060
Subject: Re: solderless breadboard + fpga + smt-adaptable socket?
From: "Jean Nicolle" <j.nicolle@sbcglobal.net>
Date: Tue, 01 Jun 2004 02:34:28 GMT
Links: << >>  << T >>  << A >>
Instead of an FPGA board that includes a breadboard, why not a breadboard
where you plug a "DIP" FPGA board?
Like this http://www.fpga4fun.com/board_pluto-II.html ?

You populate the board sides with headers and it becomes a 24 pins "FPGA DIP
chip".
You configure it through a PC's serial port.

Jean



Article: 70061
Subject: DLL- Change in input clock source --Suggestions plz
From: rajes_kumar@yahoo.com (Rajesh Murugesan)
Date: 1 Jun 2004 01:46:23 -0700
Links: << >>  << T >>  << A >>
rajes_kumar@yahoo.com (Rajesh Murugesan) wrote in message news:<5b293f11.0405241143.1d54258e@posting.google.com>...
> td@emu.com (Tony Dean) wrote in message news:<33aa9b10.0405181256.7895fada@posting.google.com>...
> 
> > I have the same requirement and have successfully generated a reset
> > signal for the CLKDLL, so I know it can be done. It looks something
> > like this:
> > 
> > dll : CLKDLL port map ( 
> >   CLKIN => clk,
> >   CLKFB => clkfb,
> >   RST => dll_reset,
> >   etc.
> >   );
> > 
> > dll_reset <= error1 OR error2; -- error1, error2 generated by internal
> > logic
> > 
> > Good luck!
> > -td

******
Hi

I tried to generate the reset signal for the CLKDLL, where the reset
signal is generated by internal logic (thnx to Tony!!!).Still I get
errors when I tried to implement the design. If i dont use the reset
pin of the DLL(ie, when the reset pin is tied to ground), there are no
errors. Since there is change in input frequency, manual reset is
mandatory. Device: Spartan II

To Tony: Did you use a change in input frequency and if so..how did
you activate and de-activate the reset signal when there is a change
in input frequency?

CODE:
 rst_a, rst_b : signal
 f_done_prog, f_start_prog_pll : input
 rst_out: output

<<if modu_clk'event and modu_clk = '1' then
   if (div16_clk_counter(3)='0' and sclk_div16='1') then
	case reset_status is
		when rst_boot =>
		  	rst_out <= rst_a OR rst_b;
	 	  	reset_status <= rst_0;
		when rst_0 =>
			if f_done_prog_pll ='1' then
				rst_a <= '0';
				rst_b <= '0';
				reset_status <= rst_1;
			end if;
	 	when rst_1 =>
			rst_out <= rst_a OR rst_b;
			reset_status <= rst_2;
		when rst_2 =>
			if f_start_prog_pll = '0' then
				rst_b <= '1';		
				reset_status <= rst_3;
			end if;
		when rst_3 =>
			rst_out <= rst_a OR rst_b;
			reset_status <= rst_0;
         	end case;


dll : CLKDLL port map ( 
   CLKIN => clk,
   CLKFB => clkfb,
   RST => rst_out,
   etc.
   );
**************************
ERRORS:
ERROR:NgdBuild:455 - logical net 'rst_rst_out' has multiple drivers.
The
   possible drivers causing this are:
     pin Q on block rst_rst_out with type FDE,
     pin PAD on block rst_rst_out.PAD with type PAD
ERROR:NgdBuild:466 - input pad net 'rst_rst_out' has illegal
connection.
   Possible pins causing this are:
     pin Q on block rst_rst_out with type FDE,
     pin I0 on block rst__n000812_SW0 with type LUT3

Also..Checked the RTL-schematic and could not find any multiple
drivers or an illegal connection. Am I doing wrond anywhere.
Suggestions please!!!

Thanks in advance.

Regards
Rajesh


Article: 70062
Subject: Configration............problem..............
From: arvindstomar@india.com (arvind)
Date: 1 Jun 2004 02:22:32 -0700
Links: << >>  << T >>  << A >>
I am using xc2s30 -5 pq144 fpga when i am programming through
jatag(slave serial using ISE4.2i) this device programmed successfully
but when i am trying to configure using prom xc18v02 pc44 the FPGA is
not getting configured and the done is not getting high the cclk is
coming from FPGA continues and the data from prom is comes power-on we
seen on oscilloscope. the init and programme pin high and the cclk is
4mhz coming continues.
In prom xc18v series data sheet the recommended prom for xc2s30 is
xc18v512 so i want to know can i use this xc18v02 for xc2s30 or i have
to use xc18v512 only.
I used xc18v02 prom to configure xc2s100 and xc2s200 it is working
fine so what is the difference in xc2s30.
xc18v02 is recommended for xc2s200 but it is configuring xc2s100 fpga
so it should configure xc2s30 also.

Thanks.


Article: 70063
Subject: Re: Is this a bug in ISE 6.1?
From: "lee news" <l.ainscough@ntlworld.com>
Date: Tue, 1 Jun 2004 11:58:28 +0100
Links: << >>  << T >>  << A >>



This is a warning that tells you that the XST / PAR has used the last =
constraint set in the UCF file.

Xilinx allows multiple constrainst to be set, but if more than one is =
used the UCF file will have priority.

I think it goes something like EDIF file constraint to NCF file to UCF =
file etc.

With UCF file setting the priority. i.e. the user can override what an =
IP provider has stated in the EDIF or NCF for a particular place and =
route run in the UCF.

Good Luck

ExpressIP LTD



Article: 70064
Subject: Re: DLL - Change in input frequency (CLKIN)
From: "lee news" <l.ainscough@ntlworld.com>
Date: Tue, 1 Jun 2004 13:22:38 +0100
Links: << >>  << T >>  << A >>

Yes this is possible.

See our downloadable design examples, specifically the  clocks file, I haves
assumed Xilinx and XST flow etc.

This does more than what you want, as it synchronises some external SDRAM
memorys too.

rs_sys comes from an input buffer (IBUF) etc.

Good Luck


----------------------------------------------------------------------------
----------
-- (c) Copyright [2003] ExpressIP Ltd.  All rights reserved.
----------------------------------------------------------------------------
----------
-- The copyright in this material is owned by ExpressIP Ltd ("ExpressIP").
--
-- The contents of this file are subject to the ExpressIP License Agreement.
--
-- You may not use this file except in compliance with the ExpressIP Licence
Agreement.
--
--   See the ExpressIP web site for LICENSE Agreement details.
--
--   The ExpressIP Licence Agreement is to be used over and above all other
agreements.
--
--   This source file may be used and distributed subject to the
--   licence and provided this copyright statement is not
--   removed from the file and that any derivative work contains
--   the original copyright notice and the associated disclaimer.
--
--   THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY
--   EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
--   TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
--   FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL THE AUTHOR
--   OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
--   INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
--   (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
--   GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
--   BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
--   LIABILITY, WHETHER IN  CONTRACT, STRICT LIABILITY, OR TORT
--   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
--   OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
--   POSSIBILITY OF SUCH DAMAGE.
--
----------------------------------------------------------------------------
----------
----------------------------------------------------------------------------
----------
                                                                          --



LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;


-- synthesis translate_off
LIBRARY unisim;
USE unisim.ALL;
-- synthesis translate_on


ENTITY ExpressIP_clks IS
    PORT(
        ra_sys                    : IN    STD_LOGIC
; -- System asynchronous reset.
        cki_sys                   : IN    STD_LOGIC
; -- 27MHz raw clock in from osc.
  ckr_sys                   : OUT   STD_LOGIC
; -- 54MHZ (x2) System clock output for use inside FPGA, clock tree output.

        cki_capt                  : IN    STD_LOGIC
; -- capture clock.
        ckr_capt                  : OUT   STD_LOGIC
; -- capture clock.
        ckr_capt_dir              : OUT   STD_LOGIC
; -- capture clock direct.


        cko_54MHz_1               : OUT   STD_LOGIC
; -- 54MHZ (x2) System clock output for use outside FPGA, with sdrams.
        cki_54MHz_1              : IN    STD_LOGIC
; -- feedback version of cko_54MHz_1 for DLL in EpressIP_clks.vhd, used to
synchronise the clocks.

        cko_54MHz_2               : OUT   STD_LOGIC
; -- 54MHZ (x2) System clock output for use outside FPGA, with sdrams.
        cki_54MHz_2              : IN    STD_LOGIC
; -- feedback version of cko_54MHz_2 for DLL in EpressIP_clks.vhd, used to
synchronise the clocks.

        op_dlls_capt_locked    : OUT   STD_LOGIC
; -- indicates the DLL's are settled
        op_dlls_locked_extd    : OUT   STD_LOGIC
; -- indicates the DLL's are settled but delayed so that the pulse can be
used in a state machine etc.
        op_dlls_locked            : OUT
            -- indicates the DLL's are settled.
        );
END ExpressIP_clks;

ARCHITECTURE asic OF ExpressIP_clks IS


COMPONENT CLKDLL
PORT (clkin, clkfb, rst  : IN STD_LOGIC;
      clk0, clk90, clk180, clk270, clk2x, clkdv, locked : OUT STD_LOGIC);
END COMPONENT;

COMPONENT IBUFG
PORT (I : IN STD_LOGIC; O : OUT STD_LOGIC);
END COMPONENT;

COMPONENT BUFG
PORT (I : IN STD_LOGIC; O : OUT STD_LOGIC);
END COMPONENT;

COMPONENT OBUF
PORT (I : IN STD_LOGIC; O : OUT STD_LOGIC);
END COMPONENT;


COMPONENT SRL16E
 PORT (D                 : IN    STD_LOGIC                            ;
       CLK               : IN    STD_LOGIC                            ;
       Q                 : OUT   STD_LOGIC                            ;
       CE                : IN    STD_LOGIC                            ;
    A3                : IN    STD_LOGIC                            ;
    A2                : IN    STD_LOGIC                            ;
    A1                : IN    STD_LOGIC                            ;
    A0                : IN    STD_LOGIC
    );
END COMPONENT;

SIGNAL s_ra_sys                             : STD_LOGIC
;

SIGNAL s_logic1                             : STD_LOGIC  := '1'
;
SIGNAL s_clk_in_ibuf                        : STD_LOGIC
;
SIGNAL s_clk_fb_ibuf                        : STD_LOGIC
;
SIGNAL s_clk_108_ibuf                       : STD_LOGIC
;
SIGNAL s_clk_dllx2_ext                      : STD_LOGIC
;
SIGNAL s_dll_locked_ext                     : STD_LOGIC
;
SIGNAL s_cko_54MHz                          : STD_LOGIC
;
SIGNAL s_clk_dllx2_int                      : STD_LOGIC
;
SIGNAL s_dll_locked_int                     : STD_LOGIC
;
SIGNAL s_clk_a_out                          : STD_LOGIC
;
SIGNAL s_clk_dllx4_int                      : STD_LOGIC
;
SIGNAL s_clk_108_out                        : STD_LOGIC
;
SIGNAL s_clk_dllx4_ext                      : STD_LOGIC
;
SIGNAL s_op_dlls_locked                     : STD_LOGIC
;
SIGNAL s_dll_locked_int_dly                 : STD_LOGIC
;
SIGNAL s_dll_locked_int_dly_inv             : STD_LOGIC
;
SIGNAL s_dll_locked_ext_dly                 : STD_LOGIC
;
SIGNAL s_dll_locked_ext_dly_inv             : STD_LOGIC
;
SIGNAL s_op_dlls_locked_extd                : STD_LOGIC
;
SIGNAL s_op_dlls_locked_extdd               : STD_LOGIC
;
SIGNAL s_dll_locked_108int                  : STD_LOGIC
;
SIGNAL s_read_addr                          : STD_LOGIC_VECTOR(3 DOWNTO 0)
;


SIGNAL s_clk_capt_ibuf                      : STD_LOGIC
;
SIGNAL s_clk_capt_int                       : STD_LOGIC
;
SIGNAL s_clk_capt_out                       : STD_LOGIC
;
SIGNAL s_dll_locked_capt                    : STD_LOGIC
;


BEGIN

  s_ra_sys <= NOT(ra_sys) ;

  ibufg_i0  : IBUFG
    PORT MAP (
              I  => cki_sys                 ,
     O  => s_clk_in_ibuf
       );

 ibufg_i1  : IBUFG
   PORT MAP (
             I => cki_54MHz_1                   ,
             O => s_clk_fb_ibuf
            );


 ibufg_i2  : IBUFG
   PORT MAP (
             I => cki_54MHz_2                   ,
             O => s_clk_108_ibuf
            );

  clkdll_i0    : CLKDLL
     PORT MAP (
               CLKIN  => s_clk_in_ibuf                       ,
               CLKFB  => s_clk_a_out                         ,
               RST    => s_ra_sys                            ,
               CLK2X  => s_clk_dllx2_int                     ,
               clk0   => OPEN                                ,
               clk90  => OPEN                                ,
               clk180 => OPEN                                ,
               clk270 => OPEN                                ,
               clkdv  => OPEN                                ,
               LOCKED => s_dll_locked_int
              );

   bufg0   : BUFG
      PORT MAP (
                I => s_clk_dllx2_int                          ,
                O => s_clk_a_out
               );

   ckr_sys    <= s_clk_a_out                                 ;


   ExpressIP_pipe_srl16_1_i0 : srl16e
         PORT MAP (
               CLK      => s_clk_in_ibuf                      ,
               D        => s_dll_locked_int             ,
               Q        => s_dll_locked_int_dly         ,
                  CE       => s_logic1                     ,
            A3       => s_read_addr(3)               ,
            A2       => s_read_addr(2)               ,
            A1       => s_read_addr(1)               ,
            A0       => s_read_addr(0)
            );


   s_dll_locked_int_dly_inv <= NOT(s_dll_locked_int_dly) ;

   clkdll_i1    : CLKDLL
     PORT MAP (
               CLKIN  => s_clk_a_out                         ,
               CLKFB  => s_clk_fb_ibuf                       ,
               RST    => s_dll_locked_int_dly_inv            ,
               CLK2X  => s_clk_dllx4_ext                     ,
               clk0   => s_clk_dllx2_ext                     ,
               clk90  => OPEN                                ,
               clk180 => OPEN                                ,
               clk270 => OPEN                                ,
               clkdv  => OPEN                                ,
               LOCKED => s_dll_locked_ext
              );

   obuf_i1   : OBUF
      PORT MAP (
                I => s_clk_dllx2_ext         ,
                O => s_cko_54MHz
               );

   cko_54MHz_1   <= s_cko_54MHz                ;


   ExpressIP_pipe_srl16_1_i1 : srl16e
         PORT MAP (
               CLK      => s_clk_in_ibuf                      ,
               D        => s_dll_locked_ext             ,
               Q        => s_dll_locked_ext_dly         ,
                  CE       => s_logic1                     ,
            A3       => s_read_addr(3)               ,
            A2       => s_read_addr(2)               ,
            A1       => s_read_addr(1)               ,
            A0       => s_read_addr(0)
            );


  s_dll_locked_ext_dly_inv <= NOT(s_dll_locked_ext_dly) ;

  clkdll_i2    : CLKDLL
     PORT MAP (
               CLKIN  => s_clk_a_out              ,
               CLKFB  => s_clk_108_ibuf           ,
               RST    => s_dll_locked_ext_dly_inv ,
               CLK2X  => OPEN                     ,
               clk0   => s_clk_dllx4_int          ,
               clk90  => OPEN                     ,
               clk180 => OPEN                     ,
               clk270 => OPEN                     ,
               clkdv  => OPEN                     ,
               LOCKED => s_dll_locked_108int
              );


  obuf1   : OBUF
     PORT MAP (
               I => s_clk_dllx4_int               ,
               O => s_clk_108_out
              );

  cko_54MHz_2    <= s_clk_108_out ;


  s_op_dlls_locked <= s_dll_locked_ext;

  op_dlls_locked   <= s_op_dlls_locked_extd ;


  ExpressIP_pipe_srl16_1_i2 : srl16e
           PORT MAP (
                 CLK      => s_clk_in_ibuf                      ,
                 D        => s_op_dlls_locked             ,
                 Q        => s_op_dlls_locked_extd        ,
                  CE       => s_logic1                     ,
              A3       => s_read_addr(3)               ,
              A2       => s_read_addr(2)               ,
              A1       => s_read_addr(1)               ,
              A0       => s_read_addr(0)
              );


    s_read_addr <= (OTHERS => '1' ) ;

    ExpressIP_pipe_srl16_1_i3 : srl16e
           PORT MAP (
                 CLK      => s_clk_in_ibuf                      ,
                 D        => s_op_dlls_locked_extd        ,
                 Q        => s_op_dlls_locked_extdd       ,
                  CE       => s_logic1                     ,
              A3       => s_read_addr(3)               ,
              A2       => s_read_addr(2)               ,
              A1       => s_read_addr(1)               ,
              A0       => s_read_addr(0)
              );




  op_dlls_locked_extd <= s_op_dlls_locked_extdd ;





-- capture clock

  ibufg_i3  : IBUFG
    PORT MAP (
              I  => cki_capt       ,
       O  => s_clk_capt_ibuf
         );


  clkdll_i3    : CLKDLL
     PORT MAP (
               CLKIN  => s_clk_capt_ibuf                     ,
               CLKFB  => s_clk_capt_out                      ,
               RST    => s_ra_sys                            ,
               CLK2X  => OPEN                                ,
               clk0   => s_clk_capt_int                      ,
               clk90  => OPEN                                ,
               clk180 => OPEN                                ,
               clk270 => OPEN                                ,
               clkdv  => OPEN                                ,
               LOCKED => s_dll_locked_capt
              );

   bufg1   : BUFG
      PORT MAP (
                I => s_clk_capt_int                          ,
                O => s_clk_capt_out
               );


   ckr_capt               <= s_clk_capt_out                  ;
   ckr_capt_dir           <= s_clk_capt_ibuf                 ;

   op_dlls_capt_locked   <= s_dll_locked_capt               ; -- indicates
the DLL's are settled





END asic;

ExpressIP LTD

"Rajesh Murugesan" <rajes_kumar@yahoo.com> wrote in message
news:5b293f11.0405172336.39ea9f62@posting.google.com...
> Hi all,
>
> In my design, DLL is used to multiply the input frequency at the
> factor of 2. Since the input source clock is from the external PLL
> (Generates 2 different frequency---Change in input frequency), a
> manual reset is mandatory. When I tried to generate an INTERNAL SIGNAL
> and mapped to the reset signal (RST) of the DLL, there were errors as
> mentioned below:
>
> ERROR:NgdBuild:455 - logical net 'rst_in' has multiple drivers. The
> possible
>    drivers causing this are:
>      pin G on block XST_GND with type GND,
>      pin PAD on block rst_in with type PAD
> ERROR:NgdBuild:466 - input pad net 'rst_in' has illegal connection.
>
> Would the design implementation in FPGA allow the user to map an
> internally generated reset signal to the reset signal of the DLL?
>
> Tool: Xilinx ISE 6.2i
>
> Device: Spartan XC2S200
>
> Eagerly waiting for your suggestions..
>
> Thanks in advance
>
> Regards
> Rajesh



Article: 70065
Subject: Testing a lot of FPGA
From: iker@wanadoo.fr (Iker Pryszo)
Date: 1 Jun 2004 05:34:14 -0700
Links: << >>  << T >>  << A >>
Hello, I am currently working with spartan2E FPGA (series 200). Is
there a solution to test a great number of FPGA quickly (in order to
make some statistical measurement) ? Simplest would be to use standard
PC84 package to clip the various FPGA on an home made test board, but
none of the Spartan2E exist in this package. Would somebody have an
idea preventing me from welding and unsolder the different FPGA ? I
specify that I need only little I/O.
Thanks

Article: 70066
Subject: Re: Malfunctioning dual port block ram.
From: spr <raphael.spiess@REMOVEMEhevs.ch>
Date: Tue, 1 Jun 2004 05:54:36 -0700
Links: << >>  << T >>  << A >>
I had this problem with leonardo version 2001. I've just 
changed to leonardo 2002 and it was working well.



Article: 70067
Subject: NIOS 2 memory limitations
From: george.martin@att.net (George)
Date: 1 Jun 2004 07:29:36 -0700
Links: << >>  << T >>  << A >>
I'm converting a NIOS design to a NIOS 2 design.  The end product has
a large number of 256MBit FLASH devices (19).  I've mapped all the
periferrals to low mamory 0x000 to 0x2000 and then one 256 MBit SDRAM
0x0200 0000 (spaces added for clarity)  I then start adding FLASH
devices at 0x0400 0000.  All goes well till I try to place FLASH at
0x1000 0000.  I get a compiler error messages: "Address range of
instruction master crossing a 256 MByte boundary. Not supported"

My questions are:  Did I do something wrong?  Is this a bug or for
real? How can I handle large memory designs?  How can I make some of
the FLASH data and ont instructin memory and will that help?

Thanks
George

Article: 70068
Subject: Problem with carry reusing RPM with ISE 6.2i and VirtexE
From: yvan.eustache1@etud.univ-ubs.fr (yvan.eustache1@etud.univ-ubs.fr)
Date: 1 Jun 2004 07:42:38 -0700
Links: << >>  << T >>  << A >>
Hi 

First, excuse me for my english, Im a french student. 

Then, I have problems to reuse RPM with ISE 6.2i and VirtexE : 

I have cut a project in macros which are relationnaly placed. 
I want to reuse those macros in another project but the Translate 
shows me errors : 
------ERROR:NgdBuild:753 - Line 3 in 'emis.ucf': Could not find 
instance(s) 
   'b_emisq/b_opp/Madd_s_inst_cy_34' in the design.  To suppress this 
error 
   specify the correct instance name or remove the constraint. 
or 
------ERROR:NgdBuild:753 - Line 4 in 'emis.ucf': Could not find 
instance(s) 
   'b_emisq/b_opp/Madd_s_inst_sum_34' in the design... 
... 

The carry logic and sum logic make errors because (I think) during the 
resynthesise of the macros ISE changes the name of carry logic and sum 
logic. 

There's no error with the others logic, and I can reuse all macros 
which have no carry chain. 

Do you know those errors and how I can resolve them ? 

Thank you 

Yvan EUSTACHE

Article: 70069
Subject: Re: NIOS 2 memory limitations
From: "David Brown" <david@no.westcontrol.spam.com>
Date: Tue, 1 Jun 2004 16:49:17 +0200
Links: << >>  << T >>  << A >>

"George" <george.martin@att.net> wrote in message
news:e9d879fa.0406010629.27219b22@posting.google.com...
> I'm converting a NIOS design to a NIOS 2 design.  The end product has
> a large number of 256MBit FLASH devices (19).  I've mapped all the
> periferrals to low mamory 0x000 to 0x2000 and then one 256 MBit SDRAM
> 0x0200 0000 (spaces added for clarity)  I then start adding FLASH
> devices at 0x0400 0000.  All goes well till I try to place FLASH at
> 0x1000 0000.  I get a compiler error messages: "Address range of
> instruction master crossing a 256 MByte boundary. Not supported"
>
> My questions are:  Did I do something wrong?  Is this a bug or for
> real? How can I handle large memory designs?  How can I make some of
> the FLASH data and ont instructin memory and will that help?
>

You can choose whether the memory banks are connected to the instruction
master and/or the data master.  It sounds like there is a limitation in the
Nios II regarding the width of instruction addresses (probably so that an
absolute call or jump can fit within a single instruction), but that should
not affect the data access (presumably this range is mostly data?).
Deselect the instruction master connection from the data banks, and see if
that helps.




Article: 70070
Subject: Re: Serial I/O Standards
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 01 Jun 2004 10:56:20 -0500
Links: << >>  << T >>  << A >>
>Anybody knows a good reference with all the 
>specs for the various I/O standards such as:
>
>SSTL, HST, GTL, CTT, LVCMOS, LVPCML, LVTTL and others ?

FPGA data sheets?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 70071
Subject: Re: Problem with carry reusing RPM with ISE 6.2i and VirtexE
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 1 Jun 2004 09:27:17 -0700
Links: << >>  << T >>  << A >>
Cher Yvan,
Two suggestions.
1) Use the Floorplanner to find out the new names of the chain, and correct
the UCF file accordingly.
2) Put the RLOCs in your source code. i.e. Use VHDL attributes. See the
'constraints guide' in the Xilinx documentation.
I've had to do both of these in the past.
Bon chance, Syms.
<yvan.eustache1@etud.univ-ubs.fr> wrote in message
news:c48b3bae.0406010642.57de0c63@posting.google.com...
> The carry logic and sum logic make errors because (I think) during the
> resynthesise of the macros ISE changes the name of carry logic and sum
> logic.



Article: 70072
Subject: Re: VHDL warning " Feedback mux " from synplify pro ...thx
From: Ray Andraka <ray@andraka.com>
Date: Tue, 01 Jun 2004 12:37:41 -0400
Links: << >>  << T >>  << A >>
The feedback mux warning comes about because of the condition where
bitsync_temp is not assigned in the if_then potion:

Jimmy wrote:

>
>          if (pnt < "1011000") then
>              pnt := pnt + '1';
>          else
>              pnt := (others => '0');
>
>             if (PeakValue(BitWidth+6 downto 3) >= "011111111111" ) then
>                  BitSync_temp <= '1';
>             else
>                 BitSync_temp <= '0';
>             end if;
>
>          end  if;

That structure makes an implied memory element for bitsync_temp in the case
pnt<"1011000".   separate the logic for pnt and bitSync_temp into two separate
if then elses to fix the problem as well as to make it more readable.

  --
--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: 70073
Subject: Re: NIOS 2 memory limitations
From: george.martin@att.net (George)
Date: 1 Jun 2004 11:41:08 -0700
Links: << >>  << T >>  << A >>
"David Brown" <david@no.westcontrol.spam.com> wrote in message news:<c9i4bk$3lg$1@news.netpower.no>...
> "George" <george.martin@att.net> wrote in message
> news:e9d879fa.0406010629.27219b22@posting.google.com...
> > I'm converting a NIOS design to a NIOS 2 design.  The end product has
> > a large number of 256MBit FLASH devices (19).  I've mapped all the
> > periferrals to low mamory 0x000 to 0x2000 and then one 256 MBit SDRAM
> > 0x0200 0000 (spaces added for clarity)  I then start adding FLASH
> > devices at 0x0400 0000.  All goes well till I try to place FLASH at
> > 0x1000 0000.  I get a compiler error messages: "Address range of
> > instruction master crossing a 256 MByte boundary. Not supported"
> >
> > My questions are:  Did I do something wrong?  Is this a bug or for
> > real? How can I handle large memory designs?  How can I make some of
> > the FLASH data and ont instructin memory and will that help?
> >
> 
> You can choose whether the memory banks are connected to the instruction
> master and/or the data master.  It sounds like there is a limitation in the
> Nios II regarding the width of instruction addresses (probably so that an
> absolute call or jump can fit within a single instruction), but that should
> not affect the data access (presumably this range is mostly data?).
> Deselect the instruction master connection from the data banks, and see if
> that helps.


Do you know how to do that.  I added a 2nd TriState Bus and connected
that to the CPU Data Master Bus.  The 1st TriSatate bus is connected
to the CPU Instruction Master Bus.

Is this the best (correct) way??

Thanks
George

Article: 70074
Subject: converting design from ise 6.1 to 6.2 problems
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Tue, 1 Jun 2004 15:25:47 -0400 (EDT)
Links: << >>  << T >>  << A >>
I have a design that runs perfecly fine in ise 6.1 but when i try to
implement the design in 6.2 i get a bunch of errors somehow related to pin
drive strength and slew rate?

i have a diff clock pair that uses io standard lvpecl_25
and a couple signals on different banks that use typical io standards.

the errors start in the map sections
here is a printout of the log
(I changed sensitive variable names to NETNAME, note they were not all the
same variable)


Using target part "2vp7ff672-7".
Removing unused or disabled logic...
Running cover...
Running directed packing...
Running delay-based LUT packing...
Running related packing...
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp RTS, based on its IO standard of LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp RTS, based on its IO standard of LVCMOS25.
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp NETNAME, based on its IO standard of
   LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp NETNAME, based on its IO standard of
   LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp ser_out, based on its IO standard of LVCMOS25.
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength
must
   not be set in IOB comp NETNAME, based on its IO standard of
   LVCMOS25.
ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not
be set
   in IOB comp NETNAME, based on its IO standard of LVCMOS25.
ERROR:Map:46 - Errors in physical DRC.



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