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 40500

Article: 40500
Subject: Error in Foundation 4.1i
From: "Peter Waldeck" <pjwaldeck@hotmail.com>
Date: Fri, 8 Mar 2002 15:30:30 +1000
Links: << >>  << T >>  << A >>
Hi,
I'm trying to do a design for a VirtexII using ISE 4.1i and I can't
understand the synthesis errors I'm getting.  (I am fairly new to FPGA's as
well...)  I have two .vhd files - both of which are included in the work
library.  The first, mygpio.vhd, tries to instantiate an entity from the
second - pselect.vhd.  Within pselect, an architecture imp is declared.  But
the synthesis tool doesn't like it -

ERROR:HDLParsers:3281 - C:\Peripheral\peripheral/mygpio.vhd Line 81. imp is
not an architecture body for pselect in library work.

I don't understand it - are there some path settings that are wrong?  Or do
I have to do things in a specific order?

Thanks!
Peter



Article: 40501
Subject: GATE ARRAY PROJECT
From: dand@dkdinst.com (dan doberstein)
Date: 7 Mar 2002 22:59:08 -0800
Links: << >>  << T >>  << A >>
We need a small Gate Array job done. It's a port expander, equivilent
to 6 parralel ports ( output only, 74LS374 latch type) with a 3 bit
write strobe decoder, similar to 74LS138 so that each can be written
to via 8 bit bus

total outputs: 48 data bits, six 8 bit registers
total inputs: 4, 3 select , one strobe.
Speed: Not critcal, 74HC speed is good enough.

Can reach at;

info@dkdinst.com

805-929-2285
Dan D.

Article: 40502
Subject: Re: Webpack/SpartanII maplib:93 error
From: jschneider@cix.ceeowe.uk (Jon Schneider)
Date: Fri, 8 Mar 2002 07:34 +0000 (GMT Standard Time)
Links: << >>  << T >>  << A >>
In article <8bdb52f9.0203072034.5c7b52d@posting.google.com>, 
dsredy3@mailcity.com (MegaPowerStar) wrote:

> Jon Schneider <jschneider@cix.ceeowe.ewekay> wrote in message 
> > news:<3C87F0CE.25AD4750@cix.ceeowe.ewekay>...
> > I'm getting
> > 
> > ERROR:MapLib:93 - Illegal LOC on symbol "ucs" (pad signal=ucs) or 
> > BUFGP
> > symbol
> >    "ucs_BUFGP" (output signal=ucs_BUFGP), IPAD-IBUFG should only be
> > LOCed to
> >    GCLKIOB site.
> hi jon
> you better instantiate an input buffer IBUF. pass your input signal 
> through IBUF

That cures it.

Thanks

Jon


Article: 40503
Subject: Xilinx 32 Point FFT for post synthesis simulation ?
From: google@rauschert-online.de (Peter Rauschert)
Date: 7 Mar 2002 23:35:47 -0800
Links: << >>  << T >>  << A >>
Hi,

I am working with FPGA Advantage and used the Xilinx Core Generator to
get a 32 point fft component for my design. The behavioral simulation
with Modelsim works fine, but the post synthesis simulation doesn't
work anymore. The ovflo signal comes up. Does anybody out there have
an idea ?

I guess the .mif files (for shift operation while calculation) are
only used for behavioral simulation and for synthesis the scale factor
is included into the delivered netlist.

Has anybody ever implemented a Xilinx 32 point FFT with FPGA Advantage
(HDL Designer/Modelsim/Leonard Spectrum) ?

Thanks !

Article: 40504
Subject: a simulation question about apex20ke_asynch_lcell
From: shengyu_shen@hotmail.com (ssy)
Date: 8 Mar 2002 00:27:51 -0800
Links: << >>  << T >>  << A >>
Hi everyone

I perform post syn simulation with modelsim5.5e, in my design , I some
module use high active reset, other use low active, so I need to
invert global reset signal(low active).

but i find that the reset pass though an apex20ke_asynch_lcell, and in
the time zone that should got high value, it appear to be 1'bx.

so I trace into apex20ke_asynch_lcell, and found the following
statements

buf (icascin, cascin);
data=&#65288;long string...&#65289; && icascin;
and (combout, data, 'b1) ;

in this apex20ke_asynch_lcell that act as inverter, the cascin is not
connected, so it must be an 1'bz, so I can not got an high active
reset signal on combout.

why?

Article: 40505
Subject: Re: high active and low active reset signal mixed in a design
From: shengyu_shen@hotmail.com (ssy)
Date: 8 Mar 2002 00:31:42 -0800
Links: << >>  << T >>  << A >>
Hi everyone

I perform post syn simulation with modelsim5.5e, in my design , I some
module use high active reset, other use low active, so I need to
invert global reset signal(low active).

but i find that the reset pass though an apex20ke_asynch_lcell, and in
the time zone that should got high value, it appear to be 1'bx.

so I trace into apex20ke_asynch_lcell, and found the following
statements

buf (icascin, cascin);
data=(long string...); && icascin;
and (combout, data, 'b1) ;

in this apex20ke_asynch_lcell that act as inverter, the cascin is not
connected, so it must be an 1'bz, so I can not got an high active
reset signal on combout.

why?
Muzaffer Kal <muzaffer@dspia.com> wrote in message news:<ev0f8u01r78kjn7vqi5j1tfklb864gehno@4ax.com>...
> On 7 Mar 2002 03:50:04 -0800, shengyu_shen@hotmail.com (ssy) wrote:
> 
> >Hi
> >
> >my question may seem a bit stupid, but if you know about my condition,
> >you can understand it.
> >
> > these days. I met with serious problem about simulation/synthesis
> >mismatch , so I search everywhere to find the cause, to make the
> >problem even worse, the post syn simulation just can not run
> >correctly.
> 
> it's usually a bit of detective work unless the problem is obvious. It
> could be a problem with your RTL where the synthesized hardware is not
> what you think it will be. Or it could be a synthesizer bug which is
> less likely. 
> The solution is to try to isolate the bug. First do a simulation
> without any timing annotated. If that works but not the annotated
> netlist, you know you have  a timing problem. If you have a
> multi-module design, you should individually synthesize the modules
> and do a mixed RTL, gate level simulation and see which module breaks.
> Of course by looking at how the gate level breaks, you should have
> some idea which module could be the problem. If all the modules singly
> synthesized, work correctly it is more likely a cross-boundry
> optimization problem with synthesis. If you find one of the modules
> breaking when synthesized, read the RTL carefully to see if you're
> following all the rules of the specific tool for synthesizable subset
> of the HDL you're using. 
> These are some of the ways you can try to pinpoint the problem. Good
> luck.
> 
> Muzaffer Kal
> 
> http://www.dspia.com
> ASIC/FPGA design/verification consulting specializing in DSP algorithm implementations

Article: 40506
Subject: Re: Converting old Mach 5 project from DSL to VHDL
From: "David Brown" <dav-nospam-id@westco-nospam-ntrol.com>
Date: Fri, 8 Mar 2002 10:46:59 +0100
Links: << >>  << T >>  << A >>

Jim Granville wrote in message <3C880A14.2892@designtools.co.nz>...
>David Brown wrote:
>>
>> Hi,
>>
>> We have an old project that used a Mach 5 PLD, programmed in DSL using
>> MachXL software, around 3 years ago.  We are now looking at updating the
>> project, and using a Mach 4 PLD instead (when we started, there were no
Mach
>> 4 chips that were big enough).  But the current design software does not
>> support the old DSL language.  Are there any tools or shortcuts that we
>> could use to convert the old DSL project to newer VHDL code?  We don't
>> actually need to make any significant changes to the functionality of the
>> design, just to fit it into a newer chip, so we'd really like to avoid
>> having to re-write everything in VHDL (or Verilog).
>
> The normal 'open' design flow creates a Berkeley PLA file, and then
>runs
>a fitter on that. Sometimes these have .TT2 extensions.
> BLIF format is another variant, that can be selected in ABEL flows.
>
> This allows older source files to target newer devices, but lattice
>may be more 'closed' than that.
> you are tight, rewrite just to use a new device does not sound a good
>idea.
>


I am not sure what the exact formats are, but my old MachXL software
compiles .src DSL source files into an ".AFB" file.  The AFB files from each
module are then linked together into a .FB file, from which a jdec file is
produced (I honestly can't remember where the logic reduction, optimisation
and routing is done in this process).  In other words,  I really don't think
there is any possibility of fitting together the old and new software (i.e.,
using the old software to compile the DSL source, and the new software to
fit it into a newer chip).

I am pretty sure now that I will have to do the convertion to VHDL manually.
I've been meaning to learn VHDL for a while now anyway - it will make it
much easier for us to use programmable logic in the future, whether it be
from Lattice or anyone else.




Article: 40507
Subject: suggestion to comp.arch.fpga
From: nahum_barnea@yahoo.com (Nahum Barnea)
Date: 8 Mar 2002 02:33:37 -0800
Links: << >>  << T >>  << A >>
Hi .

There are alot of interesting messages in comp.arch.fpga ,
BUT it takes alot of time to sort the ones that interest 
you because there are alot of messages per 1 day.

I think that it would be best if someone (I do'nt know who can do it)
will open :
comp.arch.fpga.xilinx and 
comp.arch.fpga.altera and
comp.arch.fpga.others

What do you think ?

ThankX,
Nahum.

Article: 40508
Subject: hash arithmetic
From: sboe <sodif@ire.zlkxv>
Date: Fri, 8 Mar 2002 02:37:44 -0800
Links: << >>  << T >>  << A >>
who can introduce some knowledge(link/book)about hash arithmetic?
it is better if you can post some verilog source code(link

Article: 40509
Subject: Re: Quartus II 2.0 fast fit option
From: Nial Stewart <nials@britain.agilent.com>
Date: Fri, 08 Mar 2002 11:34:39 +0000
Links: << >>  << T >>  << A >>
Kevin Brace wrote:
> 
> Nial Stewart wrote:
> >
> >
> > I wonder how many people use Nativelink? I'm sure it's not a high priority
> > for testing, although this isn't good, they should take it out rather than
> > have it and it doesn't work.
> >
> 
>         According to this article, Tim Southgate has been saying that
> Altera is going to deemphasize internally developed frontend tools, and
> will concentrate their software efforts on backend tools.
> 
> http://www.ebnews.com/story/OEG20020121S0029
> 
> That makes sense, considering that LS-Altera seems to synthesize better
> circuit than its in-house QII Verilog synthesis tool in my case.
> Then, isn't NativeLink going to be more important than ever?

No.

I prefer to run the tools independantly. I see synthesis and P+R as 
seperate processes and would rather keep them seperate. I think
this helps keep clear what constraints etc are being applied
where and when.

>         I don't care how many people actually use NativeLink, but as
> long as FLEX10KE/ACEX1K is on the support device list, and NativeLink is
> officially supported (assuming that the correct version of LS-Altera is
> used. Yes, I used the latest version LS-Altera 2002a_014, and still
> didn't work properly until I figured out the workaround from an advise
> from someone else who replied to my question.) Altera should test it to
> make sure the thing works.
> Otherwise, don't officially support such a feature/device.

That was my point, if I was them I'd just remove it. It's not a core
feature and you just piss people off if it doesn't work.



> The X 90%/A 10% in the highend FPGA market is a number I heard
> anecdotally, and I may have read that somewhere, too, but couldn't not
> find an article that gave the 90%/10% number.
> If I find it later, I will post that.

Fair enough.


>         Regardless, the general consensus of the industry watchers seems
> to indicate that Altera is definitely losing ground to Xilinx especially
> in the highend.

The 'big two' have been leapfroggig each other for the last X years.

> Also, have you also noticed the number of Altera related questions on
> this newsgroup?

What, you mean the way they seem to be increasing?

> They are far fewer than Xilinx related questions, and when you compare
> the ratio of Virtex/APEX related questions, it seems to me the 90%/10%
> number holds (or close to that to say the least).
> Although to be fair, Altera supposedly doesn't pay its employee to
> answer questions at news:comp.arch.fpga, so that might contribute to the
> lower number of Altera related questions here.

Aye. The fact that you know you're going to get answers to Xilinx 
questions here is a very good thing for Xilinx. I think it's crazy
that Altera don't do the same.


> I personally think they should change their policies, and pay their
> employees.

I'm sure most of them are paid.

> 
> > > I read some time ago on EE Times that much of the reason customers
        ^^^^^^^^^^^^^^^^^^
> > > choose Virtex instead of APEX20K several years ago is because the
                                       ^^^^^^^^^^^^^^^^^
> > > quality of Quartus wasn't as good as Xilinx's software offering at the
                                                                      ^^^^^^
> > > time.
      ^^^^^

If you were looking at tools from two vendors, one of which had a stable
offering and one of which had a new product _just_ out you'd probably go 
for the vendor with the stable offering.

Give the other vendor a year to iron out their teething problems and 
see what proportion of people chose each offering for a fairer
comparison.


>         In case of ISE WebPACK 4.1 I tried, yes, there were lots of
> Virtex-II related bugs, and I only experienced one serious bugs in the
> first release that had to do with guided routing.
> I personally don't really use (only accidentally discovered the problem)
> guided routing, so I don't really care.

Hmmm. So it doesn't matter how buggy software is as long as it doesn't
affect you. What if you need to use that feature in your next project?


> Since then, ISE WebPACK has had three Service Pack releases (now the
> latest is 4.1WP3.0), so I will assume that the bug is fixed, but I
> haven't tested whether or not guided routing bug is really fixed.
> No, I am not saying that Xilinx is perfect, but from my experience, it
> has far fewer problems related to software.


One comment I've heard is that all free software is worth what you 
pay for it.

The free web software from Altera and Xilinx is cut down versions 
of their full blown offering. 

I'm sure the teams supporting these aren't nearly as big as those
supporting the software that people are purchasing.


>         Although I have no intention of defending Xilinx, I don't use
> MicroBlaze, so I don't really care even if it is buggy.
> Yes, I think Xilinx should have been more careful in debugging their
> products.
> However, at the end of the day, what I care is the stuff I use (most of
> the time ISE WebPACK, and some occasional QII for to ensure my design is
> vendor independent), and if brand X does well, and brand A doesn't, then
> I just have to call brand A is inferior.
>         Honestly, I am surprised with some hysterical responses I got
> from some die-hard Altera fans.

Bloody hell Kevin, 'hysterical resonses'???

Have you got some sort of 'spetic' filter on your newsreader?

> Please, don't get mad,

I'm more bemused than anything else.

> and try out other vendors tools occasionally to
> see if it is better than what you are using right now.

I use Altera and Xilinx tools on a day to day basis.

I have jus been trying to point out that the software from both
companies has strengths and weaknesses but you seem very
quick to point out the faults in Altera's offering, while
blind to those in Xininx's.


> Note: I am paid by Xilinx to post this postings. I don't work at Xilinx

I presume this should have been 'not paid'.

> ones. If Altera's software was as good as Xilinx or better, I surely
> won't be criticizing Altera that much.

It takes all sorts :-).


Nial (sitting firmly on the fence).

Article: 40510
Subject: Re: FPGA or DSP in a power supply?
From: frankmotje@hotmail.com (F. Modderkolk)
Date: 8 Mar 2002 04:37:11 -0800
Links: << >>  << T >>  << A >>
So if I'll understand you right, you say it's possible to create the
frequencies 300.000MHz, 299.700MHz, 299.400MHZ  and split them in 6
different fases, with a 50 MHz FPGA. Could you suggest me a FPGA in
witch I can program that easy.
Thanks.



Ray Andraka <ray@andraka.com> wrote in message news:<3C878220.EAB872CA@andraka.com>...
> It's not the FPGA you don't follow, it is the direct digital synthesis that is eluding
> you.  You can clock modern FPGAs at 300 MHz with careful design, but in your case there is
> really no need to do so.  Clocking at a more comfortable 10-50 MHz will make the design
> much easier, will permit a smaller part, will reduce your power, and will eliminate any
> chance of needing a heatsink on the FPGA.
> 
> To the point, the reason a DDS gives you finer resolution than might be apparent is that
> it accumulates fractional cycles.  This is manifested at the output by essentially
> sampling the accumulated phase at the clock interval.  what that means is you can get very
> fine frequency resolution but with some jitter due to the time sampling.  Picture the DDS
> as a phase accumulator.  The accumulator bits represent a fraction of a revolution.  So if
> you have a 4 bit accumulator, 0000 represents phase angle of 0, 0101= 5/16 of a
> revolution, 1111=15/16 of a revolution.  Now if we have a fixed increment of 0101 or 5/16
> then after 16 clocks we have gone around the phase circle exactly 5 times in the sequence:
> 0,5,10,15,4,9,14,3,8,13,2,7,12,1,6,11,0.  by setting the increment value we can go 1/16 to
> 8/16 times the input frequency, in steps with 1/16 the input frequency resolution.  For a
> simple square wave, you can take the msb of the accumulator out.  In the example above
> with an increment of 5 we then get the sequence:
> 
> 0,0,1,1,0,1,1,0,1,1,0,0,1,0,0,1
> 
> Note that it gets better frequency resolution than would otherwise be apparent by
> modulating the sequence of bits.  If you look closely, what it is doing is putting the
> transitions at the clock interval closest to where it would be in an infinitely sampled
> situation.  Now if we wanted to increase the resolution, we can add a bit to the
> accumulator.  Sa instead of 5/16 * fclk we really needed 21/64* fclk.  If we have 32 bits
> then we might use 11/32, getting the sequence:
> 0,11,22,1,12,23,2,13,24,3,14,25,4,15,26,5,16,27,6,17,28,7,18,29,8,19,30,9,20,31,10,21,0
> which gives.
> 
> 0, 0, 1 ,0, 0,  1 ,0, 0,  1, 0,  0,  1, 0, 0,  1,0 , 1,  1 ,0, 1 , 1 ,0, 1,   1,0,  1, 1,
> 0, 1,  1, 0,  1,
> 
> As you can see you now get 11 rising edges in 32 clocks instead of 5 in 16 (10 in 32).  By
> adding a bit, we essentially increase the resolution by extending the time for the
> sequence to repeat.  In all these sequences, the edges are as evenly spaced as possible
> with the clock used, Hence the jitter of 1 cycle of your master clock we were speaking
> of.  Unless your jitter requirement is less than 3ns, you have no reason to be working at
> 300 MHz.  In fact, if you use more than one of the MSBs, you can use the fractional pahse
> angle with a DAC to get sub clock slicing.
> 
> 
> "F. Modderkolk" wrote:
> 
> > Maybe I don't quit understand the working of the fpga, so explain me
> > whem I'm wrong.
> > I want to give you give you an example why my resolution needs to be
> > so high.
> > When I'm switching the fets with 300 kHz and I can switch my output
> > with 300MHz, the following is  possible. Let's say the duty cycle of
> > my pulse is 40% ( it's always less than 50%). When I switch with 300
> > kHz, one period is 3,33333 us. the next frequncy I can create at my
> > output = 1/300k + 1/300M = 3,33666 us. That is a frequency of
> > 299,700kHz. That is a difference of 300Hz. Such a difference means at
> > the output of the power supply a change of current of 0.2A. This is
> > because the working frequency is very small. I hope I made clear why I
> > need the high frequency.
> >
> > Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>...
> > > See my post to your previous post.  Knowing now what you are doing, I am
> > > sure you can get away with a much slower clock.  Jitter is not likely to
> > > be much of a problem in this application.  If, for example, you use a 10
> > > MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002
> > > Hz with jitter no greater than 100ns (1 cycle of the master clock).  Your
> > > master clock determines the amount of jitter and the maximum output
> > > frequency (Fclk/2).  Resolution is determined just by the number of bits.
> > >

Article: 40511
Subject: Re: FPGA or DSP in a power supply?
From: "Paul" <nospam@nospamplease.com>
Date: Fri, 8 Mar 2002 13:24:30 -0000
Links: << >>  << T >>  << A >>

"F. Modderkolk" <frankmotje@hotmail.com> wrote in message
news:82eb64d2.0203080437.2353727@posting.google.com...
> So if I'll understand you right, you say it's possible to create the
> frequencies 300.000MHz, 299.700MHz, 299.400MHZ  and split them in 6
> different fases, with a 50 MHz FPGA. Could you suggest me a FPGA in
> witch I can program that easy.

From your questions, are you sure you have enough knowledge to go down this
route?
You won't be flooding this site with 'give me code for a DDS' or 'how do I
program this' will you?
At some point people will stop doing your work for you.

Wouldn't a pre-programmed solution be better for you?
Search for DDS at analog devices web site for instance. This will certainly
go into the details of DDS in a lot more detail to aid your understanding.

Pretty much any but the smallest FPGAs from any vendor will be able to
accommodate a simple DDS at 50MHz.

However you'll need the tools (so probably the free Altera or Xilinix tools
which restricts choice of FPGA to older or smaller ones).

Are you hoping to get a small cheap development board for this, or put an
FPGA on your own board? Packaging etc might become an issue or available
boards in your price range.

I'm not trying to sound too negative, but you've asked pretty much for a
piece of string but what length should you get.

Regards

Paul





Article: 40512
Subject: Re: FPGA or DSP in a power supply?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 08 Mar 2002 13:34:59 GMT
Links: << >>  << T >>  << A >>
I think you mean 300.000KHz, 299.7 KHz, 299.4 KHz don't you?  The DDS design I am referring to
could be put in nearly any FPGA (OI'd use one with a carry chain).  If you have a 50 MHz clock.
and want frequency resolution to .001 Hz, then  you need a log2(50e6/.001)= 36 bit
accumulator.   For a 300.000Khz output:
Fo= 50M* N/2^36

For Fo=300.000KHz N=412316860 which gives actual frequency of 299999.9997 Hz assuming your 50
MHz is that precise.
for Fo=299.700KHz, N=411904544 => 299700.0003 Hz
for Fo=299.400KHz, N=411492227 => 299400.0002 Hz

The nice thing is the output frequency is proportional to the increment value, which is not true
for other divider schemes.

If you want to split them into phases, you can work the DDS at 12x frequency and use a 6 bit
johnson (ring) counter to generate the 6 phases.  This design can go into a CPLD or a small FPGA
such as the XC2S15.  Coding it can be done with very basic knowledge of the HDL you choose.


"F. Modderkolk" wrote:

> So if I'll understand you right, you say it's possible to create the
> frequencies 300.000MHz, 299.700MHz, 299.400MHZ  and split them in 6
> different fases, with a 50 MHz FPGA. Could you suggest me a FPGA in
> witch I can program that easy.
> Thanks.
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3C878220.EAB872CA@andraka.com>...
> > It's not the FPGA you don't follow, it is the direct digital synthesis that is eluding
> > you.  You can clock modern FPGAs at 300 MHz with careful design, but in your case there is
> > really no need to do so.  Clocking at a more comfortable 10-50 MHz will make the design
> > much easier, will permit a smaller part, will reduce your power, and will eliminate any
> > chance of needing a heatsink on the FPGA.
> >
> > To the point, the reason a DDS gives you finer resolution than might be apparent is that
> > it accumulates fractional cycles.  This is manifested at the output by essentially
> > sampling the accumulated phase at the clock interval.  what that means is you can get very
> > fine frequency resolution but with some jitter due to the time sampling.  Picture the DDS
> > as a phase accumulator.  The accumulator bits represent a fraction of a revolution.  So if
> > you have a 4 bit accumulator, 0000 represents phase angle of 0, 0101= 5/16 of a
> > revolution, 1111=15/16 of a revolution.  Now if we have a fixed increment of 0101 or 5/16
> > then after 16 clocks we have gone around the phase circle exactly 5 times in the sequence:
> > 0,5,10,15,4,9,14,3,8,13,2,7,12,1,6,11,0.  by setting the increment value we can go 1/16 to
> > 8/16 times the input frequency, in steps with 1/16 the input frequency resolution.  For a
> > simple square wave, you can take the msb of the accumulator out.  In the example above
> > with an increment of 5 we then get the sequence:
> >
> > 0,0,1,1,0,1,1,0,1,1,0,0,1,0,0,1
> >
> > Note that it gets better frequency resolution than would otherwise be apparent by
> > modulating the sequence of bits.  If you look closely, what it is doing is putting the
> > transitions at the clock interval closest to where it would be in an infinitely sampled
> > situation.  Now if we wanted to increase the resolution, we can add a bit to the
> > accumulator.  Sa instead of 5/16 * fclk we really needed 21/64* fclk.  If we have 32 bits
> > then we might use 11/32, getting the sequence:
> > 0,11,22,1,12,23,2,13,24,3,14,25,4,15,26,5,16,27,6,17,28,7,18,29,8,19,30,9,20,31,10,21,0
> > which gives.
> >
> > 0, 0, 1 ,0, 0,  1 ,0, 0,  1, 0,  0,  1, 0, 0,  1,0 , 1,  1 ,0, 1 , 1 ,0, 1,   1,0,  1, 1,
> > 0, 1,  1, 0,  1,
> >
> > As you can see you now get 11 rising edges in 32 clocks instead of 5 in 16 (10 in 32).  By
> > adding a bit, we essentially increase the resolution by extending the time for the
> > sequence to repeat.  In all these sequences, the edges are as evenly spaced as possible
> > with the clock used, Hence the jitter of 1 cycle of your master clock we were speaking
> > of.  Unless your jitter requirement is less than 3ns, you have no reason to be working at
> > 300 MHz.  In fact, if you use more than one of the MSBs, you can use the fractional pahse
> > angle with a DAC to get sub clock slicing.
> >
> >
> > "F. Modderkolk" wrote:
> >
> > > Maybe I don't quit understand the working of the fpga, so explain me
> > > whem I'm wrong.
> > > I want to give you give you an example why my resolution needs to be
> > > so high.
> > > When I'm switching the fets with 300 kHz and I can switch my output
> > > with 300MHz, the following is  possible. Let's say the duty cycle of
> > > my pulse is 40% ( it's always less than 50%). When I switch with 300
> > > kHz, one period is 3,33333 us. the next frequncy I can create at my
> > > output = 1/300k + 1/300M = 3,33666 us. That is a frequency of
> > > 299,700kHz. That is a difference of 300Hz. Such a difference means at
> > > the output of the power supply a change of current of 0.2A. This is
> > > because the working frequency is very small. I hope I made clear why I
> > > need the high frequency.
> > >
> > > Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>...
> > > > See my post to your previous post.  Knowing now what you are doing, I am
> > > > sure you can get away with a much slower clock.  Jitter is not likely to
> > > > be much of a problem in this application.  If, for example, you use a 10
> > > > MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002
> > > > Hz with jitter no greater than 100ns (1 cycle of the master clock).  Your
> > > > master clock determines the amount of jitter and the maximum output
> > > > frequency (Fclk/2).  Resolution is determined just by the number of bits.
> > > >


Article: 40513
Subject: Re: suggestion to comp.arch.fpga
From: S Ramirez <sramirez@cfl.rr.com>
Date: Fri, 08 Mar 2002 15:04:38 GMT
Links: << >>  << T >>  << A >>
Nahum Barnea wrote:

> Hi .
> 
> There are alot of interesting messages in comp.arch.fpga ,
> BUT it takes alot of time to sort the ones that interest 
> you because there are alot of messages per 1 day.
> 
> I think that it would be best if someone (I do'nt know who can do it)
> will open :
> comp.arch.fpga.xilinx and 
> comp.arch.fpga.altera and
> comp.arch.fpga.others
> 
> What do you think ?
> 
> ThankX,
> Nahum.




Mahum,
    I agree with you that there are a lot of messages.  You should try 
monitoring alt.os.linux.mandrake!  That will take your eyes on a 
literary roller coaster ride.
    Anyway, I disagree that we should have separate newsgroups for 
different vendors.  One of the beauties here is that we can bounce ideas 
off each other in whatever vendor we choose.  Some topics help us 
determine which vendor has advantages and disadvantages for a particular 
application.  Yes, I know that Xilinx (1) and Altera (2) dominate the 
topics here but just take a look at the FPGA market pie.  It reflects 
the same thing.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA


Article: 40514
Subject: Re: FPGA or DSP in a power supply?
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 08 Mar 2002 15:22:21 GMT
Links: << >>  << T >>  << A >>
No, no, no !
Please read Ray's and my postings carefully. We explain that you can get extremely fine AVERAGE
resolution, just using a 50 MHz ( or lower ) clock.

Peter Alfke
====================================
"F. Modderkolk" wrote:

> So if I'll understand you right, you say it's possible to create the
> frequencies 300.000MHz, 299.700MHz, 299.400MHZ  and split them in 6
> different fases, with a 50 MHz FPGA. Could you suggest me a FPGA in
> witch I can program that easy.
> Thanks.
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3C878220.EAB872CA@andraka.com>...
> > It's not the FPGA you don't follow, it is the direct digital synthesis that is eluding
> > you.  You can clock modern FPGAs at 300 MHz with careful design, but in your case there is
> > really no need to do so.  Clocking at a more comfortable 10-50 MHz will make the design
> > much easier, will permit a smaller part, will reduce your power, and will eliminate any
> > chance of needing a heatsink on the FPGA.
> >
> > To the point, the reason a DDS gives you finer resolution than might be apparent is that
> > it accumulates fractional cycles.  This is manifested at the output by essentially
> > sampling the accumulated phase at the clock interval.  what that means is you can get very
> > fine frequency resolution but with some jitter due to the time sampling.  Picture the DDS
> > as a phase accumulator.  The accumulator bits represent a fraction of a revolution.  So if
> > you have a 4 bit accumulator, 0000 represents phase angle of 0, 0101= 5/16 of a
> > revolution, 1111=15/16 of a revolution.  Now if we have a fixed increment of 0101 or 5/16
> > then after 16 clocks we have gone around the phase circle exactly 5 times in the sequence:
> > 0,5,10,15,4,9,14,3,8,13,2,7,12,1,6,11,0.  by setting the increment value we can go 1/16 to
> > 8/16 times the input frequency, in steps with 1/16 the input frequency resolution.  For a
> > simple square wave, you can take the msb of the accumulator out.  In the example above
> > with an increment of 5 we then get the sequence:
> >
> > 0,0,1,1,0,1,1,0,1,1,0,0,1,0,0,1
> >
> > Note that it gets better frequency resolution than would otherwise be apparent by
> > modulating the sequence of bits.  If you look closely, what it is doing is putting the
> > transitions at the clock interval closest to where it would be in an infinitely sampled
> > situation.  Now if we wanted to increase the resolution, we can add a bit to the
> > accumulator.  Sa instead of 5/16 * fclk we really needed 21/64* fclk.  If we have 32 bits
> > then we might use 11/32, getting the sequence:
> > 0,11,22,1,12,23,2,13,24,3,14,25,4,15,26,5,16,27,6,17,28,7,18,29,8,19,30,9,20,31,10,21,0
> > which gives.
> >
> > 0, 0, 1 ,0, 0,  1 ,0, 0,  1, 0,  0,  1, 0, 0,  1,0 , 1,  1 ,0, 1 , 1 ,0, 1,   1,0,  1, 1,
> > 0, 1,  1, 0,  1,
> >
> > As you can see you now get 11 rising edges in 32 clocks instead of 5 in 16 (10 in 32).  By
> > adding a bit, we essentially increase the resolution by extending the time for the
> > sequence to repeat.  In all these sequences, the edges are as evenly spaced as possible
> > with the clock used, Hence the jitter of 1 cycle of your master clock we were speaking
> > of.  Unless your jitter requirement is less than 3ns, you have no reason to be working at
> > 300 MHz.  In fact, if you use more than one of the MSBs, you can use the fractional pahse
> > angle with a DAC to get sub clock slicing.
> >
> >
> > "F. Modderkolk" wrote:
> >
> > > Maybe I don't quit understand the working of the fpga, so explain me
> > > whem I'm wrong.
> > > I want to give you give you an example why my resolution needs to be
> > > so high.
> > > When I'm switching the fets with 300 kHz and I can switch my output
> > > with 300MHz, the following is  possible. Let's say the duty cycle of
> > > my pulse is 40% ( it's always less than 50%). When I switch with 300
> > > kHz, one period is 3,33333 us. the next frequncy I can create at my
> > > output = 1/300k + 1/300M = 3,33666 us. That is a frequency of
> > > 299,700kHz. That is a difference of 300Hz. Such a difference means at
> > > the output of the power supply a change of current of 0.2A. This is
> > > because the working frequency is very small. I hope I made clear why I
> > > need the high frequency.
> > >
> > > Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>...
> > > > See my post to your previous post.  Knowing now what you are doing, I am
> > > > sure you can get away with a much slower clock.  Jitter is not likely to
> > > > be much of a problem in this application.  If, for example, you use a 10
> > > > MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002
> > > > Hz with jitter no greater than 100ns (1 cycle of the master clock).  Your
> > > > master clock determines the amount of jitter and the maximum output
> > > > frequency (Fclk/2).  Resolution is determined just by the number of bits.
> > > >


Article: 40515
Subject: Re: FPGA or DSP in a power supply?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 08 Mar 2002 15:41:36 GMT
Links: << >>  << T >>  << A >>
Looks like a subject for a tutorial on my website....in my spare time :-)  (Actually I do have much
of the material already in printed form for my DSP seminar).

Peter Alfke wrote:

> No, no, no !
> Please read Ray's and my postings carefully. We explain that you can get extremely fine AVERAGE
> resolution, just using a 50 MHz ( or lower ) clock.
>
> Peter Alfke
> ====================================
> "F. Modderkolk" wrote:
>
> > So if I'll understand you right, you say it's possible to create the
> > frequencies 300.000MHz, 299.700MHz, 299.400MHZ  and split them in 6
> > different fases, with a 50 MHz FPGA. Could you suggest me a FPGA in
> > witch I can program that easy.
> > Thanks.
> >
> > Ray Andraka <ray@andraka.com> wrote in message news:<3C878220.EAB872CA@andraka.com>...
> > > It's not the FPGA you don't follow, it is the direct digital synthesis that is eluding
> > > you.  You can clock modern FPGAs at 300 MHz with careful design, but in your case there is
> > > really no need to do so.  Clocking at a more comfortable 10-50 MHz will make the design
> > > much easier, will permit a smaller part, will reduce your power, and will eliminate any
> > > chance of needing a heatsink on the FPGA.
> > >
> > > To the point, the reason a DDS gives you finer resolution than might be apparent is that
> > > it accumulates fractional cycles.  This is manifested at the output by essentially
> > > sampling the accumulated phase at the clock interval.  what that means is you can get very
> > > fine frequency resolution but with some jitter due to the time sampling.  Picture the DDS
> > > as a phase accumulator.  The accumulator bits represent a fraction of a revolution.  So if
> > > you have a 4 bit accumulator, 0000 represents phase angle of 0, 0101= 5/16 of a
> > > revolution, 1111=15/16 of a revolution.  Now if we have a fixed increment of 0101 or 5/16
> > > then after 16 clocks we have gone around the phase circle exactly 5 times in the sequence:
> > > 0,5,10,15,4,9,14,3,8,13,2,7,12,1,6,11,0.  by setting the increment value we can go 1/16 to
> > > 8/16 times the input frequency, in steps with 1/16 the input frequency resolution.  For a
> > > simple square wave, you can take the msb of the accumulator out.  In the example above
> > > with an increment of 5 we then get the sequence:
> > >
> > > 0,0,1,1,0,1,1,0,1,1,0,0,1,0,0,1
> > >
> > > Note that it gets better frequency resolution than would otherwise be apparent by
> > > modulating the sequence of bits.  If you look closely, what it is doing is putting the
> > > transitions at the clock interval closest to where it would be in an infinitely sampled
> > > situation.  Now if we wanted to increase the resolution, we can add a bit to the
> > > accumulator.  Sa instead of 5/16 * fclk we really needed 21/64* fclk.  If we have 32 bits
> > > then we might use 11/32, getting the sequence:
> > > 0,11,22,1,12,23,2,13,24,3,14,25,4,15,26,5,16,27,6,17,28,7,18,29,8,19,30,9,20,31,10,21,0
> > > which gives.
> > >
> > > 0, 0, 1 ,0, 0,  1 ,0, 0,  1, 0,  0,  1, 0, 0,  1,0 , 1,  1 ,0, 1 , 1 ,0, 1,   1,0,  1, 1,
> > > 0, 1,  1, 0,  1,
> > >
> > > As you can see you now get 11 rising edges in 32 clocks instead of 5 in 16 (10 in 32).  By
> > > adding a bit, we essentially increase the resolution by extending the time for the
> > > sequence to repeat.  In all these sequences, the edges are as evenly spaced as possible
> > > with the clock used, Hence the jitter of 1 cycle of your master clock we were speaking
> > > of.  Unless your jitter requirement is less than 3ns, you have no reason to be working at
> > > 300 MHz.  In fact, if you use more than one of the MSBs, you can use the fractional pahse
> > > angle with a DAC to get sub clock slicing.
> > >
> > >
> > > "F. Modderkolk" wrote:
> > >
> > > > Maybe I don't quit understand the working of the fpga, so explain me
> > > > whem I'm wrong.
> > > > I want to give you give you an example why my resolution needs to be
> > > > so high.
> > > > When I'm switching the fets with 300 kHz and I can switch my output
> > > > with 300MHz, the following is  possible. Let's say the duty cycle of
> > > > my pulse is 40% ( it's always less than 50%). When I switch with 300
> > > > kHz, one period is 3,33333 us. the next frequncy I can create at my
> > > > output = 1/300k + 1/300M = 3,33666 us. That is a frequency of
> > > > 299,700kHz. That is a difference of 300Hz. Such a difference means at
> > > > the output of the power supply a change of current of 0.2A. This is
> > > > because the working frequency is very small. I hope I made clear why I
> > > > need the high frequency.
> > > >
> > > > Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>...
> > > > > See my post to your previous post.  Knowing now what you are doing, I am
> > > > > sure you can get away with a much slower clock.  Jitter is not likely to
> > > > > be much of a problem in this application.  If, for example, you use a 10
> > > > > MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002
> > > > > Hz with jitter no greater than 100ns (1 cycle of the master clock).  Your
> > > > > master clock determines the amount of jitter and the maximum output
> > > > > frequency (Fclk/2).  Resolution is determined just by the number of bits.
> > > > >


Article: 40516
Subject: Re: GATE ARRAY PROJECT
From: John_H <johnhandwork@mail.com>
Date: Fri, 08 Mar 2002 17:27:00 GMT
Links: << >>  << T >>  << A >>
total inputs: 12 ?  8 data, 3 select, one strobe.

When you say you need a small Gate Array job, are you looking for true
ASICs or do you want someone to design an FPGA or CPLD for you?  Gate
Arrays ask for very high production volumes for break-even compared to
the programmable alternative.  Does the device have to be instant-on or
can it wait several milliseconds before it's awake?



dan doberstein wrote:

> We need a small Gate Array job done. It's a port expander, equivilent
> to 6 parralel ports ( output only, 74LS374 latch type) with a 3 bit
> write strobe decoder, similar to 74LS138 so that each can be written
> to via 8 bit bus
>
> total outputs: 48 data bits, six 8 bit registers
> total inputs: 4, 3 select , one strobe.
> Speed: Not critcal, 74HC speed is good enough.
>
> Can reach at;
>
> info@dkdinst.com
>
> 805-929-2285
> Dan D.


Article: 40517
Subject: Re: suggestion to comp.arch.fpga
From: vhdlcohen@aol.com (VhdlCohen)
Date: 08 Mar 2002 17:32:51 GMT
Links: << >>  << T >>  << A >>
>> I think that it would be best if someone (I do'nt know who can do it)
>> will open :
>> comp.arch.fpga.xilinx and 
>> comp.arch.fpga.altera and
>> comp.arch.fpga.others
>> 

You can also do a search on groups.google as shown below for comp.arch.fpga and
altera 

http://groups.google.com/groups?as_q=comp.arch.fpga%20altera&as_eq=%20&as_
scoring=d&hl=en

-------------------------------------------------------------------------
Ben Cohen     Publisher, Trainer, Consultant    (310) 721-4830  
http://www.vhdlcohen.com/                 vhdlcohen@aol.com  
Author of following textbooks: 
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8 
* Component Design by Example ",  2001 isbn  0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------

Article: 40518
Subject: Re: GATE ARRAY PROJECT
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 08 Mar 2002 09:49:36 -0800
Links: << >>  << T >>  << A >>
Looks to me like a "no-brainer"  CPLD application.
Peter Alfke
=============================
John_H wrote:

> total inputs: 12 ?  8 data, 3 select, one strobe.
>
> When you say you need a small Gate Array job, are you looking for true
> ASICs or do you want someone to design an FPGA or CPLD for you?  Gate
> Arrays ask for very high production volumes for break-even compared to
> the programmable alternative.  Does the device have to be instant-on or
> can it wait several milliseconds before it's awake?
>
> dan doberstein wrote:
>
> > We need a small Gate Array job done. It's a port expander, equivilent
> > to 6 parralel ports ( output only, 74LS374 latch type) with a 3 bit
> > write strobe decoder, similar to 74LS138 so that each can be written
> > to via 8 bit bus
> >
> > total outputs: 48 data bits, six 8 bit registers
> > total inputs: 4, 3 select , one strobe.
> > Speed: Not critcal, 74HC speed is good enough.
> >
> > Can reach at;
> >
> > info@dkdinst.com
> >
> > 805-929-2285
> > Dan D.


Article: 40519
Subject: Re: exceeding 2GB limits in xilinx
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: Fri, 08 Mar 2002 18:04:27 GMT
Links: << >>  << T >>  << A >>
"Tim" <tim@rockylogic.com.nooospam.com> writes:

> Petter Gustad wrote
> 
> > Actually the command line tools (ngdbuild, map, par etc.) appears to
> > be UNIX style programs, at least they use -options rather than
> > /options. The first time I used XACT was on a SPARC/SunOS plattform.
> 
> The first time I used XACT was on a 8MHz 8086, running MS-DOS 3.1.
> If this was developed on UNIX, the boys and girls at Xilinx sure
> knew a thing or two about writing portable code :-)

That must have been long before me then. It must have been on a
SparcStation II in the early 1990's.

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 40520
Subject: Re: FPGA or DSP in a power supply?
From: frankmotje@hotmail.com (F. Modderkolk)
Date: 8 Mar 2002 10:34:09 -0800
Links: << >>  << T >>  << A >>
Ok, I think I understand finally what you tried to tell me. I want to
thank you for that, because I'm only a simple student trying to
graduate. As a final solution, you suggest me to use an simple FPGA in
combinaton of an DDS.
Thanks again.

Article: 40521
Subject: Re: FPGA or DSP in a power supply?
From: Santiago de Pablo <sanpab@eis.uva.es>
Date: Fri, 08 Mar 2002 19:44:35 +0100
Links: << >>  << T >>  << A >>
Just one quick comment:

"F. Modderkolk" escribió:
> 
...
> 
> Yes, when I change the load at the output of the power supply, the
> expected current drops or rises. As a result my output voltage drops
> or rise. By chanching the switching frequency, I can deliver more
> power at the output. I want the output-voltage to be constant.

If you use Voltage PWM you get voltage, but not always the voltage you
want, so you need to measure and react with a quick regulator (not
always a high frequency).

Have you consider to apply a Voltage Source Sliding? Please, see

http://www.dte.eis.uva.es/Publicaciones/Congresos/EPE97A.PDF

Regards, Santiago (sanpab@eis.uva.es).

Article: 40522
Subject: Sandwich board at ESC
From: "Ryan Henderson" <hendersr@oit.edu>
Date: Fri, 8 Mar 2002 10:54:11 -0800
Links: << >>  << T >>  << A >>
What do you think the response would be if I wore a sandwich board at the
embedded systems conference that said

            HDL Designer

              Hire Me!


Just a thought
-Ryan





Article: 40523
Subject: Re: exceeding 2GB limits in xilinx
From: kayrock66@yahoo.com (Jay)
Date: 8 Mar 2002 11:21:41 -0800
Links: << >>  << T >>  << A >>
Provided you have multiple licenses, you can do a divide and conquer
multi-machine bottom-up synthesis using Synopsys and a few scripts,
but the P&R task just seems to be atomic to date and we're constantly
asking "How can we make this faster?"  So far the only workable
solution I've seen is manual partition into multiple FPGAs.  A
XC2V3000 P&R more than twice as fast as an XC2V6000.

Regards

Petter Gustad <newsmailcomp1@gustad.com> wrote in message news:<m3k7so7o7r.fsf@scimul.dolphinics.no>...
> Ray Andraka <ray@andraka.com> writes:
> 
> > It sounds like we are all barking up the wrong tree.  The solution is not to
> > go to more and more memory...There is something to be said about using low
> > cost PCs...instead, Xilinx needs to get the modular flow working so that one
> > can truely partition a design and run each partition through the entire
> [snip]
> Johann Glaser:
> > > Another idea would be to use a cluster for P&R. So, therefore P&R must be
> > > done for some independant and seperabel parts. I don't know how P&R
> [snip]
> 
> I agree with both of you. Even in a hierarchical/modular design
> methodology you could benefit greatly of a cluster of cheap PCs do do
> your job.
> 
> The EDA vendors seems to spend a lot of effort working on their GUIs.
> I would like to see some effort spent on parallel synthesis and PAR
> tools. The problem is that this is difficult to add later, you have to
> design it in from the start.
> 
> Petter

Article: 40524
(removed)




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