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 72675

Article: 72675
Subject: SOC and ASIC ?
From: muthusnv@yahoo.co.in (Muthu)
Date: 28 Aug 2004 04:00:47 -0700
Links: << >>  << T >>  << A >>
Hi,

Can any help me out to understand, how does SOC differs from ASIC ?

-Muthu.

Article: 72676
Subject: Re: 16-depth FIFO and 64-depth FIFO use the same Ram
From: Marc Randolph <mrand@my-deja.com>
Date: Sat, 28 Aug 2004 07:14:42 -0500
Links: << >>  << T >>  << A >>
bonetiger wrote:
> Hi,
> 
> I generated two FIFOs using Xilinx ISE CoreGen.
> 
> Both FIFOs are 64-bit wide, but one FIFO depth is 16, the other is 64.
> 
> After doing the mapping, I was surprised to find that both FIFOs use the same amount of BlockRam.
> 
> I cannot understand the reason since the 16-depth FIFO will definately use less memory than the 64-depth FIFO.
> 
> Please give some idea about this. Thanks.


Surely this isn't homework.  Memory is only available in certain widths 
and certain depths.  If you exceed either of those two, more memories 
will have to be used, even if the first one is not fully utilized.  Your 
wide bus is the limiting factor here, not the depth or the total number 
of bits used.

Have fun,

    Marc

Article: 72677
Subject: Re: 16-depth FIFO and 64-depth FIFO use the same Ram
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Sat, 28 Aug 2004 09:59:33 -0400
Links: << >>  << T >>  << A >>
On Fri, 27 Aug 2004 21:39:14 -0700, bonetiger wrote:

> Hi,
> 
> I generated two FIFOs using Xilinx ISE CoreGen.
> 
> Both FIFOs are 64-bit wide, but one FIFO depth is 16, the other is 64.
> 
> After doing the mapping, I was surprised to find that both FIFOs use the same amount of BlockRam.
> 
> I cannot understand the reason since the 16-depth FIFO will definately use less memory than the 64-depth FIFO.
> 
> Please give some idea about this. Thanks.

XST tends to use block ram even when it doesn't need to. In the 16 deep
FIFO use a directive to force it to use LUT RAMs. The example below has
directives for both XST and Precision, the // synthesis is XST, the //
pragma is Precision. 

   reg [WIDTH-1:0]    ram[15:0];
   // synthesis attribute ram_style of ram is distributed
   // pragma attribute ram block_ram false

For the 64 deep FIFO block RAM is the better choice. For depths of 16 the
trade off between LUT Ram and Block RAM is that LUT RAMs are generally
faster and easier to place, Block RAMs are cheaper. The minimum depth of
the Block RAMs is 512, (512x36), so if you are using them for FIFOs you
might as well make them 512 deep.


Article: 72678
Subject: Re: Channel Link signals into Xilinx
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Sat, 28 Aug 2004 07:31:15 -0700
Links: << >>  << T >>  << A >>
Hi Steven,

It would appear from this article that the designer used another chipset to
do the Camera Link interface and not the IO pins of the Virtex directly.
This is contrary to what I am thinking about.
However, considering what you are saying, it does seem possible that the
link can be done directly with either Virtex or Spartan3 IOs, although I
haven't found anybody to tell me that they actually have.
>
> Both Virtex-II Pro and Spartan-3 support LVDS signals.  I don't have a
> Spartan-3 specific design but here's an example of one such product using
> Virtex-II.
> http://www.transtech-dsp.com/fpga/custom_mod_exam.asp
>
> Essentially, Channel Link is a 7:1 LVDS interface with a 66 MHz input
clock.
> Use the CLKFX and CLKFX180 outputs from a DCM.  Set the CLKFX_MULTIPLY=7,
> CLKFX_DIVIDE=2.  Use DDR flip-flips and LVDS input or output buffers for
> either the input (receiver) or output (transmitter).  66 MHz * 7/2 * 2X
> (DDR) = 462 Mbps.
>
> ---------------------------------
> Steven K. Knapp
> Applications Manager, Xilinx Inc.
> General Products Division
> Spartan-3/II/IIE FPGAs
> http://www.xilinx.com/spartan3
> ---------------------------------
> Spartan-3:  Make it Your ASIC



Article: 72679
Subject: Counter counting on both clock edges.
From: Andrew Rogers <andrew@_NO_SPAM_rogerstech.co.uk>
Date: Sat, 28 Aug 2004 15:33:47 +0100
Links: << >>  << T >>  << A >>
I'm trying to produce a square wave clock that is a fifth of the 
frequency of a faster clock. This means that I must use both the falling 
edge and rising of the clock. XST complains "Signal cnt cannot be 
synthesized, bad synchronous description.", I have since learned that I 
can only have one event per process.

How do I produce a counter that counts on both clock edges?

Regards
Andrew



entity div5 is
   port (
     clk : in  std_logic;
     q   : out std_logic);
end div5;

architecture div5_arch of div5 is
   signal cnt : std_logic_vector (2 downto 0) := "000";

begin
   process (clk)
   begin
     if(clk'event and clk = '0')then
       if(cnt = "110") then
         cnt <= "000";
       else
         cnt <= cnt + 1;
       end if;
     end if;
     if(clk'event and clk = '1')then
       if(cnt = "010") then
         cnt <= "100";
       else
         cnt <= cnt;
       end if;
     end if;
   end process;
   q         <= cnt(2);
end div5_arch;

-- 
Spartan3 configuration JTAG download tool for GNU/Linux available from
http://www.rogerstech.co.uk/xc3sprog/


Article: 72680
Subject: how can I simulate the vhdl and verilog mixed design in modelsim?
From: "Jimmy" <mljiang@eee.hku.hk>
Date: Sat, 28 Aug 2004 22:40:57 +0800
Links: << >>  << T >>  << A >>
Hi, all ,

    I am using ISE6.2 and modelsim5.8b. My design is composed of two
modules, one is VDHL design ,and the other is verilog design. Now I want to
combine them together in a top level file (in vhdl) and simulate the whole
design. Can I just instantiate the verilog design module with a compoenent
in the top file and write a testbench for the top file.
    I have done this , but it fails when binding the verilog module
(rx_backend).
# ** Failure: Default binding had errors for entity 'rx_backend' on the
component declaration of line 220. See the compiler messages.
    Could u give any idea on how to do the mixed vhdl and verilog design and
simulation?
    Many thanks.

Jimmy



Article: 72681
Subject: Re: SOC and ASIC ?
From: Javier Castillo <jcastillo@opensocdesign.com>
Date: Sat, 28 Aug 2004 15:47:56 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hello:

A SOC is a System On Chip and is independent of where you implement it, a 
FPGA a ASIC or wherever you want. An ASIC one of the possible ways to 
implement the SOC.

Regards

Javier Castillo
jcastillo@opensocdesign.com
www.opensocdesign.com





muthusnv@yahoo.co.in (Muthu) wrote in news:4f8e807b.0408280300.129f3088
@posting.google.com:

> Hi,
> 
> Can any help me out to understand, how does SOC differs from ASIC ?
> 
> -Muthu.


Article: 72682
Subject: Re: Counter counting on both clock edges.
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 28 Aug 2004 12:12:41 -0400
Links: << >>  << T >>  << A >>
Andrew Rogers wrote:
> 
> I'm trying to produce a square wave clock that is a fifth of the
> frequency of a faster clock. This means that I must use both the falling
> edge and rising of the clock. XST complains "Signal cnt cannot be
> synthesized, bad synchronous description.", I have since learned that I
> can only have one event per process.
> 
> How do I produce a counter that counts on both clock edges?
> 
> Regards
> Andrew
> 
> entity div5 is
>    port (
>      clk : in  std_logic;
>      q   : out std_logic);
> end div5;
> 
> architecture div5_arch of div5 is
>    signal cnt : std_logic_vector (2 downto 0) := "000";
> 
> begin
>    process (clk)
>    begin
>      if(clk'event and clk = '0')then
>        if(cnt = "110") then
>          cnt <= "000";
>        else
>          cnt <= cnt + 1;
>        end if;
>      end if;
>      if(clk'event and clk = '1')then
>        if(cnt = "010") then
>          cnt <= "100";
>        else
>          cnt <= cnt;
>        end if;
>      end if;
>    end process;
>    q         <= cnt(2);
> end div5_arch;

This program is trying to describe something that can not be built using
standard elements found inside an FPGA.  Instead of trying to think in
VHDL, try thinking in terms of the logic.  Forget the code for a moment
and figure out what logic would be generated to do what you want.  

I can think of three ways to do what you want.  One is to use a clock
that is twice the frequency (generated in a PLL/DLL in the FPGA).  Your
design is a bit unusual in that you do different things on the rising
and falling edges of the original clock.  You will need to reference
this clock to distinguish the two actions.  

A second way is to use both a rising edge triggered register and a
falling edge register, each a function of the other.  Your logic will
need to change from what you have above.  

The third is to use two registers, but one logic path with a MUX in the
front to switch registers as required by your function definition.  

Since this is a very odd function to be implementing as part of a job, I
assume it is a homework assignment.  So I won't give any more
details...  But the main idea is to use VHDL to describe your logic...
*AFTER* you have figured out what it must be.  Don't try to code your
problem without having a solution in mind.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 72683
Subject: Re: Counter counting on both clock edges.
From: "mep" <mpe@metanic.dk>
Date: Sat, 28 Aug 2004 19:38:14 +0200
Links: << >>  << T >>  << A >>
Hi Andrew
In real hardware the trick is to use a 5-stage shift register with an
inverter between the output of the last stage and the input of the first
stage. This should be easy to implement in VHDL.
Mogens Pelle

"Andrew Rogers" <andrew@_NO_SPAM_rogerstech.co.uk> skrev i en meddelelse
news:4130963b$1_1@127.0.0.1...
> I'm trying to produce a square wave clock that is a fifth of the
> frequency of a faster clock. This means that I must use both the falling
> edge and rising of the clock. XST complains "Signal cnt cannot be
> synthesized, bad synchronous description.", I have since learned that I
> can only have one event per process.
>
> How do I produce a counter that counts on both clock edges?
>
> Regards
> Andrew
>
>
>
> entity div5 is
>    port (
>      clk : in  std_logic;
>      q   : out std_logic);
> end div5;
>
> architecture div5_arch of div5 is
>    signal cnt : std_logic_vector (2 downto 0) := "000";
>
> begin
>    process (clk)
>    begin
>      if(clk'event and clk = '0')then
>        if(cnt = "110") then
>          cnt <= "000";
>        else
>          cnt <= cnt + 1;
>        end if;
>      end if;
>      if(clk'event and clk = '1')then
>        if(cnt = "010") then
>          cnt <= "100";
>        else
>          cnt <= cnt;
>        end if;
>      end if;
>    end process;
>    q         <= cnt(2);
> end div5_arch;
>
> -- 
> Spartan3 configuration JTAG download tool for GNU/Linux available from
> http://www.rogerstech.co.uk/xc3sprog/
>



Article: 72684
Subject: Re: Counter counting on both clock edges.
From: jakespambox@yahoo.com (Jake Janovetz)
Date: 28 Aug 2004 16:36:46 -0700
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in message news:<4130AEF9.BF3AD39D@yahoo.com>...
> Since this is a very odd function to be implementing as part of a job, I
> assume it is a homework assignment.  So I won't give any more
> details...

I see this sort of answer a lot on this forum and, while I agree that
we don't need to be doing someone's homework, do we really need to
make this sort of statement?  It's condescending and really
unnecessary.  If you don't want to give details, just leave them out. 
Let's give folks the benefit of the doubt and maybe we won't scare
people away.

I -have- had to implement this sort of thing as part of a job (more
than once, in fact).  Another way to do this (depending on what you
really need) is to construct a /10 signal, delay it by 2.5 cycles
(using a neg-triggered FF) and XOR it with the undelayed version.

If the freq. of the input is high enough to allow you to use the
on-chip DLL (if you're using an FPGA with one), many DLLs will do a
divide-by-5.

   Jake

Article: 72685
Subject: Re: Counter counting on both clock edges.
From: "Robert Sefton" <rsefton@abc.net>
Date: Sat, 28 Aug 2004 17:46:54 -0700
Links: << >>  << T >>  << A >>
"mep" <mpe@metanic.dk> wrote in message
news:4130c30c$0$287$edfadb0f@dread14.news.tele.dk...
> Hi Andrew
> In real hardware the trick is to use a 5-stage shift register with an
> inverter between the output of the last stage and the input of the first
> stage. This should be easy to implement in VHDL.
> Mogens Pelle
>

Mogens -

That gives you a /10, not /5 (assuming you start with all 5 FFs in the same
state).

But he could use your 5-stage shift register + inverter if he initialized it
to "00011". Then delay the shift register output (any stage will work) 1/2
cycle and OR it with the undelayed output to create a 50% duty cycle /5
clock.

Without a 2x clock I don't think there's any way to avoid a 1/2 cycle delay
someplace plus a gate. Another poster (Jake) suggested a /10 signal delayed
2 1/2 cycles then XORed with the undelayed output. Same idea.

RJS



Article: 72686
Subject: Re: 6.1 vs. 6.2
From: john.l.smith@titan.com (John)
Date: 28 Aug 2004 18:45:03 -0700
Links: << >>  << T >>  << A >>
Mike Treseler <mike_treseler@comcast.net> wrote in message > 
> *Simulation* is an alternative to logic analysis.
> For synchronous designs, a functional sim and
> Xilinx static timing are all the chipscope you need.

(Mike, I generally respect your posts, this one bears comment)

If this were true, Chipscope would probably not exist.

Let's hypothesize some numbers (someone with better knowledge of
simulator performance please correct me on the first point)

1) A simulator (even a cycle based one) on a moderately complex design
may run about 10e5 times slower than the actual circuit. E.g., a 100
MHz FPGA might simulate at about 1 KHz, 1 ms/cycle. This number is
just a crude estimate, assumes 10e4 nodes in a circuit, 10e2 cycles
per node processing time for the simulator, and the simulator cycling
a 1 GHz. (I think this is optimistic, does anyone have a good number?)

2) State machines can be extremely complex, with "billions _of_
billions" of states. Remember, a processor executing code is really a
state machine, where state corresponds to [program counter, register
contents, pipeline states, even memory contents]. For that matter, the
whole FPGA can be viewed as a single state machine...but I won't get
that outrageous.

Assume three state machines, A, B and C (each of which has already
been thoroughly proven) each with only 10000 states each (tiny pieces
of code running on simple processors, with very few variables
perhaps), and a set of 10 external inputs. Further assume that an
error condition corresponds to a small subset of the trillions of
possible states (bit x of variable X on processor A is '1' while bit y
of variable Y on processor B is '0' and bit z of variable Z in
processor C is '0', causing the rocket engine to shut down or
whatever).

Now make the biggest, wildest assumptions of all:

3) A totally brilliant (omniscient?) test bench writer produces code
that puts the system through every possible state. (Unlikely, but
possible...there are some smart people out there), and produces this
code in under a month.

4) Each of the 10e12 states of the hypothetical machine can be reached
in a single simulator cycle (even more unlikely than 3).

So we have: 10e12 states at 10e-3 seconds per state giving 10e9
seconds to perform the simulation... umm, that's 31.7 years.

Meanwhile, a day of testing the actual circuit on the testbed turns up
the failure.

OK, I hear sputtering on comp.arch.fpga...from both sides...

"Someone didn't do enough higher level system analysis, the system
designer should be shot"

"It's the programmer's fault, shoot him"

"Only 10e12 states? I've got 50 different inputs to worry about, let
alone internal states. Shoot me"

So shoot down my example, you can probably come up with a better one.
The point is (echoing Jeff Goldlum, "Jurassic Park" ran last week) any
sufficiently complex system will have unforseen failure modes.
Simulation (even "formal verification") cannot catch them. When the
failure occurs, it is nice to have visibility into the circuit, be it
Chipscope or handrolled test circuitry.

Forget about Brian's BlockRAM example, Mike's arbitration answer takes
care of that. Here where I work, programmers tend to use logic
analysis as much as the H/W types do, to monitor bus activity (who
said what to whom, and when?). My designs involve video processing,
which can be quicker to implement and look at than to try to simulate.
If I understand O.P., he's in the same position.

To all c.a.f, sorry for the B/W, I haven't posted anything lately. I
just hate hearing "simulation is all you need". For small simple
circuits that is true; for larger systems, the more tools the better
(till you end up spending more time learning the tools than actually
producing). Apologies Mike if I took your statement out of context.
You are 100% right about regression, but not every corner can be
forseen, and often the data outweighs the simulator. I don't use
timing sim either (although the x-men posts leave me wondering if I'll
have to)...

Regards,
John

Article: 72687
Subject: Re: using GNU to compile for PPC405?
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Sat, 28 Aug 2004 23:04:50 -0400 (EDT)
Links: << >>  << T >>  << A >>
I know this.
For reasons I dont want to get into I cant use EDK.  so i wanted to 
compile with a mostly standard gnu tool chain install.

Thanks

Matt

On Fri, 27 Aug 2004, Peter Ryser wrote:

> EDK ships with GNU tools.
>
> - Peter
>
>
> Matthew E Rosenthal wrote:
>> Has anybody out there had any luck using GNU tools to compile source code 
>> into an ELF file that can be loaded into an ISE or EDK project?
>> 
>> is it possible? easy?
>> 
>> Thanks
>> 
>> Matt
>
>

Article: 72688
Subject: Nios Development Kit, STRATIX Edition
From: yudhvir@hawaii.edu (Gabru)
Date: 28 Aug 2004 22:23:10 -0700
Links: << >>  << T >>  << A >>
Hey Guys,

I have this "development Suite" and am wondering if it is worth
anything, I'd like to sell it. If it isn't I'd like to know which
deserving group I should donate it to. Thanks for any comments.

*  Nios Embedded Processor, Documentation and Reference Designs
*  Nios development Board
	- Stratix EP1S10 Device
	- One 10/100 Ethernet and One CompactFlash Connector
	- Two RS-232 Ports
	- 1-Mbyte SRAM, 16-Mbyte Single-Data Rate (SDR) SDRAM and 8-Mbyte
Flash Memory
	- Mictor Trace/Debug Connector and Expansion Prototype Headers
*  Quartus II Design Software with SOPC Builder System Development
Tool
*  GNUPro Toolkit:  Software Development Suite
*  Power Supply and Cables

Article: 72689
Subject: Re: X propagation in Timing Simulation
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 28 Aug 2004 22:31:21 -0700
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:

> Most people fake their way around this by replacing the first
> FF model in the resynchroniser with a FF model that doesn't
> propagate X. 

Another way is to have the testbench 
fake synchronized stimulus for the 
"unsynchronized" inputs.

This allows a functional test of the
untainted synthesis code or netlist.

    -- Mike Treseler

Article: 72690
Subject: Re: 6.1 vs. 6.2
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 28 Aug 2004 23:44:20 -0700
Links: << >>  << T >>  << A >>
John wrote:

> Mike Treseler <mike_treseler@comcast.net> wrote in message >
>> *Simulation* is an alternative to logic analysis.
>> For synchronous designs, a functional sim and
>> Xilinx static timing are all the chipscope you need.
> (Mike, I generally respect your posts, this one bears comment)

Yes, it is a bit overweening. Maybe I should have said: 

For synchronous designs, a functional sim and static timing
can cover at least as much ground as logic analysis.

> If this were true, Chipscope would probably not exist.

Chipscope exists because a significant percentage
of fpga designers already understand and can make
good use of logic analysis to debug designs.

> So we have: 10e12 states at 10e-3 seconds per state giving 10e9
> seconds to perform the simulation... umm, that's 31.7 years.
> Meanwhile, a day of testing the actual circuit on the testbed turns up
> the failure.
> 
> OK, I hear sputtering on comp.arch.fpga...from both sides...

No sputtering here.  
Simulation can't cover every fpga
code defect. Certainly testing continues 
on the bench and at alpha and beta sites.
And almost certainly, the fpga designer
will be fingered with a defect or two.

When this happens, you either fire up
a sim and try duplicate the problem
or configure a logic analyzer and try
and trigger on it. It's a matter of
personal preference. When you're under
the gun, you go with what you know best.

> To all c.a.f, sorry for the B/W, I haven't posted anything lately. I
> just hate hearing "simulation is all you need".

If that's how it sounded to you, I apologize.
My intention was to voice the minority opinion
that simulation can be just as useful 
as logic analysis.

Thanks for the posting.

  -- Mike Treseler


Article: 72691
Subject: EDK core wrapping and include files
From: Rudolf Usselmann <russelmann@hotmail.com>
Date: Sun, 29 Aug 2004 14:40:47 +0700
Links: << >>  << T >>  << A >>

Hi !

we are wrapping some of our IP Cores for EDK. That way they
can be automatically instantiated in to a SoC and easily
integrated.

However, we seem to have problems with include files. Our
cores are written in Verilog, and we don't know how to
specify the proper include path for include files. When
EDK compiles the IP Core it can not find the include files
unless we manually copy them to a local working directory.

Does anybody know how to solve this problem ?

Thanks,
rudi               
=============================================================
Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis


Article: 72692
Subject: Re: problem with DDR
From: vinodece@yahoo.co.in (vinod)
Date: 29 Aug 2004 03:14:30 -0700
Links: << >>  << T >>  << A >>
Brian,
Actually i mean if d is input port and data is coming to it at double
data rate.
in my code q1 and q2 are signals which takes data from d on risng and
falling edges respectivley. ie. data in d on rising edge of clk shud
come to q1(on falling edge of clk) and similarly data in d on falling
edge of clk shud come to q2(on next rising edge of clk). timing
diagram for input DDR is shown in this link.. page no : 225

http://direct.xilinx.com/bvdocs/userguides/ug002.pdf


i am getting functional simulation correct but not gate level.. ie.
data in d on rising edge of clk getting to q1 on same rising edge
itself.similarly for q2.
i think u can once simulate it and check it..


thank you
vinod









Brian Philofsky <brian.philofsky@no_xilinx_spam.com> wrote in message news:<cgnl64$d3i2@xco-news.xilinx.com>...
> Vinod,
> 
>     I do not fully understand your problem but I can guess that you may 
> be having issues with order of events in the simulator other than what 
> you are expecting.  Try to offset your input stimulus from the clock so 
> that the two do not happen at the same time to see if that makes things 
> clearer as to how the logic operates.  In other words try changing your 
> input stimulus to change 1 ns after the clock edge and see if the 
> results look more as you would expect.
> 
> 
> --  Brian
> 
> 
> vinod wrote:
> 
> > Brian Philofsky,
> > Thank u for ur response..i made changes in my stimulus as u told
> > stimuli : process 
> > begin 
> > wait for 20 ns;
> > reset <= '1';
> >  
> > wait for 120 ns;
> > reset <= '0';
> > 
> >  
> >  
> > wait;
> > end process stimuli;
> >  and i made simulation once again but @180 ns the rising edge data '0'
> > of d comes to q1 in same rising edge ..actually it shud come at
> > falling edge.. it is correct in functional simulation... i am getting
> > same wrong result even if I used IFFDDRSE primitive .
> > 
> > can u check this plz..
> > 
> > thank u
> > vinod
> > 
> > 
> > Brian Philofsky <brian.philofsky@no_xilinx_spam.com> wrote in message news:<412E568B.9020503@no_xilinx_spam.com>...
> > 
> >>Vinod,
> >>
> >>I would guess that the reason you are seeing a functional difference 
> >>would be due to the fact that you are not waiting until the global 
> >>set/reset signal to complete.  For all Xilinx gate-level simulations, a 
> >>global set/reset pulse is generated for the first 100 ns of the design 
> >>to initialize all of the registers and simulate the effect for the GSR 
> >>signal in simulation.  For the first 100 ns of the design, the registers 
> >>will be in reset and will not change value.  If you hold off you 
> >>stimulus for the first 100 ns of simulation (keep your clock running and 
> >>initialize the inputs but just don't wiggle them yet), you will likely 
> >>see more correlation between your behavioral and post-translate simulation.
> >>
> >>Also, if you are desiring to have the DDR register pulled into the I/O 
> >>and use the dedicated resource, you should be instantiating the IFDDRRSE 
> >>in the design.  The code you are creating will use two separate 
> >>registers but not the dedicated DDR registers in the I/O.
> >>
> >>
> >>--  Brian
> >>
> >>
> >>vinod wrote:
> >>
> >>
> >>>i am vinod..i got problem with ddr for virtex2 fpga. i have written
> >>>code and did functional simulation everything is correct but after
> >>>post translate simulation i am not getting same result. here is my
> >>>code and testbench
> >>>
> >>>code: 
> >>>library ieee; 
> >>>use ieee.std_logic_1164.all; 
> >>>library UNISIM;
> >>>use UNISIM.VCOMPONENTS.ALL;
> >>>
> >>>entity input_ddr is 
> >>>Port ( d : in std_logic; 
> >>>reset : in std_logic;
> >>>clk : in std_logic; 
> >>>dataoutx : out std_logic;
> >>>dataouty : out std_logic
> >>> ); 
> >>>end input_ddr; 
> >>>
> >>>architecture input_ddr_arch of input_ddr is 
> >>> 
> >>>
> >>>signal q1, q2 : std_logic; 
> >>> 
> >>> 
> >>>
> >>>begin 
> >>> 
> >>> 
> >>> 
> >>>
> >>>process (clk,d,reset) 
> >>>begin 
> >>>
> >>>if reset = '1' then
> >>>  q1 <= '0';
> >>>  dataoutx <= '0';
> >>>
> >>>elsif  rising_edge(clk) then 
> >>>q1 <= d; 
> >>>dataoutx <= q1;
> >>>end if; 
> >>>end process; 
> >>>
> >>>process (clk,d,reset)
> >>>begin 
> >>>if reset = '1' then
> >>> q2 <= '0';
> >>> dataouty <= '0';
> >>>elsif  falling_edge(clk)  then 
> >>>q2 <= d; 
> >>>dataouty <= q2;
> >>>end if; 
> >>>end process; 
> >>>
> >>> 
> >>>
> >>>end input_ddr_arch; 
> >>>
> >>>testbench....
> >>>library ieee; 
> >>>use ieee.std_logic_1164.all;  library ieee;
> >>>use ieee.std_logic_1164.all;
> >>>use ieee.numeric_std.all;
> >>>use IEEE.STD_LOGIC_1164.ALL;
> >>>use IEEE.STD_LOGIC_ARITH.ALL;
> >>>use IEEE.STD_LOGIC_UNSIGNED.ALL;
> >>>library UNISIM;
> >>>use UNISIM.VCOMPONENTS.ALL;
> >>>
> >>>entity tbddr is
> >>>end entity tbddr;
> >>>
> >>>architecture test2 of tbddr is
> >>>component  input_ddr is 
> >>>Port ( d : in std_logic; 
> >>>reset : in std_logic;
> >>>clk : in std_logic; 
> >>>dataoutx : out std_logic;
> >>>dataouty : out std_logic
> >>> ); 
> >>>end component ; 
> >>> 
> >>>
> >>>component FDDRRSE is
> >>>port (
> >>>
> >>>Q : out STD_ULOGIC;
> >>>C0 : IN STD_ULOGIC;
> >>>C1 : IN STD_ULOGIC;
> >>>CE  :IN STD_ULOGIC;
> >>>D0 : IN STD_ULOGIC;
> >>>D1 : IN STD_ULOGIC;
> >>>R  :IN STD_ULOGIC ;
> >>>S : IN STD_ULOGIC
> >>>);
> >>>end component;
> >>>
> >>> 
> >>> 
> >>>signal risdatax,faldatax : std_ulogic;
> >>>signal dataoutx,dataouty : std_logic;
> >>>signal count : natural range 0 to 15;
> >>>--signal cnt : natural range 0 to 40;
> >>>signal ind : std_logic;
> >>>signal S,R,cE :std_logic;
> >>> 
> >>>signal data : std_ulogic_vector(15 downto 0):="1101000111010101";
> >>>signal data1 : std_ulogic_vector(15 downto 0):= "1001011100011100";
> >>>--signal data2: std_ulogic_vector(15 downto 0):= "0010100111001011";
> >>>signal clk,invclk,  reset :std_logic;
> >>>signal clk2 ,d : std_logic;
> >>>begin
> >>>
> >>>--clk2 <= not  clk;
> >>>
> >>>
> >>>uut1: input_ddr
> >>>port map (
> >>> d   => d,
> >>> clk  => clk,
> >>>reset => reset,
> >>>dataoutx => dataoutx,
> >>>dataouty => dataouty
> >>>  
> >>> 
> >>>);
> >>>
> >>>
> >>>FDDRRSEx : FDDRRSE
> >>>port map (
> >>>
> >>>Q => d,
> >>>C0 => clk,
> >>>c1 => invclk,
> >>>CE => ce,
> >>>
> >>>d0  => risdatax,
> >>>d1 =>  faldatax,
> >>>r => '0',
> >>>s => '0'
> >>>);
> >>>
> >>> 
> >>> 
> >>>clock1 : process
> >>>begin
> >>> clk <= '1';
> >>> invclk <= '0';
> >>>wait for 10 ns;
> >>>
> >>>clk <= '0';
> >>>invclk <= '1';
> >>>wait for 10 ns;
> >>>end process;
> >>>
> >>>stimuli : process 
> >>>begin 
> >>>wait for 20 ns;
> >>>reset <= '1';
> >>> 
> >>>wait for 40 ns;
> >>>reset <= '0';
> >>>
> >>> 
> >>> 
> >>>wait;
> >>>end process stimuli;
> >>>
> >>>process(clk,reset,ind)
> >>>begin 
> >>>  if reset  = '1' then
> >>>    count <= 0;
> >>>	 ce <= '0';
> >>>	 risdatax <= '0';
> >>>	 faldatax <= '0';
> >>>elsif clk'event and clk = '1' then
> >>>  
> >>> ce <= '1';
> >>>  risdatax <= data(count);
> >>>  faldatax <= data1(count);
> >>>  if count < 15 then
> >>>  count <= count+1;
> >>>   elsif count = 15 then
> >>>	  count <= 0;
> >>>  end if;
> >>>  end if;
> >>>  
> >>> end process;
> >>>end test2;
> >>>
> >>>
> >>>
> >>>i have used FFDDRSE primitive in testbench for generating double data
> >>>rate.
> >>>
> >>>i will be waiting for reply...
> >>>
> >>>thanks in advance
> >>>bye

Article: 72693
Subject: Re: 6.1 vs. 6.2
From: Philip Freidin <philip@fliptronics.com>
Date: Sun, 29 Aug 2004 11:57:06 GMT
Links: << >>  << T >>  << A >>
On Fri, 27 Aug 2004 22:25:38 GMT, Simon <news@gornall.net> wrote:

>>> Someone wrote:
>>>
>>> Actually in the newer BlockRAM implementations, you can choose the 
>>> behaviour (at least you can on the Spartan-3, whose datasheets I've 
>>> been poring over recently :-)
>>>
>>> There's:
>>>
>>>   o READ_FIRST, which will always report the value of the data
>>>     in RAM before the write was committed

Which means: If you write to Port A, at address Y, with data Z,
the prior contents of location Y will be latched on the port A
output. Location Y will be set to Z.

If Port B is looking at some address other than Y, the behavior
is as expected. If port B is set to address Y, and the clocks
occur at the appropriate time, and Port B is enabled, you might
not get what you expect. I describe exactly what happens below.

>>>   o WRITE_FIRST, which will provide the unpredictable behaviour
>>>     you mention (and it's the default, to provide backwards
>>>     compatibility)

Which means: If you write to Port A, at address Y, with data Z,
the Z be latched on the port A output. Location Y will be set to Z.

If Port B is looking at some address other than Y, the behavior
is as expected. If port B is set to address Y, and the clocks
occur at the appropriate time, and Port B is enabled, you might
not get what you expect. I describe exactly what happens below.

>>>   o NO_CHANGE, which seems to disconnect the output RAM so the
>>>     output value remains unchanged.

Which means: If you write to Port A, at address Y, with data Z,
Location Y will be set to Z. Port A output latch will not be changed.

If Port B is looking at some address other than Y, the behavior
is as expected. If port B is set to address Y, and the clocks
occur at the appropriate time, and Port B is enabled, you might
not get what you expect. I describe exactly what happens below.

>>> I doubt anything would help you if you simultaneously write into the 
>>> same address on both ports, though :-)

This is called "you get what you deserve mode"

>> Brian Philofsky wrote:
>> This is a mis-conception many fall into.  Those modes apply only to the 
>> port that is being written to.  In other words, the output of the port 
>> being written has this known behavior you specify above but as for the 
>> other port, everything I said still applies regardless of which mode you 
>> have it in.

I believe this is not quite the full story. The write mode causes some
changes in the internal timing sequence of a port, and when exactly the
RAM is updated. The write mode on the other port has no affect on the timing
of a read on that port. The following describes how the internal timing
sequence on the write port can affect the read on the other port, IF it is
using exactly the same clock, enable, and address.

>Hmm, well XAPP463 (Using BlockRAM in spartan3 FPGA's) seems to cope with 
>both ports, or am I misunderstanding what you are saying ?

The problem is that this APP note does not express reality well.

>I'm looking at the table (table 8) on page 14, and it's laid out as:
>
>  Write mode     Same Port   Other port (dual port only, same addr)
>-------------------------------------------------------------------
>  WRITE_FIRST    blah        Invalidates data on DO,DOP
>  READ_FIRST     blah        Data from RAM to DO,DOP
>  NO_CHANGE      blah        Invalidates data on DO,DOP
>
>
>I thought it was clear, but now I'm confused :-(

I hope the following will un-confuse you, and give you understanding.

Here is the "truth"

1) The two ports are totally independent, except for the array
   of storage bits.

2) There is no contention detection logic, or address match logic. So
   there is no way for the block RAM to "know" that both ports are
   accessing the same location.

3) The 3 different write modes do not have identical internal timing
   and this leads to behavior that may surprise you if you didn't
   know this.

4) If the two clocks are asynchronous, you can not predict what will
   happen on the other port, when writes and reads are close to each
   other, and addresses match. If you care about reliable systems,
   there should be system level things you should have done so that
   this can never occur.

So what follows, is for the very special case of:

A) both ports are using the same clock
     (if not, nothing can be predicted)
B) both ports are enabled
     (if the non writing port is not enabled, then nothing changes
      on its output regardless of address. Remember, the ports are
      totally independent)
C) port A is writing, port B is reading (or the other way round)
     (if neither are writing, then nothing special is going on.
      if both are writing, either it is to different address
      and nothing special about that, or they are writing to the
      same address, and you need a new system designer)
D) both ports have the same address
     (if not same address, nothing special to think about)

Block RAMS take time to write data. Block RAMS take time to read
data. Reading and writing involves address decoding, data propagation,
write select lines, sense amplifiers for reading, timing control logic.

To write, latch the address, data, enable. Decode address, select the
word, distribute the data on the bit lines, strobe the word write logic.

To read, latch address, enable. Decode address, select the word,
enable contents to be driven from the RAM bits onto the bit lines, use
the sense amps to read the bit lines, latch the sensed data into the
output latch.

Between read and write, the address latch and decode logic is obviously
shared, and that is not an issue because the reads and writes use them
the same way. The bit lines are a different story.

Here is the timeline for Read and the 3 write modes:

READ:		decode address, drive RAM onto bit lines, use sense amps
		to read bit lines, update output latch.

WRITE_FIRST:	decode address, distribute write data, strobe data into RAM
		drive RAM onto bit lines (no change), use sense amps
		to read bit lines, update output latch.

READ_FIRST:	decode address, drive RAM onto bit lines, use sense amps
		to read bit lines, update output latch, distribute write
		data, strobe data into RAM

NO_CHANGE:	decode address, distribute write data, strobe data into RAM


READ and READ_FIRST have the same read timing. The read timing for
WRITE_FIRST is different.

WRITE_FIRST and NO_CHANGE have the same write timing. The write timing
for READ_FIRST is different.

Now lets look at the table 8 from the APP note, but first, lets look at
the prior paragraph:

"These different modes determine which data is available on the output
latches after a valid write clock edge to the same port."

underline "same port"

"In READ_FIRST mode, a memory port supports simultaneous read and write
operations to the same address on the same clock edge, free of any
timing complications."

Place a little asterisk after "free of any timing complications".

At the bottom of the page, put another asterisx, and follow it with a
link to this article.

"Table 8 outlines how the WRITE_MODE setting affects the output data
latches on the same port, and how it affects the output latches on the
opposite port during a simultaneous access to the same address."

underline "during a simultaneous access".  This means: Exactly the same
clock, and enable. Go back and read (4) above.

OK, here we go.

>I'm looking at the table (table 8) on page 14, and it's laid out as:
>
>  Write mode     Same Port   Other port (dual port only, same addr)
>-------------------------------------------------------------------
>  WRITE_FIRST    blah        Invalidates data on DO,DOP

Port A writes, port B reads same address, identical clocks.
port B is using READ timing (see above) which assumes that RAM contents
are stable. WRITE_FIRST is writing to the RAM at this time, so bits are
in transition. Port B sees anything between old contents, new contents,
or a mix of both. The read and write timing are "self timed" so no
predictions can be made as to which happens first. Rather than say
"Invalidates" it would have been better to say "unpredictable"

>  READ_FIRST     blah        Data from RAM to DO,DOP

Port A does the late write, so the port A read first occurs at the same
time as the port B read, so the data has not yet changed at the time
when port B is reading, so it gets the old contents, same as port A.

>  NO_CHANGE      blah        Invalidates data on DO,DOP

Port A writes, port B reads same address, identical clocks.
port B is using READ timing (see above) which assumes that RAM contents
are stable. NO_CHANGE is writing to the RAM at this time, so bits are
in transition. Port B sees anything between old contents, new contents,
or a mix of both. The read and write timing are "self timed" so no
predictions can be made as to which happens first. Rather than say
"Invalidates" it would have been better to say "unpredictable"

You can see all the gory details by going to http://patft.uspto.gov
and looking at US 6,373,779
  "Block RAM having multiple configurable write modes for use in a
   field programmable gate array "

Figure 5 is READ
Figure 6 is WRITE_FIRST
Figure 7 is NO_CHANGE
Figure 8 is READ_FIRST


This will be on the final exam.

Philip Freidin



===================
Philip Freidin
philip.freidin@fpga-faq.com
Host for WWW.FPGA-FAQ.COM

Article: 72694
Subject: Re: using GNU to compile for PPC405?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Sun, 29 Aug 2004 22:06:20 +1000
Links: << >>  << T >>  << A >>
Hi Matthew,

Matthew E Rosenthal wrote:

> I know this.
> For reasons I dont want to get into I cant use EDK.  so i wanted to 
> compile with a mostly standard gnu tool chain install.

I recently used Dan Kegel's crosstool to build a power PC toolchain, 
then used that tool chain to build a PPC linux kernel targeted for a 
V2Pro device.  Alas I don't have a dev board to test it (ml300 reference 
platform), but the initial signs were good.

The ppc compiler distributed with edk is gcc-powerpc-eabi - it should be 
easy to use crosstool to build this toolchain.  I don't have enough 
experience with the V2Pro PPC core to say if there are any special 
tricks in the EDK version.


Regards,

John

Article: 72695
Subject: Re: EDK core wrapping and include files
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Sun, 29 Aug 2004 22:12:18 +1000
Links: << >>  << T >>  << A >>
Hi Rudi,

Rudolf Usselmann wrote:

> we are wrapping some of our IP Cores for EDK. That way they
> can be automatically instantiated in to a SoC and easily
> integrated.

Good plan!  I would love to see a wishbone -> opb bridge to get some of 
that great opencores.org stuff into microblaze projects.

> However, we seem to have problems with include files. Our
> cores are written in Verilog, and we don't know how to
> specify the proper include path for include files. When
> EDK compiles the IP Core it can not find the include files
> unless we manually copy them to a local working directory.
> 
> Does anybody know how to solve this problem ?

Maybe the  .pao (peripheral analyse order) file has something to do with 
it?  It lives in pcores/mycore/data/...  I've only used it for VHDL 
cores, but it probably has a role to play with verilog as well.

Hope this hepls,

John

Article: 72696
Subject: Re: 6.1 vs. 6.2
From: Simon <news@gornall.net>
Date: Sun, 29 Aug 2004 13:53:03 GMT
Links: << >>  << T >>  << A >>
Philip Freidin wrote:
>
 > On Fri, 27 Aug 2004 22:25:38 GMT, Simon <news@gornall.net> wrote:
>>
>>I thought it was clear, but now I'm confused :-(
> 
> 
> I hope the following will un-confuse you, and give you understanding.

Thanks Philip, most illuminating :-)

> This will be on the final exam.

[grin] I did my finals more years ago than I care to remember, but I'm 
always keen to learn something new :-)

[aside]
Up until now I've always used single-clock designs, so there was an 
implicit assumption in my post that the clocks/enables were identical on 
both ports. It's the signs down the multiple-clock path that put me off, 
you know, the ones saying "Abandon hope, all ye who enter here", and 
"Here be Dragons". I think the blood dripping onto the path is a little 
melodramatic though :-)
[/aside]

Simon.

Article: 72697
Subject: Floorplanner RPM question
From: Simon <news@gornall.net>
Date: Sun, 29 Aug 2004 14:07:09 GMT
Links: << >>  << T >>  << A >>
I noticed that there's the capability in the floorplanner to create an 
RPM from a floorplanned design.

I tried floorplanning some of the lower-level modules, and then saving 
them into the [module].ucf file, but the higher-level modules (those 
that instantiate the lower ones :-) didn't seem to pick up on the RPM 
availability.

Is there something I have to do in the high-level module to tell ISE to 
use the RPM ? I'm using verilog and XST if that matters ?

Cheers,
	Simon.



Article: 72698
Subject: Re: Xilinx in Linux
From: Brian Dam Pedersen <brian.pedersen@mail.danbbs.dk>
Date: Sun, 29 Aug 2004 16:26:57 +0200
Links: << >>  << T >>  << A >>
ted wrote:
> Hi,
> 
> Does anyone know if it's possible to run the Xilinx ISE 4.2i software in
> Linux?  I would like to develop VHDL code and then program my FPGA (I use a
> parallel port JTAG programmer).  Being able to do this from Linux would make
> the project easier as I need to develop a Linux device driver at the same
> time.  I was thinking I could use WINE.  Do any websites with instructions
> exist?
> 
> Thanks.
> 
> 

Hi

Programming the actual FPGA using JTAGcannot be done from within the ISE 
- you need to find a third-party program to do that under linux, but at 
least ISE 6.x will run under Wine otherwise (mostly). See my page on how 
to do it here:

http://www.danbbs.dk/~kibria/xilinx.html

I don't know if this applies fro 4.2 also - but you can always give it a 
  try. Hope it helps.

-- Brian




Article: 72699
Subject: Re: Impact vs. Linux RedHat Linux
From: "Alex Gibson" <me@privacy.net>
Date: Mon, 30 Aug 2004 01:19:10 +1000
Links: << >>  << T >>  << A >>

"Rudolf Usselmann" <russelmann@hotmail.com> wrote in message 
news:cgpi22$lkk$1@nobel.pacific.net.sg...
> Stephen Williams wrote:
>
>> Brad Smallridge wrote:
>>> Maybe it's one of those spaces in the path names problems disguised as
>>> path too long.
>>
>> Might be.
>>
>> Have I mentioned yet that I hate this Wind/U atrocity?-)
>>
>
> I have to jump in here !
>
> This Wind/U crap is made by some sort of a third party, to
> "easy" "porting" of windows applications to unix like systems.
>
> I can't see the usability of any GIUs made with this Wind/U
> stuff. Did anybody try to use EDK on Linux ? C'mon, I am
> trying to get a job done not finding out alternative ways
> to use a mouse and a keyboard.
>
> Great to see the results from the Wind/U "porting" tools.
> Don't have to bother evaluating or trying it out for any
> of our projects - what a piece of crap !!!
>
> If Xilinx could find an alternative to this Wind/U, I think
> they would have an excellent tool flow for Linux (plus fixing
> the paralle port support to something native of course).
>

Well if they ever need a cross platform gui
they should look at wxwidget (was wxwindows )
http://www.wxwindows.org/
available for windows , linux and mac ox
as well as support for x,  gtk+ , motif

for some screenshots follow the links
http://www.wxwindows.org/screensh.htm

for a list of users which includes AMD , AOL , Green Mountain(VHDL Studio), 
ING (Bank),
Lockheed Martin, Ecos, Scitech , Xerox and others
http://www.wxwindows.org/users.htm

for a list of applications writen using it
http://www.wxwindows.org/apps.htm

wxperl  http://wxperl.sourceforge.net/
wxpython http://wxpython.org
are bindings for those languages

Probably take a bit / while to rewrite  but to have one
common main project  would make it easier to
support multiple platforms.


Alex 





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