Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 13850

Article: 13850
Subject: Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 29 Dec 1998 16:51:01 -0500
Links: << >>  << T >>  << A >>
Magnus Homann wrote:

> rk <stellare@NOSPAMerols.com> writes:
> > Peter wrote:
> >
> >      < snip bunch of stuff on PAL internals >
> >
> > > Without withing to make this thread even longer, and despite what has
> > > been said here, I cannot see the problem in *sampling* a *single*
> > > async input, with a *Gray-code* state machine. In such a state
> > > machine, only *one* D-type at any one time can potentially act on that
> > > input, so either a) the input change is just sampled (and you go to
> > > the next state) or b) the input change is just missed (and you remain
> > > in the present state).
> >
> > i agree, 100%, there is no problem, that's why the gray code is popular.
>
> I disagree. In fact, here's an example.
>
> Consider a SM where from state "00" you go to "01" on IN = '1' or to
> "10" on IN = '0'. If the signals change within, say, x ps skew,
> there's still a chance to get to state "11". I don't think you can
> design a PAL to reliably handle this situation. Non-glitching LUTs
> wont help you either.

> It's a bit forced example, but not entirely unlikely to happen.

i think there is a bit, well, over-forced. :-)

let us assume that IN=0 and that Q=00.  then the combinational logic will be
outputting 10, ready to be clocked in on the next rising edge of the clock.
now if you change IN to be a 1, at an inconvenient time, like when the clock
is transitioning, then according to your logic description two outputs of the
combinational logic will be changing, from 10 to 01, which can cause an
error.  of course, if a single input causes two bits of the output to change,
it's not a gray code.

by the definitions of a gray code that i have read, only a single output may
change at a time.  these are safe to sample asynchronously assuming that after
sampling the flip-flop outputs are allowed to settle to avoid metastability
problems before being used in the next stage of logic.  further, at most one
of the flip-flops doing the same can go metastable, since by definition of a
gray code, all the other bits are constant.

===============================================================

> Homann

thanks,

have a nice evening,

rk


Article: 13851
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Tue, 29 Dec 1998 22:20:42 GMT
Links: << >>  << T >>  << A >>

>Consider a SM where from state "00" you go to "01" on IN = '1' or to
>"10" on IN = '0'. If the signals change within, say, x ps skew,
>there's still a chance to get to state "11". I don't think you can
>design a PAL to reliably handle this situation. Non-glitching LUTs
>wont help you either.

I agree with the above, where an input of 0|1 can select either of two
next states.

However, if an input of 0|1 selected either the present state, or a
next state, then a Gray code SM should be reliable, because only *one*
D-type will ever be capable of acting on the changing input.

If I am right then this is another thing to watch out for.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.

Article: 13852
Subject: Re: 22V10 Metastability - help please
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 29 Dec 1998 23:30:22 +0100
Links: << >>  << T >>  << A >>
rk <stellare@NOSPAMerols.com> writes:

> let us assume that IN=0 and that Q=00.  then the combinational logic will be
> outputting 10, ready to be clocked in on the next rising edge of the clock.
> now if you change IN to be a 1, at an inconvenient time, like when the clock
> is transitioning, then according to your logic description two outputs of the
> combinational logic will be changing, from 10 to 01, which can cause an
> error.

Yes, exactly.

> of course, if a single input causes two bits of the output to change,
> it's not a gray code.

See below.

> by the definitions of a gray code that i have read, only a single output may
> change at a time.

No, the thing is that only one of the _state bits_ can change at any
_state change_. That's the definition. It doesn't say anything about
the combinatorial logic in front of the state bits. It doesn't say
anything about the outputs, it could be a Mealy machine for instance.

I think you are mixing outputs from the state machine with the logic
computing next state.

If indeed you have a clear ref. handy, look it up and let me know
what it says. I'm still doing this from memory.

> these are safe to sample asynchronously assuming that after
> sampling the flip-flop outputs are allowed to settle to avoid metastability
> problems before being used in the next stage of logic.  further, at most one
> of the flip-flops doing the same can go metastable, since by definition of a
> gray code, all the other bits are constant.

Only one bit of the state registers change at the same time, but
which? Both 00 to 01 and 00 to 10 are legal transitions in a gray coded
SM, but logic hazard can make you take the 00 to 11 transition, which
is illegal. Ergo, your SM isn't fool proof for asynch inputs.

> have a nice evening,

Night, really. It's 2330 :-)

Homann
-- 
   Magnus Homann  Email: d0asta@dtek.chalmers.se
                  URL  : http://www.dtek.chalmers.se/DCIG/d0asta.html
  The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html

Article: 13853
Subject: Xilinx - Virtex Power Estimation?
From: "David Tang" <NOSPAMdtang@springtidenet.com>
Date: Tue, 29 Dec 1998 17:49:54 -0500
Links: << >>  << T >>  << A >>
Hi All,

I am currently doing a design with the Virtex XCV300 part and wanted
to get a first order of power consumption estimation on this part.
Is there any easy way to do this?

TIA,
David Tang



Article: 13854
Subject: Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 29 Dec 1998 18:18:32 -0500
Links: << >>  << T >>  << A >>
Magnus Homann wrote:

> rk <stellare@NOSPAMerols.com> writes:
>
> > let us assume that IN=0 and that Q=00.  then the combinational logic will be
> > outputting 10, ready to be clocked in on the next rising edge of the clock.
> > now if you change IN to be a 1, at an inconvenient time, like when the clock
> > is transitioning, then according to your logic description two outputs of the
> > combinational logic will be changing, from 10 to 01, which can cause an
> > error.
>
> Yes, exactly.
>
> > of course, if a single input causes two bits of the output to change,
> > it's not a gray code.
>
> See below.

ok

=================================================

> > by the definitions of a gray code that i have read, only a single output may
> > change at a time.
>
> No, the thing is that only one of the _state bits_ can change at any
> _state change_. That's the definition. It doesn't say anything about
> the combinatorial logic in front of the state bits. It doesn't say
> anything about the outputs, it could be a Mealy machine for instance.

sorry, bit of a disagreement here in definitions.  i actually went back and re-read
a bunch of my logic books.  gray codes, as it turns out, are not tied to
flip-flops, but to a sequence of numbers.  they can come out of a mechanical shaft
encoder, as i've stated before.  see, for example, _analysis and design of digital
circuits and computer systems_, p. chirlian, pp. 336-339.  they show the example
where the code is nothing more than the output of a set of brushes on a wheel.  the
codes advance as the mechanical shaft turns.  nothing at all to do with
flip-flops.  since the output is a gray code, only one bit can change at a time and
thus the error is small.

if you choose to replace the nicely fabricated wheel (which outputs a gray code
sequence when a input is applied) with an electrical network which does not share
the property of changing only one bit at a time, then the output will no longer be
a gray code, the flip-flops will sample a set of values where more than one value
can change at a time, and the circuit can have large errors.

_digital logic and computer design_, m. morris mano, p. 19-20, has the same
definition as chirlian, gray codes are not tied to state machines at all; indeed
they are introduced before flip-flops are discussed .  they also discuss how it is
used to sample analog systems to keep the errors low.

_switching theory and finite automate theory_, kohavi, pp. 12-14 again discuss the
codes without regard to state machines.  the sequence of words have certain
properites and they discuss cyclic and reflected codes.

i could go on and on but it would be a waste of time.

again, let me repeat, if you sample something that has more than one bit changing
at a time you are not sampling a gray code sequence and it's a bad circuit.

since this thread is going to idiotsville, perhaps you can simply demonstrate the
following: sample a set of n values, only one of which is changing at a time, and
you have multiple bits in error.

======================================================

> I think you are mixing outputs from the state machine with the logic
> computing next state.

sorry, nope, i'm confusing nothing.  basic logic.

=======================================================

> If indeed you have a clear ref. handy, look it up and let me know
> what it says. I'm still doing this from memory.

i did at first and then i listed some references above.

now, of course it is common to think of a sequencer using a gray coded sequence
(which is what you are referring to).  these can be very handy and i use them all
of the time.  they have the very nice property that you can sample them any old
time you want to, asynchronously, and only have small errors (where 1 is considered
small).  however, these will not be constructed in the manner in which the original
poster constructed his state machine where the next state inputs are a function of
the asynchronously changing input, which is a bad circuit.  in this case, the next
state inputs will be ONLY a function of the current state inputs and the
asynchronous signal will be the clock.

here's how this circuit is used.  suppose you have to count event which occur
randomly and the event pulse you get is well formed; i.e., sufficient pulse width
to clock your flip-flops and enough dead time between flip-flops so that you do not
violate the tlow time of your flip-flops. (or course, with random events you can
not guarantee that, but the pulse conditioning circuitry ahead of the gray coded
counter takes care of it for you, which is why we still need analog engineers or
peter a.'s 1 GHz fpga).  now the state machine will count through the gray coded
sequence just fine and will never have an error.  let's say the system needs to
collect the counts at 1 usec intervals.  obviously this is asynchronous to the gray
coded state machine.  will it work?  yes, of course it will, because ONLY 1 INPUT
TO THE SAMPLING REGISTER IS CHANGING AT A TIME BECAUSE IT'S A GRAY CODED
SEQUENCE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

if you would have happenned to use a binary counter to count events, or perhaps a
ripple counter, then you got a mess.

the important principle here is that when you sample multiple bits asynchronously,
it can be done reliably, but only if you sample a gray coded sequence, which means
that only one bit is changing at a time.  i don't care if it's the output of a
shaft encoder, an ADC, a combinational logic network, or a set of flip-flops.  if
the outputs when viewed with inifite time resolution do not glitch and only change
one bit at a time in a gray code sequence you are in good shape (as long as you
don't do anything really stupid).  if multiple bits are changing, you are not
sampling a gray code sequence and you have a bad circuit.  which is why the
original posters circuit most probably failed.

==================================================================

> > these are safe to sample asynchronously assuming that after
> > sampling the flip-flop outputs are allowed to settle to avoid metastability
> > problems before being used in the next stage of logic.  further, at most one
> > of the flip-flops doing the same can go metastable, since by definition of a
> > gray code, all the other bits are constant.
>
> Only one bit of the state registers change at the same time, but
> which? Both 00 to 01 and 00 to 10 are legal transitions in a gray coded
> SM, but logic hazard can make you take the 00 to 11 transition, which
> is illegal. Ergo, your SM isn't fool proof for asynch inputs.

sorry, you can't have it both ways.  if you have a logic hazard in the
combinational network, then the input to the registers isn't guaranteed to have
only 1 input changing at a time, so you are not sampling a gray coded sequence, so
the circuit will fail.  you are not describing my SM, but a poorly designed one.
i've said this a bunch of times, perhaps you should go back and read it a bit more
slowly.

================================================================

> > have a nice evening,
>
> Night, really. It's 2330 :-)

sorry, NY is center of universe, it's night time :-)

rk


Article: 13855
Subject: Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 29 Dec 1998 18:20:59 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Magnus Homann wrote:
>
> > ....In fact, here's an example.
> >
> > Consider a SM where from state "00" you go to "01" on IN = '1' or to
> > "10" on IN = '0'. If the signals change within, say, x ps skew,
> > there's still a chance to get to state "11". I don't think you can
> > design a PAL to reliably handle this situation. Non-glitching LUTs
> > wont help you either.
> >
>
> That's exactly what I tried to explain earlier.
> Thanks, Magnus, for the simple example.

please see explanation to this given in another post.

========================================

> Grey code doesn't help, neither does the non-glitching LUT. It is more
> fundamental:
> NEVER synchronize an asynchronous control input in more than a single
> flip-flop.

exactly.  if more than one input is changing, it's not a gray code, and
will obviously be a poor circuit and will fail.

========================================

> All the other dozen responses make for interesting reading, but I am
> pretty sure that this example here explains the real root cause.

yes, if you sample an input vector where multiple bits are changing at
once, for whatever reason (in this case a logic hazard), the circuit will
fail.

===========================================

rk

Article: 13856
Subject: Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 29 Dec 1998 15:21:39 -0800
Links: << >>  << T >>  << A >>
rk wrote:

> i think there is a bit, well, over-forced. :-)
>
> let us assume that IN=0 and that Q=00.  then the combinational logic
> will be
> outputting 10, ready to be clocked in on the next rising edge of the
> clock.
> now if you change IN to be a 1, at an inconvenient time, like when the
> clock
> is transitioning, then according to your logic description two outputs
> of the
> combinational logic will be changing, from 10 to 01, which can cause
> an
> error.  of course, if a single input causes two bits of the output to
> change,
> it's not a gray code.
>
> by the definitions of a gray code that i have read, only a single
> output may
> change at a time.

Let me disagree.Magnus brought up this beautifully simple example:The
circuit is supposed to transition from 00 to 01 when control is a 1,
but to transition from 00 to 10 when control is a 0.
That is a legitimate Grey-coded state machine with only one bit changing

when everything goes nicely and synchronously.

But when the control input changes asynchronously, then the two
flip-flops might interprete the control differently ( because of
routing  delay differences, set-up time differences, etc)
So the output might actually change directly from 00 to 11, because the
left flip-flop caught control =0, while the right flip-flop caught
control =1.
Bye-bye Grey code.

Peter Alfke, Xilinx Applications
 
  

Article: 13857
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Tue, 29 Dec 1998 15:25:18 -0800
Links: << >>  << T >>  << A >>
I think you better look at the examples again.  They will oscillate.  We can
continue from there via email if you'd rather.  (remove .extra to email)

Bruce

"Having spent untold hours at analyzing and measuring metastable
behavior, I can assure you that it is (today) a highly overrated
problem.  You can almost ignore it."

Peter Alfke
12/28/98



Peter Alfke wrote in message <3689409A.9126686@xilinx.com>...
>Bruce Nepple wrote:
>
>> snip
>
>> Nobody has really said much about metastability here, so I'd like to
>> share what I think is a real good example (a simplification)  of
>> exactly how
>
>> metastability can occur if a flip-flop.  There are two conditions that
>> can
>> easily cause metastability.  Race conditions and runt pulses.
>>
>> Race Conditions:
>> Picture an ordinary cross coupled latch made of 2 nand-gates with
>> exactly
>> identical finite prop delays.   Connect both inputs together, and
>> ground
>> them.  Both outputs are high.  Now, connect both inputs to logic 1.
>> You now
>> have an oscillator that will never stop.
>
>Try it: You have a latch that is stable in either state. No way does it
>oscillate !


>
>>
>>
>> Runt Pulse:
>>
>> Take the same cross coupled latch and start with a stable initial
>> condition,
>> both inputs high and the top gate with its output low.  Apply a low
>> going
>> pulse that is less than the prop delay to the top gate.  You now have
>> another oscillator.
>
>No way again.

>
>>
>>
>> Now, as a mental exercise, notice what happens in the race example if
>> the
>> prop delays are not balanced, or in either example if there are
>> imbalanced
>> finite rise and fall times.
>>
>> Either of these conditions occurring inside a synchronizer will cause
>> strange results.  I'm not saying that these are the *only* conditions
>> that
>> occur, but they are two fine examples of how unpredictable behavior
>> can
>> occur when setup and/or hold times are violated, and illustrate how
>> metastable effects can be of infinite duration.
>
>"Infinite duration". You mean a continuously running oscillator?Please,
>this is engineering, not speculation. Go to the lab.Try it out, and you
>will see that your explanation is completely wrong.
>Two cross-coupled NAND gates will never oscillate.
>
>Many of us understand metastability fairly well.
>Let's not confuse the issue with bogus theories.

>
>Peter Alfke, Xilinx Applications
>
>>
>
>
>


Article: 13858
Subject: Re: 22V10 Metastability - help please
From: fred@ee.wustl.edu (Fred U. Rosenberger)
Date: 29 Dec 1998 17:37:22 -0600
Links: << >>  << T >>  << A >>
Snip

>> Picture an ordinary cross coupled latch made of 2 nand-gates with exactly
>> identical finite prop delays.   Connect both inputs together, and ground
>> them.  Both outputs are high.  Now, connect both inputs to logic 1. You now
>> have an oscillator that will never stop.
>
>Try it: You have a latch that is stable in either state. No way does it oscillate !

Not always true (see below)!

>
>> Runt Pulse:
>>
>> Take the same cross coupled latch and start with a stable initial condition,
>> both inputs high and the top gate with its output low.  Apply a low going
>> pulse that is less than the prop delay to the top gate.  You now have
>> another oscillator.
>
>No way again.

 Actually: way (see below)

>
>> Now, as a mental exercise, notice what happens in the race example if the
>> prop delays are not balanced, or in either example if there are imbalanced
>> finite rise and fall times.
>>
>> Either of these conditions occurring inside a synchronizer will cause
>> strange results.  I'm not saying that these are the *only* conditions that
>> occur, but they are two fine examples of how unpredictable behavior can
>> occur when setup and/or hold times are violated, and illustrate how
>> metastable effects can be of infinite duration.
>
>"Infinite duration". You mean a continuously running oscillator?Please,
>this is engineering, not speculation. Go to the lab.Try it out, and you
>will see that your explanation is completely wrong.
>Two cross-coupled NAND gates will never oscillate.
>
>Many of us understand metastability fairly well.
>Let's not confuse the issue with bogus theories.
>
>Peter Alfke, Xilinx Applications


Sorry but this is not true.  Try it and you will *probably* never see it
oscillate.  However, it is possible for oscillation to persist forever
(or 15 minutes which is close enough) with two cross coupled inverters.
If you insist I will dig out
a photograph/reference, scan it and post to this group.

Of course if your circuit/model for an inverter is nice and simple
with a single pole it will not oscillate.  Real circuits can be more
complex although CMOS comes pretty close to the single pole model.
TTL inverters do not come close to a single pole simple model.

Regards,

Fred

Fred U. Rosenberger                 fred@ee.wustl.EDU
Institute for Biomedical Computing  http://www.ibc.wustl.edu/~fred
Washington University               Voice: (314) 362-3124
700 S. Euclid Ave.                  Fax (e-mail preferred):
St. Louis, MO 63110                     (314) 362-0234
                                    GPS: N38 38.038'  W90 15.769'

Article: 13859
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: bob@nospam.thanks (Bob Perlman)
Date: Tue, 29 Dec 1998 23:56:50 GMT
Links: << >>  << T >>  << A >>
Hi - 

On Tue, 29 Dec 1998 12:50:51 -0800, Peter Alfke <peter@xilinx.com>
wrote:

>Bruce Nepple wrote:
>
>> snip
>
>> Nobody has really said much about metastability here, so I'd like to
>> share what I think is a real good example (a simplification)  of
>> exactly how
>
>> metastability can occur if a flip-flop.  There are two conditions that
>> can
>> easily cause metastability.  Race conditions and runt pulses.
>>
>> Race Conditions:
>> Picture an ordinary cross coupled latch made of 2 nand-gates with
>> exactly
>> identical finite prop delays.   Connect both inputs together, and
>> ground
>> them.  Both outputs are high.  Now, connect both inputs to logic 1. 
>> You now
>> have an oscillator that will never stop.
>
>Try it: You have a latch that is stable in either state. No way does it
>oscillate !

Actually, sometimes cross-coupled NAND gates can oscillate.  Take a
look at "Anomalous Behavior of Synchronizer and Arbiter Circuits," a
paper written by two metastability demi-gods, Thomas Chaney and
Charles Molnar, in the April, 1973 IEEE Transactions on Computers, p.
421.  Chaney and Molnar show scope plots of what happens when
cross-coupled NAND gate latches built out of SN7400 logic either (a)
are hit with a runt pulse on one of the inputs or (b) have both S and
R inputs raised from LOW to HIGH simultaneously.  In both cases, the
outputs oscillate (in phase) for a few cycles, then assume a HIGH or
LOW value as they fall out of the metastable state.  The authors'
claim is that this behavior is more common in gates whose
prop-time-to-output-transition-time ratio is high, so I doubt you'd
see this behavior inside an FPGA or CPLD.

I've never observed this phenomenon myself, but have seen it reported
in other articles, too.

Bob Perlman
Cambrian Design Works

Article: 13860
Subject: Re: 22V10 Metastability - help please
From: jonathan@oxfordbromley.u-net.com (Jonathan Bromley)
Date: Wed, 30 Dec 1998 00:24:07 GMT
Links: << >>  << T >>  << A >>
On Sun, 27 Dec 1998 20:19:39 GMT, z80@ds2.com (Peter) wrote:

>I have an 8-state state machine (fully encoded, not one-hot). It has
>only *one* input that ever changes. The states are Gray-coded so that
>when transitioning from one state to another, only *one* D-type
>changes state.
>
>This is standard stuff which I have been using for > 10 years, with no
>problems, with various PLDs from a 16V8 to an XC3090. I am using CUPL.
>
>Now I am using an AMD PALCE22V10-15 (3.3 volt) and it is jumping
>illegally from state 100 to 001, in response to a single async input.
>The only next state should be 101.
>
>The clock is just 1MHz.

I just sat down and read the whole of this thread - good stuff,
ought to be required reading for all my digital design students -
and I don't think I have anything to add to what's already been
said by numerous people whose opinions and skills I've learned
to respect.  But there is one other point worth noting, which has
only been mentioned in passing.  I guess it's not the problem
here, since we are talking about experienced engineers and not
newbies, but it might be worth saying....  I've had no end of
trouble with students' apparently simple, bulletproof sequential
designs in small GAL devices making apparently ridiculous state
transitions, almost always caused by ground bounce.  The output
structures on fast CMOS GALs are so fast and brutal that the
dI/dt in the device's ground lead can disturb input thresholds
enough to make another, false clock pulse appear to occur;
since this false pulse is very short indeed, it may fail to
trigger some of the f/fs in the device and so you can get
completely inexplicable activity. This is a terrible 
problem if the outputs see capacitive loads - even 100pF
can be enough to cause real trouble, I've found.  Lattice's
GALs seem to be particularly troublesome in this regard.
The FPGAs I've used seem much better - I suspect the device
designers were well aware of the problem of lots of outputs
switching simultaneously, and took steps to control output
dI/dt.  The cynic in me suspects that the fast GALs get some
of their datasheet-headline speed from their ill-disciplined 
and excessively brutal outputs.

A quick way to find whether this is a problem, especially
since your clock is so slow, is to add about 1k in series 
with the clock pin, right next to the device.  Note that
changing the frequency of the clock has no effect.

On a 4-layer board, with good layout practice, this is
probably NOT the problem.  But it is very hard to spot
if you aren't ready for it, and it is a problem that's
very strongly dependent on what sort of device you use
(how big a dI/dt can the outputs create?) and on
small details like the size of capacitive load on the 
outputs.  Even the presence or absence of a scope
probe on an output can be relevant!

Just my 2p-worth (Britain won't have the euro for
a while yet...)

Jonathan Bromley

Article: 13861
Subject: Re: FAQ Address Please
From: Steve Casselman <sc@vcc.com>
Date: Tue, 29 Dec 1998 17:32:07 -0800
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> Comp.arch.fpga FAQ
>
> Q: Is there a FAQ for comp.arch.fpga?
> A: This is it.
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka

  Good start keep it up:)

--
Steve Casselman, President
Virtual Computer Corporation
http://www.vcc.com


Article: 13862
Subject: Re: smallest DCT algorithm?
From: bhaskaran vasudev <bhaskara@best.com>
Date: Tue, 29 Dec 1998 17:54:21 -0800
Links: << >>  << T >>  << A >>
Tom Lane wrote:
> 
> bhaskaran vasudev <bhaskara@best.com> writes:
> > The problem with mult. free DCTs is that they don't pass the IEEE
> > DCT accuracy test (which may or may not be okay depending on your
> > application).
> 
> Huh?  Take an IEEE-1180 compliant fixed-point DCT, expand its
> multiplies by constants to shifts and adds, and voila.  Perhaps
> we have different ideas of what is meant by a "mult-free DCT"?
> 
>                         regards, tom laneyes, it is obvious that you can take a fixed-point dct and 
synthesize the mults into a series of shifts and adds. what i meant
was "to come up with a few number of shifts and adds".. the objective is
to keep the op count reasonable. that is why i claim that if one
uses a efficient mult. free dct (say something that does a 8x8 dct
in 400 ops) it is unlikely that this dct will pass the IEEE dct
accuracy test (atleast i have not seen anything published in any ieee
journal on mult. free dcts that achieves this for reasonable op count).

Article: 13863
Subject: Re: 22V10 Metastability - help please
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Tue, 29 Dec 1998 18:30:42 -0800
Links: << >>  << T >>  << A >>

Peter wrote in message <368a2e45.96017826@news.netcomuk.co.uk>...
>
>>Consider a SM where from state "00" you go to "01" on IN = '1' or to
>>"10" on IN = '0'. If the signals change within, say, x ps skew,
>>there's still a chance to get to state "11". I don't think you can
>>design a PAL to reliably handle this situation. Non-glitching LUTs
>>wont help you either.
>
>I agree with the above, where an input of 0|1 can select either of two
>next states.
>
>However, if an input of 0|1 selected either the present state, or a
>next state, then a Gray code SM should be reliable, because only *one*
>D-type will ever be capable of acting on the changing input.
>
>If I am right then this is another thing to watch out for.
>
>

Yes Yes Yes.  You got it! I challenge anyone here to come up with a gray
code state machine that can reside in state A and conditionally branch to
either state B or State C based on an async. input.  Cannot be done without
changing 2 D-inputs at once, in which case you are not sampling a gray code
sequence, and it will fail.

All you can do is stay in state A or advance to state B based on the async
input.  You can build a safe gray code counter with an async. count enable,
but that is about all it will ever be.

Bruce

"Having spent untold hours at analyzing and measuring metastable
behavior, I can assure you that it is (today) a highly overrated
problem.  You can almost ignore it."
Peter Alfke
12/28/98



Article: 13864
Subject: Arch Jobs @ Lucent <NJ>
From: ejob <engineer@ejob.com>
Date: Tue, 29 Dec 1998 19:49:24 -0800
Links: << >>  << T >>  << A >>

>>>>>>>>>  Lucent SPAM deleted by Archive Owner



Article: 13865
Subject: Re: 22V10 Metastability - help please
From: ems@riverside-machines.com.NOSPAM
Date: Wed, 30 Dec 1998 10:11:11 GMT
Links: << >>  << T >>  << A >>
On 29 Dec 1998 17:23:25 +0100, Magnus Homann
<d0asta@mis.dtek.chalmers.se> wrote:

>ems@riverside-machines.com.NOSPAM writes:
>
>> Here's another 2 centi-euros(?) worth. At the risk of annoying a lot
>> of people, there seem to be a number of red herrings here (doubtless
>> I'll be severely kicked if I've misunderstood):
>
>Where do you want to be kicked? :-)

I'll try to present a minimal target...  :>

>What do you mean by a "synchro"? Never heard that term before.

Just shorthand for 'synchroniser'.

> Indeed
>tht logic hazards do matter, because they can (and do) occur just as
>the the DFF is sampled. Whether it's one or more DFFs, doesn't matter.

Sure, but my point is that a problem can only occur when the async
input is changing. If the input is changing, then it doesn't matter
whether the f/f decides to settle to 1 or to 0 - either the f/f gives
us the new value of the input, or the old value. Both are ok, and so
hazards on the input don't matter *when you've only got one f/f*.

>[...]
>> In this case, both EQ2 and EQ0 sample
>> ENC_IN. This will eventually fail since EQ2 and EQ0 will occasionally
>> disagree on the value of ENC_IN. You don't need a Gray-coded machine -
>> you just have to make sure that only one f/f samples the input.
>
>That wouldn't have helped. The logic hazards would still be there.

Yes, but they'd only be at the input to *one* f/f, so the hazard/s
wont matter.

>In fact, if you look at the equations, you do see that EQ0 and EQ2
>samples ENC_IN at *differeent states*. They will never care what
>the value of ENC_IN has at the same transition. The other terms in the
>product take care of that.

True, so what you're saying is that if you're careful with your
design, then you *can* sample an async input in different f/fs, as
long as you're certain that the samples don't occur on the same clock
edge. But then you have to make certain that you don't have any
hazards, so you have to design your machine by hand.... but why
bother? If you only sample in one f/f, then you're *guaranteed* that
you won't get any problems, and you don't have to do any hazard
analysis.

>> In this case, to explain the 100 -> 101 -> 001 sequence you may have
>> to invoke a hazard, or whatever (I can't explain it just by assuming
>> that EQ2 and EQ0 have sampled different values), but I find it hard to
>> believe that you could eventually make this machine work by removing
>> all hazards - you'll still have two registers sampling ENC_IN.
>
>But not at the same time. I wish Peter would try the solution I
>suggested, and see how it works.

Ok, I'm sure you're right when you say that you can make this case
work by removing the hazards, but I don't think that this is a
practical solution in general (and what if your machine has more than
one state exiting from the sample state? In this case, there are at
least two f/fs sampling the async input on the same clock cycle, and
hazard analysis won't help). one f/f per async input seems a lot
cleaner to me. But if Peter can't recode his machine cleanly, then
perhaps it's the only option (apart from using an external synchro, of
course).
 
Evan

Article: 13866
Subject: Re: Aldec integration
From: "Grzegorz Apczynski" <grzegorza@aldec.com>
Date: Wed, 30 Dec 1998 11:26:52 GMT
Links: << >>  << T >>  << A >>
Stuart Clubb wrote in message <36894c5d.1727921@nntp.netcruiser>...
>On Fri, 25 Dec 1998 19:23:18 +0200, "Ido Kleinman"
><kleinn@REMOVETHIS.mail.biu.ac.il> wrote:
>
>>I am using Aldec Active-VHDL 3.2 and Foundation M1.4 (haven't upgraded
yet).
>
>My sympathies :-)

I would suggest upgrading to Foundation 1.5. You could use Active-VHDL 3.2
directly from the flow ( in the similar way as a gate level simulator)
More information you can find on website www.aldec.com
http://www.aldec.com/activevhdl/html/XLX_FND_AVHDL.pdf 'Using Active-VHDL
Simulation with Xilinx Foundation 1.5'


>
>>I need to know how to add xilinx libraries to Active-VHDL so I will be
able
>>to instanciate and simulate components such as TBUFs, IBUFs, BUFGs and so
>>on.
>>Foundation Library file-type isn't compatible to Aldec's.
>
>You should just need the Vital libraries and map them to the various
>libraries appropriately. Look in the VHDL directory of your Xilinx
>installation and check xilinx www for the right way specifically for
>Aldec.


There are two libraries:
  UNISIM - used for functional and post-synthesis simulation
  SIMPRIM - used for timing simulation
Both libraries are included to Active-VHDL 3.2 install.
They are compiled so all you have to do is adding the appropriate
library declaration in your VHDL code.
(Foundation export to VHDL can do it automatically, this can be
set in a xilinx.cfg file located in the VHDL subfolder, if you have
any questions about it let me know: grzegorza@aldec.com )

>
>>Also I want to be able to export my design from Active-VHDL to Foundation
>>implementation and get it back for timing-simulation into Active-VHDL - I
>>know it's possible and I saw the tutorial in Aldec's Site but it wasn't
>>helpful since it referenced me to non-existant files.
>
>Select the appropriate back-annotation for writing VHDL and SDF from
>the Design Manager, and then just compile the time_sim.vhd output like
>it was regular VHDL (it's just a structural netlist). Then you should
>just simulate, applying the sdf to the appropriate unit under test.
>
>This is what I do for ModelSim, and I'm sure that Aldec is fairly
>similar.
>

Yes, Active-VHDL works in a similar way. You need both time_sim.vhd
and an SDF file. You can find more details in the above mentioned
pdf document.


>Cheers
>Stuart
>
>An employee of Saros Technology, The HDL Solutions Company:
>Renoir
>Model Technology
>Exemplar Logic
>TransEDA
>www.saros.co.uk
>(I sell these products, so paint me biased)


Article: 13867
Subject: Re: about using Mentor and Foudation together
From: ems@riverside-machines.com.NOSPAM
Date: Wed, 30 Dec 1998 11:38:48 GMT
Links: << >>  << T >>  << A >>
On Tue, 29 Dec 1998 21:49:25 GMT, s_clubb@NOSPAMnetcomuk.co.uk (Stuart
Clubb) wrote:

>3 - Synthesis
>	Leonardo Spectrum (MGC)

does mentor own exemplar?? MGC's website describes exemplar as 'an
independent company'.

a couple of things to add:

>> Now I am thinking of using mentor leonardo to synthesis it

good

>> and function simulate it

bad - it's not a simulator

>> and then generate EDIF file. Export it to xilinx foundation,
>> and then do programming and timing verify.

good

>> But, how to do timing verify just with a EDIF file?

leonardo/spectrum produce an EDIF (or XNF) file and, optionally, a
xilinx constraints file. foundation implements the design, and can
carry out a *static* timing analysis on the design. foundation will
also optionally produce an SDF (standard delay format) file. this
contains timing information which can be used by a vhdl or verilog
simulator, for timing simulation.

>> And, can I do the whole thing with mentor? with timing simulation and back
>> annotation?

the short answer is no. you'll need to buy a VHDL simulator, which
must be VITAL-compliant.

the long answer is maybe. if you pay enough for spectrum, it will read
in the SDF file produced by foundation, and you can then use the
schematic viewer option, which will report on timing delays from point
A to point B. i believe (but i haven't tried this) that it will also
use the SDF information to verify any timing constraints that you
originally entered into spectrum; in other words, it will do static
timing analysis for you.

if your budget is limited, i'd suggest:

1) get foundation, with the cheap synthesiser (a cut-down version of
synopsys's FPGA express)

2) spend your money on a VITAL-compliant simulator (you can't go wrong
with modelsim, but there are cheaper ones)

3) if you've got any money left over, you can think about buying a
better synthesiser, such as spectrum.

evan

Article: 13868
Subject: Re: Xilinx XC4000 cinfigured from EPC2?
From: "Carl R. Poirier" <CPoirier@Kodak.com>
Date: Wed, 30 Dec 1998 08:07:27 -0500
Links: << >>  << T >>  << A >>
Thanks.  I found some samples.
Seems there's an issue with the JTAG-based ISP.
Supposed to be corrected by product release in late January (WW4).

Regards, Carl

Victor Snesarev wrote in message <3680EA3D.EEC791B1@nortelnetworks.com>...
>Our Altera rep. at RTP, North Carolina will have samples available after
>Christmas.
>
>There's also a data sheet on Altera's web site:
>
>http://www.altera.com/document/ds/dsconf.pdf
>
>Sorry, cannot comment on Xilinx application of that chip.
>
>Cheers,
>
>Victor


Article: 13869
Subject: Re: about using Mentor and Foudation together
From: Le mer Michel <michel.lemer@ago.fr>
Date: Wed, 30 Dec 1998 16:23:16 +0100
Links: << >>  << T >>  << A >>
George wrote:

> Hi, Can anyone help me to solve this problems?
> I start to use xilinx and VHDL now, but my xilinx foundation basic software
> donot support
> VHDL synthesis, what a pity.
> Now I am thinking of using mentor leonardo to synthesis it, and function
> simulate it, and then generate EDIF file. Export it to xilinx foundation,
> and then do programming and timing verify.
> But, how to do timing verify just with a EDIF file?
> And, can I do the whole thing with mentor? with timing simulation and back
> annotation?
>

You can do a post-synthesis Fonctionnel gate level simulation according to the
"Xilinx/Exemplar Large Device Design Methodology" application note :
http://www.xilinx.com/apps/4000.html
For a real timing simulation, you need the Alliance series Software from
xilinx.
Then, generate a file.vhd and a file.sdf with Alliance and import it to
Modelsim (Mentor group).

> Thank you very much!

If you do the post-synthesis fonctionnel gate level simulation, let me know
please.

Good luck, good purchase.

Michel.

Michel Le Mer
Gerpi sa
3, rue du Bosphore
Alma city
35000 Rennes
France.

Article: 13870
Subject: Reconfigurable Technology -- Call for Papers
From: John Schewel <jas@vcc.com>
Date: Wed, 30 Dec 1998 09:34:55 -0800
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------FEC4E2A6DB089053FCD3A9BB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

CALL FOR PAPERS  

SPIE's International Symposium on Voice, Video & Data Communications
19-22 Septmber 1999 - Hynes Convention Center -- Boston Massachusetts
USA

Reconfigurable Technology: FPGAs for Computing and Applications (VV03)

       This is the Fourth Year of this Conference

On-site Proceedings.  Abstracts for this conference are due by 8
February
1999. Manuscripts are due by 28 June 1999.

Conference Chairs: John Schewel, Virtual Computer Corp.; Peter M.
Athanas,
Virginia Polytechnic Institute and State Univ.; Steven A. Guccione,
Xilinx
Inc.; Stefan Ludwig, Compaq Computer Corp.; John T. McHenry, National
Security Agency

Many systems engineers are using reconfigurable device technologies,
such
as Field Programmable Gate Arrays (FPGAs) and Complex Programmable Logic
Devices (CPLDs), to overcome computation and product development
bottlenecks.  In recent years, these devices have been incorporated into
computing systems for the purpose of providing a reconfigurable
environment
for high-performance applications.  This conference focuses on two areas
of
reconfigurable technology:

                1) systems, tools and techniques
                2) high-performance applications

Today's reconfigurable devices can be used for datapath and data
processing
applications, as well as for general logic replacement.Processors built
from reconfigurable logic devices are being applied to a wide range of
computationally-intensive tasks. 

The conference will present papers that illustrate applications and
techniques for using reconfigurable technology in both the design cycle
and
in production systems.  Papers relating to the following areas are
solicited:

* digital and analog reconfigurable components
* programming tools and methodologies for configurable computing systems 
* applications and platforms utilizing configurable technology for: 
        - hardware/software codesign 
        - rapid product development 
        - high-performance computing
        - image, signal, and communication processing 
          intelligent systems, robotics, and evolvable algorithms


Abstract Due Date: 8 February 1999
Manuscript Due Date Date: 28 June 1999

Abstract Information Required:
1. Submit To: VV03 Schewel ET AL
2. Abstract Title
3. Author Listing (Principle Author First)
    First Name, Last NAme, Affliation, Mailing Address,
    Telephone, Fax, Email
4. Presentation: "Oral" or "Poster"
5. Abstract Text (Aproximately 250 Words) English
6. Keywords: Five Max.
7. Brief Bio of Principle Author

You may submit Abstracts in ONE of the following options:

SPIE WEB --- Form to be found on SPIE Website
                         www.spie.org/forms/pe99_submission_form.html
EMAIL      --- To: abstracts@spie.org ; in ASCII Text Only
                         Subject:  VV03, Schewel
MAIL         --- Three copies of abstract to: 
	         Voice, Video & Data Communications
	         SPIE PO Box 10, Bellingham WA 98227-0010 USA
                        or Shipping Address   
                        1000 20th St. Bellingham WA 98225 USA
FAX           --- one copy top SPIE at   (1) 360-647-1445
               
-- 

Best Regards,
John Schewel, VP Marketing & Sales
Virtual Computer Corp.
http://www.vcc.com
--------------FEC4E2A6DB089053FCD3A9BB
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Schewel
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             John Schewel
n:              Schewel;John
org:            Virtual Computer Corporation
adr:            6925 Canby Ave. #103;;;Reseda;CA;91335;USA
email;internet: jas@vcc.com
title:          VP Marketing & Sales
tel;work:       +1 (818) 342-8294
tel;fax:        +1 (818) 342-0240
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard


--------------FEC4E2A6DB089053FCD3A9BB--

Article: 13871
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Wed, 30 Dec 1998 17:39:58 GMT
Links: << >>  << T >>  << A >>

As the person who started this thread (!!) I think my original
"theory":

 it is OK for a SM to sample a single async input provided that 
 its states are gray-coded

should have this added

 and provided that the effect of that input is EITHER to
 remain in the present state, OR to go to a next state (i.e.
 using the input to select one of *two* next states is not
 allowed)

In the example you give below, one is indeed sampling just one input
but one has *two* D-types potentially acting on that signal, and it is
only a matter of time before one sees the signal as 1 and the other
sees it as 0.

It so happens that my state machine does sample only one input, and
also happens to obey rule #2 above (this won't be apparent unless one
looks at the state diagram, which I could but did not post). However,
as I have said before, my "one input" becomes "two inputs", courtesy
of CUPL's usage of *both* true and complement versions of that input
and courtesy of a nice skew in the generation of the true and
complement versions in the *AMD* 22V10.

>But when the control input changes asynchronously, then the two
>flip-flops might interprete the control differently ( because of
>routing  delay differences, set-up time differences, etc)
>So the output might actually change directly from 00 to 11, because the
>left flip-flop caught control =0, while the right flip-flop caught
>control =1.
>Bye-bye Grey code.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.

Article: 13872
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Wed, 30 Dec 1998 17:39:59 GMT
Links: << >>  << T >>  << A >>
Whoopeeee!  After 60 posts to this thread... !

>Yes Yes Yes.  You got it! I challenge anyone here to come up with a gray
>code state machine that can reside in state A and conditionally branch to
>either state B or State C based on an async. input.  Cannot be done without
>changing 2 D-inputs at once, in which case you are not sampling a gray code
>sequence, and it will fail.
>
>All you can do is stay in state A or advance to state B based on the async
>input.  You can build a safe gray code counter with an async. count enable,
>but that is about all it will ever be.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.

Article: 13873
Subject: US job:EDA SW, Firmware,Appl.Eng+VISA
From: garynlang@aol.com (Garynlang)
Date: 30 Dec 1998 19:24:53 GMT
Links: << >>  << T >>  << A >>
We have the following openings at large semiconductor
companies.  We provide US work visa for qualified candidates if needed.


Firmware Engineer (Portland, Oregon)
* Will be responsible for developing firmware/software to allow customers 
to use the company chips.
* Will help to develop a process so that the firmware/software routines can be
easily 
re-used in future chips.
* Will support prototype and test validation. 
 * Will work with customer to develop requirements and support customer in the
integration 
of the chips. 

BSCS/BSEE or equivalent with 2+ years designing and developing software is
required.  
Must have program in C/C++ language experience.  
Experience writing firmware for embedded designs, image processing a plus.
Japenese, Korean and Mandarin languge knowledge a plus.



Application Engineer (Oregon and Arizona)

Primary duties of the position include providing technical support to 
customers as well as the company  marketing and sales personnel.  Developing 
technical collateral to aid in product implementation and business 
development.  Analyzing and resolving product performance, function and 
application issues.  Perform competitive analysis, and developing 
evaluation boards, demonstration applications, and other tools to aid in 
product evaluation and sales.

 BSEE, 2+  years experience in applications/systems engineering. 
In depth knowledge of circuit analysis and electronic system architecture; 
excellent verbal and written  communication skills; 
(Japanese, Korean and Mandarin knowledge is a big plus)
=========================================
Capability to effectively operate logic analyzers, 
scopes, and other electronic diagnostic tools. In addition, it is 
required that candidates have knowledge of software languages (C++, 
Assembly), and have experience in printed circuit board design and 
tools.

EDA SW developer. (Arizoan)
2+ years experience in UNIX, C++ and EDA SW development

Please send  your TEXT only  resume if you are interested.
Sincerely:
Gary  Lang

Article: 13874
Subject: Re: 22V10 Metastability - help please
From: terry.harris@dial.pipex.com (Terry Harris)
Date: Wed, 30 Dec 1998 20:09:51 GMT
Links: << >>  << T >>  << A >>
z80@ds2.com (Peter) wrote:

>
>As the person who started this thread (!!) I think my original
>"theory":
>
> it is OK for a SM to sample a single async input provided that 
> its states are gray-coded
>
>should have this added
>
> and provided that the effect of that input is EITHER to
> remain in the present state, OR to go to a next state (i.e.
> using the input to select one of *two* next states is not
> allowed)

But if the same input can do this in more than one place in the
sequence of states then it may still be controlling more than one
state ff and static hazards associated with that input may still cause
problems. 


Cheers Terry...



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search