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 140325

Article: 140325
Subject: Re: Any Experiences with the GN4124 PCI Express - FPGA bridge?
From: "DrBill" <drbill@soaringaudio.com>
Date: Fri, 08 May 2009 15:00:21 -0500
Links: << >>  << T >>  << A >>
>Yesterday, the nice marketing people from Gennum informed me that, in
>their unbiased opinion, their GN4124 PCI Express to Local Bus bridge
>chip is the finest solution that the world has ever seen for connecting
>an FPGA as a PCIe endpoint, and that anyone trying to do so any other
>way is sadly misguided, and will in future years be looked back on
>as a group with flat Earth believers and Chicago Cubs fans.
>
>The surface level stuff I've had a chance to look over on the chip is
>pretty interesting.  At first glance, it should have no trouble handling
>my needs for about a 1 Gbps average throughput and should be pretty
>straightforward.  But before I get too far into the depths of the
>restricted datasheets, driver code samples, provided Verilog, etc, I
>figured I'd go on a quick CAF fishing trip.
>
>Anyone had any experiences with the GN4124?  Or alternatively, with the
>PEX8311 by PLX, which is the only other chip I've managed to find that
>performs a similair task?  The ultimate project goal is going to be a
>PCIe card with an FPGA talking to a mini-ITX running Linux, and I'm
>likely going to be the one doing the coding on all ends.  Total project
>run's only likely about 200, 250 pieces, so it's easier to spend BOM
>money than it is to buy expensive IP or spend weeks and weeks of extra
>coding.
>
>-- 
>Rob Gaddi, Highland Technology
>Email address is currently out of order
>
I have just completed a design using the GN4124 and it worked exactly as
promised.  I had to convert a 15 year old ISA bus RF modem to PCIe bus. 
The data rate on the legacy modem slow and I was considering using the
Gennum GN4124 paired up with a Xilinx FPGA.  Then, found the IP cost for
the Xilinx was 14K$.  I talked with Gennum and found that they have
implemented a 16 bit general purpose I/O port that you can talk to directly
over the PCIe bus.  All the PCIe power up enumeration is handled inside the
GN4124 and you don't even need the Xilinx chip at all. I took the Xilinx
chip off the board and got rid of a ton of development.

I purchased Gennum's RDK and hooked it into the legacy modem and got it
working easily.   They also have another 6 bit port which is also directly
accessible through PCI reads and writes so the total is 22 bits.  The
interrupt system is great.  You can debug the whole interrupt chain inside
the GN4124 by reading and writing a group of registers.  Any pin, either
high or low going edge or both, and high or low level for any pin on the
the 16 bit port.  The 4 legacy PCI interrupts INTA-INTD are supported.  

Xilinx support for a small company is very tough but Gennum support is
excellent.  Phone calls, email - same day usually. 

DrBill
Dr. Bill Avery
S A Engineering 
Reno Nevada 



Article: 140326
Subject: Re: Can the complex DSP archetecture based on FPGA+DSP be replaced by
From: -jg <Jim.Granville@gmail.com>
Date: Fri, 8 May 2009 14:58:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 25, 2:11=A0am, "zhj1985" <zhanghaojun1...@hotmail.com> wrote:
> Generally, the most popular DSP archetecture which focused on complex
> digital signal processing is based on DSP +FPGA. FPGA is often used as a
> coprocessor for a DSP because those PowerPC 440 cores aren't as fast as D=
SP
> and those algorithms which are developed by C language can be developped
> more easily than those developed by Verilog or VHDL language.
>
> However, as the time goes, FPGA has developped fast in recent years. I
> want to ask that whether those complex digital system which was based on
> DPS+FPGA can be replaced by FPGA now. And if it is, then how can I do tha=
t?
> I know Xilinx has developed those software such as system generator, but =
I
> don't know whether it can work out. Does anybody know where I can get mor=
e
> information about those things(By the way, I use Xilinx products)? Thanks=
.

It's a moving target, and depends on your application, and data
bandwidths.
DSPs are falling in price, and include things you will NEVER find on a
FPGA,
like 12 bit 4MSPS ADCs

DSPs also have the memory built in, often FLASH, and also have uA
region
power down modes, and commonly simple, single supply operation.

So IF you can find what you need in a commercial DSP, it is always
likely to be
cheaper, and lower power,  than the incremental cost of adding that to
a FPGA..

FPGAs come into their own, when you cannot find the 'mix' you need in
a DSP

-jg

Article: 140327
Subject: Re: Can the complex DSP archetecture based on FPGA+DSP be replaced by FPGA
From: Al Clark <aclark@danvillesignal.com>
Date: Fri, 08 May 2009 22:11:48 GMT
Links: << >>  << T >>  << A >>
-jg <Jim.Granville@gmail.com> wrote in news:f85bd7c4-841b-45fd-848b-
6e7db0cf36ed@a5g2000pre.googlegroups.com:

> On Mar 25, 2:11 am, "zhj1985" <zhanghaojun1...@hotmail.com> wrote:
>> Generally, the most popular DSP archetecture which focused on complex
>> digital signal processing is based on DSP +FPGA. FPGA is often used as a
>> coprocessor for a DSP because those PowerPC 440 cores aren't as fast as 
D
> SP
>> and those algorithms which are developed by C language can be developped
>> more easily than those developed by Verilog or VHDL language.
>>
>> However, as the time goes, FPGA has developped fast in recent years. I
>> want to ask that whether those complex digital system which was based on
>> DPS+FPGA can be replaced by FPGA now. And if it is, then how can I do 
tha
> t?
>> I know Xilinx has developed those software such as system generator, but 
> I
>> don't know whether it can work out. Does anybody know where I can get 
mor
> e
>> information about those things(By the way, I use Xilinx products)? 
Thanks
> .
> 
> It's a moving target, and depends on your application, and data
> bandwidths.
> DSPs are falling in price, and include things you will NEVER find on a
> FPGA,
> like 12 bit 4MSPS ADCs
> 
> DSPs also have the memory built in, often FLASH, and also have uA
> region
> power down modes, and commonly simple, single supply operation.
> 
> So IF you can find what you need in a commercial DSP, it is always
> likely to be
> cheaper, and lower power,  than the incremental cost of adding that to
> a FPGA..
> 
> FPGAs come into their own, when you cannot find the 'mix' you need in
> a DSP
> 
> -jg
> 

I think that in most cases an FPGA & DSP are good complements. We make a 
dspblok module with a SHARC DSP and and a Cyclone III DSP. 

http://www.danvillesignal.com/dspblok/dspblok-21369+fpga-analog-devices-
adsp-21369-altera-cyclone-iii-dsp-fpga-modules.html

Al Clark
Danville Signal Processing, Inc.








Article: 140328
Subject: Re: OpenCores CAN/Ethernet cores
From: Richard Pennington <rich@pennware.com>
Date: Sat, 09 May 2009 00:13:27 -0500
Links: << >>  << T >>  << A >>
Jukka Marin wrote:
> Dear All,
> 
> I'm wondering whether to use 10/100 Ethernet and CAN controller chips
> (two of each) in a new design or just put cores from OpenCores inside
> an FPGA (which we will need in both cases).  I'm (still) new to FPGA's
> and have never used cores from OpenCores.  Has anybody used these cores?
> Are they reliable and ready for production use?
> 
> The third alternative is to buy commercial IP blocks, but I'm afraid
> they might cost more than the old-fashioned way (the production volumes
> will be relatively small).
> 
> I'd appreciate any facts and/or opinions. :)
> 
>   -jm
Jukka,

Whose FPGA are you using?

-Rich

Article: 140329
Subject: Re: Dual Port RAM Inference
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sat, 09 May 2009 13:02:32 +0100
Links: << >>  << T >>  << A >>
On Fri, 8 May 2009 10:01:30 -0700 (PDT), peter@xilinx.com wrote:

>This is not a Xilinx or Altera circuit design problem,
> nor is it a VHDL problem. It is a systems design issue.

With respect, Peter, it is definitely neither a circuit
design nor a system design problem.  Speaking for myself
(and for Rick too, I'm pretty sure) I know well enough
what the capabilities and limitations of the BRAMs are, 
and how to work with them successfully.  I already
know what form of BRAM I want, and I can easily enough
instantiate it.  I have already chosen a set of 
behaviours that I know are available in both Xilinx 
and Altera BRAMs.

But I don't want the grotesque non-portable ugliness
of instantiated and/or wizard-generated BRAM components.

So I seek a way of writing VHDL and Verilog code that
correctly describes the memories' simulation behaviour,
at the appropriate level of abstraction, and that will
allow a range of synthesis tools to infer correctly the
BRAM properties that I need.  As has already been said by
others, it is not hard to do this for BRAM configurations
with only one write port.  As soon as you add a second
write port, things get much more vexatious and you 
get significantly less help from the coding guidelines
in vendor documentation.  There are good reasons for 
this, as have already been discussed; I made a promise
(which I aim to keep) to find out just what can be
done, and to write it up in a convenient vendor-neutral
form.  Systems design it ain't; it's all about finding 
a valid HDL coding style that reliably gets a desired 
result out of a range of different vendors' tools.
-- 
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

Article: 140330
Subject: Re: Dual Port RAM Inference
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 9 May 2009 11:03:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 9, 5:02=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 8 May 2009 10:01:30 -0700 (PDT), pe...@xilinx.com wrote:
> >This is not a Xilinx or Altera circuit design problem,
> > nor is it a VHDL problem. It is a systems design issue.
>
> With respect, Peter, it is definitely neither a circuit
> design nor a system design problem. =A0Speaking for myself
> (and for Rick too, I'm pretty sure) I know well enough
> what the capabilities and limitations of the BRAMs are,
> and how to work with them successfully. =A0I already
> know what form of BRAM I want, and I can easily enough
> instantiate it. =A0I have already chosen a set of
> behaviours that I know are available in both Xilinx
> and Altera BRAMs.
>
> But I don't want the grotesque non-portable ugliness
> of instantiated and/or wizard-generated BRAM components.
>
> So I seek a way of writing VHDL and Verilog code that
> correctly describes the memories' simulation behaviour,
> at the appropriate level of abstraction, and that will
> allow a range of synthesis tools to infer correctly the
> BRAM properties that I need. =A0As has already been said by
> others, it is not hard to do this for BRAM configurations
> with only one write port. =A0As soon as you add a second
> write port, things get much more vexatious and you
> get significantly less help from the coding guidelines
> in vendor documentation. =A0There are good reasons for
> this, as have already been discussed; I made a promise
> (which I aim to keep) to find out just what can be
> done, and to write it up in a convenient vendor-neutral
> form. =A0Systems design it ain't; it's all about finding
> a valid HDL coding style that reliably gets a desired
> result out of a range of different vendors' tools.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

Why did I call it a systems problem?
The BRAM behaves like a synchronous two-port RAM should, common clock
or uncorrelated clocks, as long as you do not perform "simultaneous"
write and read operations on the same location.
Two writes with conflicting data will leave the content undefined,
while a write and a read can result in an undefined output. Two reads
are no problem.
Protecting against these system issues is quite complicated, and would
sacrifice performance.
What does the user community expect from us (Xilinx)?

Peter Alfke


Article: 140331
Subject: difficulty during processing
From: prashant.gyawali@gmail.com
Date: Sat, 9 May 2009 11:03:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
hi all,
       the clock frequency of my fpga board is 125Mhz and i need to
process data from a sensor which is at 1khz to generate an 8bit data.
for that i tried to sample the data 256 times ie i tried to generate a
clock with frequency 256khz=0.256Mhz. i tried to generate the new
clock by using a counter with followin calculation
125/(2^n)=0.256
n=8.93
so i went for a 9 bit counter taking n=9.
but due to the roundoff there is some error in the design.could
somebody suggest be a better way for sampling the data.
any suggestions would be highly appreciated.

also what i would like to know is , is using the counter  only way for
achieving lower frequency clocks or are ther other alternatives with
more accurecy?
any suggestions would be highly aprreciated.
thank you


Article: 140332
Subject: Re: Dual Port RAM Inference
From: Mike Treseler <mtreseler@gmail.com>
Date: Sat, 09 May 2009 11:18:19 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Protecting against these system issues is quite complicated, and would
> sacrifice performance.
> What does the user community expect from us (Xilinx)?

What if we wrote you a vhdl and verilog model
that captures your English description above
and a testbench to demonstrate that modelsim agrees.

Then you would give the models to the right person
and see to it that ise will synthesize
a netlist that passes the same testbench.

     -- Mike Treseler

Article: 140333
Subject: Re: Dual Port RAM Inference
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 9 May 2009 20:25:04 +0200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Why did I call it a systems problem?
> The BRAM behaves like a synchronous two-port RAM should, common clock
> or uncorrelated clocks, as long as you do not perform "simultaneous"
> write and read operations on the same location.
> Two writes with conflicting data will leave the content undefined,
> while a write and a read can result in an undefined output. Two reads
> are no problem.
> Protecting against these system issues is quite complicated, and would
> sacrifice performance.
> What does the user community expect from us (Xilinx)?

I didn't need such a feature so far, but with Altera Quartus you can
specify for dual port RAMs, if you want to read the old content when
simultaneous writing at the same location, or you can speficy "I don't
care" (which I assume is faster). Maybe this features makes sense for some
projects.

But I don't think that it makes sense to specify the behaviour, if a BRAM
has two write ports and from both ports are written to the same address
simultaneously. And if it makes sense, it should be easy to catch this rare
case in user logic, e.g. a simple priority algorithm with static logic.
Implementing this for the write/read-case in user logic would be more
complicated and maybe slower than what is possible with low-level support.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 140334
Subject: Re: difficulty during processing
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 9 May 2009 14:53:18 -0400
Links: << >>  << T >>  << A >>

<prashant.gyawali@gmail.com> wrote in message 
news:8cee21a7-2632-4552-b023-e4f4bce56ba2@e23g2000vbe.googlegroups.com...
> hi all,
>       the clock frequency of my fpga board is 125Mhz and i need to
> process data from a sensor which is at 1khz to generate an 8bit data.
> for that i tried to sample the data 256 times ie i tried to generate a
> clock with frequency 256khz=0.256Mhz. i tried to generate the new
> clock by using a counter with followin calculation
> 125/(2^n)=0.256
> n=8.93
> so i went for a 9 bit counter taking n=9.
> but due to the roundoff there is some error in the design.could
> somebody suggest be a better way for sampling the data.
> any suggestions would be highly appreciated.
>

Counters do not need need to count through their entire 2^n cycle.  You know 
the FPGA clock period, you know the sensor clock period, the ratio of those 
two times tells you how many FPGA clocks there are per sensor period...so 
you create a counter that counts in that range, you don't round it up to the 
next 2^n count.  Below is some VHDL code to mull over.

From your description, I'm not sure what exactly you're trying to do with 
your sensor data.  It sounds like you can sample it at a 1KHz rate, but 
don't really get what in the world you're trying to do with the 256 KHz that 
you mentioned.  The code below shows you how to create a timer for an 
arbitrary constant time period which seems like the root problem you're 
trying to understand.  Once you have the basic counter, you can use that to 
do all kinds of things at any point in the counter's sequence.  As an 
example, I created a 'Sensor_Clock' that would be a free running 1 KHz, 50% 
duty cycle signal.  You can also decode whatever other counter values you'd 
like if you need to do something at different points (i.e. there is nothing 
special about the constant 'HALF_PERIOD' used in the code below, it's just a 
number).  If you want to define 256 points within that cycle where you do 
something you simply define 256 constant values that you will compare with 
'Sensor_Counter' (which I'm guessing is where you came up with the 256 KHz, 
but not sure what the significance of those 256 points are).  Those 256 
points don't necessarily have to be evenly spaced.

The only error sources (i.e. deviations from sampling at exactly 1 KHz) that 
are caused by the code below itself are:
- The resolution of the FPGA clock.  In this particular case, the 8ns 
resolution of the FPGA clock will not be an issue, but if you're trying to 
time something that is not an integer multiple of 8ns clocks it might 
matter.
- In general, you can't count on the ratio of your generated clock period to 
your system clock period to be an exact multiple.  In this case (125 MHz and 
1 KHz) it happens to work out nicely to be exactly 125,000.  The computation 
of 'FPGA_CLKS_PER_SENSOR_PERIOD' in the code below will always truncate any 
fractional part.  This can be fixed so that a rounding occurs, but this is 
left as an exercise to the reader.

constant CLOCK_PERIOD:    time    := 1 us / 125; -- Define the clock period 
of the FPGA clock
constant SENSOR_PERIOD:  time    := 1 ms;
constant FPGA_CLKS_PER_SENSOR_PERIOD: natural := CLOCK_PERIOD / 
SENSOR_PERIOD;
signal Sensor_Counter: natural range 0 to FPGA_CLKS_PER_SENSOR_PERIOD;
...
process(Fpga_Clock)
  constant HALF_PERIOD:  natural := FPGA_CLKS_PER_SENSOR_PERIOD / 2;
begin
  if rising_edge(Fpga_Clock) then
    -- Create a counter of the proper period
    if (Reset = '1') or (Sensor_Counter = 0) then
      Sensor_Counter <= FPGA_CLKS_PER_SENSOR_PERIOD;
    else
      Sensor_Counter <= Sensor_Counter - 1;
    end if;
   -- I'm guessing you want some form of sensor clock to run at 1KHz, not 
sure
   if (Reset = '1') or (Sensor_Counter = 0) then
     Sensor_Clock <= '0';
  elsif (Sensor_Counter = HALF_PERIOD) then
     Sensor_Clock <= '1';
  end if;
end process;

> also what i would like to know is , is using the counter  only way for
> achieving lower frequency clocks or are ther other alternatives with
> more accurecy?

In FPGAs or CPLDs, the counter is the only way that you will be able to come 
up with a robust design that always works.  Another approach would be PLLs 
built into the part, but I don't think this would be appropriate for the 
frequencies you are talking about (i.e. the 1 KHz sensor) since it is rather 
needlessly generating a new clock domain that I'm sure you'll be wanting to 
transfer data from into the FPGA clock domain.

Kevin Jennings 



Article: 140335
Subject: Re: difficulty during processing
From: "KJ" <kkjennings@sbcglobal.net>
Date: Sat, 9 May 2009 15:03:27 -0400
Links: << >>  << T >>  << A >>

"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:EikNl.15989$hc1.2627@flpi150.ffdc.sbc.com...

Oops, this...
> constant FPGA_CLKS_PER_SENSOR_PERIOD: natural := CLOCK_PERIOD / 
> SENSOR_PERIOD;

Should be...
constant FPGA_CLKS_PER_SENSOR_PERIOD: natural := SENSOR_PERIOD / 
CLOCK_PERIOD;

KJ 



Article: 140336
Subject: Re: ISE 10.1 installation troubles on windows Vista 32bit
From: andip1982 <andreasp1982@arcor.de>
Date: Sat, 9 May 2009 12:38:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 30 Apr., 08:18, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> "Benjamin Couillard" <benjamin.couill...@gmail.com> wrote in message
>
> news:d4b34802-28fe-48dd-a4e8-28d812bb0f50@r13g2000vbr.googlegroups.com...
>
> > Hi, I've downloaded ISE 10.1 =A0and I'm now trying to install it on my
> > PC. Every time I click on setup.exe, the program crashes and I get an
> > error message from Windows.
>
> > I tried running it as an administrator, I tried running it with
> > "windows xp compatability mode" and it still doesn't work. What's
> > weird is that I've installed ISE 9.2 without any problems. It seems
> > that Vista home is not officially supported by Xilinx since they only
> > mention Vista Business on ISE 10.1 webpage. However, it should stil
> > work with Vista Home.
>
> I recall very **vaguely** some issues running the downloaded installers o=
n
> XP, so assume for now and pursue it as though it were not an OS issue. It
> wass long ago, and I don't recall the details. They all worked with some
> trick. Something like right click/Install; or unzip and then run the
> installer; or move the download to a different directory, maybe one witho=
ut
> spaces in the path... As I said, I don't recall, but all the 10.1 product
> installers had the same problem on my system, and all installed fine with
> the same trick.

Well I think it IS an OS issue. I found ISE 10.x =FAnable to operate on
3 different machines now using Vista home.


Article: 140337
Subject: Which alternative prog to use for hdl handling ?
From: andip1982 <andreasp1982@arcor.de>
Date: Sat, 9 May 2009 12:41:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am searching for a simple tool to handle hdl entities similar to
mentor hdl designer. no hdl synthesis required - just edit entites
graphically and keep overview over the hierarchies.

any idea ?

Article: 140338
Subject: Re: Dual Port RAM Inference
From: rickman <gnuarm@gmail.com>
Date: Sat, 9 May 2009 13:03:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 9, 2:03=A0pm, Peter Alfke <al...@sbcglobal.net> wrote:
> On May 9, 5:02=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
> wrote:
>
>
>
> > On Fri, 8 May 2009 10:01:30 -0700 (PDT), pe...@xilinx.com wrote:
> > >This is not a Xilinx or Altera circuit design problem,
> > > nor is it a VHDL problem. It is a systems design issue.
>
> > With respect, Peter, it is definitely neither a circuit
> > design nor a system design problem. =A0Speaking for myself
> > (and for Rick too, I'm pretty sure) I know well enough
> > what the capabilities and limitations of the BRAMs are,
> > and how to work with them successfully. =A0I already
> > know what form of BRAM I want, and I can easily enough
> > instantiate it. =A0I have already chosen a set of
> > behaviours that I know are available in both Xilinx
> > and Altera BRAMs.
>
> > But I don't want the grotesque non-portable ugliness
> > of instantiated and/or wizard-generated BRAM components.
>
> > So I seek a way of writing VHDL and Verilog code that
> > correctly describes the memories' simulation behaviour,
> > at the appropriate level of abstraction, and that will
> > allow a range of synthesis tools to infer correctly the
> > BRAM properties that I need. =A0As has already been said by
> > others, it is not hard to do this for BRAM configurations
> > with only one write port. =A0As soon as you add a second
> > write port, things get much more vexatious and you
> > get significantly less help from the coding guidelines
> > in vendor documentation. =A0There are good reasons for
> > this, as have already been discussed; I made a promise
> > (which I aim to keep) to find out just what can be
> > done, and to write it up in a convenient vendor-neutral
> > form. =A0Systems design it ain't; it's all about finding
> > a valid HDL coding style that reliably gets a desired
> > result out of a range of different vendors' tools.
> > --
> > Jonathan Bromley, Consultant
>
> > DOULOS - Developing Design Know-how
> > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> > The contents of this message may contain personal views which
> > are not the views of Doulos Ltd., unless specifically stated.
>
> Why did I call it a systems problem?
> The BRAM behaves like a synchronous two-port RAM should, common clock
> or uncorrelated clocks, as long as you do not perform "simultaneous"
> write and read operations on the same location.
> Two writes with conflicting data will leave the content undefined,
> while a write and a read can result in an undefined output. Two reads
> are no problem.
> Protecting against these system issues is quite complicated, and would
> sacrifice performance.
> What does the user community expect from us (Xilinx)?

I'm not sure you are talking about the same problem that we are.  We
don't have a problem with how the block ram works.  We just want to be
able to use them without using instantiation, for a number of
reasons.  Block rams can be inferred as long as they are used in
single port or pseudo dual port modes.  But if they are needed with
two write ports, the tools have a lot of trouble inferring a dual port
block ram.  The error message I got from XST 10.1 clearly showed that
the tools understood that I wanted a ram with two write ports, but it
could not figure out that I wanted it to use the block ram.

Or am I missing something about your statements that affect this
issue?

Actually, the VHDL description of a block ram that uses two processes
to write to the same memory also has undefined behavior.  If both
processes write to the same location using the same clock edge, it is
undefined which process will run first and which will run second; so
the result written to the block ram is undefined... maybe not in the
same way as the hardware, but it is still undefined.

Rick

Article: 140339
Subject: Re: ISE 10.1 installation troubles on windows Vista 32bit
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Sat, 9 May 2009 15:35:46 -0500
Links: << >>  << T >>  << A >>
"andip1982" <andreasp1982@arcor.de> wrote in message 
news:3dfee53c-de02-48f3-8e73-282ed26d6a45@t11g2000vbc.googlegroups.com...
On 30 Apr., 08:18, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> "Benjamin Couillard" <benjamin.couill...@gmail.com> wrote in message
>
> news:d4b34802-28fe-48dd-a4e8-28d812bb0f50@r13g2000vbr.googlegroups.com...
>
> > Hi, I've downloaded ISE 10.1 and I'm now trying to install it on my
> > PC. Every time I click on setup.exe, the program crashes and I get an
> > error message from Windows.
>
> > I tried running it as an administrator, I tried running it with
> > "windows xp compatability mode" and it still doesn't work. What's
> > weird is that I've installed ISE 9.2 without any problems. It seems
> > that Vista home is not officially supported by Xilinx since they only
> > mention Vista Business on ISE 10.1 webpage. However, it should stil
> > work with Vista Home.
>
> I recall very **vaguely** some issues running the downloaded installers on
> XP, so assume for now and pursue it as though it were not an OS issue. It
> wass long ago, and I don't recall the details. They all worked with some
> trick. Something like right click/Install; or unzip and then run the
> installer; or move the download to a different directory, maybe one 
> without
> spaces in the path... As I said, I don't recall, but all the 10.1 product
> installers had the same problem on my system, and all installed fine with
> the same trick.

Well I think it IS an OS issue. I found ISE 10.x únable to operate on
3 different machines now using Vista home.

========
Maybe. They do take care teo specifically say XP Business in the system 
requirements.

I also rediscovered how some installers dislike spaces in path names. I went 
through several tens of gigabytes of upgrades here recently.



Article: 140340
Subject: Re: Which alternative prog to use for hdl handling ?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Sat, 09 May 2009 22:04:23 +0100
Links: << >>  << T >>  << A >>
On Sat, 9 May 2009 12:41:34 -0700 (PDT), andip1982
<andreasp1982@arcor.de> wrote:

>I am searching for a simple tool to handle hdl entities similar to
>mentor hdl designer. no hdl synthesis required - just edit entites
>graphically and keep overview over the hierarchies.

You say "no synthesis required", but in fact what you're
asking for is synthesis of all but the leaf instances (i.e.
those that don't themselves contain any instances).  You
can easily do this for simple cases, but if someone is using
the full power of Verilog or VHDL generates to create an
interesting hierarchy, nothing short of full processing
of the language will do.

In fact I think you will find that the big-name FPGA
tools (Quartus, ISE) provide pretty much what you need,
for low or zero cost.  You can edit schematics (perish the
thought) and create an HDL netlist from them.  Good luck.
-- 
Jonathan Bromley, Consultant

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

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

Article: 140341
Subject: Re: Dual Port RAM Inference
From: Sandro <sdroamt@netscape.net>
Date: Sat, 9 May 2009 14:26:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rick,
I hope this can help...
below you can find the code to infer dual port-ram with
both port sharing the same clock.
I suppose the secret could be using a shared variable (instead of a
signal) as RAM...

regards
Sandro


entity ramInference is
  generic (
    g_data_w : natural := 9;
    g_addr_w : natural := 11
    );
  port (
    i_clkA  : in  std_logic;
    --i_clkB  : in  std_logic;
    i_enA   :     std_logic;
    i_weA   :     std_logic;
    i_addrA : in  std_logic_vector (g_addr_w - 1 downto 0);
    i_dataA : in  std_logic_vector (g_data_w - 1 downto 0);
    o_dataA : out std_logic_vector (g_data_w - 1 downto 0);

    i_enB   :     std_logic;
    i_weB   :     std_logic;
    i_addrB : in  std_logic_vector (g_addr_w - 1 downto 0);
    i_dataB : in  std_logic_vector (g_data_w - 1 downto 0);
    o_dataB : out std_logic_vector (g_data_w - 1 downto 0)
    );
end ramInference;


architecture Behavioral of ramInference is

  constant c_ram_sz : natural := 2**(g_addr_w);

  type t_ram is array (c_ram_sz - 1 downto 0) of
    std_logic_vector (g_data_w - 1 downto 0);

  shared variable v_ram : t_ram := (
    1      => X"05",
    2      => X"08",
    3      => X"1A",
    -- ...
    others => X"00"
    );

begin

  p_portA : process (i_clkA)
  begin
    if rising_edge(i_clkA) then
      if (i_enA = '1') then
        -- READ FIRST
        o_dataA(g_data_w - 1 downto 0) <= v_ram(conv_integer
(i_addrA));
        -- WRITE AFTER
        if (i_weA = '1') then
          v_ram(conv_integer(i_addrA)) := i_dataA(g_data_w - 1 downto
0);
        end if;
      end if;
    end if;
  end process;

  p_portB : process (i_clkA)
  begin
    if rising_edge(i_clkA) then
      if (i_enB = '1') then
        -- WRITE FIRST
        if (i_weB = '1') then
          v_ram(conv_integer(i_addrB)) := i_dataB(g_data_w - 1 downto
0);
        end if;
        -- READ AFTER
        o_dataB(g_data_w - 1 downto 0) <= v_ram(conv_integer
(i_addrB));
      end if;
    end if;
  end process;

end Behavioral;

Article: 140342
Subject: Re: Dual Port RAM Inference
From: Jacko <jackokring@gmail.com>
Date: Sat, 9 May 2009 14:26:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
The BRAM does not have the necessary dual address decoders. The best
option is to clock at half speed and multiplex. Read before write is
most usual.

Article: 140343
Subject: Re: Dual Port RAM Inference
From: Peter Alfke <alfke@sbcglobal.net>
Date: Sat, 9 May 2009 15:15:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 9, 2:26=A0pm, Jacko <jackokr...@gmail.com> wrote:
> The BRAM does not have the necessary dual address decoders. The best
> option is to clock at half speed and multiplex. Read before write is
> most usual.

All Xilinx BRAMs have dual address decoders, and each port also has
the option of read before or after write or retain previous output.
It seems there is no argument about the hardware, but there is about
the software...
Peter Alfke

Article: 140344
Subject: Re: Dual Port RAM Inference
From: Sandro <sdroamt@netscape.net>
Date: Sat, 9 May 2009 15:31:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 10, 12:15=A0am, Peter Alfke <al...@sbcglobal.net> wrote:
> All Xilinx BRAMs have dual address decoders, and each port also has
> the option of read before or after write or retain previous output.
> It seems there is no argument about the hardware, but there is about
> the software...
> Peter Alfke

Peter,
This time... (quite) no argument about the software too (see my
previous post).
XST (your software [xilinx]) infers the bram with two r/w ports both
with "READ FIRST" and with "WRITE FIRST" options...

Maybe the only software (vhdl) argument could be "how to infer dual
port BRAM with
different bus sizes for the two ports"

regards
Sandro

Article: 140345
Subject: Re: Dual Port RAM Inference
From: Brian <scubabrian@gmail.com>
Date: Sat, 9 May 2009 21:00:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 9, 4:31=A0pm, Sandro <sdro...@netscape.net> wrote:
>
> Peter,
> This time... (quite) no argument about the software too (see my
> previous post).
> XST (your software [xilinx]) infers the bram with two r/w ports both
> with "READ FIRST" and with "WRITE FIRST" options...
>
> Maybe the only software (vhdl) argument could be "how to infer dual
> port BRAM with
> different bus sizes for the two ports"
>
> regards
> Sandro

Thought I would chime in on some of the comments and observations from
this thread.  Starting with the most recent comment, if you need
different port widths in either the read vs. write of the same port or
different widths on the dual port, you do need to instantiate.
Neither XST, Synplify or Precision support RAMs with different port
widths.  I can comment from the XST side that we have investigated
this and plan to some day offer this however to date, have not been
able to include this capability.

As Sandro explains, you should be able to infer a common clock dual
port RAM (assuming same port widths) in any of the READ_FIRST,
WRITE_FIRST or NO_CHANGE modes.  It is fairly straightforward in
verilog to code this however for VHDL as explained, you do need to use
a shared variable to accomplish this.  I am more familiar with Verilog
than VHDL but my understanding is that the shared variable is
necessary for proper simulation when accessing the same array at the
same time.  In terms of coding examples for these RAMs, most of the
coding examples can be found in the Xilinx Language Templates which
are accessible from Xilinx Project Navigator.  Open the Templates and
look in VHDL or Verilog --> Synthesis Constructs --> Coding Examples --
> RAM to see several examples.  In the Single-Port descriptions you
can see the differences between READ_FIRST, WRITE_FIRST and NO_CHANGE
mode however unfortunately for the dual port not all have been adapted
there but in theory should work.  I will see if in 11.2 we can get the
templates updated to include all of the dual port examples for these.
One other note, if you are inferring a BRAM in which you never plan to
read from the same port at the time you are writing, describe
NO_CHANGE mode.  It will save power but not many realize this.

In terms of memory collisions (writing to the same memory address on a
dual port RAM as either reading or writing on the other) this
described in the device User Guides and the Synthesis and Simulation
Design Guide so I hope that most understand what it is and what should
be done to avoid them however as for inferring dual-port BRAM, you do
need to heed more caution.  A behavioral RTL simulation will not alert
or model a collision so you can very well simulate a collision
behaviorally and get a seemingly valid result but the implementation
can give something different.  This is not covered by static timing
analysis as this is a dynamic situation.  It can be covered and
alerted by timing simulation however many choose not to do timing
simulations so in lieu of that some synthesis tools have decided to
arbitrate the access to the same memory locations with additional
logic around the BRAM.  Both Synplicity and Precision do this however
XST does not.  Most people who are aware of this, disable the addition
of the collision avoidance logic using a synthesis attribute as it can
slow the RAM down, add more resources and add more power to the FPGA
design and in many cases is not needed however if you do disable this,
you need to take extra care to ensure an undetected collision will not
give undesired results in your design.  I too try to avoid
instantiation of BRAM however one advantage it does give you is it
will alert you to a memory collision as it is modeled in the UNISIM.
As mentioned before a timing simulation (no matter how the RAM was
entered) can also detect this. In system testing, can not detect
this.  Reason being, collisions are as unpredictable as a timing error
and while a system may behave one way in one device in one
environmental condition (temperature or voltage) during a collision,
it may behave differently in another device or under a different
environmental condition) so I would not trust in-system testing to
this any more than I would a timing violation.

Hopefully this clears up some of the issues identified in this
thread.  I often do infer RAMs in my designs however there are certain
circumstances (such as different port widths) that necessitate
instantiation so we are still not in a full RTL world when it comes to
RAMs.  However more situations than most know can be inferred with
relative ease (i.e. dual-port, byte enables, read modes,
initialization from an external file, all can be inferred now).

Regards,

--  Brian Philofsky
--  Xilinx Applications

Article: 140346
Subject: Re: Dual Port RAM Inference
From: Sandro <sdroamt@netscape.net>
Date: Sun, 10 May 2009 00:50:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 10, 6:00=A0am, Brian <scubabr...@gmail.com> wrote:
> On May 9, 4:31=A0pm, Sandro <sdro...@netscape.net> wrote:
>
>
>
> > Peter,
> > This time... (quite) no argument about the software too (see my
> > previous post).
> > XST (your software [xilinx]) infers the bram with two r/w ports both
> > with "READ FIRST" and with "WRITE FIRST" options...
>
> > Maybe the only software (vhdl) argument could be "how to infer dual
> > port BRAM with
> > different bus sizes for the two ports"
>
> > regards
> > Sandro
>
> Thought I would chime in on some of the comments and observations from
> this thread. =A0Starting with the most recent comment, if you need
> different port widths in either the read vs. write of the same port or
> different widths on the dual port, you do need to instantiate.
> Neither XST, Synplify or Precision support RAMs with different port
> widths. =A0I can comment from the XST side that we have investigated
> this and plan to some day offer this however to date, have not been
> able to include this capability.
>
> As Sandro explains, you should be able to infer a common clock dual
> port RAM (assuming same port widths) in any of the READ_FIRST,
> WRITE_FIRST or NO_CHANGE modes. =A0It is fairly straightforward in
> verilog to code this however for VHDL as explained, you do need to use
> a shared variable to accomplish this. =A0I am more familiar with Verilog
> than VHDL but my understanding is that the shared variable is
> necessary for proper simulation when accessing the same array at the
> same time. =A0In terms of coding examples for these RAMs, most of the
> coding examples can be found in the Xilinx Language Templates which
> are accessible from Xilinx Project Navigator. =A0Open the Templates and
> look in VHDL or Verilog --> Synthesis Constructs --> Coding Examples --> =
RAM to see several examples. =A0In the Single-Port descriptions you
>
> can see the differences between READ_FIRST, WRITE_FIRST and NO_CHANGE
> mode however unfortunately for the dual port not all have been adapted
> there but in theory should work. =A0I will see if in 11.2 we can get the
> templates updated to include all of the dual port examples for these.
> One other note, if you are inferring a BRAM in which you never plan to
> read from the same port at the time you are writing, describe
> NO_CHANGE mode. =A0It will save power but not many realize this.
>
> In terms of memory collisions (writing to the same memory address on a
> dual port RAM as either reading or writing on the other) this
> described in the device User Guides and the Synthesis and Simulation
> Design Guide so I hope that most understand what it is and what should
> be done to avoid them however as for inferring dual-port BRAM, you do
> need to heed more caution. =A0A behavioral RTL simulation will not alert
> or model a collision so you can very well simulate a collision
> behaviorally and get a seemingly valid result but the implementation
> can give something different. =A0This is not covered by static timing
> analysis as this is a dynamic situation. =A0It can be covered and
> alerted by timing simulation however many choose not to do timing
> simulations so in lieu of that some synthesis tools have decided to
> arbitrate the access to the same memory locations with additional
> logic around the BRAM. =A0Both Synplicity and Precision do this however
> XST does not. =A0Most people who are aware of this, disable the addition
> of the collision avoidance logic using a synthesis attribute as it can
> slow the RAM down, add more resources and add more power to the FPGA
> design and in many cases is not needed however if you do disable this,
> you need to take extra care to ensure an undetected collision will not
> give undesired results in your design. =A0I too try to avoid
> instantiation of BRAM however one advantage it does give you is it
> will alert you to a memory collision as it is modeled in the UNISIM.
> As mentioned before a timing simulation (no matter how the RAM was
> entered) can also detect this. In system testing, can not detect
> this. =A0Reason being, collisions are as unpredictable as a timing error
> and while a system may behave one way in one device in one
> environmental condition (temperature or voltage) during a collision,
> it may behave differently in another device or under a different
> environmental condition) so I would not trust in-system testing to
> this any more than I would a timing violation.
>
> Hopefully this clears up some of the issues identified in this
> thread. =A0I often do infer RAMs in my designs however there are certain
> circumstances (such as different port widths) that necessitate
> instantiation so we are still not in a full RTL world when it comes to
> RAMs. =A0However more situations than most know can be inferred with
> relative ease (i.e. dual-port, byte enables, read modes,
> initialization from an external file, all can be inferred now).
>
> Regards,
>
> -- =A0Brian Philofsky
> -- =A0Xilinx Applications

Brian,
thanks for your answer ... you avoided me to waste time
trying to figure out how the ram can be represented (in vhdl) as two
array with "different geometry" (read dual port with different
bus sizes).


Peter Alfke wrote:
> ...
> What does the user community expect from us (Xilinx)?
> ...
(...winking to Peter) that is what the user
community expect from you (Xilinx) ;-)

regards
Sandro

Article: 140347
Subject: implementing arbitrary combinational functions using block rams
From: anand <writeanand@gmail.com>
Date: Sun, 10 May 2009 00:51:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

I am looking to get some info on implementing arbitrary combinational
functions in large designs using block rams (BRAMs). The target is an
emulation platform using Virtex 4 fpgas

For example

assign x = ^a
  where a is an 8 bit input for example.

in normal fpga synthesis will use LUTS.

However I can declare a memory as

reg [255:0] lookuptable_for_bitwise_xor_mem;

always@(a) begin

x <=  lookuptable_for_bitwise_xor_mem[a];
end

I would have pre loaded  lookuptable_for_bitwise_xor_mem with the
truth table for 8 input bitwise XOR.

Note that this is just one example.

The advantage is that I use little LUTs and only Block RAMs (which are
unused otherwise), therefore rducing area.

If there is another assign that takes a bitwise xor of 8 bit vector, I
can use the same ROM and reuse the ROM.

Example:




assign x = ^a
assign y = ^b
 where a, b is an 8 bit input for example.

becomes

always@(a or b) begin

x <=  lookuptable_for_bitwise_xor_mem[a];
y <=  lookuptable_for_bitwise_xor_mem[b];

end

 I am basically trying to use BRAMs that are unused anyway - there are
more than 300 BRAMs per Virtex 4 FPGA each of 16K.

Now the question is - is this a feasible way to reduce LUTs and
thereby area? .


-Andy


Article: 140348
Subject: Re: implementing arbitrary combinational functions using block rams
From: Jacko <jackokring@gmail.com>
Date: Sun, 10 May 2009 03:49:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 10, 8:51=A0am, anand <writean...@gmail.com> wrote:
> Hi
>
> I am looking to get some info on implementing arbitrary combinational
> functions in large designs using block rams (BRAMs). The target is an
> emulation platform using Virtex 4 fpgas
>
> For example
>
> assign x =3D ^a
> =A0 where a is an 8 bit input for example.
>
> in normal fpga synthesis will use LUTS.
>
> However I can declare a memory as
>
> reg [255:0] lookuptable_for_bitwise_xor_mem;
>
> always@(a) begin
>
> x <=3D =A0lookuptable_for_bitwise_xor_mem[a];
> end
>
> I would have pre loaded =A0lookuptable_for_bitwise_xor_mem with the
> truth table for 8 input bitwise XOR.
>
> Note that this is just one example.
>
> The advantage is that I use little LUTs and only Block RAMs (which are
> unused otherwise), therefore rducing area.
>
> If there is another assign that takes a bitwise xor of 8 bit vector, I
> can use the same ROM and reuse the ROM.
>
> Example:
>
> assign x =3D ^a
> assign y =3D ^b
> =A0where a, b is an 8 bit input for example.
>
> becomes
>
> always@(a or b) begin
>
> x <=3D =A0lookuptable_for_bitwise_xor_mem[a];
> y <=3D =A0lookuptable_for_bitwise_xor_mem[b];
>
> end
>
> =A0I am basically trying to use BRAMs that are unused anyway - there are
> more than 300 BRAMs per Virtex 4 FPGA each of 16K.
>
> Now the question is - is this a feasible way to reduce LUTs and
> thereby area? .
>
> -Andy

The double use needs two address decoders, and so does not work as far
as I am aware. The same table would have to be duplicated in two
BRAMs.

cheers jacko

Article: 140349
Subject: Re: implementing arbitrary combinational functions using block rams
From: whygee <whygee@yg.yg>
Date: Sun, 10 May 2009 13:42:37 +0200
Links: << >>  << T >>  << A >>
anand wrote:
> Hi
<snip>
>  I am basically trying to use BRAMs that are unused anyway - there are
> more than 300 BRAMs per Virtex 4 FPGA each of 16K.
> 
> Now the question is - is this a feasible way to reduce LUTs and
> thereby area? .

(warning : it's just a guess, not even an opinion or experiment result)

It helps, I presume.
You should target the complex logic operations, or (if there are
enough address pins) you can even provide a quite fast "logic reduction"
(the OR or AND of many inputs).

However the overall speed will be different, and not necessarily faster.
This is because LUTs are regularly spread all over the chip, but
BRAMs are in certain places. So place&route will be more constrained
than before, may resulting in slightly longer wires and slower signals.

OTOH if your design is already filling the FPGA, and speed is not an issue,
it looks like a good method.

> -Andy
yg

-- 
http://ygdes.com / http://yasep.org



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