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
2017JanFebMarApr2017

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 40175

Article: 40175
Subject: Re: Rising and falling edge of a clk
From: "H.L" <alphaboran@yahoo.com>
Date: Fri, 1 Mar 2002 14:40:42 +0200
Links: << >>  << T >>  << A >>
Hi Peter, thanks for your reply
I was confident of this method's effectiveness but now I am worried :)) . I
have already done a timing analysis in the paper and also the simulation
waveforms seem promising.
I didnt understand what do you mean when telling me that one of my words
arrives early and the other one late. The transmitter sends to my FPGA an
external clock (thats the 155MHz clock), a valid signal (1 bit indicating
the transmission time period) and of course the 16-bit words that I have to
store. Every clock period (~6 ns) I have available in my ports one 16-bit
word, I register two sequential words from the in port to a 32-bit register
(31->16 the first incoming word, 15->0 the second one). Then , in another
32-bit register I register (2 nd time) the 32-bit word I just "made" which
are the BRAM data_in. All the above operations are in a process that has in
its sensitivity list the 155 clock. I write to the BRAM at 77MHz  using the
incoming clock divide by 2 using a DLL. BRAM input signals are assigned in
the falling edge of the 77MHz clock so as to be before the rising edge (of
the same clock) where the BRAM samples them. The write operations are in
another process with the slow clock in its sensitivity list.
The timing waveforms of the simulation are the same with the timing analysis
in paper but does this is a valid hardware design technique?
Thanks for your time and help!

Best Regards,
Harris

p.s: thats a small part of my design. I use DLL because other parts need
them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155 MHz and I
got many timing errors (floorplanning managed to reduce them but still lot
of work to be done)

"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3C7E621F.1E77A244@xilinx.com...
> I suggest you grab pencil and paper and do a clock-by-clock timing
analysis. You
> will find that your clock-speed reduction buys you nothing, unless you
also
> double-buffer the data.
> One of your words arrives nice and early, the other one late. However you
clock
> the BRAM, one of the two words has the same old short set-up time...
> Double-buffering would help. But Ray has mentioned some neat tricks to
avoid the
> long set-up time of the control inputs.
>
> I will get back with more constructive notes. "Gotta run"
>
> Peter Alfke
> ===================
> "H.L" wrote:
>
> > Hello all,
> >
> > I have a module that accepts 16 bit words at 155MHz and I want to store
then
> > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA) to
divide by
> > 2 the 155MHz clock as this frequency seems to be pretty high to write in
the
> > BRAM. So far I think 2 processes are enough to do my job, one operating
@
> > 155MHz to accept the 16-bit data and store them in a 32-bit register and
the
> > another one @ 75MHz to write the content of the 32-bit register in the
BRAM.
> > I am thinking to assign the BRAM's signals
(ENABLE,WRITE,ADDRESS,DATA_IN) in
> > the falling edge of the 75MHz clock, the main reason for this is the
setup
> > time of the BRAMs signals (in this way the address,data are 6 ns before
next
> > rising edge of the clock where BRAM samples its inputs). My question now
:)
> > , if one process uses the falling edge of one clock does this causes
> > problems to other processes in the design , e.g to processes that use a
> > different clock or to  processes using the rising edge of the same
clock?
> >
> > Best Regards,
> > Harris.
>



Article: 40176
Subject: Clock multiplier/ADPLL in PLD
From: eeburyc@swan.ac.uk (Colin Bury)
Date: 1 Mar 2002 04:41:20 -0800
Links: << >>  << T >>  << A >>
Hi,

I need to multiply a clock from around 44kHz to 11MHz, to be
implemented in a Lattice ISP (Programmable Logic) device.

Does anyone know of how to implement a clock multiplier in
VHDL/Verilog or have any schematics or references?
I am considering trying to implement an All-Digital PLL (due to noise
considerations I would prefer not use an analogue VCO), does anyone
have any idea/know of any references on how to do this?
Am I being stupid, or is it possible to implement this without using a
high frequency external reference clock?

Any help would be greatly appreciated.

Colin Bury
eeburyc@swan.ac.uk
University of Wales Swansea

Article: 40177
Subject: Re: Pin assignments in QUARTUS
From: guiducci@cern.ch (Luigi)
Date: 1 Mar 2002 04:56:25 -0800
Links: << >>  << T >>  << A >>
rjshaw@iprimus.com.au (russell) wrote in message news:<c3771dbf.0202260036.edc1b91@posting.google.com>...
> >...............
> > boring interface of the "Assignment organizer". I cannot assign 500
> > pins clicking with my mouse!
> 
> Yes (in quartus2), open the node-finder, select "pins unassigned",
> Named "*", then click "Start" to list all the pins.
> 
> Now open "current assignments" floor-plan, and display the external
> package view. Now just drag and drop the pins from the node-finder
> window to the pins in the floor-plan window. Maxplus2 could do this,
> so any version of quartus probably would too.

Ah, ok... when I said "I cannot assign 500 pins clicking with my
mouse" it wasn't a kind of complain because I couldn't... I meant that
assigning 500 pins with my mouse wouldn't have been a good way to use
my time, especially if I have to floorplan more than one time...

Article: 40178
Subject: Re: Altera FPGAs
From: sanket@insight.memec.co.in (Xilinx FAE from Insight SANKET)
Date: 1 Mar 2002 06:12:01 -0800
Links: << >>  << T >>  << A >>
Hi Prashant,

Firstly I would like to know which software you are using in case of
Xilinx devices.
Secondly, I would like to see the timing report of 16x16 multiplier on
a
XC2V250 .

Peter too had mentioned something like this--->(<6 ns combinatorial
delay, < 4 ns with internal pipeline).

Please check again.
Regards,
SANKET.



"Peter Ormsby" <faepete.deletethis@mediaone.net> wrote in message news:<f9Df8.10278$Or3.1089192@typhoon.mn.ipsvc.net>...
> Prashant <prashantj@usa.net> wrote in message
> news:ea62e09.0202281345.1467d3c2@posting.google.com...
> 
> > I'm trying to implement a 16x16 combinational multiplier in the
> > EP20K160E. But the timing simulations seem to take 40-50 ns for a
> > single multiply.
> >
> > Anyone have any ideas, how can I speedup the operation?
>  ...
> > Thanks,
> > Prashant
> 
> Prashant,
> 
> If anything, the 20K1500E is going to be slower than the 20K160E.  However,
> you should be able to get much faster speeds out of your 20K160E than you
> are currently seeing.
> 
> Make sure that your inputs and outputs are registered.  It takes a
> relatively long time for a signal to go between the pins and the FPGA
> routing structure, so it's helpful to move the inputs into a register before
> running them though the multiplier and then registering the multiplier
> outputs before running them off the chip.
> 
> Once you have the inputs and outputs registered, you should be able to get a
> multiplier working about 50MHz with no pipeline stages or over 110 MHz with
> two stages in a 20K160E.  You can use the Megawizard to create a pipelined
> multiplier without having to figure out the partial products implementation
> yourself.
> 
> Let me know if this doesn't help.
> 
> -Pete-

Article: 40179
Subject: Re: stuck in state in Spartan-II!
From: sanket@insight.memec.co.in (Xilinx FAE from Insight SANKET)
Date: 1 Mar 2002 06:32:52 -0800
Links: << >>  << T >>  << A >>
Hi Ken,

Are you using any PLLs outside? If yes, then if you do an environment
testing with the "Phil" modified code, you may see that for a
particular temperature your design works perfectly.

Use a DLL in the FPGA instead.This is just a solution on hunch.
Have a good day.
SANKET.


"Ken Mac" <aeu96186@yahoo.co.uk> wrote in message news:<a5noh4$pj4$1@dennis.cc.strath.ac.uk>...
> Phil,
> 
> Your solution did indeed solve the hanging problem - thanks very much for
> the code!
> 
> The design now runs for 28 seconds instead of 3 for some other reason but I
> am sure I can track this down now I can make changes to my VHDL without
> random state hangs happening!
> 
> Thanks again,
> 
> Ken

Article: 40180
Subject: Re: Altera FPGAs
From: David Hawke <dhawke@xilinx.com>
Date: Fri, 01 Mar 2002 14:41:57 +0000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------FCD48B0226BC6BA3B7F0117E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phil,

How do you know that it will outperform any Virtex2 device? They aren't even out yet, so any speed file that is being used that is simply based on extensive spice simulation is not something I would recommend using for production devices.

Dave

phil wrote:

> Hi,
>
> you should not expect that the multiplication wil be calculated faster when using the 1500E. the reason is that the die size of the 1500E is larger than the one of the 160E. Therefore, used LEs are likely to spread over the (larger) die and, therefore, performance will be worse. I would recommend to:
>
> 1. Use the Megawizard to implement the multiplication.
> 2. To use a sophisticated synthesys tool such as Synplicitys Synplify to implement the multiplication (just describe  a*b, add as many register as you can allow (Synplify will use them as pipeline stages).
> 3. Use Synplicitys Amplify to add physical constraints.
> 4. Use Alteras Logic Lock to add  physical constraints.
> 5. Use Alteras new Stratix family of devices which would outperform any Virtex 2 or APEX device.
>
> regards
>
> Phil



Article: 40181
Subject: Re: Clock multiplier/ADPLL in PLD
From: Ray Andraka <ray@andraka.com>
Date: Fri, 01 Mar 2002 14:47:13 GMT
Links: << >>  << T >>  << A >>
For a digital PLL, you'll need a master clock that is higher than your
target frequency.  Typically, you'll need something that is at least 16x,
which puts the design frequency near the upper limit of what you'll be
able to do in the device.  The higher your master, the smaller the
resulting jitter.  You could put a ring oscillator in your design to
generate a high frequency master.  The ring oscillator's frequency would
be sensitive to temperature, supply voltage and possibly the phase of the
moon, but since you would be using for a reference in a DPLL, the drift
would probably be OK as long as it wasn't fast compared to your output
frequency.  The other option would be to implement a delay lock loop,
although I think the delay granularity possible in the CPLD may make that
impractical.

Colin Bury wrote:

> Hi,
>
> I need to multiply a clock from around 44kHz to 11MHz, to be
> implemented in a Lattice ISP (Programmable Logic) device.
>
> Does anyone know of how to implement a clock multiplier in
> VHDL/Verilog or have any schematics or references?
> I am considering trying to implement an All-Digital PLL (due to noise
> considerations I would prefer not use an analogue VCO), does anyone
> have any idea/know of any references on how to do this?
> Am I being stupid, or is it possible to implement this without using a
> high frequency external reference clock?
>
> Any help would be greatly appreciated.
>
> Colin Bury
> eeburyc@swan.ac.uk
> University of Wales Swansea

--
--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: 40182
Subject: Re: stuck in state in Spartan-II!
From: "Ken Mac" <aeu96186@yahoo.co.uk>
Date: Fri, 1 Mar 2002 14:50:30 -0000
Links: << >>  << T >>  << A >>

I am not using a PLL outside (I don't think - would the DAC have one?).

At the moment my clock configuration is as follows:

clk33 comes in on a pin and is fed through a DLL to the design.
clk425 also comes in on a pin and is fed through a DLL to the design.

I then use Phil's code to create the en425 signal which I use to enable my
process C which needs to run at 425kHz to feed the DAC.

Do you mean use a DLL on the FPGA to route my DAC clock out?

The DAC did work perfectly before when I got my design to work without doing
Phils clock synchronisation.  I just fed the clk425 out to the DAC on the
correct pin.

Now I am just not sure how to clock my DAC - do I feed en425 into a DLL and
then out to the DAC?

Thanks for your help,

Ken.



> Hi Ken,
>
> Are you using any PLLs outside? If yes, then if you do an environment
> testing with the "Phil" modified code, you may see that for a
> particular temperature your design works perfectly.
>
> Use a DLL in the FPGA instead.This is just a solution on hunch.
> Have a good day.
> SANKET.



Article: 40183
Subject: Re: Altera FPGAs
From: Rene Tschaggelar <rets@esr.phy.chem.ethz.ch>
Date: Fri, 01 Mar 2002 16:17:34 +0100
Links: << >>  << T >>  << A >>
Pipelining ?
For more than result though.

Rene

Prashant wrote:

> hi,
> 
> Do the different devices in the APEX20KE family have different maximum
> speeds of operation. e.g. Would EP20K1500E be expected to run much
> faster than EP20K160E ?
> 
> I'm trying to implement a 16x16 combinational multiplier in the
> EP20K160E. But the timing simulations seem to take 40-50 ns for a
> single multiply.
> 
> Anyone have any ideas, how can I speedup the operation. 


Article: 40184
Subject: Re: Beginner Altera Questions
From: "jerry1111" <jerry1111@wp.pl>
Date: Fri, 1 Mar 2002 16:57:16 +0100
Links: << >>  << T >>  << A >>
> 1) You can invert it with one pass through your part then bring it back

Going outside of device and entering with inverted signal into other pin? OK

> in and make your tools happy.

And what means that message 'signal usage may not be global' or sth like that
is generated?
Are there any disadvantages other than some delays in clock propagation?
Can I safely ignore this message? (Part runs OK with this message) or there
are 'hidden' things happenig when such message is generated?

jerry



Article: 40185
Subject: clock nets use non-dedicated resources
From: dottavio@ised.it (Antonio)
Date: 1 Mar 2002 08:01:19 -0800
Links: << >>  << T >>  << A >>
In my project I use a Asynchronous FIFO CORE version 4 to synchronize
the data clock coming from the pattern generator with the internal
clock (..having about the same frequency) produced by my circuit. This
clock arrive to the FIFO CORE via a BUFG according to an answer
database Xilinx message that tells to do exactly this to achieve that
the signal could use a global clock line.
The result is that after Place & Route I have the warning 

-----------------------
WARNING:Timing - Clock nets using non-dedicated resources were found
in this
   design. Clock skew on these resources will not be automatically
addressed
   during path analysis. To create a timing report that analyzes clock
skew for
   these paths, run trce with the '-skew' option.
 
   The following clock nets use non-dedicated resources:
      clk_to_fifo  
--------------------------


where clk_to_fifo is between bufg and the wr_clk of the FIFO, I also
try to assign to this signal the attribute USEGLOBALCLOCKLINES via the
constain Editor of XST but the result at the end of P&R is always
this.

How can I take it away ??


Antonio

Article: 40186
Subject: Re: high-speed clock distribution/divider in a FPGA?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 01 Mar 2002 08:03:16 -0800
Links: << >>  << T >>  << A >>
Thomas,

The DCM has a divide by 2 prescaler in it.  I use FPGA Editor to use it, so I am
not sure how it is done in verilog/vhdl, or if it is in the schematic primitive
as an attribute (I guess you could call be a hopeless bit hacker, but then, that
is what we do in the Lab to test everything).

The prescaler has been tested to beyond the frequency to mention....way beyond.

The difficulty is in getting the signal inside.  LVPECL/LVDS input buffer will
work at 622 MHz, but you must be extra careful with your signal integrity at
this frequency, and carefully model the termination and the traces to the
package, taking into account the short t-lines in the package itself (see the
comments at the beginning of the IBIS files).

Once inside and divided by two, the DCM can lock on it, and if no DCM jitter is
allowed (I'm guessing this is SONET/SDH), the DCM can be placed in "Freeze" mode
by tying the LOCKED pin to the Freeze_DLL pin.  This will stop all DCM tap
processing, and will leave you with the deskewed, and duty cycle corrected taps
that were chosen, so later with changes to voltage and temperature the skew and
duty cycle will vary by some small amount.  The DCM is temperature compensated,
so temperature alone results in a +/- 5% error, roughly.

The you can use the DIV=4 attribute and CLKDV output to a BUFG to a DDR FF to
forward a 155 MHz clock.

To remove jitter, and make the clock SONET/SDH compliant, an ICS 8745 PLL (or
8735 for LVPECL) can be used to remove (almost) all of the jitter added by
switching IOs, ground bounce, etc.  Completely integrated (no external RCs for
the PLL):

 http://www.icst.com/pdf/ics8735-01.pdf

Tests in the FPGA Lab show less than 40 ps P-P total jitter with an input that
has as much as 500 ps P-P from the FPGA (jitter added to test the effectiveness
of the PLL).  ICS has designed their PLL to have its pole and filter response
such that it compements the Virtex DLL and DCM tap update rates for best
attentuation.

As with any PLL, it has its own quiet power supply pins so that it can actually
attentuate the jitter.

Austin


Thomas Zipper wrote:

> Hi,
> there were some "counter discussions" in this newsgroup, however I wonder if
> it might be possible to
>
> - divide down a couple of LVPECL clocks running at 622 MHz to a few MHz or
> kHz and
>
> - build a programmable LVPECL divider that can either pass 155 MHz and drive
> it off-chip as LVDS clock or divide down a 622 MHz LVPECL clock to 155 MHz
> and again drive it as LVDS clock to an another chip on board
>
> I requirement would be, that the FPGA is small in respect to the board
> space - the small Virtex-II 50/80 (BGA256) devices looking very nice.
>
> Might there be a way to do that?
>
> Bye
>
> Thomas


Article: 40187
Subject: Re: high-speed clock distribution/divider in a FPGA?
From: "Theron Hicks (Terry)" <hicksthe@egr.msu.edu>
Date: Fri, 01 Mar 2002 11:15:15 -0500
Links: << >>  << T >>  << A >>
Thomas,
    Based on what I recall of the speed ratings of the Virtex2 I would be
skeptical.  However, I seem to recall Peter Alfke mentioning that he was working
on a 1 gig frequency counter in the Virtex2 chip.  Given that Peter tends to
produce what he plans on, I would guess that your 622 MHz _might_ be
attainable.  In particular, if you can keep the temperature down and make
certain that the core supply voltage is on the high side.  I just looked and the
Virtex2 does list an internal toggle frequency that high.  BTW, can anyone tell
me what the "For export control" statement means?  Is that a US governmental
thing or is that "real"?

As an alternative, could you get away with a simple divide by 2 low voltage ECL
chip.  I know that Onsemi has one in the 8 pin tssop package.  It will run at as
low as 3 volts.  For example the MC100EP32DT is a divide by 2 or the MC100EP33DT
is a divide by 4.  They also have an mc100lvep34 in a tssop16 that runs on 2.5
volts.  It is a divideby 2,4,and 8.

Good luck,
Theron

Thomas Zipper wrote:

> Hi,
> there were some "counter discussions" in this newsgroup, however I wonder if
> it might be possible to
>
> - divide down a couple of LVPECL clocks running at 622 MHz to a few MHz or
> kHz and
>
> - build a programmable LVPECL divider that can either pass 155 MHz and drive
> it off-chip as LVDS clock or divide down a 622 MHz LVPECL clock to 155 MHz
> and again drive it as LVDS clock to an another chip on board
>
> I requirement would be, that the FPGA is small in respect to the board
> space - the small Virtex-II 50/80 (BGA256) devices looking very nice.
>
> Might there be a way to do that?
>
> Bye
>
> Thomas


Article: 40188
Subject: Re: high-speed clock distribution/divider in a FPGA?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 01 Mar 2002 08:25:17 -0800
Links: << >>  << T >>  << A >>
Terry,

No probelm, see my post.  Works over the temp range just fine.  The 1/2 presscaler
is the trick Peter is using for the counter.

Austin

"Theron Hicks (Terry)" wrote:

> Thomas,
>     Based on what I recall of the speed ratings of the Virtex2 I would be
> skeptical.  However, I seem to recall Peter Alfke mentioning that he was working
> on a 1 gig frequency counter in the Virtex2 chip.  Given that Peter tends to
> produce what he plans on, I would guess that your 622 MHz _might_ be
> attainable.  In particular, if you can keep the temperature down and make
> certain that the core supply voltage is on the high side.  I just looked and the
> Virtex2 does list an internal toggle frequency that high.  BTW, can anyone tell
> me what the "For export control" statement means?  Is that a US governmental
> thing or is that "real"?
>
> As an alternative, could you get away with a simple divide by 2 low voltage ECL
> chip.  I know that Onsemi has one in the 8 pin tssop package.  It will run at as
> low as 3 volts.  For example the MC100EP32DT is a divide by 2 or the MC100EP33DT
> is a divide by 4.  They also have an mc100lvep34 in a tssop16 that runs on 2.5
> volts.  It is a divideby 2,4,and 8.
>
> Good luck,
> Theron
>
> Thomas Zipper wrote:
>
> > Hi,
> > there were some "counter discussions" in this newsgroup, however I wonder if
> > it might be possible to
> >
> > - divide down a couple of LVPECL clocks running at 622 MHz to a few MHz or
> > kHz and
> >
> > - build a programmable LVPECL divider that can either pass 155 MHz and drive
> > it off-chip as LVDS clock or divide down a 622 MHz LVPECL clock to 155 MHz
> > and again drive it as LVDS clock to an another chip on board
> >
> > I requirement would be, that the FPGA is small in respect to the board
> > space - the small Virtex-II 50/80 (BGA256) devices looking very nice.
> >
> > Might there be a way to do that?
> >
> > Bye
> >
> > Thomas


Article: 40189
Subject: Re: Is ISE3.1 a good one?
From: Kamal <>
Date: Fri, 1 Mar 2002 08:46:38 -0800
Links: << >>  << T >>  << A >>
Hello Johnny,

This feature is not yet available in ISE software.  To use a netlist
in an HDL flow, you could create a wrapper HDL file where the 
netlist is instantiated, and then create a schematic symbol from 
that source.

I hope this helps.

Article: 40190
Subject: Re: Clock multiplier/ADPLL in PLD
From: John_H <johnhandwork@mail.com>
Date: Fri, 01 Mar 2002 17:10:16 GMT
Links: << >>  << T >>  << A >>
My thoughts are that you'll need a high(er) frequency external clock of
some kind.  What are your jitter requirements on the 11MHz?  If you just
need an average of 11MHz and you can skip an entire clock cycle (90ns
jitter), a digital PLL can be designed pretty easily.  If you can get by
with a few ns of jitter, there are techniques that can still produce good
results without going to extremes, but that's in brand X devices.

You'll most probably end up with a tradeoff of jitter versus external
frequency to deal with.

Think of a digital PLL as an arithmetic equivalent of an analog PLL and
you may see how to design the DPLL with limited logic requirements (phase
comparator provides an error in counts of the high frequency reference,
the CRC 2nd order filter can be approximated with some shift and
accumulation, the VCO is realized as a phase accumulator based off the
high speed clock).

The Xilinx Virtex-II devices have some nice internal digital clock
management units that can provide high speed clocks (based on at least
25MHz input frequency) with variable phase values and "global clock mux"
elements that allow glitchless switching between phases to end up with a
*very* resolute clock (in digital terms) without breaking the bank in the
smallest device of the family.

But Lattice?  Dunno.

- John_H



Colin Bury wrote:

> Hi,
>
> I need to multiply a clock from around 44kHz to 11MHz, to be
> implemented in a Lattice ISP (Programmable Logic) device.
>
> Does anyone know of how to implement a clock multiplier in
> VHDL/Verilog or have any schematics or references?
> I am considering trying to implement an All-Digital PLL (due to noise
> considerations I would prefer not use an analogue VCO), does anyone
> have any idea/know of any references on how to do this?
> Am I being stupid, or is it possible to implement this without using a
> high frequency external reference clock?
>
> Any help would be greatly appreciated.
>
> Colin Bury
> eeburyc@swan.ac.uk
> University of Wales Swansea


Article: 40191
Subject: Re: Altera FPGAs
From: John_H <johnhandwork@mail.com>
Date: Fri, 01 Mar 2002 17:21:38 GMT
Links: << >>  << T >>  << A >>
Are there many good FPGA design firms in Alaska?  I understand they've got a
bunch of people familiar with pipelining up there.


Nicholas Weaver wrote:

> B)  Pipeline.  Pipeline.  With FPGAs, ALWAYS pipeline!


Article: 40192
Subject: Re: microblaze
From: kempaj@yahoo.com (Jesse Kempa)
Date: 1 Mar 2002 09:59:18 -0800
Links: << >>  << T >>  << A >>
Thank you for the insight. We're still evaluating both solutions and
are eager to compare things without any of the marketing discussion
you refer to. My coworker can't wait for the GUI.

My comments on the use of m-blaze refer to version "2.1" which we
downloaded after getting registered.

Perhaps you can help me understand a technical detail of the m-blaze
memory architecture & associated compiler options:

Your MDK Tutorial doc, page 1-9, describes the use of "-mxl-gp-opt".
The description implies we can use this option to speed on-chip memory
access for address spaces addressable by the 16 bit Immediate.

My confusion comes from bit 9 of the address space, which is used to
define whether the peripheral is on the LMB or OPB.  So, what is the
maximum size of on-chip memory that can be used with this compiler
option?  2^15 or 2^8 or 2^?

Regards,

Jesse Kempa



Goran Bilski <goran@xilinx.com> wrote in message news:<3C7E916F.AABFA453@xilinx.com>...
> Hi,
> 
> In order to get that system working you could only copy one of the predef
> ined example
> and change a few lines, not several pages.
> I'm not sure if I want to into all the difference between MicroBlaze and 
> NIOS without
> maybe stepping into marketing territory.
> And I'm sure that you didn't try the latest MDK 2.1 of MicroBlaze, that i
> s a much improved
> version
> over the 1.9
> 
> The normal distribution of MDK is over the internet.
> 
> Xilinx will some also come out with some GUI driven system generation as 
> well.
> 
> 
> G?an Bilski
> 
> 
> Jesse Kempa wrote:
> 
> > I can help elaborate on this one. I've seen both kits, and have been
> > won over by Nios myself.
> >
> > A coworker of mine ordered his MicroBlaze kit last year and it took
> > over two months to show up. While I found that the Insight development
> > board was a pretty good softcore CPU development platform (as is the
> > Nios dev board), the MicroBlaze product itself is a bit (to say the
> > least) lacking. After receiving the kit and opening it up we found no
> > MicroBlaze CD! It showed up in a separate mailing on a generic CD-R,
> > as if it were burned on some engineer's cubicle CD burner.
> >
> > These tidbits aside, the MicroBlaze design flow is entirely script
> > based - without any GUI. Nios is also script based, but it is all
> > abstracted in their system builder software.  In order to get a basic
> > m-blaze system with CPU and a couple peripherals (UART, general
> > purpose IO), a couple of pages of typing are required to instantiate
> > everything! One goof up and no system for you! The Nios kit GUI lets
> > you make an equivalent system in seconds.
> >
> >  -- Jesse Kempa
> >
> > emanuel stiebler <emu@ecubics.com> wrote in message news:<3C7D300C.3B55
>  34A1@ecubics.com>...
> > > Victor Schutte wrote:
> > > >
> > > > I have given up trying to get hold of it.
> > >
> > > Care to elaborate a little further ?
> > >
> > > > I am now hooked on NIOS ver 2.0.
> > > > Excellent IP.
> > >
> > > I'll check ;-)
> > >
> > > cheers & thanks

Article: 40193
Subject: Re: microblaze
From: emanuel stiebler <emu@ecubics.com>
Date: Fri, 01 Mar 2002 11:33:40 -0700
Links: << >>  << T >>  << A >>
Jesse Kempa wrote:
> 
> Thank you for the insight. We're still evaluating both solutions and
> are eager to compare things without any of the marketing discussion
> you refer to. 

That's what I was asking for. An opinion of the usability of the
microblaze.
Can't go to altera ...

> My coworker can't wait for the GUI.

The GUI is probably the last thing I'm waiting for. Better
documentation,
more examples how to use it, more peripherals, OPB SDRAM, ...
 
> My comments on the use of m-blaze refer to version "2.1" which we
> downloaded after getting registered.

So, it is really available ?
Did you get the source with it ?

 
Cheers,
emanuel

Article: 40194
Subject: Xilinx Virtex Family die photos...
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Fri, 1 Mar 2002 18:40:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
Does anyone have a nice hi-res photo of a Xilinx Virtex CLB or general
die?  Google has failed me.

thanks.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 40195
Subject: Re: microblaze
From: Goran Bilski <goran@xilinx.com>
Date: Fri, 01 Mar 2002 10:42:30 -0800
Links: << >>  << T >>  << A >>
Hi,

The bit 9 for determine LMB or OPB accesses is just temporal it will vani=
shed in future
releases when
the tools automatically figure out the address decoding between LMB and O=
PB.
The compiler doesn't know if an address is in LMB or OPB, is just address=
es for the
compiler.

Use of -mxl-gp-opt option:

-mxl-gp-opt option will only access data of size 8 bytes and less using t=
he special small
data anchors [r13 an r2] . For all other
memory accesses, absolute value will be used.  for e.g. .. if you have gl=
obal variables:

int a, b, c, x[100];

Variables a, b and c will be put in small data area, which is accessed us=
ing the small data
anchor [r13]. but the array x will be put
in the data area and will be accessed using the absolute memory location =
address. Thus
-mxl-gp-opt will be of no use for such
array accesses.

You can read about this in:
"MicroBlaze Platform Generator" section of swref.pdf and (even more impor=
tant) the
"MicroBlaze
Address Map" section of the swref.pdf doc.

Hope that this helps
G=F6ran Bilski

Jesse Kempa wrote:

> Thank you for the insight. We're still evaluating both solutions and
> are eager to compare things without any of the marketing discussion
> you refer to. My coworker can't wait for the GUI.
>
> My comments on the use of m-blaze refer to version "2.1" which we
> downloaded after getting registered.
>
> Perhaps you can help me understand a technical detail of the m-blaze
> memory architecture & associated compiler options:
>
> Your MDK Tutorial doc, page 1-9, describes the use of "-mxl-gp-opt".
> The description implies we can use this option to speed on-chip memory
> access for address spaces addressable by the 16 bit Immediate.
>
> My confusion comes from bit 9 of the address space, which is used to
> define whether the peripheral is on the LMB or OPB.  So, what is the
> maximum size of on-chip memory that can be used with this compiler
> option?  2^15 or 2^8 or 2^?
>
> Regards,
>
> Jesse Kempa
>
> Goran Bilski <goran@xilinx.com> wrote in message news:<3C7E916F.AABFA45=
3@xilinx.com>...
> > Hi,
> >
> > In order to get that system working you could only copy one of the pr=
edef
> > ined example
> > and change a few lines, not several pages.
> > I'm not sure if I want to into all the difference between MicroBlaze =
and
> > NIOS without
> > maybe stepping into marketing territory.
> > And I'm sure that you didn't try the latest MDK 2.1 of MicroBlaze, th=
at i
> > s a much improved
> > version
> > over the 1.9
> >
> > The normal distribution of MDK is over the internet.
> >
> > Xilinx will some also come out with some GUI driven system generation=
 as
> > well.
> >
> >
> > G?an Bilski
> >
> >
> > Jesse Kempa wrote:
> >
> > > I can help elaborate on this one. I've seen both kits, and have bee=
n
> > > won over by Nios myself.
> > >
> > > A coworker of mine ordered his MicroBlaze kit last year and it took=

> > > over two months to show up. While I found that the Insight developm=
ent
> > > board was a pretty good softcore CPU development platform (as is th=
e
> > > Nios dev board), the MicroBlaze product itself is a bit (to say the=

> > > least) lacking. After receiving the kit and opening it up we found =
no
> > > MicroBlaze CD! It showed up in a separate mailing on a generic CD-R=
,
> > > as if it were burned on some engineer's cubicle CD burner.
> > >
> > > These tidbits aside, the MicroBlaze design flow is entirely script
> > > based - without any GUI. Nios is also script based, but it is all
> > > abstracted in their system builder software.  In order to get a bas=
ic
> > > m-blaze system with CPU and a couple peripherals (UART, general
> > > purpose IO), a couple of pages of typing are required to instantiat=
e
> > > everything! One goof up and no system for you! The Nios kit GUI let=
s
> > > you make an equivalent system in seconds.
> > >
> > >  -- Jesse Kempa
> > >
> > > emanuel stiebler <emu@ecubics.com> wrote in message news:<3C7D300C.=
3B55
> >  34A1@ecubics.com>...
> > > > Victor Schutte wrote:
> > > > >
> > > > > I have given up trying to get hold of it.
> > > >
> > > > Care to elaborate a little further ?
> > > >
> > > > > I am now hooked on NIOS ver 2.0.
> > > > > Excellent IP.
> > > >
> > > > I'll check ;-)
> > > >
> > > > cheers & thanks


Article: 40196
Subject: Re: stuck in state in Spartan-II!
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 01 Mar 2002 13:49:46 -0500
Links: << >>  << T >>  << A >>
I would continue to use the 425 kHz clock to clock the DAC.  I would
then use the rising edge of this clock to latch the data out to the DAC
data pins.  I belive the 425enable signal can just tell the 33 MHz
Process B to load new data into the previous register.  

But I actually would have done your processes a little differently.  One
of the nice things about the memory in a Spartan II is that they are
dual ported with independent clocks.  Unless you need a control signal
(like Empty or Full) passing between the two domains, you could easily
move data without the messy metastability issues.  

Actually, you HAVE to have some controls passing between the two clock
domains because there has to be a counter that increments when you put
data in and decrements when you take data out.  But this is very easy
and is essentially like the syncing you did on the 425EN signal.  But it
would eliminate the Process B logic.  The wide difference in clock
speeds makes this a much simpler problem.  I assume that you are writing
blocks of data to the FIFO?  If you are responding to each word that is
read out to the DAC, then you don't need the FIFO, right? 



Ken Mac wrote:
> 
> Phil,
> 
> Forgot to mention that the DAC is fed the 425kHz clock via a pin of my
> Spartan-II.
> 
> The DAC uses the negative edges of the 425kHz clock to take data from
> process C.
> 
> Process C uses the positive edges of the 425kHz clock to place data on the
> serial data pin for the DAC and the negative edges then drive the DAC.
> 
> My DAC output now seems to be irregular - what signal should I use to clock
> my DAC now?
> 
> Thanks again,
> 
> Ken
> 
> > > Process A:    Runs at 33MHz to fill a 16 location FIFO with 8-bit data
> > > samples and then keep it full.
> > > Process B:    Runs at 33MHz to take data from the FIFO when told to and
> > > supply it to process C via a register.
> > > Process C:    Runs at 425kHz and sends FIFO 8-bit data samples to a DAC
> > > bit-serially then asks process B for next piece of data.
> >
> > > Process A is fed with data via a Visual C++ app (the Spartan-II is
> mounted
> > > on a PCI board) which is synchronised with the FPGA using an interrupt
> pin
> > > that the FPGA can assert and the C++ can read.
> > >
> > > I have used this system for many designs with no trouble (none of them
> had
> > > multiple clock domains however).  The problem here is that the design is
> > > getting stuck in state for no apparent reason!  (i.e. the C++ hangs
> waiting
> > > for the interrupt pin!).
> >
> > Sounds to me like you have a problem crossing clock domains.
> >
> >
> > > The system works for a random number of samples (between 28 and 33 it
> seems)
> > > and then gets stuck in state. This is very strange because it means that
> my
> > > protocols do work.
> >
> > Not strange at all.  Suppose we have two registers in one clock domain
> sampling
> > a signal from the other clock domain.  If both get the same value for the
> next
> > clock, the logic works.  If only one gets the value, the logic hangs.
> >
> >
> > > The weird thing is that I put a piece of debug code in another state to
> send
> > > a signal out to a pin to probe, I ran the flow again to get a bitstream
> and
> > > the system ran perfectly for all 75001 samples I am using!  The debug
> code
> > > was "Debug <= '1'".
> >
> > Different placement, different routing, different timing, different odds
> of
> > failure.  Might work well at 25C, and fail like above at 28C.
> >
> > > Then I enabled clock DLLs using the BUFGDLL component and it hangs
> again!
> >
> > Different timing, different odds of failure.
> >
> >
> > > Previously, I had it working perfectly using the clock DLLs but without
> a
> > > FIFO (i.e. 1 sample at a time from C++ to FPGA to DAC) but I got some
> > > stutters hence I introduced the FIFO.
> > >
> > > In that design I also had hanging problems but after I rejigged my
> protocol
> > > in my VHDL state machines it worked perfectly.
> > >
> > > It seems that seemingly random changes of VHDL make or break the system.
> I
> > > guess it must be to do with my 2 different clock rates but that is the
> way
> > > it has to be.
> > >
> > > I am at a loss - anyone any ideas?
> >
> > First, sync the 425KHz to 33 MHz, then edge detect, and then use the edge
> > detected clock 425 for a clock enable for process C.  Code fragments:
> >
> > process(clk33) begin
> >   if rising_edge(clk33) then
> >     synslow <= clk425;
> >     synslow2 <= synslow;
> >     synslow3 <= synslow2;
> >     en425 <= synslow2 and not synslow3;
> >   end if;
> > end process;
> >
> > processc:
> > process(clk33) begin -- was (clk425)
> >   if rising_edge(clk33)
> >     if en425 = '1' then -- was rising_edge(clk425)
> >     ....
> >
> > The reason this (hopefully!) will solve your problem is that almost all
> logic
> > will be running on a single clock.  While there is a chance that synslow
> will
> > not correctly clock in clk425 on rising or falling edge ("go metastable"),
> > synslow2 is much less likely to fail (As mean time between failures >> age
> of
> > universe), and en425 even less so.
> >
> > Also, you could synchronize all control signals between the two processes.
> More
> > complex.
> >
> >
> > --
> > Phil Hays

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 40197
Subject: Altera Excalibur
From: "jerry1111" <jerry1111@wp.pl>
Date: Fri, 1 Mar 2002 20:03:39 +0100
Links: << >>  << T >>  << A >>
Hello,

I want to buy Altera's softcore uP. 
Which one: Nios-based or Arm-based?
Any suggestions?
Before spending money for development tools I'd like
to know the good and bad news for it.

Is it possible to move from Nios to Arm-based without
spending lot of money for Arm option (already having
Nios purchased)?

Thanks

jerry



Article: 40198
Subject: Re: Clock multiplier/ADPLL in PLD
From: Ray Andraka <ray@andraka.com>
Date: Fri, 01 Mar 2002 19:15:09 GMT
Links: << >>  << T >>  << A >>
you are the second to mention the Xilinx DLLs/DCMs.  Unfortunately, they are
of no use here since the input clock is only 44 KHz, and even the desired
output is less than half the minimum frequency for those blocks.  As for the
DPLL, it is not really a direct port from an analog PLL, there are usually no
filters per se.  Instead, the 'filtering' is done by the counters.  Actel has
an app note on doing DPLLs in FPGAs that is fairly decent.  see
http://www.actel.com/appnotes/s04_18.pdf.  You might also look at some of the
old DPLL device data sheets.  You'll still need some source of clock that is
faster than your intended output.  As I mentioned earlier, if adding an extra
external clock is unacceptable, you may be able to use a ring oscillator in
the design.

John_H wrote:

> My thoughts are that you'll need a high(er) frequency external clock of
> some kind.  What are your jitter requirements on the 11MHz?  If you just
> need an average of 11MHz and you can skip an entire clock cycle (90ns
> jitter), a digital PLL can be designed pretty easily.  If you can get by
> with a few ns of jitter, there are techniques that can still produce good
> results without going to extremes, but that's in brand X devices.
>
> You'll most probably end up with a tradeoff of jitter versus external
> frequency to deal with.
>
> Think of a digital PLL as an arithmetic equivalent of an analog PLL and
> you may see how to design the DPLL with limited logic requirements (phase
> comparator provides an error in counts of the high frequency reference,
> the CRC 2nd order filter can be approximated with some shift and
> accumulation, the VCO is realized as a phase accumulator based off the
> high speed clock).
>
> The Xilinx Virtex-II devices have some nice internal digital clock
> management units that can provide high speed clocks (based on at least
> 25MHz input frequency) with variable phase values and "global clock mux"
> elements that allow glitchless switching between phases to end up with a
> *very* resolute clock (in digital terms) without breaking the bank in the
> smallest device of the family.
>
> But Lattice?  Dunno.
>
> - John_H
>
> Colin Bury wrote:
>
> > Hi,
> >
> > I need to multiply a clock from around 44kHz to 11MHz, to be
> > implemented in a Lattice ISP (Programmable Logic) device.
> >
> > Does anyone know of how to implement a clock multiplier in
> > VHDL/Verilog or have any schematics or references?
> > I am considering trying to implement an All-Digital PLL (due to noise
> > considerations I would prefer not use an analogue VCO), does anyone
> > have any idea/know of any references on how to do this?
> > Am I being stupid, or is it possible to implement this without using a
> > high frequency external reference clock?
> >
> > Any help would be greatly appreciated.
> >
> > Colin Bury
> > eeburyc@swan.ac.uk
> > University of Wales Swansea

--
--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: 40199
Subject: Re: Rising and falling edge of a clk
From: Ray Andraka <ray@andraka.com>
Date: Fri, 01 Mar 2002 19:27:26 GMT
Links: << >>  << T >>  << A >>
VirtexE BRAMs can be written at 155MHz in any speed grade.  To do so, you will
likely have to put registers near to and with no logic between them and the
BRAMs.  Watch the loading too, routing to more than 1 BRAM for each register may
cause you some heartburn.  At higher speeds, you probably should also consider
tying the WE, and ENA inputs active and controlling your access through the
address registers instead.  You'll also need to floorplan the registers to make
sure they are located physically close to the BRAMs.

"H.L" wrote:

> Hi Peter, thanks for your reply
> I was confident of this method's effectiveness but now I am worried :)) . I
> have already done a timing analysis in the paper and also the simulation
> waveforms seem promising.
> I didnt understand what do you mean when telling me that one of my words
> arrives early and the other one late. The transmitter sends to my FPGA an
> external clock (thats the 155MHz clock), a valid signal (1 bit indicating
> the transmission time period) and of course the 16-bit words that I have to
> store. Every clock period (~6 ns) I have available in my ports one 16-bit
> word, I register two sequential words from the in port to a 32-bit register
> (31->16 the first incoming word, 15->0 the second one). Then , in another
> 32-bit register I register (2 nd time) the 32-bit word I just "made" which
> are the BRAM data_in. All the above operations are in a process that has in
> its sensitivity list the 155 clock. I write to the BRAM at 77MHz  using the
> incoming clock divide by 2 using a DLL. BRAM input signals are assigned in
> the falling edge of the 77MHz clock so as to be before the rising edge (of
> the same clock) where the BRAM samples them. The write operations are in
> another process with the slow clock in its sensitivity list.
> The timing waveforms of the simulation are the same with the timing analysis
> in paper but does this is a valid hardware design technique?
> Thanks for your time and help!
>
> Best Regards,
> Harris
>
> p.s: thats a small part of my design. I use DLL because other parts need
> them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155 MHz and I
> got many timing errors (floorplanning managed to reduce them but still lot
> of work to be done)
>
> "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> news:3C7E621F.1E77A244@xilinx.com...
> > I suggest you grab pencil and paper and do a clock-by-clock timing
> analysis. You
> > will find that your clock-speed reduction buys you nothing, unless you
> also
> > double-buffer the data.
> > One of your words arrives nice and early, the other one late. However you
> clock
> > the BRAM, one of the two words has the same old short set-up time...
> > Double-buffering would help. But Ray has mentioned some neat tricks to
> avoid the
> > long set-up time of the control inputs.
> >
> > I will get back with more constructive notes. "Gotta run"
> >
> > Peter Alfke
> > ===================
> > "H.L" wrote:
> >
> > > Hello all,
> > >
> > > I have a module that accepts 16 bit words at 155MHz and I want to store
> then
> > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA) to
> divide by
> > > 2 the 155MHz clock as this frequency seems to be pretty high to write in
> the
> > > BRAM. So far I think 2 processes are enough to do my job, one operating
> @
> > > 155MHz to accept the 16-bit data and store them in a 32-bit register and
> the
> > > another one @ 75MHz to write the content of the 32-bit register in the
> BRAM.
> > > I am thinking to assign the BRAM's signals
> (ENABLE,WRITE,ADDRESS,DATA_IN) in
> > > the falling edge of the 75MHz clock, the main reason for this is the
> setup
> > > time of the BRAMs signals (in this way the address,data are 6 ns before
> next
> > > rising edge of the clock where BRAM samples its inputs). My question now
> :)
> > > , if one process uses the falling edge of one clock does this causes
> > > problems to other processes in the design , e.g to processes that use a
> > > different clock or to  processes using the rising edge of the same
> clock?
> > >
> > > Best Regards,
> > > Harris.
> >

--
--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





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
2017JanFebMarApr2017

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