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 123800

Article: 123800
Subject: Re: Multiple CPLDs on a PCB.
From: Peter Alfke <alfke@sbcglobal.net>
Date: Tue, 04 Sep 2007 19:16:39 -0700
Links: << >>  << T >>  << A >>
On Sep 4, 6:54 pm, NickNitro <NickHo...@googlemail.com> wrote:
> Hi all,
>
> >>Perhaps in theory, but 'algortihm development' is a very fluid thing, and a good designer allows for late changes.
>
> Well I don't think I've mentioned just how far the algorithm is
> through development, although is it completely designed and has been
> finalised by many people and all have signed it off. It has been
> designed down to the bit level and has been tested in a software
> environment with no flaws (strong words, but every possible scenario
> has been tested through brute forcing, so nothing has been missed); so
> I can safely say the algorithm being altered at this stage won't
> happen.
>
> >>Device retargeting is not difficult.
>
> I've done what you've suggested and had a look at the Xilinx web pack
> and if I've done it correctly, device retargeting seems to be just be
> selecting a different device from the list? Or am I greatly
> oversimplifying to what I imagine?
>
> >>Don't you ever get a new idea after a design has been running for a while?
>
> Very much, although as above, the algorithm is set in concrete.
>
> >>Why would you think that way?  Getting on/off chip is usually slow.
>
> Naivety. ;) I'm coming from a software background, so unfortunately
> I'm relying on software knowledge, where more cores==better
> performance.
>
> >>CPLDs generally have wide inputs relative to LUTs in FPGAs. There are probably some designs that will be faster on CPLDs because they take advantage of that.
>
> I'm afraid I don't have a clue what 'wide inputs' are, but I'll take
> your word at it. ;)
>
> >>even if you have to operate sequentially on 128000 bits
>
> Yes, that's correct.
>
> >>I would also use one of the many existing evaluation boards, which eliminates a lot of work, time, money, and risk.
>
> Thing is, once it's working fine in the FPGA/evaluation board
> environment, I'll still need to move the chip to a custom PCB so it
> has the correct peripherals?
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - - -
>
> Speed is extremley important to this problem, I'm not too worried
> about the difficulty of this - just the final result; since ideally
> execution of the algorithm cannot take more than 15-20 milliseconds. I
> hope you don't think I'm being completely ignorant and rude asking
> this, nor do I want you to think that I don't appreciate your advice -
> although I can't help but think something like the following would be
> faster - I'm stuggling to shake off my software thinking:
>
> http://img529.imageshack.us/img529/9474/cpldlayoutus9.jpg
>
Nick,
you can implement the same (or many other) structure(s) in an FPGA.
You have many hundreds of I/O pins, wide adders and multipliers (if
you need them) and tens of thousands of flip-flops (rather scare
resources in CPLDs). You can have many (hundreds) of independent or
dependent operations going on in the FPGA simultaneously. Don't forget
pipelining to enhance throughput by using many of the "free" flip-
flops...

 But you have to make the decision that you are comfortable with.
Regarding peripherals, you can get them "for free", i.e. without
design effort, in the more sophisticated development boards, like the
Xilinx ML405. That allows you to concentrate on the uniqueness of your
design, and avoid pc-board lay-out, manufacturing and debugging
headaches, for just a few hundred dollars or pounds in your case
Peter Alfke (we are all just trying to preserve your good spirits and
your sanity)


> Where 32 bits would be passed from a 'CPLD Memory Manager' to a 'CPLD
> Parallel Algorithm', and while that was working, another 32 bits would
> be passed from the same 'CPLD Memory Manager' to the next 'CPLD
> Parallel Algorithm', etc... and each 'CPLD Parallel Algorithm' when
> complete would check that the other 'CPLD Memory Manager' was
> available to take data and if so pass it to the memory manager, and
> then asking the first memory manager for some more data.
>
> Again, I apologise for sounding like a broken record. I'd appreciate
> your thoughts for the pros and cons for something like this.
>
> Thanks,
> Nick.



Article: 123801
Subject: Re: PCB Impedance Control
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Tue, 04 Sep 2007 19:42:41 -0700
Links: << >>  << T >>  << A >>
On Tue, 04 Sep 2007 19:45:10 -0000, vasile <piclist9@gmail.com> wrote:

>On Sep 1, 7:44 am, John Larkin
><jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>> On Thu, 30 Aug 2007 15:36:04 +0100, "Symon" <symon_bre...@hotmail.com>
>> wrote:
>>
>>
>>
>>
>>
>> >"maxascent" <maxasc...@yahoo.co.uk> wrote in message
>> >news:ifidnQIYxf3YUUvbRVn_vw@giganews.com...
>>
>> >> Hi
>>
>> >> If I am designing a pcb using impedance controlled layers can I treat the
>> >> power planes as a reference layer as well as the gnd layers?
>>
>> >> Cheers
>>
>> >> Jon
>>
>> >Hi Jon,
>> >Yes. But with a caveat. When your signals switch reference layers, make sure
>> >there is a path for the reference current.
>>
>> >E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal goes
>> >from layer 1 to 6 through a via, you should have a bypass cap bewteen power
>> >and ground near this via.
>>
>> That's not necessary. There's already so much plane-plane capacitance
>> that the planes are already equipotential as far as the tiny charge
>> injected by the signal trace can affect them.
>>
>> Really, on a board with, say, 3000 vias, are you going to put a bypass
>> via near every signal via? I've heard of people asking for two!
>
>If you're routing a long 3Gbps differential signal, then definitely
>you must have ground vias near every signal pair vias.

Why? If the signal is balanced, it needs even fewer vias than a
single-ended signal, which needs none.

John



Article: 123802
Subject: Re: Strange behaviour of a design
From: markus.jank@gmx.de
Date: Tue, 04 Sep 2007 23:04:32 -0700
Links: << >>  << T >>  << A >>
@Kunal
I do synchronisation with the async. signal. Therefore I have to wait
at least two clock cycles after the falling edge of the read strobe.
That is the delay that comes with the synchronisation. So I added two
wait states in the FSM.

I found also a other solution to met the timing requirement. I have to
reduce the clock to output delay of the strobe signal. That can be
achieved by putting the output d-Flip Flop in the IOB.

At the moment the solution with the synchronisation works.







Article: 123803
Subject: Re: Multiple CPLDs on a PCB.
From: Zara <me_zara@dea.spamcon.org>
Date: Wed, 05 Sep 2007 08:18:53 +0200
Links: << >>  << T >>  << A >>
On Tue, 04 Sep 2007 11:08:49 -0700, NickNitro
<NickHolby@googlemail.com> wrote:

<...>
>Hi,
>Finally, could
>anybody recommend any books for getting started in the CPLD world -
>I'm unsure to use Verilog or VHDL at the moment?
>


Take a llok at:
HDL Programming fundamentals, Nazih M. Botros, Da Vinci Enginnering
press.

It is a simultaneous introduction to VHLD and Verilog, so you may
compare pros and cons of both languages easily.

Try both in some FPGA design tool, and decide for yourself.

Best regards,

Zara

Article: 123804
Subject: warning 1780 shown while synthesis, in xilinx 6.3i
From: ankur <ankurrawat0612@gmail.com>
Date: Wed, 05 Sep 2007 00:49:51 -0700
Links: << >>  << T >>  << A >>
hi
 I am designing a generic arbiter .
while synthesis the xilinx tool is giving warning


WARNING:Xst:646 - Signal <inter> is assigned but never used.
WARNING:Xst:1780 - Signal <k> is never used or assigned.

I searched  it out in the solution record
warning 646 can be ignored .
but warning 1780 is displayed in the case of jtag ,so i am not able to
conceive why this is coming.
i have pasted the design below.
thanks for help
ankur

 module  pri_encoder32(inbus,outbus);


  parameter size=9;
  parameter size_1=size-1;
  parameter size_out=4;
  input  [size-1:0]inbus;

  output reg  [size_out-1:0]outbus;


  reg [size_out-1:0]k;
  reg [size_out-1:0]inter;



	always @(inbus)
		begin
			inter=0;
			for (k = size; k >= 1; k = k - 1)
               			begin

                      			if (inbus[k-1]==1)
                                  		begin
                                     			outbus = k-1;
                                     			inter=k-1;
                                   		end
	                      		else
                          			begin
                                     			outbus=inter;
                           			end
                 		end



 		end


endmodule


Article: 123805
Subject: Re: ERROR:NgdBuild:604 with user ipcore
From: "L. Schreiber" <l.s.rockfan@web.de>
Date: Wed, 05 Sep 2007 10:34:24 +0200
Links: << >>  << T >>  << A >>
Paulo Dutra wrote:
> Is your moduleA and moduleB listed in the PAO file?
> If is not listed in the PAO, then it will not synthesized by XST. Xst
> will give a warning that the moduleA and moduleB are black box components.
> 
> Take a looke at you <proj_directory>/synthesis/opb2ip_bridge_0_xst.srp
> This is the syntesis report file for your component. Look for warnings
> regarding moduleA and moduleB.
> 
> L. Schreiber wrote:

Exactly, this was the problem, I found out yesterday late afternoon,
too. :-D

Thanks anyway. So I don't need to write the solution anymore.

Article: 123806
Subject: Re: Multiple CPLDs on a PCB.
From: Mike Harrison <mike@whitewing.co.uk>
Date: Wed, 05 Sep 2007 09:07:27 GMT
Links: << >>  << T >>  << A >>
On Wed, 05 Sep 2007 07:47:40 +1200, Jim Granville <no.spam@designtools.maps.co.nz> wrote:

>NickNitro wrote:
>> Hi,
>> 
>> Apologies if this isn't the best group, but there doesn't appear to be
>> a comp.arch.cpld group.
>> 
>> I'm going to start learning about CPLDs to use them in my projects,
>> but the algorithm I've developed will require a few CPLDs working on
>> different parts of the algorithm in sequence. So part A of the
>> algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. 
>
>Probably not the best direction.
>
>> They
>> are all complete guesses at the moment, as I know next to nothing
>> about PLDs in general, but I know that for my algorithm to run as fast
>> as required, I will require multiple PLDs. I'm choosing CPLDs as from
>> what I've read FPGAs can be a bit overbearing for a beginner due to
>> the amount of features/number of gates they have, 
>
>You do not have to use all features on the first pass :)

More gates means you don't need to worry about squeezing your design to fit, so you can concentrate
on getting it working. 
You can ignore peripherals etc. you don't need, and if you start with one of the many devboards, you
don't need to worry about the more complex multiple power supplies or config devices.
 


Article: 123807
Subject: Re: PCB Impedance Control
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 5 Sep 2007 10:30:13 +0100
Links: << >>  << T >>  << A >>
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
news:aq5sd3p1mttvq1s6kh9dcal265cokucd05@4ax.com...
> On Tue, 04 Sep 2007 19:45:10 -0000, vasile <piclist9@gmail.com> wrote:
>
>>
>>If you're routing a long 3Gbps differential signal, then definitely
>>you must have ground vias near every signal pair vias.
>
> Why? If the signal is balanced, it needs even fewer vias than a
> single-ended signal, which needs none.
>
> John
>
Hi John,

As I'm sure you already know, this is because usually edge coupled signal 
pairs on a PCB are not 'proper' differential pairs the way (say) twisted 
pairs in CAT-5 are. The coupling between each distinct trace and the ground 
plane is much greater than the coupling between the pair of traces 
themselves. This is why Xilinx (and almost everyone else except, apparently, 
you) recommend this GSSG structure when passing high speed differential 
signals through vias. The vias reduce the common mode inductance of the 
transistion, which is, after all, essentially two single ended signals. (In 
fact the via is much more important for a single ended signal than a 
differential one, as a single ended signal is all 'common mode' and the 
ground via significantly reduces transition inductance.)

Today's hilariously bizarre link collection is here
http://www.xilinx.com/bvdocs/userguides/ug076.pdf
http://www.edn.com/contents/images/300022.pdf

Read chapter 11 of UG076, and check out fig.11.10.

BTW., I saw the link you posted to your products. Thanks, they look great. I 
noticed that you chose to put them all in metal boxes or racks. Bearing in 
mind your philosophy on SI, I think that was a wise choice.

Cheers, Syms. 



Article: 123808
Subject: Re: Actel Designer - Specifying multicycle path constraints (via .sdc file) when using synchronous clock enables
From: "HT-Lab" <hans64@ht-lab.com>
Date: Wed, 05 Sep 2007 09:36:04 GMT
Links: << >>  << T >>  << A >>

"David" <spdracer911@gmail.com> wrote in message 
news:1188927341.571209.55110@g4g2000hsf.googlegroups.com...
>
>
> I have a design that uses a 100Mhz system clock, but only a very small
> portion actually runs at 100MHz.  The rest of the FFs in the design
> use a synchronous "clk_10M_en" signal which is active for one clock
> period and repeats every 100ns.  I would like to know how to specify
> the constraints correctly so that Actel Designer (i.e. SmartTime))
> knows "that paths FROM FFs using clk_10M_en TO FFs using clk_10M_en"
> are 100ns paths, not 10ns paths.
>
> It's quiet easy to add a multicycle path constraint on the two
> registers, such as:
>
> set_multicycle_path 10 -from {reg1:CLK} -to {reg2:CLK}
>
> But what I need is a solution that can find these registers when they
> are buried in a hierarchy of modules.  Since they all use clk_10M_en
> as their enable, there should be a way to perform a "find" and then
> set a multicycle path constraint between each regsiter.

Hi David,

You might be able to do it in your synthesis tool (in my case Precision). In 
one of my designs an FSM output stage drives the enable of some output 
registers.  I can then use the Precision report_connection command to list 
all the CE pins this FSM output signal is connected to.

# COMMAND: report_connections -net state(4)
# ix35.out {ix5.in[0]} reg_sin(11).ce reg_sin(10).ce reg_sin(9).ce 
reg_sin(8).ce reg_sin(7).ce reg_sin(6).ce reg_sin(5).ce reg_sin(4).ce 
reg_sin(3).ce reg_sin(2).ce reg_sin(1).ce reg_sin(0).ce reg_cos(11).ce 
reg_cos(10).ce reg_cos(9).ce reg_cos(8).ce reg_cos(7).ce reg_cos(6).ce 
reg_cos(5).ce reg_cos(4).ce reg_cos(3).ce reg_cos(2).ce reg_cos(1).ce 
reg_cos(0).ce

I can then use a bit of Tcl to filter this list and write out some MCP 
commands

set_multicycle_path -design rtl 4 -to reg_sin(*).in
set_multicycle_path -design rtl 4 -to reg_cos(*).in

Which is then translated by Precision to an Actel flavoured technology SDC 
file before invoking designer,

set_multicycle_path 4 -to { U1/reg_y10_s(9)_pbrt_0:D reg_sin(3):D 
reg_sin(2):D reg_sin(4):D reg_sin(5):D reg_sin(6):D reg_sin(8):D 
reg_sin(1):D reg_sin(7):D U1/reg_y10_s(10)_pbrt_0:D 
U1/reg_y10_s(11)_pbrt_0:D U1/reg_b(1)_dup_1028_pbrt_0:D 
U1/reg_sin_addsub12_29_modgen_add_12_Carry(1)_pbrt_0:D 
U1/reg_sin_addsub12_29_modgen_add_12_pog_array(2)(4)_pbrt_0:D 
U1/reg_sin_addsub12_29_modgen_add_12_pog_array(2)(8)_pbrt_0:D 
U1/reg_sin_addsub12_29_modgen_add_12_pog_array(2)(8)_pbrt_0_dup_52374:D 
U1/reg_sin_addsub12_29_modgen_add_12_g_array(2)(4)_pbrt_0:D
.. snip continue for another 2 pages...

You might be able to do the same using the standard SDC 
get_pins()/get_nets()/get_cells/etc commands but I haven't tried it,

Hans
www.ht-lab.com




>
> I have contacted Actel but they refer me to their docs or using the
> GUI tools which does not solve my problem.
> Surely this can be done via the .sdc constraints file using some TCL
> code.
>
> TIA.
>
> David
> 



Article: 123809
Subject: Re: DDR controller - best device to perform
From: pgw <"SwietyMikolaj["@]poczta.onet.pl>
Date: Wed, 5 Sep 2007 12:14:23 +0200
Links: << >>  << T >>  << A >>
rkruger@altera.com wrote:


> For Cyclone II devices you will find user guides on alt_dq and
> alt_dqs
> megafunctions on the Altera web site at http://www.altera.com/literature/ug/ug_altdq_dqs.pdf.
> 
> Note that on Cyclone III devices Altera has changed the design/
> architecture of DDR/DDR2 interfaces to use a new megafunction called
> ALTMEMPHY. This new megafunction is included with all versions of the
> Quartus II software including the free Quartus II Web Edition. This
> function builds an autocalibrating DDR/DDR2 PHY interface (calibrates
> out PVT changes) with the goal of relieving designers from much of
> the
> timing analysis burden associated with static interfaces and reducing
> PLL resource needs for wider DDR interfaces. The calibration feature
> takes advantage of new dynamic phase adjustment circuitry included in
> the Cyclone III PLL. The PLL phase shift is adjusted at power up and
> automatically over time to place the read capture clock in the center
> of the data valid window for the memory data calibrating out changes
> over process, voltage, and temperature. Cyclone III devices also add
> 2
> additional output registers in the I/O cell that improve write margin
> timing.
> The ALTMEMPHY user guide is available at http://www.altera.com/literature/ug/ug_altmemphy.pdf.
> 
> 
> ALTMEMPHY users have the choice of using the Altera high performance
> (HP) controller, third party controller, or designing their own
> controller. The Altera HP controller is included with Altera software
> subscriptions. Performance specifications are available in the
> External Memory Interfaces chapter of the Cyclone III Handbook at
> http://www.altera.com/literature/hb/cyc3/cyc3_ciii51009.pdf .
> 
> 
> I hope you find this helpful.

Thanks for your response. It's helpful.

-- 
PGW

Article: 123810
Subject: Re: Die size, pitch size?
From: Pasacco <pasacco@gmail.com>
Date: Wed, 05 Sep 2007 03:23:30 -0700
Links: << >>  << T >>  << A >>
Hi
Thank you all very much for pointer and comments
-P



Article: 123811
Subject: EDK9.1 linux registration fails (vista ok)
From: rponsard@gmail.com
Date: Wed, 05 Sep 2007 10:28:02 -0000
Links: << >>  << T >>  << A >>
Hi groups,

is there any reason for edk 9.1 registration failure with linux (I use
the same id that successfully register edk on the same dual boot vista/
ubuntu laptop ?)


Article: 123812
Subject: Re: PCB Impedance Control
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 05 Sep 2007 07:11:20 -0700
Links: << >>  << T >>  << A >>
On Wed, 5 Sep 2007 10:30:13 +0100, "Symon" <symon_brewer@hotmail.com>
wrote:

>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
>news:aq5sd3p1mttvq1s6kh9dcal265cokucd05@4ax.com...
>> On Tue, 04 Sep 2007 19:45:10 -0000, vasile <piclist9@gmail.com> wrote:
>>
>>>
>>>If you're routing a long 3Gbps differential signal, then definitely
>>>you must have ground vias near every signal pair vias.
>>
>> Why? If the signal is balanced, it needs even fewer vias than a
>> single-ended signal, which needs none.
>>
>> John
>>
>Hi John,
>
>As I'm sure you already know, this is because usually edge coupled signal 
>pairs on a PCB are not 'proper' differential pairs the way (say) twisted 
>pairs in CAT-5 are. The coupling between each distinct trace and the ground 
>plane is much greater than the coupling between the pair of traces 
>themselves. This is why Xilinx (and almost everyone else except, apparently, 
>you) recommend this GSSG structure when passing high speed differential 
>signals through vias. The vias reduce the common mode inductance of the 
>transistion, which is, after all, essentially two single ended signals. (In 
>fact the via is much more important for a single ended signal than a 
>differential one, as a single ended signal is all 'common mode' and the 
>ground via significantly reduces transition inductance.)
>
>Today's hilariously bizarre link collection is here
>http://www.xilinx.com/bvdocs/userguides/ug076.pdf
>http://www.edn.com/contents/images/300022.pdf
>
>Read chapter 11 of UG076, and check out fig.11.10.


The GSSG structure makes sense in both those papers, not because it
provides a "return current path" (which the papers, thankfully, don't
say) but because it keeps the impedances of the traces constant as
they burrow through the epoxy-glass, by providing uniform grounded
capacitive loading. There is a difference. 

That sort of thing matters at tens of gbps. It wouldn't matter if the
signals were slow, a couple of hundred ps risetime or something pokey
like that. 

>
>BTW., I saw the link you posted to your products. Thanks, they look great. I 
>noticed that you chose to put them all in metal boxes or racks. Bearing in 
>mind your philosophy on SI, I think that was a wise choice.

The V880 receives an optical data payload, phase locks to it, and
fires any mix of eight delay generators, each of which makes delays of
up to 3 seconds with 1 ps resolution. On board are power supplies, a
pll, a uP crunching lots of code, and high-power electrical or laser
output drivers. It mounts in a VME rack adjacent to various other
boards, like Pentium SBCs, on 0.8" spacing, with no shields between.
Jitter at the delayed outputs, relative to the master clock of the NIF
timing system, averages maybe 3 ps RMS. There are no "return current"
vias anywhere, and both single-ended and differential signals are
"referenced" to any plane that's convenient.

John


Article: 123813
Subject: Re: Multiple CPLDs on a PCB.
From: NickNitro <NickHolby@googlemail.com>
Date: Wed, 05 Sep 2007 07:15:55 -0700
Links: << >>  << T >>  << A >>
Ok, thanks everybody for the comments. It seems I've underrated FPGAs
in comparison to CPLDS. :)

Thanks again,
Nick.


Article: 123814
Subject: Re: warning 1780 shown while synthesis, in xilinx 6.3i
From: Dave Pollum <vze24h5m@verizon.net>
Date: Wed, 05 Sep 2007 07:30:42 -0700
Links: << >>  << T >>  << A >>
On Sep 5, 2:49 am, ankur <ankurrawat0...@gmail.com> wrote:
> hi
>  I am designing a generic arbiter .
> while synthesis the xilinx tool is giving warning
>
> WARNING:Xst:646 - Signal <inter> is assigned but never used.
> WARNING:Xst:1780 - Signal <k> is never used or assigned.
>
> I searched  it out in the solution record
> warning 646 can be ignored .
> but warning 1780 is displayed in the case of jtag ,so i am not able to
> conceive why this is coming.
> i have pasted the design below.
> thanks for help
> ankur
>
>  module  pri_encoder32(inbus,outbus);
>
>   parameter size=9;
>   parameter size_1=size-1;
>   parameter size_out=4;
>   input  [size-1:0]inbus;
>
>   output reg  [size_out-1:0]outbus;
>
>   reg [size_out-1:0]k;
>   reg [size_out-1:0]inter;
>
>         always @(inbus)
>                 begin
>                         inter=0;
>                         for (k = size; k >= 1; k = k - 1)
>                                 begin
>
>                                         if (inbus[k-1]==1)
>                                                 begin
>                                                         outbus = k-1;
>                                                         inter=k-1;
>                                                 end
>                                         else
>                                                 begin
>                                                         outbus=inter;
>                                                 end
>                                 end
>
>                 end
>
> endmodule

I'm not familiar with verilog, but it looks like this boils down to
k=1.  You may want to post this to comp.lang.verilog.
-Dave Pollum


Article: 123815
Subject: clock skew problems
From: michel.talon@gmail.com
Date: Wed, 05 Sep 2007 14:46:42 -0000
Links: << >>  << T >>  << A >>
Hi all,

I've got a FPGA design with a lot of clocks! I know this is not really
good, but I've to implement a microprocessor initially designed for an
ASIC. The microprocessor uses combinatorial signals to drive latchs
and Flipflops.

I tried to re-clock some critical signals with a faster clock but this
is not very efficient.. :-(  and I've trouble with this clock, ISE
gives me warnings :
Route:447  - CLK Net : my_clock may have excessive skew because 2 NON-
CLK pins failed to route using a CLK template. ( I've this warning for
a lot of others clock generated by combinatorial logics... )

My question is how can I locate the 2 NON-CLK pins ? because I've a
fanout of 678 signals... and if I've to search manually, it could be
very long! Is there an ISE functionality to do that ?

Thanks by advance,

Best regards, Michel.


Article: 123816
Subject: Re: Null statement in VHDL
From: Andy <jonesandy@comcast.net>
Date: Wed, 05 Sep 2007 07:48:18 -0700
Links: << >>  << T >>  << A >>
On Sep 3, 9:28 am, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message
>
> news:71fnd39ctb6egc7jjloldmvn9pjnr96u4s@4ax.com...
>
> > On Sun, 02 Sep 2007 22:38:38 GMT, "KJ" wrote:
>
> >>For whatever tools that you have that meet the following two tests, did
> >>you
> >>open a service request?
> >>- Tool claims compliance to VHDL standard
> >>- Tool does not error (or at least warning) about ignoring the initial
> >>value
> >>assignment
>
> > Every synth tool I've used issues a warning or error when it ignores
> > initial values.  It's a tool restriction I've learnt to live with.
>
> If the target device does not support initial values then that would be the
> correct behaviour of the tool.  If the target device does support a power up
> value for registers than I still say that the service request should be
> opened to the supplier for non-compliance to the VHDL standard.
>
> > On FPGAs with well-defined config values, I work around it by
> > providing an explicit asynchronous reset in the usual way and then
> > tying-off that reset to "false" somewhere in the top-level wrapper
> > that organises the design for the target platform.  That gives me
> > no additional hardware cost in the FPGAs that I've used, and it
> > gives me a different, clumsier, but equally effective way to
> > specify initial values.
>
> But that doesn't sound like a 'tool' thing, it sounds like a way to make the
> code re-usable when targeted towards devices that either do or not support
> power up defined values.  I thought your point had to do with grumblings
> about synthesis tools but it appears that it really has to do with physical
> parts that do not have guaranteed power up values.
>
> KJ

The most often confused part about reset and initial conditions (in
FPGA's, where reliable initial conditions are possible), is that
neither handles the transition from reset or configuration to normal
operation automatically and correctly. However, an explicit reset
gives the user more options to correctly implement the transition.

For example, a counter is initialized/reset to zero, but on the first
clock out of reset (or configuration), the counter counts down,
resulting in a rollover. Unless the reset or end of configuration is
synchronized to the clock, the entire contents of the counter become
undefined. And this problem is not just related to counters. One-hot
state machines can get into illegal states if transitions are allowed
on the first clock out of reset/configuration. In the old days (before
FPGA's and dirt), we used to have rules about down counters being
initialized to odd values, and up counters initialized to even values,
initial transitions on state machines being single bit transitions,
etc. to combat this. These methods are still valid, but are much less
reviewable/auditable/verifiable that correctly handling the timing
relationship between the clock and the end of configuration or reset.

This timing relationship can be handled by traditionally synchronizing
the deassertion of reset, or by delaying the clock sufficiently after
the deassertion of reset/config. The latter is applicable regardless
of whether reset is explicitly coded; the former is applicable only to
explicit resets.

Some FPGA storage elements (e.g. RAM) do not have a reset capability,
but do have an initialization (via configuration) capability. It is
vital that either the clock be disabled sufficiently after
configuration is complete, or that the contents of the ram are not
allowed to change on the first clock after configuration is complete
(assuming one clock period is long enough to guarantee that all
storage elements are out of configuration).

In summary, just because VHDL initial conditions are supported by a
synthesis tool does not mean that all initialization problems are
automatically handled by them.

Andy



Article: 123817
Subject: Re: Spartan3E and DDR termination
From: vasile <piclist9@gmail.com>
Date: Wed, 05 Sep 2007 14:55:28 -0000
Links: << >>  << T >>  << A >>
On Sep 4, 1:42 pm, Gabor <ga...@alacron.com> wrote:
> On Sep 4, 3:40 pm, vasile <picli...@gmail.com> wrote:
>
>
>
>
>
> > On Aug 30, 8:41 am, Gabor <ga...@alacron.com> wrote:
>
> > > On Aug 30, 9:41 am, Gabor <ga...@alacron.com> wrote:
>
> > > > On Aug 30, 4:59 am, Guru <ales.gor...@email.si> wrote:
>
> > > > > Hi all,
>
> > > > > We are building a board with Spartan3E (XC3S1200E FG320) and a 64MB
> > > > > x16 DDR (HYB25DC512160CF-6). Trying to make the board as tiny as
> > > > > possible the DDR termination presents a problem. Since the Spartan3E
> > > > > does not have DCI, termination on chip is not possible. This means
> > > > > that 44 termination resistors should be added and maybe a VTT power
> > > > > source. The other problem is that according to MIG we should connect
> > > > > DDR to two banks.
>
> > > > > Any good suggestions?
> > > > > Is it possible to eliminate termination resistors?
>
> > > > > Cheers,
>
> > > > > Guru
>
> > > > If you're only driving a single chip with very short lines you
> > > > can probably get away without termination on everything except
> > > > the clock.  I would suggest using SSTL2_I instead of SSTL2_II
> > > > to avoid overdriving.  Another approach is to just leave out
> > > > the series termination on these signals and just add the parallel
> > > > termination to Vtt.  I've used the latter method with Virtex2
> > > > and an SO-DIMM without DCI on the data lines and SSTL2_I drive.
> > > > A good argument for leaving out the series termination is any
> > > > net where the driving stub (from the S3 to the resistor) is
> > > > about the same length as the driven stub (from the resistor
> > > > to the memory).  Here the terminator is of dubious value.
>
> > > > It's probably best to simulate your transmission lines,
> > > > especially if you're planning to run the memory at its
> > > > maximum speed of 166 MHz / DDR333.  My V2 design ran at
> > > > 133 MHz / DDR266.
>
> > > > HTH,
> > > > Gabor
>
> > > One other thought if your main interest is in reducing the
> > > board size.  Often I find that using a x32 single-data-rate
> > > (143 MHz) memory can save space.  If you're using a TSSOP-66
> > > package for the DDR part, the 86-pin TSSOP for the x32 SDR
> > > part has the same footprint and runs from +3.3V with no
> > > requirements for VREF and DQS pins on the FPGA and no
> > > Vtt or 2.5V supply.
>
> > How looks the Vref signal inside the DDR II ? Exactly what is good
> > for ?
>
> > thx,
> > Vasile
>
> Not quite sure what you're asking here.  


I have asked how looks the Vref internal circuitry of a DDRAM II. Why
you need Vref for DDRAM II and which is the Vref value related to Vtt.
I didn't ask about FPGA Vref which description is quite clear to me.
It seems from your answer it's about SSTLII standard only, but I'm not
sure it's the complet answer. Do you have any datasheet for DDRAM II
talking in detail about the Vref problem?

thx,
Vasile


The point I was trying to
> make
> is that the single-data-rate parts don't need to tie up FPGA pins with
> Vref and DCI.  On Virtex 2 parts, you can have as many as 6 Vref pins
> in one bank.  If you use SSTL2 signalling instead of LVTTL you lose
> the ability to use these pins as I/O.  If you also decide to use DCI
> you lose an additional 2 pins per bank.  The DDR parts also have more
> control pins (differential clock adds one pin, DQS adds one per 8 bits
> of interface).  So if you can live with the data rates of the single-
> data-rate parts, you can avoid a lot of headaches and perhaps use
> only a small number of additional pins to double the data width.
>
> By the way, for SSTL2 you need Vref as a precision threshold reference
> at 1/2 Vddq, usually 1.25V or 1.3V depending on the speed for DDR I
> parts.  LVTTL allows a wide threshold tolerance, usually 0.8 to 2.0v
> but generally won't work well at DDR bit rates.- Hide quoted text -
>
> - Show quoted text -



Article: 123818
Subject: high bandwitch ethernet communication
From: eliben <eliben@gmail.com>
Date: Wed, 05 Sep 2007 14:59:30 -0000
Links: << >>  << T >>  << A >>
Hello,

In our application we have to receive and merge several proprietary
serial channels (200 MHz) over fibers, and send all the data over
Gigabit Ethernet. The bandwidth is ~60 MByte/s, sustained.

While generally sending this amount of data is possible over Gbit
Ethernet, doing so in an embedded system isn't easy. That's because we
need to send it by UDP or TCP, for which a TCP/UDP/IP stack is
required (software).

Since the translation of the proprietary format is certainly done in
an FPGA, I tried to calculate how to implement the whole process in an
FPGA. For example, I can take an Altera Stratix II GX (with a built in
Gbit Ethernet PHY), add Altera's MAC and use a TCP/IP stack running on
the Nios II soft-core processor. Unfortunately, as Altera's appnote
440 shows, the maximal bandwidth attainable this way is only 15-17
MByte/s. For the sake of comparison, benchmarks of Gbit Ethernet
adapters on PCs show a maximal bandwidth of 80-90 MByte/s.

However, I wouldn't like to build in a Pentium into the embedded
system. Any suggestions / recommendations on how to solve the
problem ?

Thanks in advance


Article: 123819
Subject: Re: clock skew problems
From: Gabor <gabor@alacron.com>
Date: Wed, 05 Sep 2007 08:01:16 -0700
Links: << >>  << T >>  << A >>
On Sep 5, 10:46 am, michel.ta...@gmail.com wrote:
> Hi all,
>
> I've got a FPGA design with a lot of clocks! I know this is not really
> good, but I've to implement a microprocessor initially designed for an
> ASIC. The microprocessor uses combinatorial signals to drive latchs
> and Flipflops.
>
> I tried to re-clock some critical signals with a faster clock but this
> is not very efficient.. :-(  and I've trouble with this clock, ISE
> gives me warnings :
> Route:447  - CLK Net : my_clock may have excessive skew because 2 NON-
> CLK pins failed to route using a CLK template. ( I've this warning for
> a lot of others clock generated by combinatorial logics... )
>
> My question is how can I locate the 2 NON-CLK pins ? because I've a
> fanout of 678 signals... and if I've to search manually, it could be
> very long! Is there an ISE functionality to do that ?
>
> Thanks by advance,
>
> Best regards, Michel.


You probably know the design well enough to guess where these loads
are.  Are you creating a gated clock somewhere?  Does this clock
drive an output pin?  Any flip-flop in the design using the clock
will "route using a CLK template", so gates (LUTs) and pins (IOBs)
and possibly clock muxes (BUFGMUX) or DCM's will be the problem
loads.

By the way, skew is only a problem if the loads mentioned actually
drive some synchronous logic.  For example gated clocks used by
flip-flops receiving inputs from the original clock domain.  The
"excessive skew" doesn't apply to the other 676 clock loads tha
do "route using a CLK template."

HTH,
Gabor


Article: 123820
Subject: Re: Null statement in VHDL
From: Andy <jonesandy@comcast.net>
Date: Wed, 05 Sep 2007 08:02:01 -0700
Links: << >>  << T >>  << A >>

> >It is more a dirty hack to trick the tools in the desired behaviour
> >than it is an effective way to specify initial values.
> >Any tool is free to break your implentation and will still be in
> >compliance with the language spec.
>
> Guilty as charged.  There's no doubt that synthesis
> support for initialization values - with, of course,
> checks that it been applied only to variables or
> signals that represent a flip-flop - would be the
> best solution by far.

Why the restriction on variables/signals that represent flops? It
seems to me that initialization of a combinatorial variable or signal
would be correctly simulated and synthesized even if it were just
ignored (thus no warning issued), unless a combinatorial loop/latch
were involved, which would be its own warning.

Besides, variables, in and of themselves, represent neither register
nor combinatorial values. References to them do. In fact, different
references to the same variable can represent both a combinatorial and
a registered value. That's one of their attributes which makes them so
powerful. But that's another topic...

Andy


Article: 123821
Subject: Re: high bandwitch ethernet communication
From: Tim Wescott <tim@seemywebsite.com>
Date: Wed, 05 Sep 2007 10:13:25 -0500
Links: << >>  << T >>  << A >>
On Wed, 05 Sep 2007 14:59:30 +0000, eliben wrote:

> Hello,
> 
> In our application we have to receive and merge several proprietary
> serial channels (200 MHz) over fibers, and send all the data over
> Gigabit Ethernet. The bandwidth is ~60 MByte/s, sustained.
> 
> While generally sending this amount of data is possible over Gbit
> Ethernet, doing so in an embedded system isn't easy. That's because we
> need to send it by UDP or TCP, for which a TCP/UDP/IP stack is
> required (software).
> 
> Since the translation of the proprietary format is certainly done in
> an FPGA, I tried to calculate how to implement the whole process in an
> FPGA. For example, I can take an Altera Stratix II GX (with a built in
> Gbit Ethernet PHY), add Altera's MAC and use a TCP/IP stack running on
> the Nios II soft-core processor. Unfortunately, as Altera's appnote
> 440 shows, the maximal bandwidth attainable this way is only 15-17
> MByte/s. For the sake of comparison, benchmarks of Gbit Ethernet
> adapters on PCs show a maximal bandwidth of 80-90 MByte/s.
> 
> However, I wouldn't like to build in a Pentium into the embedded
> system. Any suggestions / recommendations on how to solve the
> problem ?
> 
> Thanks in advance

My first choice would be some other, more embeddable, processor running
off to the side.  A PowerPC from Freescale, or an ARM processor from just
about anybody, comes to mind.  I suspect that even a modest such processor
would get some pretty high speeds if that's all it was doing.

You may have to bite the bullet and write your own stack that's shared
between a processor and the FPGA.  I know practically nothing about
TCP/IP, but I'm willing to bet that once you've signed up to writing
or modifying your own stack there are some obvious things to put into the
FPGA to speed things up.

Slapping a big, limited temperature range, power hungry Pentium into an
embedded product would not be my first choice either.

-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Article: 123822
Subject: Re: high bandwitch ethernet communication
From: Gabor <gabor@alacron.com>
Date: Wed, 05 Sep 2007 08:26:25 -0700
Links: << >>  << T >>  << A >>
On Sep 5, 10:59 am, eliben <eli...@gmail.com> wrote:
> Hello,
>
> In our application we have to receive and merge several proprietary
> serial channels (200 MHz) over fibers, and send all the data over
> Gigabit Ethernet. The bandwidth is ~60 MByte/s, sustained.
>
> While generally sending this amount of data is possible over Gbit
> Ethernet, doing so in an embedded system isn't easy. That's because we
> need to send it by UDP or TCP, for which a TCP/UDP/IP stack is
> required (software).
>
> Since the translation of the proprietary format is certainly done in
> an FPGA, I tried to calculate how to implement the whole process in an
> FPGA. For example, I can take an Altera Stratix II GX (with a built in
> Gbit Ethernet PHY), add Altera's MAC and use a TCP/IP stack running on
> the Nios II soft-core processor. Unfortunately, as Altera's appnote
> 440 shows, the maximal bandwidth attainable this way is only 15-17
> MByte/s. For the sake of comparison, benchmarks of Gbit Ethernet
> adapters on PCs show a maximal bandwidth of 80-90 MByte/s.
>
> However, I wouldn't like to build in a Pentium into the embedded
> system. Any suggestions / recommendations on how to solve the
> problem ?
>
> Thanks in advance


Check out Stretch http://www.stretchinc.com

They have processors with 4 gigabit ethernet ports and a
hardware-assisted stack that can keep up at full gigE
bandwidth on at least 3 at the same time.  Getting data
into the Stretch processor memory can be via the
"coprocessor bus" interface or by using one of the
MAC interfaces as a simple FIFO.


Article: 123823
Subject: Re: high bandwitch ethernet communication
From: John McCaskill <jhmccaskill@gmail.com>
Date: Wed, 05 Sep 2007 15:53:06 -0000
Links: << >>  << T >>  << A >>
On Sep 5, 9:59 am, eliben <eli...@gmail.com> wrote:
> Hello,
>
> In our application we have to receive and merge several proprietary
> serial channels (200 MHz) over fibers, and send all the data over
> Gigabit Ethernet. The bandwidth is ~60 MByte/s, sustained.
>
> While generally sending this amount of data is possible over Gbit
> Ethernet, doing so in an embedded system isn't easy. That's because we
> need to send it by UDP or TCP, for which a TCP/UDP/IP stack is
> required (software).
>
> Since the translation of the proprietary format is certainly done in
> an FPGA, I tried to calculate how to implement the whole process in an
> FPGA. For example, I can take an Altera Stratix II GX (with a built in
> Gbit Ethernet PHY), add Altera's MAC and use a TCP/IP stack running on
> the Nios II soft-core processor. Unfortunately, as Altera's appnote
> 440 shows, the maximal bandwidth attainable this way is only 15-17
> MByte/s. For the sake of comparison, benchmarks of Gbit Ethernet
> adapters on PCs show a maximal bandwidth of 80-90 MByte/s.
>
> However, I wouldn't like to build in a Pentium into the embedded
> system. Any suggestions / recommendations on how to solve the
> problem ?
>
> Thanks in advance



If you have the choice between UDP and TCP, UDP is much simpler and
fits an FPGA well. The big issue in choosing between the two is if you
require the guaranteed delivery of TCP, or can tollerate the potential
packet loss of UDP.

As an example, we make a card that acquires real time data in a custom
protocol that is wrapped in UDP. We use a Xilinx Virtex-4 FX60, and a
protocol offload engine that uses the Xilinx PicoBlaze soft processor
to deal with the protocol stack.  The PicoBlaze is an 8-bit soft
processor.  It looks at each incomming packet and reads the header to
see if it is one of the real time streams we are trying to offload.
If it is, it sends the header to one circular buffer in memory and the
data to another circular buffer.  If it is not, it sends it to a
kernel buffer and we let the Linux network stack deal with it.

With this setup, we can consume data at over 90 MB/sec per Gigabit
Ethernet port.  The data part of the packet is 1024 bytes, and each
GigE port has its own PicoBlaze dedicated to it.

I did notice that you want to send GigE instead of receive it like we
are doing, but this method should work for sending a custom protocol
wrapped in UDP with some minor changes.

How is the GigE that you are sending the data over connected? Is it
point to point, a dedicated network, or something else?

The network that the data we deal with is set up as multicast data on
VLANs.  The VLANs are allocated to guantee the required bandwidth
through the switches, and data sources use traffic shapping to put out
their packets at a steady rate. In that environment, UDP works just
fine.

This is the card that I am talking about:

http://www.fastertechnology.com/products_p6.html

Regards,

John McCaskill,
www.fastertechnology.com


Article: 123824
Subject: Re: New keyword 'orif' and its implications
From: Andy <jonesandy@comcast.net>
Date: Wed, 05 Sep 2007 09:19:58 -0700
Links: << >>  << T >>  << A >>

> Are you sure that Jim's assertion method in communicating mutually
> exclusivity to VHDL compiler is good enough without need for 'orif'
> introduction?

It depends on the definition of "good enough", but there is not a
single situation where an assertion could not reasonably be used, but
where 'orif' could be. Conversely, there are several situations where
'orif' is not an option, but an assertion would be.

>
> 1. As I described before, if you use Jim's method and want to get the
> information to compiler, you must insist the 'if...end if' structure
> to get the benefits, otherwise it is useless, meaningless and wasting
> time.

Not necessarily. There are many mutual exclusivity situations that
might even span different processes. Consider two processes that both
use multipliers. If both processes' uses of their multipliers are
enabled by specific conditions that can be shown to be mutually
exclusive, the synthesis tool has enough information to enable them to
share one multiplier.  Of course whether or not current synthesis
tools share resources across processes is beyond the scope of this
argument.

Another example is two state machines that are never both in a state
that uses a multiplier (or some other expensive, shareable resource).

Both of these situations are certainly possible with if-then code
structures, but they don't have to be, and can still take advantage of
an assertion to verify and communicate the mutual exclusivity.

>
> 2. When you use 'if...end if' structure, 'orif' is the best choice, no
> question! You can add the information line by line at any levels as
> you want.

'Orif' is only an option if you can code the function in an if-ELSIF
structure, which cannot be done for a parameterized loop of if-then
structures.

>
> 3. My goal is to make writing VHDL for a hardware engineer as easy as
> writing C for a software engineer using 'if...end if' structure with
> mixing 'elsif' and 'orif'.

Ouch! Then just use verilog; it is already as "easy to use as C" (and
to get into trouble with).  ;^)

The way I see it is thus: The barrier to new syntactical changes in
VHDL, particularly those that affect the synthesizable subset of VHDL,
should be quite high because of the problems that occur until every
tool in the chain can even read the new syntax. Therefore, syntactical
changes should only be made to allow functionality that cannot be
reasonably supported within the existing syntax. Of course, that
depends on the definition of "reasonably", but I just don't think
'orif' exceeds the barrier.

Thanks,

Andy




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