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 92300

Article: 92300
Subject: Distributed RAMs / SRL: Why not, Altera?
From: Michael Kramer <michikramer@compuserve.de>
Date: Sat, 26 Nov 2005 12:22:17 +0100
Links: << >>  << T >>  << A >>
Hello,

currently we are working on relatively large project with a focus on 
signal processing algorithms. Some months ago we decided to use the 
Altera Stratix II Family for a number of reasons. Some of them were the 
highly versatile analog PLLs the better balance between logic an dsp 
blocks compared to the specialist Virtex 4 LX/SX.

But now onwarding in the development process we miss one feature of 
Xilinx Devices more an more: The ability to use the LUTs of a logic cell 
  for storage. This enables the effective implementation of RAM and 
shift registers in the logic without wasting huge amounts of registers. 
The Altera hint to use the fine grained memory blocks (M512, M4K) is no 
real alternative because you waste a lot of memory when implementing 
e.g. small coefficent memory or shift registers with many taps. And in 
our application memory is rare..

I don't understand why altera didn't implement this useful feature in 
Stratix II. Xilinx has introduced this years ago with the virtex 2, so 
in my eyes there was enougth time adopt this at least for Stratix II.

Are there any patent issues related with that. (is it patentable to make 
luts programmable??). By the way: Isn't it the same with DSP Blocks? 
Here Xilinx and Altera can offer them! Where is the difference?

Finally I can't believe that it is a technical problem for Altera to 
implement this.

Has anyone out there a good explanation why Altera can't/doesn't offer 
this feature?? I'm very curious about it..

greetings from Bavaria

Michael

Article: 92301
Subject: Re: Distributed RAMs / SRL: Why not, Altera?
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Sat, 26 Nov 2005 13:01:17 -0000
Links: << >>  << T >>  << A >>
Michael

I am fairly sure that this is a patent issue. Xilinx have the patent and for 
some applications the local ram and srl16 are very useful. They aren't going 
to give that away easily although the origional patent must go back some 
time.

John Adair
Enterpoint Ltd. - Home of Raggedstone1. The Cheap Spartan3 Development 
Board.
http://www.enterpoint.co.uk


"Michael Kramer" <michikramer@compuserve.de> wrote in message 
news:dm9gh9$28n$1@online.de...
> Hello,
>
> currently we are working on relatively large project with a focus on 
> signal processing algorithms. Some months ago we decided to use the Altera 
> Stratix II Family for a number of reasons. Some of them were the highly 
> versatile analog PLLs the better balance between logic an dsp blocks 
> compared to the specialist Virtex 4 LX/SX.
>
> But now onwarding in the development process we miss one feature of Xilinx 
> Devices more an more: The ability to use the LUTs of a logic cell for 
> storage. This enables the effective implementation of RAM and shift 
> registers in the logic without wasting huge amounts of registers. The 
> Altera hint to use the fine grained memory blocks (M512, M4K) is no real 
> alternative because you waste a lot of memory when implementing e.g. small 
> coefficent memory or shift registers with many taps. And in our 
> application memory is rare..
>
> I don't understand why altera didn't implement this useful feature in 
> Stratix II. Xilinx has introduced this years ago with the virtex 2, so in 
> my eyes there was enougth time adopt this at least for Stratix II.
>
> Are there any patent issues related with that. (is it patentable to make 
> luts programmable??). By the way: Isn't it the same with DSP Blocks? Here 
> Xilinx and Altera can offer them! Where is the difference?
>
> Finally I can't believe that it is a technical problem for Altera to 
> implement this.
>
> Has anyone out there a good explanation why Altera can't/doesn't offer 
> this feature?? I'm very curious about it..
>
> greetings from Bavaria
>
> Michael 



Article: 92302
Subject: Re: Cyclone II and Stratix II dual ports are dead
From: altera_smells@hotmail.com
Date: 26 Nov 2005 09:33:01 -0800
Links: << >>  << T >>  << A >>
Wow,

It means if you have a design with an asynch fifo out in the field that
it could fail.

altera_smells@hotmail.com wrote:
> The innovation is not only built in, it's engineered in. I don't
> believe I've seen a more embarrassing issue in a long time. Well, at
> least since ARM based Excalibur and Mercury were released to zero
> sales. Can't even read and write to dual port rams? That should be an
> automatic 100% correct feature. Better set your safe write and safe
> read parameters. Weren't dual port rams built into FPGAs around 10
> years ago? Doh!
>
> From: Altera Customer Notification [mailto:announcements@altera.com]
> Subject: Important Update for Stratix II and Cyclone II Devices
>
> Dear customer,
>
> Altera has identified M4K memory block issues affecting Stratix(R) II
> and Cyclone(TM) II FPGAs. Please see below for a description of the
> issues and links to more information.
>
> Issue Description:
>
> Stratix II M4K Read Issue
>
> An intermittent read failure has been detected on Stratix II FPGA M4K
> memory blocks in dual clock dual port mode due to a software
> configuration error.
>
> Cyclone II M4K Write Issue
>
> A write error has been detected on Cyclone II FPGA M4K memory blocks
> when using dual ports and dual clocks.
>
> Action Required:
>
> If you are using Stratix II or Cyclone II devices, read the updated
> errata sheets on the Altera(R) web site.
>
> Stratix II FPGA Family Errata Sheet:
>
> Cyclone II FPGA Family Errata Sheet:
>
> For further information please contact your FAE or file a service
> request through MySupport at:
>
> -----------------------------------------------------------------------
>
> You are receiving this notification because you have a license to use
> Altera's Quartus II software, Quartus II Web Edition software, or are
> an
> Altera customer.
>
> Please do not respond to this e-mail to get further information on this
> issue. This mailbox is not monitored by technical support.
>
> Altera Corporation, 101 Innovation Drive, San Jose, California 95134,
> USA


Article: 92303
Subject: Xilinx timing constraint question
From: "johnp" <johnp3+nospam@probo.com>
Date: 26 Nov 2005 09:37:29 -0800
Links: << >>  << T >>  << A >>
I'm using a Xilinx V2Pro part with the 6.2.03i s/w release and I'm
seeing
the following unconstrained path in the timing report.

================================================================================
Timing constraint: Unconstrained period analysis for net "clk_conv"

Delay:                  3.073ns (data path - clock path skew +
uncertainty)
  Source:               u0clk_trig_if/trig_conv0 (FF)
  Destination:          u0clk_trig_if/trig_conv1 (FF)
  Data Path Delay:      3.073ns (Levels of Logic = 0)
  Clock Path Skew:      0.000ns
  Source Clock:         clk_conv rising at 0.000ns
  Destination Clock:    clk_conv rising at 2.450ns
  Clock Uncertainty:    0.000ns

  Data Path: u0clk_trig_if/trig_conv0 to u0clk_trig_if/trig_conv1
    Location             Delay type         Delay(ns)  Physical
Resource
                                                       Logical
Resource(s)
    -------------------------------------------------
-------------------
    SLICE_X32Y0.YQ       Tcko                  0.419
u0clk_trig_if/trig_conv0

u0clk_trig_if/trig_conv0
    SLICE_X25Y9.BY       net (fanout=2)        2.428
u0clk_trig_if/trig_conv0
    SLICE_X25Y9.CLK      Tdick                 0.226
u0clk_trig_if/trig_conv1

u0clk_trig_if/trig_conv1
    -------------------------------------------------
---------------------------
    Total                                      3.073ns (0.645ns logic,
2.428ns route)
                                                       (21.0% logic,
79.0% route)


In my .ucf file, I have set the period on clk_conv, and the report
section above
shows the proper info on clk_conv.  The Verilog code has the registers
trig_conv1 and trig_conv0 in the same always block with the proper
clock
edge.  The code seems straight forward.

In another section of the timing report, I see
================================================================================
Timing constraint: TS_clk_conv = PERIOD TIMEGRP "clk_conv"  2.450 nS
HIGH 50.000000 % ;

 4 items analyzed, 0 timing errors detected. (0 setup errors, 0 hold
errors)

So it looks like the tools are picking up the constraint, they're just
not applying
it to these registers.

Any ideas?

Thanks

John Providenza


Article: 92304
Subject: Re: XST :division and mod in vhdl
From: "Simon Peacock" <simon$actrix.co.nz>
Date: Sun, 27 Nov 2005 14:05:28 +1300
Links: << >>  << T >>  << A >>
for fewer passes... there is also successive approximation...  Use the
hardware multiplier and a 32 bit register..
1/ set  msb
2/ multiply a x b
3/ if greater clear msb
4/ set next msb
5/ repeate 2 to 4  31 times



"Philip Freidin" <philip@fliptronics.com> wrote in message
news:2i3fo1h4shvf470ksf7v8j72kplkfvptl5@4ax.com...
> On Fri, 25 Nov 2005 21:39:32 -0800, "Okashii" <nordicelf@msn.com> wrote:
>
> >I'm trying to simulate the behaviour of integer division in C, so its
32bit
> >by 32bit division with both operands unknown. I don't care about speed or
> >number of clock cycles though. Do you know of any links or reference
where I
> >can find the algorithm for that? Thanks in advance.
>
> Since you don't care about speed or number of clock cycles:
>
> 1) Set a counter to zero
> 2) Copy the dividend to an Accumulator
> 3) If Accumulator is less than divisor, go to step 7
> 4) Subtract divisor from Accumulator
> 5) Increment counter
> 6) Goto step 3
> 7) Counter is Quotient, Accumulator is remainder
>
>
> This is called division by repeated subtraction.
> Are you still sure that you don't care about speed  :-)
>
> If you want more precision, you can extend the accumulator at the
> LSB end, and scale the divisor (divide it by a convenient constant)
> as well. For example, you could add 12 zero bits at the LSB end of
> the Accumulator, and divide the divisor by 4096 (which requires
> exactly zero logic and zero time). The Counter also has to be 12
> bits longer, and the algorithm will take 4096 times as long to run
> (which you don't care about). The result will be 12 bits more
> accurate. There will be a binary point between the 13th and 12th
> bit (from the LSB end) of the counter. The stuff to the left of the
> binary point is the integer part of the quotient, and the stuff on
> the right is the fractional part. The remainder in the accumulator
> also has this format.
>
>
>
>
> Philip
>
>
>
>
> ===================
> Philip Freidin
> philip.freidin@fpga-faq.org
> Host for WWW.FPGA-FAQ.ORG



Article: 92305
Subject: Virtex 4 Tapped Delay Lines
From: alastairlynch@blueyonder.co-dot-uk.no-spam.invalid (al99999)
Date: Sat, 26 Nov 2005 19:15:36 -0600
Links: << >>  << T >>  << A >>
Hi,

I was wondering if anybody could help.  I'm looking for a way to
create tapped delay lines on a Xilinx Virtex 4 without having to
specify which logic slices should be used.  I'm trying to create a
time interval analyser to measure
accurately (to within approx 500 picoseconds) the length of time
between a start and a stop pulse.

If anybody has any simpler ideas of how to do this instead of using
tapped delay lines i'd be very grateful.  The alternative i'd been
thinking of were to up the clock speed (currently at 10MHz) to say
250MHz and then have 8 phase shifts of this clock.  When the start
(or stop) pulse arrives it would only AND correctly with one set of
phases specifying which part of the original clock pulse it was in,
but this might be prone to strange delays etc. through the AND gate.

Thanks a lot!

Alastair


Article: 92306
Subject: Re: Distributed RAMs / SRL: Why not, Altera?
From: "Simon Peacock" <simon$actrix.co.nz>
Date: Sun, 27 Nov 2005 14:19:41 +1300
Links: << >>  << T >>  << A >>
A lot of it is distinguishing features.. how do we make our product
different to everyone else's....
LVDS is different.. even the way you can use block rams is different.. if
they were the same then it would be hard for the marketing people to sell
customers on.
Also the SRL16 and distributed ram isn't free.. or Spartan 3 wouldn't have
removed half .

Simon


"John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk> wrote in
message news:dm9mav$ald$1@newsg1.svr.pol.co.uk...
> Michael
>
> I am fairly sure that this is a patent issue. Xilinx have the patent and
for
> some applications the local ram and srl16 are very useful. They aren't
going
> to give that away easily although the origional patent must go back some
> time.
>
> John Adair
> Enterpoint Ltd. - Home of Raggedstone1. The Cheap Spartan3 Development
> Board.
> http://www.enterpoint.co.uk
>
>
> "Michael Kramer" <michikramer@compuserve.de> wrote in message
> news:dm9gh9$28n$1@online.de...
> > Hello,
> >
> > currently we are working on relatively large project with a focus on
> > signal processing algorithms. Some months ago we decided to use the
Altera
> > Stratix II Family for a number of reasons. Some of them were the highly
> > versatile analog PLLs the better balance between logic an dsp blocks
> > compared to the specialist Virtex 4 LX/SX.
> >
> > But now onwarding in the development process we miss one feature of
Xilinx
> > Devices more an more: The ability to use the LUTs of a logic cell for
> > storage. This enables the effective implementation of RAM and shift
> > registers in the logic without wasting huge amounts of registers. The
> > Altera hint to use the fine grained memory blocks (M512, M4K) is no real
> > alternative because you waste a lot of memory when implementing e.g.
small
> > coefficent memory or shift registers with many taps. And in our
> > application memory is rare..
> >
> > I don't understand why altera didn't implement this useful feature in
> > Stratix II. Xilinx has introduced this years ago with the virtex 2, so
in
> > my eyes there was enougth time adopt this at least for Stratix II.
> >
> > Are there any patent issues related with that. (is it patentable to make
> > luts programmable??). By the way: Isn't it the same with DSP Blocks?
Here
> > Xilinx and Altera can offer them! Where is the difference?
> >
> > Finally I can't believe that it is a technical problem for Altera to
> > implement this.
> >
> > Has anyone out there a good explanation why Altera can't/doesn't offer
> > this feature?? I'm very curious about it..
> >
> > greetings from Bavaria
> >
> > Michael
>
>



Article: 92307
Subject: Re: Distributed RAMs / SRL: Why not, Altera?
From: Michael Kramer <michikramer@compuserve.de>
Date: Sun, 27 Nov 2005 08:33:02 +0100
Links: << >>  << T >>  << A >>
Hello John,

I think this must be a patent issue, too. But again: Is the fact of 
programmable luts really patentable. Altera can't simply copy the Xilinx 
  implementation, thats clear. But can't they realize the 
programmability in another way, give this feature another name and 
that's it??

And i still don't understand the difference regarding patentability 
between programmable luts and dsp-blocks..

Michael

P.S. I seems to me that there are far more xilinx people active in this 
list than guys from altera. Why is altera so quiet?


John Adair wrote:
> Michael
> 
> I am fairly sure that this is a patent issue. Xilinx have the patent and for 
> some applications the local ram and srl16 are very useful. They aren't going 
> to give that away easily although the origional patent must go back some 
> time.
> 
> John Adair
> Enterpoint Ltd. - Home of Raggedstone1. The Cheap Spartan3 Development 
> Board.
> http://www.enterpoint.co.uk
> 
> 
> "Michael Kramer" <michikramer@compuserve.de> wrote in message 
> news:dm9gh9$28n$1@online.de...
> 
>>Hello,
>>
>>currently we are working on relatively large project with a focus on 
>>signal processing algorithms. Some months ago we decided to use the Altera 
>>Stratix II Family for a number of reasons. Some of them were the highly 
>>versatile analog PLLs the better balance between logic an dsp blocks 
>>compared to the specialist Virtex 4 LX/SX.
>>
>>But now onwarding in the development process we miss one feature of Xilinx 
>>Devices more an more: The ability to use the LUTs of a logic cell for 
>>storage. This enables the effective implementation of RAM and shift 
>>registers in the logic without wasting huge amounts of registers. The 
>>Altera hint to use the fine grained memory blocks (M512, M4K) is no real 
>>alternative because you waste a lot of memory when implementing e.g. small 
>>coefficent memory or shift registers with many taps. And in our 
>>application memory is rare..
>>
>>I don't understand why altera didn't implement this useful feature in 
>>Stratix II. Xilinx has introduced this years ago with the virtex 2, so in 
>>my eyes there was enougth time adopt this at least for Stratix II.
>>
>>Are there any patent issues related with that. (is it patentable to make 
>>luts programmable??). By the way: Isn't it the same with DSP Blocks? Here 
>>Xilinx and Altera can offer them! Where is the difference?
>>
>>Finally I can't believe that it is a technical problem for Altera to 
>>implement this.
>>
>>Has anyone out there a good explanation why Altera can't/doesn't offer 
>>this feature?? I'm very curious about it..
>>
>>greetings from Bavaria
>>
>>Michael 
> 
> 
> 

Article: 92308
Subject: Re: Virtex 4 Tapped Delay Lines
From: Philip Freidin <philip@fliptronics.com>
Date: Sun, 27 Nov 2005 08:41:20 GMT
Links: << >>  << T >>  << A >>
On Sat, 26 Nov 2005 19:15:36 -0600, alastairlynch@blueyonder.co-dot-uk.no-spam.invalid (al99999) wrote:
>Hi,
>
>I was wondering if anybody could help.  I'm looking for a way to
>create tapped delay lines on a Xilinx Virtex 4 without having to
>specify which logic slices should be used.  I'm trying to create a
>time interval analyser to measure
>accurately (to within approx 500 picoseconds) the length of time
>between a start and a stop pulse.

Xilinx has a tapped delay line in each IOB for skewing the data path,
and this can be between the input pad and the input FF.

"Virtex-4 modules have an IDELAY module in the input path of every
user I/O. IDELAY allows the implementation of deskew algorithms to
correctly capture incoming data. IDELAY can be applied to data
signals, clock signals, or both. IDELAY features a fully-controllable,
64-tap delay line. Each tap delay is carefully calibrated to provide
an absolute delay value of 78 ps independent of process, voltage,
and temperature variations."

So the range is 5 ns, with 78 ps resolution.

   http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/v4lsc/v4lsc0122_113.html


>If anybody has any simpler ideas of how to do this instead of using
>tapped delay lines i'd be very grateful.  The alternative i'd been
>thinking of were to up the clock speed (currently at 10MHz) to say
>250MHz and then have 8 phase shifts of this clock.  When the start
>(or stop) pulse arrives it would only AND correctly with one set of
>phases specifying which part of the original clock pulse it was in,
>but this might be prone to strange delays etc. through the AND gate.

So you are on the right track. I think with IDELAY and your example
numbers, you would bring the input signal in on 8 input pins, and set
the delay from 0 to 3.5 nS , all the input flipflops are clocked by
your 250 MHz clock, and then you decode the resulting 8 bit result
to get your fine timing, and count the 250 MHz clock for coarse
timing.

You can either double your resolution or halve the number of inputs
if you also take advantage of the DDR capability:

At 250 MHz, your cycle time is 4 ns, and half cyycle time is 2 ns,
so a DDR input FF-pair, with IDELAY set to 0, gives you sampling at
0 and 2 ns. With IDELAY set to 7 (546 ps) you get sampling at 0.546
and 2.546 ns.

>Thanks a lot!
>
>Alastair

I would also add some sort of calibration capability to the design
such as being able to drive all the inputs from a reference signal
(make the IOBs bidirectional), and then go through a calibration
process to figure out the phase relationship to the effective 250
MHz clock edge, and the sampling time of the inputs. The result
might feed a barrel shifter on the 8 bit code to handle the phase
correction.

A totally different approach might be to use the SerDes blocks if
you have them, with all the 10B/8B decoding and other protocol
logic disabled. You would then get a stream of 20 or 40 bit words
with the SerDes receiver running from the transmitter clock and
have it setup for 2.000 gigabits per second. Again, you would need
some sort of calibration process to correct for the arbitrary
phase relationship between the TX clock and the deserialized RX
data. Once you figur this out, it should remain stable till you
reset/cycle the power.

Have fun,

Philip






Article: 92309
Subject: VLSI Processor Cores
From: "ABS" <abhishekbedi@gmail.com>
Date: 27 Nov 2005 01:16:39 -0800
Links: << >>  << T >>  << A >>
Hi All

I want to  Research in the "Processors Core Development"  , can any one
suggest me of  any current topics to conduct this Master's Level
Research for whole year .
I would be great full !!
or else i would like to Research in developing "Applications for FPGA's
/ CPLD's " .

Cheers 

Abhishek Bedi


Article: 92310
Subject: Re: Mobile Chips
From: "PeteS" <ps@fleetwoodmobile.com>
Date: 27 Nov 2005 01:52:31 -0800
Links: << >>  << T >>  << A >>
Production mobile phones use highly integrated devices, for two
reasons:
Power and space. Note that low space usage has two distinct advantages;
it permits not only small products, but also permits easier shielding
of the non-RF sections from the RF section.

To get this level of integration, ASICS appear to be the most commonly
used devices. When Nokia or Motorola decide on a new design, they
expect to sell a few million ( at least) thus amortising the NRE cost
of an ASIC.

I am not sure of what group(s) may be appropriate. I would do a quick
search.

Cheers

PeteS


Article: 92311
Subject: Re: Distributed RAMs / SRL: Why not, Altera?
From: Mike Harrison <mike@whitewing.co.uk>
Date: Sun, 27 Nov 2005 12:07:12 GMT
Links: << >>  << T >>  << A >>
On Sun, 27 Nov 2005 08:33:02 +0100, Michael Kramer <michikramer@compuserve.de> wrote:

>Hello John,
>
>I think this must be a patent issue, too. But again: Is the fact of 
>programmable luts really patentable. Altera can't simply copy the Xilinx 
>  implementation, thats clear. But can't they realize the 
>programmability in another way, give this feature another name and 
>that's it??
>
>And i still don't understand the difference regarding patentability 
>between programmable luts and dsp-blocks..
>
>Michael
>
>P.S. I seems to me that there are far more xilinx people active in this 
>list than guys from altera. Why is altera so quiet?

Altera guys are too busy using the parts - Xilinx people have more time on their hands waiting for
them to become available... ;-)


Article: 92312
Subject: Re: Distributed RAMs / SRL: Why not, Altera?
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Sun, 27 Nov 2005 12:15:51 -0000
Links: << >>  << T >>  << A >>
Michael

Some of this is the way the US system allows patents. They do patent things 
that here in Europe that would not get past our patent bodies. There is also 
a culture in the US that if they stand a chance of something being useful 
they patent it. Companies over here are traditionally much more conservative 
in going after and policing patents.

There does seem to be an imbalance in this newsgroup but there are Altera 
users and people here. You could speculate why but historically the toolsets 
meant that Altera users came from a push button design approach mentality 
and Xilinx users came from a more power user background. Now with Xilinx 
making it's tools more push button (if you want to)  and Altera going the 
other way towards making more control available there isn't a lot of 
difference in toolset capability and it is more a look and feel issue to 
which toolset you like.

There are other factors. Many years ago my company Enterpoint probably did 
as much Altera as Xilinx. Here in Europe Xilinx started the European 
Consultants program which is generally accepted as the predecessor to the 
Xperts Program now merged into Alliance. About a similar time Altera started 
ACAP. The difference was that the European Consultants Program was a very 
low overhead to entry and gave back a good knowledge base. ACAP conversely 
had a high entry and maintainence cost. We considered the options and 
essentially went Xilinx. The inside track knowledge and contacts we have had 
in Xilinx since have pulled us more and more stromngly towards Xilinx. 
Altera also had a few years where products that were behind or simply missed 
the target markets but I will say I think that issue has been rectified now 
and Altera is a strong competitor to Xilinx in most areas.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development 
Board.
http://www.enterpoint.co.uk


"Michael Kramer" <michikramer@compuserve.de> wrote in message 
news:dmbnfe$fkl$1@online.de...
> Hello John,
>
> I think this must be a patent issue, too. But again: Is the fact of 
> programmable luts really patentable. Altera can't simply copy the Xilinx 
> implementation, thats clear. But can't they realize the programmability in 
> another way, give this feature another name and that's it??
>
> And i still don't understand the difference regarding patentability 
> between programmable luts and dsp-blocks..
>
> Michael
>
> P.S. I seems to me that there are far more xilinx people active in this 
> list than guys from altera. Why is altera so quiet?
>
>
> John Adair wrote:
>> Michael
>>
>> I am fairly sure that this is a patent issue. Xilinx have the patent and 
>> for some applications the local ram and srl16 are very useful. They 
>> aren't going to give that away easily although the origional patent must 
>> go back some time.
>>
>> John Adair
>> Enterpoint Ltd. - Home of Raggedstone1. The Cheap Spartan3 Development 
>> Board.
>> http://www.enterpoint.co.uk
>>
>>
>> "Michael Kramer" <michikramer@compuserve.de> wrote in message 
>> news:dm9gh9$28n$1@online.de...
>>
>>>Hello,
>>>
>>>currently we are working on relatively large project with a focus on 
>>>signal processing algorithms. Some months ago we decided to use the 
>>>Altera Stratix II Family for a number of reasons. Some of them were the 
>>>highly versatile analog PLLs the better balance between logic an dsp 
>>>blocks compared to the specialist Virtex 4 LX/SX.
>>>
>>>But now onwarding in the development process we miss one feature of 
>>>Xilinx Devices more an more: The ability to use the LUTs of a logic cell 
>>>for storage. This enables the effective implementation of RAM and shift 
>>>registers in the logic without wasting huge amounts of registers. The 
>>>Altera hint to use the fine grained memory blocks (M512, M4K) is no real 
>>>alternative because you waste a lot of memory when implementing e.g. 
>>>small coefficent memory or shift registers with many taps. And in our 
>>>application memory is rare..
>>>
>>>I don't understand why altera didn't implement this useful feature in 
>>>Stratix II. Xilinx has introduced this years ago with the virtex 2, so in 
>>>my eyes there was enougth time adopt this at least for Stratix II.
>>>
>>>Are there any patent issues related with that. (is it patentable to make 
>>>luts programmable??). By the way: Isn't it the same with DSP Blocks? Here 
>>>Xilinx and Altera can offer them! Where is the difference?
>>>
>>>Finally I can't believe that it is a technical problem for Altera to 
>>>implement this.
>>>
>>>Has anyone out there a good explanation why Altera can't/doesn't offer 
>>>this feature?? I'm very curious about it..
>>>
>>>greetings from Bavaria
>>>
>>>Michael
>>
>> 


Article: 92313
Subject: Re: VLSI Processor Cores
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Sun, 27 Nov 2005 12:23:16 -0000
Links: << >>  << T >>  << A >>
Abhishek

I don't know what country you want but it might be worth looking at the 
Institute for System Level Integration in Scotland which is associated with 
Alba Centre in Livingston. There are courses and post-grad oppertunities 
that are certainly near what you want. Alba centre website is here 
http://www.scottish-enterprise.com/albacentre.htm .

John Adair
Enterpoint Ltd. - Home of MINI-CAN. The FPGA CAN Bus Development Board.
http://www.enterpoint.co.uk



"ABS" <abhishekbedi@gmail.com> wrote in message 
news:1133082999.335991.288870@g44g2000cwa.googlegroups.com...
> Hi All
>
> I want to  Research in the "Processors Core Development"  , can any one
> suggest me of  any current topics to conduct this Master's Level
> Research for whole year .
> I would be great full !!
> or else i would like to Research in developing "Applications for FPGA's
> / CPLD's " .
>
> Cheers
>
> Abhishek Bedi
> 



Article: 92314
Subject: Virtex 4 Configuration
From: "Enzo Guerra" <talon@pathcom.com>
Date: Sun, 27 Nov 2005 10:10:56 -0500
Links: << >>  << T >>  << A >>
hello
have a few questions regarding the configuration pins on the V4 chip
1. in the Virtex-4 Configuration Guide [ug071].pdf,  pg 35 figure 2-12, Note 
1

1. The DONE pin is by default an open-drain output requiring an external 
pull-up

resistor. A 330? pull-up resistor is recommended. In this arrangement, the 
active

DONE driver can be enabled, eliminating the need for an external pull-up 
resistor.

not sure what this means
can the DONE configuration pin be driver enabled?
can the other pins also be enabled or pulled up or pulled down?
or
if the fpga has some spare pins, and pulling up or pulling down the spare 
pin, then wire it to any of the configuration pins, would that not work like 
an external pulled up/down resistor?

lastly
if any of the above is possible can the same pin be both pulled up and 
pulled down, then wired to CCLK, it might take care of Note 10

10. The CCLK net requires Thevenin parallel termination.

thanks 



----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Article: 92315
Subject: Re: subtractor
From: Olaf Petzold <olaf@mdcc-fun.net>
Date: Sun, 27 Nov 2005 16:38:38 +0100
Links: << >>  << T >>  << A >>
there seems to be some problems on this line:

>    b_2c <= std_logic_vector(to_unsigned(to_integer(unsigned(not b)) + 1, 
> b_2c'length));

if b is zero, I got the warning: NUMERIC_STD.TO_UNSIGNED: vector 
truncated. Well, it's ok, since complement of 0x00 is 0xFF and +1 got 
overflow. The interesting part is, that the testbench with zero fails. 
Are there some thing to care about?

Thanks
Olaf

Article: 92316
Subject: Re: Virtex 4 Tapped Delay Lines
From: alastairlynch@blueyonder.co-dot-uk.no-spam.invalid (al99999)
Date: Sun, 27 Nov 2005 11:15:45 -0600
Links: << >>  << T >>  << A >>
> Xilinx has a tapped delay line in each IOB for skewing the data
path,
> and this can be between the input pad and the input FF.
> 
> The range is 5 ns, with 78 ps resolution.
> 
>
http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/v4lsc/v4lsc0122_113.html
> 

Ok, looking at the datasheet for IDELAY in fixed delay mode, the only
output is 'O' which is the data output.  Do I not need to be able to
access the output of the tap multiplexer?
   
> So you are on the right track. I think with IDELAY and your example
> numbers, you would bring the input signal in on 8 input pins, and
set
> the delay from 0 to 3.5 nS , all the input flipflops are clocked by
> your 250 MHz clock, and then you decode the resulting 8 bit result
> to get your fine timing, and count the 250 MHz clock for coarse
> timing.

What do you mean bring the input signal on to 8 input pins? 
Physically wire up the input pulse to 8 of the virtex 4 IO pins?

Sorry, just a little bit confused!!  I'd be grateful for any more
detail you could provide on how to go about doing this.

Thanks!

Al


Article: 92317
Subject: Re: Virtex 4 Configuration
From: "Bob" <nimby1_notspamm_@earthlink.net>
Date: Sun, 27 Nov 2005 17:22:19 GMT
Links: << >>  << T >>  << A >>

"Enzo Guerra" <talon@pathcom.com> wrote in message 
news:1133104411_34795@spool6-east.superfeed.net...
> hello
> have a few questions regarding the configuration pins on the V4 chip
> 1. in the Virtex-4 Configuration Guide [ug071].pdf,  pg 35 figure 2-12, 
> Note 1
>
> 1. The DONE pin is by default an open-drain output requiring an external 
> pull-up
>
> resistor. A 330? pull-up resistor is recommended. In this arrangement, the 
> active
>
> DONE driver can be enabled, eliminating the need for an external pull-up 
> resistor.
>
> not sure what this means

There can be a problem, when DONE is released by the FPGA, if its risetime 
is too slow. From what I understand, this is only a problem if there are 
more than one FPGA's DONE pins tied together.

If the open-drain configuration is used, and there are several DONE pins in 
parallel, then the rise time can be minimized by using a small-valued pullup 
resistor (330 is the minimum value, IIRC).

If there is only one FPGA being configured (i.e., the DONE pins are not 
paralleled with others), then the DONE pin can be configured to have a totem 
pole output stage (push-pull). This is a bitgen option (IIRC). You don't 
want to use this option if you have more than one DONE in parallel since you 
will (eventually) have one DONE pulling low and another pulling high.

> can the DONE configuration pin be driver enabled?

See above.

> can the other pins also be enabled or pulled up or pulled down?
> or

Sure, but (generally) only after the user I/O has been configured. See 
below.

> if the fpga has some spare pins, and pulling up or pulling down the spare 
> pin, then wire it to any of the configuration pins, would that not work 
> like an external pulled up/down resistor?

Remember, this is all happening 'pre-configuration'. The user I/O pins are 
not active, at this time. There is a mode pin option to allow the 
pre-configured user I/O to have pullups (during configuration), but 
connecting a bunch of user I/O to the DONE pin, for the sake of using the 
additional I/O pullup current, is silly. Just add a resistor. They're cheap 
and small.
>
> lastly
> if any of the above is possible can the same pin be both pulled up and 
> pulled down, then wired to CCLK, it might take care of Note 10
>
> 10. The CCLK net requires Thevenin parallel termination.

The CCLK pin a clock. It's critical that its signal integrity be carefully 
controlled -- as any other clock signal needs to be. Double clocking could 
result. Proper termination is a must. Start reading about "signal integrity" 
and "termination techniques".

>
> thanks

Yahvelcome.



Article: 92318
Subject: Re: Distributed RAMs / SRL: Why not, Altera?
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Sun, 27 Nov 2005 09:40:54 -0800
Links: << >>  << T >>  << A >>
Michael Kramer wrote:

>  Altera can't simply copy the Xilinx 
>  implementation, thats clear. But can't they realize the programmability 
> in another way, give this feature another name and that's it??

Altera seems to focus on customers who use
HDL design entry/simulation/synthesis
and rarely work at the LUT level.
I expect that Altera's largest customers would not
see a Xilinx style logic cell as a big advantage.

> P.S. I seems to me that there are far more xilinx people active in this 
> list than guys from altera. Why is altera so quiet?

Xilinx seems to focus on customers who want to
squeeze the last dollar, gate and nanosecond
out of their designs. As a result, many of the posts here
concern such squeezing, specific to Xilinx device architectures.
Many Altera users think in vhdl or verilog
and do not post much here.

        -- Mike Treseler

Article: 92319
Subject: async fifo design
From: michaeldre@gmx.de (Michael Dreschmann)
Date: Sun, 27 Nov 2005 18:30:56 GMT
Links: << >>  << T >>  << A >>
Hi,

I'm designing an "On Chip Network" System consisting of one network
master and several network interfaces. Every interface is connected to
a prozessor (picoblaze) which can transmit and receive data onto/from
the network.
Now I'd like to have two completely independent clocks on the network
and on the prozessor bus site. In the network interface I use two fifos
(rx and tx) implemented in a signle bram to exchange data between
network and prozessor site. So I think an asynchronous fifo should solve
the problem.
But I'm not sure how to implement such a fifo exactly. I found several sites
recommending gray coded read and write pointer, but I couldn't find infos
how to implement a gray code to binary code converter to address the
block ram and how to increase the gray coded pointers.

Also my fifo is a little bit special:

I've implemented two fifos in a single bram but I don't think that is relevant
here because read and write pointers are present for each fifo. The final
bram address is calculated for each site (network/prozessor) from the read
or write pointer depending on which fifo is addressed (= if the site is reading or writing).

The second point is the read and write pointers points to a block base
address. Each block is 18 bytes long. Each site can random access the
18 bytes in the active block by an address input:
ram_address = read/writepointer * 18 + local_address
(local_address < 18)
Because I want to avoid the *18 multiplication I increase the read/write
pointers by 18 with any block_release or block_store command. The release
command is synchron to the reading site, the store command is synchron to
the writing site. Both are active for on clock period.

The fifo empty and full signals are generated by comparing write and read
pointer:
empty: write = read
full: (write+1) = read
I know that I waste one fifo entry in this way, but that is acceptable.

My problem is now:

1. How do I implement gray code pointers and how do I convert them to a
binary coded pointer that can act as base for the local_address addition?

2. Is there any way to add 18 instead of 1 to a gray code pointer without
losing his "hamming distance 1" characteristic to avoid a *18 multiplication?

I'v added the address logic from my fifo here, perhaps it helps.

Thanks,
 Michael

----------------------------------------------------------------------------------------------------------------------------------

function inc_block(arg: std_logic_vector) return std_logic_vector is
begin
	if arg < "1111011110" then -- increase arg by 1 in a loop from 0 - 55
		return arg + "0000010010";
	else
		return "0000000000";
	end if;
end;

-- calculate fifo a/b, in/out addresses:
addr_ram_in_a <= block_base_addr_in_a + addr_in_a;
addr_ram_out_a <= block_base_addr_out_a + addr_out_a;
addr_ram_in_b <= block_base_addr_in_b + addr_in_b;
addr_ram_out_b <= block_base_addr_out_b + addr_out_b;


-- use "wr" to generate absolute port addresses:
addr_pa(10) <= wr_b;
addr_pa(9 downto 0) <= addr_ram_in_b when (wr_b = '1') else addr_ram_out_a;
addr_pb(10) <= not wr_a;
addr_pb(9 downto 0) <= addr_ram_in_a when (wr_a = '1') else addr_ram_out_b;


-- fifo states
buffer_empty_a_int <= '1' when block_base_addr_in_a = block_base_addr_out_a else '0';
buffer_full_a_int <= '1' when inc_block(block_base_addr_in_a) = block_base_addr_out_a else '0';
buffer_empty_b_int <= '1' when block_base_addr_in_b = block_base_addr_out_b else '0';
buffer_full_b_int <= '1' when inc_block(block_base_addr_in_b) = block_base_addr_out_b else '0';


-- fifo counters and controllogic
process (clk)
begin  
	if (clk'event and clk = '1') then
		if reset = '1' then
			block_base_addr_in_a <= "0000000000";
			block_base_addr_out_a <= "0000000000";
			block_base_addr_in_b <= "0000000000";
			block_base_addr_out_b <= "0000000000";
		else
			-- fifo a control
			if (clear_buffer_a = '1') then						-- reset writepointer and readpointer if clear_buffer is active
				block_base_addr_in_a <= "0000000000";
				block_base_addr_out_a <= "0000000000";
			else
				if (save_block_a = '1') and (buffer_full_a_int = '0') then		-- increase writepointer if save_bock is active and buffer is not full
					block_base_addr_in_a <= inc_block(block_base_addr_in_a);
				end if;
				if (release_block_a = '1') and (buffer_empty_a_int = '0') then	-- increase readpointer if release_bock is active and buffer is not empty
					block_base_addr_out_a <= inc_block(block_base_addr_out_a);
				end if;
			end if;
			-- fifo b control
			if (clear_buffer_b = '1') then						-- reset writepointer and readpointer if clear_buffer is active
				block_base_addr_in_b <= "0000000000";
				block_base_addr_out_b <= "0000000000";
			else
				if (save_block_b = '1') and (buffer_full_b_int = '0') then		-- increase writepointer if save_bock is active and buffer is not full
					block_base_addr_in_b <= inc_block(block_base_addr_in_b);
				end if;
				if (release_block_b = '1') and (buffer_empty_b_int = '0') then	-- increase readpointer if release_bock is active and buffer is not empty
					block_base_addr_out_b <= inc_block(block_base_addr_out_b);
				end if;
			end if;
		end if;	-- reset state
	end if;	-- clk'event
end process;

Article: 92320
Subject: Re: Distributed RAMs / SRL: Why not, Altera?
From: Michael Kramer <michikramer@compuserve.de>
Date: Sun, 27 Nov 2005 21:39:32 +0100
Links: << >>  << T >>  << A >>
Hello Mike,

 > Xilinx seems to focus on customers who want to
 > squeeze the last dollar, gate and nanosecond
 > out of their designs. As a result, many of the posts here
 > concern such squeezing, specific to Xilinx device architectures.
 > Many Altera users think in vhdl or verilog
 > and do not post much here.

Can i conclude from your remarks that Altera users want to waste logic 
resources (=money)?? I agree that modern digital design should 
concentrate on vhdl/verilog and that it should be the job of the 
synthesis tool to map this to the device effectively. But i simply don't 
see any advantage in offering the synthesis tool less optimization 
opportunities..

 > I expect that Altera's largest customers would not
 > see a Xilinx style logic cell as a big advantage.

Our company is one of Xilinx' largest customers in europe 
(T&M,broadcasting,communications) and our local Altera guys were 
extremely happy to gain such a large project against xilinx. I can say 
that we want to get all out of the part and we would definitely 
appreciate such an option in the altera logic cell...

greetings
Michael

Mike Treseler wrote:
> Michael Kramer wrote:
> 
>>  Altera can't simply copy the Xilinx  implementation, thats clear. But 
>> can't they realize the programmability in another way, give this 
>> feature another name and that's it??
> 
> 
> Altera seems to focus on customers who use
> HDL design entry/simulation/synthesis
> and rarely work at the LUT level.
> I expect that Altera's largest customers would not
> see a Xilinx style logic cell as a big advantage.
> 
>> P.S. I seems to me that there are far more xilinx people active in 
>> this list than guys from altera. Why is altera so quiet?
> 
> 
> Xilinx seems to focus on customers who want to
> squeeze the last dollar, gate and nanosecond
> out of their designs. As a result, many of the posts here
> concern such squeezing, specific to Xilinx device architectures.
> Many Altera users think in vhdl or verilog
> and do not post much here.
> 
>        -- Mike Treseler

Article: 92321
Subject: Re: subtractor
From: Olaf Petzold <olaf@mdcc-fun.net>
Date: Sun, 27 Nov 2005 21:41:43 +0100
Links: << >>  << T >>  << A >>

> architecture rtl of subtractor is
>    -- two's-complement
>    signal b_2c : std_logic_vector(WIDTH-1 downto 0);
> begin
>    b_2c <= std_logic_vector(to_unsigned(to_integer(unsigned(not b)) + 1, 
> b_2c'length));
> 
>    adder_i : entity work.adder
>       generic map (
>          WIDTH => WIDTH)
>       port map (
>          a   => a,
>          b   => b_2c,
>          sum => diff,
>          co  => co);
> end architecture rtl;

somethings is wrong here. The adder TB success. The TB for this entity 
fails:

# ** Note: Verify Test #0: 27 - 9 = 18; co = '0' vs. got = '1'
# ** Note:    got wrong carry = '1'
# ** Note: Verify Test #1: 39 - 0 = 39; co = '0' vs. got = '0'
# ** Note: Verify Test #2: 0 - 0 = 0; co = '0' vs. got = '0'
# ** Note: Verify Test #3: 255 - 0 = 255; co = '0' vs. got = '0'
# ** Note: Verify Test #4: 10 - 20 = 246; co = '1' vs. got = '0'
# ** Note:    got wrong carry = '0'
# ** Note: Verify Test #5: 0 - 255 = 1; co = '1' vs. got = '0'
# ** Note:    got wrong carry = '0'

Does someone say what gone wrong? Only the carry flag fails.

Thanks
Olaf

Article: 92322
Subject: Re: subtractor
From: Olaf Petzold <olaf@mdcc-fun.net>
Date: Sun, 27 Nov 2005 22:00:55 +0100
Links: << >>  << T >>  << A >>
> architecture rtl of subtractor is
>    -- two's-complement
>    signal b_2c : std_logic_vector(WIDTH-1 downto 0);
> begin
>    b_2c <= std_logic_vector(to_unsigned(to_integer(unsigned(not b)) + 1, 
> b_2c'length));

a simplification doesn't help:

    constant ONE : unsigned(WIDTH-1 downto 0)
                            := to_unsigned(1, WIDTH);

    -- two's-complement
    signal b2c : std_logic_vector(WIDTH-1 downto 0);

    ...
    b2c <= std_logic_vector(unsigned(not b) + ONE);

Article: 92323
Subject: Re: Virtex 4 Tapped Delay Lines
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 27 Nov 2005 13:08:13 -0800
Links: << >>  << T >>  << A >>
Al, Philip gave you good advice:
For each input pin, you can specify a delay from the pad to the O. The
granularity (given a 200 MHz calibration frequency) is 78.125 ps,but
each tap has its own non-cumulative error of about 15 ps.
I would improve your accuracy by using 16 inputs, each having a
different IDELAY value, so that you divide the 5 ns into 16 steps of
312 ps each (give or take a 15 ps non-accumulative error). The tap
delays are unaffected by any jitter of the 200 MHz clock.
You interconnect all 16 inputs. When an edge comes in, it will be
delayed differently in each IDELAY, and you use your 200 MHz clock to
register a 16-bit input word which has ones on one end, and zeros on
the other.
It's then your job to find the transition point (look-up-tables are
good for that),and that 4-bit binary value identifies the time as a
fraction of your 5 ns timing (200 MHz)
This means you have an absolute time for the rising as well as for the
falling edge, and the difference is your pulse width.  Worst-case error
is thus +/- one tap.
Peter Alfke, from home


Article: 92324
Subject: Re: Distributed RAMs / SRL: Why not, Altera?
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Sun, 27 Nov 2005 14:04:01 -0800
Links: << >>  << T >>  << A >>
Michael Kramer wrote:

> Can i conclude from your remarks that Altera users want to waste logic 
> resources (=money)??

I would not draw such a conclusion.
Sometimes getting to market quickly will
more than cover some padding of resources.
For a field upgrade, the part is already
soldered on the board, usually with unused capacity.
A quick field upgrade that works the first time
can save a large system sale.

> I agree that modern digital design should 
> concentrate on vhdl/verilog and that it should be the job of the 
> synthesis tool to map this to the device effectively. But i simply don't 
> see any advantage in offering the synthesis tool less optimization 
> opportunities..

I have no facts to offer. You have my speculation.
We do packet processing/analysis and no DSP so I have
not run into this memory limitation.

     -- Mike Treseler



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