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 13800

Article: 13800
Subject: Re: Async Fifo Core or Macro for Xilinx FPGA
From: rk <stellare@NOSPAMerols.com>
Date: Mon, 28 Dec 1998 10:28:48 -0500
Links: << >>  << T >>  << A >>
Edward Moore wrote:

> then Ray Andraka <randraka@ids.net> wrote:
>
> >It is very difficult to get this kind of performance in a synthesized design
> >(especially with the async clocks).  In cases like this it is much faster and
> >easier to just to do it in schematic the way you know it needs to be implemented
> >and be done with it.
>
> IMO one of the reasons why the schematic entry vs. HDL debate keeps
> cropping up is statements like the above, which are originated by people
> who either:
>
> a) might have a vested interest in persuading people that they won't be
> able to use a HDL for their designs
>
> b) havn't tried using a HDL
>
> c) have tried a HDL, but didn't do it properly
>
> d) work for FPGA manufacurers and should perhaps know better.
>
> At it's heart, the 'cant do it in a HDL' arguement seems to stem from a
> confusion between inferred and instantiated HDL. No one is claiming that
> a synthesiser can infer a a complete async fifo. But using instantited
> components is a direct textual equivalant to schematic entry, so there
> is no design element that can be placed on a schematic that can't be
> included in a HDL design. Period. (as you Americans say).

i would strongly disagree that instantiated components in a hdl is a direct
equivalent to schematic entry.  now, if you draw schematics such that there is just a
group of black blox symbols on the sheet, with a textual label on them as a reference
designator indentifying the function, and no interconnection between components with
lines, just labels for a small net attached to each pin, and the symbols for each
component positioned linearly on the page, without respect for data flow or time,
then you would have an equivalence.  while some engineers do draw schematics that
way, it loses a lot of information.

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

> I believe that the mixed inferred/instantiated method is used by most
> experienced HDL designers. A designer might predominately infer logic,
> but a some point will say to themselves 'it will be easier to just
> instantiate this element and have done with it'.

or hook a mixture of components, schematic, macro, and hdl on a top level roadmap or
dare i say, schematic.  a large amount of instantiated logic is good for 'puters, in
my opinion, not for humanoids.

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

rk

Article: 13801
Subject: Re: 22V10 Metastability - help please
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 28 Dec 1998 11:27:31 -0500
Links: << >>  << T >>  << A >>
Peter,

My two cents worth is that whether the problem is a slow clock edge
double clocking your part, or a static hazard in your equations can be
determined by whether you see this problem only at this state transition
or whether you see it happening at other transitions as well. If this is
the only transition that has a problem, then you most likely have a
static hazard. 

But don't discount the slow clock edge. A little noise on the rising
edge of a clock line can produce a extra splinter pulse that violates
the spec on the pulse duration of the clock and will be seen by some FFs
and not all. This is very analogous to the asynch race condition that
made you gray code your counter. If one FF 'sees' the extra pulse and
the others don't, it can transition ahead of the others. Another clue
would be if your normal state sequence is 100 to 101 to 001. This would
strongly indicate that it is a clock edge problem. 

The static hazard problem can be very difficult to determine and even
harder to fix. The only way I know to diagnose it is to examine the fuse
map, or whatever text files are provided which show you the 'optimized'
equations that are actually implemented in the fuses in the PAL. Then
you can check the coverage of these equations. 

To see if you have a static hazard, you can draw a Karnaugh-Map with all
of the input signals for a given bit. Then circle the minterms as
indicated by the product terms in your fuse map. Now you examine the
possible transitions. If there is a transition you need to make in
moving from one state to another, that crosses between two circled
groups and does not stay within a circle while making the transition,
you have a static hazard. To fix it you need to add a product term to
cover each transition. It is not enough to just cover all the minterms
as we are taught to do for logic minimization. 

If this is not clear, I can refer you to some texts on the subject. 


Peter wrote:
> 
> I don't think it is this because the state machine is clocked with a
> clock common to all three D-types. Glitches, or a slow edge, on an
> input should mean simply that the state machine just misses it or just
> catches it.
> 
> However I think Don, in a post in this thread, has the right answer...
> unfortunately :)
> 
> >You might have a 'static hazard'.  For example an XOR gate with both
> >inputs connected, if the propogation time is not perfectly matched
> >then the output will glitch high on input state changes.

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 13802
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Mon, 28 Dec 1998 16:29:36 GMT
Links: << >>  << T >>  << A >>

>normally, i would construct a gray coded
>machine the asynchronous input going into the clock of the state machine,
>which goes through a gray code sequence.  then, if you sample the output
>asynchronously, it can't jump illegally between states, you can only get
>either the present state or the next state.

This is true where you have the async input *clocking* the state
machine.

In my case, the async input is *sampled* by a state machine which is
clocked at a constant clock, 1MHz.

I think the problem is caused by the equation(s) making use of both
Input and !Input, and there is the inevitable slight skew between the
two.


--
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: 13803
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Mon, 28 Dec 1998 16:29:37 GMT
Links: << >>  << T >>  << A >>

I am sure that if one is sampling just *one* input, and the states are
Gray-coded, then there should never be a metastable hazard. FWIIW I
have relied on this extensively in the past, as have others I know,
and I always thought it was a well-known principle.

But I am in fact sampling *two* inputs, generated from my single input
within the state machine equations.

My problem is how to rewrite the equations so that either only the
input, or only its complement, (but not both) are used. I don't think
there is a way to do that predictably using CUPL's state machine
language; obviously one could do it by working out all the equations
manually but then I am not sure if the 22V10 has enough product terms.

I will simply put an HC74 on the async input :)  Even if I could fix
this 8-state state machine, I have another 16-state one in the same
22V10 which will be a good deal harder to fix, and that uses a similar
async input as well.

I am astonished at how helpful people here have been, at a time when
the world is supposed to have ground to a halt. Many thanks!

>I second your opinion on both counts. I think you have identified the
>hazard which is causing the problem as well as the cure, but even with
>all of the hazards fixed, isn't there still a problem with
>metastability? I haven't done the math, but I suppose that at 1 MHz
>there is not much likelihood of it causing a failure. But synching the
>input will guarantee that there won't be a metastability problem. 


--
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: 13804
Subject: Re: 22V10 Metastability - help please
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 28 Dec 1998 11:50:49 -0500
Links: << >>  << T >>  << A >>
Magnus Homann wrote:
> 
> z80@ds2.com (Peter) writes:
> > Unfortunately, the TEST_ENA signal does get used. It is a manually
> > operated switch; rarely used but still needs to work.
> 
> A misunderstanding? The "ENC_IN" from the last term should be removed,
> not the !TEST_ENA. To me, it seems that this will keep the logical
> functioning of the TEST_ENA, but still remove the hazard.
> 
> > I also have the problem of how to reconcile my preference for using
> > CUPL's state machine precompiler with the increasingly obvious fact
> > that doing it the hard way is better in this case :)
> 
> I would go for synching all asynch inputs. Makes it easier in the long
> run, IMHO.
> 
> > >The second two is where the problem is.
> > >>   # !ENC_IN & !EQ0 & !EQ1 & EQ2
> > >>   # ENC_IN & !EQ0 & !EQ1 & EQ2 & !TEST_ENA
> > >
> > >If TEST_ENA is inactve, and EQ[0-2] = "001", one of the rows are
> > >active, and they switch depending on the input. As a check, none of
> > >the other terms are active on that state.
> > >
> > >Making a two-variable Karnaugh-diagram (very impressive... ;-), I
> > >suggest you remove the "ENC_IN" from the last term. That should do it.
> 
> Homann

I second your opinion on both counts. I think you have identified the
hazard which is causing the problem as well as the cure, but even with
all of the hazards fixed, isn't there still a problem with
metastability? I haven't done the math, but I suppose that at 1 MHz
there is not much likelihood of it causing a failure. But synching the
input will guarantee that there won't be a metastability problem. 

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 13805
Subject: Re: 22V10 Metastability - help please
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 28 Dec 1998 19:03:30 +0100
Links: << >>  << T >>  << A >>
z80@ds2.com (Peter) writes:

> I am sure that if one is sampling just *one* input, and the states are
> Gray-coded, then there should never be a metastable hazard. FWIIW I
> have relied on this extensively in the past, as have others I know,
> and I always thought it was a well-known principle.

Don't think I've heard it.

> But I am in fact sampling *two* inputs, generated from my single input
> within the state machine equations.

Depends on how you look at it, I guess. If you look at the pin, only
one input. If you look after the generation of the inputs inverse, you
have two inputs. Maybe one should look after the first and gate? Then
you have as many asynch inputs as you have PTs. Or maybe it's the
input to each DFF. Then you are back to one input.

The number of "apparent" input to your logic black box is not
important, What is important is what you do with it inside your box.

I think it is easier to consider it from the "Karnaugh-side", where
you never go from one "sqaure" to another with the same value, without
being covered by the same term.

> My problem is how to rewrite the equations so that either only the
> input, or only its complement, (but not both) are used. I don't think
> there is a way to do that predictably using CUPL's state machine
> language; obviously one could do it by working out all the equations
> manually but then I am not sure if the 22V10 has enough product terms.
> 
> I will simply put an HC74 on the async input :)

Will probably save you a lot of grief.

> I am astonished at how helpful people here have been, at a time when
> the world is supposed to have ground to a halt. Many thanks!

No problem, it will be $2.99. Or a beer. :-)

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: 13806
Subject: Re: 22V10 Metastability - help please
From: "Jeff Stout" <jstout@ncon.com>
Date: Mon, 28 Dec 1998 12:34:51 -0600
Links: << >>  << T >>  << A >>

rk wrote in message <36878B1E.42C45D73@NOSPAMerols.com>...
>Stout wrote:
>>
>> By the way, I'm not aware of any theory which saz that Gray
>> codes can be used to avoid illegal state jumps.  I always thought
>> they were used to reduce the size of the state machine.  Can
>> anybody else confirm this?
>
>gray code machines have the same number of flip-flops as a binary encoded
>one.  however, they excel  at avoiding illegal state jumps since only one

I was not talking about the number of FF they use.  Clearly they use
the same number of FF.  What I was talking about was the comb.
logic before the the FF is sometimes reduced with Gray codes vs.
straight binary implimentation.  I would think smart synthesis program
could do as well or beter.

>variable changes at a time.  normally, i would construct a gray coded
>machine the asynchronous input going into the clock of the state machine,
>which goes through a gray code sequence.  then, if you sample the output
>asynchronously, it can't jump illegally between states, you can only get
>either the present state or the next state.  or you can think of it as a

I think you are wrong when you said, "it can't jump illegally between
states".
With metastable, and a pore design, a state machine can do almost
anything it wants to.  This hole thread is because peter has just proved
this.

>mechanical shaft encoder.  as a shaft rotates, the position is indicated by
>a gray code.  since sampling is asynchronous, you cannot guarantee that the
>inputs are stable when sampled.  however, since only one input can be
>changing at the clock edge, you will get the correct position to within one
>click.
>

By the way, I've looked at Don's artical and I agree with what he saz.


>=========================================================
>
>> Good Luck
>> Jeff Stout
>
>rk
>



Article: 13807
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Mon, 28 Dec 1998 19:32:33 GMT
Links: << >>  << T >>  << A >>

After another day spent on this:

AMD PALLV22V10-15JC date code 4264AMK (yes 4264AMK)

 Exhibits the already described metastability problem
 - approx 1 error per second

PHILIPS P3Z22V10BA date code 9722

 So bad it barely runs, I spent days on this before
 trying out the AMD parts - these were from 5 samples
 received ~6/98 from a UK Philips distributor. I don't
 know what is wrong with these but it could be extreme
 sensitivity to clock risetime (actual=10ns, spec=20ns
 max), clock looks extremely clean on a 200MHz scope

PHILIPS P3Z22V10BA date code 9809

 Works perfectly, no errors in over an hour!!
 I will still add the external HC74. This has to work at
 60C ambient, etc.

So it looks like Philips have done a very quiet but possibly a very
substantial redesign of the device. And the AMD device has a
relatively huge skew in its internal data and !data generation.

On top of all this I have had more fun:

Data I/O Chiplab programmer (used for the AMD parts) being unable to
read any ex-CUPL jedec files ("incompatible data type"); I had to
"process" the jedec file with an old programmer front end (Logiclab,
long-defunct) into a very bare (and possibly barely legal) jedec file
which the Chiplab *does* accept, but this process strips the test
vectors which would have been handy on the Chiplab. The Chiplab also
refuses to program the device, with another cryptic error message,
unless one un-checks the test-vector test option (really obvious!).
Why this stupid programmer cannot intelligently handle jedec files,
especially those which are 64 bits "short" because they don't have the
UES, I don't know.

The Philips Coolrunner programmer refuses to accept the ex-Logiclab
jedec file (fair enough), it does accept the CUPL jedec files but
complains 'not enough fuses' even if one of them (with the 64-bit UES
added) definitely does have enough fuses. It however does not do any
test vector testing. At least I now know the Philips 22V10 problem was
a whole batch of duff devices and not a duff programmer.

I am glad to be doing this with the phone *not* ringing...
 

--
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: 13808
Subject: Re: 22V10 Metastability - help please
From: Ed McCauley <emccauley@bltinc.com>
Date: Mon, 28 Dec 1998 14:39:26 -0500
Links: << >>  << T >>  << A >>
Hi Peter:

I'll take another perspective.... forget about "Gray Scales" and.......

If 	the single input signal is feeding flops to determine next state
	AND
	the input signal is, as you say asynchronous
THEN
	It COULD be possible that one state flop is having its setup
requirement met while the other is not.
Endif :)

The result of course would be to enter an "unplanned" state.

For yuks, I'd register the async input(s) the state machine using the
state machine's clock.  See what happens.


-- 
Ed McCauley
Bottom Line Technologies Inc.
http://www.bltinc.com
Specializing Exclusively in Xilinx Design, Development and Training
Voice: (500) 447-FPGA, (908) 996-0817
FAX:   (908) 996-0817

Article: 13809
Subject: Re: 22V10 Metastability - help please
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 28 Dec 1998 14:46:30 -0500
Links: << >>  << T >>  << A >>
Peter wrote:
> 
> I am sure that if one is sampling just *one* input, and the states are
> Gray-coded, then there should never be a metastable hazard. FWIIW I
> have relied on this extensively in the past, as have others I know,
> and I always thought it was a well-known principle.

I don't believe this is true at all. The problem you are seeing, a
static logic hazard, and Metastability are two different issues. The
logic hazard has to do with the output of combinatoral logic glitching
on the change of a single input because of a lack of product terms
covering all of the transitions. Metastability has to do with the
behaviour of a FF when the setup and hold times are not met. 

I believe Xilinx has a good app note on metastability. It describes how
it happens, complete with the pertinent equations to describe how often
you are likely to see a problem from it. But one key point they make is
that you can never eliminate it, even by putting a FF in front of your
FSM. The output of the FF will have some probability of "holding" a
metastable state for the entire clock period. This is analogous to you
balancing a pencil on its point. But it only needs to stand for a uSec
before the next clock tick clocks the next FF with an indeterminate
voltage on its input and produces a metastable condition in that FF. 

While the likelihood of this happening with the 1 MHz clock is greatly
diminished compared to a 30 MHz clock, it is not zero. But I am pretty
sure that you won't see it happen within the next year. 

 
> But I am in fact sampling *two* inputs, generated from my single input
> within the state machine equations.

This is the static logic hazard, not a metastable problem. 

 
> My problem is how to rewrite the equations so that either only the
> input, or only its complement, (but not both) are used. I don't think
> there is a way to do that predictably using CUPL's state machine
> language; obviously one could do it by working out all the equations
> manually but then I am not sure if the 22V10 has enough product terms.

I don't think you can adjust the equations in your source code unless
you can turn off optimization. Magnus had a good fix for your optimized
equations if you can get that into the fuse map. 

 
> I will simply put an HC74 on the async input :)  Even if I could fix
> this 8-state state machine, I have another 16-state one in the same
> 22V10 which will be a good deal harder to fix, and that uses a similar
> async input as well.

You might want to check the Xilinx app note (or others) before you
assume this will fix the problem well enough. It may reduce it to once a
year or so, but that is a guess. You may need two FFs in front of your
FSM for this to work correctly. An HC174 might be more useful (more FFs 
;^). 
 
> I am astonished at how helpful people here have been, at a time when
> the world is supposed to have ground to a halt. Many thanks!

I think you must have hit a nerve. I guess a lot of people have
encountered this problem before and "feel your pain".
 
-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 13810
Subject: Re: smallest DCT algorithm?
From: "Daniel Sears" <dbsears@ix.netcom.com>
Date: Mon, 28 Dec 1998 11:59:09 -0800
Links: << >>  << T >>  << A >>

Dan,

in principle, there isn't a big difference between finding nice
numbers near the original cosine values and truncating them at
a certain precision.  Both of these are approximations.

When I looked at this stuff, the shift and add approaches were
for minimizing hardware.  If the hardware is given, and you
are minimizing software instructions, I don't think it is profitable.

Multiplication free DCTs are a subset of multiplication free filters
which are well published in the various research magazines.

You might look at:

 SPIE Proceedings Vol. 2419
 Digital Video Compression: Algorithms and Technologies 1995
 Multiplication free scaled 8 x 8 DCT algorithm with 530 additions


Article: 13811
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Mon, 28 Dec 1998 20:24:48 GMT
Links: << >>  << T >>  << A >>

>I don't believe this is true at all. The problem you are seeing, a
>static logic hazard, and Metastability are two different issues. The
>logic hazard has to do with the output of combinatoral logic glitching
>on the change of a single input because of a lack of product terms
>covering all of the transitions. Metastability has to do with the
>behaviour of a FF when the setup and hold times are not met. 
>
>I believe Xilinx has a good app note on metastability. 

Yes, I agree with you fully. I stupidly used the wrong terminology. I
generally understand the issues with metastability, with the
frequencies and edge risetimes all affecting it. A fast synchroniser
can easily push the occurrence way into the "almost never" area, at
only 1MHz.

>While the likelihood of this happening with the 1 MHz clock is greatly
>diminished compared to a 30 MHz clock, it is not zero. But I am pretty
>sure that you won't see it happen within the next year. 

I think a VHC74, also clocked at 1MHz, will do very well. Its output
would have to be wondering about for a whole microsecond to cause
trouble. Also, its o/p risetime is <5ns versus my present 50ns edge. 

Also, (see my other post) the Philips P3Z22V10 is evidently far far
better at this than the AMD device, several orders of magnitude. I
will however keep using the AMD parts for crap jobs like CPU address
decoding - they are very cheap :)

>You might want to check the Xilinx app note (or others) before you
>assume this will fix the problem well enough. It may reduce it to once a
>year or so, but that is a guess. You may need two FFs in front of your
>FSM for this to work correctly. An HC174 might be more useful (more FFs 
>;^). 

Yes, I have seen this done. In my case I fortunately can tolerate the
delay.


--
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: 13812
Subject: Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 28 Dec 1998 12:26:01 -0800
Links: << >>  << T >>  << A >>
Christmas seems to bring out the best in the people on these newsgroups.

More than a dozen responses, several quite detailed and insightful,
within a day, when most of the world is goofing off. Or let's call it
"resting"
I like it. That's the way it should be.
Happy New Year to all of you!

Peter Alfke

Article: 13813
Subject: Re: 22V10 Metastability - help please
From: dgy@cutout.gci-net.com (Don Yuniskis)
Date: Mon, 28 Dec 1998 20:51:37 GMT
Links: << >>  << T >>  << A >>
On Mon, 28 Dec 1998 08:24:56 GMT, z80@ds2.com (Peter) was overheard to
say:

[Apologies if my ASCII art gets munged in the process...]

> >Just employing a Gray code doesn't imply that your *implementation*
> >is "hazard free".  Make sure there are no adjacent terms in
> >the Karnaugh maps that aren't covered by a *single* minterm!
> >Often, this requires a less than minimal sum-of-products
> >implementation (i.e. some redundant terms are introduced to
> >ensure that the adjacent terms are always within a single minterm).
> >
> >In other words, if there are any paths in the Karnaugh map
> >that *momentarily* leave one minterm's coverage on their
> >way to *another* minterm's coverage, you have a potential
> >hazzard at the transition point.
> 
> I think *this* is the answer. I actually suspected this but having
> spent years on "push button" logic design I am not sure what to look
> for.
> 
> Thinking back over my previous designs, it turns out that most did
> have a synch'ed input. However I vaguely recall, on a memory
> arbitration state machine I did years ago in an EP900, that I had to
> stop CUPL minimising the expressions.
> 
> Oh well, time to blow 20 years' worth of dust off my ex-univ. logic
> books... I always hated those diagrams.
> 
> I am not asking others to do my work for me but maybe someone will
> spot something really obvious in the following:
> 
> The three D-type outputs are EQ2,EQ1,EQ0, the inputs are ENC_IN and
> TEST_ENA (the latter is not used and is always false) and the logic is
> 
> EQ0.d  =>
>     !ENC_IN & !EQ0 & !EQ1 & EQ2
>   # ENC_IN & !EQ0 & !EQ1 & !EQ2
>   # !EQ0 & EQ1
>   # !EQ0 & !EQ1 & EQ2 & TEST_ENA

   \  E1 E0
    \
IN E2\   00    01    11    10
      +-----+-----+-----+-----+
   00 |  0  |  0  |  0  |  C  |
      +-----+-----+-----+-----+
   01 |  A  |  0  |  0  |  C  |
      +-----+-----+-----+-----+
   11 |  0  |  0  |  0  |  C  |
      +-----+-----+-----+-----+
   10 |  B  |  0  |  0  |  C  |
      +-----+-----+-----+-----+

A B and C are all "1"s and just shown this way to indicate which of
the equations above was used to synthesize those particular cases in
the map.
Note I have assumed "TEST_ENA" = 0 and, as such, the 4th equation is
ignored.  This allows me to only have to deal with 4 variable maps...
 
[N.B. I build Karnaugh maps with the input variables listed in
gray code order instead of pure binary -- look at the labeling
of the horizontal and vertical axes...other folks have different
preferences]

> EQ1.d  =>
>     EQ0 & !EQ1 & EQ2 & !TEST_ENA
>   # EQ0 & !EQ1 & !EQ2
>   # !EQ0 & EQ1

   \  E1 E0
    \
IN E2\   00    01    11    10
      +-----+-----+-----+-----+
   00 |  0  |  B  |  0  |  C  |
      +-----+-----+-----+-----+
   01 |  0  |  A  |  0  |  C  |
      +-----+-----+-----+-----+
   11 |  0  |  A  |  0  |  C  |
      +-----+-----+-----+-----+
   10 |  0  |  B  |  0  |  C  |
      +-----+-----+-----+-----+
 
> EQ2.d  =>
>     !EQ0 & !EQ1 & TEST_ENA
>   # !EQ0 & EQ1 & EQ2
>   # EQ0 & EQ1 & !EQ2
>   # !ENC_IN & !EQ0 & !EQ1 & EQ2
>   # ENC_IN & !EQ0 & !EQ1 & EQ2 & !TEST_ENA
>   # EQ0 & !EQ1 & EQ2


   \  E1 E0
    \
IN E2\   00    01    11    10
      +-----+-----+-----+-----+
   00 |  0  |  0  |  C  |  0  |
      +-----+-----+-----+-----+
   01 |  D  |  F  |  0  |  B  |
      +-----+-----+-----+-----+
   11 |  E  |  F  |  0  |  B  |
      +-----+-----+-----+-----+
   10 |  0  |  0  |  C  |  0  |
      +-----+-----+-----+-----+
 
Note that the first equation is always false so there is no "A"
in the map...  Likewise, the "!TEST_EN" in equation E is always
true...

Imagine a circle drawn to encompass like letters in these maps.
In the above map, the two B's would be in one such circle.  Likewise
for the two F's.  The circle for the C's would connect the two
*adjacent*(!) C's (imagine the top and bottom edges of the map were
tied together).  The D and E would be in their own separate circles.

Now, if you are at "E" (state = 100, IN = 1) and you change the IN
input to "0", it is as if you are traversing from the E to the D. But,
as you make that change, there is a point in time when you are no
longer "covered" by the "E" equation and not yet covered by the "D"
equation.  If the clock edge occurs at that time, you end up in some
*other* state!

The solution is to make sure there is an equation that covers you
*while* you are transitioning.  In other words, we want a "circle"
that covers both the "D" and "E" squares in the above map.

Note that the D square is represented by state = 100, IN = 1
while E is represented by state = 100, IN = 0.  We can cover *both*
of them by noting that "state = 100" and IN = don't care.  This
removes the dependancy on "IN" in those two equations and eliminates
the race/hazzard.

Note that you don't have to worry about combining these with,
for example, the two "F" cases immediately adjacent to them
(though you can and this will reduce the equations even further!)
since the "transitions" from D or E to F don't depend on this
asynchronous input of yours...

A minimal implementation of this would be to combine the D E and F
terms into !E1 & E2.  Likewise, combine the B E and F terms per
!E0 & E2 (of course, you could factor these two equations
into E2 & (!E0 + !E2) but that won't help you with a two level
sum-of-products implementation typical of PAL AND/OR arrays)

However, combining the E case like this presupposes that TEST_IN
will always be "0".  To retain that independant function, you can only
combine D with the F located immediately to it's right.  The D can
*also* be combined with the E located below it by adding "TEST_IN"
to the case for the D term.

In other words, treat the D equation as:
   ...
   # !ENC_IN & !EQ0 & !EQ1 & EQ2 & TEST_IN  (D.1)
   # !ENC_IN & !EQ0 & !EQ1 & EQ2 & !TEST_IN  (D.2)
   ...
and then combine with
   # ENC_IN & !EQ0 & !EQ1 & EQ2 & !TEST_IN (E)
to yield
   # !ENC_IN & !EQ0 & !EQ1 & EQ2 & TEST_IN  (D.1)
   #          !EQ0 & !EQ1 & EQ2 & !TEST_IN  (D.2 + E)

Note that you *could* combine the A and B cases in the equations
for E1 *if* you always assume TEST_IN is wired to "0".  Then, they
could be replaced by !E1 & E0

L:ikewise, the  E0 equations could combine the A term with part
of the C term located immediately adjacent to it (i.e. remember the
left and right edges of the maps are interpreted as adjacent)
using !IN & E2 & !E0.  The B term can be combined with the adjacent
portion of C using IN & !E2 & !E0.

> The above is *after* the lowest level of optimisation by CUPL. With no
> optimisation it won't compile because there are far too many terms to
> fit a 22V10.

Well, my Brainiac2000 might be on the fritz today so double check
all my logic  :> 

> I can use a HC74 to sync the input if I have to but would prefer to
> avoid it to save PCB space.

Do you have a spare FF inside the GAL/PAL?  If so, you could use it as
a synchronizer and route it's synchronized output back into the AND/OR
array as if it was your "ENA" input...

(synchronizers are always a problem issue, though, so make sure
you design it right!  :>)


To reply, replace the asterisks:  dgy*gci-net*com

Article: 13814
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Mon, 28 Dec 1998 21:32:37 GMT
Links: << >>  << T >>  << A >>

More thoughts on this: in a Xilinx FPGA, even though the LUT is a RAM
decoder and - like any normal RAM/ROM decoder - could generate
decoding glitches, it is guaranteed by Xilinx that no glitches will
occur provided only *one* input changes at any one time.

Presumably this is achieved by making sure that any differences in
propagation delays through different paths of the LUT circuit are
*less* than the switching time of the logic (I mean the ability of the
logic to respond to an input change) which forms the LUT output(s). So
even if glitches were generated - and I can't see how they can be
avoided since no two things in nature can ever take exactly the same
time - they won't propagate to the LUT output(s).

There is no reason why the same principle would not apply to a GAL.
Referring to the input pin circuitry (the one which generates the
true/complement signals which drive the fuse matrix), if these two
signals are generated with a skew which is less than the switching
time of the huge OR gates which form the product matrix, then these
glitches (which I presumably saw in the AMD device) could never occur.

If the above is true, then the AMD PALLV22V10 is a really s****y
design, because anyone designing such devices must be aware of the way
they are going to get used.

Just imagine how many Xilinx FPGA designs would never work if the LUT
had propagation time skews big enough to generate glitches.

In light of the above I wonder if my statement about a "single async
input plus Gray code state machine encoding" is true after all, IF you
have a glitchless piece of logic before the D-types.


--
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: 13815
Subject: Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Mon, 28 Dec 1998 17:20:45 -0500
Links: << >>  << T >>  << A >>
Rickman wrote:          <snip bunch of stuff>

> > I will simply put an HC74 on the async input :)  Even if I could fix
> > this 8-state state machine, I have another 16-state one in the same
> > 22V10 which will be a good deal harder to fix, and that uses a similar
> > async input as well.
>
> You might want to check the Xilinx app note (or others) before you
> assume this will fix the problem well enough. It may reduce it to once a
> year or so, but that is a guess. You may need two FFs in front of your
> FSM for this to work correctly. An HC174 might be more useful (more FFs
> ;^).

i think it will be quite less than once per year at those frequencies - and
it's easy enough to calculate.  the xilinx flip-flops, as shown in peter's
app notes, are extremely good.  while no matter what you do you can never
eliminate metastability problems, it can be made quite small with an
extremely low failure rate.  500 nsec settiling time for a modern high-speed
flip-flop is pretty good and peter may wish to consider a 74ac74 for better
response.  also, since that is a dual f-f, he can, if he can stand the
latency, let it go through both flops, one for 1 usec settling, the other
for 500 nsec.  that will give quite adequate performance.

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

> > I am astonished at how helpful people here have been, at a time when
> > the world is supposed to have ground to a halt. Many thanks!

> I think you must have hit a nerve. I guess a lot of people have
> encountered this problem before and "feel your pain".

actually, it's an interesting topic and i've designed hazard-free circuits
(ok, now how do you test them?).  and of course it's a nice case of just hit
the button and the software does all the work - and produces a bad circuit.
perhaps there's something left for logic designers to do ...

rk


Article: 13816
Subject: Re: 22V10 Metastability - help please
From: Bob Sefton <rsefton@home.com>
Date: Mon, 28 Dec 1998 22:33:23 GMT
Links: << >>  << T >>  << A >>
Nothing to add here. I just wanted to be part of what could turn
out to be longest thread in the history of CAF.

Bob S.

Peter wrote:
> 
> Hello,
> 
> I have come across a weird problem.
> 
> 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.
> 
> The single changing input is monotonic. The illegal transition occurs
> when "expected", i.e. when the input changes at the same time as the
> clock edge.
> 
> Does anyone have any idea what could be causing this?
> 
> I can externally sync the input with an HC74, even using the opposite
> clock edge, but if there is something odd happening inside this device
> then I am going to have other problems, since I am relying on the Gray
> coding to avoid illegal state jumps.
> 
> --
> 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: 13817
Subject: Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 28 Dec 1998 14:47:45 -0800
Links: << >>  << T >>  << A >>
Rickman wrote:

> I believe Xilinx has a good app note on metastability. It describes
> how
> it happens, complete with the pertinent equations to describe how
> often
> you are likely to see a problem from it. But one key point they make
> is
> that you can never eliminate it, even by putting a FF in front of your
>
> FSM. The output of the FF will have some probability of "holding" a
> metastable state for the entire clock period. This is analogous to you
>
> balancing a pencil on its point. But it only needs to stand for a uSec
>
> before the next clock tick clocks the next FF with an indeterminate
> voltage on its input and produces a metastable condition in that FF.
>
> While the likelihood of this happening with the 1 MHz clock is greatly
>
> diminished compared to a 30 MHz clock, it is not zero. But I am pretty
>
> sure that you won't see it happen within the next year.
>  

The app note is called XAPP094 and can also be found on pages 13-47...49
of the 1998 Xilinx data book.
Metastability is an unpredictable response on a flip-flop OUTPUT that
can ( not must ) occur when the set-up time is violated. Modern
flip-flops fall back out of the metastable state in a very short time,
usually in lass than a few nanoseconds. But that delay is a statistical
phenomenon.
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.

Driving asynchronous data inputs "simultaneously" into more than one
flip-flop, however, is bound to lead to strange results, whether the
logic is grey-coded or not. But don't blame that on metastability.

Peter Alfke, Xilinx Applications
 
 

Article: 13818
Subject: Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Mon, 28 Dec 1998 17:58:02 -0500
Links: << >>  << T >>  << A >>
good evening,

pls see some comments below,

rk

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

Jeff Stout wrote:

> rk wrote in message <36878B1E.42C45D73@NOSPAMerols.com>...
> >Stout wrote:
> >>
> >> By the way, I'm not aware of any theory which saz that Gray
> >> codes can be used to avoid illegal state jumps.  I always thought
> >> they were used to reduce the size of the state machine.  Can
> >> anybody else confirm this?
> >
> >gray code machines have the same number of flip-flops as a binary encoded
> >one.  however, they excel  at avoiding illegal state jumps since only one
>
> I was not talking about the number of FF they use.  Clearly they use
> the same number of FF.  What I was talking about was the comb.
> logic before the the FF is sometimes reduced with Gray codes vs.
> straight binary implimentation.  I would think smart synthesis program
> could do as well or beter.

i remember from one of my logic books that the logic resources uesed was about
the same, although i never looked into it that much.  just for kicks, i coded up
an 8 state machine with enable and synthesized it twice, once for gray coding
the other for straight binary.  both used identical number of logic resources.
of course, this is just one test case, ymmv.

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

> >variable changes at a time.  normally, i would construct a gray coded
> >machine the asynchronous input going into the clock of the state machine,
> >which goes through a gray code sequence.  then, if you sample the output
> >asynchronously, it can't jump illegally between states, you can only get
> >either the present state or the next state.  or you can think of it as a
>
> I think you are wrong when you said, "it can't jump illegally between states".
>
> With metastable, and a pore design, a state machine can do almost
> anything it wants to.  This hole thread is because peter has just proved
> this.

actually, no, this thread hasn't proved that at all.  what is happening is that
the state machine has more than one variable changing state at a time and a
logic design error (and not a gray code).  if you have a set of flip-flops
changing in a gray code sequence and sample the outputs asynchronously, even if
a flip-flop goes metastable, the error can not be large, and the following
machine can't do just about anything it wants, assuming that proper settling
time is allowed after sampling.  if the sequence was binary, then your statement
would be partially true, just about anything can happen, as in the case where
the sequence goes from 011 to 100 - any value may be sampled.

now, in the original problem, it's not clear that any flip-flop is going
metastable at all.  while clearly the setup and hold times are not being met,
there is no evidence in any of the discussion that oscillations, non-logic
values, or delayed outputs are being observerd.  it appears that the problem is
a static hazard and the flip-flop is simply sampling the wrong value.  the
output of the pal's combinational logic is not a gray code, two things are
changing, and that's the problem.  by adding in the "redundant" terms to cover
all of the transitions, the output of the combinational network can be made to
look like a gray code sequence and things will work fine.  or, simply,
synchronize the asynchronous input so that the static hazard happens away from a
clock edge (preferred).

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

> >mechanical shaft encoder.  as a shaft rotates, the position is indicated by
> >a gray code.  since sampling is asynchronous, you cannot guarantee that the
> >inputs are stable when sampled.  however, since only one input can be
> >changing at the clock edge, you will get the correct position to within one
> >click.
> >
>
> By the way, I've looked at Don's artical and I agree with what he saz.

you should, it's correct and exactly what i said.

        don saz:

        The point of using a Gray code is that it avoids the types of
        hazzards associated with races in the next state logic.
        A Gray code, by definition, only has a single bit change between
        any two adjacent code words.  So, a signal that could have
        potential timing problems through the decoding (i.e. next state)
        logic will only affect at most a *single* output.  By contrast,
        if two or more state variables change then if the signal manages
        to propagate through *one* path in the time available, *that*
        output variable will change correctly while the *other(s)*
        may not have enough time for the correct output to be formed.

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

rk

Article: 13819
Subject: How to import EDIF file in Foundation Software?
From: "George" <gazhao@ece.ucsd.edu>
Date: Mon, 28 Dec 1998 15:48:26 -0800
Links: << >>  << T >>  << A >>
Hi, I am now trying to combine Mentor VHDL synthesize tool with Xilinx FPGA
Foundation software.
I using the Mentor Leonardo software to generate the EDIF file, which is
says to be netlist
file synthesized, but how can I import them into Xilinx software? Have
anybody do this before?
Thank you very much for your help!
Also, can somebody give me a more detailed description about what is EDIF
files?
Thanks a lot!



Article: 13820
Subject: Re: 22V10 Metastability - help please
From: bob@nospam.thanks (Bob Perlman)
Date: Tue, 29 Dec 1998 00:12:14 GMT
Links: << >>  << T >>  << A >>
Hi - 

I'm not trying to be a cheerleader for AMD--Jerry Sanders can do his
own PR--but I have no reason to believe that there's anything bad or
substandard about AMD versions of the 22V10.  22V10s and most other
PLDs are based on AND/OR planes, which are bound to be glitchy if the
designer hasn't (a) added product terms to mask the effects of
transition or (b) synchronized asynchronous inputs.

The Xilinx FPGA implementation is completely different.  Each 4-input
LUT consists of 16 SRAM cells (latches, actually) followed by a 16:1
mux built with transmission gates.  The construction is such that, if
you switch a single LUT input, the mux switches between the outputs of
two latches, and no others.   (To see how this would work, picture 4
levels of 2:1 muxes, each of which has a LUT input as its select.  I
may be wrong about the exact structure, but you get the idea.)  If the
two latches we're transitioning between have the same state, you get a
glitchless transition.  There's no RAM decode glitch because there's
no decoder.

Each type of implementation has its pros and cons.  AND/OR structures
can have lots and lots of inputs and product terms, while LUTs are a
compact way of implementing arbitrary functions of N variables.  You
pays your money and takes your choice.

Regards,
Bob Perlman
Cambrian Design Works

Article: 13821
Subject: Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 28 Dec 1998 18:02:09 -0800
Links: << >>  << T >>  << A >>
Bob Perlman wrote:

> Hi -
> <snip>

 

> 22V10s and most other
> PLDs are based on AND/OR planes, which are bound to be glitchy if the
> designer hasn't (a) added product terms to mask the effects of
> transition or (b) synchronized asynchronous inputs.
>
> The Xilinx FPGA implementation is completely different.  Each 4-input
> LUT consists of 16 SRAM cells (latches, actually) followed by a 16:1
> mux built with transmission gates.  The construction is such that, if
> you switch a single LUT input, the mux switches between the outputs of
>
> two latches, and no others.   <snip> If the
> two latches we're transitioning between have the same state, you get a
>
> glitchless transition.  There's no RAM decode glitch because there's
> no decoder.

Bob is right, but the reason that there is no glitch, even when the
multiplexer acts like a break-before-make switch (  it undoubtably does,
either in one direction or the other ) is more subtle., There is no
glitch even with break-before-make because the stray capacitance between
these pass transistors holds the old value for the fractional nanosecond
in question.

Having answered this question many times...

Peter Alfke, Xilinx Applications

Article: 13822
Subject: Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 28 Dec 1998 18:18:35 -0800
Links: << >>  << T >>  << A >>
Peter wrote:

> More thoughts on this: in a Xilinx FPGA, even though the LUT is a RAM
> decoder and - like any normal RAM/ROM decoder - could generate
> decoding glitches, it is guaranteed by Xilinx that no glitches will
> occur provided only *one* input changes at any one time.
>
> Presumably this is achieved by making sure that any differences in
> propagation delays through different paths of the LUT circuit are
> *less* than the switching time of the logic (I mean the ability of the
>
> logic to respond to an input change) which forms the LUT output(s). So
>
> even if glitches were generated - and I can't see how they can be
> avoided since no two things in nature can ever take exactly the same
> time - they won't propagate to the LUT output(s).

Yes, kind of. As I just described in a separate entry in this "longest
thread", it is the stray capacitance between the pass transistors that
bridges over whenever any  of the switching 2-to-1 mux'es behaves as
break-before-make.

> Just imagine how many Xilinx FPGA designs would never work if the LUT
> had propagation time skews big enough to generate glitches.
>
> In light of the above I wonder if my statement about a "single async
> input plus Gray code state machine encoding" is true after all, IF you
>
> have a glitchless piece of logic before the D-types.

Here is my attempt at a broad and simple explanation:Any state machine
can ususally go to different states, depending on the input conditions.
Even if grey-coded, it can still go either forward or backwards.
When asynchronous control inputs appear at the D-inputs of sveral
flip-flops and change during their set-up-time window, there is a
possibility that one flip-flop interprets the control as "go forward",
another flip-flop interprets it as "go backwards", and they might both
change.

It's an old story. Asynchronous inputs should never be synchronized in
more than one flip-flop per input. I had that as an example in "Just Say
NO to Asynchronous Design" in the 1994 Xilinx data book ( page 9-13).

Just another way to make this thread even longer.... :-)

Peter Alfke, Xilinx Applications
 

Article: 13823
Subject: Re: 22V10 Metastability - help please
From: murray@pa.dec.com (Hal Murray)
Date: 29 Dec 1998 02:38:56 GMT
Links: << >>  << T >>  << A >>
In article <368809B8.7E864BB9@xilinx.com>, Peter Alfke <peter@xilinx.com> writes:

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

Wow!  I haven't seen anything like that from Peter Alfke before.


I think I understand the issues.  I consider metastibility a
big part of any design I get involved with.  Sometimes, it's
easy to convince myself that it won't be a problem.  Often, it's
a lot of work.

I claim the problem isn't under control until metatstbility
data gets published in data sheets rather than ApNotes.

Note that the Xilinx ApNote that Peter referenced is over
a year old.  What if I want to use a chip released since then?

What was the temp and Vcc during those tests?  Can I assume it
is worst case?

-- 
These are my opinions, not necessarily my employers.

Article: 13824
Subject: Re: 22V10 Metastability - help please
From: rk <rich.katz@nospam.gsfc.nasa.gov>
Date: Mon, 28 Dec 1998 22:04:27 -0500
Links: << >>  << T >>  << A >>
Hal Murray wrote:

> In article <368809B8.7E864BB9@xilinx.com>, Peter Alfke <peter@xilinx.com> writes:
>
> > 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.
>
> Wow!  I haven't seen anything like that from Peter Alfke before.
>
> I think I understand the issues.  I consider metastibility a
> big part of any design I get involved with.  Sometimes, it's
> easy to convince myself that it won't be a problem.  Often, it's
> a lot of work.
>
> I claim the problem isn't under control until metatstbility
> data gets published in data sheets rather than ApNotes.

good point.  the old amd (29800 ?) logic family was "metastable-state hardened" and
did have specifications as part of the data sheet.  more recently, i've seen numbers
in the chip express data books, for various flip-flop configurations.  mostly,
though, i've seen app notes from a number of the programmable vendors - and some
others when you ask them for the metastable state parameters go, 'huh?'.

rk



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