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 68700

Article: 68700
Subject: System Generator HDL co-simulatin problem
From: benkhalh@hotmail.com (Oleg)
Date: 14 Apr 2004 12:46:58 -0700
Links: << >>  << T >>  << A >>
Hi,
I am using system generator 6.1 withing Matlab 13 and ISE 6.1 and
modelsim 5.7d. When i run a HDL co-simulation of my black box(imported
VHDL to black box), the modelsim shows the following error: the
communication interface timeout, simulation halted.....and all
Matlab's windows hangs up indefinitly.
When i simulate my imported VHDL entity in black box it doesnt react
to the stimulus generated by simulink. I can see the test vectors
applied by simulink to my black box but this one doesnt react (output
= 0 all time)
Thanks for any help

Article: 68701
Subject: DDS-Based PLL
From: "Kevin Neilson" <kevin_neilson@removethiscomcast.net>
Date: Wed, 14 Apr 2004 20:29:45 GMT
Links: << >>  << T >>  << A >>
An alternative using a conventional VCO-based PLL with an FPGA would be to
implement most of the PLL as a DDS.  The FPGA would have a phase accumulator
and BRAM-based sine LUT and would output a sine to a cheap 8-bit DAC.  The
output of the DAC would be reconstructed with a simple lowpass (with a
simplicity based on the oversampling rate) and then squared with a
comparator to make a clock of any desired frequency.  The comparator would
do the job of placing the edge of the clock at the correct interpolated
point between DAC samples.  This has several advantages.  You can synthesize
any clock with any crazy multiplication ratio without fractional-N
techniques.  You can dither or spread the clock easily and digitally control
overshoot when transitioning.  You get rid of a bunch of analog hardware,
including a VCO and a loop filter and charge pump, all of which have varying
characteristics from part to part.  You could even generate really fast
clocks by bandpassing one of the DAC's images.  Yet I rarely see this
technique used.  Is is just that it's used more than I think, or does it
have some disadvantage like introducing a lot of phase noise?
-Kevin



Article: 68702
Subject: Re: Help - DDS Control in Virtex II
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 14 Apr 2004 16:35:50 -0400
Links: << >>  << T >>  << A >>
"jonathan" <dodgepickup318@yahoo.com> wrote in message
news:c5iblt$e6e$1@news.tamu.edu...
> Hi All,
>
>     I am not looking for an easier answer (unless one wants to offer it
:-))
> as I am looking for a good source to learn from or a place to begin
looking
> for answers.
> I have a Xilinx Virtex II as part of the Xilinx ExtremeDSP Kit and I am
> building a digital mixer as my first step in learning. My problem is this:
> I need a program written in C++ to have control of the DDS frequency
running
> in the FPGA. I need to find an answer such as where is the memory or
> register location going to be set in the fpga? Or, specific information
> about how to use the ZBT ram as an interface between a C program and the
> DDS? I am also using Xilinx System Generator if anyone is familiar with
it.
> Thanks for any pointers or information sources.

I don't know anything about the ExtremeDSP Kit, but generally speaking you
need to do the following:
1. Instantiate your DDS core in your design;
2. Add some registers that will be used for storing DDS parameters and
connect them to the DDS core;
3. Organize access to those registers from your host interface side (is it
PCI?);
4. Write your own or find an off-the-shelf kernel OS driver (such as
Windriver) that will talk to your board at the low level;
5. Write your C++ app that will talk to the board through the driver.

/Mikhail



Article: 68703
Subject: Re: DDS-Based PLL
From: "John_H" <johnhandwork@mail.com>
Date: Wed, 14 Apr 2004 21:00:54 GMT
Links: << >>  << T >>  << A >>
Analog Devices has a whole line of parts based on integrating the whole ball
of wax.

The technique is used, just not in the boards *we've* seen.

One of the issues is that the bulk of designs don't need a precise,
arbitrary, low jitter clock source opting instead for lower cost, fixed (or
limited) solutions.

If you have a clock that's low enough in frequency to use a really cheap
DAC, you could get better results by using the MSB output of a faster DDS.
If you're fast enough to need a decent DAC, it'll cost you.  A simple
lowpass filter works fine for some apps but may involve a less-simple filter
than you expect to block out an alias as close as the 3rd harmonic.
Oversampling is great but increases the cost of the DAC further.  The Analog
Devices chips integrate most of these functions in one device providing
exceptional spectral purity.

I put together a DDS based synthesizer that adds controlled levels of
sinusoidal jitter about 6 years ago and have since watched some of the
offerings that provide higher integration.

The higher frequency extraction with a bandpass can work but the filtering
is easier with single-sideband modulation of a high frequency carrier with a
DDS controlled offset.  I/Q modulation devices achieve this translation
(with -35 dBc images) and are used significantly in wireless systems and
don't have the narrow bandwidth, high rejection requirements of picking out,
say, the ninth harmonic.  Good I/Q is cheap stuff nowadays.


"Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message
news:Zahfc.37136$wP1.140239@attbi_s54...
> An alternative using a conventional VCO-based PLL with an FPGA would be to
> implement most of the PLL as a DDS.  The FPGA would have a phase
accumulator
> and BRAM-based sine LUT and would output a sine to a cheap 8-bit DAC.  The
> output of the DAC would be reconstructed with a simple lowpass (with a
> simplicity based on the oversampling rate) and then squared with a
> comparator to make a clock of any desired frequency.  The comparator would
> do the job of placing the edge of the clock at the correct interpolated
> point between DAC samples.  This has several advantages.  You can
synthesize
> any clock with any crazy multiplication ratio without fractional-N
> techniques.  You can dither or spread the clock easily and digitally
control
> overshoot when transitioning.  You get rid of a bunch of analog hardware,
> including a VCO and a loop filter and charge pump, all of which have
varying
> characteristics from part to part.  You could even generate really fast
> clocks by bandpassing one of the DAC's images.  Yet I rarely see this
> technique used.  Is is just that it's used more than I think, or does it
> have some disadvantage like introducing a lot of phase noise?
> -Kevin
>
>



Article: 68704
Subject: Re: what is a better approach to synthezise synchronous reset on FPGA?
From: Bassman59a@yahoo.com (Andy Peters)
Date: 14 Apr 2004 14:10:13 -0700
Links: << >>  << T >>  << A >>
"valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in message news:<c5j6rg$2bkqr$1@ID-212430.news.uni-berlin.de>...
> if Rising_Edge(Clk) then
>    if RESET = '1' then
>     ERROR_CODE <= (others => '0');
>    elsif ENABLE = '1' then
>         ...
> or
> 
>   if Rising_Edge(Clk) then
>    if ENABLE = '1' then
>         if RESET = '1' then
>             ERROR_CODE <= (others => '0');
>         else
>             ...

Well, quite clearly, the second will reset only if the ENABLE signal
is asserted.  Is that your desired functionality?

-a

Article: 68705
Subject: Re: Cyclone and ByteBlasterMV?
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Wed, 14 Apr 2004 22:47:55 +0100
Links: << >>  << T >>  << A >>

"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message
news:407d8fbc$0$31701$fa0fcedb@lovejoy.zen.co.uk...
> > > That schematic looks nothing like the insides of the
> > > ByteBlaster II cable I had (I've just shipped it off
> > > to a client and am awaiting a new one).
> >
> > What chip(s) did it use? If I know the logic family, I can probably work
> the
> > rest of it out for myself.
> > Leon
>
> Leon,
>
> From memory it was a sea of transistors on both sides with an 8 pin
> SOIC on one side.

Thanks, Nial. I think someone else mentioned something like that.

Leon



Article: 68706
Subject: Re: what is a better approach to synthezise synchronous reset on FPGA?
From: "Hendra Gunawan" <u1000393@email.sjsu.edu>
Date: Wed, 14 Apr 2004 15:42:18 -0700
Links: << >>  << T >>  << A >>
"valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in
message news:c5j6rg$2bkqr$1@ID-212430.news.uni-berlin.de...
>   if Rising_Edge(Clk) then
>    if RESET = '1' then
>     ERROR_CODE <= (others => '0');
>    elsif ENABLE = '1' then
>         ...
> or
>   if Rising_Edge(Clk) then
>    if ENABLE = '1' then
>         if RESET = '1' then
>             ERROR_CODE <= (others => '0');
>         else
>             ...

I guess it depends on what you are trying to do. The first one describes a
familiar D Flip Flop with synchronous reset and clock enable. This is the
same as  FDRE in Xilinx library. In the first case, the clock enable signal
is only required for one case. It is required if a user wants to transfer
data from the input to the output (D to Q). Clock enable signal is
irrelevant when you want to reset the flip flop. The 2nd case also describes
a similar flip flop. But in this case, the clock enable is required for both
cases. It is required if a user want to reset the flip flop and if a user
wants to transfer data from D to Q.

Hendra



Article: 68707
Subject: Re: DDS-Based PLL
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 14 Apr 2004 16:09:42 -0700
Links: << >>  << T >>  << A >>
Fine frequency resolution with reasonably low jitter.

I just finished and tested an FPGA design using a 30-bit DDS phase
accumulator that is conservatively clocked at 80 MHz and, with the help of a
DCM in Frequency Synthesis mode and a binary divider chain, generates any
frequency from 1 Hz to 80 MHz with 1 Hz granularity.
The output period jitter is <300 picoseconds peak-to-peak.
There is a roadmap to increase the output frequency to max 5 GHz at
substantially reduced jitter.

Peter Alfke 
> From: "John_H" <johnhandwork@mail.com>
> Organization: Xerox Officeprinting NewsReader Service
> Reply-To: "John_H" <johnhandwork@mail.com>
> Newsgroups: comp.arch.fpga
> Date: Wed, 14 Apr 2004 21:00:54 GMT
> Subject: Re: DDS-Based PLL
> 
> Analog Devices has a whole line of parts based on integrating the whole ball
> of wax.
> 
> The technique is used, just not in the boards *we've* seen.
> 
> One of the issues is that the bulk of designs don't need a precise,
> arbitrary, low jitter clock source opting instead for lower cost, fixed (or
> limited) solutions.
> 
> If you have a clock that's low enough in frequency to use a really cheap
> DAC, you could get better results by using the MSB output of a faster DDS.
> If you're fast enough to need a decent DAC, it'll cost you.  A simple
> lowpass filter works fine for some apps but may involve a less-simple filter
> than you expect to block out an alias as close as the 3rd harmonic.
> Oversampling is great but increases the cost of the DAC further.  The Analog
> Devices chips integrate most of these functions in one device providing
> exceptional spectral purity.
> 
> I put together a DDS based synthesizer that adds controlled levels of
> sinusoidal jitter about 6 years ago and have since watched some of the
> offerings that provide higher integration.
> 
> The higher frequency extraction with a bandpass can work but the filtering
> is easier with single-sideband modulation of a high frequency carrier with a
> DDS controlled offset.  I/Q modulation devices achieve this translation
> (with -35 dBc images) and are used significantly in wireless systems and
> don't have the narrow bandwidth, high rejection requirements of picking out,
> say, the ninth harmonic.  Good I/Q is cheap stuff nowadays.
> 
> 
> "Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message
> news:Zahfc.37136$wP1.140239@attbi_s54...
>> An alternative using a conventional VCO-based PLL with an FPGA would be to
>> implement most of the PLL as a DDS.  The FPGA would have a phase
> accumulator
>> and BRAM-based sine LUT and would output a sine to a cheap 8-bit DAC.  The
>> output of the DAC would be reconstructed with a simple lowpass (with a
>> simplicity based on the oversampling rate) and then squared with a
>> comparator to make a clock of any desired frequency.  The comparator would
>> do the job of placing the edge of the clock at the correct interpolated
>> point between DAC samples.  This has several advantages.  You can
> synthesize
>> any clock with any crazy multiplication ratio without fractional-N
>> techniques.  You can dither or spread the clock easily and digitally
> control
>> overshoot when transitioning.  You get rid of a bunch of analog hardware,
>> including a VCO and a loop filter and charge pump, all of which have
> varying
>> characteristics from part to part.  You could even generate really fast
>> clocks by bandpassing one of the DAC's images.  Yet I rarely see this
>> technique used.  Is is just that it's used more than I think, or does it
>> have some disadvantage like introducing a lot of phase noise?
>> -Kevin
>> 
>> 
> 
> 


Article: 68708
Subject: Re: Apples to Apples? Stratix II <> Virtex-II Pro
From: "Paul Leventis \(at home\)" <paul.leventis@utoronto.ca>
Date: Thu, 15 Apr 2004 05:48:39 GMT
Links: << >>  << T >>  << A >>
Hi Austin,

> As for 90nm 'not buying a huge performance improvement', that remains to
> be seen when we announce V4 and publish its specifications.  Intel has
> made performance gains, so has TI.  It can be done.

The Intels of the world don't have the 500 million transistor problem that
PLD vendors do -- and the CPU vendors can afford massive thermal solutions.
Don't get me wrong, 90 um does buy performance (we see it too -- 50%
performance in Stratix II vs. Stratix isn't all from cute architecture
improvements).  It just doesn't come automatically like it once did, and the
power/performance trade-offs are very different.

> We did not intend to get any improvement in performance at all in S3
> (over Virtex II at 150 nm) but just crash through the $$$ barrier for
> logic per dollar, which is totally different that what we are doing for
V4.
> So to compare our 90nm S3 product to your 130nm one, is also not
> relevant:  cost is the issue, not speed.  Cost wins in this market.

We too did not architect Cyclone with speed as the target -- our goal was to
produce a very low-cost product, a goal which we exceeded.  We were careful
to examine the speed-vs-area trade-offs of all decisions and didn't
needlessly sacrifice performance.  It's pretty easy to make a low-cost
chip -- making a low-cost chip that is also zippy is a much more difficult
problem.

And speed can be used to reduce cost.  If speed is unimportant, why sell
faster speed grades of S3?  For a user who needs to buy a fast speed grade
of S3 (if they can get their hands on one...), their design will often meet
performance requirements in the slowest Cyclone device.  And if you can get
a huge performance win, you can reduce the number of LEs required (reducing
degree of parallelism for given throughput, etc.) potentially reducing the
size of the device required, which is another cost lever.

I guess we'll have to wait until Cyclone II is released to get a true
apples-to-apples comparison of cost vs. performance in the same process.
But we'd really have to work hard at cutting performance relative to Cyclone
in order for that comparison to not look good for us...

> The one thing that I don't understand, is why do you not have SRL16s?
> The architecture of having these SRL16s is such a huge advantage (for
> us), I am amazed you haven't provided a competitive answer to them.

Obviously we have considered them.  But the "huge advantage" isn't that
clear to me (though Ray has some interesting applications).  If all you have
are 18K RAMs, then yes, some sort of small memory would be handy.  But how
much die size are you paying for SRL16s?  Clearly SRL16 consumes some
appreciable amount of die space otherwise you wouldn't have invested the
effort required to design and layout two different slices in Spartan-3.
Would that die size be better spent on small discrete memories (such as our
M512 blocks)?  That all depends on what you think the types of designs
implemented in FPGAs look like, how much memory they have, what that memory
is doing, how it is organized, whether shift registers are related or not,
etc.

The continued presence of M512 blocks in Stratix II suggests that we think
that a mix of small, medium, and large memories, aggressive packing of logic
with registers into LEs, and SW/IP support for packing shift registers into
RAMs provides the most cost-effective solution.

> Now you have reached parity with the ALM (which is all that we see in
> our benchmarks)

We see a 54% advantage ALM vs. LC, you see a 0% advantage...  What does it
matter?  No one will believe either of us -- all I can do is to (a) say that
we believe Stratix II is 25% more efficient than Stratix (which we
definitely know how to measure) (b) point to our respective whitepapers on
the topic (http://www.altera.com/literature/wp/wpstxiiple.pdf,
http://www.altera.com/literature/wp/wpstxiixlnx.pdf, Xilnx WP209) and (c)
wait five years or so to see what the marketplace has to say.

Regards,

Paul Leventis
Altera Corp.



Article: 68709
Subject: Re: DDS-Based PLL
From: "Kevin Neilson" <kevin_neilson@removethiscomcast.net>
Date: Thu, 15 Apr 2004 05:51:10 GMT
Links: << >>  << T >>  << A >>
Peter,
I'd like to know more about this.  If the output of a phase accumulator has
300ps jitter, then that indicates that the phase accumulator clock is at
least 3.3GHz.  How would you ever get speeds like that in a Xilinx?
-Kevin

"Peter Alfke" <peter@xilinx.com> wrote in message
news:BCA312C6.5ED9%peter@xilinx.com...
> Fine frequency resolution with reasonably low jitter.
>
> I just finished and tested an FPGA design using a 30-bit DDS phase
> accumulator that is conservatively clocked at 80 MHz and, with the help of
a
> DCM in Frequency Synthesis mode and a binary divider chain, generates any
> frequency from 1 Hz to 80 MHz with 1 Hz granularity.
> The output period jitter is <300 picoseconds peak-to-peak.
> There is a roadmap to increase the output frequency to max 5 GHz at
> substantially reduced jitter.
>
> Peter Alfke
> > From: "John_H" <johnhandwork@mail.com>
> > Organization: Xerox Officeprinting NewsReader Service
> > Reply-To: "John_H" <johnhandwork@mail.com>
> > Newsgroups: comp.arch.fpga
> > Date: Wed, 14 Apr 2004 21:00:54 GMT
> > Subject: Re: DDS-Based PLL
> >
> > Analog Devices has a whole line of parts based on integrating the whole
ball
> > of wax.
> >
> > The technique is used, just not in the boards *we've* seen.
> >
> > One of the issues is that the bulk of designs don't need a precise,
> > arbitrary, low jitter clock source opting instead for lower cost, fixed
(or
> > limited) solutions.
> >
> > If you have a clock that's low enough in frequency to use a really cheap
> > DAC, you could get better results by using the MSB output of a faster
DDS.
> > If you're fast enough to need a decent DAC, it'll cost you.  A simple
> > lowpass filter works fine for some apps but may involve a less-simple
filter
> > than you expect to block out an alias as close as the 3rd harmonic.
> > Oversampling is great but increases the cost of the DAC further.  The
Analog
> > Devices chips integrate most of these functions in one device providing
> > exceptional spectral purity.
> >
> > I put together a DDS based synthesizer that adds controlled levels of
> > sinusoidal jitter about 6 years ago and have since watched some of the
> > offerings that provide higher integration.
> >
> > The higher frequency extraction with a bandpass can work but the
filtering
> > is easier with single-sideband modulation of a high frequency carrier
with a
> > DDS controlled offset.  I/Q modulation devices achieve this translation
> > (with -35 dBc images) and are used significantly in wireless systems and
> > don't have the narrow bandwidth, high rejection requirements of picking
out,
> > say, the ninth harmonic.  Good I/Q is cheap stuff nowadays.
> >
> >
> > "Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message
> > news:Zahfc.37136$wP1.140239@attbi_s54...
> >> An alternative using a conventional VCO-based PLL with an FPGA would be
to
> >> implement most of the PLL as a DDS.  The FPGA would have a phase
> > accumulator
> >> and BRAM-based sine LUT and would output a sine to a cheap 8-bit DAC.
The
> >> output of the DAC would be reconstructed with a simple lowpass (with a
> >> simplicity based on the oversampling rate) and then squared with a
> >> comparator to make a clock of any desired frequency.  The comparator
would
> >> do the job of placing the edge of the clock at the correct interpolated
> >> point between DAC samples.  This has several advantages.  You can
> > synthesize
> >> any clock with any crazy multiplication ratio without fractional-N
> >> techniques.  You can dither or spread the clock easily and digitally
> > control
> >> overshoot when transitioning.  You get rid of a bunch of analog
hardware,
> >> including a VCO and a loop filter and charge pump, all of which have
> > varying
> >> characteristics from part to part.  You could even generate really fast
> >> clocks by bandpassing one of the DAC's images.  Yet I rarely see this
> >> technique used.  Is is just that it's used more than I think, or does
it
> >> have some disadvantage like introducing a lot of phase noise?
> >> -Kevin
> >>
> >>
> >
> >
>



Article: 68710
Subject: Re: Writing PCI constraints in Altera
From: davidk@altera.com (David Karchmer)
Date: 14 Apr 2004 22:51:23 -0700
Links: << >>  << T >>  << A >>
> The PCI spec says I need to ensure a setup time of 7ns for all pins.

If you need a setup time of 7ns, simply add a TSU_REQUIREMENT of 7ns.
You can add this assignment individually to each of your pins (using
the Assignment Editor), use wildcards to group pins together, or
simply add a global Tsu requirement ("Timing Settings" DLG).
Using Tcl (if you are a command-line type of guy), simply do:

     set_global_assignment -name TSU_REQUIREMENT 7ns
or
     set_instance_assignment -to * -name TSU_REQUIREMENT 7ns

(Use "quartus_sh --qhelp" for more info on Tcl)

> The PCI clock itself works at 33Mhz. I want to know the following:
> 1) Is it okay if I just constraint the PCI clk of my design to 50Mhz
> (30ns for the 33Mhz clock and another 10ns to ensures that the setup
> time is met)? I realise this will be an overkill on the internal logic
> but may save me some effort.

Not really, increasing the code frequency is not going to help you
with your I/O timing. If anything, it will make it worse. You need an
I/O timing constraint to get the fitter to optimize the I/O path(s)

> 2) The other way I think to do this is to constraint the PCI clk to
> 33MHz and specify the external delay on all the PCI signals to 7 or
> 8ns. While setting PCI clk to 33Mhz I also ticked the option of
> including external delays in the frequency calculation. Is this the
> correct approach? OR do I need to setup the tco.

This will also work, specially in V4.0 where we added support for the
new INPUT_MAX_DELAY constraint (a great improvement over the
EXTERNAL_DELAY feature in V3.0), but in your case, it seems like a
simple TSU requirement is all you need (at least in terms of time
constraining the design)

And yes, the Tsu will only optimize your input path. For the output
path, you need to specify a TCO_REQUIREMENT using the same methodology
(or OUTPUT_MAX_DELAY in V4.0)

As Subroto indicated, studying the PCI core provided by Altera is a
good way to learn how to do it.

-David Karchmer
 Altera Corp.

Article: 68711
Subject: Re: Apples to Apples? Stratrix Two <> Virtex II Pro
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 15 Apr 2004 06:58:46 -0000
Links: << >>  << T >>  << A >>
>We typically internally benchmark our Quartus p&r with randomly selected pin
>placements.  This mimics the situation you point out above, where I/O
>locations are selected and locked down before the design has been fully
>implemented. ...

Change of topic, but I'm curious.

What fraction of P&R runs have the IO pins locked down?

I'd guess many/most, but maybe my view is warped.

I generally assume that the pin assignment is a cooperative project
between the PCB designer and the FPGA designer.  Clocks and high
speed signals get more attention, but sometimes moving a signal
to a different pin helps the board and sometimes it helps the FPGA.

At some point the pin assignment gets fixed and the board gets built.
But the FPGA design continues to evolve: sometimes minor bug fixes or
easy enhancements, sometimes major upgrades.  But all using the
initial I/O pin assignment.

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


Article: 68712
Subject: Re: DDS-Based PLL
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Thu, 15 Apr 2004 17:37:37 +1000
Links: << >>  << T >>  << A >>
On Thu, 15 Apr 2004 05:51:10 GMT, "Kevin Neilson"
<kevin_neilson@removethiscomcast.net> wrote:

>Peter,
>I'd like to know more about this.  If the output of a phase accumulator has
>300ps jitter, then that indicates that the phase accumulator clock is at
>least 3.3GHz.  How would you ever get speeds like that in a Xilinx?
>-Kevin

An ability to position an edge within 300ps does not imply that a
3+GHz clock has been used.  It is possible to use multiple phases of a
lower frequency clock to achieve the same thing.

Regards,
Allan.

Article: 68713
Subject: Re: VirtexII : XC2V2000 Design
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Thu, 15 Apr 2004 07:51:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
Steve Merritt <steveb_merritt@nospamhotmail.com> wrote:
: Uwe -

: The XCF32 _is_ available now.  Please feel free to contact Insight UK for a
: quote.

Are you sure, Insight UK is allowed to deliver Xilinx parts to Germany? At
least Avnet USA was not...

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 68714
Subject: Re: DDS-Based PLL
From: hmurray@suespammers.org (Hal Murray)
Date: Thu, 15 Apr 2004 09:42:57 -0000
Links: << >>  << T >>  << A >>
>An ability to position an edge within 300ps does not imply that a
>3+GHz clock has been used.  It is possible to use multiple phases of a
>lower frequency clock to achieve the same thing.

Or an adjustable delay.  Consider the MC100E195
  http://www.onsemi.com/pub/Collateral/MC10E195-D.PDF
It claims 20 ps resolution.  (Mainly for ATE equipment, I think.)

I've always wanted to build something that could use one of them.

I'd guess Peter is using the equivalent thing packaged in a DCM

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


Article: 68715
Subject: Re: what is a better approach to synthezise synchronous reset on FPGA?
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Thu, 15 Apr 2004 11:42:13 GMT
Links: << >>  << T >>  << A >>
> Let me open another can of worms by saying 'why do you want a reset
at
> all?'.  Resets in *most* cases simply use up logic and routing
resources
> unnecessarily as all the fpga elements are initialised on powerup.
You can
> even control the initialisation states of individual registers if
necessary.
> In *most* cases resets are mainly there to make simulations look
good by
> removing unknown signal conditions.

And when you target an ASIC? Is it ok to have registers without a
reset in an ASIC? What about the scan chain for BIST?

Martin
--
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/




Article: 68716
Subject: Re: Yet Another Altera Online Support Is USELESS Rant...
From: rrr@ieee.org (Rajeev)
Date: 15 Apr 2004 05:06:42 -0700
Links: << >>  << T >>  << A >>
"Kenneth Land" <kland1@neuralog1.com1> wrote in message news:<107r15nglancv04@news.supernews.com>...

<...>

> What would/should be the effect of operating a SPI port on unused pins?
> Should it function or do I have to do something meaningful will the MISO
> input?

Can't speak to NIOS implementation, but in general you should be able
to do SPI writes all day long to unused pins.  You should be able to do
SPI reads also, just the data you'll get back will be all zeros or all ones
depending on the state of the data-in pin.  SPI is not real complicated.

Hope this helps,
-rajeev-

Article: 68717
Subject: Re: what is a better approach to synthezise synchronous reset on FPGA?
From: "Steve Merritt" <steveb_merritt@NOSPAMhotmail.com>
Date: Thu, 15 Apr 2004 13:32:38 +0100
Links: << >>  << T >>  << A >>
In the title of this thread - he did specifically ask about 'Synchronous
reset on FPGA'

Best Regards

-- 
Steve Merritt BEng (Hons) CEng MIEE
XILINX Gold Certified Field Applications Engineer
Insight MEMEC

Click link below for more information on :
XILINX Free Training
<http://www.xilinx.com/support/training/europe-home-page.htm>
XILINX Design Services
<http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Design+Service
s>
10 Gbps Serial IO on FPGA <http://www.xilinx.com/systemio/10gig/index.htm>

Or Tel - 08707 356532 for more information



"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message
news:pyufc.448237$Or1.234590@news.chello.at...
> > Let me open another can of worms by saying 'why do you want a reset
> at
> > all?'.  Resets in *most* cases simply use up logic and routing
> resources
> > unnecessarily as all the fpga elements are initialised on powerup.
> You can
> > even control the initialisation states of individual registers if
> necessary.
> > In *most* cases resets are mainly there to make simulations look
> good by
> > removing unknown signal conditions.
>
> And when you target an ASIC? Is it ok to have registers without a
> reset in an ASIC? What about the scan chain for BIST?
>
> Martin
> --
> ----------------------------------------------
> JOP - a Java Processor core for FPGAs:
> http://www.jopdesign.com/
>
>
>



Article: 68718
Subject: Re: System Generator HDL co-simulatin problem
From: rrr@ieee.org (Rajeev)
Date: 15 Apr 2004 05:33:29 -0700
Links: << >>  << T >>  << A >>
Oleg,

In Altera DSPBuilder I have found that it is not possible to simulate
external VHDL, if I want simulation I have to fill in the black box with
equivalent model built out of Simulink _or_ Altera blocks.  I would be
very interested to know if System Generator supports simulation of external
VHDL.  

However Matlab and Mentor have a product available that allows running
ModelSim VHDL and Verilog simulations from Matlab+Simulink.

http://www.mathworks.com/company/pressroom/articles/article7062.html

http://www.mathworks.com/products/modelsim/

I'm also interested to hear your overall experience and satisfaction with
SystemGenerator, online or off.

Regards,
-rajeev-
---------------
benkhalh@hotmail.com (Oleg) wrote in message news:<5f8ab9cc.0404141146.31389696@posting.google.com>...
> Hi,
> I am using system generator 6.1 withing Matlab 13 and ISE 6.1 and
> modelsim 5.7d. When i run a HDL co-simulation of my black box(imported
> VHDL to black box), the modelsim shows the following error: the
> communication interface timeout, simulation halted.....and all
> Matlab's windows hangs up indefinitly.
> When i simulate my imported VHDL entity in black box it doesnt react
> to the stimulus generated by simulink. I can see the test vectors
> applied by simulink to my black box but this one doesnt react (output
> = 0 all time)
> Thanks for any help

Article: 68719
Subject: Re: what is a better approach to synthezise synchronous reset on FPGA?
From: "jakab tanko" <jtanko@ics-ltd.com>
Date: Thu, 15 Apr 2004 09:20:52 -0400
Links: << >>  << T >>  << A >>
On the "can of worms"...since it is allready opened:
If you don't have a reset how you bring the FPGA logic into a known
state without power cycle?
---
jakab
"Steve Merritt" <steveb_merritt@NOSPAMhotmail.com> wrote in message
news:Keefc.123$QB3.56@newsfe5-gui.server.ntli.net...
> Hi Valentin,
>
> The first one is the better way to do it.  The second will only work if
your
> enable is high.
>
> Let me open another can of worms by saying 'why do you want a reset at
> all?'.  Resets in *most* cases simply use up logic and routing resources
> unnecessarily as all the fpga elements are initialised on powerup.  You
can
> even control the initialisation states of individual registers if
necessary.
> In *most* cases resets are mainly there to make simulations look good by
> removing unknown signal conditions.
>
> You may even miss out on some very useful resources if you automatically
> apply resets to all your code... for example if you are using a Xilinx
> Virtex device and you infer a shift register (i.e. 16 bits) in your HDL,
you
> will not be using a single SRL (Shift Register LUT) element, you will be
> using 16 registers.
>
> Food for thought ;)
>
> Regards,
>
>
> --
> Steve Merritt BEng (Hons) CEng MIEE
> XILINX Gold Certified Field Applications Engineer
> Insight MEMEC
>
> Click link below for more information on :
> XILINX Free Training
> <http://www.xilinx.com/support/training/europe-home-page.htm>
> XILINX Design Services
>
<http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Design+Service
> s>
> 10 Gbps Serial IO on FPGA <http://www.xilinx.com/systemio/10gig/index.htm>
>
> Or Tel - 08707 356532 for more information
>
> "valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in
> message news:c5j6rg$2bkqr$1@ID-212430.news.uni-berlin.de...
> >   if Rising_Edge(Clk) then
> >    if RESET = '1' then
> >     ERROR_CODE <= (others => '0');
> >    elsif ENABLE = '1' then
> >         ...
> > or
> >
> >   if Rising_Edge(Clk) then
> >    if ENABLE = '1' then
> >         if RESET = '1' then
> >             ERROR_CODE <= (others => '0');
> >         else
> >             ...
> >
> >
>
>



Article: 68720
Subject: Re: what is a better approach to synthezise synchronous reset on FPGA?
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Thu, 15 Apr 2004 13:26:53 GMT
Links: << >>  << T >>  << A >>
But my question is still open ;-)

Do I need a reset for every flip-flop in an ASIC?
I want only use designs in an FPGA which are not to hard to transfer to
an ASIC. With some care only the memory models have to be exchanged and
as I know there are tools to add the BIST circuits 'on top' of the
design. Have been involved in an FPGA design that was transfered to an
ASIC, but all flip-flops where reset (there was discussion about asynch.
vs. synch reset).

Martin
--
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/

"Steve Merritt" <steveb_merritt@NOSPAMhotmail.com> schrieb im Newsbeitrag
news:ehvfc.339$c33.133@newsfe2-gui.server.ntli.net...
> In the title of this thread - he did specifically ask about
'Synchronous
> reset on FPGA'
>
> Best Regards
>
> --
> Steve Merritt BEng (Hons) CEng MIEE
> XILINX Gold Certified Field Applications Engineer
> Insight MEMEC
>
> Click link below for more information on :
> XILINX Free Training
> <http://www.xilinx.com/support/training/europe-home-page.htm>
> XILINX Design Services
>
<http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Design+Serv
ice
> s>
> 10 Gbps Serial IO on FPGA
<http://www.xilinx.com/systemio/10gig/index.htm>
>
> Or Tel - 08707 356532 for more information
>
>
>
> "Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message
> news:pyufc.448237$Or1.234590@news.chello.at...
> > > Let me open another can of worms by saying 'why do you want a reset
> > at
> > > all?'.  Resets in *most* cases simply use up logic and routing
> > resources
> > > unnecessarily as all the fpga elements are initialised on powerup.
> > You can
> > > even control the initialisation states of individual registers if
> > necessary.
> > > In *most* cases resets are mainly there to make simulations look
> > good by
> > > removing unknown signal conditions.
> >
> > And when you target an ASIC? Is it ok to have registers without a
> > reset in an ASIC? What about the scan chain for BIST?
> >
> > Martin
> > --
> > ----------------------------------------------
> > JOP - a Java Processor core for FPGAs:
> > http://www.jopdesign.com/
> >
> >
> >
>
>



Article: 68721
Subject: Re: what is a better approach to synthezise synchronous reset on FPGA?
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Thu, 15 Apr 2004 13:39:53 GMT
Links: << >>  << T >>  << A >>
You get a known state after configuration (you don't need a power up).

All flip-flops are in a defined state after configuration. But if 0 or 1
is the default state depends on your logic and synthesis tool. In Quartus
you'll get a warning when some filp-flops power up 1 (power up is
configuration). In reality all registers are cleared, but optimization
can change the logic in a way that some registers are inverted and will
be effectively 1 with respect to your original logic.

You can use this default state to generat an internal reset for some
logic without an external reset pin. E.g.:

--
-- intern reset
--
 signal int_res   : std_logic;
 signal res_cnt   : unsigned(2 downto 0);

begin

process(clk_int)
begin
 if rising_edge(clk_int) then
  if (res_cnt/="111") then
   res_cnt <= res_cnt+1;
  end if;

  int_res <= not res_cnt(0) or not res_cnt(1) or not res_cnt(2);
 end if;
end process;

With this logic res_cnt will usually be "000" after configuration, but
you have to check with simulation after P&R.

Martin
--
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/


"jakab tanko" <jtanko@ics-ltd.com> schrieb im Newsbeitrag
news:c5m2e4$8j$1@news.storm.ca...
> On the "can of worms"...since it is allready opened:
> If you don't have a reset how you bring the FPGA logic into a known
> state without power cycle?
> ---
> jakab
> "Steve Merritt" <steveb_merritt@NOSPAMhotmail.com> wrote in message
> news:Keefc.123$QB3.56@newsfe5-gui.server.ntli.net...
> > Hi Valentin,
> >
> > The first one is the better way to do it.  The second will only work
if
> your
> > enable is high.
> >
> > Let me open another can of worms by saying 'why do you want a reset
at
> > all?'.  Resets in *most* cases simply use up logic and routing
resources
> > unnecessarily as all the fpga elements are initialised on powerup.
You
> can
> > even control the initialisation states of individual registers if
> necessary.
> > In *most* cases resets are mainly there to make simulations look good
by
> > removing unknown signal conditions.
> >
> > You may even miss out on some very useful resources if you
automatically
> > apply resets to all your code... for example if you are using a
Xilinx
> > Virtex device and you infer a shift register (i.e. 16 bits) in your
HDL,
> you
> > will not be using a single SRL (Shift Register LUT) element, you will
be
> > using 16 registers.
> >
> > Food for thought ;)
> >
> > Regards,
> >
> >
> > --
> > Steve Merritt BEng (Hons) CEng MIEE
> > XILINX Gold Certified Field Applications Engineer
> > Insight MEMEC
> >
> > Click link below for more information on :
> > XILINX Free Training
> > <http://www.xilinx.com/support/training/europe-home-page.htm>
> > XILINX Design Services
> >
>
<http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Design+Serv
ice
> > s>
> > 10 Gbps Serial IO on FPGA
<http://www.xilinx.com/systemio/10gig/index.htm>
> >
> > Or Tel - 08707 356532 for more information
> >
> > "valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote
in
> > message news:c5j6rg$2bkqr$1@ID-212430.news.uni-berlin.de...
> > >   if Rising_Edge(Clk) then
> > >    if RESET = '1' then
> > >     ERROR_CODE <= (others => '0');
> > >    elsif ENABLE = '1' then
> > >         ...
> > > or
> > >
> > >   if Rising_Edge(Clk) then
> > >    if ENABLE = '1' then
> > >         if RESET = '1' then
> > >             ERROR_CODE <= (others => '0');
> > >         else
> > >             ...
> > >
> > >
> >
> >
>
>



Article: 68722
Subject: Re: what is a better approach to synthezise synchronous reset on FPGA?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 15 Apr 2004 09:41:47 -0400
Links: << >>  << T >>  << A >>
There is no need to reset every flip-flop in a design.  A reset signal that
breaks any feedback loops so that the design is in  a known state after some
number of clock cycles with the feedback loop and inputs forced is sufficient.
For example, a DSP design typically has a pipelined data path with little or no
feedback, and some sort of sequencer.  It is sufficient to reset the sequencer,
and hold the inputs at a known state (typically zero) long enough for any data
in the pipeline to propagate out.  If you also hold the outputs at zero while
the reset sequence is in progress, it becomes impossible to tell the difference
from outside the chip between a reset that clears every last flip-flop and one
that holds the input, output and a few key points at reset for some
predetermined length of time.  The latter doesn't chew up routing and LUT
resources the way the reset everything approach does.

jakab tanko wrote:

> On the "can of worms"...since it is allready opened:
> If you don't have a reset how you bring the FPGA logic into a known
> state without power cycle?
> ---
> jakab
> "Steve Merritt" <steveb_merritt@NOSPAMhotmail.com> wrote in message
> news:Keefc.123$QB3.56@newsfe5-gui.server.ntli.net...
> > Hi Valentin,
> >
> > The first one is the better way to do it.  The second will only work if
> your
> > enable is high.
> >
> > Let me open another can of worms by saying 'why do you want a reset at
> > all?'.  Resets in *most* cases simply use up logic and routing resources
> > unnecessarily as all the fpga elements are initialised on powerup.  You
> can
> > even control the initialisation states of individual registers if
> necessary.
> > In *most* cases resets are mainly there to make simulations look good by
> > removing unknown signal conditions.
> >
> > You may even miss out on some very useful resources if you automatically
> > apply resets to all your code... for example if you are using a Xilinx
> > Virtex device and you infer a shift register (i.e. 16 bits) in your HDL,
> you
> > will not be using a single SRL (Shift Register LUT) element, you will be
> > using 16 registers.
> >
> > Food for thought ;)
> >
> > Regards,
> >
> >
> > --
> > Steve Merritt BEng (Hons) CEng MIEE
> > XILINX Gold Certified Field Applications Engineer
> > Insight MEMEC
> >
> > Click link below for more information on :
> > XILINX Free Training
> > <http://www.xilinx.com/support/training/europe-home-page.htm>
> > XILINX Design Services
> >
> <http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Design+Service
> > s>
> > 10 Gbps Serial IO on FPGA <http://www.xilinx.com/systemio/10gig/index.htm>
> >
> > Or Tel - 08707 356532 for more information
> >
> > "valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in
> > message news:c5j6rg$2bkqr$1@ID-212430.news.uni-berlin.de...
> > >   if Rising_Edge(Clk) then
> > >    if RESET = '1' then
> > >     ERROR_CODE <= (others => '0');
> > >    elsif ENABLE = '1' then
> > >         ...
> > > or
> > >
> > >   if Rising_Edge(Clk) then
> > >    if ENABLE = '1' then
> > >         if RESET = '1' then
> > >             ERROR_CODE <= (others => '0');
> > >         else
> > >             ...
> > >
> > >
> >
> >

--
--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: 68723
Subject: Re: Apples to Apples? Stratix II <> Virtex-II Pro
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 15 Apr 2004 07:36:12 -0700
Links: << >>  << T >>  << A >>
Paul,

Excepting the performance claims, we seem to be in "violent agreement" 
yet again.  It surprises me when people are amazed when we agree on 
something.  In large part we agree on a vast number of issues.

One item you failed to mention is that our die size is a lot smaller 
than yours in comparable technologies.  That also has something to do 
with trade-offs made in S3.  As for cutting the number of SRL16s in 
half, even Ray wasn't able to use 100% of them, and the area penalty 
while small, adds up as it is replicated everywhere.  Cost cost cost. 
That is all about S3. (As well as it has to have margin margin margin) 
as no one works for free.

As for the faster speed grade, we wanted to have a one speed grade 
family for S3, but there are some customers who basically are trying to 
replace a VII with the S3.  The product was not intented to do that (as 
pulling an "Osborne" is not good for business!).  But, as we had yield 
to a faster grade, and we can charge for it if people want it, why not 
get the money?

Poor Adam, I knew him, and traveled and lectured with him a long time 
ago.  Funny his failure is now a standard business school study case. 
He is but one example of why we should all strive to be humble....

http://en.wikipedia.org/wiki/Adam_Osborne

Good luck.

Austin

Article: 68724
Subject: Re: Apples to Apples? Stratix II <> Virtex-II Pro
From: Ray Andraka <ray@andraka.com>
Date: Thu, 15 Apr 2004 11:52:58 -0400
Links: << >>  << T >>  << A >>
No, but I did do a design where  a little more than 70% of the LUTs were
SRL16's.  They are wonderful for reloadable LUTs, which is convenient for
making adaptive filters using distributed arithmetic, for example.
Fortunately, filters only use 50% of the LUTs as SRL's so they still work
out in the S3 architecture.  Where it hurts is on big delay queues in which
case the size of the delay queue is doubled since the LUTs between SRL's
are hard to route to when the SRL's are strung together in a big delay.
The flip side, is that it is not as critical as it was with Virtex I
because there is more BRAM to soak up delay queues with.

Austin Lesea wrote:

> One item you failed to mention is that our die size is a lot smaller
> than yours in comparable technologies.  That also has something to do
> with trade-offs made in S3.  As for cutting the number of SRL16s in
> half, even Ray wasn't able to use 100% of them, and the area penalty
> while small, adds up as it is replicated everywhere.  Cost cost cost.
> That is all about S3. (As well as it has to have margin margin margin)
> as no one works for free.
>
>
> Austin

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