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 98950

Article: 98950
Subject: Re: for all those who believe in ASICs....and can't stop ranting
From: "John_H" <johnhandwork@mail.com>
Date: Sat, 18 Mar 2006 00:34:38 GMT
Links: << >>  << T >>  << A >>
<fpga_toys@yahoo.com> wrote in message 
news:1142635551.101974.25260@u72g2000cwu.googlegroups.com...
<snip>
> Nope ... I don't even know an Altera person. I do know or have met
> several Xilinx people who have always been great people to deal with.
> Every time I've been against the wall, there's been a Xilinx FAE to
> help. Field staff always seem to have great customer skills.

Did you rail on Xilinx and their trashing young developers when the FAE was 
there to help?  Did you declare their datasheets a piece of crap because 
they don't provide what you believe to be "proper" power data?  Did you call 
their business methods a scam?

Geeze, man - listen to yourself.  Ask the FAEs that have been so helpful to 
look at your threads and see if they'll side with you or try to help educate 
you in the other aspects of Xilinx that are there to benefit the customer 
base.

The written word is often a poor way to communicate for those who don't have 
a solid understanding of professional interaction.  Often all it takes is a 
good conversation - face to face - to help the understanding come through. 
If you're a customer in need and you ask for help from a respectable 
company, you get courteous assistance.  On this newsgroup you haven't been a 
customer in need, you've been an agitator - specifically in this tired 
thread you've been an underinformed "devil's advocate."

You help noone. 



Article: 98951
Subject: Re: Urgent Help Needed!!!!!
From: "Isaac Bosompem" <x86asm@gmail.com>
Date: 17 Mar 2006 17:12:33 -0800
Links: << >>  << T >>  << A >>

Chauhan wrote:
> Well the above post was adressed not 2 u but 2 JJ definetly.Sorry for
> giving u headache.

No offense to you man, but I am a student as well. You must understand
how important it is with communication. I read somewhere that the
biggest problems with engineering grads is that they can not
communicate effectively. This means poor writing or language skills. I
do chat as you do with my friends on MSN, but when I come to post here
I use proper English and sentence structure (well try). Just use proper
structure and think of it as practice for your future career (perhaps
you will stand out from the rest) :).

Plus a lot of the posters here are from a different generation, it is
likely they will be unable to comprehend what you are saying.

-Isaac

PS: Google Groups really is terrible. Does anyone know of any free
newsservers? My ISP  (Rogers) dropped USENET a few months and didnt
lower my monthly fee....

-------------------------------------------------------------------------------------------------------
I am looking for summer employment in the Toronto, Canada area
If you have any openings contact me at isaacb[AT]rogers[DOT]com.


Article: 98952
Subject: Re: Where are FPGA heading?
From: ziggy <ziggy@fakedaddress.com>
Date: Sat, 18 Mar 2006 01:31:31 GMT
Links: << >>  << T >>  << A >>
In article <6a2e9f084e.tank@tankstage.co.uk>,
 Tank <webmaster@tankstage.co.uk> wrote:

> In message <ifmi1218qkjo36fnvf3mk21p6n2k4mv39m@4ax.com>
>           John C <brakepiston@yahoo.co.uk> wrote:
> 
> > Reading the LSI Strucutred ASIC fiasco thread has made me think.
> > People are saying the FPGA revenues are going to grow, so....
> > 
> > Which markets are FPGA heading into?
> > 
> > I mean, at the moment there's Comms, Medical, Military, Consumer.
> > 
> > Where are they going next? 
> > 
> > Automotive I guess is coming, as is aerospace. You could put the two
> > together, as control electronics. 
> > 
> > How about seeing them in a PC? 
> 
> See http://www.microdigital.info 
> 
> Altho the company seems to have ceased trading, there are a few of us who
> have units.
> It uses  Spartan xc2s200's, one to implement a northbridge and one as a
> memory controller and graphic engine. A xc95144 is used to boot them and
> provide memory control.
> NOTE this is not a windows machine, but is a RISCOS (http://www.riscos.com)
> machine with an ARM based processor.
> 
> 
> > 
> > What are your views on the matter?



Their web site is also non functional.  Sounds interesting tho, 
something like what i wanted to do. Multiple FPGA's on a 'pc' like 
board. One for the cpu(s), one for video, another to handle all the 
ports and drive communications. 

Wont be any speed demon, but might be fun.

Article: 98953
Subject: Re: Where are FPGA heading?
From: ziggy <ziggy@fakedaddress.com>
Date: Sat, 18 Mar 2006 01:33:17 GMT
Links: << >>  << T >>  << A >>
In article <bvtj129bi3tecrbann43si35dhcc35nt4a@4ax.com>,
 metal <nospam@spaam.edu> wrote:

> On Thu, 16 Mar 2006 12:33:27 +0000, John C <brakepiston@yahoo.co.uk>
> wrote:
> 
> >Reading the LSI Strucutred ASIC fiasco thread has made me think.
> >People are saying the FPGA revenues are going to grow, so....
> >
> >Which markets are FPGA heading into?
> >
> >I mean, at the moment there's Comms, Medical, Military, Consumer.
> >
> >Where are they going next? 
> >
> >Automotive I guess is coming, as is aerospace. You could put the two
> >together, as control electronics. 
> >
> >How about seeing them in a PC? 
> >
> >What are your views on the matter?
> 
> hmm....looking at the writing on the wall economically....
> 
> PC-mkt: no growth...expect a decline.
> 
> mil/aero:  a new slaughter every year should keep this going; but
> overall volume is questionable....
> 
*snip*

Lets hope you are a bit wrong, would hate to see FPGA companies start to 
fold.. There really arent many to start with.

But i do agree with you, except for use in development of ASIC's is 
there really a *true* market?  

And is that market enough to keep things afloat for us hobbiests?

Article: 98954
Subject: Re: PacoBlaze update
From: ziggy <ziggy@fakedaddress.com>
Date: Sat, 18 Mar 2006 01:34:08 GMT
Links: << >>  << T >>  << A >>
In article <1142332120.711327.96730@j52g2000cwj.googlegroups.com>,
 "Pablo Bleyer Kocik" <pablobleyer@hotmail.com> wrote:

>  I have made a new release of the PacoBlaze module
> [http://bleyer.org/pacoblaze] considering the bug reports and
> suggestions I have been receiving. The configuration macros were
> cleaned and the stack implementation and PC control logic were revised.
> I also started adding debug signals and a bit of documentation.
> 
>  I think the current result is pretty neat. I have been playing adding
> a 8x8 MUL instruction that uses a straightforward even/odd model for
> the register file, plus one multiplier block. With 16-bit add/sub ALU
> instructions, I think this will be a useful addition to the instruction
> set utilizing just a few FPGA resources more. I will submit that once I
> finish testing it.
> 
>  I would also like to make a code repository for Pico/PacoBlaze. If you
> have code you want/can share I will put it in the web site.
> 
>  Have fun ;o)
> 
> --
> PabloBleyerKocik /"How wonderful it is that nobody need wait a single
>  pablo          / moment before starting to improve the world."
>   @bleyer.org  / -- Anne Frank

Cool, keep up the great work.

Article: 98955
Subject: Re: Support software for XC3042
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 17 Mar 2006 19:02:25 -0800
Links: << >>  << T >>  << A >>
Do yourself and everybody on this newsgoup a favor and get rid of these
chips in an environmentally acceptable way.
Then overcome your frugality and spend a few dollars on a modern chip
evaluation board. Spartan3 or 3E comes to mind.
You will get ever so much more enjoyment out of that choice.
The XC3042 was introduced in 1988, 17 years ago. According to my 15:1
rule, that makes it the equivalent of a 255 year old senior citizen.
Would you ask that tottering poor guy to do your work?
The silicon would work perfectly, but is small and slow. The software
is no longer supported and is slow and clumsy and only runs on archaic
computers. Forget it.

Peter Alfke, Xilinx.


Article: 98956
Subject: Re: Where are FPGA heading?
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 17 Mar 2006 19:31:50 -0800
Links: << >>  << T >>  << A >>
Wallstreet consensus is that the programmable (i.e. FPGA+CPLD) market
will grow faster than the aggregate semiconductor or IC market
(expressed in percentage revenue growth per year). Yes, only two
vigorouly competing giants plus a small group of also-runs. But the
same can be said of many other maturing markets. 
Peter Alfke


Article: 98957
Subject: Re: for all those who believe in ASICs....and can't stop ranting
From: fpga_toys@yahoo.com
Date: 17 Mar 2006 19:35:37 -0800
Links: << >>  << T >>  << A >>

John_H wrote:
> Did you declare their datasheets a piece of crap because
> they don't provide what you believe to be "proper" power data?

Actually I had two large proposals out with one of them pressing me
like hell about the power design, and the FAE could not get me an
answer, and the potential customer gave up. I got drilled about several
other items the data sheet could not answer either. That was a useful
exercise in learning that the info just isn't available.

> Did you call their business methods a scam?

And when was that?

> Geeze, man - listen to yourself.  Ask the FAEs that have been so helpful to
> look at your threads and see if they'll side with you or try to help educate
> you in the other aspects of Xilinx that are there to benefit the customer
> base.

If Austin and Peter want to be confrontational .... it's their choice.
I've tried to cool that. I'm also not going to back down and let them
ridicule me every thing they disagree without a cost to them. I'm just
a few years younger, have spent my life in other engineering areas, and
I do understand my business areas. There are some very clear
differences between our perspectives, which are not based on absolute
rights and wrongs, and would normally be matters to agree to disagree
on. If their intent is to destroy my credibility because I'm not an
insider, and I've a different view point they don't like ... then I
will reluctantly play that game as well until they get tired of being
burned too - or Xilinx management steps in and pulls the plug. If they
can act responsibly, so will I. But I will continue to push for things
that are needed for a pure reconfigurable computing market place, a
niche market that is growing, and they clearly have mixed interest in.

It was fully amusing to watch last week go from Austin and the other
poster say that RC and PR were money sinks and being dropped, and right
after I pressed to open source it, another Xilinx guy steps in and says
wait a year and they will finally get it fixed in the next major
release. That is still a tiled PR solution using PAR, which is just to
slow and requires far to my floor planning for my market. With Austin
asserting JBits is dead, that kills the alternate strategies of using
the backend tools from JHDL or JHDLBits into Jbits.  Xilinx has very
mixed internal positions on that whole tool set. I had been told that I
would never be able to use JHDLBits, Then Austin pops in and trys to
change that. Then the next week is declaring JBits a failure and dead.
Then another source tells me Austin doesn't speak for the JBits team,
that the JBits isn't dead.

> The written word is often a poor way to communicate for those who don't have
> a solid understanding of professional interaction.  Often all it takes is a
> good conversation - face to face - to help the understanding come through.
> If you're a customer in need and you ask for help from a respectable
> company, you get courteous assistance.  On this newsgroup you haven't been a
> customer in need, you've been an agitator - specifically in this tired
> thread you've been an underinformed "devil's advocate."

That's a two way street.  Yes I've pressed hard, but the personal
attacks in reponse were never justified. Frankly, based on a business
that stands behind Austin and Peter, I've considered not ever doing
business with Xilinx if that level of utter arrogance is to be
expected. I have about 4K Xilinx parts in my inventory that I can dump,
and never deal with the company again. Or, I can do as I've planned for
two years, and that is build a new company around reconfigurable
computing boards. I've pressed that the current ISE software model with
very poor place and route for compile, load and go operations just
doesn't fit that market. It was designed to do an excellent job at all
costs, not a very good job quickly. It's ability to handle dynamic
reconfiguration has been marginal and error prone.  After talking with
several people that had gone down that path, the suggest was to roll my
own based on the jbits and JHDL code.  The legal issues with that are
less than clear.  Nor do the high ISE per seat license costs work
trying to sell FPGA's as a very fast computer accellerator.

That Xilinx is a bit thin skinned about criticism, and constructive
criticism, is a bit of an understatement from my perspective.  I do
know that when my FAE can not provide worst case power numbers, and I'm
being pressed hard for them, there are problems. The customer had
already had the same discussion and lack of results from a prior
proposal and was WAY ahead of me.  There are also problems when
customer interfaces are not trained to listen to the customers needs,
and instead jump in and argue why the customers are wrong.  There is a
lot of truth that the customer understands their business, and it's the
vendors job to understand that the customer probably isn't just wrong
about their business needs. In tech land, that concept that the
customer is always right, needs some serious refinement. Sure customers
get it wrong, and need guidance, but they are generally very clueful
about what they need for their business.

In talking with others I've gotten similar mixed feelings about Altera,
but no first hand experience yet.

>
> You help noone.

I've actually interacted with a fair number of people with radically
different perspectives. The problem in a nut shell is that RC isn't
taken seriously by Xilinx, as it's been a 15 year pipe dream. Their
tools and business model are for a different market place -- high
volume embedded. And there staff are used to telling customers how to
use Xilinx product, and have some serious problems when you step
outside the high volume embedded application areas. First of all, the
biggest sales get the support. And as we have clearly seen, niche
markets, get little and are quickly subjected to being dropped, to go
chase another large customer. Small customers either need a way to fit
in and pickup the crumbs, or go to the seven dwarfs as Austin puts it.
IE send the small customers to the small players.

Given this has been the status quo for some decade .... clearly things
are not likely to change without a shove from my perspective. I'm more
than willing to step up and push for change, rather than watch the
opportunities slip by. I don't think watching the chances slip by
another decade is the right choice.  When it comes to Xilinx and RC,
either they need to embrace it, and clearly get behind it, or step
aside. Their indecison is hurting the market place seriously. Other
than a few ruffled feathers the last few weeks have been very useful in
airing differences in market requirements. The side emails I've gotten
have been supportive in general.

So I leave you with this challenge ... layout a road map that will
either effect the required changes, or get a clear decision from Xilinx
management they do not want to be a major player in the RC market -
firm decision inside 3-6 months.

I'm avocating being vocal, direct, and a bit of a squeeky wheel, as the
passive approach has created 15 years of indicision that we see even in
the last few weeks with radically different views from several
different Xilinx spokes persons. I'm willing to actively and intensely
engage Austin, Peter, and other Xilinx staff on all the related issues
to fully air the differences in opionion  about the divergent needs of
the various markets. So far, the intense, and informative debate here
has actually been very useful to provoke discussion that would normally
just be ignored.

Austin and I differ on the impact that patent expirations will have,
but history clearly relates that the expiration of base patents in
other technology areas was followed by a rapid change in the guard as
off shore companies stepped in and took over the market globally
leafing the US market founders dino's. In the next four years all the
major patents that control XC2000, XC3000, and much of XC4000
technology expire ... which means off shore companies will be free to
market bigger and faster version of those product technologies. They
will not be Virtext-II Pro's or XC4V's, but they will be big, fast, and
cheap FPGAs. And five years after that, about a decade from now, the
landscape may well be very very different in who are market leaders.

Fairly major revenue choices, like the Zero Defect is Quality
perspective the prevents Xilinx from wringing maxium revenue from every
wafer are very strong indicators that Xilinx may not be nimble enough
to adapt to a comodity FPGA market place price pressures that will
force severe cuts in the margins they have held for years.  The
layoffs, the market restructuring, sweeping changes in management teams
could easily send Xilinx to it's grave inside as little as a few years
- or leave it a minority low volume player for a long lingering death
or takeover/buyout target for the IP.

I can be vocal, and raise the issues. Or I can shut my trap and watch
:)

engage the debate .... make up your mind .... and if the changes come
true as I suspect, at least everyone had their day to plan ahead and
not cry over the changes. Austin and Peter are likely to retire before
long, so it will not be their watch on duty if the market loss happens
.... but it will be their direction and attitudes that set the stage
for it.


Article: 98958
Subject: Re: Support software for XC3042
From: "J Silverman" <g1powermac@yahoo.com>
Date: Fri, 17 Mar 2006 19:36:38 -0800
Links: << >>  << T >>  << A >>
Hi Peter,

I realized after doing some searching of these chips that they are ancient, but would be perfect for the project I'm building. I do not need anything more complicated than these. I'd really like to use them somehow instead of just throwing them away. Do you know of any other third party software that would support these chips? All I need is a way to create the configuration bitstream from some VHDL so I can program a flash chip with it.

Thanks, J Silverman

Article: 98959
Subject: Re: Support software for XC3042
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 17 Mar 2006 20:06:20 -0800
Links: << >>  << T >>  << A >>
Unless you have some sentimental attachment, there is no reason to even
think of using such obsolete parts for a new project.
Would you start a music library on 8-tracks?
Would you go on vacation with a super-8 movie camera ?
Would you buy a car with an SU carburator and drum brakes( except for
reasons of nostalgia)?
You are lacking not "just software": software is the most crucial
ingredient.
The smallest and cheapest Spartan3 chip runs circles around the 3042.
If you need even less, use CoolRunner CPLDs, they are great and work
with microamps...
Peter Alfke, Xilinx Applictions from home


Article: 98960
Subject: Re: Support software for XC3042
From: "J Silverman" <g1powermac@yahoo.com>
Date: Fri, 17 Mar 2006 20:24:45 -0800
Links: << >>  << T >>  << A >>
Hi Peter,

The main reason why I want to use these FPGAs is because they're in a simple enough package (PLCC84) that I could breadboard them directly with an adapter. And I also do not need anything more complicated than them in the number of gates and such. The project I'm working on is an intermediate step, which will be replaced with much newer and more powerful parts when I'm able to. A way to be able to program these FPGAs somehow would be great for what I need.

Thanks, J Silverman

Article: 98961
Subject: Re:Disk/LCD defect tolerant models for FPGA sales
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 18 Mar 2006 17:42:37 +1300
Links: << >>  << T >>  << A >>
  Thread name changed to explore an interesting point:

fpga_toys@yahoo.com wrote:
> Peter Alfke wrote:
> 
>>Without EasyPath any production device with any known defect (that is
>>not covered by an errata note) goes into the garbage can.
>>That has been and will remain our policy, and I assume the policy of
>>any reputable IC manufacturer.
> 
<snip>
> I remember the 1980's when the disk drive industry was going thru that
> too. Just try and buy a half million zero defect drives today.
> 
> Maybe some stock holders aught to be asking your board why you are so
> eager to crush into the can near perfect dies and packaged parts for a
> single (or small number) of flaws that might easily bring another
> 10-50% in sales into users perfectly willing to purchase parts with
> classified flaws they can design around.

Sounds OK, at first glance.

  But Disk drives have an inherent storage for defect maps, and LCD 
screens rather 'self document' any faulty pixels.

  So, how to actually do that, in a RAM based FPGA ?

  You don't REALLY want to do what the Russians used to, and ship a
errata per device ?!

  I think Altera have a method for re-mapping defective areas, so they
can make real yields higher.
  Not sure about Xilinx, or others ?
  Xilinx did have a patent swap, after they both finally tired of 
feeding the lawyers, but it takes years for that to work into silicon.


> I'm perfectly willing to design reconfigurable computers with a few
> routing and LUT failures that we can map around with a defect list
> keepaway table. I'd be even happy to get them as bare, but mountable
> die.

  So, that means the Tools have to be defect-literate, and be able to
read a device ID and then find that device's defect map ?

  I suppose that is do-able, but it does not sound cheap, and the SW
teams are struggling with quality now, do we really want them
distracted with defect mapping ?

  How long can you tolerate running a Place/Route, for just one device ?

> Anybody else here that would be willing to purchase high end FPGA's for
> reconfigurable computing with a few minor flaws? Since they are trash
> to you, can I get several thousand XC4VLX200's at say a 90-95%
> discount? hmm ... maybe that's to low an offer, and there is a bidding
> war ready to errupt.

  Another minus to this idea, is that of counterfeit devices.
How can Xilinx prevent the defect devices, entering a grey market, sold
as fully functional devices ?
  Sounds like a Device ID again...

Problem is, device ID is not in any present Xilinx silicon ?

  Others are looking at this (IIRC Actel use something like this, to
'lock' their ARM cores, to Silicon that includes the license fees? )

  There might be long-term potential, for some FPGA vendor to
make their Tools and Silicon Defect-map-smart, but the P&R would have
to be way faster than present - and anyway, why not just fix it in 
silicon, with some redundancy and fuse re-mapping ?.

  Seems only a tiny portion of users could tolerate the custom P&R's ?

-jg


Article: 98962
Subject: Microblaze FSL peripheral problem
From: dotnetters@gmail.com
Date: 17 Mar 2006 21:05:26 -0800
Links: << >>  << T >>  << A >>
Hello All!
We are newbies to FPGAs and VHDL. We're doing a project on it and we
need to have custom hardware for it. We then settled for the FSL
solution. We are just starting to work on it.. We wanted to have a very
primitive ALU kind of a thing. We set out editing the a template file
generated when we create a new peripheral on XPS (We use EDK7.1), which
gets 8 input words and returns their sum. We modified the VHDL code to
want to it to work this way: get an opcode, get two operands and return
the sum or difference based on the opcode. Something kind of this:
if(opcode == )
   return a+b;
else
   return a * b;
But its not working. We tried out many things, but in vain. I'm
copy-n-paste-ing the VHDL code here and also the C file. Please help us
figure out the problem:

------------------------------------------------------------------------------
-- MyIP - entity/architecture pair
------------------------------------------------------------------------------
--
--
***************************************************************************
-- ** Copyright (c) 1995-2005 Xilinx, Inc.  All rights reserved.
    **
-- **
    **
-- ** Xilinx, Inc.
    **
-- ** XILINX IS PROVIDING THIS DESIGN, CODE, OR INFORMATION "AS IS"
    **
-- ** AS A COURTESY TO YOU, SOLELY FOR USE IN DEVELOPING PROGRAMS AND
    **
-- ** SOLUTIONS FOR XILINX DEVICES.  BY PROVIDING THIS DESIGN, CODE,
    **
-- ** OR INFORMATION AS ONE POSSIBLE IMPLEMENTATION OF THIS FEATURE,
    **
-- ** APPLICATION OR STANDARD, XILINX IS MAKING NO REPRESENTATION
    **
-- ** THAT THIS IMPLEMENTATION IS FREE FROM ANY CLAIMS OF INFRINGEMENT,
    **
-- ** AND YOU ARE RESPONSIBLE FOR OBTAINING ANY RIGHTS YOU MAY REQUIRE
    **
-- ** FOR YOUR IMPLEMENTATION.  XILINX EXPRESSLY DISCLAIMS ANY
    **
-- ** WARRANTY WHATSOEVER WITH RESPECT TO THE ADEQUACY OF THE
    **
-- ** IMPLEMENTATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OR
    **
-- ** REPRESENTATIONS THAT THIS IMPLEMENTATION IS FREE FROM CLAIMS OF
    **
-- ** INFRINGEMENT, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
    **
-- ** FOR A PARTICULAR PURPOSE.
    **
-- **
    **
-- ** YOU MAY COPY AND MODIFY THESE FILES FOR YOUR OWN INTERNAL USE
SOLELY  **
-- ** WITH XILINX PROGRAMMABLE LOGIC DEVICES AND XILINX EDK SYSTEM OR
    **
-- ** CREATE IP MODULES SOLELY FOR XILINX PROGRAMMABLE LOGIC DEVICES
AND    **
-- ** XILINX EDK SYSTEM. NO RIGHTS ARE GRANTED TO DISTRIBUTE ANY FILES
    **
-- ** UNLESS THEY ARE DISTRIBUTED IN XILINX PROGRAMMABLE LOGIC DEVICES.
    **
-- **
    **
--
***************************************************************************
--
------------------------------------------------------------------------------
-- Filename:          MyIP
-- Version:           1.00.a
-- Description:       Example FSL core (VHDL).
-- Date:              Mon Mar 13 20:23:40 2006 (by Create and Import
Peripheral Wizard Wizard)
-- VHDL Standard:     VHDL'93
------------------------------------------------------------------------------
-- Naming Conventions:
--   active low signals:                    "*_n"
--   clock signals:                         "clk", "clk_div#", "clk_#x"
--   reset signals:                         "rst", "rst_n"
--   generics:                              "C_*"
--   user defined types:                    "*_TYPE"
--   state machine next state:              "*_ns"
--   state machine current state:           "*_cs"
--   combinatorial signals:                 "*_com"
--   pipelined or register delay signals:   "*_d#"
--   counter signals:                       "*cnt*"
--   clock enable signals:                  "*_ce"
--   internal version of output port:       "*_i"
--   device pins:                           "*_pin"
--   ports:                                 "- Names begin with
Uppercase"
--   processes:                             "*_PROCESS"
--   component instantiations:              "<ENTITY_>I_<#|FUNC>"
------------------------------------------------------------------------------

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

-------------------------------------------------------------------------------------
--
--
-- Definition of Ports
-- FSL_Clk             : Synchronous clock
-- FSL_Rst           : System reset, should always come from FSL bus
-- FSL_S_Clk       : Slave asynchronous clock
-- FSL_S_Read      : Read signal, requiring next available input to be
read
-- FSL_S_Data      : Input data
-- FSL_S_CONTROL   : Control Bit, indicating the input data are control
word
-- FSL_S_Exists    : Data Exist Bit, indicating data exist in the input
FSL bus
-- FSL_M_Clk       : Master asynchronous clock
-- FSL_M_Write     : Write signal, enabling writing to output FSL bus
-- FSL_M_Data      : Output data
-- FSL_M_Control   : Control Bit, indicating the output data are contol
word
-- FSL_M_Full      : Full Bit, indicating output FSL bus is full
--
-------------------------------------------------------------------------------

------------------------------------------------------------------------------
-- Entity Section
------------------------------------------------------------------------------

entity MyIP is
    port
    (
        -- DO NOT EDIT BELOW THIS LINE ---------------------
        -- Bus protocol ports, do not add or delete.
        FSL_Clk    : in    std_logic;
        FSL_Rst    : in    std_logic;
        FSL_S_Clk    : out    std_logic;
        FSL_S_Read    : out    std_logic;
        FSL_S_Data    : in    std_logic_vector(0 to 31);
        FSL_S_Control    : in    std_logic;
        FSL_S_Exists    : in    std_logic;
        FSL_M_Clk    : out    std_logic;
        FSL_M_Write    : out    std_logic;
        FSL_M_Data    : out    std_logic_vector(0 to 31);
        FSL_M_Control    : out    std_logic;
        FSL_M_Full    : in    std_logic
        -- DO NOT EDIT ABOVE THIS LINE ---------------------
    );

attribute SIGIS : string;
attribute SIGIS of FSL_Clk : signal is "Clk";
attribute SIGIS of FSL_S_Clk : signal is "Clk";
attribute SIGIS of FSL_M_Clk : signal is "Clk";

end MyIP;

------------------------------------------------------------------------------
-- Architecture Section
------------------------------------------------------------------------------

-- In this section, we povide an example implementation of ENITY MyIP
-- that does the following:
--
-- 1. Read all inputs
-- 2. Add each input to the contents of register 'sum' which
--    acts as an accumulator
-- 3. After all the inputs have been read, write out the
--    content of 'sum' into the output FSL bus NUMBER_OF_OUTPUT_WORDS
times
--
-- You will need to modify this example or implement a new architecture
for
-- ENTITY MyIP to implement your coprocessor

architecture EXAMPLE of MyIP is

   -- Total number of input data.
   constant NUMBER_OF_INPUT_WORDS  : natural := 3;

   -- Total number of output data
   constant NUMBER_OF_OUTPUT_WORDS : natural := 1;

   type STATE_TYPE is (Idle, Read_Operands, Write_Outputs);

   signal state        : STATE_TYPE;

   -- Accumulator to hold sum of inputs read at any point in time
   signal sum          : std_logic_vector(0 to 31);
   signal op           : std_logic_vector(0 to 31);

   -- Counters to store the number inputs read & outputs written
   signal nr_of_reads  : natural range 0 to NUMBER_OF_INPUT_WORDS - 1;
   signal nr_of_writes : natural range 0 to NUMBER_OF_OUTPUT_WORDS - 1;

-- Stack definition starts =======================
   -- The Stack
    constant MAXSTACK:INTEGER := 256; -- the max stack file length
    type stack_file is array (MAXSTACK-1 downto 0) of
std_logic_vector(0 to 31); -- 256 entry stack.
    signal TheStack : stack_file;

    -- Stack variables and pointers
    signal sp : std_logic_vector ( 0 to 8-1 ) := (others=>'0') ;    --
the stack pointer
    signal localStart : std_logic_vector ( 0 to 8-1 ) := (others=>'0')
;
    signal argsStart : std_logic_vector ( 0 to 8-1 ) := (others=>'0') ;

    type StackState is (CTRL, DATA, ARGSDATA, LDLOCS);
    signal nextState : StackState := CTRL; -- first to start with: Ctrl
signal.
-- Stack definition ends =========================


begin
   -- CAUTION:
   -- The sequence in which data are read in and written out should be
   -- consistant with the sequence they are written and read in the
   -- driver's MyIP.c file

   FSL_S_Read  <= FSL_S_Exists   when state = Read_Operands else '0';
   FSL_M_Write <= not FSL_M_Full when state = Write_Outputs else '0';

   FSL_M_Data <= sum;

   The_SW_accelerator : process (FSL_Clk) is
   begin  -- process The_SW_accelerator
    if FSL_Clk'event and FSL_Clk = '1' then     -- Rising clock edge
      if FSL_Rst = '1' then               -- Synchronous reset (active
high)
        -- CAUTION: make sure your reset polarity is consistant with
the
        -- system reset polarity
        state        <= Idle;
        nr_of_reads  <= 0;
        nr_of_writes <= 0;
        sum          <= (others => '0');
      else
        case state is
          when Idle =>
            if (FSL_S_Exists = '1') then
              op <= std_logic_vector(unsigned(FSL_S_Data));
              state       <= Read_Operands;
              nr_of_reads <= NUMBER_OF_INPUT_WORDS - 1;
              sum         <= (others => '0');
            end if;

          when Read_Operands =>
            if (FSL_S_Exists = '1') then
                  if (unsigned(op) = 0) then
                      sum         <= std_logic_vector(unsigned(sum) +
unsigned(FSL_S_Data));
                elsif (unsigned(op) = 1) then
                    sum         <= std_logic_vector(unsigned(sum) *
unsigned(FSL_S_Data));
                else
                    sum <= "10101010101010101010101010101010";
                end if;
                  if (nr_of_reads = 0) then
                    state        <= Write_Outputs;
                    nr_of_writes <= NUMBER_OF_OUTPUT_WORDS - 1;
                  else
                    nr_of_reads <= nr_of_reads - 1;
                    state <= Read_Operands;
                  end if;
            end if;

          when Write_Outputs =>
            if (nr_of_writes = 0) then
              state <= Idle;
            else
              if (FSL_M_Full = '0') then
                nr_of_writes <= nr_of_writes - 1;
              end if;
            end if;
        end case;
      end if;
    end if;
   end process The_SW_accelerator;
end architecture EXAMPLE;


And this is the C file:
/*
 *  * Copyright (c) 2004 Xilinx, Inc.  All rights reserved.
 *
 * Xilinx, Inc.
 * XILINX IS PROVIDING THIS DESIGN, CODE, OR INFORMATION "AS IS" AS A
 * COURTESY TO YOU.  BY PROVIDING THIS DESIGN, CODE, OR INFORMATION AS
 * ONE POSSIBLE   IMPLEMENTATION OF THIS FEATURE, APPLICATION OR
 * STANDARD, XILINX IS MAKING NO REPRESENTATION THAT THIS
IMPLEMENTATION
 * IS FREE FROM ANY CLAIMS OF INFRINGEMENT, AND YOU ARE RESPONSIBLE
 * FOR OBTAINING ANY RIGHTS YOU MAY REQUIRE FOR YOUR IMPLEMENTATION
 * XILINX EXPRESSLY DISCLAIMS ANY WARRANTY WHATSOEVER WITH RESPECT TO
 * THE ADEQUACY OF THE IMPLEMENTATION, INCLUDING BUT NOT LIMITED TO
 * ANY WARRANTIES OR REPRESENTATIONS THAT THIS IMPLEMENTATION IS FREE
 * FROM CLAIMS OF INFRINGEMENT, IMPLIED WARRANTIES OF MERCHANTABILITY
 * AND FITNESS FOR A PARTICULAR PURPOSE.
 */

/*
 * Xilinx EDK 7.1.2 EDK_H.12.5.1
 *
 * This file is a sample test application
 *
 * This application is intended to test and/or illustrate some
 * functionality of your system.  The contents of this file may
 * vary depending on the IP in your system and may use existing
 * IP driver functions.  These drivers will be generated in your
 * XPS project when you run the "Generate Libraries" menu item
 * in XPS.
 *
 * Your XPS project directory is at:
 *    C:\Projects
 */


// Located in: microblaze_0/include/xparameters.h
#include "xparameters.h"

#include "mb_interface.h"

#include "xutil.h"

//====================================================

int main (void) {


   print("-- Entering main() --\r\n");
   int i = 0, k=0, r=0, j=0;

   /*
    * MemoryTest routine will not be run for the memory at
    * 0x00000000 (dlmb_cntlr)
    * because it is being used to hold a part of this application
program
    */

    microblaze_bwrite_datafsl(0,0);
    microblaze_bwrite_datafsl(304,0);
    microblaze_bwrite_datafsl(1,0);

    for(i=0;i<100;i++);
    microblaze_nbread_datafsl(j,1);
    xil_printf("%d; ",j);

    microblaze_bwrite_datafsl(1,0);
    microblaze_bwrite_datafsl(1,0);
    microblaze_bwrite_datafsl(1,0);

    for(i=0;i<100;i++);
    microblaze_nbread_datafsl(j,1);
    xil_printf("%d; ",j);

    microblaze_bwrite_datafsl(0,0);
    microblaze_bwrite_datafsl(22,0);
    microblaze_bwrite_datafsl(2,0);
    microblaze_nbread_datafsl(j,1);
    xil_printf("%d; ",j);

   print("-- Exiting main() --\r\n");
   return 0;
}

Its not working as expected. Please help.

Thanks.
-- Dotnetters.


Article: 98963
Subject: Re: for all those who believe
From: austin <austin@xilinx.com>
Date: Fri, 17 Mar 2006 21:14:10 -0800
Links: << >>  << T >>  << A >>
Retire?

Wow.

That is a very strange thought.

Both Peter and I are "retire-adverse."

We are having far too much fun watching and helping Xilinx grow.

And I think I am more than young enough to be Peter's child, not his peer.

Amusing post,

Austin

Article: 98964
Subject: Re: Support software for XC3042
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 17 Mar 2006 21:38:22 -0800
Links: << >>  << T >>  << A >>
I can only repeat: you will be much happier with a low-cost evaluation
bord, where you can concentrate on the uniquness of your design,
instead of being bogged down by software issues and soldering mishaps.
For real simple circuits, look at CoolRunner CPLDs.
Peter Alfke


Article: 98965
Subject: Re: Re:Disk/LCD defect tolerant models for FPGA sales
From: fpga_toys@yahoo.com
Date: 17 Mar 2006 21:55:35 -0800
Links: << >>  << T >>  << A >>

Jim Granville wrote:
>   So, that means the Tools have to be defect-literate, and be able to
> read a device ID and then find that device's defect map ?

Having a unique serial number for identification might be nice, but is
certainly not necessary to apply defect mapping to a particular well
known FPGA device. Two likely environments exist ... the fpga device,
or devices are mounted on a pci card and installed in a traditional
system. The installation process for that card would run extensive
screening diagnostics, and develop and error map for it. The driver for
that device, interfaced to the tool chain would make the map available
as a well known service. In addition the device/card would be sold with
either media or internet access to the more accurate testing done prior
to sale by the mfg.

The other likely RC environment, are FPGA centric processor clusters,
built arround a mix of pure logic FPGA's (like XC4VLX200's) coupled
with cpu core FPGAs (II-Pro and SX parts) possibly coupled to 32/64bit
traditional risc processors. These have been my research for the last 5
years. These super computers would be targeting extereme performance
for mostly high end simulation and processing applications
traditionally found doing nuke simulations, heat/stress sim's, weather
sims, genetic sim and searches, and other specialty applications.
Machines doing this in various degress exist today in both research and
production environments. The software for controlling these machines
and ground up vendor specific designs .... and defect management is a
trivial task for that software.

>   I suppose that is do-able, but it does not sound cheap, and the SW
> teams are struggling with quality now, do we really want them
> distracted with defect mapping ?

Defect mapping is an integral part of every operating system, and you
will find it to cover for faults on floppy media, optical media, and
even hard drives .... it's part of most filesystems.
Providing defect mapping generated keep out zones on the fpga for place
and route is rather trivial. That is a very small price to pay to have
access to large numbers of relatively inexpensive FPGA's. Anything that
will allow effectively higher yields will lower the prices for RC
computing based on defect management, AND lower the price for zero
defect parts where the design and deployment infrastructure is unable
to handle defect mangement due to fixed bitstreams.

>   How long can you tolerate running a Place/Route, for just one device ?

For RC ... not long at all. Which is why different strategies which are
baed in fast acceptable placement and routing, with dynamic clock
fitting are better for RC, while extensive optimization for fixed
bitstreams used in embedded applications need the tools used today. RC
has very very different goals .... bitstreams whose life may be
measured in seconds, or hours, maybe even a few days. Embedded is
trying to optimize many other variables, and for the goal of using
bitstreams with lifetimes in years.

>   There might be long-term potential, for some FPGA vendor to
> make their Tools and Silicon Defect-map-smart, but the P&R would have
> to be way faster than present - and anyway, why not just fix it in
> silicon, with some redundancy and fuse re-mapping ?.

Much easier said that done, and loaded with the same problems that
dynamic sparing has in disk drives. To access a spared sector requires
a seek, and rotational latency loss TWICE for each error .... huge
performance penalty. Ditto for FPGA's when you have to transparently
alter routing to another LUT in an already densely routed design.

Defect tollerant is a completely different strategy where place and
route happens defect aware. It's actually not that difficult to edit a
design on the fly .... using structures similar to todays cores, which
are linked as a block into an existing netlist. That can happen both
quickly and distort the prelinked/routed object during the load process
to effect the remapping around the failed resources.

Anyway ... zero defect designs need zero defect parts, systems designed
around defect tollarent strategies are built from the ground up to
edit/alter/link the design around defects to avoid them.
This could be done using a soft core or a $1 micro on board with the
fpga for embedded designs that do not want to suffer the zero defect
price premium.

>   Seems only a tiny portion of users could tolerate the custom P&R's ?

With todays ISE tools ... that is certainly true.  Using custom JBits
style loaders, such as found in JHDL and JHDLBits, really a piece of
cake using mature tools that have been around for many years on the
educational side, with some small tweeks for defect mapping. All the
same tools the FpgaC project needs for compile load and go to an FPGA
coprocessor board.

Tiny relative to the size of the FPGA universe today  ... sure. Tiny in
terms of dollars and importance certainly not. Completely disjoint to
embedded fpga design today ... different customers, different designs,
different cost structures, different applications.


Article: 98966
Subject: Re: for all those who believe
From: fpga_toys@yahoo.com
Date: 17 Mar 2006 21:58:04 -0800
Links: << >>  << T >>  << A >>

austin wrote:
> Retire?
>
> Wow.
>
> That is a very strange thought.
>
> Both Peter and I are "retire-adverse."
>
> We are having far too much fun watching and helping Xilinx grow.
>
> And I think I am more than young enough to be Peter's child, not his peer.
>
> Amusing post,
>
> Austin

Sorry ... I would have swore I remember a post where you claimed at
least the number of years in the industry as I.


Article: 98967
Subject: Re: for all those who believe
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 17 Mar 2006 22:04:12 -0800
Links: << >>  << T >>  << A >>
Jim, pretty unlikely.
It would only make sense on the really big devices. Smaller devices do
not need such a crutch.
At the high end, we now have 80 million configuration bits, each of
them responsible for one tiny aspect of the functionality. Tough job to
keep track of that. And how can the user work around it ?  When the
chip is simple, it does not buy you anything. When it is really big,
the work-around methodology chokes on its complexity.
Our production testing is always go/no-go, which means we do not even
try to identify the failure, it's just either perfect or scrap. Even
the EasyPath testing is that way; but after a more restricted test that
gives much improved yield. (Such a clever concept!)
Very regular structures (like memories) can use self-repairing
non-volatile fixes. Altera's earlier FPGAs (called CPLDs) had a regular
interconnect structure that allowed such redundant repair, and most big
memories do it. So selling parts with non-functional circuitry on it is
neither new nor unusual (nor unreliable).
But most FPGA structures are too complex and irrgular to allow that,
IMHO.
Wherever the IC manufacturer can really make the repair transparent to
the user, it will obviously be done.
Peter Alfke


Article: 98968
Subject: Re: where can I find the simulation model of the sram, ISSI61LV25616?
From: "moo" <moo@bmi.be.cycu.edu.tw>
Date: Sat, 18 Mar 2006 01:06:24 -0600
Links: << >>  << T >>  << A >>
>Hello,Everbody!!!
>I'm working with the spartan3 starter kit,I want to use the on-board
sram
>for temporary data storage,so I hope to find the simulation model of the
>sram(ISSI61LV25616-10T) for function and timing simulation .Please!
>Somebody tell me where I can find the simulation model,or anybody
provided
>me some suggestions about how to verify the timing.Thank you!!!! 
>
>
>
sorry,everbody!!!!
I have found the verilog model from the ISSI's web.


Article: 98969
Subject: Re: Microblaze FSL peripheral problem
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Sat, 18 Mar 2006 08:36:59 +0100
Links: << >>  << T >>  << A >>
dotnetters@gmail.com wrote:

> We are newbies to FPGAs and VHDL.
...
> We modified the VHDL code to
> want to it to work this way: get an opcode, get two operands and return
> the sum or difference based on the opcode. Something kind of this:
> if(opcode == )
>    return a+b;
> else
>    return a * b;
> But its not working.

This sounds to me to be a pure VHDL problem. -> comp.lang.vhdl

You seek for a pure combinational solution (add, mul, mux) and post a 
code of a state machine, which is sequential. What do you want? ;-)

Do your try to get something running by modifying examples so that it 
fits your requirements? I would not recommend this. Use examples as 
ideas and guidelines, but write your own code.

Wouldn't it be a good idea to post a _minimal example_ of your problem?

Ralf

Article: 98970
Subject: Re: Urgent Help Needed!!!!!
From: "Chauhan" <coolsaroj@gmail.com>
Date: 17 Mar 2006 23:45:11 -0800
Links: << >>  << T >>  << A >>
Thank u Isaac.Now u also hav understood that there is no point in
discussing these topics anymore bcoz neither of the generations is
having mutual respects for each other.So burry this topic here itself.
Thank u once again.


Article: 98971
Subject: Re: Urgent Help Needed!!!!!
From: "Chauhan" <coolsaroj@gmail.com>
Date: 17 Mar 2006 23:51:15 -0800
Links: << >>  << T >>  << A >>
Special Thanks to Ralf Hildebrandt
who ignored the formalities and helped with his valuable
suggestion.Thank u Ralf.


Article: 98972
Subject: Re: Instantiating addsub, comparators in Xilinx
From: "Leow Yuan Yeow" <nordicelf@msn.com>
Date: Sat, 18 Mar 2006 00:03:10 -0800
Links: << >>  << T >>  << A >>
Hi, I was doing that before but I found that each + that I use generates a 
32-bit adder under the synthesis report which increases the LUT usage by 
quite a fraction. After that I tried to multiplex them to a addsub component 
and the LUT usage went down from 90+% to 80+% (I'm using the old RC100 board 
with spartan II so I have limited resources :( ).
I was wondering if there are any other components that I can instantiate for 
comparators as well?

"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message 
news:1142607625.918465.315430@e56g2000cwe.googlegroups.com...
> Hi,
> Please do the following way:
>
> LIBRARY ieee;
> USE ieee.std_logic_1164.all;
> use ieee.numeric_std.all;
>
> signal A : unsigned(4 downto 0); -- example
> signal B : unsigned(4 downto 0); -- example
>
> In the code area,
>
> -- they can be in process or between process area.
> A <= A + 5;
> B <= B - 7;
>
> No need to instantiate any module.
> In numeric.vhd liberary, all arithmatic operations are functions.
>
> Weng
> 



Article: 98973
Subject: Re: Microblaze FSL peripheral problem
From: dotnetters@gmail.com
Date: 18 Mar 2006 00:08:28 -0800
Links: << >>  << T >>  << A >>
Ralf,
Sorry, we were right from the start doubtful whether this was the right
group to ask for clarification. But since we had problems with FSL,
which was more to the MicroBlaze side, we thought it would be fine to
do so.. And obviously, we were wrong..
Anyway, thanks.

Cheers, everyone..

-- DotNetters


Article: 98974
Subject: Re: Microblaze FSL peripheral problem
From: Sylvain Munaut <tnt-at-246tNt-dot-com@youknowwhattodo.com>
Date: Sat, 18 Mar 2006 09:52:19 +0100
Links: << >>  << T >>  << A >>
Your first VHDL looks wrong ...

You put :

    FSL_S_Read  <= FSL_S_Exists   when state = Read_Operands else '0';

But you read data during the IDLE cycle as well, since you read the
operation to do during that cycle. So it should be

    FSL_S_Read  <= FSL_S_Exists   when (state = Read_Operands) or (state
= Idle) else '0';

But then you don't need to read 3 data during the Read_Operands state
but only 2. So you should use

	constant NUMBER_OF_INPUT_WORDS  : natural := 2;

You made theses mistakes because you tries to modify code you didn't
understand properly. You should have written your peripheral from
scratch, using the demo code to see how FSL works.


	Sylvain






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