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

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

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

Custom Search

Messages from 157300

Article: 157300
Subject: Re: disadvantages of inferring latches
From: rickman <gnuarm@gmail.com>
Date: Mon, 17 Nov 2014 23:23:17 -0500
Links: << >>  << T >>  << A >>
On 11/17/2014 8:16 PM, glen herrmannsfeldt wrote:
> GaborSzakacs <gabor@alacron.com> wrote:
>
> (snip on latch vs. register)
>
>> Some points:
>
>> Most Xilinx FPGA's have the ability to configure the fabric
>> flops as a gated latch rather than an edge-triggered flop.
>> These are quite robust latches and work as you might expect
>> a gated latch to work.  Xilinx's own XST synthesis is happy
>> to infer them for you (with warnings, because as mentioned
>> elsewhere, latch inference is often unintentional).
>
> (snip)
>
>> The same parts will fail miserably if you try to build
>> asynchronous sequential logic using just the LUTs.  One
>> reason is that you cannot prevent the tools from removing
>> coverage terms, short of directly instantiating the LUTs
>> with your own INIT attributes (LUT contents).
>
>> Xilinx *does* guarantee that a LUT with one input switching
>> will not glitch going from a 1 to a 1 or a 0 to a 0.  There
>> are no guarantees when multiple inputs switch mostly because
>> it is impossible to route such that they switch at exactly
>> the same time.
>
>> The timing analyzer also tends to be overly conservative when
>> determining timing through a transparent latch.  One of the points
>> of the latch is that it can add to setup time at the next flop
>> by passing through the input while the gate is "open."  The
>> tools however will look at the gate enable path as a worse case
>> rather than the data, and in some cases falsely state that your
>> timing will not work.  This leads to a lot of hand analysis of
>> the timing.
>
> In computer designs from the 1950's and 1960's, everything
> was latch, and they still worked. It takes a lot more transistors
> to make an edge-triggered master-slave FF, and transistors
> were expensive!

No, not really.  All they did was to make the clocking more complicated, 
unless they were using dynamic latches (capacitors) to store the digital 
value for a very short time resulting in a minimum clock rate.

To use latches you have to have at least two non-overlapping clocks and 
two sets of latches.  That is exactly what an edge triggered FF is, two 
latches with non-overlapping clocks allowing the input to be held by the 
first latch and then before the gate opens again the value is stored 
into a second latch.  The output changes when the second latch gate 
opens but at that point the input is already isolated so it appears as 
if the input is "clocked" into the register on the edge.

These early machines either used dynamic storage (which is *very* 
simple) or they were just splitting the register into two halves (each a 
latch) one on each clock phase (sometimes three or even four).


> One interesting latch design from the 1960's is the Earle latch:
>
> https://en.wikipedia.org/wiki/Flip-flop_%28electronics%29#Earle_latch
>
> As noted, in many cases you can combine two levels of logic with
> the logic of the latch. In a pipelined processor, that can make
> a big difference in how much logic you get at each stage, or at
> least did before the fast transistors that we have today.

Yep

-- 

Rick

Article: 157301
Subject: Re: disadvantages of inferring latches
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 18 Nov 2014 05:31:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)
>> In computer designs from the 1950's and 1960's, everything
>> was latch, and they still worked. It takes a lot more transistors
>> to make an edge-triggered master-slave FF, and transistors
>> were expensive!
 
> No, not really.  All they did was to make the clocking more complicated, 
> unless they were using dynamic latches (capacitors) to store the digital 
> value for a very short time resulting in a minimum clock rate.

Many of the early microprocessers used dynamic logic.

Also, some systems used dynamic shift registers for storage.

Don Lancaster's TV typewriter (the display part of a video terminal)
uses 512 bit MOS shift registers to store the screen data.
 
> To use latches you have to have at least two non-overlapping clocks and 
> two sets of latches.  That is exactly what an edge triggered FF is, two 
> latches with non-overlapping clocks allowing the input to be held by the 
> first latch and then before the gate opens again the value is stored 
> into a second latch.  The output changes when the second latch gate 
> opens but at that point the input is already isolated so it appears as 
> if the input is "clocked" into the register on the edge.

Yes, but you can do:

  (logic) (phase A latch) (logic) (phase B latch) ...

I never did figure out what to do with four phases, though.

> These early machines either used dynamic storage (which is *very* 
> simple) or they were just splitting the register into two halves (each a 
> latch) one on each clock phase (sometimes three or even four).
 
>> One interesting latch design from the 1960's is the Earle latch:

>> https://en.wikipedia.org/wiki/Flip-flop_%28electronics%29#Earle_latch

>> As noted, in many cases you can combine two levels of logic with
>> the logic of the latch. In a pipelined processor, that can make
>> a big difference in how much logic you get at each stage, or at
>> least did before the fast transistors that we have today.
 
> Yep

-- glen

Article: 157302
Subject: Re: disadvantages of inferring latches
From: rickman <gnuarm@gmail.com>
Date: Tue, 18 Nov 2014 02:00:37 -0500
Links: << >>  << T >>  << A >>
On 11/18/2014 12:31 AM, glen herrmannsfeldt wrote:
> rickman <gnuarm@gmail.com> wrote:
>
> (snip, I wrote)
>>> In computer designs from the 1950's and 1960's, everything
>>> was latch, and they still worked. It takes a lot more transistors
>>> to make an edge-triggered master-slave FF, and transistors
>>> were expensive!
>
>> No, not really.  All they did was to make the clocking more complicated,
>> unless they were using dynamic latches (capacitors) to store the digital
>> value for a very short time resulting in a minimum clock rate.
>
> Many of the early microprocessers used dynamic logic.
>
> Also, some systems used dynamic shift registers for storage.
>
> Don Lancaster's TV typewriter (the display part of a video terminal)
> uses 512 bit MOS shift registers to store the screen data.
>
>> To use latches you have to have at least two non-overlapping clocks and
>> two sets of latches.  That is exactly what an edge triggered FF is, two
>> latches with non-overlapping clocks allowing the input to be held by the
>> first latch and then before the gate opens again the value is stored
>> into a second latch.  The output changes when the second latch gate
>> opens but at that point the input is already isolated so it appears as
>> if the input is "clocked" into the register on the edge.
>
> Yes, but you can do:
>
>    (logic) (phase A latch) (logic) (phase B latch) ...

Yes and the two latches is equivalent to a single register in terms of 
functionality and complexity.  It doesn't save any timing.  It just 
requires that you distribute two clock phases.

I expect this was mostly used with dynamic storage since that is always 
latches and not registers.


> I never did figure out what to do with four phases, though.

I can't say, but I still have a TMS9900 SBC with a four phase clock.  I 
was rummaging in the basement the other day and found a TMS9995 CPU 
board I had built too.  I don't think I ever got that one doing anything 
useful.  I see it is hooked up to an old LCD display that came out of 
UPS trucks way back when.

I have enough old junk that I could start my own computer museum.  But I 
already threw out my LSI-11, some 15 or more years ago.  It was a 
heathkit with 8" floppy drives.  I think that is why I ditched it. 
While an SBC is always relevant what am I going to do with RT-11 on 
floppy disks?

-- 

Rick

Article: 157303
Subject: Re: disadvantages of inferring latches
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 18 Nov 2014 12:39:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip)

> I have enough old junk that I could start my own computer museum.  But I 
> already threw out my LSI-11, some 15 or more years ago.  It was a 
> heathkit with 8" floppy drives.  I think that is why I ditched it. 
> While an SBC is always relevant what am I going to do with RT-11 on 
> floppy disks?

http://www.livingcomputermuseum.org/default.aspx

-- glen

Article: 157304
Subject: Re: disadvantages of inferring latches
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 18 Nov 2014 09:21:03 -0500
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> GaborSzakacs <gabor@alacron.com> wrote:
> 
> (snip on latch vs. register)
> 
>> Some points:
>  
>> Most Xilinx FPGA's have the ability to configure the fabric
>> flops as a gated latch rather than an edge-triggered flop.
>> These are quite robust latches and work as you might expect
>> a gated latch to work.  Xilinx's own XST synthesis is happy
>> to infer them for you (with warnings, because as mentioned
>> elsewhere, latch inference is often unintentional).
>  
> (snip)
> 
>> The same parts will fail miserably if you try to build
>> asynchronous sequential logic using just the LUTs.  One
>> reason is that you cannot prevent the tools from removing
>> coverage terms, short of directly instantiating the LUTs
>> with your own INIT attributes (LUT contents).
>  
>> Xilinx *does* guarantee that a LUT with one input switching
>> will not glitch going from a 1 to a 1 or a 0 to a 0.  There
>> are no guarantees when multiple inputs switch mostly because
>> it is impossible to route such that they switch at exactly
>> the same time.
>  
>> The timing analyzer also tends to be overly conservative when
>> determining timing through a transparent latch.  One of the points
>> of the latch is that it can add to setup time at the next flop
>> by passing through the input while the gate is "open."  The
>> tools however will look at the gate enable path as a worse case
>> rather than the data, and in some cases falsely state that your
>> timing will not work.  This leads to a lot of hand analysis of
>> the timing.
> 
> In computer designs from the 1950's and 1960's, everything
> was latch, and they still worked. It takes a lot more transistors
> to make an edge-triggered master-slave FF, and transistors
> were expensive! 
> 
> One interesting latch design from the 1960's is the Earle latch:
> 
> https://en.wikipedia.org/wiki/Flip-flop_%28electronics%29#Earle_latch
> 
> As noted, in many cases you can combine two levels of logic with
> the logic of the latch. In a pipelined processor, that can make
> a big difference in how much logic you get at each stage, or at
> least did before the fast transistors that we have today.
> 
> -- glen
> 

The point of this thread isn't really that there's an inherent
problem with latches.  The issue is that FPGA's aren't designed
to create asynchronous sequential logic.  Folding a bunch of
2-input gates from your RTL into a LUT results in a huge change
in the timing characteristics of the logic.  Any structure that
doesn't already exist in the slice or logic cell gets converted
into LUTs.  Trying to build an edge-triggered D flop from LUTs
will fail just as miserably as an attempt to create latches that
way.  The older TI TTL catalogs had a schematic representation
of a 7474 flip-flop that consists of 6 3-input NAND gates.  Code
that up in an FPGA and see what happens...

-- 
Gabor

Article: 157305
Subject: Re: disadvantages of inferring latches
From: ronhk25 <ronhk25@gmail.com>
Date: Tue, 18 Nov 2014 08:02:45 -0800 (PST)
Links: << >>  << T >>  << A >>
=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=A0=D7=99,=
 17 =D7=91=D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2014 11:17:04 UTC+2, =D7=9E=
=D7=90=D7=AA ronhk25:
> Hi all,
>=20
> I always hear from FPGA designers that latches are "dangerous" and that i=
t's very important avoiding them. I wonder what are the technical risks res=
ulting by using latches. As far as I understand, the main problem is that F=
PGAs don't have built in hard latches so the synthesizer has to implement i=
t from logic blocks and then the race condition in the resulting logic is h=
ard/impossible to be analyzed.
> Is this main disadvantage latches? are there any other issues regarding l=
atches which shall be considered?
>=20
> Thanks,
>=20
> Ron

Thank you all for your answers!=20
I would like to clarify- I didn't mean to combinatorial state machines, I m=
eant to a "multi-process synchronous state machine" while the output signal=
s and the next state are assigned in an asynchronic process and the current=
 state is assigned in a synchronous process, i understand that this kind of=
 state machine is defined as synchronous state machine. I'm not experienced=
 with that kind of state machines as in the past I have always used one clo=
cked process in my state machines but in my new job I'm obliged to use the =
HDL designer graphical tool which generates those "multi-process synchronou=
s state machine". Now, as i wrote, the output signals are assigned in an as=
ynchronous process and in some states i want that some of the outputs will =
keep their last assigned value. In
synchronous process this is not a problem since a flip flop is used but in
asynchronous process an inferred latches might be created.

Those unintended latches made me open this thread, what are your recommenda=
tions to this issue?

Article: 157306
Subject: Re: disadvantages of inferring latches
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 18 Nov 2014 17:50:29 +0000 (UTC)
Links: << >>  << T >>  << A >>
GaborSzakacs <gabor@alacron.com> wrote:

(snip, I wrote)

>> In computer designs from the 1950's and 1960's, everything
>> was latch, and they still worked. It takes a lot more transistors
>> to make an edge-triggered master-slave FF, and transistors
>> were expensive! 
 
(snip)

> The point of this thread isn't really that there's an inherent
> problem with latches.  The issue is that FPGA's aren't designed
> to create asynchronous sequential logic.  Folding a bunch of
> 2-input gates from your RTL into a LUT results in a huge change
> in the timing characteristics of the logic.  Any structure that
> doesn't already exist in the slice or logic cell gets converted
> into LUTs.  

I am at least slightly interested (though I might never get 
around to) recreating old designs in FPGA logic.  Hardware
emulation is just a little bit different from software emulation.

> Trying to build an edge-triggered D flop from LUTs
> will fail just as miserably as an attempt to create latches that
> way.  The older TI TTL catalogs had a schematic representation
> of a 7474 flip-flop that consists of 6 3-input NAND gates.  Code
> that up in an FPGA and see what happens...

I believe it will also fail if you build it out of TTL gates.

Some of the schematics in the TTL data book are written with
transistors, others with gates.  Even so, I don't believe that all
that are written with gates can be implemented with actual
separate TTL gates.  And yes, not in an FPGA, either.

-- glen

Article: 157307
Subject: Re: disadvantages of inferring latches
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 18 Nov 2014 14:44:33 -0500
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> GaborSzakacs <gabor@alacron.com> wrote:
> 
> (snip, I wrote)
> 
>>> In computer designs from the 1950's and 1960's, everything
>>> was latch, and they still worked. It takes a lot more transistors
>>> to make an edge-triggered master-slave FF, and transistors
>>> were expensive! 
>  
> (snip)
> 
>> The point of this thread isn't really that there's an inherent
>> problem with latches.  The issue is that FPGA's aren't designed
>> to create asynchronous sequential logic.  Folding a bunch of
>> 2-input gates from your RTL into a LUT results in a huge change
>> in the timing characteristics of the logic.  Any structure that
>> doesn't already exist in the slice or logic cell gets converted
>> into LUTs.  
> 
> I am at least slightly interested (though I might never get 
> around to) recreating old designs in FPGA logic.  Hardware
> emulation is just a little bit different from software emulation.
> 
>> Trying to build an edge-triggered D flop from LUTs
>> will fail just as miserably as an attempt to create latches that
>> way.  The older TI TTL catalogs had a schematic representation
>> of a 7474 flip-flop that consists of 6 3-input NAND gates.  Code
>> that up in an FPGA and see what happens...
> 
> I believe it will also fail if you build it out of TTL gates.
> 

No it won't.  It will just be really slow compared to an actual
74xx74 chip of the same TTL family.  Unlike the FPGA where the
gates get lumped together into LUTs, the TTL 3-input NAND gates
will be wired just like the diagram and keep the causality relationship
between inputs and outputs.  You can also make a working flip-flop
using FPGA LUTs as individual 3-input NAND gates, but the tools
will force you to instantiate the LUTs to prevent their being
combined during optimization.

> Some of the schematics in the TTL data book are written with
> transistors, others with gates.  Even so, I don't believe that all
> that are written with gates can be implemented with actual
> separate TTL gates.  And yes, not in an FPGA, either.
> 
> -- glen

Article: 157308
Subject: Re: disadvantages of inferring latches
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 18 Nov 2014 14:48:02 -0500
Links: << >>  << T >>  << A >>
ronhk25 wrote:
> בתאריך יום שני, 17 בנובמבר 2014 11:17:04 UTC+2, מאת ronhk25:
>> Hi all,
>>
>> I always hear from FPGA designers that latches are "dangerous" and that it's very important avoiding them. I wonder what are the technical risks resulting by using latches. As far as I understand, the main problem is that FPGAs don't have built in hard latches so the synthesizer has to implement it from logic blocks and then the race condition in the resulting logic is hard/impossible to be analyzed.
>> Is this main disadvantage latches? are there any other issues regarding latches which shall be considered?
>>
>> Thanks,
>>
>> Ron
> 
> Thank you all for your answers! 
> I would like to clarify- I didn't mean to combinatorial state machines, I meant to a "multi-process synchronous state machine" while the output signals and the next state are assigned in an asynchronic process and the current state is assigned in a synchronous process, i understand that this kind of state machine is defined as synchronous state machine. I'm not experienced with that kind of state machines as in the past I have always used one clocked process in my state machines but in my new job I'm obliged to use the HDL designer graphical tool which generates those "multi-process synchronous state machine". Now, as i wrote, the output signals are assigned in an asynchronous process and in some states i want that some of the outputs will keep their last assigned value. In
> synchronous process this is not a problem since a flip flop is used but in
> asynchronous process an inferred latches might be created.
> 
> Those unintended latches made me open this thread, what are your recommendations to this issue?

Assuming you really want to start editing the output of the
generated code, the way to make this work is to feed the
current state into the next state.  i.e. anything on the
right side of your assignments in the async process needs
to come from the synchronous process.  If something needs
to keep its current value, then you need to assign it to
the flop (in the other process) that holds that previous value.
Assigning it to itself creates a gated latch.

-- 
Gabor

Article: 157309
Subject: Re: disadvantages of inferring latches
From: rickman <gnuarm@gmail.com>
Date: Tue, 18 Nov 2014 15:17:30 -0500
Links: << >>  << T >>  << A >>
On 11/18/2014 11:02 AM, ronhk25 wrote:
> בתאריך יום שני, 17 בנובמבר 2014 11:17:04 UTC+2, מאת ronhk25:
>> Hi all,
>>
>> I always hear from FPGA designers that latches are "dangerous" and that it's very important avoiding them. I wonder what are the technical risks resulting by using latches. As far as I understand, the main problem is that FPGAs don't have built in hard latches so the synthesizer has to implement it from logic blocks and then the race condition in the resulting logic is hard/impossible to be analyzed.
>> Is this main disadvantage latches? are there any other issues regarding latches which shall be considered?
>>
>> Thanks,
>>
>> Ron
>
> Thank you all for your answers!
> I would like to clarify- I didn't mean to combinatorial state machines, I meant to a "multi-process synchronous state machine" while the output signals and the next state are assigned in an asynchronic process and the current state is assigned in a synchronous process, i understand that this kind of state machine is defined as synchronous state machine. I'm not experienced with that kind of state machines as in the past I have always used one clocked process in my state machines but in my new job I'm obliged to use the HDL designer graphical tool which generates those "multi-process synchronous state machine". Now, as i wrote, the output signals are assigned in an asynchronous process and in some states i want that some of the outputs will keep their last assigned value. In
> synchronous process this is not a problem since a flip flop is used but in
> asynchronous process an inferred latches might be created.
>
> Those unintended latches made me open this thread, what are your recommendations to this issue?

If your output has state that means it is part of the state logic rather 
than the output.  If you need to "hold" an output while the rest of the 
state machine has moved on, you are not separating the state from the 
output.

I believe this is the difference between a Mealy and a Moore machine. 
In the Moore machine the output is only a function of state.  In a Mealy 
machine the output is a function of both the state and the input.  But 
in neither case is the output a function of the output.

So if you are getting latches in your output combinatorial logic it is 
because you either didn't code it correctly or you didn't specify it 
correctly.

Then there is a type of machine where the outputs are also registered 
rather than being pure combinatorial logic.  In this case the logic can 
be coded in a synchronous process and no latch will be generated 
regardless.

-- 

Rick

Article: 157310
Subject: Re: disadvantages of inferring latches
From: Les Cargill <lcargill99@comcast.com>
Date: Tue, 18 Nov 2014 20:26:22 -0600
Links: << >>  << T >>  << A >>
rickman wrote:
> On 11/17/2014 7:21 PM, Les Cargill wrote:
>> rickman wrote:
>>> On 11/17/2014 1:30 PM, Les Cargill wrote:
>>>> rickman wrote:
>>>>> On 11/17/2014 4:17 AM, ronhk25 wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I always hear from FPGA designers that latches are "dangerous" and
>>>>>> that it's very important avoiding them. I wonder what are the
>>>>>> technical risks resulting by using latches. As far as I understand,
>>>>>> the main problem is that FPGAs don't have built in hard latches so
>>>>>> the
>>>>>> synthesizer has to implement it from logic blocks and then the race
>>>>>> condition in the resulting logic is hard/impossible to be analyzed.
>>>>>> Is this main disadvantage latches? are there any other issues
>>>>>> regarding latches which shall be considered?
>>>>>
>>>>> It is not that latches are inherently bad.  The problem is that they
>>>>> can
>>>>> be inferred unintentionally.  The only time I remember using a
>>>>> latch in
>>>>> a design was way back when the 8085 CPU was around.  I recall that
>>>>> they
>>>>> multiplexed the address with the data or with itself (upper/lower) and
>>>>> to get the best address setup time a latch was used, 74LS373 rather
>>>>> than
>>>>> the 74LS374 register.  The address would flow through ahead of the
>>>>> edge
>>>>> of the clock that would hold it giving more address setup time.
>>>>>
>>>>> I believe that most programmable logic will implement latches ok.  I'm
>>>>> not sure what race condition you are referring to.  The only problem I
>>>>> can see is that if you use them in the wrong place they will let
>>>>> signals
>>>>> flow through successive latches rather than holding like registers
>>>>> will
>>>>> do.  Oh yes, the static timing analysis program is incapable of
>>>>> calculating any timing analysis on them, so that is a real problem.
>>>>>
>>>>> I have never needed a latch in any HDL design I have worked on.  Do
>>>>> you
>>>>> see a use for latches in your design?
>>>>>
>>>>
>>>> When you present registers to be consumed or manipulated by a
>>>> microprocessor ( say, memory mapped ) , are those what you are calling
>>>> registers, or are  they latches?
>>>>
>>>> Or is it "could go either way"?
>>>>
>>>> It's been a while but I remember them being a register with some
>>>> different attributes form, a purely internal register.
>>>
>>> I can't say I understand your question on several points.  I don't know
>>> what it means to "consume" a register.
>>>
>>> The definition of a register is a storage element that is edge sensitive
>>> while a latch is level sensitive.
>>
>>
>> I think that actually answered my question - it could be either
>> depending on how you wanted it to work.
>>
>>> Assert the enable of a latch and it
>>> passes the data input to the output.  When the enable is removed it
>>> remembers the last value on the output.  A register output is only
>>> affected by sampling the data input on the clock edge (rising or falling
>>> but not both) and presenting it to the output.
>>>
>>
>> So basically, a register latches on a clock edge.
>>
>>> In light of that can you rephrase your question?
>>>
>>
>>
>> Suppose we have a memory mapped segment on a CPU that "goes to" a
>> register bank in an FPGA. Are those bits latches/latched or not,
>> or are they a mix?
>
> I'm still not grasping the question.  The issue of being memory mapped
> is not related to whether the memory is implemented as latches or
> registers.  There are at least two issues here.
>
> One is how you code the "memory".  If you code it as a latch it will be
> a latch.  The other is how such logic is actually implemented in the
> FPGA.  If you just code memory (all such memory and other storage
> elements in an FPGA are edge triggered and so really are registers
> technically) how do they actually implement the memory in the FPGA?  I
> don't know for sure.  I see mention of 6 transistor RAM being the
> standard elements in processors for static memory, I expect that is also
> what they use for FPGA memories (not the registers used in the logic
> fabric).  Then they likely fake the interface to work like a register or
> actually put registers in the address/data path and synthesize the
> timing controls for the RAM array invisibly to the user.
>

Right!

> I remember when they stopped providing static RAM from the LUTs and made
> it edge sensitive.  They had too many users who sucked at designing with
> async memory (which works like latches) and so just made it look like
> sync memory (which looks like registers).  The info they provided
> basically said this was async memory with a faked out interface and they
> synthesized the write strobe for you.
>
> Lol, I hope that isn't too confusing.
>

NO, that is great. I appreciate you taking the time - it's just 
something I always wondered. And right now, I am doing a project where 
it made me wonder more - how do you you make sure the interface is 
stable? I ended up basically burying it in a device driver so that at 
least CPU interrupts were off.

This isn't an FPGA; it's a simulated FPGA. So I can read or write to the 
"memory" atomically. I was gonna do it with a mechanism like System V 
shared memory, but I wasn't sure this had the right ... atomicity of 
read/write. It smelt like a Heisenbug waiting to happen.

Apologies for the inability to actually ask the question properly -
but I think the salient distinction is "edge triggered" vs. "level 
sensitive". The rest follows from that.

-- 
Les Cargill


Article: 157311
Subject: Re: disadvantages of inferring latches
From: rickman <gnuarm@gmail.com>
Date: Wed, 19 Nov 2014 02:17:56 -0500
Links: << >>  << T >>  << A >>
On 11/18/2014 9:26 PM, Les Cargill wrote:
> rickman wrote:
>> On 11/17/2014 7:21 PM, Les Cargill wrote:
>>> rickman wrote:
>>>> On 11/17/2014 1:30 PM, Les Cargill wrote:
>>>>> rickman wrote:
>>>>>> On 11/17/2014 4:17 AM, ronhk25 wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I always hear from FPGA designers that latches are "dangerous" and
>>>>>>> that it's very important avoiding them. I wonder what are the
>>>>>>> technical risks resulting by using latches. As far as I understand,
>>>>>>> the main problem is that FPGAs don't have built in hard latches so
>>>>>>> the
>>>>>>> synthesizer has to implement it from logic blocks and then the race
>>>>>>> condition in the resulting logic is hard/impossible to be analyzed.
>>>>>>> Is this main disadvantage latches? are there any other issues
>>>>>>> regarding latches which shall be considered?
>>>>>>
>>>>>> It is not that latches are inherently bad.  The problem is that they
>>>>>> can
>>>>>> be inferred unintentionally.  The only time I remember using a
>>>>>> latch in
>>>>>> a design was way back when the 8085 CPU was around.  I recall that
>>>>>> they
>>>>>> multiplexed the address with the data or with itself (upper/lower)
>>>>>> and
>>>>>> to get the best address setup time a latch was used, 74LS373 rather
>>>>>> than
>>>>>> the 74LS374 register.  The address would flow through ahead of the
>>>>>> edge
>>>>>> of the clock that would hold it giving more address setup time.
>>>>>>
>>>>>> I believe that most programmable logic will implement latches ok.
>>>>>> I'm
>>>>>> not sure what race condition you are referring to.  The only
>>>>>> problem I
>>>>>> can see is that if you use them in the wrong place they will let
>>>>>> signals
>>>>>> flow through successive latches rather than holding like registers
>>>>>> will
>>>>>> do.  Oh yes, the static timing analysis program is incapable of
>>>>>> calculating any timing analysis on them, so that is a real problem.
>>>>>>
>>>>>> I have never needed a latch in any HDL design I have worked on.  Do
>>>>>> you
>>>>>> see a use for latches in your design?
>>>>>>
>>>>>
>>>>> When you present registers to be consumed or manipulated by a
>>>>> microprocessor ( say, memory mapped ) , are those what you are calling
>>>>> registers, or are  they latches?
>>>>>
>>>>> Or is it "could go either way"?
>>>>>
>>>>> It's been a while but I remember them being a register with some
>>>>> different attributes form, a purely internal register.
>>>>
>>>> I can't say I understand your question on several points.  I don't know
>>>> what it means to "consume" a register.
>>>>
>>>> The definition of a register is a storage element that is edge
>>>> sensitive
>>>> while a latch is level sensitive.
>>>
>>>
>>> I think that actually answered my question - it could be either
>>> depending on how you wanted it to work.
>>>
>>>> Assert the enable of a latch and it
>>>> passes the data input to the output.  When the enable is removed it
>>>> remembers the last value on the output.  A register output is only
>>>> affected by sampling the data input on the clock edge (rising or
>>>> falling
>>>> but not both) and presenting it to the output.
>>>>
>>>
>>> So basically, a register latches on a clock edge.
>>>
>>>> In light of that can you rephrase your question?
>>>>
>>>
>>>
>>> Suppose we have a memory mapped segment on a CPU that "goes to" a
>>> register bank in an FPGA. Are those bits latches/latched or not,
>>> or are they a mix?
>>
>> I'm still not grasping the question.  The issue of being memory mapped
>> is not related to whether the memory is implemented as latches or
>> registers.  There are at least two issues here.
>>
>> One is how you code the "memory".  If you code it as a latch it will be
>> a latch.  The other is how such logic is actually implemented in the
>> FPGA.  If you just code memory (all such memory and other storage
>> elements in an FPGA are edge triggered and so really are registers
>> technically) how do they actually implement the memory in the FPGA?  I
>> don't know for sure.  I see mention of 6 transistor RAM being the
>> standard elements in processors for static memory, I expect that is also
>> what they use for FPGA memories (not the registers used in the logic
>> fabric).  Then they likely fake the interface to work like a register or
>> actually put registers in the address/data path and synthesize the
>> timing controls for the RAM array invisibly to the user.
>>
>
> Right!
>
>> I remember when they stopped providing static RAM from the LUTs and made
>> it edge sensitive.  They had too many users who sucked at designing with
>> async memory (which works like latches) and so just made it look like
>> sync memory (which looks like registers).  The info they provided
>> basically said this was async memory with a faked out interface and they
>> synthesized the write strobe for you.
>>
>> Lol, I hope that isn't too confusing.
>>
>
> NO, that is great. I appreciate you taking the time - it's just
> something I always wondered. And right now, I am doing a project where
> it made me wonder more - how do you you make sure the interface is
> stable? I ended up basically burying it in a device driver so that at
> least CPU interrupts were off.
>
> This isn't an FPGA; it's a simulated FPGA. So I can read or write to the
> "memory" atomically. I was gonna do it with a mechanism like System V
> shared memory, but I wasn't sure this had the right ... atomicity of
> read/write. It smelt like a Heisenbug waiting to happen.
>
> Apologies for the inability to actually ask the question properly -
> but I think the salient distinction is "edge triggered" vs. "level
> sensitive". The rest follows from that.

Ok, glad I could help.

-- 

Rick

Article: 157312
Subject: Re: disadvantages of inferring latches
From: Mike Perkins <spam@spam.com>
Date: Thu, 20 Nov 2014 00:50:15 +0000
Links: << >>  << T >>  << A >>
On 17/11/2014 09:42, rickman wrote:

<snip>

> I have never needed a latch in any HDL design I have worked on.  Do you
> see a use for latches in your design?

I'm surprised at that statement. Have you never used a counter or 
anything else related to a clock or flip-flop?

Perhaps the secret with any HDL is to consider how code will be 
implemented in the hardware?

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 157313
Subject: Re: disadvantages of inferring latches
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Wed, 19 Nov 2014 16:58:38 -0800
Links: << >>  << T >>  << A >>
On Thu, 20 Nov 2014 00:50:15 +0000
Mike Perkins <spam@spam.com> wrote:

> On 17/11/2014 09:42, rickman wrote:
> 
> <snip>
> 
> > I have never needed a latch in any HDL design I have worked on.  Do you
> > see a use for latches in your design?
> 
> I'm surprised at that statement. Have you never used a counter or 
> anything else related to a clock or flip-flop?
> 
> Perhaps the secret with any HDL is to consider how code will be 
> implemented in the hardware?
> 

Rick was using the fairly common distinction of a "latch" to mean a
transparent latch with a level-sensitive gate, and a "register" or
"flip-flop" to mean a storage element that's edge sensitive.

Sorry to be curt, but this thread has spun far too far off into
semantics, and finally just resolved with people agreeing.  We can't go
back down that rabbit hole, all the rabbits have rabies and halitosis.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 157314
Subject: Bypass Xilinx flexlm license check
From: rwr.4f4@gmail.com
Date: Thu, 20 Nov 2014 11:43:50 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,

While I certainly do not condone piracy, and I believe Xilinx should be com=
pensated for their hard work, sometimes it can be handy to run ISE without =
limitations on the range of targetable devices and without having to go thr=
ough the rather annoying 30-day evaluation license generation.

For the purpose of disabling the license checks, install ISE 14.7 (20131013=
) and make sure to create a ~/.Xilinx/Xilinx.lic (can be empty). With a hex=
 editor, open /opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/libSecurity.so (md5: ba=
5974651af72b9296f76e40bc432679) and at offset 0x3EABA, which is the epilogu=
e of Sec_Checkout, replace the two bytes 89 D8 with B0 42 (mov al, 0x42).

The new md5 will be 3d29e8d3c00ea2bb5beb406bcb9df95d. This effectively bypa=
sses te license verification, and restrictions on targetable devices will b=
e lifted.

--rwr

Article: 157315
Subject: Re: Bypass Xilinx flexlm license check
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 20 Nov 2014 17:29:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, November 20, 2014 2:43:56 PM UTC-5, rwr...@gmail.com wrote:
> Hello,
> 
> While I certainly do not condone piracy

So you don't condone piracy, but you enable it instead?  Or am I missing something?


Article: 157316
Subject: Re: disadvantages of inferring latches
From: Mike Perkins <spam@spam.com>
Date: Fri, 21 Nov 2014 01:50:48 +0000
Links: << >>  << T >>  << A >>
On 20/11/2014 00:58, Rob Gaddi wrote:
> On Thu, 20 Nov 2014 00:50:15 +0000
> Mike Perkins <spam@spam.com> wrote:
>
>> On 17/11/2014 09:42, rickman wrote:
>>
>> <snip>
>>
>>> I have never needed a latch in any HDL design I have worked on.  Do you
>>> see a use for latches in your design?
>>
>> I'm surprised at that statement. Have you never used a counter or
>> anything else related to a clock or flip-flop?
>>
>> Perhaps the secret with any HDL is to consider how code will be
>> implemented in the hardware?
>>
>
> Rick was using the fairly common distinction of a "latch" to mean a
> transparent latch with a level-sensitive gate, and a "register" or
> "flip-flop" to mean a storage element that's edge sensitive.

It may be a common distinction among many, but latches in FPGA parlance 
is generally any circuit or code that retains a signal (or level). 
Intended or otherwise.

I also accept that transparent latches are not used as often as any 
other type of 'latch', but there are times when it prudent to use a 
"Write Enable" in its intended manner.


-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 157317
Subject: Re: disadvantages of inferring latches
From: rickman <gnuarm@gmail.com>
Date: Fri, 21 Nov 2014 03:05:15 -0500
Links: << >>  << T >>  << A >>
On 11/20/2014 8:50 PM, Mike Perkins wrote:
> On 20/11/2014 00:58, Rob Gaddi wrote:
>> On Thu, 20 Nov 2014 00:50:15 +0000
>> Mike Perkins <spam@spam.com> wrote:
>>
>>> On 17/11/2014 09:42, rickman wrote:
>>>
>>> <snip>
>>>
>>>> I have never needed a latch in any HDL design I have worked on.  Do you
>>>> see a use for latches in your design?
>>>
>>> I'm surprised at that statement. Have you never used a counter or
>>> anything else related to a clock or flip-flop?
>>>
>>> Perhaps the secret with any HDL is to consider how code will be
>>> implemented in the hardware?
>>>
>>
>> Rick was using the fairly common distinction of a "latch" to mean a
>> transparent latch with a level-sensitive gate, and a "register" or
>> "flip-flop" to mean a storage element that's edge sensitive.
>
> It may be a common distinction among many, but latches in FPGA parlance
> is generally any circuit or code that retains a signal (or level).
> Intended or otherwise.
>
> I also accept that transparent latches are not used as often as any
> other type of 'latch', but there are times when it prudent to use a
> "Write Enable" in its intended manner.

Can you tell us about the last time you used a latch rather than a 
register?

-- 

Rick

Article: 157318
Subject: Re: Bypass Xilinx flexlm license check
From: al.basili@gmail.com (alb)
Date: 21 Nov 2014 16:26:26 GMT
Links: << >>  << T >>  << A >>
Hi rwr,

rwr.4f4@gmail.com wrote:
[]
> While I certainly do not condone piracy, and I believe Xilinx should 
> be compensated for their hard work, sometimes it can be handy to run 
> ISE without limitations on the range of targetable devices and without 
> having to go through the rather annoying 30-day evaluation license 
> generation.

just to get the nomenclature straight:

1. piracy: the act of reproducing someone's else (art) work without 
permission

2. copyright infringement: unauthorized used of a copyrighted material.

3. license: set of permission granted by the licensor to the licensee to 
use a product.

By doing what you are doing you are certainly not promoting piracy, 
since there's no reproduction of any artwork in your 'advise'. 

On the contrary you are suggesting you have more rights than the ones 
the licensor (Xilinx) gave you in the license. (I recall you that you 
accepted the license the very same moment you decided to use their 
software).

The reason why Xilinx issues the license the way it does and copyrights 
their products that way is because they consider that 'running ISE 
without limitations' is affecting negatively their business and they 
want to protect it.

If you really believe you have the rights to 'run ISE without 
limitations' you can post your name and address so that any Xilinx 
representative here on the group may get in touch with you and kindly 
explain what are your rights and what are theirs. Or maybe you can 
simply give them a call and see what they think.

That being said, I strongly discourage anyone in this group to follow 
such practices and stand against such advices.

OTOH if the OP wants to work hard on a GPLed toolchain for fpgas in 
order to really be able to *run it without limitations*, I'd be more 
than happy to promote and contribute to that effort.

Al

Article: 157319
Subject: Re: disadvantages of inferring latches
From: "mnentwig" <24789@embeddedrelated>
Date: Fri, 21 Nov 2014 10:27:25 -0600
Links: << >>  << T >>  << A >>
>> It may be a common distinction among many, but latches in FPGA parlance
is generally any circuit or code that retains a signal (or level). 
Intended or otherwise.

that would mean a register is a latch. I don't think this is the most
common definition (even though it is used sometimes).

Wikipedia quotes the following paragraph

"Sometimes the terms flip-flop and latch are used interchangeably, but
there is a distinction. A latch is transparent during a positive clock,
whereas a FF is only transparent during a brief interval during the clock
transition (edge)."

from 
http://rfic.eecs.berkeley.edu/ee100/pdf/lect24.pdf

which is consistent with my understanding (this isn't supposed to prove
anything, just my opinion).	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 157320
Subject: Re: disadvantages of inferring latches
From: Rob Gaddi <rgaddi@technologyhighland.invalid>
Date: Fri, 21 Nov 2014 09:45:19 -0800
Links: << >>  << T >>  << A >>
On Fri, 21 Nov 2014 01:50:48 +0000
Mike Perkins <spam@spam.com> wrote:

> On 20/11/2014 00:58, Rob Gaddi wrote:
> > On Thu, 20 Nov 2014 00:50:15 +0000
> > Mike Perkins <spam@spam.com> wrote:
> >
> >> On 17/11/2014 09:42, rickman wrote:
> >>
> >> <snip>
> >>
> >>> I have never needed a latch in any HDL design I have worked on.  Do you
> >>> see a use for latches in your design?
> >>
> >> I'm surprised at that statement. Have you never used a counter or
> >> anything else related to a clock or flip-flop?
> >>
> >> Perhaps the secret with any HDL is to consider how code will be
> >> implemented in the hardware?
> >>
> >
> > Rick was using the fairly common distinction of a "latch" to mean a
> > transparent latch with a level-sensitive gate, and a "register" or
> > "flip-flop" to mean a storage element that's edge sensitive.
> 
> It may be a common distinction among many, but latches in FPGA parlance 
> is generally any circuit or code that retains a signal (or level). 
> Intended or otherwise.
> 
> I also accept that transparent latches are not used as often as any 
> other type of 'latch', but there are times when it prudent to use a 
> "Write Enable" in its intended manner.
> 
> 
> -- 
> Mike Perkins
> Video Solutions Ltd
> www.videosolutions.ltd.uk

Any time a synthesis tool has ever thrown a warning about "inferred
latches", it's talking about transparent latches being accidentally
generated inside of combinational code.  It doesn't warn me about the
thousands and thousands of registers that I've put enables on in the
same design, just about

MUX: process(all)
begin
  if sel = "00" then
    Y <= A;
  elsif sel = "01" then
    Y <= B;
  elsif sel = "10" then
    Y <= C;
  end if;
end process MUX;

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 157321
Subject: Re: Program IO 1.2V
From: muzaffer.kal@gmail.com
Date: Fri, 21 Nov 2014 14:41:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Saturday, November 8, 2014 7:06:34 PM UTC-8, stefano....@gmail.com wrote=
:
> Hi, I would like to create a project with FPGA.=20
> I would like to begin with a starter kit, not too expensive, <200$, but I=
 would like to have the possibility to communicate using ios @ 1.2V.
> Which system do you suggest me?

One option is to use Xilinx 7 series FPGAs. And especially if you have expe=
rience with microcontrollers, Zynq is an excellent choice. It gives you dua=
l ARM cores and FPGA on the same chip with 1.2V IO thrown in.
Try the following for inexpensive options: http://digilentinc.com/Products/=
Detail.cfm?Prod=3DZYBO
 http://www.amazon.com/Adapteva-P1601-DK03-Parallella-16-Desktop-Computer/d=
p/B0091UD6TM/ref=3Dsr_1_1?ie=3DUTF8&qid=3D1416609614&sr=3D8-1&keywords=3Dpa=
rallellahttp://www.amazon.com/Adapteva-P1601-DK03-Parallella-16-Desktop-Com=
puter/dp/B0091UD6TM/ref=3Dsr_1_1?ie=3DUTF8&qid=3D1416609614&sr=3D8-1&keywor=
ds=3Dparallella

www.dspia.com

Article: 157322
Subject: Re: Bypass Xilinx flexlm license check
From: "Tomas D." <mailsoc@gmial.com>
Date: Fri, 21 Nov 2014 23:29:18 -0000
Links: << >>  << T >>  << A >>
There were and there are tools to decrypt Xilinx and Altera IP cores, so 
they become regular HDL files. I doubt nobody knew that in this group... 



Article: 157323
Subject: Re: Bypass Xilinx flexlm license check
From: Nikolaos Kavvadias <nikolaos.kavvadias@gmail.com>
Date: Fri, 21 Nov 2014 15:32:49 -0800 (PST)
Links: << >>  << T >>  << A >>
Dear all,

agreeing with alb, this is a license breach issue and not promotion of pira=
ting acts.

> By doing what you are doing you are certainly not promoting piracy,=20
> since there's no reproduction of any artwork in your 'advise'.=20
>=20
> On the contrary you are suggesting you have more rights than the ones=20
> the licensor (Xilinx) gave you in the license.=20

I agree; there is no other point to be made here; accepting a license for a=
 licensable work is a binary decision.

> OTOH if the OP wants to work hard on a GPLed toolchain for fpgas in=20
> order to really be able to *run it without limitations*, I'd be more=20
> than happy to promote and contribute to that effort.

It would be great to see such an effort that many of us would contribute. I=
f you are looking into a logic synthesis open-source project with a lot of =
potential, I would suggest YOSYS (http://clifford.at/yosys/) by Clifford Wo=
lf. Clifford does a great job in filtering out multiple and contradicting u=
ser proposals and I think the project progresses well. On some aspects, it =
is already commercial-grade work.


Best regards
Nikolaos Kavvadias
http://www.nkavvadias.com

Article: 157324
Subject: Re: Linux USB JTAG Cable Driver for Xilinx Impact
From: sbattazzo@gmail.com
Date: Fri, 21 Nov 2014 15:38:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, November 6, 2014 3:58:05 PM UTC-8, Ron Aikins wrote:
> I've read much on this topic elsewhere, but I'm confused on some things, =
not to mention some of what I've read is out of date w.r.t. s/w versions, e=
tc. I've been frustrated on a previous attempt to get things going, but am =
now starting with a fresh OS installation and hope to resolve compatibility=
 issues up front.
>=20
> So, I'm running Ubuntu 14.04 and have downloaded but not yet installed Xi=
linx LabTools 14.7. I also have the infamous usb-driver-HEAD.tgz from http:=
//rmdir.de/~michael/xilinx/ but have not yet installed it.
>=20
> First, my OS is 64-bit. In spite of that, do I need to install the 32-bit=
 version of LabTools to be compatible with the usb-driver? From what I've r=
ead, it doesn't sound as though there is a 64-bit version of the driver. Is=
 that true?
>=20
> I'm not sure what runs with what, but need to find out what to do to get =
this running.
>=20
> Would be nice to find a "current" list of installation instructions...
>=20
> Thanks,
> Ron


I have found recently that I didn't need to install that USB driver anymore=
. You should only have to copy the firmware .hex files to the correct place=
 (usually from your Xilinx installation /bin/lin to /usr/share or wherever =
you choose to have them in your .rules file) and install xusbdfw.rules to /=
etc/udev/rules.d and restart udev. The syntax and capitalization sometimes =
need minor adjustments depending which Linux distro you are using. It's bee=
n a while since I messed with this but at some point along the line I reali=
zed this and stopped grabbing and building that USB driver from source.



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

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

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

Custom Search