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 23500

Article: 23500
Subject: Re: Porting C to FPGA
From: "Alex Carreira" <aycarrei@acs.ucalgary.ca>
Date: Tue, 27 Jun 2000 15:54:25 -0600
Links: << >>  << T >>  << A >>
A product originating from the UK called
Handel-C would likely be of great interest
to you.  It allows C type syntax to be compiled
and produces a bitstream, xnf, or edif files.

It has some subtle nuances that should be
observed though.  I suspect you could
port your code very quickly with this tool.

The web link is:

http://www.embedded-solutions.ltd.uk/

Click on overview, under the technology heading.

Alex :)

Eliot Friedman <efriedma@eos.hitc.com> wrote in message
news:395917FD.3E5F8916@eos.hitc.com...
> I'm new to FPGA/HDL, and assigned to a "proof of concept" project
> porting legacy C code to FPGA, hoping for significant execution speed
> improvements.  What books/hardware/software tools can anyone recommend
> to help us get reportable results soonest/cheapest?
>
> Thanks for all your help,
>
> Eliot
>


Article: 23501
Subject: Re: Different ?
From: "R. T. Finch" <robfinch@cyg.net>
Date: Tue, 27 Jun 2000 18:10:15 -0400
Links: << >>  << T >>  << A >>
->Rob, you have it all wrong.

Sorry, I did not want to mislead anyone. I got it _plain_ wrong. You are
100% correct. I should have spent more time thinking about it and less time
thinking about pizza. I guess that's why I never got an engineering job...
:( 

I am well aware of deMorgan's theorem, and bubbles on input and output - that's why I mentioned them, but I should have been more careful about the number of possibilities.

I knew I should have paid more attention in that calculus of variable functions class.

Rob



"Peter Alfke" <palfke@earthlink.net> wrote in message news:3958380C.FB2507C3@earthlink.net...
> Rob, you have it all wrong.
> The question was: How many different "black-box" circuit can be implemented
> with a look-up table.
> And the answer is 2 exp(2exp.n) which means 16 different functions for a
> 2-input LUT. ( Nobody ever claimed 256 for this. You got that wrong, too)
> There are the basic functions like: and, or, xor, but then there are possible
> "bubbles" on the input(s) and/or the outputs, and then there is deMorgan... And
> there is the "ignore" function...
> It's much simpler to look at it as black box: You can test the behavior of a
> combinatorial black box with two inputs exhaustively by applying four test
> vectors (neither more nor less), and observing the four results.
> Obviously, there are 16 different response patterns. ( and there are 256 for 3
> inputs, 64K for 4 inputs, 16million for 5 inputs etc)
> I have used these questions to interview many hundreds of applicants for
> applications engineer jobs, over the past 20 years. Anybody who could not
> (finally) answer these questions satisfactorily never got an applications job
> at Fairchild, Zilog, AMD and now Xilinx. The smart candidates usually "got it"
> in a few minutes.
> 
> Greetings
> Peter Alfke
> 
> "R. T. Finch" wrote:
> 
> > The confusing aspect is the difference between the number of bits of storage
> > available and the number of possible states this storage may represe
nt. 40
> > bits of storage (16+16+8) may have one of 2^40 _possible_ values.
However,
> > it is important to note that it may have only _one_ of these values. IE
40
> > bits of stoarage can't represent every different possible state at the
same
> > time, only one at a time!
> >
> > I think you have the right idea. To calculate the potential number of
> > "states" shouldn't it be 2 * (n+1) not 2 ^ (n+1), because not all the
> > combinations can be active at the same time (there is only one output).
IE.
> > you're not combining state 0000 and 0001, but just counting them. For
> > example with a two input function (under the same constraints), there
are
> > eight basic functions (and, or, xor, andc) * 2 for possibly inverting
the
> > output, _not_ 2^(2+1) = 256 functions. Note that as a black box, with
two
> > inputs and a single output, we could model all possible states using a
truth
> > table with just four entries. It all depends what you want to consider
to be
> > a function. I could call this a single function (sigma) or I could claim
it
> > represents eight different functions. However I think we could define a
> > function, at a minimum, as something that produces a different output
than
> > any other 'function'.
> > Thus the 9-input Xilinx 4+4+3 FGH tree would result in 2 * (3 + 1) = 8
> > states for the 3-LUT times(I think this is a product operation here) 2 *
2 *
> > (4 + 1) = 20 for the two four LUTs which results in a total of 160
possible
> > states.
> > This is certainly far less than the 2^40 number (but I'm not comparing
> > apples to apples here).
> > We know for certain we cannot have more than 2^(9+1) (1024) states
because
> > there is only nine inputs and all possible outcomes can be represented
in
> > 2^10 values. (IE think of a black box with 9 inputs and a single output)
160
> > possibilities is pretty darn good considering the small amount of ram
used.
> > Note: I think we have to distinguish between the number of possible
> > functions implemented and the number of possible functions implemented
with
> > unique results. I think the number of possible states may represent the
> > number of possible functions with unique results (but don't quote me).
The
> > possible number of functions implemented may be quite large (although I
> > seriously doubt it's anywhere near 2^25), however the number of unique
> > results they produce (160) is quite limited.
> > What can be said is that for any possible combination of inputs, there
is
> > only one of 160 states selected. Compare that to the 1024 that would be
> > available with a 512 bit ram.
> >
> > The best approach may be to simply state that given x inputs, one of y
> > different output (states) can be produced. If you wnat to take functions
to
> > the extreme you could claim that an infinite number of functions can be
> > handled, because you can define the function to be as complex as you
like,
> > however all of these functions would reduce to "given x inputs, one of y
> > different output (states) can be produced".
> >
> > If I got the right answer, do I get a prize - pizza would be good  :) ?
> > Rob
> >
> > "Tom Burgess" <tom.burgess@home.com> wrote in message
> > news:39555A39.5345F956@home.com...
> > > I withdraw the conjecture as stated. If true, one could implement a
512x1
> > ROM in
> > > a single CLB which is obviously not the case, darn it.
> > >
> > > post in haste, regret at leisure,
> > > tom
> > >
> > > Tom Burgess wrote:
> > > >
> > > > Assertion: for an n-input LUT, with input swapping permitted,
> > > > there are 2^(n+1) possible unique functions possible.
> > > >
> > > > Nor-rigorous proof: For n inputs, there are n+1 possible unique
states
> > available,
> > > > e.g. for 4 inputs, the 5 unique states are {0000, 0001, 0011, 0111,
> > 1111}.
> > > > (with swapping allowed, 0001 is is equivalent to 1000, 0100, and
0010)
> > > > Since the n inputs to the LUT can only assume n+1 states, and the
> > contents of
> > > > each LUT entry are either 0 or 1, there are therefore 2^(n+1)
possible
> > > > unique LUT patterns (functions) available. So the result for n=4 is
32.
> > > >
> > > > Conjecture: the internal structure of the LUT is not important. With
> > input
> > > > swapping permitted, any function of n inputs is possible. So a
single
> > > > 512x1 LUT is equivalent to the 9-input Xilinx 4+4+3 FGH tree. Both
can
> > > > therefore implement 2^(9+1) = 1024 unique functions. The proof is
left
> > as
> > > > exercise for the student :)
> > > >
> > > > regards, tom
> > > >
> > > > Philip Freidin wrote:
> > > > >
> > > > > In article <8j2b2o$ar3$1@news.ust.hk>,
> > > > > WU Chi Hang FOX  <eefox@uxmail.ust.hk> wrote:
> > > > > >       First, thanks Rickman. However, I am really stucked at
that, I
> > am
> > > > > >not asking about HW questions, I really want to count how many
> > fuctions
> > > > > >that a cascaded LUTs can implement.
> > > > > >       For 1-bit LUT, I know there are 4 functions
> > > > > >
> > > > > >                               Output
> > > > > >       Input   Function 1      2       3       4
> > > > > >       0                0      0       1       1
> > > > > >       1                0      1       0       1
> > > > >
> > > > > Fine. You have enumerated all the functions of a 1 input LUT
> > > > >
> > > > > Inputs     Number of memory bits    Functions
> > > > > 1             2                       4
> > > > > 2             4                      16
> > > > > 3             8                     256
> > > > > 4            16                   65536
> > > > > N            2^N                  2^(2^N)
> > > > >
> > > > > >Function 1 is a zero function, Function 2 is follower, Function 3
is
> > NOT
> > > > > >Function 4 is a one function.
> > > > >
> > > > > So depending on your view of life, not all of these are
'interesting'.
> > > > >
> > > > > Function 1 and 4 ignore the input, function 2 is a wire, and
function
> > 3
> > > > > is an inverter. Maybe only the inverter case is interesting,
depends
> > what
> > > > > you had for breakfast.
> > > > >
> > > > > >       However, what I am concerning is that, even there are 4
> > functions,
> > > > > >utimatelly, it is only 0 and 1 pass into the LUT, so, it does not
> > matter.
> > > > > >So, what I think is, no-matter it is cascaded or not, the maximum
> > > > > >function is determined by the last LUT, so for this case, the no.
of
> > functions
> > > > > >is 2^4.
> > > > >
> > > > > For this case maybe, but remember that in the following LUT, it
too
> > has
> > > > > cases where the inputs are ignored, or the output is the inversion
or
> > > > > pass thru of one input, and other inputs are ignored. Which do you
> > > > > consider interesting?
> > > > >
> > > > > >       Then bringing back to the XC4000, if that is the case,
then
> > why
> > > > > >the total number of funtions is 2^40 instead of 2^8 ?
> > > > >
> > > > > Since the XC4000 CLB has 40 bits total in the two 4-LUTs, and the
one
> > > > > 3-LUT, there are exactly 2^40 possible configurations.
> > > > >
> > > > > I believe they are not all interesting, because MANY of these
ignore
> > some
> > > > > of the inputs, or are synonyms of each other, with just the input
> > signals
> > > > > swapped. The reason that the pin swaped equivalent functions are
not
> > > > > interesting, is because the place and route software does this pin
> > > > > swapping all the time, and permutes the LUT contents to account
for
> > the
> > > > > pin swapping. I wouldn't be surpised if the number of unique
patterns
> > is
> > > > > less than 2^25. The only way to find out the real number may be
> > through
> > > > > an exhaustive search.
> > > > >
> > > > > Philip Freidin
>
>


Article: 23502
Subject: digital phase lock loop
From: sriley <sueriley@my-deja.com>
Date: Wed, 28 Jun 2000 00:21:51 GMT
Links: << >>  << T >>  << A >>
Hello,

Recently (end of May) there was a thread in the group regarding
digital phase lock loops.  Below is a part of the thread.  It mentions
a xilinx app note.  Does anyone have the app#?  -Thanks

-Sue




On Mon, 29 May 2000 15:19:39 +0100, dmac
 <dmac@cutme.matter200.demon.co.uk> wrote:

 >
 >Hi Nestor,
 >
 >I don't have your original request for info and so have lost track of
 >your intended application but offer some info from what you have
given.
 >
 >I have not used type 2 but have used type 1 extensively with success.
It
 >is a superbly simple circuit and so wins hands down in my book - you
 >could have the basics working in no time.
 >
 >I notice that you are intending a comparison frequency of 25MHz in
the
 >phase comparator section. I would avoid this - notice that Peter's
Xil
 >Apps note uses a comparison freq of around 5kHz. The benefits of this
 >are jitter reduction, filter simplicity (audio range) and simpler
 >stability calcs. A lower comparison frequency is easily achieved by
 >dividing the reference and feedback paths by the same amount.

 Thanks, Dave, for your response.

 I read the xilinx AppNote too and noticed this low reference, but
Peter doesn't mention what frequency he intends to generate with that
 reference.  I do agree that the design will be simpler since certain
sections could operate slower.

 Do you know perhaps how the jitter depends on the reference tone?  I
would like to perforom some calculations to determine the
 maximum reference frequency that can also provide a small enough
jitter.  So far I know that the jitter is related to the loop variance
 which can be derived from the loop bandwidth.

 Any comments are welcome.

 Nestor
 nestor@ece.concordia.ca


 >
 >Peter also mentions ...
 >...
 >Watch out also for the type of VCXO used. At the frequency you are
 >talking, the mfr may use a lower rate item with a freq tripler stage.
 >Ours did - I think 'cos we wanted a big spread (+/-250ppm) - this
will
 >have greater jitter. 3rd overtone VCXO (the alternative) has, I
think,
 >lower pull range. As you are looking for +/-300ppm, watch out. If you
 >can reduce the spread, do, as lower spread oscs will be better
behaved
 >and easier (cheaper) to procure.

 I will see if I can use a narrower range VCXO (+/-150ppm tuning
 range).


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 23503
Subject: Re: JTAG emulation of TI DSPs
From: "Mark" <feydo@lcworkshop.com>
Date: Tue, 27 Jun 2000 18:12:07 -0700
Links: << >>  << T >>  << A >>
I have done a board similar to what you want to do.  The are 4 devices in my
chain in the following order  1) MPC823 (microcontroller), 2) XCV200, 3)
XCS30XL, and 4) TMS320C5402.  Both the microcontroller and DSP use the JTAG
port for emulation.  I put 0 ohm resistors on the board to allow me to
break the chain between devices if necessary for emulation / debugging.
When the 0 ohm jumpers are installed (standard configuration) production
will use the JTAG port to test the board.
   So far we have had no problems emulating either the microcontroller or
the DSP (XDS-510) with the jumpers in place.  I believe (it's be some months
since we made the config / ini files so I don't remember the details) there
was a setup step with the XDS-510 (or Code Composer SW) that told it what
position the DSP was at in the chain.  This caused the XDS-510 (and/or SW)
to put any earilier devices in the chain in pass-thru mode so the emulator
would work properly.

Hope this helps,
mark


Rickman <spamgoeshere4@yahoo.com> wrote in message
news:39583F61.D9F938DA@yahoo.com...
> I am looking at what it will take to use JTAG boundry scan on my next
> DSP board. I expect the board to have several FPGAs, one TI DSP and
> possibly a 16 bit microController, all with JTAG. I would like to string
> all of these devices in line to allow software to use the boundry scan
> features to test the interconnections on the board.
>
> But I have read from several people who have had problems with this
> approach. The biggest one seem to be that adding other devices to the
> JTAG path interferes with the operation of the XDS-510 emulator. Does
> anyone have any experience with this? Have you done this and did it
> work? Were there any special design features I need to know about, like
> does the DSP need to be first in the chain (or the last)?
>
> I don't expect to be using the FPGA JTAG ports in any other way. But I
> may want to use the JTAG to program Flash on the microController. I have
> not selected the micro just yet, but is this expected to be a problem?
>
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
>
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com


Article: 23504
Subject: Re: Powerup problem to 9500XL part @ -40 deg
From: rk <stellare@nospamplease.erols.com>
Date: Tue, 27 Jun 2000 22:09:41 -0400
Links: << >>  << T >>  << A >>
Elftmann wrote:

> Eirik--
>
> Try running a free running clock into TCK and insure that TMS is tied high,
> this will insure that the TAP controller state machine returns to
> the IDLE state.  Assuming it is in an unknown state.  If this corrects the
> problem then most likely the Xilinx JTAG tap controller is not
> getting sufficient power on reset at low temperature and is getting left in
> an unknown state, which will most likely leave all I/Os tri-stated.

I assume that the optional TRST* is not on this chip.  I am a big fan of the
optional TRST* pin.  Especially for critical systems (I note the original
poster was from Lockheed-Martin).

Also, when running the free running clock into the TCLK pin, make sure that it
is isolated from a regular pin.  If a regular pin drives out and low from the
instruction register being loaded with something unfortunate, it can clamp the
clock and then you get no TCLK and you have a bad day.

While according to the JTAG specification one is guaranteed to get back into
the TEST-LOGIC-RESET state in no more than 5 ticks of the TCLK, in practice,
with some chip designs, it may not do the job as the effects of a bad
instruction can take down a system (i.e., high currents).

Also a good idea to make sure that at -40C the power supply rise is relatively
quick and monotonic so that the power-on-reset circuit doesn't get confused.

----------------------------------------------------------------------
rk                               It is unlikely that all these
stellar engineering, ltd.        conditions come together, but we are
stellare@erols.com.NOSPAM        designers, not gamblers.
Hi-Rel Digital Systems Design    -- Peter Alfke



> "Eirik Esp" <eirik.n.esp@lmco.com> wrote in message
> news:394F8CF0.590E9D@lmco.com...
> > Technically a CPLD problem, but I thought to post it here anyway.  I am
> > having a problem with a XC9572XL @ -40 degrees.  It seems that when I
> > cycle power, the JTAG controller becomes confused and takes over the
> > chip.  The only way I can reset the JTAG controller is to power down and
> > up at room temp.  Once the JTAG controller is confused, if I warm the
> > part to room, it still misbehaves (TAP controller is in control).  I do
> > have a switching power supply on the board, so the +5v starts coming up
> > about 6 ms before the 3.3v, but if I apply a cap between the 3.3 and +5
> > so the 3.3 starts coming up with the +5v, it still doesn't fix it.  I
> > tried shorting the TCK directly to gnd and through a 1.1K pulldown, and
> > I tied the TMS to +5 through 4.7K and to 3.3 through a wire.  I am
> > really starting the suspect a ground bounce problem, or the TAP
> > controller in the chip itself.  Anyone else have similar experiences the
> > the 9500XL family at cold?  If so, how did you address it?  Also, anyone
> > know how Xilinx tests the industrial rated parts at cold?  Any chance
> > the JTAG controller is not tested?  If I access the JTAG port in the
> > right way at cold, the parts seems to come back to life, so maybe if the
> > testing uses the JTAG port, then it wouldn't demonstrate the fault we
> > are experiencing?

Article: 23505
Subject: MAPLD 1999 Conference Proceedings
From: "Richard B. Katz" <rich.katz@nospamplease.gsfc.nasa.gov>
Date: Tue, 27 Jun 2000 22:39:32 -0400
Links: << >>  << T >>  << A >>
The Conference Proceedings from the Military and Aerospace Applications
of Programmable Devices and Technologies Conference (MAPLD 1999),
September 28-30, 1999, are now available.

http://rk.gsfc.nasa.gov/richcontent/MAPLDCon99/Technical_Program.html

The Conference Proceedings was designed for CD-ROM distribution and some
users may experience long download times for some of the material.  All
abstracts, presentations, and papers are available from the link above.

Richard B. Katz
National Aeronautics and Space Administration

Article: 23506
Subject: I cant stand it any more.
From: fliptron@netcom.com (Philip Freidin)
Date: 28 Jun 2000 03:34:02 GMT
Links: << >>  << T >>  << A >>

For a 4 input LUT, there are 4 inputs, 16 bits in the LUT, and 65536
possible patterns that the 16 bits can represent.

Because the input signals can be swapped by the routing software, we 
should consider how many permutations there are for 4 inputs.
The answer is 4 factorial.  24

Start with a pattern in the 16 bits of the LUT. Calculate the new pattern 
for each of the remaining 23 input permutations. If the new pattern is 
not the current pattern, then it is a pattern that is not unique, just a 
pattern that can result from permuting the inputs and getting the same 
output from the LUT.

Repeat this for all 65536 patterns, except for those already eliminated 
as permutations of previous patterns.

The answer is 3984 unique paterns ( or interesting functions ).

Note that this includes functions where an input has no effect.
For example, an inverter only uses 1 of the 4 inputs. If we call the 4
inputs D,C,B,A, and the inverter input is on input A, and th rest are
"don't care" the LUTs are actually loaded with a pattern that makes the 
unused inputs don't care, rather than requiring them to be tied to ground 
(which would add significantly to the routing congestion).

Lut Input
arrangement      Lut Contents (MSB to LSB)

D C B A          0101 0101 0101 0101

Of the 23 input permutations, only the following are interesting:
(x can be any of D, C, or B)

x x A x          0011 0011 0011 0011

x A x x          0000 1111 0000 1111

A x x x          0000 0000 1111 1111

so only 3 other patterns would be eliminated from the pool by the 23 
permutations.

Would you like me to post an article that lists them?

Philip Freidin


In article <3958FD0F.AEEEF144@hia.nrc.ca>,
Tom Burgess  <tom.burgess@hia.nrc.ca> wrote:
>I should point out that I was not discussing the number of functions available
>from an n-input LUT (2^(2^n)), but the number of "unique" functions, i.e.
>those which cannot be generated from another function by arbitrarily permuting
>(swapping) the input pins - which I believe to be 2^(n+1). The difference is that
>while n inputs can assume 2^n binary states, only n+1 of those states are unique
>in this sense.
>
>Apologies for any confusion this may have caused,
>Tom Burgess
>
Article: 23507
Subject: Re: Defining a reset concept for VirtexE
From: "Austin Franklin" <austin@darkr99oom.com>
Date: 28 Jun 2000 04:09:38 GMT
Links: << >>  << T >>  << A >>
> > > If you don't have any inputs that will cause a
> > > state change following reset (including any logic that will change
state
> > > without inputs such as a free running counter) then you don't have a
> > > problem with the reset timing. I think I covered that in my other
> > > description for case 3.
> > 
> > well, why not just hold off the counter for N (N as described/defined
> > above)?
> 
> That would require that you have a secondary reset input to your counter
> which I discussed in case 2 of my post to Derek Wallace, IIRC. 

It does not require a secondary reset (for counters).  Use the clock enable
to waiting during reset.  For refresh, where in the count the counter
starts, is not relevant anyway.

Instead of contesting you point by point, let it suffice to say I believe
'people' over complicating the reset issue.  Perhaps, for some
applications, it can be complicated, but I believe they are due more to
poor engineering, or bad circumstances.

Article: 23508
Subject: Re: I cant stand it any more.
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 28 Jun 2000 16:49:24 +1200
Links: << >>  << T >>  << A >>
Philip Freidin wrote:
> 
> For a 4 input LUT, there are 4 inputs, 16 bits in the LUT, and 65536
> possible patterns that the 16 bits can represent.
> 
> Because the input signals can be swapped by the routing software, we
<snip>

But can they ?

If you have to design a routing scheme that is a true crosspoint, 
( so simplifies the LUT ) you have a LOT of bus loading, and a large
die overhead, plus more bits to control the cross points...

It might make more sense to allow the LUT to do '4 line allocate',
to simplify, and speed, the routing resource.

- jg
Article: 23509
Subject: Re: JTAG emulation of TI DSPs
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 Jun 2000 02:33:07 -0400
Links: << >>  << T >>  << A >>
Thanks, the XDS510 was my main concern. Did you pick this order
deliberately? Are there any issues that made this order preferred?

BTW, I looked to see what a MPC823 was and the Motorola web site
indicated it is a PowerPC chip. When I looked at the microcontroller
section the only parts they listed are the MPC509 and MPC555 both of
which seem a bit overgrown to be microcontrollers. Is the MPC823 also an
external memory part? 



Mark wrote:
> 
> I have done a board similar to what you want to do.  The are 4 devices in my
> chain in the following order  1) MPC823 (microcontroller), 2) XCV200, 3)
> XCS30XL, and 4) TMS320C5402.  Both the microcontroller and DSP use the JTAG
> port for emulation.  I put 0 ohm resistors on the board to allow me to
> break the chain between devices if necessary for emulation / debugging.
> When the 0 ohm jumpers are installed (standard configuration) production
> will use the JTAG port to test the board.
>    So far we have had no problems emulating either the microcontroller or
> the DSP (XDS-510) with the jumpers in place.  I believe (it's be some months
> since we made the config / ini files so I don't remember the details) there
> was a setup step with the XDS-510 (or Code Composer SW) that told it what
> position the DSP was at in the chain.  This caused the XDS-510 (and/or SW)
> to put any earilier devices in the chain in pass-thru mode so the emulator
> would work properly.
> 
> Hope this helps,
> mark
> 
> Rickman <spamgoeshere4@yahoo.com> wrote in message
> news:39583F61.D9F938DA@yahoo.com...
> > I am looking at what it will take to use JTAG boundry scan on my next
> > DSP board. I expect the board to have several FPGAs, one TI DSP and
> > possibly a 16 bit microController, all with JTAG. I would like to string
> > all of these devices in line to allow software to use the boundry scan
> > features to test the interconnections on the board.
> >
> > But I have read from several people who have had problems with this
> > approach. The biggest one seem to be that adding other devices to the
> > JTAG path interferes with the operation of the XDS-510 emulator. Does
> > anyone have any experience with this? Have you done this and did it
> > work? Were there any special design features I need to know about, like
> > does the DSP need to be first in the chain (or the last)?
> >
> > I don't expect to be using the FPGA JTAG ports in any other way. But I
> > may want to use the JTAG to program Flash on the microController. I have
> > not selected the micro just yet, but is this expected to be a problem?
> >
> >
> > --
> >
> > Rick Collins
> >
> > rick.collins@XYarius.com
> >
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> >
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design
> >
> > Arius
> > 4 King Ave
> > Frederick, MD 21701-3110
> > 301-682-7772 Voice
> > 301-682-7666 FAX
> >
> > Internet URL http://www.arius.com

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



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

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

Internet URL http://www.arius.com
Article: 23510
Subject: Re: JTAG emulation of TI DSPs
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 28 Jun 2000 02:56:18 -0400
Links: << >>  << T >>  << A >>
Thanks for the note. I have both of these documents fortunately. I tried
to find them on the TI site and it is almost impossible to find using
the search even if you know the document file name. I am sure there is a
place to look these up, but it can be hard to find that place. 

Anyway they are good documents and I will reread them carefully. 



Etienne Racine wrote:
> 
> Hi Rick,
> 
> Rickman wrote:
> 
> > I am looking at what it will take to use JTAG boundry scan on my next
> > DSP board. I expect the board to have several FPGAs, one TI DSP and
> > possibly a 16 bit microController, all with JTAG. I would like to string
> > all of these devices in line to allow software to use the boundry scan
> > features to test the interconnections on the board.
> 
> Assuming all components are IEEE 1149.1 compatible, it *should* be OK.
> 
> > But I have read from several people who have had problems with this
> > approach. The biggest one seem to be that adding other devices to the
> > JTAG path interferes with the operation of the XDS-510 emulator. Does
> > anyone have any experience with this? Have you done this and did it
> > work? Were there any special design features I need to know about, like
> > does the DSP need to be first in the chain (or the last)?
> 
> The idea is that you cannot directly use the emulator on your JTAG chain
> because the resulting bitstream is not understood well by the emulation
> software. What must first be done is a small text file to indicate the
> emulation software the length of the JTAG instruction register of every
> device placed before and after the DSP(s).
> 
> Thus, each non-DSP component will be placed in BYPASS (by shifting an all-1
> pattern for the appropriate number of bits) and will only add a data bit (0)
> to the chain. Based on this info, the emulation software will discard
> irrelevant data and should work OK.
> 
> As for the position in the chain, I remember some people in c.a.fpga stating
> that some positions (i.e. DSP being first) worked better. Was it pure
> coincidence, a design issue or just a flaky JTAG compatibility, I couldn't
> say.
> 
> Two TI documents are quite useful when discussing issues about emulation &
> JTAG: "spdu079a.pdf" and "spra439.pdf"; they're worth a look (if you haven't
> done it already).
> 
> Regards,
> 
> tienne.
> --
>       ______ ______
> *****/ ____// _  \_\*************************************************
> *   / /_/_ / /_/ / /       Etienne Racine, Hardware Designer        *
> *  / ____// __  /_/           Visual Systems Engineering            *
> * / /_/_ / / /\ \ \              CAE Electronics Ltd.               *
> */_____//_/_/**\_\_\*************************************************

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



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

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

Internet URL http://www.arius.com
Article: 23511
Subject: Hanging PCI interrupt
From: Dominique SZYMIK <szymik@nospam.univ-lille1.fr>
Date: Wed, 28 Jun 2000 09:39:01 +0200
Links: << >>  << T >>  << A >>
Hello,

I am trying to interface a PCI9050 card to 
software. I am in win98 and I do it with a
VxD driver.

A problem shows when I try to use interrupts.
My handler in VxD is called, but if I unmask
the irq at the end with VPICD_Phys_EOI() the 
system freezes. I of course deassert the intA
line in my card as soon as I can.

Another something suspicious occur, I cannot
find my interrupt in CMCONFIG at configuration 
time but later it appears and I can register it
successfully.

What's unclear to me is what happens in the 
chipset between the four PCI irq lines and 
the PIC.
Maybe its the realm of the plug and play bios.
I would like to know if there are more registers
to look at, to investigate futher the problem.

Any hints, threads on the problem welcome.

d.
Article: 23512
Subject: Re: First time user Spartan problem (Panic over)
From: Charles Brain <chbrain@dircon.co.uk>
Date: Wed, 28 Jun 2000 09:00:37 +0100
Links: << >>  << T >>  << A >>
Charles Brain wrote:
> 
> Hi,
> 
> Can someone tell me what I am doing wrong?
> 

Well the problem is now fixed. 
Adding a boundary scan object to the schematic did the job. 

- Charles
Article: 23513
Subject: Virtex power estimation
From: SteVe <Ste@xxx.it>
Date: Wed, 28 Jun 2000 10:17:25 +0200
Links: << >>  << T >>  << A >>
Hello.

I need a rough estimation of the power consumption of my design (the
target device is a Xilinx XCV400). I've found a web page
(http://www.xilinx.com/cgi-bin/powerweb.pl) with the Virtex Power
Estimator developed by Xilinx. Is there somebody who used it? Is it a
good choice? Or do you suggest another way to perform this estimation?

Thanks,
SteVe


Article: 23514
Subject: PLXMon sources
From: Dominique SZYMIK <szymik@nospam.univ-lille1.fr>
Date: Wed, 28 Jun 2000 10:31:04 +0200
Links: << >>  << T >>  << A >>
Hello, 

Once PLXTech offered to download the
sources of their PCI debuggers,
PLXMon and PLXMon95, and phyacc.vxd
driver.

I would like to see if I can adapt the
VxD to win98, it only works for win95.
 
I would be happy if anybody could pass
me these sources. PLXTech doesn't support
them any longer.

d.
Article: 23515
Subject: Re: How to speed it up? :-)
From: Phil Endecott <phil_endecott@spamcop.net>
Date: Wed, 28 Jun 2000 13:02:24 +0000
Links: << >>  << T >>  << A >>
Dear motoring experts,

I think there is something wrong with my car.  When I drive round the
corner to my sister's house I find that I can complete the journey in as
little as five minutes, yet my journey to work in the next town can take
half an hour!  So what is the reason?

Shoran wrote:
> There is a problem in my design under Maxplus2 9.6 . I find that
> each individual module(symbol) can run at high speed above
> 100MHz, but it will be slow as 20MHz when I connect the symbols
> as a whole design. So what is the reason?
Article: 23516
Subject: Re: Virtex Demo Board
From: Mark Bowlby <bowlby@xilinx.com>
Date: Wed, 28 Jun 2000 08:05:07 -0700
Links: << >>  << T >>  << A >>
You can find a listing of Virtex Demo boards from Xilinx and third parties
at:

http://www.xilinx.com/products/protoboards/protoboards.htm


John Fielden wrote:

> I'm looking for a Virtex demonstration board.  Something that has at least
> one of the larger parts (1000 or 1000E, and above).  I would prefer an E
> part.
>
> Does anyone know who makes such a thing?
>
> Thanks,
>
> John Fielden

Article: 23517
Subject: How to do ...?
From: =?iso-8859-1?Q?=C1ngel=20Guti=E9rrez?= <agutierrez@matrix.es>
Date: Wed, 28 Jun 2000 17:13:47 +0200
Links: << >>  << T >>  << A >>
How to generate a signal  with a cpld, an crystal and a resistor and
other ?

Angel Guti‚rrez

ADVANCED PROSER SL
e-mail: agutierrez@matrix.es
Tel: +34 93 588 2137
Fax: + 34 93 588 6172


Article: 23518
Subject: Re: I cant stand it any more.
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 28 Jun 2000 16:28:05 +0100
Links: << >>  << T >>  << A >>


Jim Granville wrote:

> Philip Freidin wrote:
> >
> > For a 4 input LUT, there are 4 inputs, 16 bits in the LUT, and 65536
> > possible patterns that the 16 bits can represent.
> >
> > Because the input signals can be swapped by the routing software, we
> <snip>
>
> But can they ?
>
> If you have to design a routing scheme that is a true crosspoint,
> ( so simplifies the LUT ) you have a LOT of bus loading, and a large
> die overhead, plus more bits to control the cross points...
>
> It might make more sense to allow the LUT to do '4 line allocate',
> to simplify, and speed, the routing resource.
>
> - jg

Not swapping the inputs by some sort of Xbar but allowing the layout tools
to choose the input to LUT ``pin'' allocation for most efficient routing
then adjusting the LUT configuration accordingly.

BTW Its not only input permutations that can reduce the number of distinct
LUT functions but also
pushing & pulling inversions. If we say that 2 LUT patterns are equivalent
if you can get from one to the other by permutations & inversions on the
inputs then an N input LUT has

(2**(2**N))/(N! * (2**N))

distinct [= equivalence classes of] patterns (?).

Article: 23519
Subject: Re: digital phase lock loop
From: dmac <dmac@cutme.matter200.demon.co.uk>
Date: Wed, 28 Jun 2000 17:05:16 +0100
Links: << >>  << T >>  << A >>

<extract>
The digital Phase/Frequency Comparator is the same one shown in
  Xilinx Application Note XAPP028 (Dec 2 1996)
  http://www.xilinx.com/xapp/xapp028.pdf
<end>

I think this is the one from Nestor's original post - author is Peter
Alfke - now where have I heard that name before :o)

Dave

sriley <sueriley@my-deja.com> writes
>Hello,
>
>Recently (end of May) there was a thread in the group regarding
>digital phase lock loops.  Below is a part of the thread.  It mentions
>a xilinx app note.  Does anyone have the app#?  -Thanks
>
>-Sue
>

dmac
remove the obvious for email reply
Article: 23520
Subject: Re: digital phase lock loop
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 28 Jun 2000 09:25:44 -0700
Links: << >>  << T >>  << A >>

--------------8E330EF489511977CB4CD0BE
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

The phase-frequency compartor app note is XAPP028. Juts lick on

http://www.xilinx.com/apps/xapp.htm

and go to XAPP028.
The comparator is a CLB adaptation of the venerable Motorola design of
many decades ago .

Peter Alfke


sriley wrote:

> Hello,
>
> Recently (end of May) there was a thread in the group regarding
> digital phase lock loops.  Below is a part of the thread.  It mentions
> a xilinx app note.  Does anyone have the app#?  -Thanks
>
> -Sue
>
> On Mon, 29 May 2000 15:19:39 +0100, dmac
>  <dmac@cutme.matter200.demon.co.uk> wrote:
>
>  >
>  >Hi Nestor,
>  >
>  >I don't have your original request for info and so have lost track of
>  >your intended application but offer some info from what you have
> given.
>  >
>  >I have not used type 2 but have used type 1 extensively with success.
> It
>  >is a superbly simple circuit and so wins hands down in my book - you
>  >could have the basics working in no time.
>  >
>  >I notice that you are intending a comparison frequency of 25MHz in
> the
>  >phase comparator section. I would avoid this - notice that Peter's
> Xil
>  >Apps note uses a comparison freq of around 5kHz. The benefits of this
>  >are jitter reduction, filter simplicity (audio range) and simpler
>  >stability calcs. A lower comparison frequency is easily achieved by
>  >dividing the reference and feedback paths by the same amount.
>
>  Thanks, Dave, for your response.
>
>  I read the xilinx AppNote too and noticed this low reference, but
> Peter doesn't mention what frequency he intends to generate with that
>  reference.  I do agree that the design will be simpler since certain
> sections could operate slower.
>
>  Do you know perhaps how the jitter depends on the reference tone?  I
> would like to perforom some calculations to determine the
>  maximum reference frequency that can also provide a small enough
> jitter.  So far I know that the jitter is related to the loop variance
>  which can be derived from the loop bandwidth.
>
>  Any comments are welcome.
>
>  Nestor
>  nestor@ece.concordia.ca
>
>  >
>  >Peter also mentions ...
>  >...
>  >Watch out also for the type of VCXO used. At the frequency you are
>  >talking, the mfr may use a lower rate item with a freq tripler stage.
>  >Ours did - I think 'cos we wanted a big spread (+/-250ppm) - this
> will
>  >have greater jitter. 3rd overtone VCXO (the alternative) has, I
> think,
>  >lower pull range. As you are looking for +/-300ppm, watch out. If you
>  >can reduce the spread, do, as lower spread oscs will be better
> behaved
>  >and easier (cheaper) to procure.
>
>  I will see if I can use a narrower range VCXO (+/-150ppm tuning
>  range).
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
The phase-frequency compartor app note is XAPP028. Juts lick on
<p><u><A HREF="http://www.xilinx.com/apps/xapp.htm">http://www.xilinx.com/apps/xapp.htm</A></u>
<p>and go to XAPP028.
<br>The comparator is a CLB adaptation of the venerable Motorola design
of many decades ago .
<p>Peter Alfke
<br>&nbsp;
<p>sriley wrote:
<blockquote TYPE=CITE>Hello,
<p>Recently (end of May) there was a thread in the group regarding
<br>digital phase lock loops.&nbsp; Below is a part of the thread.&nbsp;
It mentions
<br>a xilinx app note.&nbsp; Does anyone have the app#?&nbsp; -Thanks
<p>-Sue
<p>On Mon, 29 May 2000 15:19:39 +0100, dmac
<br>&nbsp;&lt;dmac@cutme.matter200.demon.co.uk> wrote:
<p>&nbsp;>
<br>&nbsp;>Hi Nestor,
<br>&nbsp;>
<br>&nbsp;>I don't have your original request for info and so have lost
track of
<br>&nbsp;>your intended application but offer some info from what you
have
<br>given.
<br>&nbsp;>
<br>&nbsp;>I have not used type 2 but have used type 1 extensively with
success.
<br>It
<br>&nbsp;>is a superbly simple circuit and so wins hands down in my book
- you
<br>&nbsp;>could have the basics working in no time.
<br>&nbsp;>
<br>&nbsp;>I notice that you are intending a comparison frequency of 25MHz
in
<br>the
<br>&nbsp;>phase comparator section. I would avoid this - notice that Peter's
<br>Xil
<br>&nbsp;>Apps note uses a comparison freq of around 5kHz. The benefits
of this
<br>&nbsp;>are jitter reduction, filter simplicity (audio range) and simpler
<br>&nbsp;>stability calcs. A lower comparison frequency is easily achieved
by
<br>&nbsp;>dividing the reference and feedback paths by the same amount.
<p>&nbsp;Thanks, Dave, for your response.
<p>&nbsp;I read the xilinx AppNote too and noticed this low reference,
but
<br>Peter doesn't mention what frequency he intends to generate with that
<br>&nbsp;reference.&nbsp; I do agree that the design will be simpler since
certain
<br>sections could operate slower.
<p>&nbsp;Do you know perhaps how the jitter depends on the reference tone?&nbsp;
I
<br>would like to perforom some calculations to determine the
<br>&nbsp;maximum reference frequency that can also provide a small enough
<br>jitter.&nbsp; So far I know that the jitter is related to the loop
variance
<br>&nbsp;which can be derived from the loop bandwidth.
<p>&nbsp;Any comments are welcome.
<p>&nbsp;Nestor
<br>&nbsp;nestor@ece.concordia.ca
<p>&nbsp;>
<br>&nbsp;>Peter also mentions ...
<br>&nbsp;>...
<br>&nbsp;>Watch out also for the type of VCXO used. At the frequency you
are
<br>&nbsp;>talking, the mfr may use a lower rate item with a freq tripler
stage.
<br>&nbsp;>Ours did - I think 'cos we wanted a big spread (+/-250ppm) -
this
<br>will
<br>&nbsp;>have greater jitter. 3rd overtone VCXO (the alternative) has,
I
<br>think,
<br>&nbsp;>lower pull range. As you are looking for +/-300ppm, watch out.
If you
<br>&nbsp;>can reduce the spread, do, as lower spread oscs will be better
<br>behaved
<br>&nbsp;>and easier (cheaper) to procure.
<p>&nbsp;I will see if I can use a narrower range VCXO (+/-150ppm tuning
<br>&nbsp;range).
<p>Sent via Deja.com <a href="http://www.deja.com/">http://www.deja.com/</a>
<br>Before you buy.</blockquote>
</html>

--------------8E330EF489511977CB4CD0BE--

Article: 23521
Subject: Re: I cant stand it any more.
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 28 Jun 2000 09:37:02 -0700
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote:

> BTW Its not only input permutations that can reduce the number of distinct
> LUT functions but also
> pushing & pulling inversions. If we say that 2 LUT patterns are equivalent
> if you can get from one to the other by permutations & inversions on the
> inputs then an N input LUT has
>
> (2**(2**N))/(N! * (2**N))
>
> distinct [= equivalence classes of] patterns (?).

Isn't math fun! Exponentials and factorials!
This was all very enlightening, but it has no practical significance. The
4-input LUT is a very compact and efficient way to implement logic, and it
has no restrictions in implementing ANY function of its four input variables.
Whether the 64K number is inflated by the 24 input permutations is of no
practical significance. Nobody should even try to burden the routing with
attempts to save something in the LUT that is there, for free.
Let's go back to engineering...
Peter Alfke



Article: 23522
Subject: Re: Tech: looking for Allpro programming software
From: Fred <mil-tecNOmiSPAM@msn.com.invalid>
Date: Wed, 28 Jun 2000 09:53:09 -0700
Links: << >>  << T >>  << A >>
If you have not found the needed software I have the DOS version for a
ALLPRO 88.


* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!

Article: 23523
Subject: Re: I cant stand it any more.
From: "R. T. Finch" <robfinch@cyg.net>
Date: Wed, 28 Jun 2000 13:00:38 -0400
Links: << >>  << T >>  << A >>
Why would input swapping reduce the number of functions possible ? To figure
out how many functions there was I drawed them all and I don't see why
swapping the input names would make a difference. Put all the inputs
(storage bits numbered 0 to 39) along the x-axis of a graph, and the output
along the y-axis of a graph. Transposing (permuting) two storage bits and
there input select doesn't reduce the number of functions (it just changes
the order they appear in) doesn't it ?

Rob


"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:395A1985.3E5930D1@algor.co.uk...
>
>
> Jim Granville wrote:
>
> > Philip Freidin wrote:
> > >
> > > For a 4 input LUT, there are 4 inputs, 16 bits in the LUT, and 65536
> > > possible patterns that the 16 bits can represent.
> > >
> > > Because the input signals can be swapped by the routing software, we
> > <snip>
> >
> > But can they ?
> >
> > If you have to design a routing scheme that is a true crosspoint,
> > ( so simplifies the LUT ) you have a LOT of bus loading, and a large
> > die overhead, plus more bits to control the cross points...
> >
> > It might make more sense to allow the LUT to do '4 line allocate',
> > to simplify, and speed, the routing resource.
> >
> > - jg
>
> Not swapping the inputs by some sort of Xbar but allowing the layout tools
> to choose the input to LUT ``pin'' allocation for most efficient routing
> then adjusting the LUT configuration accordingly.
>
> BTW Its not only input permutations that can reduce the number of distinct
> LUT functions but also
> pushing & pulling inversions. If we say that 2 LUT patterns are equivalent
> if you can get from one to the other by permutations & inversions on the
> inputs then an N input LUT has
>
> (2**(2**N))/(N! * (2**N))
>
> distinct [= equivalence classes of] patterns (?).
>


Article: 23524
Subject: Re: I cant stand it any more.
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Wed, 28 Jun 2000 11:01:37 -0700
Links: << >>  << T >>  << A >>
You approach is of course correct - I had been sidetracked into considering
the number of n-bit binary patterns which are not permutations of
each other while thinking I was doing something else. Anyway, I think
I have demonstrated enough combinatorial ignorance for now and will
consider the thread closed :)

regards,
Tom Burgess

Philip Freidin wrote:
> 
<snipped>
>
> For a 4 input LUT, there are 4 inputs, 16 bits in the LUT, and 65536
> possible patterns that the 16 bits can represent.
> 
> Because the input signals can be swapped by the routing software, we
> should consider how many permutations there are for 4 inputs.
> The answer is 4 factorial.  24
>


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