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 61625

Article: 61625
Subject: Re: LVDS_25_DCI : Top Ten List
From: brimdavis@aol.com (Brian Davis)
Date: 7 Oct 2003 18:50:41 -0700
Links: << >>  << T >>  << A >>
Austin,

>
>Get off that boat:  I have admitted it many times now.
>It is you who seems to persist in dragging it on, 
>and on, and on, and on, and on.....
>

 Perhaps when you stop posting the same poorly reasoned 
arguments over and over again, I'll stop correcting them 
over and over and over again.

 You claim to have "admitted" that the input capacitance is a
problem, yet here you go again with your denials:

>>
>>  You disagreed with me on this issue, so in subsequent posts
>> I refuted the various arguments that you made contending that
>> the high V2 C_COMP value is unavoidable/not a problem/etc.
>
>It is.
>

 If you can't form a coherent argument, don't bother
posting grade school "is too, is too, is too" nonsense.

>
>Since I can not see their data sheet (they block Xilinx domain),
>I have no means of verifying your claim.
>

 That information was in my very first post; you ignored it,
continued denying it, yet still can't be bothered to check?

 Get a real excuse.
 
 Do you honestly expect us to believe that you have no 
Internet access outside of work?

 Or, that nobody at Xilinx keeps up on competitor's products?


>> >
>> >Our parts meet the LVDS standard, they work.
>> >
>>  What about the other specs I have mentioned, such as HyperTransport,
>> that have a tighter Cin or slew rate specification?
>
>Then we don't meet the "specs".  Wasn't that simple?  But we do
>interoperate, and many people choose to do so.
>

 Interoperate where? In one reference design, with one vendor's
parts? Or, in all the potential configurations considered by 
the standards committee when they wrote the spec?

 May the spirits of the all the anonymous standards weenies,
who worked so hard to incorporate those specifications that you
so blithely dismiss, haunt your designs until you repent.


>
>No, it is just physics.  Can't probe anyones 840 Mbs lines
>without affecting them.
>

 How can you argue on one hand that the ~10pf total Cin of your 
receiver inputs is not a problem, yet claim the fraction of a pf
imposed by a decent probing scheme will somehow be significant 
in the same system?

 A well designed resistive coupler, properly packaged, will work
at OC-192 rates and beyond.

>
>Gee, I designed digital microwave radios for 5 years, and I never could
>"see" anything.  Only could sniff at it with a spectrum analyzer.
>Everything was simulated.  Guess where we are all headed?
>

 You may be stuck with doing simulations at the chip level, except
for perhaps the guys doing wafer probe for low level device model 
correlations, but the users of your parts still have the luxury of
testing and measuring directly in the real world.

 We will continue to use those tools that are most appropriate 
to the task at hand, rather than blindly placing our faith in 
IBIS models and simulators alone.


Brian

Article: 61626
Subject: Re: Avnet Xilinx Virtex II Development Board - getting started
From: yankiu_chan@yahoo.com (mintchoco)
Date: 7 Oct 2003 19:17:10 -0700
Links: << >>  << T >>  << A >>
Hi Martin,

Thanks for your reply.

I'm a University student.  I'm very familiar with HDL, I've already
done my code in Verilog, and I just need to program the device so I
can test and make sure my code is working.  I'm actually very familiar
with Actel FPGAs, but never used Xilinx before.  System ACE and boot
prom stuff is pretty new to me.  The myriad of information on the
Xilinx website is overwhelming, and that is why I wasn't sure where to
start.

I'll take a look at those materials you've pointed to, but I've
already scanned through AVNET documentation that came with the board,
and it was not very clear what plugs into where and how to 'quickly'
get started.

> Did you get a JTAG cable?  
So once I get Parallel IV cable, that plugs from my parallel port to
JTAG directly?  Is there a 'programmer' that I need?  Also, I have ISE
installed.

Article: 61627
Subject: Re: Xilinx DCMs, DDR, CLK0, and CLK180
From: Marc Randolph <mrand@my-deja.com>
Date: Wed, 08 Oct 2003 03:29:29 GMT
Links: << >>  << T >>  << A >>
John Providenza wrote:
> I'm working on a design that's using multiple DCMs along
> with DDR i/o registers.  The main input clock is 500MHz
> going into a DCM with the CLKIN_DIVIDE_BY_2 flag set
> so it's immediataly cut down to 250MHz. The DCMs used in
> the design also have CLKOUT_PHASE_SHIFT=VARIABLE.
> 
> To drive my DDR i/o flops, I'm currently using both the CLK0 and
> CLK180 pins (running at 250MHz).
> 
> The original designer flowed the DDR data though the chip using
> both clock edges, ie, the incoming "posedge" data went down a
> "posedge" data pipeline to flow back out the DDR output.  The
> incoming "negedge" data went down a "negedge" pipeline. The
> original design did NOT use CLK0 and CLK180 for these two
> data paths.  Instead, the designer used "posedge" and "negedge"
> in the Verilog.  The major problem comes in the control and
> data signals that cross the two domains.  Because of the potential
> duty cycle degradation, 

Howdy John,

I have to admit some ignorance here, but I won't let that stop me from 
later making some guesses about what is going on :-)

By duty cycle degradation, are you referring to what the DCM introduces, 
or something with regard to the clock tree?

The datasheets claims that the DCM "duty cycle precision" is +/-150ps, 
while the phase offset between DCM outputs is +/-140ps... and the jitter 
out of CLK180 is +/-50ps worse than just CLK0.  So it seems like you are 
just going to be trading one problem for another problem here.

 > the P&R tools don't achieve timing
> closure consistently.
> 
> As an experiment, I changed the design to use CLK0 and CLK180 for
> the internal flops.  I was:
>   a) pleased when the P&R timing was better

I can't say I'm too surprised at that.  Or rather, I can imagine why 
that might be... if you open it up in FPGA editor, are there now 
distinct sections of the devices that seem to be run exclusively off 
CLK180 while other areas run exclusively off CLK0?  If so, by diving up 
the clocks, you may have effectively helped the tools floorplan the 
design.  Previously, everything was on a single clock tree, so it may 
have mixed the two pipelines willy-nilly, making timing more difficult 
to meet.

>   b) surprised when the design no longer worked.

The only idea I have is to repeat Ray's mantra of being careful about 
going back and forth between domains that are on different outputs of 
the DCM.

Well, I take that back.  Another idea is to floorplan the original 
design at the top level: divide the device in half, one for each 
pipeline, and see if you get noticeably better timing results.

Good luck,

    Marc


Article: 61628
Subject: Re: Digesting runs of ones or zeros "well"
From: Ray Andraka <ray@andraka.com>
Date: Wed, 08 Oct 2003 00:31:42 -0400
Links: << >>  << T >>  << A >>
You can do it, and it is fairly simple.  The shortcut method is to partition the
logic by using keep buffers (syn_keep attributes in synplify).  The synthesizer
will preserve the signals with the keep buffer, which pushes those signals onto
LUT outputs.  The lut contents are then specified with logic equations and the
luts are inferred.  For example:

attribute syn_keep of d:signal is true;
attribute syn_keep of h: signal is true;

begin

d<= a and b and c;
h<= e and f and (not g);
out<= d or h;

forces the synthesis to put the equation for d in one lut, the equation for h in
one lut and out in a third lut.  Actually what it does is force the outputs d,
and h to be lut outputs.  If a,b and c come from flip flops or have syn_keeps on
them then you fully force the LUT.  If you leave those off, the the synth is free
to move those.  This gives you a method of controlling construction without
resorting to instantiation.

Synplicity also provides a mechanism for creating a component tht you can put an
fmap on forcing it to be a LUT.  In this case, the LUT has to be a separate
component.  This one can be RLOC''d.  To do this, you create a separate
component, in this case an AND3, and include an xc_map=lut attribute on the
component.  The architecture of the component has the boolean equation for the
LUT in it.

--FMAP'd and3
library IEEE;
use IEEE.std_logic_1164.all;

entity fmap_and3 is
  port ( a, b, c : in std_logic;
  z : out std_logic);
end fmap_and3;
architecture rtl of fmap_and3 is
attribute xc_map : STRING;
attribute xc_map of rtl : architecture is "lut";
attribute syn_hier: string;
attribute syn_hier of rtl:architecture is "hard";
begin
  z <=  a and b and c;
end rtl;

This method depends on your naming to make it readable.  Naming is not hard for
simple logic functions, but can be a bit of a pain when the 4 inptu equation gets
complicated.

A third method is instantiating the LUT4, LUT3 or LUT2 component.  In this case,
you dont' have a separate component to define, but you do have to supply the LUT
contents in the form of a hex string in two places: once for the INIT=attribute
which gets passed onto the edif netlist but not to simulation, and once to the
INIT generic which is used for simulation, but not passed to the netlist.  As I
understand it, the latest version of synplify passes the INIT generic to the
netlist, but that is not portable.  Great care has to be taken with this method
to make sure the simulation matches the synthesized hardware.  It is also
extraordinarily error prone and difficult to read and maintain.  This can be
worked around by writing a function to parse a boolean expression and convert it
to the appropriate INIT strings, but it is not trivial to write.

The first method gives you structure but no handles for naming or placing the
LUTs.  The second is one I use for many of my library macros, as it permits
attachment of an RLOC placement attribute so you can get control over placement.
It does however result in a large library of small combinatorial functions which
can become awkward to maintain.  The third is generally too hard to use and
maintain without a good INIT string generation function, however it does not
require a large library of 2,3 and 4 input functions.  It is hardly usable
without the boolean to INIT function however.



Hal Murray wrote:

> >I tried to instantiate a LUT the other day and I couldn't figure out
> >the "right" way to do the Verilog for Synplify since there are INIT
> >parameters for simulation and xc_props="INIT=xxxx" for synthesis as
> >far as I can tell.  I had something that looked un-LUT-like in the HDL
> >Analyst technology viewer so I didn't pursue that furhter.
>
> This seems like a good addition to the tools discussion in other
> threads.
>
> There really should be a simple way to say something like:
>   Generate this signal in a LUT (or whatever) with these inputs.
>   Possibly constraining the location and/or locking some inputs to
>     particular ports.
> The idea is that the system will figure out the details from the
> info it already has.
>
> --
> The suespammers.org mail server is located in California.  So are all my
> other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
> commercial e-mail to my suespammers.org address or any of my other addresses.
> These are my opinions, not necessarily my employer's.  I hate spam.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 61629
Subject: Re: Digesting runs of ones or zeros "well"
From: Ray Andraka <ray@andraka.com>
Date: Wed, 08 Oct 2003 00:36:09 -0400
Links: << >>  << T >>  << A >>
The mapper seems to be pretty good at respecting LUTs and not changing them.

rickman wrote:

>
> Actually, I don't think logic primatives will work since the back end
> mapper can redo logic at will.  The keep attribute is what is required
> to define the LUTs and even that is not guaranteed since it only results
> in a wire being kept; the LUT can still be split if other logic uses the
> same inputs.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 61630
Subject: Re: Digesting runs of ones or zeros "well"
From: Ray Andraka <ray@andraka.com>
Date: Wed, 08 Oct 2003 00:45:44 -0400
Links: << >>  << T >>  << A >>
I'm not sure I caught your requirement completely.  As I understand it, you need to detect
when there are 9 0's or 9 1's starting at a byte boundary?
That can be done with a bit of logic and a carry chain:

the lsb inverts the remaining bits if it is zero, otherwise the remaining bits are passed to
the carry chain unchanged.  the carry chain gets the conditionally inverted bits starting at
LSB+1, and at the 9th bit you look at the carry chain output (the carry in at the base of
the chain is also a '1').  If all the bits match the LSB, you get a '1' on the carry chain
output.  This is easiest to code with instantiated MUXCY's rather than pushing on a rope to
get the synthesizer to figure out you want to use the carry chain as a wide and gate.   Not
sure if this meets your requirement or not, but it is illustrative of how you might tackle a
similar problem with a perhaps less than obvious approach.


John_H wrote:

> rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F7B3F59.191901A4@yahoo.com>...
> > My experience has been that it does not much matter how you code
> > combinatorial logic like this.  The tools run it through a grinder and
> > produce an optimal version (in its own mind).  When I want to optimize
> > like this, I either use a "keep" attribute on the wire, or sometimes you
> > can instantiate primitives.  For logic I don't think primitives work
> > since gates just get remapped.
>
> I overuse the syn_keep attribute and I hate the idea of instantiating
> LUTs.  My Carnot skills aren't exactly used regularly.
>
> > But I still don't understand your code.  Why does the outer loop range
> > over 64 values.
>
> I've had problems with bit ranges in the past where [i+4:i] is a
> complaint.  Perhaps this isn't an issue with for loops but I've
> learned to avoid them in general logic.  They do work fine in generate
> blocks, however.  I stepped through every bit to make a comparison to
> the adjacent bit; 3 adjacent comparisons lumped into one variable
> (with an eventual syn_keep) would give me 4-input functions that
> should pack into LUTs.  The complex end of the inside loop is so that
> the three "LUTs" per byte are 4-input, 4-input, and 3-input functions.
>
> > I would code two nested loops where the outer loop
> > ranges over the 8 outputs and the inner loop ranges over the 9 inputs
> > for each output.  Or just skip the inner loop and use two outputs from
> > two sets of four inputs feeding a 3 input function and use keeps on the
> > first two output arrays.  Maybe that is what you are doing, but I can't
> > figure out the code easily.
> >
> > I see you are incrementing the i variable by j and ranging j in the
> > second loop by some complex control expression.  Can't you just
> > increment i by 8?
> >
> > for( i=0; i<64; i=i+8 ) begin
> >   k = i % 8;
> >   for( j=0; j<4; j=j+1 ) begin
> >     runBitsA_[k] = runBitsA_[k] & bytePlus1[i+j];
> >     runBitsB_[k] = runBitsB_[k] & bytePlus1[i+j+4];
> >   end
> >   runByte_[i] = runBitsA_[i] & runBitsB_[k] & bytePlus1[i+9];
> > end
> >
> > Put the keep on runBitsA_ and runBitsB_ and you should get your two
> > level structure.
>
> This works very well for runs of ones only.  I need to identify runs
> of ones or runs of zeros.  The technique can be expanded to my needs
> resulting in runBitsA, B, and C where one of them needs to cover 2
> comparisons, not 3 like the others.  ...which is really is the
> approach I was coding but using consecutive bits in a vector rather
> than {A,B,C} and using the one statement rather than 3 to make the
> assignments, dealing with the 2 comparison exception by terminating
> the inside loop early.
>
> Thanks for the help.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 61631
Subject: Re: Avnet Xilinx Virtex II Development Board - getting started
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 08 Oct 2003 05:02:22 GMT
Links: << >>  << T >>  << A >>
"mintchoco" wrote:

> I'm a University student.  I'm very familiar with HDL, I've already
> done my code in Verilog, and I just need to program the device so I
> can test and make sure my code is working.  I'm actually very familiar
> with Actel FPGAs, but never used Xilinx before.  System ACE and boot
> prom stuff is pretty new to me.  The myriad of information on the
> Xilinx website is overwhelming, and that is why I wasn't sure where to
> start.
>
> I'll take a look at those materials you've pointed to, but I've
> already scanned through AVNET documentation that came with the board,
> and it was not very clear what plugs into where and how to 'quickly'
> get started.
>
> > Did you get a JTAG cable?
> So once I get Parallel IV cable, that plugs from my parallel port to
> JTAG directly?  Is there a 'programmer' that I need?  Also, I have ISE
> installed.


OK, good.  Then it sounds like it shouldn't be all that difficult for you to
get going.
Keep in mind that there are architectural differences between what you know
and a VirtexII.

Yes, the parallel cable IV (or III) for that matter, goes between the
parallel port of your PC and the JTAG port on the board.  If you have the
small board with the XC2V40 it would be J100, next to the RS232 port on the
board itself (I just happen to have a small collection of dev boards).

There are several ways to program a Xilinx FPGA:
1- Master Serial
2- Slave Serial
3- Master SelectMAP (Parallel)
4- Slave SelectMAP (Parallel)
5- JTAG

You'll find details in the "Configuration" section of the User Guide I
pointed out to you.

Xilinx FPGA's have volatile configuration memory.  Regardless of which
programming technique you use, if power goes out they wake-up without a
configuration.  There is a hardware option to use battery backup to retain
configuration data as well.  Check the docs.

So, if you don't use the battery option you either use FLASH, SystemACE or
other means of preserving and loading the bitstream during power-up (like a
microprocessor with separate storage).  These various means of bistream
loading can use all of the above techniques to get the bistream loaded.
However, the first four are the most common.

The main difference between the serial and parallel loading methods is, of
course, speed.  Parallel can reach clock rates of around 60MHz.  With an
eight-bit bus you can load a 1 million gate FPGA real fast (only about 4
megabits required).  Serial is probably a better option for a board with
more than one FPGA where you need to create a configuration chain and load
speed might not be crucial.

JTAG and Serial is what you can do with either parallel cable.  They are
called "parallel" cables because of how they connect to your PC.  There's a
programming module called "MultiLynx" which can also do Parallel SelectMAP
but it doesn't seem to be favored.  This one connects to your PC via USB.
You'd think it'd be the better way to go, but the FAE's I've talked to did
not recommend it.  Don't know why.

With both JTAG and Serial SelectMAP you use a program shipped with ISE
called IMPACT.  Use the tools to synthesize, map, place and route your code.
IMPACT would then take your "*.bit" file and either program the FPGA
directly or an attached Xilinx FLASH chip which would, in turn, load the
FPGA to run your code.

I hope that gives you a better picture of what you are up against.  The
board should have shipped with a couple of test bitstreams you could
practice loading.

Oh, yes, if you didn't know, you need to create a UCF file where you'd
assign your pins.  Being that this is a development board, you don't want to
let the tools assign pins at random 'cause you don't know where they might
land.  You don't need to edit the UCF file by hand, you can use the PACE
utility to help you define the pinout (I prefer editing by hand though).


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"





Article: 61632
Subject: Programmimg Altera serial configuration devices
From: Ben Popoola <b.popoola@ntlworld.com>
Date: Wed, 08 Oct 2003 06:09:34 +0100
Links: << >>  << T >>  << A >>
Hi,
    Does anyone have a schematic for the Altera byteblaster II cable or 
has anyone developed a programmer for programming the ALtera EPCS1/4 
family of serial configuration devices.

    I am designing a board and I want to design the programmer into the 
system.

Regards
Ben


Article: 61633
Subject: Visualizing VHDL
From: Kevin Kilzer <kkilzer.remove.this@mindspring.com>
Date: Wed, 08 Oct 2003 05:49:40 GMT
Links: << >>  << T >>  << A >>
When you write VHDL (or Verilog for that matter), do you visualize a
schematic with wires, gates, flops, latches, muxes, etc., or do you
use some other way of thinking about it?

Kevin


Article: 61634
Subject: Re: Visualizing VHDL
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 08 Oct 2003 05:56:44 GMT
Links: << >>  << T >>  << A >>
"Kevin Kilzer" wrote:

> When you write VHDL (or Verilog for that matter), do you visualize a
> schematic with wires, gates, flops, latches, muxes, etc., or do you
> use some other way of thinking about it?

I don't know about visualizing (I do a lot of pencil drawings), but you are
describing hardware.  If you loose that focus you are bound to create
monstruous designs that will not perform well at all.  If you are a hardware
guy it is a subconscious thing to simply think in those terms.  I typically
start with the hardware I want to create and simply use HDL to describe it.
You can either rely on inference (which can be dangerous) or explicitly
instantiate what you need.  I tend to favor actually wiring-up what I want
or using inference when I know that the tools won't screw it up.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 61635
Subject: Re: Visualizing VHDL
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Wed, 08 Oct 2003 16:19:36 +1000
Links: << >>  << T >>  << A >>
On Wed, 08 Oct 2003 05:49:40 GMT, Kevin Kilzer
<kkilzer.remove.this@mindspring.com> wrote:

>When you write VHDL (or Verilog for that matter), do you visualize a
>schematic with wires, gates, flops, latches, muxes, etc., or do you
>use some other way of thinking about it?

I don't think about gates and muxes, because the FPGAs I use have
LUTs.  
So I think about clouds of LUTs and flip flops.  The only significant
thing (for my application) about a cloud of LUTs is the depth, which
determines the delay.

Regards,
Allan.

Article: 61636
Subject: Instantiating LUTs and INIT strings [was Re: Digesting runs of ones or zeros "well"]
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 08 Oct 2003 08:47:02 +0100
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> writes:
<snip>
> A third method is instantiating the LUT4, LUT3 or LUT2 component.  In
> this case, you dont' have a separate component to define, but you do
> have to supply the LUT contents in the form of a hex string in two
> places: once for the INIT=attribute which gets passed onto the edif
> netlist but not to simulation, and once to the INIT generic which is
> used for simulation, but not passed to the netlist.  As I understand
> it, the latest version of synplify passes the INIT generic to the
> netlist, but that is not portable.  Great care has to be taken with
> this method to make sure the simulation matches the synthesized
> hardware.  It is also extraordinarily error prone and difficult to
> read and maintain.  This can be worked around by writing a function to
> parse a boolean expression and convert it to the appropriate INIT
> strings, but it is not trivial to write.
>
<snip>
>... The third is generally too hard to use and maintain without
> a good INIT string generation function, however it does not require a
> large library of 2,3 and 4 input functions.  It is hardly usable
> without the boolean to INIT function however.
> 

Like this one?  I rememebred seeing this mentioned a few weeks ago - a
quick google and I found a link to it... from andraka.com of all
places :-)  [ Ray, you might want to update the link ]

http://www.rockylogic.com/freebies/freebies.html
Scroll down to "Locking Logic to a Single Xilinx Virtex LUT"

Cheers,
Martin
-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 61637
Subject: use of radix-2 ffts
From: stenasc@yahoo.com (Bob)
Date: 8 Oct 2003 01:12:32 -0700
Links: << >>  << T >>  << A >>
Hello again,

Can a radix-4 fft be used to construct any type of radix-2 fft. e.g.
can I manipulate a 64 pt radix-4 fft to give me a 128 pt radix-2 fft ?
If so, is the radix-2 fft of any use in dsp as it usually results in
larger and slower ffts than the radix-4 version.


As always thanks for all replies.

Bob Carter
--
My ignorance is shameful, but I would rather be ashamed than ignorant.
Better, I would rather be neither !!!!

Article: 61638
Subject: Re: More RPM / RLOC fun
From: Goran Bilski <goran@xilinx.com>
Date: Wed, 08 Oct 2003 10:33:43 +0200
Links: << >>  << T >>  << A >>
Hi Martin,

I'm not fluent in verilog. I prefer VHDL but not let start that thread 
again.

When you use U_SET, every primitive within that SET as to have the 
attribute U_SET.
You have to assign the U_SET attribute to all SRL16C and FD in the 
submodule.

That's why I pass along the U_SET name as a generic in my VHDL code.
When you use H_SET, all primitives within a module belong to the same 
SET but for U_SET for have to assign each primitive to the SET.

I have attached a module from MicroBlaze which detect ZERO on one of the 
register values.
Here you can see that I pass along a generic called C_U_SET which is of 
the type string.
I use that value for the attribute value of U_SET.

When I instanciate the module on a higher level, I assign a unique name 
to the generic or giving it a common name if it belongs to a bigger RPM. 
The actual values for the RLOC in this module is calculated in the 
function which exists in a library. That will allow me to handle all 
floorplanning in one place and also handle the difference of the RLOC 
values between "XnYm" and "RnCm.S" for different families. That a nice 
thing with VHDL.

Göran

>>>>>>  insane quote removed by archive manager



Martin Euredjian wrote:

>This is the top module.  It's simple.  I'm using the new attribute syntax to
>specify U_SETs.  It's nice 'cause you can comment these out if you are
>experimenting.
>
>code below.
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Martin Euredjian
>
>To send private email:
>0_0_0_0_@pacbell.net
>where
>"0_0_0_0_"  =  "martineu"
>
>
>
>
>
>module test(
> input wire clk,
> input wire [9:0] a,
> input wire [9:0] b,
> output reg [10:0] total
>);
>
>wire [9:0] a_dly[1:0];
>
>(* U_SET = "DLY00" *)
>SRL_DLY #(.WIDTH (10), .DELAY ( 2)) DLY00(.CLK(clk), .IN(a),
>.Q_OUT(a_dly[0]), .Q15_OUT());
>(* U_SET = "DLY01" *)
>SRL_DLY #(.WIDTH (10), .DELAY ( 4)) DLY01(.CLK(clk), .IN(a),
>.Q_OUT(a_dly[1]), .Q15_OUT());
>
>always @(posedge clk) begin
> total <=  a_dly[0] +  a_dly[1];
>end
>
>endmodule
>
>
>  
>


Article: 61639
Subject: Implementing a fast cache in Altera Cyclone
From: andres.vazquez@gmx.de (Vazquez)
Date: 8 Oct 2003 02:31:57 -0700
Links: << >>  << T >>  << A >>
Hello,

I want to implement a cache which has over 30 words á 2 bytes.
The description of that module should be in VDHL.

The problem I am facing right now is the following:

It should be feasible to write an address into it and to read an
address out of it.
The most important function should be that a new incoming address
should be
checked if it is already in the cache. This check should occur within
some few clocks. The problem is that the cache has over 30 entries so
that
using a FIFO or a RAM-structure would take over 30 clock cycles to
check all the
words.

Has anyone an idea how this problem could be solved basically in order
to achieve a faster check time?

Thank you very much for your help.

Kind regards
Andrés Vázquez
G&D System Development - FPGA design

Article: 61640
Subject: Re: Visualizing VHDL
From: "Simon Peacock" <nowhere@to.be.found>
Date: Wed, 8 Oct 2003 23:18:31 +1300
Links: << >>  << T >>  << A >>
I always visualise what I want, not how I get there..
there's an old saying.. if you keep looking down you will never see the sky.

Same with FPGA's.. if you keep looking at the gates, you miss the big
picture..  VHDL and Verilog allow you to design high level.  think
concepts.. then thing solutions.. same as designing Top Down Software.

Simon

"Kevin Kilzer" <kkilzer.remove.this@mindspring.com> wrote in message
news:qg97ovc5hrf4aii8qe858uljdpg14d5rp9@4ax.com...
> When you write VHDL (or Verilog for that matter), do you visualize a
> schematic with wires, gates, flops, latches, muxes, etc., or do you
> use some other way of thinking about it?
>
> Kevin
>



Article: 61641
Subject: Re: Programmimg Altera serial configuration devices
From: "Simon Peacock" <nowhere@to.be.found>
Date: Wed, 8 Oct 2003 23:19:03 +1300
Links: << >>  << T >>  << A >>
the schematics are on the Altera web site.

"Ben Popoola" <b.popoola@ntlworld.com> wrote in message
news:oVMgb.20449$4D.10223328@newsfep2-win.server.ntli.net...
> Hi,
>     Does anyone have a schematic for the Altera byteblaster II cable or
> has anyone developed a programmer for programming the ALtera EPCS1/4
> family of serial configuration devices.
>
>     I am designing a board and I want to design the programmer into the
> system.
>
> Regards
> Ben
>



Article: 61642
Subject: Re: Should I worry about metastability
From: "Simon Peacock" <nowhere@to.be.found>
Date: Wed, 8 Oct 2003 23:21:12 +1300
Links: << >>  << T >>  << A >>
Have a talk to your friendly Xilinx Apps engineer  Spartan 3's can tolerate
a high jitter (So I've read) .. they just wont tell you that except under
NDA.

Simon


"Ray Andraka" <ray@andraka.com> wrote in message
news:3F8325DD.371B7949@andraka.com...
> Nope,  Jitter out of the video decoders is about 10x what is allowed by
the
> DLL/DCM.  I posted earlier a solution that works fine for this, and is
used in
> a number of my customer's products.
>
>
>
> Simon Peacock wrote:
>
> > If you pick the right xilinx you could multiply the 27MHz up to 108MHz
> > internally.  Just use the internal PLL
> >
> > Simon
> >
> > "Guy Eschemann" <geschemann@yahoo.fr> wrote in message
> > news:b9f16a5b.0310062304.4b75202a@posting.google.com...
> > > > But you said that the clock was not truly asynchronous, but was 4
times
> > > > the data rate, with an unknown ( but stable?) phase relationship.
> > > >
> > >
> > > Maybe my description was a bit confusing, sorry for this. The clocks
> > > really are asychronous. There is no stable phase relationship between
> > > them, since the 27MHz clock is the ouput of a PLL locked on the H-Sync
> > > of a video signal, and the 108MHz system clock is derived from a 27MHz
> > > crystal oscillator.
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 61643
Subject: Re: BF957C Application
From: "Simon Peacock" <nowhere@to.be.found>
Date: Wed, 8 Oct 2003 23:32:42 +1300
Links: << >>  << T >>  << A >>
You could always get it to flash a LED every few seconds :-)

Simon


"Emile" <banktrade2002@yahoo.com> wrote in message
news:952209fb.0310070512.731ec498@posting.google.com...
> Can someone suggest a project/application that would call for an
> XC2V6000-4BF957C?  Thanks.
>
> -Emile



Article: 61644
Subject: Re: synplify vqm not able to fit in Quartus
From: "Simon Peacock" <nowhere@to.be.found>
Date: Wed, 8 Oct 2003 23:36:17 +1300
Links: << >>  << T >>  << A >>
Synplify is suppose to be a better tool..  It should be at the price.  Have
you tried using the Synplify EDF output file as the quartus source file ?

That way you get all the benefit of the synplify work.

Simon


"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
news:3F82F013.5000007@flukenetworks.com...
> Bob wrote:
>
> > I re-synthesized the design again in Synplify and got the same result
> > as before so there is definitely some problem in the flow between the
> > two tools. It certainly looks like I'm back to the drawing board
> > design wise.
> >
> > If you can think of anything else, I would be very grateful.
>
> Maybe you can eliminate the flow between the tools.
> Try bypassing Synplify and process your source files
> directly with Quartus synthesis.
>
>   -- Mike Treseler
>



Article: 61645
Subject: Re: Implementing a fast cache in Altera Cyclone
From: "Hans Brand" <Hans.Brand@BrandInnovators.com>
Date: Wed, 8 Oct 2003 12:53:43 +0200
Links: << >>  << T >>  << A >>
"Vazquez" <andres.vazquez@gmx.de> wrote in message
news:eee19a7a.0310080131.5a53d3f2@posting.google.com...
> Hello,
>
> I want to implement a cache which has over 30 words á 2 bytes.
> The description of that module should be in VDHL.
>
> The problem I am facing right now is the following:
>
> It should be feasible to write an address into it and to read an
> address out of it.
> The most important function should be that a new incoming address
> should be
> checked if it is already in the cache. This check should occur within
> some few clocks. The problem is that the cache has over 30 entries so
> that
> using a FIFO or a RAM-structure would take over 30 clock cycles to
> check all the
> words.
>
> Has anyone an idea how this problem could be solved basically in order
> to achieve a faster check time?
>
> Thank you very much for your help.
>
> Kind regards
> Andrés Vázquez
> G&D System Development - FPGA design

http://www.altera.com/support/software/eda_quartus2/glossary/def_cam.html

Gr, Hans



Article: 61646
Subject: Re: More RPM / RLOC fun
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Wed, 08 Oct 2003 10:56:36 GMT
Links: << >>  << T >>  << A >>
There was an error in the code posted below.  I posted the wrong iteration
of code.
The error had nothing to do with the problem (but didn't help).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:axGgb.12589$g_2.8245@newssvr25.news.prodigy.com...
> This is the module with the RLOCs.
> I'm just hacking away here, so it's not perfect code.
> The long list of RLOC/BEL attributes is there because I haven't been able
to
> figure out how to integrate that into the "generate" portion of the code.
I
> don't see a way to construct the attribute string --even with the V2001
> (*...*) attribute format.  Yet another case for VHDL :-(
>
> Code below.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"
>
>
>
>
> // Generates an SRL-based shift register of the desired word width and
delay
> (in clocks)
> // A minimum delay of 2 clocks is required, as the output is registered.
> // "Q15_OUT" is the cascading SRL output, used to get 16 clocks of delay,
> regardless
> // of the DELAY setting.
> //
>
> module SRL_DLY
> #(parameter WIDTH = 8, DELAY = 2)
> (
>    input   wire  CLK,
>    input   wire [WIDTH - 1:0] IN,
>    output  wire [WIDTH - 1:0] Q_OUT,
>    output  wire [WIDTH - 1:0] Q15_OUT
> );
>
> localparam D = DELAY - 2;
>
> wire [WIDTH - 1:0] qw;
>
> genvar i;
>
> generate
> for(i=0; i < WIDTH; i=i+1) begin:BIT
>  SRLC16 SRL(.Q(qw[i]), .Q15(Q15_OUT[i]), .A3(D[3]), .A2(D[2]), .A1(D[1]),
> .A0(D[0]), .CLK(CLK), .D(IN[i]));
>  FD DFF (.Q (Q_OUT[i]), .C (CLK), .D (qw[i]));
> end
> endgenerate
>
> // RLOC the SRLC16 primitives
> //
> //synthesis attribute RLOC of BIT[0].SRL  is X0Y0
> //synthesis attribute BEL  of BIT[0].SRL  is F
> //synthesis attribute RLOC of BIT[1].SRL  is X0Y0
> //synthesis attribute BEL  of BIT[1].SRL  is G
>
> //synthesis attribute RLOC of BIT[2].SRL  is X0Y1
> //synthesis attribute BEL  of BIT[2].SRL  is F
> //synthesis attribute RLOC of BIT[3].SRL  is X0Y1
> //synthesis attribute BEL  of BIT[3].SRL  is G
>
> //synthesis attribute RLOC of BIT[4].SRL  is X0Y2
> //synthesis attribute BEL  of BIT[4].SRL  is F
> //synthesis attribute RLOC of BIT[5].SRL  is X0Y2
> //synthesis attribute BEL  of BIT[5].SRL  is G
>
> //synthesis attribute RLOC of BIT[6].SRL  is X0Y3
> //synthesis attribute BEL  of BIT[6].SRL  is F
> //synthesis attribute RLOC of BIT[7].SRL  is X0Y3
> //synthesis attribute BEL  of BIT[7].SRL  is G
>
> //synthesis attribute RLOC of BIT[8].SRL  is X0Y4
> //synthesis attribute BEL  of BIT[8].SRL  is F
> //synthesis attribute RLOC of BIT[9].SRL  is X0Y4
> //synthesis attribute BEL  of BIT[9].SRL  is G
>
> //synthesis attribute RLOC of BIT[10].SRL is X0Y5
> //synthesis attribute BEL  of BIT[10].SRL  is F
> //synthesis attribute RLOC of BIT[11].SRL is X0Y5
> //synthesis attribute BEL  of BIT[11].SRL  is G
>
> //synthesis attribute RLOC of BIT[12].SRL is X0Y6
> //synthesis attribute BEL  of BIT[12].SRL  is F
> //synthesis attribute RLOC of BIT[13].SRL is X0Y6
> //synthesis attribute BEL  of BIT[13].SRL  is G
>
> //synthesis attribute RLOC of BIT[14].SRL is X0Y7
> //synthesis attribute BEL  of BIT[14].SRL  is F
> //synthesis attribute RLOC of BIT[15].SRL is X0Y7
> //synthesis attribute BEL  of BIT[15].SRL  is G
>
>
> // RLOC the FF's
> //
> //synthesis attribute RLOC of DFF[0] is X0Y0
> //synthesis attribute BEL  of DFF[0] is FFX
> //synthesis attribute RLOC of DFF[1] is X0Y0
> //synthesis attribute BEL  of DFF[1] is FFY
>
> //synthesis attribute RLOC of DFF[2] is X0Y1
> //synthesis attribute BEL  of DFF[2] is FFX
> //synthesis attribute RLOC of DFF[3] is X0Y1
> //synthesis attribute BEL  of DFF[3] is FFY
>
> //synthesis attribute RLOC of DFF[4] is X0Y2
> //synthesis attribute BEL  of DFF[4] is FFX
> //synthesis attribute RLOC of DFF[5] is X0Y2
> //synthesis attribute BEL  of DFF[5] is FFY
>
> //synthesis attribute RLOC of DFF[6] is X0Y3
> //synthesis attribute BEL  of DFF[6] is FFX
> //synthesis attribute RLOC of DFF[7] is X0Y3
> //synthesis attribute BEL  of DFF[7] is FFY
>
> //synthesis attribute RLOC of DFF[8] is X0Y4
> //synthesis attribute BEL  of DFF[8] is FFX
> //synthesis attribute RLOC of DFF[9] is X0Y4
> //synthesis attribute BEL  of DFF[9] is FFY
>
> //synthesis attribute RLOC of DFF[10] is X0Y5
> //synthesis attribute BEL  of DFF[10] is FFX
> //synthesis attribute RLOC of DFF[11] is X0Y5
> //synthesis attribute BEL  of DFF[11] is FFY
>
> //synthesis attribute RLOC of DFF[12] is X0Y6
> //synthesis attribute BEL  of DFF[12] is FFX
> //synthesis attribute RLOC of DFF[13] is X0Y6
> //synthesis attribute BEL  of DFF[13] is FFY
>
> //synthesis attribute RLOC of DFF[14] is X0Y7
> //synthesis attribute BEL  of DFF[14] is FFX
> //synthesis attribute RLOC of DFF[15] is X0Y7
> //synthesis attribute BEL  of DFF[15] is FFY
>
>
> endmodule
>
>



Article: 61647
Subject: Re: ISE WebPack 6.1 Impact problem
From: Javier =?iso-8859-1?Q?Fern=E1ndez?= Baldomero <javier@atc.ugr.es>
Date: Wed, 08 Oct 2003 13:22:38 +0200
Links: << >>  << T >>  << A >>


> Comparing 5.2 with 6.1, we have found that 5.2 said
> ---------------------------------------------------
>  LPT base address = 0378h.
> ---------------------------------------------------
> 
> but 6.1 says
> ---------------------------------------------------
>  LPT base address = 0B78h.
> ---------------------------------------------------

Hi all, again,

Neil from Xilinx assisted us offline to better diagnose
this problem, and in the process of answering his questions
it came out that another, identical PC in our department
was able to run the software perfectly. Identical since they
were bought at once, same store, same model, same date.
Basically identical SiSoft SANDRA listings.

So, whatever the problem is, it's a problem with that
particular PC, be it hardware, BIOS, XP configuration...
In short: we have found a PC with such a subtle configuration
or hardware failure that it fools iMPACT 6.1 making it believe
that LPT1: is at 0B78 (I love reproducible errors :-)

We'll try to interchange that computer with somebody else's
and upgrade to 6.1 then.

Thanks to all again

-javier

Article: 61648
Subject: Re: More RPM / RLOC fun
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Wed, 08 Oct 2003 21:37:32 +1000
Links: << >>  << T >>  << A >>
On Tue, 07 Oct 2003 19:39:11 -0400, Ray Andraka <ray@andraka.com>
wrote:

>BTW, this is a heckuva lot easier in VHDL with the generate statements.  With
>VHDL you can convert the generate index variable to a string constant to form
>the attribute string.  I don't know of a way to do that in verilog.  For VHDL,
>the code might look like:
>
>L:for i in 0 to width-1 generate
> constant rloc_str : string := "R" & itoa( origin -(i/2))  & "C0" & ".S" &
>itoa(slice mod 2);
> signal l,d,qr,qs: STD_LOGIC;
> attribute BEL of U1:label is bel_lut(i mod 2);
> attribute RLOC   of U1 : label is rloc_str;

Hi Ray,

I've been using Verilog recently.  Verilog got a whole lot better
(read: borrowed some features from VHDL) with the 2001 language
revision.

Pertinent bits added:

new attribute syntax.
generate statements.
constant functions (i.e. functions that can run at elaboration time).
$swrite system task.

It would seem that the above VHDL fragment could be translated to
Verilog as follows:

genvar i;
generate
  for (i = 0; i < width; i=i+1)
  begin
    (* RLOC = $swrite("R%dC0.S", origin -(i/2)) *)
    (* BEL =  i%2 ? "G" : "F" *)

    // instantiate something here

  end
end generate

But there are still problems:

1.  $swrite is a system task, and system tasks can't be used in
constant functions.

2.  The (* name = value *) attribute syntax doesn't seem to allow
anything other than integer values.  I don't have the Verilog 2001
LRM, so I can't say for sure.
This current comp.lang.verilog thread gives some hints:
http://groups.google.com/groups?threadm=3a8e124e.0310071017.75124189%40posting.google.com

3.  This is all new to the Verilog language.  Good tool support isn't
there yet.  The equivalent features have been in VHDL since the '87
version, so the VHDL tool support is a lot better.
Note: XST 6.1 supports the new attributes but the value must be a
string literal, i.e. it's useless for this sort of work.


It looks like I'll have to wait another few years.  Sigh.

Regards,
Allan.

Article: 61649
Subject: Re: Implementing a fast cache in Altera Cyclone
From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
Date: Wed, 8 Oct 2003 12:40:36 +0100
Links: << >>  << T >>  << A >>
"Vazquez" <andres.vazquez@gmx.de> wrote in message
news:eee19a7a.0310080131.5a53d3f2@posting.google.com...

> I want to implement a cache which has over 30 words á 2 bytes.
> It should be feasible to write an address into it and to read an
> address out of it.
> The most important function should be that a new incoming address
> should be
> checked if it is already in the cache. This check should occur within
> some few clocks. The problem is that the cache has over 30 entries so
> that using a FIFO or a RAM-structure would take over 30 clock
> cycles to check all the words.
>
> Has anyone an idea how this problem could be solved basically in order
> to achieve a faster check time?

The usual arrangement in caches is to compute some function of the
address, and use that as the index into your cache.  That way, it's
very easy to locate whether an address is held in the cache.

Typically the "function" is just the bottom few bits of the address,
because this gives a reasonable distribution of cached addresses
into cached locations for many practical problems.

I don't know how big your addresses are, but let's guess they are
16 bits wide.  Let's also suppose that you use the bottom 5 bits
of address to index into your 32-slot cache.  Now let's suppose
you have accessed some locations...

  0x1234  -- uses cache slot 0x14
  0x1235  -- uses cache slot 0x15
  0x9A23  -- uses cache slot 0x03

You can see that this scheme will work well for short sequential
burst accesses.  However, let's now suppose that you make a
fourth access...

  0x7255  -- uses cache slot 0x15

This new access will of course evict the 0x1235 entry from slot 0x15.

To make all this work, each cache slot needs to store...
* those bits of the address that were not used to index it:
  in my example, the top 11 bits
* the cached data
* a "valid" bit, to say that the stored data is correct
* (for write-back caches) a "dirty" bit, saying that the
  cache slot has been written with a new data value, but
  the cached memory location hasn't yet been written with
  this new value

To improve performance, caches can have N-way associativity - in
other words, you have more than one cache slot associated with
each cache index.  This means you have to compare addresses, but
typically only 2 or 4 rather than the full 32.  You can generally
do this with parallel, single-cycle logic.

If indexing on the bottom few bits of address doesn't
suit your requirement, you can use a more sophisticated
address mapping - perhaps some kind of hash function.  It
doesn't matter, as long as the function is repeatable and
distributes addresses onto cache slots in a suitable way.
You would then need to store the whole address in the cache.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                    mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.






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