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 138400

Article: 138400
Subject: Re: VHDL long elsif state machine
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Thu, 19 Feb 2009 23:23:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
> On Feb 18, 5:39 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
> wrote:
> 
>> Dear FPGA group,
>> 
>> I have a state machine done with one flag for each state.
>> Most of the states are sequential accomplished with a default
>> assignment:
>> signal state : std_logic_vector(0 to 61);
>> begin
>> if(clk'event and clk='1')then
>> state<='0'&state(0 to 60);
>> etc.
>> There are some variations to this sequential flow.
>> Elsewhere I assign data paths to these states like this:
>> if(clk'event and clk='1')then
>> if state(33 to 36)>0 then
>> mem_out<=a;
>> elsif state(37)>0 then
>> mem_out<=b;
>> etc.
>> The elsif are a bit long and have unnecessary priority
>> logic since state(33 to 36) trumps state(37).
>> This happens although I can be very sure that the states
>> are mutually exclusive by design.
>> I am using Xilinx ISE9.2, ModelSim, and an ML402 kit.
>> 
>> I am of the understanding that a series of "if end if" statements
>> would only serve to put the priority on the last "if end if"
>> statement and therefore would still result in a chain of priority
>> logic.
>> 
>> So my question is how to get rid of the priority logic?
>> If I have to resort to a case statement, how do I code
>> this succinctly with this long state vector?
>> And is there some other way to do it,
>> perhaps with a variable?
> Using "one flag for each state" is also called "one-hot" encoding.
> This means N states are encoded with N bits, all mutually exclusive.
> I do this all the time and I prefer to not use IF or CASE statements.
> The logic for each bit in one-hot encoding is very simple.  The bit is
> true if the bit is false AND any of the input conditions are true OR
> if the bit is true AND all of the output transitions are false.  So
> instead of a long case statement or a deep IF statement, you can just
> use a single assignment for each state variable defining each input
> and each output condition...
> if(clk'event and clk='1')then
> if state(33) = '0' then  -- enter this state
> state (33) <= inputA and state(31) or
> inputB and state (32) or
> inputC and state(34);
> else  -- leave this state
> state (33) <= not (inputD or inputE);
> endif;
> if state(34) = '0' then  -- enter this state
> state (34) <= inputD and state(33);
> else  -- leave this state
> state (34) <= not inputE;
> endif;
> if state(35) = '0' then  -- enter this state
> state (35) <= inputD and state(33) or inputE and state(34);
> else  -- leave this state
> state (35) <= not inputF;
> endif;
> ...
> 
> "Good synthesis tools will try to evaluate if all branch
> conditions are mutually exclusive. If they indeed are, the synthesis
> tool will build parallel logic"
> The key here is the term "Good synthesis tools".  That requires you to
> put your faith in the tools, no matter which tools are being used.
> 
> Also, you might want to use descriptive names for the indexes of
> state, such as state (memory_read).
> 
> Rick
> 

It didn't seem like the problem was changing states, as the OP used a simple 
shift for that.  It seems the problem is assigning values to other signals 
based upon the current state.  In VHDL "if else" and "conditional signal 
assignment" statements both technically create priority logic.  On the other 
hand, "case" statements and "selected signal assignment" statements represent 
mux logic (i.e. full and parallel cases).  What you presented above, is coding 
a mux by hand and generates priority logic when the assignment targets in 
any of the if blocks are the same.  For a current research project, I developed 
an algorithm to convert all of VHDL's conditional assignment statements (there 
are four) to a traditional N:1 mux, if anyone wants, I will write the algorithm 
here.  If the OP provides more insight into the actual code I could give 
a more specific answer.


---Matthew Hicks



Article: 138401
Subject: generic parameterised coding:passing of parameters
From: "akshay" <akshayvreddy@gmail.com>
Date: Thu, 19 Feb 2009 17:34:40 -0600
Links: << >>  << T >>  << A >>

Hello all,
This is a very trivial question i have. I was structural coding a memory
module(using verilog) where i have the higher module and two lower modules.
i want the code to be generic and parametrized. Higher module has a
parameter 'n' which I want to pass to the lower module.do i have to pass
this parameter as an input to the lower module or is there any other way?
i know in VHDL we can do !!generic map(m=>m)!! but how do we do that in
verilog. sorry guys i am new to verilog.

Thank you for helping me out.
akshay   

Article: 138402
Subject: Re: generic parameterised coding:passing of parameters
From: Matthew Hicks <mdhicks2@uiuc.edu>
Date: Thu, 19 Feb 2009 23:40:06 +0000 (UTC)
Links: << >>  << T >>  << A >>
module_name #() instance_name() structure works in Verilog.


---Matthew Hicks


> Hello all,
> This is a very trivial question i have. I was structural coding a
> memory
> module(using verilog) where i have the higher module and two lower
> modules.
> i want the code to be generic and parametrized. Higher module has a
> parameter 'n' which I want to pass to the lower module.do i have to
> pass
> this parameter as an input to the lower module or is there any other
> way?
> i know in VHDL we can do !!generic map(m=>m)!! but how do we do that
> in
> verilog. sorry guys i am new to verilog.
> Thank you for helping me out.
> akshay



Article: 138403
Subject: Problem loading my bitstream into the parallel NOR flash using the
From: hokie03 <hokie03@gmail.com>
Date: Thu, 19 Feb 2009 15:45:54 -0800 (PST)
Links: << >>  << T >>  << A >>
I'm having trouble loading my bitstream into the parallel NOR flash
using the indirect method with a Spartan 3A DSP.  So far I've been
able to load the design via JTAG and it works fine.  I've also loaded
the design onto Spartan 3A starter platform which is the layout that
was used as the reference for the new PC board.  The primary
difference is that the starter platform has 1800 while the new board
uses a 3400.  The parallel NOR flash chips used is the RC28F128J3D
from Numonyx (Intel).  When attempting to program the bitstream into
the flash using impact, erasing works, programing works, but verify
fails instantly at offset 0x0.

Not sure why the results are different between the two designs.

Article: 138404
Subject: GTKWave 3.2.0 for Windows is available
From: Muzaffer Kal <kal@dspia.com>
Date: Thu, 19 Feb 2009 16:55:30 -0800
Links: << >>  << T >>  << A >>
Hi everyone,
the latest version of GTKWave (3.2.0) windows binary is available at
here: http://www.dspia.com/gtkwave.html

-- Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services
http://www.dspia.com

Article: 138405
Subject: Re: VHDL long elsif state machine
From: Markus <none@nowhere.org>
Date: Fri, 20 Feb 2009 08:25:39 +0100
Links: << >>  << T >>  << A >>
Matthew Hicks schrieb:
>> On Feb 18, 5:39 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
>> wrote:
>>
>>> Dear FPGA group,
>>>
>>> I have a state machine done with one flag for each state.
>>> Most of the states are sequential accomplished with a default
>>> assignment:
>>> signal state : std_logic_vector(0 to 61);
>>> begin
>>> if(clk'event and clk='1')then
>>> state<='0'&state(0 to 60);
>>> etc.
>>> There are some variations to this sequential flow.
>>> Elsewhere I assign data paths to these states like this:
>>> if(clk'event and clk='1')then
>>> if state(33 to 36)>0 then
>>> mem_out<=a;
>>> elsif state(37)>0 then
>>> mem_out<=b;
>>> etc.
>>> The elsif are a bit long and have unnecessary priority
>>> logic since state(33 to 36) trumps state(37).
>>> This happens although I can be very sure that the states
>>> are mutually exclusive by design.
>>> I am using Xilinx ISE9.2, ModelSim, and an ML402 kit.
>>>
>>> I am of the understanding that a series of "if end if" statements
>>> would only serve to put the priority on the last "if end if"
>>> statement and therefore would still result in a chain of priority
>>> logic.
>>>
>>> So my question is how to get rid of the priority logic?
>>> If I have to resort to a case statement, how do I code
>>> this succinctly with this long state vector?
>>> And is there some other way to do it,
>>> perhaps with a variable?
>> Using "one flag for each state" is also called "one-hot" encoding.
>> This means N states are encoded with N bits, all mutually exclusive.
>> I do this all the time and I prefer to not use IF or CASE statements.
>> The logic for each bit in one-hot encoding is very simple.  The bit is
>> true if the bit is false AND any of the input conditions are true OR
>> if the bit is true AND all of the output transitions are false.  So
>> instead of a long case statement or a deep IF statement, you can just
>> use a single assignment for each state variable defining each input
>> and each output condition...
>> if(clk'event and clk='1')then
>> if state(33) = '0' then  -- enter this state
>> state (33) <= inputA and state(31) or
>> inputB and state (32) or
>> inputC and state(34);
>> else  -- leave this state
>> state (33) <= not (inputD or inputE);
>> endif;
>> if state(34) = '0' then  -- enter this state
>> state (34) <= inputD and state(33);
>> else  -- leave this state
>> state (34) <= not inputE;
>> endif;
>> if state(35) = '0' then  -- enter this state
>> state (35) <= inputD and state(33) or inputE and state(34);
>> else  -- leave this state
>> state (35) <= not inputF;
>> endif;
>> ...
>>
>> "Good synthesis tools will try to evaluate if all branch
>> conditions are mutually exclusive. If they indeed are, the synthesis
>> tool will build parallel logic"
>> The key here is the term "Good synthesis tools".  That requires you to
>> put your faith in the tools, no matter which tools are being used.
>>
>> Also, you might want to use descriptive names for the indexes of
>> state, such as state (memory_read).
>>
>> Rick
>>
> 
> It didn't seem like the problem was changing states, as the OP used a
> simple shift for that.  It seems the problem is assigning values to
> other signals based upon the current state.  In VHDL "if else" and
> "conditional signal assignment" statements both technically create
> priority logic.  On the other hand, "case" statements and "selected
> signal assignment" statements represent mux logic (i.e. full and
> parallel cases).  What you presented above, is coding a mux by hand and
> generates priority logic when the assignment targets in any of the if
> blocks are the same.  For a current research project, I developed an
> algorithm to convert all of VHDL's conditional assignment statements
> (there are four) to a traditional N:1 mux, if anyone wants, I will write
> the algorithm here.  If the OP provides more insight into the actual
> code I could give a more specific answer.
> 
> 
> ---Matthew Hicks
> 
> 
It seems the OP choose a way to implement the state machine efficiently, but
 at the same time, the implementation of the control becomes difficult. Why
doesn't he describe a state machine with symbolic names and tell the
synthesis tool to use one-hot encoding. The case statement to evaluate the
current state is trivial then and can be efficiently translated by the
synthesis tool because it *knows* about the one-hot encoding.

-Markus

Article: 138406
Subject: FPGA Stamp
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 20 Feb 2009 00:07:42 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi

it has nothing todo with Basic Stamps, just the PCB looks like a
stamp, hence the name

http://www.trioflex.com/files/Stamp60-UM.pdf

preliminary user manual is now online. The first stamp is based on
Actel FPGA
and well the user manual maybe some interesting reading - for me it
was surprise
how nice actel tools have become (compared to what they used to be).

it is also interesting that Actel ist the only company offering small
customizeable
Soft-Core fully integrated with their IDE. PicoBlaze is still not
fully officially supported
and probably never will be integrated to Xilinx IDE.

Antti
PS if some is interested i should have some give away units of the
stamp
at Embedded World. meeting at 12-536

Article: 138407
Subject: Re: VHDL long elsif state machine
From: nemo <gnuarm@gmail.com>
Date: Fri, 20 Feb 2009 03:24:06 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 19, 6:23 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote:
> > On Feb 18, 5:39 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com>
> > wrote:
>
> >> So my question is how to get rid of the priority logic?
> >> If I have to resort to a case statement, how do I code
> >> this succinctly with this long state vector?
> >> And is there some other way to do it,
> >> perhaps with a variable?
> > Using "one flag for each state" is also called "one-hot" encoding.
> > This means N states are encoded with N bits, all mutually exclusive.
> > I do this all the time and I prefer to not use IF or CASE statements.
> > The logic for each bit in one-hot encoding is very simple.  The bit is
> > true if the bit is false AND any of the input conditions are true OR
> > if the bit is true AND all of the output transitions are false.  So
> > instead of a long case statement or a deep IF statement, you can just
> > use a single assignment for each state variable defining each input
> > and each output condition...
> > if(clk'event and clk='1')then
> > if state(33) = '0' then  -- enter this state
> > state (33) <= inputA and state(31) or
> > inputB and state (32) or
> > inputC and state(34);
> > else  -- leave this state
> > state (33) <= not (inputD or inputE);
> > endif;
> > if state(34) = '0' then  -- enter this state
> > state (34) <= inputD and state(33);
> > else  -- leave this state
> > state (34) <= not inputE;
> > endif;
> > if state(35) = '0' then  -- enter this state
> > state (35) <= inputD and state(33) or inputE and state(34);
> > else  -- leave this state
> > state (35) <= not inputF;
> > endif;
> > ...
>
> > "Good synthesis tools will try to evaluate if all branch
> > conditions are mutually exclusive. If they indeed are, the synthesis
> > tool will build parallel logic"
> > The key here is the term "Good synthesis tools".  That requires you to
> > put your faith in the tools, no matter which tools are being used.
>
> > Also, you might want to use descriptive names for the indexes of
> > state, such as state (memory_read).
>
> > Rick
>
> It didn't seem like the problem was changing states, as the OP used a simple
> shift for that.  It seems the problem is assigning values to other signals
> based upon the current state.

Yes, I see your point.

> In VHDL "if else" and "conditional signal
> assignment" statements both technically create priority logic.  On the other
> hand, "case" statements and "selected signal assignment" statements represent
> mux logic (i.e. full and parallel cases).  What you presented above, is coding
> a mux by hand and generates priority logic when the assignment targets in
> any of the if blocks are the same.

Yes, you are right.  That is why my code puts all assignments to a
given state variable in a single IF ELSE statement.  But the real
point is that this is very easy to construct from the state diagram.
There is a one to one mapping from each end of the state transition in
the diagram to a term in the state assignments.  This way you can
easily keep your state assignments up to date when you make changes to
the state machine and you can verify that the code and the state
diagram match at any given point, in either direction.

   OutputFoo <= inputA and state(31) or inputB and state(32);
   OutputBar <= inputD and state(33) or inputE and state(34);
   OutputGrr <= state(35) or state(36) or state(37);

It is easy to code the output signals in a similar manner.  Rather
than to put them in conditional statements based on the current state,
I define them by a sum of products for the Mealy machine (each term is
an optional input anded with a state) or just a sum for Moore machines
(list each state where the output is true).  Again there is a one to
one relationship between output notations and the code so that it is
easy to verify as well.  I would keep the state code and the output
code separate since they would not be structured the same.  Depending
on your machine, the above notation may actually be more clear than a
diagram.  Also, these assignments do not need to be in a clocked
process, depending on your design needs.  A true Mealy or Moore
machine would not have the extra register delay.

If you need the outputs registered and don't want to have the extra
clock cycle delay, you can define the states as cur_state and
nxt_state signals with nxt_state defined with concurrent statements or
in a non-clocked process and cur_state defined as registered versions
of nxt_state in a clocked process.  Then you can use the nxt_state
values in your clocked process to assign values to the outputs since
they are essentially a "look ahead" on the cur_state signals.

I tend to think in terms of the hardware and then write code to
generate that hardware.  I don't like to write software and let the
tools try to figure out what I need only to be disappointed.  I don't
think of it as optimizing the code, I think of it as describing the
hardware I want.  I just want the tools to stay out of my way as much
as possible.

Rick

Article: 138408
Subject: Re: ERROR:Map:11 - serdes_4b_1to7_wrapper symbol "rx0" - more than
From: lijia21cn@gmail.com
Date: Fri, 20 Feb 2009 04:06:32 -0800 (PST)
Links: << >>  << T >>  << A >>
On 2=D4=C213=C8=D5, =CF=C2=CE=E76=CA=B113=B7=D6, lijia2...@gmail.com wrote:
> Hi, I suffer from a problem. when I implement the reference design
> from xilinx xapp485, there comes an error after implement the design,
> but I don't know why,can anybody tell me...? thanks in advance,I
> really appreciate your help.
>
> # November 1st 2006
>
> # Timespec should be set to period plus an amount for jitter
> # For example : pixel clock of 90 MHz =3D> high speed clock of 315 MHz
> (3175 pS).
> #               From spreadsheet : jitter is 464 pS
> #               1/(3175 - (0.5*464)) =3D> 340 MHz
>
> net rxclk35 tnm =3D rxclk35 ;
> net rxclk35not tnm =3D rxclk35not ;
> net rxclk tnm =3D rxclk1 ;
>
> timespec tsrx00 =3D period rxclk35 340 Mhz ;
> timespec tsrx01 =3D period rxclk1 tsrx00/3.5 ;
> timespec tsrx02 =3D from rxclk35 to rxclk1 =3D tsrx00/2 ;
>
> # receive clock input 1, bank 0
>
> net "rxclkina1_p" loc =3D "B8" ;              #
> net "rxclkina1_n" loc =3D "B9" ;              #
>
> # channel A lvds inputs - Bank 3
>
> net "dataina_p(3)"  loc =3D "C8" ;    #
> net "dataina_n(3)"  loc =3D "D8" ;    #
> net "dataina_p(2)"  loc =3D "E8" ;    #
> net "dataina_n(2)"  loc =3D "F8" ;    #
> net "dataina_p(1)"  loc =3D "C7" ;    #
> net "dataina_n(1)"  loc =3D "D7" ;    #
> net "dataina_p(0)"  loc =3D "F7" ;    #
> net "dataina_n(0)"  loc =3D "E7" ;    #
>
> inst "rx0" rloc_origin =3D "X18y86" ;
>
> inst "apa0" rloc_origin =3D "X42Y90" ;                                   =
     # Delete or comment this line
> if auto phase alignment is not being used
>
> timespec tsapa00 =3D from ffs(apa0/chfoundc) to ffs(apa0/sm) =3D
> tsrx00/2 ;              # Delete or comment this line if aut

no body knows?

Article: 138409
Subject: Re: GTKWave 3.2.0 for Windows is available
From: chewie <timinganalyzer@gmail.com>
Date: Fri, 20 Feb 2009 06:03:04 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 19, 7:55=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> Hi everyone,
> the latest version of GTKWave (3.2.0) windows binary is available at
> here:http://www.dspia.com/gtkwave.html
>
> -- Muzaffer Kal
>
> DSPIA INC.
> ASIC/FPGA Design Serviceshttp://www.dspia.com

Thanks to Tony Bybell,  this version also exports .tim files for the
TimingAnalyzer so you convert VCD diagrams to timing diagrams.

www.timing-diagrams.com

Thank you for distributing the windows version.



Article: 138410
Subject: Re: GTKWave 3.2.0 for Windows is available
From: Jason Zheng <Xin.Zheng@jpl.nasa.gov>
Date: Fri, 20 Feb 2009 07:32:48 -0800
Links: << >>  << T >>  << A >>
On Fri, 20 Feb 2009 06:03:04 -0800 (PST)
chewie <timinganalyzer@gmail.com> wrote:

> Thanks to Tony Bybell,  this version also exports .tim files for the
> TimingAnalyzer so you convert VCD diagrams to timing diagrams.
> 
> www.timing-diagrams.com
> 
> Thank you for distributing the windows version.
> 

And Thanks to Tony Bybell, he's gtkwave program in GPL-licensed and
freely available. I'm getting tired of your annoying marketing posts.
Please stop or promote your program as an open-sourced program.



Article: 138411
Subject: Re: Troubleshooting fpga design
From: Ehsan <ehsan.hosseini@gmail.com>
Date: Fri, 20 Feb 2009 08:28:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 18, 12:24=A0am, Ehsan <ehsan.hosse...@gmail.com> wrote:
> Hi all,
>
> I've built a fairly large and complex design in VHDL and tried to
> implement it on a Xilinx virtex-4 FX100 fpga. I have verified the
> functionality of my design through the behavioural simulations. After
> that, I decided to implement it on the fpga. I chose a set of inputs
> the same as I used in the behavioural simulations and then run the
> hardware. When I read the outputs, which are some internal registers,
> they match the values read from the simulations. However, sometimes
> the results do not match. In all of these cases, I use the same inputs
> and moreover I reload the bitstream to the fpga to make the situation
> equal. I thought the timing constraints may be violated, so I reduced
> the clock frequency, however, no significant effect can be seen. I can
> conclude that the design is synthesized according to the desired
> functionality, since it generates the desired outputs in some
> instances. However, I cannot understand why it malfunctions
> occasionally for the fixed inputs. What type of errors can lead to
> this problem? What can I do when the error is not repeatable?
>
> My design is basically controlled by an FSM which has 16 states. I
> send the start command and then it goes through all the states and
> finally asserts a done signal. Once the register values are incorrect,
> the done signal is also not set. So, something should stop the FSM
> from moving forward.
>
> Thank you in advance for your comments.

I just used the Chipscope to debug my design. What actually happens is
that the FSM goes to a wrong state in one of the transitions (always
the same). The FSM has 16 states and I designed it using StateCad tool
(included in Xilinx ISE). The FSM has a 4-bit counter, which counts up
every time it goes over the states. In the last state, it checks the
counter value and if it has reached the value of 10, it would go to
the idle state, otherwise it goes to another state and starts another
round. And this is where the error happens: sometimes when the counter
is still less than 10, it goes to the idle state.  The design is
synthesized using XST and the fsm is one-hot encoded.

I'm not sure what I've done wrong. Please let me know if you have any
suggestions.




Article: 138412
Subject: Re: Troubleshooting fpga design
From: LittleAlex <alex.louie@email.com>
Date: Fri, 20 Feb 2009 08:38:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 20, 8:28 am, Ehsan <ehsan.hosse...@gmail.com> wrote:
> On Feb 18, 12:24 am, Ehsan <ehsan.hosse...@gmail.com> wrote:
>
>
>
> > Hi all,
>
> > I've built a fairly large and complex design in VHDL and tried to
> > implement it on a Xilinx virtex-4 FX100 fpga. I have verified the
> > functionality of my design through the behavioural simulations. After
> > that, I decided to implement it on the fpga. I chose a set of inputs
> > the same as I used in the behavioural simulations and then run the
> > hardware. When I read the outputs, which are some internal registers,
> > they match the values read from the simulations. However, sometimes
> > the results do not match. In all of these cases, I use the same inputs
> > and moreover I reload the bitstream to the fpga to make the situation
> > equal. I thought the timing constraints may be violated, so I reduced
> > the clock frequency, however, no significant effect can be seen. I can
> > conclude that the design is synthesized according to the desired
> > functionality, since it generates the desired outputs in some
> > instances. However, I cannot understand why it malfunctions
> > occasionally for the fixed inputs. What type of errors can lead to
> > this problem? What can I do when the error is not repeatable?
>
> > My design is basically controlled by an FSM which has 16 states. I
> > send the start command and then it goes through all the states and
> > finally asserts a done signal. Once the register values are incorrect,
> > the done signal is also not set. So, something should stop the FSM
> > from moving forward.
>
> > Thank you in advance for your comments.
>
> I just used the Chipscope to debug my design. What actually happens is
> that the FSM goes to a wrong state in one of the transitions (always
> the same). The FSM has 16 states and I designed it using StateCad tool
> (included in Xilinx ISE). The FSM has a 4-bit counter, which counts up
> every time it goes over the states. In the last state, it checks the
> counter value and if it has reached the value of 10, it would go to
> the idle state, otherwise it goes to another state and starts another
> round. And this is where the error happens: sometimes when the counter
> is still less than 10, it goes to the idle state.  The design is
> synthesized using XST and the fsm is one-hot encoded.
>
> I'm not sure what I've done wrong. Please let me know if you have any
> suggestions.

Muzaffer Kal has already answered your question.  Read his reply over
and over until you understand it.

John Providenza has answered it in his own way, perhaps describing a
"race condition" as "metastable".  (It's really a race condition.)

Take a look at the logic generated for your state machine.  You will
see a bunch of d-flops, each with their own cloud of logic at the D
input.

Each of these clouds will have a different length.

There will be at least one input that goes through paths (clouds) of
different length.

If the clock to the D-flops happens after the signal propagates (gets
through) the short path, and before it propagates the long path, your
state machine will go to a wonky state.

Welcome to "real world" logic design.

AL

Article: 138413
Subject: Re: Troubleshooting fpga design
From: Gael Paul <gael.paul@gmail.com>
Date: Fri, 20 Feb 2009 10:19:52 -0800 (PST)
Links: << >>  << T >>  << A >>
Ehsan,

To help you further, we could use some more information:
1. Is the last state the only state that checks the counter value?
2. Is the counter running on the same clock as the FSM?
3. Are all other inputs used for the transition from the last stage to
the idle stage on the same clock domain as the FSM?
[This requires extracting the fan-in cone of logic for each last stage
inut and verifying that *every* input of the logic cone is a FF
clocked by the same clock as the FSM]
4. Apart from the counter, is there any other input to your FSM that
is only used in the transition from the last stage back to the idle
stage?
5. Is there a reset for the state register of your FSM?

Finally, why don't you post the code for the last stage only?

Cheers,

 - gael

Article: 138414
Subject: Re: GTKWave 3.2.0 for Windows is available
From: chewie <timinganalyzer@gmail.com>
Date: Fri, 20 Feb 2009 10:35:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 20, 10:32=A0am, Jason Zheng <Xin.Zh...@jpl.nasa.gov> wrote:
> On Fri, 20 Feb 2009 06:03:04 -0800 (PST)
>
> chewie <timinganaly...@gmail.com> wrote:
> > Thanks to Tony Bybell, =A0this version also exports .tim files for the
> > TimingAnalyzer so you convert VCD diagrams to timing diagrams.
>
> >www.timing-diagrams.com
>
> > Thank you for distributing the windows version.
>
> And Thanks to Tony Bybell, he's gtkwave program in GPL-licensed and
> freely available. I'm getting tired of your annoying marketing posts.
> Please stop or promote your program as an open-sourced program.

I thought from previous discusions it would be ok to make
announcements every once in a while,  but now I believe you are right,
and don't want to bother anyone, so I will not make anymore
announcements on the newsgroups.



Article: 138415
Subject: Re: ERROR:Map:11 - serdes_4b_1to7_wrapper symbol "rx0" - more than
From: Andy Peters <google@latke.net>
Date: Fri, 20 Feb 2009 12:21:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 13, 10:13=A0am, lijia2...@gmail.com wrote:
> Hi, I suffer from a problem. when I implement the reference design
> from xilinx xapp485, there comes an error after implement the design,
> but I don't know why,can anybody tell me...? thanks in advance,I
> really appreciate your help.

It would really help if you told us what the error message says.

-a

Article: 138416
Subject: Re: Xilinx ISE complete device IBIS file generation?
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Fri, 20 Feb 2009 16:19:01 -0800
Links: << >>  << T >>  << A >>
Stef wrote:
> Hello,
> 
> Xilinx provides IBIS files for the spartan (and other) devices. In these
> files the IBIS model of each possible IO driver type is given. But because
> the IO can be configured, there is no fixed IBIS for a completed design.
> 
> After P&R, there is a pin mapping file which tells which pin has which
> IO standard and drive strength. Together with the IBIS file per IO type,
> it seems a fairly simple task of generating a specific IBIS file for the
> completed design.
> 
> Is there an option in ISE or a separate tool to generate such an IBIS
> file? The task seems so simple, I'm tempted to try it myself. But that
> would be a waste of effort if the tool already exists. :-) 
> 

Yes, there is a tool within the ISE distribution called IBISWriter that 
does exactly what you want.

Ed McGettigan
--
Xilinx Inc.

Article: 138417
Subject: Very fast counter in VirtexII
From: "Marty Ryba" <martin.ryba.nospam@verizon.net>
Date: Sat, 21 Feb 2009 00:23:55 GMT
Links: << >>  << T >>  << A >>
Hi gang,

    I have an idea for a tweak of my FPGA design that involves essentially 
building a time interval counter. I found that there are some IP cores out 
there that get as much as 100ps resolution, but before I go that route I 
want to experiment with something "free" first, especially since I don't 
need any bells and whistles like embedded bus protocols or programmable 
timers. Neither of the signals I want to time between are synchronous with 
my main clock, so I'm thinking of generating a new DCM just for this purpose 
(I think I have a few left in my XC2V6000-5). Otherwise my fastest clock is 
either 133 MHz or maybe 204.8 MHz coming from an outside clock chip (I might 
be able to goose it to 409.6 MHz).

My question is there any good "how to" on writing a counter so that it runs 
at a maximum clock rate for my chip? I perused the Xilinx site, and there 
were some very old articles on fast counters in antique chip architectures; 
they provide OrCAD macros(?); not even VHDL.

So, do I just naively code the counter and pray that synthesis does the 
right things (I don't need a huge number of bits; my maximum time interval 
is maybe 80 ns), or are there some tricks needed to get optimum clock speed 
(what could I rationally expect in this FPGA?)?

Thanks for your help,

Marty 



Article: 138418
Subject: Re: Very fast counter in VirtexII
From: Allan Herriman <allanherriman@hotmail.com>
Date: 21 Feb 2009 02:07:21 GMT
Links: << >>  << T >>  << A >>
"Marty Ryba" <martin.ryba.nospam@verizon.net> wrote in
news:vQHnl.665$Ez6.422@nwrddc02.gnilink.net: 

> Hi gang,
> 
>     I have an idea for a tweak of my FPGA design that involves
>     essentially 
> building a time interval counter. I found that there are some IP cores
> out there that get as much as 100ps resolution, but before I go that
> route I want to experiment with something "free" first, especially
> since I don't need any bells and whistles like embedded bus protocols
> or programmable timers. Neither of the signals I want to time between
> are synchronous with my main clock, so I'm thinking of generating a
> new DCM just for this purpose (I think I have a few left in my
> XC2V6000-5). Otherwise my fastest clock is either 133 MHz or maybe
> 204.8 MHz coming from an outside clock chip (I might be able to goose
> it to 409.6 MHz). 
> 
> My question is there any good "how to" on writing a counter so that it
> runs at a maximum clock rate for my chip? I perused the Xilinx site,
> and there were some very old articles on fast counters in antique chip
> architectures; they provide OrCAD macros(?); not even VHDL.
> 
> So, do I just naively code the counter and pray that synthesis does
> the right things (I don't need a huge number of bits; my maximum time
> interval is maybe 80 ns), or are there some tricks needed to get
> optimum clock speed (what could I rationally expect in this FPGA?)?

The "naive counter" has no chance of giving you a resolution of better 
than a ns with current FPGA technology.

I'm guessing that most of the IP cores that achieve better than 1ns 
resolution do so by using a wider bus at a lower clock rate, e.g. a 100 
bit bus at 100MHz.  You use logic to locate the bit position on the bus 
where a transition occurs.  Each bit position in this contrived example 
represents 100ps, and each word represents 10ns.

There are two basic ways of turning your 1 bit test signal into a wider 
bus:

1.  Use a SERDES.  Most modern (larger) FPGAs have these built in, either 
as a true transceiver (with PLLs and CDR, etc.), or as a simple SERDES in 
to the IOB.  The most recent FPGAs have on-board SERDES blocks that can 
sample at 100ps intervals.

2.  Use a (different) phase delay for each of the bits, and sample them 
all with the word clock.  This has the advantage that the word clock is 
the highest frequency you need, however getting the phase delays right in 
an FPGA might be tricky.  (This method is better suited to ASIC 
implementations.)

There are some tricks you can use that will get you part way to your 
goal:  
-  Use both clock edges for sampling.  This gives you a 2x speedup (but 
requires a 50% duty cycle clock).
-  Use multiple phases from a DCM or PLL.  This can give you a 4x 
speedup.

Regards,
Allan

Article: 138419
Subject: Re: Troubleshooting fpga design
From: Ehsan <ehsan.hosseini@gmail.com>
Date: Fri, 20 Feb 2009 19:02:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 21, 2:19=A0am, Gael Paul <gael.p...@gmail.com> wrote:
> Ehsan,
>
> To help you further, we could use some more information:
> 1. Is the last state the only state that checks the counter value?
    Yes, this is the only place that checks the counter value.
> 2. Is the counter running on the same clock as the FSM?
> 3. Are all other inputs used for the transition from the last stage to
> the idle stage on the same clock domain as the FSM?
> [This requires extracting the fan-in cone of logic for each last stage
> inut and verifying that *every* input of the logic cone is a FF
> clocked by the same clock as the FSM]

  Yes, the counter and all the inputs to the FSM are running on the
same clock.

> 4. Apart from the counter, is there any other input to your FSM that
> is only used in the transition from the last stage back to the idle
> stage?
   No
> 5. Is there a reset for the state register of your FSM?

  Yes, I have a synchronous reset that brings the FSM to the idle
state. I tried the asynchronous as well, but the same thing happens.

> Finally, why don't you post the code for the last stage only?
>
> Cheers,
>
> =A0- gael

Here is the code for the last stage. As I said earlier the fsm is
generated by StateCad, so the code might not look neat.

WHEN STALL7 =3D>
					IF ( Iter_No0=3D'0' AND Iter_No1=3D'1' AND Iter_No2=3D'0' AND
Iter_No3=3D'1' )
						THEN
						next_sreg<=3DIDLE;
						next_BP_RX_EN<=3D'1';
						next_BP_Iter_Done<=3D'1';
						next_BP_CNP_FirstIter<=3D'1';
						next_BP_CNP_Mode<=3D'0';
						next_BP_CNP_Corr<=3D'0';
						next_BP_CNP_RD_EN<=3D'0';
						next_BP_CTV_START<=3D'0';
						next_BP_VTC_START<=3D'0';
						next_BP_CNP_ACK<=3D'0';
						next_BP_VNP_ACK<=3D'0';
						next_BP_BLK_REQ<=3D'1';

						IF (( BP_VNP_RD_EN=3D'1' )) THEN next_BP_VNP_RD_EN<=3D'1';
						ELSE next_BP_VNP_RD_EN<=3D'0';
						END IF;

						Iter_No <=3D (std_logic_vector'("0000"));
						BP_CNP_Count_Addr <=3D (std_logic_vector'("000000"));
					 ELSE
						next_sreg<=3DSTALL8;

						IF (( BP_BLK_REQ=3D'1' )) THEN next_BP_BLK_REQ<=3D'1';
						ELSE next_BP_BLK_REQ<=3D'0';
						END IF;

						IF (( BP_CNP_ACK=3D'1' )) THEN next_BP_CNP_ACK<=3D'1';
						ELSE next_BP_CNP_ACK<=3D'0';
						END IF;

						IF (( BP_CNP_Corr=3D'1' )) THEN next_BP_CNP_Corr<=3D'1';
						ELSE next_BP_CNP_Corr<=3D'0';
						END IF;

						IF (( BP_CNP_FirstIter=3D'1' )) THEN next_BP_CNP_FirstIter<=3D'1';
						ELSE next_BP_CNP_FirstIter<=3D'0';
						END IF;

						IF (( BP_CNP_Mode=3D'1' )) THEN next_BP_CNP_Mode<=3D'1';
						ELSE next_BP_CNP_Mode<=3D'0';
						END IF;

						IF (( BP_CNP_RD_EN=3D'1' )) THEN next_BP_CNP_RD_EN<=3D'1';
						ELSE next_BP_CNP_RD_EN<=3D'0';
						END IF;

						IF (( BP_CTV_START=3D'1' )) THEN next_BP_CTV_START<=3D'1';
						ELSE next_BP_CTV_START<=3D'0';
						END IF;

						IF (( BP_Iter_Done=3D'1' )) THEN next_BP_Iter_Done<=3D'1';
						ELSE next_BP_Iter_Done<=3D'0';
						END IF;

						IF (( BP_RX_EN=3D'1' )) THEN next_BP_RX_EN<=3D'1';
						ELSE next_BP_RX_EN<=3D'0';
						END IF;

						IF (( BP_VNP_ACK=3D'1' )) THEN next_BP_VNP_ACK<=3D'1';
						ELSE next_BP_VNP_ACK<=3D'0';
						END IF;

						IF (( BP_VNP_RD_EN=3D'1' )) THEN next_BP_VNP_RD_EN<=3D'1';
						ELSE next_BP_VNP_RD_EN<=3D'0';
						END IF;

						IF (( BP_VTC_START=3D'1' )) THEN next_BP_VTC_START<=3D'1';
						ELSE next_BP_VTC_START<=3D'0';
						END IF;

						Iter_No <=3D (( std_logic_vector'(Iter_No3, Iter_No2, Iter_No1,
Iter_No0)
							));
						BP_CNP_Count_Addr <=3D (( std_logic_vector'(BP_CNP_Count_Addr5,
							BP_CNP_Count_Addr4, BP_CNP_Count_Addr3, BP_CNP_Count_Addr2,
							BP_CNP_Count_Addr1, BP_CNP_Count_Addr0)));
					END IF;

Thanks for your helpful comments.

Article: 138420
Subject: Re: Very fast counter in VirtexII
From: -jg <Jim.Granville@gmail.com>
Date: Fri, 20 Feb 2009 19:32:24 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 21, 1:23=A0pm, "Marty Ryba" <martin.ryba.nos...@verizon.net>
wrote:
> Hi gang,
>
> =A0 =A0 I have an idea for a tweak of my FPGA design that involves essent=
ially
> building a time interval counter. I found that there are some IP cores ou=
t
> there that get as much as 100ps resolution, but before I go that route I
> want to experiment with something "free" first, especially since I don't
> need any bells and whistles like embedded bus protocols or programmable
> timers. Neither of the signals I want to time between are synchronous wit=
h
> my main clock

Your title says fast counter, but the text says time interval.
They are not quite the same thing.

If you want to do precise interval timing, then multi-phase capture,
and/or
delay line capture will give you time-domain precisions above the
clock frequency.

What time-precision do you actually need ?
eg 250MHz with 4 phases, resolves to 1ns

I think I read the some of the very newest FPGAs can self-calibrate
their
delay lines, which saves you the trouble

-jg


Article: 138421
Subject: Re: Very fast counter in VirtexII
From: "Michael Brown" <see@signature.below>
Date: Sat, 21 Feb 2009 15:24:50 +1100
Links: << >>  << T >>  << A >>
Note: Since Optus can't figure out how to run a Newsgroup server, the 
original post hasn't appeared for me ...

> Marty Ryba wrote in news:vQHnl.665$Ez6.422@nwrddc02.gnilink.net:
>
>> Hi gang,
>>
>>     I have an idea for a tweak of my FPGA design that involves
>>     essentially
>> building a time interval counter. I found that there are some IP cores
>> out there that get as much as 100ps resolution, but before I go that
>> route I want to experiment with something "free" first, especially
>> since I don't need any bells and whistles like embedded bus protocols
>> or programmable timers.

What sort of resolution and dead time do you need? If you're willing to do a 
bit of legwork with manual place'n'route, and consume a fair bit of 
resources, you can get in the order of 10 ps or so resolution and accuracy 
at the cost of 10's of nanoseconds of dead time. See:
http://www-ppd.fnal.gov/EEDOffice-W/Projects/ckm/comadc/WaveletTDC.ppt
They use an Altera Cyclone II, but I've implemented a similar thing on a 
Spartan 3E with reasonable success. I don't have good enough testing 
apparatus to properly measure the resolution and accuracy though. And at the 
10 ps level, you've got to think a bit about what's on the outside of the 
FPGA too ...

The main downside to the Xilinx parts for this purpose is that you've only 
got 4 elements on the carry chain per block, as opposed to 8 in the Altera. 
You can also tweak out the dead time by throwing more resources at it 
(basically loop the end of the carry chain around to the start where it xors 
with the input, then do edge detection along the whole buffer and track the 
edges). Of course, this is so far beyond the point of "supported" that using 
it in a commercial project is debatable, but it's certainly a fun thing to 
play with.

-- 
Michael Brown
Add michael@ to emboss.co.nz ---+--- My inbox is always open 


Article: 138422
Subject: Re: Logic Analyzer
From: Giuseppe Marullo <giuseppe.marullo@nospaminame.com>
Date: Sat, 21 Feb 2009 22:18:39 +0100
Links: << >>  << T >>  << A >>
Just to update all, with the latest 9 ISE Webpack it does not give any 
error.

Interesting.

Giuseppe Marullo

Giuseppe Marullo wrote:
> Hi  Mike,
> thanks for your email, now I have a bitfile for the 400k, deleting the 
> file worked but I have a failing timing constraint (that disappear with 
> the xc3s200):
> 
> Timing constraint: TS clock1 = PERIOD TI?MEGRP "clock1" TS xtalClock / 2 
> HIGH 50%;
> 
> Could I safely ignore it?
> 
> Sorry to bug all with this, but I can only get the 400k version, and I 
> would buy it specifically to use it as a logic analyzer.
> 
> Giuseppe
> 
> mikep@oakmicros.com wrote:
>>> Thanks, it is a nice gui, still fighting with the VHDL to see if the
>>> 400k board could be used, so far no dice.
>>>
>> I already responded privately to Giuseppe. The fix is to simply delete
>> the la_guide.ncd file (which seems to be a cached output file) and
>> rebuild the map file.
>>
>> Note that the only differences in the Oak Micros version of the
>> download package are:
>> 1. A fix to the la.ucf file that fixes an error message from 10.1 ISE
>> Webpack
>> 2. A "compiled" version of a 10.1 ISE project
>> 3. Added the configuration files needed for downloading the logic
>> analyzer into FPGA development board. I provided this to make it
>> easier for newbies to get started.
>>
>> I'm also investigating (with someone else) some updates to improve the
>> GUI. We are starting from the source both on 
>> http://www.sump.org/projects/analyzer/
>> and the SourceForge project: https://sourceforge.net/projects/jlac/
>>
>> See my User Guide: 
>> http://oakmicros.com/content/downloads/View-document/Logic-Analyzer-User-Guide.html 
>>
>> See my interface board: 
>> http://oakmicros.com/content/omla32-Logic-Analyzer-Interface-Card.html
>>
>> Mike Perks
>> oakmicros.com

Article: 138423
Subject: Re: Very fast counter in VirtexII
From: gabor <gabor@alacron.com>
Date: Sat, 21 Feb 2009 18:13:52 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 20, 10:32=A0pm, -jg <Jim.Granvi...@gmail.com> wrote:
> On Feb 21, 1:23=A0pm, "Marty Ryba" <martin.ryba.nos...@verizon.net>
> wrote:
>
> > Hi gang,
>
> > =A0 =A0 I have an idea for a tweak of my FPGA design that involves esse=
ntially
> > building a time interval counter. I found that there are some IP cores =
out
> > there that get as much as 100ps resolution, but before I go that route =
I
> > want to experiment with something "free" first, especially since I don'=
t
> > need any bells and whistles like embedded bus protocols or programmable
> > timers. Neither of the signals I want to time between are synchronous w=
ith
> > my main clock
>
> Your title says fast counter, but the text says time interval.
> They are not quite the same thing.
>
> If you want to do precise interval timing, then multi-phase capture,
> and/or
> delay line capture will give you time-domain precisions above the
> clock frequency.
>
> What time-precision do you actually need ?
> eg 250MHz with 4 phases, resolves to 1ns
>
> I think I read the some of the very newest FPGAs can self-calibrate
> their
> delay lines, which saves you the trouble
>
> -jg

Virtex 2 doesn't have these structures.  However I remember seeing
appnotes using carry chains as delay elements.  You basically
run your input into the carry chain and then have a flip-flop
at each stage in the chain all running on the master clock.
Ideally your output would look like "1110000000" for a single
transition, allowing you to interpolate between clock cycles.
I think the original appnote was for a serdes using Virtex E,
and the carry chain delay was used for phase adjustment
without the IDELAY elements available in the newer parts.

Regards,
Gabor

Article: 138424
Subject: Re: byteblaster cloning
From: "vhdlguy@gmail.com" <vhdlguy@gmail.com>
Date: Sun, 22 Feb 2009 01:46:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On 1=BF=F930=C0=CF, =BF=C0=C8=C48=BD=C300=BA=D0, colin <colin_toog...@yahoo=
.com> wrote:
> Hello
>
> Has anyone here successfully built abyteblasterclone. I have
> connected up the JTAG pins as specified and Quartus accepts that abytebla=
steris fitted. I can see activity on TCLK, TMS and TDI at the
> FPGA and TDO is getting back to the parallel port but Quartus cannot
> auto detect anything. My system works with a properByteblasterbut I have =
to give it back soon.
>
> Any ideas will be appreciated.
>
> Colin

Hi

Do not waste your time to build the byteblaster. You can get the
byteblaster II with only $24.95
Visit following website. Thanks

http://fpgaguy.110mb.com/



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