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 151775

Article: 151775
Subject: Re: Counter clocks on both edges sometimes, but not when different IO
From: rickman <gnuarm@gmail.com>
Date: Tue, 17 May 2011 06:40:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 15, 3:24=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:
> rickman wrote:
...snip...
> Ok, I am beginning to have my light bulb turn on slowly here. =A0The cloc=
k
> enable concept is new to me, but I think I get it. =A0By sampling my
> external clock and creating pulses in the clk50 domain, I can use those
> to enable the counter.
>
> The only thing I'm still unsure about is, that if these rising_edge
> pulses are generated by logic, then they are delayed somewhat from
> clk50. =A0Do they enable count on the NEXT clk50 edge? =A0(And then
> disappear a few ns after that clock edge?)
>
> Would it make more sense in this type of situation to sample with a 180
> deg phase shifted ~clk50, so that the clock enable pulses would be
> centered on the clk50 counting edges?

It is hard to give specific advice to such a general question, but I
don't think I have ever had to do anything other than detect the edge
of the clock, no "phase shifting" required.  However, if your sampled
clock is close in speed to half the sampling clock rate (i.e. close to
the Nyquist rate) then you might find that you need to also sample the
data to keep the two in sync.  But the details here depend on the
details of your interface.  A timing diagram is the only way to see
what is going on.

Recently I had a design that needed to sample the incoming clock and
data, but I first registered the serial data with the incoming clock,
then sampled both.  This allowed me to minimize the skew introduced to
the incoming clock relative to the data and have a fresh alignment to
work with internally.  This was only required because the clock edge
and other aspects of the design were programmable so I need to
optimize the setup and hold times for a general case rather than
working with specific details of a single interface case.


> > "Always" is a big statement. =A0I nearly always pick one fast clock
> > domain as the "internal" clock and sync slow clocks to this fast one.
> > Each "external" clock becomes a clock enable internally. =A0There are
> > times when I use the external clock directly, for example the serial
> > clock on an SPI port directly clocks the shift register in a recent
> > SPI design. =A0Then I have lots of time to sync the parallel word to th=
e
> > internal clock. =A0But this could be done either way. =A0Sometimes it
> > depends on the relative rate of the two clocks. =A0The closer in speed
> > they are the harder it can be to fully analyze the timing.
>
> Yes, I see. =A0And I also see how this becomes quite messy if the externa=
l
> clock is near the speed of the internal one. =A0But only if data needs to
> cross between the two domains, right?

Even that doesn't have to be a problem.  There is a circuit that will
guarantee that you get every clock edge in a crossing and by using a
combination of clocking with the incoming clock and sampling you can
assure that the data stays with the clock.  The limitation is the
jitter in your clocks.  That has to be smaller than the difference is
period.  If one clock edge jitters too much so that a period has no
clock edge in it (or two if you are looking from the other
perspective), you can miss events and data.


> Ok, so while I have learned something so far about how to sync external
> (slow) clocks to an internal fast clock, it is the case here that this
> qep_sim() is a unique clock domain, so should be able to be clocked by
> its external source directly.

But you can use the internal clock as a means of "filtering" the
spurious edges of the incoming clock.


> > I suspect that has to do with your clock signal. =A0Does it have a slow
> > rise/fall time? =A0I suspect a bit of noise is making it double clock.
> > When you route it differently (since it is not on a clock IO pin) the
> > glitch can get filtered out depending on how it is routed. =A0It only
> > takes a very tiny glitch to cause this sort of double clocking and
> > such a tiny glitch can be filtered by the random routing. =A0Putting it
> > on a global clock tree should make it fail more often.
>
> I have to probe it again Monday. =A0I recall Friday that I was a bit
> surprised that it had a rounder rising edge near the upper level than I
> would have expected. =A0However, I think it is still in the <200ns range.
> =A0 It originates from a TI ISO7220C, which specify 1ns output rise/fall.
> =A0Good grief, that can't be right. =A0I'ts slowed down a little with a
> resistor in there for various reasons related to power sequencing of the
> IO buffer panel, vs. the DSP that it usually feeds, or optionally the FPG=
A.

200 ns is an eternity on the input of an FPGA.  The internal FFs can
be clocked by glitches on the order of 10's of ps, IIRC.  You will
never see this on a scope.  The FPGA circuit itself is the best way to
detect double clocking problems.


> I tried to find the min rise time spec in the Spartan 3E datasheet last
> night, and I could swear I found a place where it said 500ns, and now
> for the life of me I can't find it again in that hideously long document.

Even if they give you a number it will have no meaning since it all
depends on the construction of your board.  Ground bounce is
inevitable.  The only question is "how much"?  A slow input is
susceptible to a smaller amount of ground noise than a fast one.

Another advantage (or maybe this was pointed out before) of the rising
edge detection on the resync approach is that it removes all such
glitches.  They are so fast that at the slower sample rate they can't
be seen.


> I will look into this again with the scope. =A0I'm almost sure it's not
> noise though, since a time magnification of the clock when a counting
> glitch occurs is perfectly smooth.

Yeah, it will look great.  But if it is crossing the threshold when a
bit of noise hits, it will either double clock on one rising edge or
can see a rising edge when the clock is falling.


> An important fact is that the counting error always happens on a falling
> edge of this ext_sim_clk, not at random times. =A0So it's not picking up
> junk from other traces which may carry asynchronous signals, of which
> there are a few.

I don't really suspect cross talk although that could be happening.
FPGAs have a lot of really fast stuff going on inside and it all
happens within the same fraction of a nanosecond.  That puts a current
spike on the ground and power pins which causes a voltage spike from
the dI/dt.  I have seen this a number of times while I haven't seen an
issue with crosstalk causing this in maybe 20 years.  I think the PCB
designers tend to watch for crosstalk pairs like a hawk while folks
sometimes forget about the ground noise of fast parts.


> >> I have gathered that when clocks are to be brought in to the FPGA, it =
is
> >> highly recommended to use a GCLK IO pin, so the signal may be buffered
> >> onto a global clock routing line. =A0I have to see if I can rearrange =
my
> >> IOs to get these external inputs onto GCLK IOs, but there are two of
> >> them and the NEXYS2 isn't very liberal about providing GCLKs on the pi=
n
> >> headers. =A0Some other GCLKs are available on another connector, but I
> >> don't yet have the mating for that.
>
> > Don't try to fix a problem if you don't understand the cause. =A0Why
> > would a GLK IO pin eliminate your problem?
>
> Oh, I don't have any intention of fixing it until I have understood it
> (I stated this in the OP)!
>
> >> Of course, when muxing external clock sources, if there are a lot of
> >> them, one could eat into the supply of GCLKs quickly, so this is
> >> undesirable.
>
> > Bingo! =A0That is a big reason for treating slow clocks as clock enable=
s
> > on an internal clock.
>
> Well in this case, it also gets muxed. =A0So it would be a waste of GCLK
> inputs if it gets fed through logic and becomes a "derived clock" anyway.

The big issue with muxing clocks is the added routing time which
disrupts the timing relationship between the clock and the incoming
data.  The tools can help to analyze this, but it is better to not
have to deal with it at all if you can.  Muxing a clock enable is
pretty much transparent since at that point it is just logic.


> >> A more interesting question is then, is it possible to take a GP IO
> >> input pin, and internally buffer it onto an internal clock routing lin=
e?
>
> > Isn't that what is already happening in your case?
>
> I have no idea at this point until I learn more about constraints and
> how to interpret the hundreds of pages of jibberish that the tools
> report when I make my bit file.
>
> As I mentioned in another post, there seems to be considerable
> discussion on the Altera forum about using constraints to control how a
> clock is distributed.

That sort of stuff is hard to deal with in my opinion.  Better off
just not having the clock in the first place.


> There is also a discussion of how muxing clocks can be dangerous. =A0I am
> very suspicous that this might be the real cause of my problem, rather
> than a signal integrity issue (I'm pretty good with signal integrity):
>
> "Gated clocks: On/off gating and muxing of clocks in clock control
> blocks or logic"http://www.alteraforum.com/forum/showpost.php?p=3D8506&po=
stcount=3D7
>
> I have to learn more about how these things are managed on the Xilinx
> device as well.

In the Lattice parts I use they have clock mux blocks.  But these
don't deal with the main problems of muxing clocks, the delay.  They
just provide a way to "cleanly" switch between clocks without
generating splinter pulses.  If the clock has no data interface then
you have a lot more freedom to run clocks through logic.


> >> Thanks for input and clarification.
>
> > Let us know what you find. =A0It is hard to analyze problems like this
> > without doing tests. =A0I may be completely off base in this case.
>
> > Rick
>
> What do you make of the test that I did where I took a copy of the muxed
> clock, and routed it back outside, then the glitches disappeared?

Remember that the glitch can be as small as a few 10's of picoseconds
which doesn't take much to filter out.  I wouldn't worry with that
test myself.  The problem is not something mysterious.  You said the
problem *always* happens on a clock edge and never in the middle of a
clock cycle, so that is clear enough to me that it is a combination of
the slow clock edges and a bit of ground noise.  Fix one or the other
or sample the clock and data to in essence, provide a digital low pass
filter.


> Since this was not perturbing the ext_sim_clk input path, and yet the
> problem disappeared, it argues strongly that the glitches are
> originating internally, possibly in the mux, where perhaps a change in
> loading by adding the new output path makes the glitches go away.
>
> Thanks very much for your feedback!

I don't think this test shows that at all.  You can filter the
glitches anywhere downstream of their source.  Try adding a fast
buffer to the clock signal.  If that makes the problem go away then it
is pretty clear that the slow clock edges are the problem.  But that
doesn't mean you have to fix it with a buffer.  I build a board with a
general purpose serial input/output.  My customer at a major
networking company figured out what I was doing in the FPGA and liked
it so much they are doing the same thing in their larger products
which have dozens of external clocks.  He got the details from me and
changed his design so it uses one internal clock instead.  He
especially liked the "filtering" the sampling approach provides since
they don't know the nature of the signals their customers will use
this with.

Need any consulting help?  Things are pretty slow for me at the
moment.  Although this is working well for my kayaking schedule.  :^)

Rick

Article: 151776
Subject: Re: Counter clocks on both edges sometimes, but not when different IO
From: rickman <gnuarm@gmail.com>
Date: Tue, 17 May 2011 06:46:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 14, 11:17=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:
> Andrew Holme wrote:
>
> > If it's an external clock, slow rise and fall times plus additive noise=
 can
> > cause multiple counts if it slews too slowly through the logic threshol=
d.
> > If the external clock rate is low, the best solution is to sample it at=
 a
> > rate comparable to the rise/fall time.
>
> Thanks for the reply.
>
> Ugh. =A0I could have sworn a few minutes ago I found a spec of 500ns for
> the min slew rate of an input in the hideous ds312.pdf "Spartan-3E FPGA
> Family: =A0Data Sheet" but now I can't find it again.
>
> Anyway, getting a clean enough clock to a logic device really isn't that
> hard. =A0I'll scope it again Monday and see if I can't put it up somewher=
e.


One more comment and then I have to run.  You will never see the
glitch on a scope, if for no other reason because it doesn't have to
be on the external signal.  A small ground shift from internal
switching currents can add a very narrow spike to an input right at
the IO buffer in the FPGA.  No noise on the input, spike on the
output.  Ground bounce, the invisible noise source.

Rick

Article: 151777
Subject: Re: Scoping a glitch
From: "Arie de Muynck" <nospam@nospam.com>
Date: Tue, 17 May 2011 22:06:16 +0200
Links: << >>  << T >>  << A >>
The ususal suspect here is ground bounce. If outputs are switching at the
same time that the clock edge occurs the wiggle you see on the scope is also
partly present on the GND pin(s), and so also seen superimposed on the CLK
signal by the CLK input buffer.
A simple test is dividing the CLK by 2 and sending that to an output pin.
You will immediately see the non-periodic pattern and most scopes can
trigger on a pulse that is longer than a CLK period.
Fast CLK edges will prevent this problem, but your CLK is far from perfect 
(for a fast chip, that is...).

Regards,
Arie de Muynck


"Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote in message
news:iqss1601vk@news6.newsguy.com...
> Hi:
>
> Today I took scope shots of a clock input to my Xilinx Spartan 3e,
> Digilent NEXYS2 board.  The clock goes to a counter, simulating a
> quadrature encoder, as explained in post "Counter clocks on both edges
> sometimes, but not when different IO pin is used" on 5-13-2011.
>
> I have discovered that I'm dealing with a different animal here than
> even the fastest logic chips I've grown comfortable with, the AC family.
>
> First is the input to the NEXYS2 IO connector pin, driven by a TI
> ISO7240c chip, with about a 150 series resistor.  This shows an
> incidence where the counter incorrectly counted on the falling edge:
>
> http://web.newsguy.com/crobcng/spartan3e/scope_11.png
>
> The falling edge which caused the glitch:
>
> http://web.newsguy.com/crobcng/spartan3e/scope_12.png
>
> At this point I was thinking, "there is no reason for this to be a
> problem."  As any discrete logic chip would never glitch with this.
>
> Nonetheless, the evidence is that internally the counter is seeing a
> rising edge here, so there must be a brief upward wiggle internally.
> How to see this?  I can't really.  The best I can do is take a copy of
> the internal signal, and spit it back out another IO port.
>
> Here is where things get weird.  Depending on which pins are chosen, it
> is possible that the glitches will go away when a copy is sent out an IO
> port.  An important additional clue was the fact that an adjacent pin to
> the clock input, when changed from unconfigured (input) to output, even
> if just a static logic level was output, caused the glitching to go
> away.  More on that later.
>
> Here is the scope looking at the output from the FPGA, of a copy of the
> internal clock, again captured on an offending falling edge causing an
> incorrect count (note this just looks the same as scope_12.png above:
>
> http://web.newsguy.com/crobcng/spartan3e/scope_13.png
>
> But when zoomed in, there is the slightest wiggle present:
>
> http://web.newsguy.com/crobcng/spartan3e/scope_14.png
>
> Now this is a 500MHz scope with a 500MHz probe, and very short (1.5cm)
> ground lead, so this is a good probing setup.  That little wiggle is
> nearly a Ghz!  Due to at least -6dB of attenuation from the scope +
> probe, the actual wiggle is probably twice or more than the amplitude
> shown, which is barely anything.
>
> Now this is of course NOT what the internal signal looks like, of
> course, because it had to go through an output buffer.  Also, the choice
> of LVCMOS 3.3V makes this perhaps the slowest output possible.
>
> But it seems like the output buffer is trying to tell us something,
> about what the internal signal looks like.  It has a friggin' glitch!
>
> I also zoomed in on several adjacent falling edges, ones which did not
> cause a counter glitch.  These have at most a "shelf" at the same level,
> but no slope reversal.  Most have just an inflection.  There is a
> pattern here.
>
>
> Finally, I replaced the driver of the input pin from the relatively high
> impedance source to a terminated 50 ohm cable with 10ns edges coming
> directly from a generator, and the glitches stopped.  This is consistent
> with the fact that the behavior changes in relation to the change in
> impedance of a pin adjacent to the input pin.
>
>
> This is fascinating.  I have to wrap my head around the fact that things
> can be happening inside the chip at the near GHz rate, so the magnitude
> of the signal integrity requirement stringency is about an order of
> magnitude more demanding than I'm used to.
>
>
> I would like to scope this again with my 1GHz scope (the one I thought
> I'd only ever need for my optical parametric oscillator work), and see
> if also I can get a faster, lower voltage signaling standard selected.
> I'm not sure if the NEXYS2 board will let that happen.  We'll see.
>
> I'm also curious to see what will happen if the edge time is slowed
> down, but the drive impedance is still low.  Fortunately my generator
> has adjustable slew rates, so I can check this out too.
>
>
> Well at least now I know what is really going on.
>
>
> -- 
> _____________________
> Mr.CRC
> crobcBOGUS@REMOVETHISsbcglobal.net
> SuSE 10.3 Linux 2.6.22.17


Article: 151778
Subject: Re: Scoping a glitch
From: "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net>
Date: Tue, 17 May 2011 20:27:50 -0700
Links: << >>  << T >>  << A >>
Arie de Muynck wrote:
> The ususal suspect here is ground bounce. If outputs are switching at the
> same time that the clock edge occurs the wiggle you see on the scope is
> also
> partly present on the GND pin(s), and so also seen superimposed on the CLK
> signal by the CLK input buffer.
> A simple test is dividing the CLK by 2 and sending that to an output pin.
> You will immediately see the non-periodic pattern and most scopes can
> trigger on a pulse that is longer than a CLK period.
> Fast CLK edges will prevent this problem, but your CLK is far from
> perfect (for a fast chip, that is...).
> 
> Regards,
> Arie de Muynck


Indeed.

Why on earth don't they put some hysteresis on the inputs to these silly
chips?

Thanks for the reply!

-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

Article: 151779
Subject: Re: Counter clocks on both edges sometimes, but not when different
From: "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net>
Date: Tue, 17 May 2011 20:51:48 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
>> Would it make more sense in this type of situation to sample with a 180
>> deg phase shifted ~clk50, so that the clock enable pulses would be
>> centered on the clk50 counting edges?
> 
> It is hard to give specific advice to such a general question, but I
> don't think I have ever had to do anything other than detect the edge
> of the clock, no "phase shifting" required.  However, if your sampled
> clock is close in speed to half the sampling clock rate (i.e. close to
> the Nyquist rate) then you might find that you need to also sample the
> data to keep the two in sync.  But the details here depend on the
> details of your interface.  A timing diagram is the only way to see
> what is going on.

Ok I made a edge detect, clock enable modification to my circuit, and it
worked fine the first try (after an hour of battling with the Xilinx
tools from hell over some silly coding issue).

>> Ok, so while I have learned something so far about how to sync external
>> (slow) clocks to an internal fast clock, it is the case here that this
>> qep_sim() is a unique clock domain, so should be able to be clocked by
>> its external source directly.
> 
> But you can use the internal clock as a means of "filtering" the
> spurious edges of the incoming clock.

Yes.  I still think the situation can arise where frequency division,
pulse generation, etc. must be done based on a clock or timebase from
another system.  And where the resynchronization jitter can't be
tolerated by registering the input "clock" to another clock close to the
chip.

I work in scientific research, and critical timing systems with lasers,
engines, etc. are all over the place.  Having to do ms delays with ns
accuracy and ps jitter are commonplace.  Hence a significant part of our
equipment budget goes to the likes of Stanford Research Systems,
Berkeley Nucleonics, etc.

So the situation will eventually arise where I will have to deliver a
clean external clock to an FPGA.  I underestimated the snappiness needed
here to feed a clock from my rather robust (from an idiot proofing from
the user, surge, and ESD proofing perspective) but sluggish (with
excessive protective impedance in the line) input buffering scheme.  The
signal is certainly smooth, so it's not external noise, but at a 30ns
rise/fall, that's certainly enough to allow a little wiggle of ground
bounce to screw things.  Another reason why I love input hysteresis.  I
always put Schmitt triggers on all my external world digital inputs.

> 200 ns is an eternity on the input of an FPGA.  The internal FFs can
> be clocked by glitches on the order of 10's of ps, IIRC.  You will
> never see this on a scope.  The FPGA circuit itself is the best way to
> detect double clocking problems.

This fact is now clear.

>> I tried to find the min rise time spec in the Spartan 3E datasheet last
>> night, and I could swear I found a place where it said 500ns, and now
>> for the life of me I can't find it again in that hideously long document.
> 
> Even if they give you a number it will have no meaning since it all
> depends on the construction of your board.  Ground bounce is
> inevitable.  The only question is "how much"?  A slow input is
> susceptible to a smaller amount of ground noise than a fast one.

Yes.

> Another advantage (or maybe this was pointed out before) of the rising
> edge detection on the resync approach is that it removes all such
> glitches.  They are so fast that at the slower sample rate they can't
> be seen.

That is an advantage, and I think I'll use this approach whenever
possible now.

> I don't really suspect cross talk although that could be happening.
> FPGAs have a lot of really fast stuff going on inside and it all
> happens within the same fraction of a nanosecond.  That puts a current
> spike on the ground and power pins which causes a voltage spike from
> the dI/dt.  I have seen this a number of times while I haven't seen an
> issue with crosstalk causing this in maybe 20 years.  I think the PCB
> designers tend to watch for crosstalk pairs like a hawk while folks
> sometimes forget about the ground noise of fast parts.

Yeah, I am convinced that it is the ground bounce at this point.

> The big issue with muxing clocks is the added routing time which
> disrupts the timing relationship between the clock and the incoming
> data.  The tools can help to analyze this, but it is better to not
> have to deal with it at all if you can.  Muxing a clock enable is
> pretty much transparent since at that point it is just logic.

That's what I'm doing now.  I made two edge detectors right on the input
timebases (I really don't want to call them clocks now) and then fed the
CEs to a mux, then on to the CE input of the enhanced qep_sim().

> In the Lattice parts I use they have clock mux blocks.  But these
> don't deal with the main problems of muxing clocks, the delay.  They
> just provide a way to "cleanly" switch between clocks without
> generating splinter pulses.  If the clock has no data interface then
> you have a lot more freedom to run clocks through logic.

In my case, splinter pulses (I call them "seams" or phase
discontinuities) aren't an issue, since there are a few recalibration
revolutions of the QEP every time the mux might be switched before
anything important happens.  But this needs to be carefully considered.

>> Since this was not perturbing the ext_sim_clk input path, and yet the
>> problem disappeared, it argues strongly that the glitches are
>> originating internally, possibly in the mux, where perhaps a change in
>> loading by adding the new output path makes the glitches go away.
> 
> I don't think this test shows that at all.

Correct.  I had gotten a bit sidetracked by the fact that muxes of the
Y=s&a|~s&b equation can glitch when s switches while a and b are both
true.  This can be easily fixed, but isn't related to my problem, which
has s constant.

>  You can filter the
> glitches anywhere downstream of their source.  Try adding a fast
> buffer to the clock signal.  If that makes the problem go away then it
> is pretty clear that the slow clock edges are the problem.

And that is what happened.  Goes away with faster input.

> Need any consulting help?  Things are pretty slow for me at the
> moment.  Although this is working well for my kayaking schedule.  :^)
> 
> Rick

Please send your CV to my work email:

crcarleREMOVETHISCRAP@ANDTHISTOOsandia.gov

I have used a consultant before (someone who hangs here), but wound up
doing things my way anyway, after learning a few important bits from
him.  In general I have the time to figure things out, and I love the
learning process, so it's unlikely we'll need you.  There are also some
expert FPGA designers on site, but somewhat partitioned from my
division.  But I do like to keep a list of prospective consultants on
file, because the situation occasionally arises where a consultant is
the right solution.


Good day!



-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

Article: 151780
Subject: Re: Counter clocks on both edges sometimes, but not when different
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Wed, 18 May 2011 10:25:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Tue, 17 May 2011 06:40:07 -0700, rickman wrote:

> Need any consulting help?  Things are pretty slow for me at the moment. 
> Although this is working well for my kayaking schedule.  :^)
> 
> Rick

Heh, you too, huh?

If only the wind dropped (here on the Isle of Skye), anyway.

At least the three sheets of ply lurking in the garage since 2004 are now 
kayak-shaped...

- Brian

Article: 151781
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: wzab <wzab01@gmail.com>
Date: Wed, 18 May 2011 05:32:15 -0700 (PDT)
Links: << >>  << T >>  << A >>

> At this point I can't say I understand what you are asking. =A0Do you
> have something specific you are asking about or have you figured it
> out at this point?
>

The idea was to have a small but efficient CPU inside of FPGA which
could be used to collect some debugging data (e.g. connected
to my http://www.ise.pw.edu.pl/~wzab/fpgadbg tool)
and also to control behavior of user IP core.
Forth seems to be the best solution due to it's extendibility
and possibility to work using simple link (serial or other).

I've exchanged some e-mails with the developer who ported J1 to
MyHDL and after this discussion I think, that the approach used
in Riscy Pygness may be really the best solution.

--
Thanks,
Wojtek


Article: 151782
Subject: Re: Scoping a glitch
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Wed, 18 May 2011 13:52:03 +0100
Links: << >>  << T >>  << A >>
> First is the input to the NEXYS2 IO connector pin, driven by a TI
> ISO7240c chip, with about a 150 series resistor.  This shows an
> incidence where the counter incorrectly counted on the falling edge:

What's the signal path to the FPGA?

> The falling edge which caused the glitch:
> http://web.newsguy.com/crobcng/spartan3e/scope_12.png

What exactly are you scoping here?

Ch3&4 are at 5V, is there some current/voltage limiting device between
the pins and the FPGA?

Are ch3 and ch4 your quadrature encoder inputs?

What's ch1 looking at?

If that falling edge is an input than at ~30ns it's shouldn't be what's causing
the problem unless you've got _terrible_ ground problems.

> Here is where things get weird.  Depending on which pins are chosen, it
> is possible that the glitches will go away when a copy is sent out an IO
> port.  An important additional clue was the fact that an adjacent pin to
> the clock input, when changed from unconfigured (input) to output, even
> if just a static logic level was output, caused the glitching to go
> away.  More on that later.


This shows your design is still susceptible to asynchronous inputs toggling.

Synchronise both(all) the inputs at the IO to the system clock then use those
to look for falling or rising edges for your counter





Nial 



Article: 151783
Subject: Re: Scoping a glitch
From: "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net>
Date: Wed, 18 May 2011 06:16:50 -0700
Links: << >>  << T >>  << A >>
Nial Stewart wrote:
>> First is the input to the NEXYS2 IO connector pin, driven by a TI
>> ISO7240c chip, with about a 150 series resistor.  This shows an
>> incidence where the counter incorrectly counted on the falling edge:
> 
> What's the signal path to the FPGA?

The ISO is on a 6-layer PCB IO buffering panel with BNC connectors to
connect to a research lab.  The output of the ISO (input to FPGA) at
3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA
header pin on the Digilent NEXYS2 board.

>> The falling edge which caused the glitch:
>> http://web.newsguy.com/crobcng/spartan3e/scope_12.png
> 
> What exactly are you scoping here?

That is a horizontally magnified view of the input to the FPGA (ch1
"A0") measured at the Digilent board pin, with 1.5cm probe ground to the
Digilent pin.  The other channels are outputs from the FPGA, after they
pass through output buffering devices and level translation to 5V on the
buffering panel.

> Ch3&4 are at 5V, is there some current/voltage limiting device between
> the pins and the FPGA?
> 
> Are ch3 and ch4 your quadrature encoder inputs?

Buffered, translated outputs from the FPGA, they go out the panel and
also at 3.3V go to a TI TMS320F2812.

> What's ch1 looking at?

Explained above.

> If that falling edge is an input than at ~30ns it's shouldn't be what's causing
> the problem unless you've got _terrible_ ground problems.

Well if there are ground problems, they are out of my control, as this
is the signal at the pin on the Digilent board.  I would expect them to
have done a competent job.

I'm not sure, is there a history of people complaining about Digilent
board signal integrity problems?

>> Here is where things get weird.  Depending on which pins are chosen, it
>> is possible that the glitches will go away when a copy is sent out an IO
>> port.  An important additional clue was the fact that an adjacent pin to
>> the clock input, when changed from unconfigured (input) to output, even
>> if just a static logic level was output, caused the glitching to go
>> away.  More on that later.
> 
> 
> This shows your design is still susceptible to asynchronous inputs toggling.

The important other fact is that if the drive impedance is made stiffer
(180->50ohms) and speed to the FPGA input increased (30->10ns) then the
glitches are no longer observed, even after an all night wait.

> Synchronise both(all) the inputs at the IO to the system clock then use those
> to look for falling or rising edges for your counter

Yeah, tried that.  Works.  I think I have things under control, with two
possible choices of path forward.

Thanks for the feedback.



-- 
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

Article: 151784
Subject: Re: Counter clocks on both edges sometimes, but not when different
From: Pete Fraser <pfraser@covad.net>
Date: Wed, 18 May 2011 06:28:08 -0700
Links: << >>  << T >>  << A >>
Brian Drummond wrote:
> On Tue, 17 May 2011 06:40:07 -0700, rickman wrote:
>
>> this is working well for my kayaking schedule.  :^)
>>
> Heh, you too, huh?

Is there some requirement that FPGA coders
are also kayakers?

Pete Fraser
Looksha IV HV


Article: 151785
Subject: Re: Random behavior of xilinx simple dual port block ram
From: Gabor <gabor@szakacs.invalid>
Date: Wed, 18 May 2011 10:12:19 -0400
Links: << >>  << T >>  << A >>
jc wrote:
> Problem 1 questions:
> How did you discover this behavior? Simulation? Chipscope? If
> chipscope, does it work in functional simulation? If so, can you
> describe difference between simulation stimulus and chipscope
> stimulus?
> Are you using separate clocks to write/read data to/from dpram?
> Does your design pass static timing analysis for all clock domains?
> What is the exact relationship between the write cycles and read
> cycles?
> Did you use coregen to create the dpram? If so, what latency does it
> say your dpram will have? It will alter this depending on if you
> select primitive/core output regs.
> 
> Problem 2 questions:
> Maybe you have unintentionally configured and are using a programmable
> almost empty flag?
> 
> - John
> 

Additional questions on Problem 2:

What are the write clock and read clock frequencies?  You *do*
understand that the empty flag gets synchronized to the read clock?

If you write one word and then wait a long time does the empty
flag eventually go low?

Is this behavior noted in simulation or in the real world?  If in
simulation did you wait at least 100 ns for global set/reset to
end before writing the FIFO?

-- Gabor

Article: 151786
Subject: Modelsim
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Wed, 18 May 2011 09:46:26 -0500
Links: << >>  << T >>  << A >>
Does anyone know if its possible to change the waveform signals so that
they are in hex instead of binary. I dont want to do it manually but just
have it come up in hex when the design is loaded.

Thanks

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 151787
Subject: Re: Scoping a glitch
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Wed, 18 May 2011 15:50:37 +0100
Links: << >>  << T >>  << A >>
>> What's the signal path to the FPGA?
> > The ISO is on a 6-layer PCB IO buffering panel with BNC connectors to
> connect to a research lab.  The output of the ISO (input to FPGA) at
> 3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA
> header pin on the Digilent NEXYS2 board.

Then it's probably not a ground problem, especially if this is the only
input to the FPGA.

> That is a horizontally magnified view of the input to the FPGA (ch1
> "A0") measured at the Digilent board pin, with 1.5cm probe ground to the
> Digilent pin.

Does that go straight to the FPGA?

Is this what it's seeing?

>> If that falling edge is an input than at ~30ns it's shouldn't be what's causing
>> the problem unless you've got _terrible_ ground problems.
>
> Well if there are ground problems, they are out of my control, as this
> is the signal at the pin on the Digilent board.  I would expect them to
> have done a competent job.
> I'm not sure, is there a history of people complaining about Digilent
> board signal integrity problems?

No, as above this almost definitely isn't a problem.

>> This shows your design is still susceptible to asynchronous inputs toggling.
>
> The important other fact is that if the drive impedance is made stiffer
> (180->50ohms) and speed to the FPGA input increased (30->10ns) then the
> glitches are no longer observed, even after an all night wait.

There could be a race condition internally which stops being a factor when
you speed up the inputs.

Depending on your build, choice of pins etc this could be re-introduced at
any point.

:-)

>> Synchronise both(all) the inputs at the IO to the system clock then use those
>> to look for falling or rising edges for your counter
>
> Yeah, tried that.  Works.  I think I have things under control, with two
> possible choices of path forward.

No, there's _only_ one path forward, synchronise your inputs.

The input you're looking at is _reasonably_ fast, how fast is the internal clock
you're using to synchronise it? Ideally it'll be a good multiple (> 5) of this
clock.

> Thanks for the feedback.

No problem, other people's problems are always interesting!



Nial



Article: 151788
Subject: Re: Modelsim
From: Allan Herriman <allanherriman@hotmail.com>
Date: 18 May 2011 15:31:46 GMT
Links: << >>  << T >>  << A >>
On Wed, 18 May 2011 09:46:26 -0500, maxascent wrote:

> Does anyone know if its possible to change the waveform signals so that
> they are in hex instead of binary. I dont want to do it manually but
> just have it come up in hex when the design is loaded.


My modelsim.ini contains the following lines in the [vsim] section:

; Default radix for all windows and commands.
; Set to symbolic, ascii, binary, octal, decimal, hex, unsigned
DefaultRadix = symbolic


Regards,
Allan

Article: 151789
Subject: Re: Modelsim
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Wed, 18 May 2011 10:46:01 -0500
Links: << >>  << T >>  << A >>
Thanks Allan

I forgot to look in the .ini file

Jon
  	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 151790
Subject: Re: Modelsim
From: rndhro <rnd@hro.org>
Date: Wed, 18 May 2011 17:53:02 +0200
Links: << >>  << T >>  << A >>


On 05/18/11 17:31, Allan Herriman wrote:
> On Wed, 18 May 2011 09:46:26 -0500, maxascent wrote:
> 
>> Does anyone know if its possible to change the waveform signals so that
>> they are in hex instead of binary. I dont want to do it manually but
>> just have it come up in hex when the design is loaded.
> 
> 
> My modelsim.ini contains the following lines in the [vsim] section:
> 
> ; Default radix for all windows and commands.
> ; Set to symbolic, ascii, binary, octal, decimal, hex, unsigned
> DefaultRadix = symbolic

you can also type
radix hex
in the command console or add it to your .do file

Article: 151791
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Brad <hwfwguy@gmail.com>
Date: Wed, 18 May 2011 09:16:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 5:32=A0am, wzab <wza...@gmail.com> wrote:
> The idea was to have a small but efficient CPU inside of FPGA which
> could be used to collect some debugging data (e.g. connected
> to myhttp://www.ise.pw.edu.pl/~wzab/fpgadbgtool)
> and also to control behavior of user IP core.
> Forth seems to be the best solution due to it's extendibility
> and possibility to work using simple link (serial or other).

I once saw a 3-word Forth, which consisted of only three words running
on the target board: fetch, store and execute. Everything else was
done on the host system and the three words were invoked over a serial
link. You have two options:

1. Words compiled on the host run on the host, performing any I/O over
the serial link.
2. Words compiled on the host run on the target after being uploaded.

Do you need a CPU to implement the "three words" or can you use
hardware? If you have a fast enough serial link (JTAG can be pretty
fast), all you need is fetch and store in the FPGA and execute on the
PC.

An interesting interface option, while not as fast as SPI/JTAG, is
I2C. Silabs CP2112 is a USB HID to I2C interface chip. A Forth (or
Python or whatever) Windows app can talk to your I2C stuff with no
drivers other than the built-in USB HID support.

-Brad

Article: 151792
Subject: Re: Modelsim
From: "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk>
Date: Wed, 18 May 2011 11:57:09 -0500
Links: << >>  << T >>  << A >>
>
>
>On 05/18/11 17:31, Allan Herriman wrote:
>> On Wed, 18 May 2011 09:46:26 -0500, maxascent wrote:
>> 
>>> Does anyone know if its possible to change the waveform signals so
that
>>> they are in hex instead of binary. I dont want to do it manually but
>>> just have it come up in hex when the design is loaded.
>> 
>> 
>> My modelsim.ini contains the following lines in the [vsim] section:
>> 
>> ; Default radix for all windows and commands.
>> ; Set to symbolic, ascii, binary, octal, decimal, hex, unsigned
>> DefaultRadix = symbolic
>
>you can also type
>radix hex
>in the command console or add it to your .do file
>

Ok thanks, 

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 151793
Subject: Re: Scoping a glitch
From: Mike Treseler <mtreseler@gmail.com>
Date: Wed, 18 May 2011 10:22:37 -0700
Links: << >>  << T >>  << A >>
On 5/18/2011 7:50 AM, Nial Stewart wrote:
> No problem, other people's problems are always interesting!

"It's funny 'cause it's true." as Homer Simpson said.
Time for me to get back to making some more-interesting problems.

          -- Mike Treseler

Article: 151794
Subject: How to use the EXT_CLK_P and EXT_CLK_N pins of Virtex II Pro
From: Pratap <pratap.iisc@gmail.com>
Date: Wed, 18 May 2011 11:06:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
I need to take out two square wave signals from the Virtex II Pro FPGA
board(XC2VP30, package ff896) with good signal shape and less jitter
value. The frequency of the two square wave signals are around 40MHz
and one is the delayed version of the other. I am trying to evaluate
the performance of a delay generator block inside the FPGA. Hence, the
shape and precision of the delays is of greater importance to me. I
have tried to take the signals through various pins on the board
including the high speed expansion connector. But I found that only
when the signals are routed out through the EXT_CLK_P(G15) and
EXT_CLK_N(F15) pins, the jitter performance is the best. But there is
a funny thing happening when I observe the two waveforms on a scope.
Below are the two cases. Looks like, when the signal levels of the two
signals are different, the signal with ZERO logic goes up to around
0.2*Vsupply and at the same time the signal with logic '1' goes down
by around 0.2Vsupply. Can anybody suggest how can I avoid such a
situation? I feel there is some sort of resistor coupling between
these two signals. But, can I  disable this coupling by changing some
setting in the ucf file? This is the entry in the ucf file
corresponding to the two pins mentioned above.

NET "clk_in_copy"  LOC = "G15" | IOSTANDARD = LVTTL  | SLEW = FAST |
DRIVE = 12 ;
#EXTERNAL_CLOCK_P=G15

NET "op_from_delay_chip_copy"  LOC = "F15" | IOSTANDARD = LVTTL | SLEW
= FAST | DRIVE = 12 ;
#EXTERNAL_CLOCK_N=F15

Please suggest a way to set these signals such that the coupling
between these two signals is nullified and I can use them as two true
single ended outputs.

Here is an illustration of the case.
https://picasaweb.google.com/lh/webUpload?uname=pratap.iisc&aid=5608112619950590593

Waiting for some helpful answers.
Thanks and regards,
Pratap

Article: 151795
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: "Rod Pemberton" <do_not_have@noavailemail.cmm>
Date: Wed, 18 May 2011 14:13:52 -0400
Links: << >>  << T >>  << A >>
"Brad" <hwfwguy@gmail.com> wrote in message
news:75de307b-6c91-46ed-9ee6-e2a57c5716a0@s41g2000prb.googlegroups.com...
On May 18, 5:32 am, wzab <wza...@gmail.com> wrote:
> > Forth seems to be the best solution due to it's extendibility
> > and possibility to work using simple link (serial or other).
>
> I once saw a 3-word Forth,
>

Frank Sergeant's 3-instruction Forth:
http://pygmy.utoh.org/forth.html


Rod Pemberton



Article: 151796
Subject: Re: How to use the EXT_CLK_P and EXT_CLK_N pins of Virtex II Pro
From: Pratap <pratap.iisc@gmail.com>
Date: Wed, 18 May 2011 11:14:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 11:06=A0pm, Pratap <pratap.i...@gmail.com> wrote:
> Hi,
> I need to take out two square wave signals from the Virtex II Pro FPGA
> board(XC2VP30, package ff896) with good signal shape and less jitter
> value. The frequency of the two square wave signals are around 40MHz
> and one is the delayed version of the other. I am trying to evaluate
> the performance of a delay generator block inside the FPGA. Hence, the
> shape and precision of the delays is of greater importance to me. I
> have tried to take the signals through various pins on the board
> including the high speed expansion connector. But I found that only
> when the signals are routed out through the EXT_CLK_P(G15) and
> EXT_CLK_N(F15) pins, the jitter performance is the best. But there is
> a funny thing happening when I observe the two waveforms on a scope.
> Below are the two cases. Looks like, when the signal levels of the two
> signals are different, the signal with ZERO logic goes up to around
> 0.2*Vsupply and at the same time the signal with logic '1' goes down
> by around 0.2Vsupply. Can anybody suggest how can I avoid such a
> situation? I feel there is some sort of resistor coupling between
> these two signals. But, can I =A0disable this coupling by changing some
> setting in the ucf file? This is the entry in the ucf file
> corresponding to the two pins mentioned above.
>
> NET "clk_in_copy" =A0LOC =3D "G15" | IOSTANDARD =3D LVTTL =A0| SLEW =3D F=
AST |
> DRIVE =3D 12 ;
> #EXTERNAL_CLOCK_P=3DG15
>
> NET "op_from_delay_chip_copy" =A0LOC =3D "F15" | IOSTANDARD =3D LVTTL | S=
LEW
> =3D FAST | DRIVE =3D 12 ;
> #EXTERNAL_CLOCK_N=3DF15
>
> Please suggest a way to set these signals such that the coupling
> between these two signals is nullified and I can use them as two true
> single ended outputs.
>
> Here is an illustration of the case.https://picasaweb.google.com/lh/webUp=
load?uname=3Dpratap.iisc&aid=3D56081...
>
> Waiting for some helpful answers.
> Thanks and regards,
> Pratap

Sorry...The link for the picture was wrogly pasted...Here is the
correct link.
https://picasaweb.google.com/pratap.iisc/May182011?authkey=3DGv1sRgCMjQ85X3=
q5O50gE#5608112742914669794

Article: 151797
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Elizabeth D Rather <erather@forth.com>
Date: Wed, 18 May 2011 08:15:21 -1000
Links: << >>  << T >>  << A >>
On 5/18/11 6:16 AM, Brad wrote:
> On May 18, 5:32 am, wzab<wza...@gmail.com>  wrote:
>> The idea was to have a small but efficient CPU inside of FPGA which
>> could be used to collect some debugging data (e.g. connected
>> to myhttp://www.ise.pw.edu.pl/~wzab/fpgadbgtool)
>> and also to control behavior of user IP core.
>> Forth seems to be the best solution due to it's extendibility
>> and possibility to work using simple link (serial or other).
>
> I once saw a 3-word Forth, which consisted of only three words running
> on the target board: fetch, store and execute. Everything else was
> done on the host system and the three words were invoked over a serial
> link. You have two options:
>
> 1. Words compiled on the host run on the host, performing any I/O over
> the serial link.
> 2. Words compiled on the host run on the target after being uploaded.
>
> Do you need a CPU to implement the "three words" or can you use
> hardware? If you have a fast enough serial link (JTAG can be pretty
> fast), all you need is fetch and store in the FPGA and execute on the
> PC.

Those three useful commands are necessary to support any kind of remote 
download or bootstrap regardless of language, but they certainly don't 
constitute anything resembling Forth.  Most microprocessor boards come 
with this facility on board, usually in some form of ROM.  JTAG is one 
way of doing it, although it also has other functions.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Article: 151798
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: BruceMcF <agila61@netscape.net>
Date: Wed, 18 May 2011 11:42:02 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 2:15=A0pm, Elizabeth D Rather <erat...@forth.com> wrote:
> On 5/18/11 6:16 AM, Brad wrote:
> > I once saw a 3-word Forth, which consisted of only three words
> > *running on the target board*

> Those three useful commands are necessary to support any kind of remote
> download or bootstrap regardless of language, but they certainly don't
> constitute anything resembling Forth.

Yes, the "Three Word Forth" is an attention grabbing title, not
*really* a three word forth, especially since the execute implies
something to be executed, so for the "processor inside an FPGA"
system, you still need the processor for the execute to have something
*to* execute.

Heck, "load, store, execute" would be a "three word forth" in any
setting in terms of the absolute minimum bootstrap required, given
knowledge of how to build a raw executable on the target.

Article: 151799
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Brad <hwfwguy@gmail.com>
Date: Wed, 18 May 2011 11:53:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 18, 11:15=A0am, Elizabeth D Rather <erat...@forth.com> wrote:
> Most microprocessor boards come
> with this facility on board, usually in some form of ROM. =A0JTAG is one
> way of doing it, although it also has other functions.

I implemented SwiftX's XTL protocol (except for Execute) in VHDL to
access stuff in my FPGA without the need for a CPU, for testing.

-Brad



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