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 16575

Article: 16575
Subject: Dynamically reconfigurable devices
From: Bernd Schmidt <bes@aifb.uni-karlsruhe.de>
Date: Fri, 28 May 1999 18:40:01 +0200
Links: << >>  << T >>  << A >>
Hi,

since Xilinx does not offer the 6000 series any more, are there any
dynamically reconfigurable FPGAs available? Maybe from another vendor.

Thanks and cheers

Bernd

Article: 16576
Subject: Re: FPGA express + VHDL: strange SR implementation?
From: micheal_thompson@my-deja.com
Date: Fri, 28 May 1999 16:56:01 GMT
Links: << >>  << T >>  << A >>
In article <374EB686.4C110CE3@yahoo.com>,
  Rickman <spamgoeshere4@yahoo.com> wrote:
>
> I also agree that this is not a good implementation. But this is what
> the code describes. To tell you the truth, I don't think what you have
> defined can really be an SR latch. Your code does not specify what
> happens when both S and R are asserted. An SR latch always has a
second
> internal node which is what makes it operate differently from a latch.
> You have specified the behavior of just the one output. The tool tried
> to give you what you asked for.
>

>> (Mike)
I'm no VHDL guru but I'm pretty sure the 'if' clause will give
precedence to the set input; so, if S an R fire 'together', I'd expect
S to win out. To be honest though I'm not sure what the 74xx equivalent
('279?) does in this situation.
Anyway, assuming I can constrain the input timing to avoid such a
scenario my main concern is the fact  the current latch implementation
will fail on EVERY falling S edge.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Article: 16577
Subject: Re: Synthesis problem
From: Elder V Costa <elder@dixtal.com.br>
Date: Fri, 28 May 1999 14:31:25 -0300
Links: << >>  << T >>  << A >>
Hi again

I just install Foundation 1.5i. They changed a little bit the interface.
Now you select the .gyd file from the menu Design->Set guide file.



Tximo wrote:
> 
> Hi all,
> 
> I am trying to synthsise a design with Xilinx Foundations F1.5, with
> some inputs and outputs.  I have a constraint file to locate every
> signal in a pin, but I get the error message:
> 
> ERROR:baste:263 - The LOC constraint "P68" (a IOB location) is not valid
> for
>    symbol "linea_lect.PAD" (pad signal=linea_lect), which is being
> mapped to the
>    following site types:
>     CLKIOB
> 
> My signal is fixed at PIN 68, a normal IOB, but the synthesis tool map
> the signal to a clock, and I don't know why.
> 
> Anyone has any idea?
> 
> Thanks to all for reading my message and sorry for my english.
Article: 16578
Subject: Re: High Speed Reconfigurability
From: Ray Andraka <randraka@ids.net>
Date: Fri, 28 May 1999 15:10:01 -0400
Links: << >>  << T >>  << A >>
The detect logic ran a series of non-writing operations on the smart card, and
depending on what it got back after each vector it could rule out one or more
cards (some had different pin definitions).  The detect logic is basically a
state machine and a set of serial interfaces.

For those who don't know what a smart card is, it is a credit card with a chip
embedded in it.  The chip is just NV memory in some, or a processor with
memory in others.  The memory ones have different amounts of memory.  Each
card has a different interface protocol and in some cases slightly different
pin definitions.  There are 8 pins (actually pads) on the face of the card
that are contacted when the card is put in the socket.  The cards are used
extensively in Europe for banking, lottery, and credit cards.

The Dallas IDs are nice.  They are easiest to work from a microcontroller, but
you do have to be careful not to let them see the sequence of 1's and 0's that
wake them up unless you want to read it.  With that in mind, you might gate
the buffering logic so that it can only be accessed when the FPGA is not
programmed or something similar.

Rickman wrote:

> Ray Andraka wrote:
> ...snip...
> > Another application I designed, which I have presented in seminars, is a
> > universal smart card controller that started with a 'detect'
> > configuration which would figure out which of about 12 different flavors
> > of smart card was inserted.  Once detected, the FPGA (a 4013) initated a
> > reconfiguration of itself with the specific smart card interface for the
> > detected card.  When the smart card was withdrawn, the FPGA would again
> > reconfigure with the detect circuit.
>
> I am planning on doing something similar. My controller won't have to
> deal with on-the-fly changes to the card, but it will identify the card
> on power up and load the corresponding interface design. This is all
> directed by the processor rather than by the FPGA design. I was thinking
> of using a Dallas one-wire ID part for the identification. Very small,
> and they only use one pin on my interface. How did you do the ID?
>
> > > > A rack of DSP processors is outperformed by a single board
> > > > with a couple FPGAs.  Some examples:
> > > > A doppler weather radar demodulator, ...a radar simulation
> > > > system, ...QAM demodulator.
> > >
> > > Those are freakish niche applications.  I thought we were
> > > talking about the applicability of reconfigurable hardware
> > > to mainstrean software systems.
> > >
> >
> > My point is that I think the real killer app is the ability to handle
> > these "freakish niche apps" in mainstream hardware.  That is a good deal
> > of the basis of mainstream reconfigurable computing thinking, isn't it?
>
> I don't know that a QAM demodulator is "freakish". Often your other
> choice is to add a DSP with memory, PROM... Doing this in an FPGA can
> really save a lot of space. QAM is extensively used. It may not be the
> "killer app", but it is something that would be used.
>

I don't think any of these are "freakish", but I was just quoting the guy who
apparently felt I didn't know what I was talking about.  Actually, QAM can be
done in a 4013, including complex demodulation from IF.  The DSP micro guys
are hard pressed to work at baseband with more than about 20 taps in the
filters.

I've done digital receiver designs in FPGAs that match the performance of the
equivalent Graychip and Harris dedicated digital receiver chips.  For example,
I have a quadrature downconverter that works at 145MSPS, with 12 bit I and Q
outputs, with a programmable local oscillator that fits in less than half of a
4013XLA-07.

>
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> remove the XY to email me.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 16579
Subject: Re: RAM for external/internal use
From: Ray Andraka <randraka@ids.net>
Date: Fri, 28 May 1999 15:38:43 -0400
Links: << >>  << T >>  << A >>
The Altera 10K does not have a dual port EAB.  The 10KE does have a limited
dual port RAM.  If your access rate is low enough however, you can make the
10K EABs look like a dual port by using a faster clock so that you can get two
accesses (one for each client) in a clock cycle.  Use multiplexers to select
the input data, control and address.

The 10KE dual port is limited in that one 'port' is a write only port, while
the other is a read-only  port.  What it does is gives you the capability to
read from one address while simultaneously writing to a different address.
Even with that setup, you still need the muxes to be able to select which
client does the write, and you still need a 2x clock to handle multiple writes
in a clock cycle.

The xilinx 4K CLBs have a little more functionality, in that the write port
can also be read, which allows you to read both ports simultaneously.  Still,
only the write port can be written in that case.

Xilinx Virtex block memories are true dual port synchronous memories.  Each
port has a full set of controls, which means either port can read or write the
array (and that can be done simultaneously).  Each port has a clock that can
be independent of the other port, and a write enable.  Each port can also
define how the memory is arranged when viewed by that port, so on one side you
could access the memory as a 256x16, while accessing it as a 2Kx2 on the other
side.  Cool stuff.

Garrick Kremesec wrote:

> > I believe you are looking, not for a dual port ram, but a ram with
> > shared address and data buses. A dual port memory can be accessed at the
> > same time by both parties. If you need the simultaineous access, then
> > you have to have two sets of busses. In effect it is two memories that
> > always have the same contents.
>
> Well, if I have separate processes working continuously (as quickly as
> possible) generating pulses (which have to compare state against what is
> requested by the user in ram) and reading many ADC channels (and writing
> them to ram), I think I will be accessing memory simultaneously.  I
> didn't think 64 words of dual port data was too much to ask out of a
> EPF10K10, but maybe I'm quite wrong.
>
> > If you don't need to access the ram from two ports at the same time, you
> > just put a mux on the address bus and either mux the data in or go with
> > a tristate bus. The controls have to have an arbitor to control access.
> > This can be very simple and just allows one device at a time to select
> > whether it is a read or a write cycle.
> >
> > The tristate bus is simple. You hook the data inputs to the ram directly
> > to the tristate bus and hook the data outputs to the bus through
> > tristate buffers. Do the same on the two units accessing the ram.
> >
> > Is that any more clear?
> >
> > --
> >
> > Rick Collins
> >
> > rick.collins@XYarius.com
>
> Will I be able to redirect the output to the same bus used as input
> (defined as inout) using a separate process on the FPGA, or do you mean
> an external tristate buffer is required on separate output lines?  That
> just seems excessively wasteful of the I/O pins.
>
> I have used several dual port rams that have only two (not four) busses
> that are I/O/tristate.
>
> Here is the only Altera component for dual port ram:
>
> component csdpram
>    generic ( LPM_WIDTH: POSITIVE;
>              LPM_WIDTHAD: POSITIVE;
>              LPM_NUMWORDS: POSITIVE );
>    port ( dataa: in STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
>           datab: in STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
>           addressa: in STD_LOGIC_VECTOR(LPM_WIDTHAD-1 downto 0);
>           addressb: in STD_LOGIC_VECTOR(LPM_WIDTHAD-1 downto 0);
>           clock: in STD_LOGIC;
>           clockx2: in STD_LOGIC;
>           wea: in STD_LOGIC;
>           web: in STD_LOGIC;
>           qa: out STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
>           qb: out STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
>           busy: out STD_LOGIC );
> end component;
>
> I see writes selects, address, data in, data out, and busy, but where is
> read? I the read line essentially the clockx2 signal???  I think I need
> a better set of reference material.
>
> Thanks a lot for your help/time.
>
> Garrick



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 16580
Subject: Re: Dynamically reconfigurable devices
From: Ray Andraka <randraka@ids.net>
Date: Fri, 28 May 1999 15:42:21 -0400
Links: << >>  << T >>  << A >>
Xilinx Virtex supports partial reconfiguration if you want to stay with
xilinx.  Atmel's 6K and 40K are also both partially reconfigurable.
Motorola's MPA also is, but it too has been discontinued.  I'm not sure
about the Lucent ORCA parts, something in the back of my mind says those
might support partial reconfiguration too.  None of these have the
bitstream wide open for the world to see the way the 6200 does though.

Bernd Schmidt wrote:

> Hi,
>
> since Xilinx does not offer the 6000 series any more, are there any
> dynamically reconfigurable FPGAs available? Maybe from another vendor.
>
> Thanks and cheers
>
> Bernd



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 16581
Subject: Re: Rom use, Renoir => leonardo => maxplus2
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Fri, 28 May 1999 19:49:58 GMT
Links: << >>  << T >>  << A >>
Ron,

What you have described is one of the more "problematic" issues with
Altera and third-party synthesis tools. Because of the way they create
models for RAMs & ROMs and the way MP2 handles netlists there are
"issues" when trying to instantiate ROMs which have initialisation
values.

It's not really a case of Leonardo doing anything "wrong" it's just
that there is no mechanism to easily doing ROM and RAM blocks with
initialisation using any current synthesis tool and MP2.

<aside on>
Of course life is sooooo much easier with xilinx coregen because they
let you use an individual name for each ROM you want and you can just
black-box it.
<aside off>

Altera's genmem creates a simulation model for a particular size of
memory that you require. The VHDL behavioural model uses the hex
format file to initialise the ROM during simulation. The name of the
file is passed as a generic, which in your case was probably called
d1.hex. For the elaboration stage of synthesis, Leonardo Spectrum
uniquifies instances by appending the generics used to the instance
name, separated by underscores. Illegal characters such as "." are
converted to underscores. Therefore if the label of your instantiation
is "romd" then you end up with the instance "romd_d1_hex" and MP2
can't find the file. MP2 has no intelligent methodology to extract
this information from the edif netlist, and there is no mechanism in
MP2 to pass the initialisation file except by instance name (AFAIK)

The quickest way for you to get round the problem is to take a copy of
your "d1.hex" file and call it "romd_d1_hex.hex".

I did write a "how to" example examining Renoir, MTI, Spectrum
integration, but as you really just need a work-around, the preceding
paragraph is it.

Cheers
Stuart

For Email remove "NOSPAM" from the address
Article: 16582
Subject: Re: FPGA express + VHDL: strange SR implementation?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 28 May 1999 15:50:44 -0400
Links: << >>  << T >>  << A >>
micheal_thompson@my-deja.com wrote:
> 
> In article <374EB686.4C110CE3@yahoo.com>,
>   Rickman <spamgoeshere4@yahoo.com> wrote:
> >
> > I also agree that this is not a good implementation. But this is what
> > the code describes. To tell you the truth, I don't think what you have
> > defined can really be an SR latch. Your code does not specify what
> > happens when both S and R are asserted. An SR latch always has a
> second
> > internal node which is what makes it operate differently from a latch.
> > You have specified the behavior of just the one output. The tool tried
> > to give you what you asked for.
> >
> 
> >> (Mike)
> I'm no VHDL guru but I'm pretty sure the 'if' clause will give
> precedence to the set input; so, if S an R fire 'together', I'd expect
> S to win out. To be honest though I'm not sure what the 74xx equivalent
> ('279?) does in this situation.
> Anyway, assuming I can constrain the input timing to avoid such a
> scenario my main concern is the fact  the current latch implementation
> will fail on EVERY falling S edge.

Yes, but it is a timing related problem which combinatoral feedback is
prone to. Your VHDL is specifying a latch. You need to change the code
to get a standard RS latch. The '279 is just a pair of crosscoupled
gates. When both inputs are asserted, both Q and Q- are asserted. Even
if Q- is not brought out to a pin, it exists inside the chip. As I said
in the earlier post, this chip also has a timing problem. It is just a
different case. 

You are assuming that what you have written is an RS latch because you
think you have specified enough of the operation. But that is not true.
The circuit that was generated meets the logical requirements. It fails
based on the timing. In fact I believe there are warnings in many VHDL
textbooks on just this sort of thing. So change your circuit with
different VHDL. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 16583
Subject: Re: RAM for external/internal use
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 28 May 1999 16:02:16 -0400
Links: << >>  << T >>  << A >>
Garrick Kremesec wrote:
> 
> > I believe you are looking, not for a dual port ram, but a ram with
> > shared address and data buses. A dual port memory can be accessed at the
> > same time by both parties. If you need the simultaineous access, then
> > you have to have two sets of busses. In effect it is two memories that
> > always have the same contents.
> 
> Well, if I have separate processes working continuously (as quickly as
> possible) generating pulses (which have to compare state against what is
> requested by the user in ram) and reading many ADC channels (and writing
> them to ram), I think I will be accessing memory simultaneously.  I
> didn't think 64 words of dual port data was too much to ask out of a
> EPF10K10, but maybe I'm quite wrong.
> 
> > If you don't need to access the ram from two ports at the same time, you
> > just put a mux on the address bus and either mux the data in or go with
> > a tristate bus. The controls have to have an arbitor to control access.
> > This can be very simple and just allows one device at a time to select
> > whether it is a read or a write cycle.
> >
> > The tristate bus is simple. You hook the data inputs to the ram directly
> > to the tristate bus and hook the data outputs to the bus through
> > tristate buffers. Do the same on the two units accessing the ram.
> >
> > Is that any more clear?
> >
> > --
> >
> > Rick Collins
> >
> > rick.collins@XYarius.com
> 
> Will I be able to redirect the output to the same bus used as input
> (defined as inout) using a separate process on the FPGA, or do you mean
> an external tristate buffer is required on separate output lines?  That
> just seems excessively wasteful of the I/O pins.
> 
> I have used several dual port rams that have only two (not four) busses
> that are I/O/tristate.
> 
> Here is the only Altera component for dual port ram:
> 
> component csdpram
>    generic ( LPM_WIDTH: POSITIVE;
>              LPM_WIDTHAD: POSITIVE;
>              LPM_NUMWORDS: POSITIVE );
>    port ( dataa: in STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
>           datab: in STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
>           addressa: in STD_LOGIC_VECTOR(LPM_WIDTHAD-1 downto 0);
>           addressb: in STD_LOGIC_VECTOR(LPM_WIDTHAD-1 downto 0);
>           clock: in STD_LOGIC;
>           clockx2: in STD_LOGIC;
>           wea: in STD_LOGIC;
>           web: in STD_LOGIC;
>           qa: out STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
>           qb: out STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
>           busy: out STD_LOGIC );
> end component;
> 
> I see writes selects, address, data in, data out, and busy, but where is
> read? I the read line essentially the clockx2 signal???  I think I need
> a better set of reference material.
> 
> Thanks a lot for your help/time.
> 
> Garrick

I don't know enough about the Altera parts to tell you how the ram
works, but you really only need to know if it is synchronous or not. The
reads typically are always asynchronous on these parts. If so, there is
no read strobe except for the enable to the tristate buffer. I also
don't know if the EPF10K10 has internal tristate busses. I work more
with Xilinx where they have these things. 

I think a lot of your questions have more to do with VHDL. A tristate
buffer can be inferred or instantiated in VHDL. You can describe library
parts or you can write code to describe the tristate buffer and let the
synthesis tool add them. 

if (read_en) then
  shared_bus <= read_data;
else
  shared_bus <= (others => 'Z');
end if;

This should define a bus of tristate buffers. If you don't have
tristates then you could use a mux, but that is not likel to be
efficient. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 16584
Subject: Re: RAM for external/internal use
From: Garrick Kremesec <gkremese@ews.uiuc.edu>
Date: Fri, 28 May 1999 15:05:39 -0500
Links: << >>  << T >>  << A >>
Ray,

    Thanks for the good info.  I think I'm going to implement two blocks
of RAM with separate inputs and outputs ports.  One the microcontroller
writes to (and the FPGA reads on the output port) and the other that the
microcontroller reads from (and the FPGA writes in the data.  Seems like
a plan now anyway.  I'll probably run into a wall somewhere and you'll
see the resulting post.  :-)

Garrick

Ray Andraka wrote:
> 
> The Altera 10K does not have a dual port EAB.  The 10KE does have a limited
> dual port RAM.  If your access rate is low enough however, you can make the
> 10K EABs look like a dual port by using a faster clock so that you can get two
> accesses (one for each client) in a clock cycle.  Use multiplexers to select
> the input data, control and address.
> 
> The 10KE dual port is limited in that one 'port' is a write only port, while
> the other is a read-only  port.  What it does is gives you the capability to
> read from one address while simultaneously writing to a different address.
> Even with that setup, you still need the muxes to be able to select which
> client does the write, and you still need a 2x clock to handle multiple writes
> in a clock cycle.
> 
> The xilinx 4K CLBs have a little more functionality, in that the write port
> can also be read, which allows you to read both ports simultaneously.  Still,
> only the write port can be written in that case.
> 
> Xilinx Virtex block memories are true dual port synchronous memories.  Each
> port has a full set of controls, which means either port can read or write the
> array (and that can be done simultaneously).  Each port has a clock that can
> be independent of the other port, and a write enable.  Each port can also
> define how the memory is arranged when viewed by that port, so on one side you
> could access the memory as a 256x16, while accessing it as a 2Kx2 on the other
> side.  Cool stuff.
> 
> Garrick Kremesec wrote:
> 
> > > I believe you are looking, not for a dual port ram, but a ram with
> > > shared address and data buses. A dual port memory can be accessed at the
> > > same time by both parties. If you need the simultaineous access, then
> > > you have to have two sets of busses. In effect it is two memories that
> > > always have the same contents.
> >
> > Well, if I have separate processes working continuously (as quickly as
> > possible) generating pulses (which have to compare state against what is
> > requested by the user in ram) and reading many ADC channels (and writing
> > them to ram), I think I will be accessing memory simultaneously.  I
> > didn't think 64 words of dual port data was too much to ask out of a
> > EPF10K10, but maybe I'm quite wrong.
> >
> > > If you don't need to access the ram from two ports at the same time, you
> > > just put a mux on the address bus and either mux the data in or go with
> > > a tristate bus. The controls have to have an arbitor to control access.
> > > This can be very simple and just allows one device at a time to select
> > > whether it is a read or a write cycle.
> > >
> > > The tristate bus is simple. You hook the data inputs to the ram directly
> > > to the tristate bus and hook the data outputs to the bus through
> > > tristate buffers. Do the same on the two units accessing the ram.
> > >
> > > Is that any more clear?
> > >
> > > --
> > >
> > > Rick Collins
> > >
> > > rick.collins@XYarius.com
> >
> > Will I be able to redirect the output to the same bus used as input
> > (defined as inout) using a separate process on the FPGA, or do you mean
> > an external tristate buffer is required on separate output lines?  That
> > just seems excessively wasteful of the I/O pins.
> >
> > I have used several dual port rams that have only two (not four) busses
> > that are I/O/tristate.
> >
> > Here is the only Altera component for dual port ram:
> >
> > component csdpram
> >    generic ( LPM_WIDTH: POSITIVE;
> >              LPM_WIDTHAD: POSITIVE;
> >              LPM_NUMWORDS: POSITIVE );
> >    port ( dataa: in STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
> >           datab: in STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
> >           addressa: in STD_LOGIC_VECTOR(LPM_WIDTHAD-1 downto 0);
> >           addressb: in STD_LOGIC_VECTOR(LPM_WIDTHAD-1 downto 0);
> >           clock: in STD_LOGIC;
> >           clockx2: in STD_LOGIC;
> >           wea: in STD_LOGIC;
> >           web: in STD_LOGIC;
> >           qa: out STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
> >           qb: out STD_LOGIC_VECTOR(LPM_WIDTH-1 downto 0);
> >           busy: out STD_LOGIC );
> > end component;
> >
> > I see writes selects, address, data in, data out, and busy, but where is
> > read? I the read line essentially the clockx2 signal???  I think I need
> > a better set of reference material.
> >
> > Thanks a lot for your help/time.
> >
> > Garrick
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka
Article: 16585
Subject: Re: Dynamically reconfigurable devices
From: Jonathan Feifarek <feifarek@removethis.ieee.org>
Date: Fri, 28 May 1999 14:24:02 -0600
Links: << >>  << T >>  << A >>


Ray Andraka wrote:
> 
> Xilinx Virtex supports partial reconfiguration if you want to stay with xilinx. 
[...]

> Bernd Schmidt wrote:
> 
> > Hi,
> >
> > since Xilinx does not offer the 6000 series any more, are there any
> > dynamically reconfigurable FPGAs available? Maybe from another vendor.
> > Thanks and cheers
> > Bernd

What about the Xilinx XC5200?  I haven't used this part and believed it
to be discontinued, like the 6000 series, but unlike that series, it
still appears in the Xilinx products Web page.  It had some problems,
but I heard that they had been worked around.

Here is an article on a new part to watch from NEC: 
http://www.edtn.com/story/OEG19990215S0004

Jonathan
-- 
Jonathan F. Feifarek
Consulting and design
Programmable logic solutions
Article: 16586
Subject: Evolutionary computation
From: Jonathan Feifarek <feifarek@removethis.ieee.org>
Date: Fri, 28 May 1999 14:45:03 -0600
Links: << >>  << T >>  << A >>
OK, time for a new thread from "Re: High Speed Reconfigurability".

I've been interested in Reconfigurable Computing in general, but know
very little about the area of Evolutionary Computation.  I, for one,
would like to learn more.

Tim Tyler wrote:
> 
> Evolutionary computations parallelise /extremely/ well.  The field offers
> applications for which there's no practical limit on how much parallelism
> is desirable - the more the merrier.  Further, typically it eats
> processing power like there's no tomorrow.  There are few applications
> *more* suitable for implementation on FPGAs than this one.
> 

I assume that evolution computation is the same thing as evolvable
hardware (plus the 'software').  Doesn't this process involve 'mutating'
configurations in successive generations, and evaluating the offspring
from each generation to determine their degree of success in meeting the
goal of the design?  (Please excuse the imprecise terminology).

My question is this: if the mutations are truly random alterations in
the logic, doesn't the possibility of logic contention arise where two
output stages are driven to opposite states at the same time?  I've
heard of damaged hardware from this - indeed, J-Bits comes with a
prominent warning to beware of it.  To check each offspring for this
possibility sounds like it would be an enormous task for a reasonably
sized circuit.

Perhaps this is one of the areas where the technology "eats processing
power like there's no tomorrow".

Jonathan
-- 
Jonathan F. Feifarek
Consulting and design
Programmable logic solutions
Article: 16587
Subject: Generating GSR From Within Chip
From: Craig Yarbrough <hyarbr01@harris.com>
Date: Fri, 28 May 1999 17:12:07 -0400
Links: << >>  << T >>  << A >>
All,

Does anyone know how or if it's possible to generate a GSR signal from
within a Xilinx 4000/Virtex?

- Craig


Article: 16588
Subject: Re: FPGA express + VHDL: strange SR implementation?
From: ems@riverside-machines.com.NOSPAM
Date: Fri, 28 May 1999 22:43:38 GMT
Links: << >>  << T >>  << A >>
On Thu, 27 May 1999 17:58:31 GMT, micheal_thompson@my-deja.com wrote:

it's late at night, but...

>Hi
>I'm using a fairly text-book ( I think) piece of code here to get an SR
>latch:
>    busy_sr_reg: process(set_tx_busy, clr_tx_busy)
>    begin
>		if (set_tx_busy = '1') then
>			tx_busy <= '1';
>		elsif (clr_tx_busy = '1') then
>			tx_busy <='0';
>		end if;
>    end process busy_sr_reg;

this correctly describes an sr in vhdl; in other words, it'll simulate
ok (and it handles simultaneously asserted s and r correctly, as you
point out in your other post). the code also clearly indicates that
the output should hold when set falls, so there's no inherent timing
or race problems for that condition.

whether it synthesises into an sr is another matter. this depends on
your synthesiser recognising this template as an sr. i'd expect this
to be a problem for most synths, but i've never tried it myself.

>My target FPGA is an ACTEL A3200DX. After FPGA express optimised it and
>pumped out an EDIF file ready for ACTEL I went back and converted that
>same EDIF into a schematic representation.
>All the synchronous stuff (not listed here)looks fine but the SR
>implementation seems a tad dodgy. I had expected to see it implemented
>using the set and pre-set inputs of a DFF but instead it uses a latch:
>The 'D' pin is connected to 'set' and the 'G(ate)'(active lo) is
>connected to the 'NOR' of 'set' and 'clear'. Conceivably then if the
>Nor-gate path had a large delay you could have a situation where the
>falling edge of set will inadvertently clear the output?

if the synth correctly recognised an sr then it could, in principle,
implement it using a DFF using S and R. your nor/latch circuit doesn't
sound good, but it would work if there was a suitably long negative
hold time on the gate. do actel latches have negative hold times? can
you do a timing simulation to verify if the output holds when set
falls?

>
>So, I'm asking the following:
>
>Is schematic viewing at this point unrepresentative of the actual
>(fitted/ layed out) circuit? In other words should I wait until the
>vendor tool (which I don't have yet) does its stuff as maybe it will
>put its own spin on the circuit?

depends on what the synth produces. if it produces a technology
netlist, and you can persuade the mapper not to mess with it, then
what you see is what you get. if it produces a gate-level netlist, on
the other hand, then the mapper will have to convert it into a
technology-specific form. 

there's another problem in your case, which is that the circuit
operation depends on the routing delay from the nor gate to the latch,
and so a schematic view won't be enough to tell you if the circuit
will work or not. spectrum will back-annotate a routing delay to the
schematic, but i'm not sure about express.

if i was you, i'd find an alternative representation. you could do a
cross-coupled gate version, or create a cell using a dff (but both of
these options could give you static timing analysis problems). or, of
course, you could go synchronous if possible.

evan

Article: 16589
Subject: Re: Xilinx M1.5 Crash
From: Jamie Lokier <spamfilter.may1999@tantalophile.demon.co.uk>
Date: 29 May 1999 00:49:59 +0200
Links: << >>  << T >>  << A >>
Zoltan Kocsi writes:
> I might very well be the only pervert who wants to
> design chips and run Linux in the same time, though. 

Not at all -- there are plenty of us.  But we always seem to find a
spare NT box to run the P&R tools on somehow.  For me it is never the
same box I actually sit in front of.  Our polite requests to EDA vendors
for Linux versions apparently don't amount to much demand.

Anyway, if it wasn't for the f***ing dongles, most Windows EDA tools
would run fine in Linux under Wine.  (Altera Maxplus, the undongled
features, seems fine).

-- Jamie
Article: 16590
Subject: Transmogrifier C
From: Steven Casselman <sc@vcc.com>
Date: Fri, 28 May 1999 15:51:00 -0700
Links: << >>  << T >>  << A >>
People interested in C to hardware compliers might
want to look at
http://www.eecg.toronto.edu/EECG/RESEARCH/tmcc/tmcc
For free source code.
This was the first C compiler code I found that
was really a compiler. If you analyze this you
will know how to make a real hardware C compiler.


--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 16591
Subject: Re: RAM for external/internal use
From: Ray Andraka <randraka@ids.net>
Date: Fri, 28 May 1999 21:54:04 -0400
Links: << >>  << T >>  << A >>

--------------DF41E6B37A597B199BE8F3A0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Altera 10K EAB has the option of registering the address, the read data output,
the write data input and the write enable.  Each can be separately selected for
registered or non-registered operation.  Read data through the RAM block is
totally combinatorial if the address input and read data out registers are not
selected.

There are no tristate busses in the Altera 10K, they can however be emulated
using logic.  There is an app note on the Altera web site regarding this.

Rickman wrote:

> I don't know enough about the Altera parts to tell you how the ram
> works, but you really only need to know if it is synchronous or not. The
> reads typically are always asynchronous on these parts. If so, there is
> no read strobe except for the enable to the tristate buffer. I also
> don't know if the EPF10K10 has internal tristate busses. I work more
> with Xilinx where they have these things.
>
> I think a lot of your questions have more to do with VHDL. A tristate
> buffer can be inferred or instantiated in VHDL. You can describe library
> parts or you can write code to describe the tristate buffer and let the
> synthesis tool add them.
>
> if (read_en) then
>   shared_bus <= read_data;
> else
>   shared_bus <= (others => 'Z');
> end if;
>
> This should define a bus of tristate buffers. If you don't have
> tristates then you could use a mux, but that is not likel to be
> efficient.
>



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


--------------DF41E6B37A597B199BE8F3A0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
Altera 10K EAB has the option of registering the address, the read data
output, the write data input and the write enable.&nbsp; Each can be separately
selected for registered or non-registered operation.&nbsp; Read data through
the RAM block is totally combinatorial if the address input and read data
out registers are not selected.

<P>There are no tristate busses in the Altera 10K, they can however be
emulated using logic.&nbsp; There is an app note on the Altera web site
regarding this.

<P>Rickman wrote:
<BLOCKQUOTE TYPE=CITE>I don't know enough about the Altera parts to tell
you how the ram
<BR>works, but you really only need to know if it is synchronous or not.
The
<BR>reads typically are always asynchronous on these parts. If so, there
is
<BR>no read strobe except for the enable to the tristate buffer. I also
<BR>don't know if the EPF10K10 has internal tristate busses. I work more
<BR>with Xilinx where they have these things.

<P>I think a lot of your questions have more to do with VHDL. A tristate
<BR>buffer can be inferred or instantiated in VHDL. You can describe library
<BR>parts or you can write code to describe the tristate buffer and let
the
<BR>synthesis tool add them.

<P>if (read_en) then
<BR>&nbsp; shared_bus &lt;= read_data;
<BR>else
<BR>&nbsp; shared_bus &lt;= (others => 'Z');
<BR>end if;

<P>This should define a bus of tristate buffers. If you don't have
<BR>tristates then you could use a mux, but that is not likel to be
<BR>efficient.
<BR><A HREF="http://www.arius.com"></A>&nbsp;</BLOCKQUOTE>
&nbsp;

<P>--
<BR>-Ray Andraka, P.E.
<BR>President, the Andraka Consulting Group, Inc.
<BR>401/884-7930&nbsp;&nbsp;&nbsp;&nbsp; Fax 401/884-7950
<BR>email randraka@ids.net
<BR><A HREF="http://users.ids.net/~randraka">http://users.ids.net/~randraka</A>
<BR>&nbsp;</HTML>

--------------DF41E6B37A597B199BE8F3A0--

Article: 16592
Subject: Re: Dynamically reconfigurable devices
From: Ray Andraka <randraka@ids.net>
Date: Fri, 28 May 1999 21:58:07 -0400
Links: << >>  << T >>  << A >>
I never used the 5200: it had way to many shortcomings for the applications I've been
dealing with.  I don't recall if it had partial reconfiguration or not.
Nevertheless, even though it may still be available, it would not be wise to use it
in a new design.  For low cost, xilinx recommends spartan devices.  If you need the
partial reconfigurability, then you should be looking at one of the current families
that supports it.

Jonathan Feifarek wrote:

> Ray Andraka wrote:
> >
> > Xilinx Virtex supports partial reconfiguration if you want to stay with xilinx.
> [...]
>
> > Bernd Schmidt wrote:
> >
> > > Hi,
> > >
> > > since Xilinx does not offer the 6000 series any more, are there any
> > > dynamically reconfigurable FPGAs available? Maybe from another vendor.
> > > Thanks and cheers
> > > Bernd
>
> What about the Xilinx XC5200?  I haven't used this part and believed it
> to be discontinued, like the 6000 series, but unlike that series, it
> still appears in the Xilinx products Web page.  It had some problems,
> but I heard that they had been worked around.
>
> Here is an article on a new part to watch from NEC:
> http://www.edtn.com/story/OEG19990215S0004
>
> Jonathan
> --
> Jonathan F. Feifarek
> Consulting and design
> Programmable logic solutions



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 16593
Subject: Re: Dynamically reconfigurable devices
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 28 May 1999 23:08:01 -0400
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> Xilinx Virtex supports partial reconfiguration if you want to stay with
> xilinx.  Atmel's 6K and 40K are also both partially reconfigurable.
> Motorola's MPA also is, but it too has been discontinued.  I'm not sure
> about the Lucent ORCA parts, something in the back of my mind says those
> might support partial reconfiguration too.  None of these have the
> bitstream wide open for the world to see the way the 6200 does though.

The data sheet on the OR3 series says it supports it. But I don't see
anything mentioned in any of the documentation about how to use it. It
is likely the same as with most vendors, let the engineer beware!


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 16594
Subject: Re: Evolutionary computation
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 28 May 1999 23:12:12 -0400
Links: << >>  << T >>  << A >>
Jonathan Feifarek wrote:
> I assume that evolution computation is the same thing as evolvable
> hardware (plus the 'software').  Doesn't this process involve 'mutating'
> configurations in successive generations, and evaluating the offspring
> from each generation to determine their degree of success in meeting the
> goal of the design?  (Please excuse the imprecise terminology).

From what I have read, you understand the concept very well.

 
> My question is this: if the mutations are truly random alterations in
> the logic, doesn't the possibility of logic contention arise where two
> output stages are driven to opposite states at the same time?  I've
> heard of damaged hardware from this - indeed, J-Bits comes with a
> prominent warning to beware of it.  To check each offspring for this
> possibility sounds like it would be an enormous task for a reasonably
> sized circuit.
> 
> Perhaps this is one of the areas where the technology "eats processing
> power like there's no tomorrow".

I believe that all of the "evolution" to date has been in the simulation
domain. They let the software evaluate the circuit where the electrons
are more under control. But certainly, there could be ways to simply
prevent a "mutated gene" from being "expressed" if it would do damage to
the "environment" (the FPGA). 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 16595
Subject: Re: FPGA express + VHDL: strange SR implementation?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 28 May 1999 23:27:45 -0400
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM wrote:
> 
> On Thu, 27 May 1999 17:58:31 GMT, micheal_thompson@my-deja.com wrote:
> >I'm using a fairly text-book ( I think) piece of code here to get an SR
> >latch:
> >    busy_sr_reg: process(set_tx_busy, clr_tx_busy)
> >    begin
> >               if (set_tx_busy = '1') then
> >                       tx_busy <= '1';
> >               elsif (clr_tx_busy = '1') then
> >                       tx_busy <='0';
> >               end if;
> >    end process busy_sr_reg;
> 
> this correctly describes an sr in vhdl; in other words, it'll simulate
> ok (and it handles simultaneously asserted s and r correctly, as you
> point out in your other post). the code also clearly indicates that
> the output should hold when set falls, so there's no inherent timing
> or race problems for that condition.
> 
> whether it synthesises into an sr is another matter. this depends on
> your synthesiser recognising this template as an sr. i'd expect this
> to be a problem for most synths, but i've never tried it myself.

I disagree about this. If you construct an SR latch the standard way
with cross coupled gates, you have an unstable response to the
concurrent removal of both the S and R inputs. In the real world this is
not unlike a metastable FF. In the ideal world of VHDL simulation, you
have a feedback loop that will never stabilize. Each of the two gates
will simultaneously switch from 0 to 1 and back on each delta time
period. The simulation will never advance in time and appear hung. The
VHDL description written above will not do this. So they are not the
same. 

I maintain that this VHDL is really not an SR latch. It only looks like
one on the surface. If you check every combination of state and every
edge, you will see that a latch and an RS latch? (FF?) are not the same. 

 
> if the synth correctly recognised an sr then it could, in principle,
> implement it using a DFF using S and R. your nor/latch circuit doesn't
> sound good, but it would work if there was a suitably long negative
> hold time on the gate. do actel latches have negative hold times? can
> you do a timing simulation to verify if the output holds when set
> falls?

...snip...

> if i was you, i'd find an alternative representation. you could do a
> cross-coupled gate version, or create a cell using a dff (but both of
> these options could give you static timing analysis problems). or, of
> course, you could go synchronous if possible.
> 
> evan

I agree. This is not a good way to go. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 16596
(removed)


Article: 16597
Subject: Re: FPGA express + VHDL: strange SR implementation?
From: ems@riverside-machines.com.NOSPAM
Date: Sat, 29 May 1999 10:58:39 GMT
Links: << >>  << T >>  << A >>
On Fri, 28 May 1999 23:27:45 -0400, Rickman <spamgoeshere4@yahoo.com>
wrote:

>ems@riverside-machines.com.NOSPAM wrote:
>> 
>> On Thu, 27 May 1999 17:58:31 GMT, micheal_thompson@my-deja.com wrote:
>> >I'm using a fairly text-book ( I think) piece of code here to get an SR
>> >latch:
>> >    busy_sr_reg: process(set_tx_busy, clr_tx_busy)
>> >    begin
>> >               if (set_tx_busy = '1') then
>> >                       tx_busy <= '1';
>> >               elsif (clr_tx_busy = '1') then
>> >                       tx_busy <='0';
>> >               end if;
>> >    end process busy_sr_reg;
>> 
>> this correctly describes an sr in vhdl; in other words, it'll simulate
>> ok (and it handles simultaneously asserted s and r correctly, as you
>> point out in your other post). the code also clearly indicates that
>> the output should hold when set falls, so there's no inherent timing
>> or race problems for that condition.
>> 
>> whether it synthesises into an sr is another matter. this depends on
>> your synthesiser recognising this template as an sr. i'd expect this
>> to be a problem for most synths, but i've never tried it myself.
>
>I disagree about this. If you construct an SR latch the standard way
>with cross coupled gates, you have an unstable response to the
>concurrent removal of both the S and R inputs. In the real world this is
>not unlike a metastable FF. In the ideal world of VHDL simulation, you
>have a feedback loop that will never stabilize. Each of the two gates
>will simultaneously switch from 0 to 1 and back on each delta time
>period. The simulation will never advance in time and appear hung. The
>VHDL description written above will not do this. So they are not the
>same. 
>
>I maintain that this VHDL is really not an SR latch. It only looks like
>one on the surface. If you check every combination of state and every
>edge, you will see that a latch and an RS latch? (FF?) are not the same. 

i agree that the two models don't simulate in the same way if S and R
are removed simultaneously, but does it matter? is there a dictionary
definition of an SR? if there was, surely it couldn't include a
description of what should happen in this case, since this is an
implementation detail, and the real behaviour depends on the
gain-bandwidth product of the gates involved.

evan

Article: 16598
Subject: Re: Generating GSR From Within Chip
From: ems@riverside-machines.com.NOSPAM
Date: Sat, 29 May 1999 10:59:45 GMT
Links: << >>  << T >>  << A >>
On Fri, 28 May 1999 17:12:07 -0400, Craig Yarbrough
<hyarbr01@harris.com> wrote:

>All,
>
>Does anyone know how or if it's possible to generate a GSR signal from
>within a Xilinx 4000/Virtex?
>
>- Craig

this is straightforward - select your favourite startup component
(STARTUP/STARUP_VIRTEX/etc.), and connect your signal to the GSR port.
your signal (which can be a device input or an internal signal) then
drives the GSR net. watch out for the GSR net timing - there's a long
delay on release, which could cause you problems when starting
synchronous sections. there are situations in which it's better to
have your own reset net in the general purpose routing.

if you're writing with an HDL then it may, or may not, do all this
automatically for you. this comes up every few weeks, so check
dejanews for specifics.

evan


Article: 16599
Subject: SE TI INTERESSA ARCHICAD 6.0,LIHTWAVE 5.6,PHOTOSHOP5.0,AUTOCAD 14ita,etc ,postami.
From: "Oniria" <mikepent@iol.it>
Date: Sat, 29 May 1999 12:18:14 +0100
Links: << >>  << T >>  << A >>
E-MAIL:  mikepent@iol.it

             Oniria







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