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
2017JanFebMarApr2017

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 26150

Article: 26150
Subject: Re: Pwr/Gnd ( again)
From: husby@my-deja.com
Date: Thu, 05 Oct 2000 17:28:49 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote:
> Also, be aware that using a bonded IO and it's internal pullup for
> this leaves an avenue to introduce emi into your design, as you have
> a fairly high impedance antenna.

Also, if you tie a signal to a pin, the optimizer won't recoginze
it as a constant (VCC or GND) and can't optimize it away.






Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 26151
Subject: PhD studentship
From: Alastair Allen <a.allen@abdn.ac.uk>
Date: Thu, 05 Oct 2000 18:50:39 +0100
Links: << >>  << T >>  << A >>
Research Studentship available: 

Neural systems engineering for embedded machine vision 

Applications are invited for a fully-funded, three-year PhD studentship.
The work will be researching future artificial neural network (ANN)
architectures based on
our neural hardware. 

The types of vision application which will form the basis for mass
implementation over the next few years are those requiring the embedding
of intelligent pattern
recognition systems into industrial processes, instrumentation and
portable systems. These systems will make extreme demands on the
hardware, requiring the
integration of traditional image processing with ANN techniques, and
implemented in designs with small footprint and low power consumption.
The project will
research methods for the efficient embedding of imaging algorithms into
hardware and neural arrays. A hardware implementation of the system will
be developed. 
The work will be motivated by industrially relevant demonstrator
applications, and will include collaboration with system developers and
end users. 

The studentship is partly funded by AXEON Ltd who are developing novel
processor systems. The student would join a lively and rapidly expanding
novel architectures
research group in the Department of Engineering. 

The funding of the studentship covers UK/EU tuition fees and a
maintenance grant equivalent to standard Research Council rates.
Applicants should have a good first
degree (equivalent of UK 1st class or upper second) in electronic
engineering, physics or computational science. Informal enquiries may be
directed to Dr Alastair
Allen. Email: a.allen@abdn.ac.uk. Tel: +44 1224 272501. Fax: +44 1224
272497. 

Application forms: Postgraduate Office, Department of Engineering,
Fraser Noble Building, University of Aberdeen, Aberdeen, AB24 3UE, UK.
Tel: +44 1224
272513. Fax: +44 1224 273895. Email: pgoffice@eng.abdn.ac.uk

Article: 26152
Subject: Re: pci host
From: steve (Steve Rencontre)
Date: Thu, 5 Oct 2000 18:51 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <8rfbre$oor$1@eol.dd.chalmers.se>, 
danielnilsson@REMOVE_THIShem3.passagen.se (Daniel Nilsson) wrote:

> Hi. I wonder what it would take to make a sharc dsp to pci controller (I
> only need very basic pci functionality, enough to control a pci ethernet
> card, with dma).

Well, you can connect a 21065L to an Intel 82559 with a small CPLD/FPGA 
(about three-quarters of a Cypress 373i will do) and a couple of 16646 bus 
buffers. Oh, plus the clever VHDL and Sharc code to make it work :-)

No more than minor variations are likely to be necessary for other Sharcs 
and Ethernet controllers, but those are what I used.

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>


Article: 26153
Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 05 Oct 2000 13:56:06 -0400
Links: << >>  << T >>  << A >>
Jamie Lokier wrote:
> 
> Ray Andraka writes:
> > ... doesn't require my customer to have the extras to support the design.
> 
> Is it principally due to $$$, or training & tool familiarity?
> Specifically, if there was a really good GPL synthesis tool (no license
> fee + you have the source), and the tool suited your style of work,
> would you use it for customer project?  Or would there still be a
> significant non-technical barrier for use of a new tool?
> 
> I was talking to an Altera FAE who felt that going into competition with
> Synplicity on synthesis via the GPL route would be no good because
> customers are far too reluctant to switch tools.  I suspect $$$ may have
> something to do with this though.  Any well put together tool should do
> its best to fit in with the customer's existing tools.
> 
> (The Altera connection was because the FAE thought Synplicity had access
> to low-level FPGA data that even he did not have, and despite saying
> that Altera are 100% a hardware company they still won't be making it
> easy for third parties to develop good bitstream-level optimisers).
> 
> -- Jamie

I think there are a lot of issues in the topic of open source tools. I
don't know that users are any more reluctant to change tools than
software developers are due to unfamiliarity of the new tool, cost, etc.
But FPGA tools are unique due to several reasons. 

One is the fact that there is a much smaller market for the end use of
the tool. So development costs a lot more when spread over the smaller
user base. Certainly customers are sensitive to tools costs. 

Another is the fact that the target of the tools seem to change a lot
more extensively and quickly than the CPUs that are the targets of SW
development tools. This makes it hard and expensive for both the
commercial and any potential freeware/open source tools to be kept up to
date. 

So even if the dollars were dropped as an issue, it is no small task to
keep a toolset up to date with the new architectures in FPGAs. I for one
would embrace open source tools if they work and can be used
efficiently. Even though the vendors charge for their tools, that is not
the real cost of using them. The big bucks are spent dealing with all
the design "issues" that they create. A constantly changing open source
toolset would not have any less "issues" than commercial tools and may
be worse. 

One last note; the chip vendors are not really interested in open source
tools since they feel that they will have to "support" any and all tools
that are used to program their parts. I know that Peter Alfke from
Xilinx has stated on more than one occasion that Xilinx would want to
support customers regardless of how they were generating the bitstream.
In theory they are a hardware company and will have to provide this
support to sell chips. Open source tools would be a can of worms for
them if they really adopt this approach. 

Personally I think that open source tools could be a major boon to the
FPGA community. Especially if it fosters innovation in how the tools
work and the user interfaces. I think that tool and FPGA vendors have a
large interest in reducing "support" which often means catering to the
lowest common denominator. The results are tools that "get in the way"
in many respects in order to offer a minimal learning curve to
beginners. Not that this is bad. But I would like to see what happens if
tools are developed by the tool users rather than the tool sellers. 

Too bad that FPGA designers are not the same community as the software
developers. Carpenters make tools out of wood. Machinists make tools out
of metal. Software developers make tools out of software. What tools do
hardware designers make?

-- 

Rick "rickman" Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 26154
Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response
From: Ray Andraka <ray@andraka.com>
Date: Thu, 05 Oct 2000 18:19:36 GMT
Links: << >>  << T >>  << A >>
It's not the $$$, Its the learning curve and effort to stay competent on yet
another set of tools, and the inevitable generating test cases for tech support.

Part of the problem with the state of the industry is the rate of change.  The
average FPGA user does about one FPGA design every 18 months, mostly because he
is usually responsible for other things than just the FPGA.  As the tools
vendors, especially the synthesis guys have said, the only way to really get
good results out of the tools is to know the tool well.  Unfortunately, in the
18 months between FPGA designs, the designer is faced with a new FPGA generation
that is significantly different than the last and new versions of the tools, not
just a minor revision, but usually a whole new user interface.  At that rate of
use, the designer has a difficult time just getting competent on the tools much
less mastering them.  It would help if the user interfaces stayed more constant,
but beyond that, I don't see any easy answers. 

My resistance to Amplify is that for the design method I have adopted, it offers
very little if any added value.  Even if the cost was not a quantum leap, the
investment in time to master yet another tool is not warranted by the marginal
incremental value it presents to me.  On top of that, my current methodology has
a better than even shot of translating to another tool (I use Synplicity), for
example I know it will port to exemplar with very little additional effort,
mostly just changing the names of a few synthesis attributes.  If I were to use
Amplify, I get further away from standard VHDL when doing placed designs and
therefore lock myself into one tool.




Jamie Lokier wrote:
> 
> Ray Andraka writes:
> > ... doesn't require my customer to have the extras to support the design.
> 
> Is it principally due to $$$, or training & tool familiarity?
> Specifically, if there was a really good GPL synthesis tool (no license
> fee + you have the source), and the tool suited your style of work,
> would you use it for customer project?  Or would there still be a
> significant non-technical barrier for use of a new tool?
> 
> I was talking to an Altera FAE who felt that going into competition with
> Synplicity on synthesis via the GPL route would be no good because
> customers are far too reluctant to switch tools.  I suspect $$$ may have
> something to do with this though.  Any well put together tool should do
> its best to fit in with the customer's existing tools.
> 
> (The Altera connection was because the FAE thought Synplicity had access
> to low-level FPGA data that even he did not have, and despite saying
> that Altera are 100% a hardware company they still won't be making it
> easy for third parties to develop good bitstream-level optimisers).
> 
> -- Jamie

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

Article: 26155
Subject: Re: Simon , decoupling caps
From: "Bob Baman" <bbauman@lynxstudio.com>
Date: Thu, 05 Oct 2000 19:49:55 GMT
Links: << >>  << T >>  << A >>
Austin,

Just curious - will there be any specific references to decoupling caps for
BGA parts in the revision of XAPP158? This info would be very pertinent to
the Spartan II design I am wrapping up.

Regards,

Bob Bauman
Lynx Studio Technology



"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:39D25202.7DECA224@xilinx.com...
Martin,
In our appnote 158 (re-write due to be released perhaps this week), we make
a point of recommending a number of large capacitors precisely because we
don't know what the frequency distribution is, and you probably are not sure
either.
Austin



Article: 26156
Subject: Non-standard vhdl expressions
From: "Domagoj" <domagoj@engineer.com>
Date: Thu, 5 Oct 2000 23:43:16 +0200
Links: << >>  << T >>  << A >>
Hi there,
    My university working group is just about to start designing vhdl 93/87
simulator. We are not sure yet about the status ( freeware probably ).
Our problem is that there are many cases found in praxis, that are not
described in LRMs. Here are a few cases :
1) different number ranges that some tools support
2) library ieee;
    use std_logic_1164.all;
    Most of simulators support this behaviour.

Could anyone share his/her experiences with these problems ?
Please include a short explanation about the non-standard
behaviour, and the tool name that supports it, if possible.

Any comments would be highly appreciated.

regards,
-------------------------------------------
-             Domagoj              -
- Domagoj@engineer.com -
-------------------------------------------





Article: 26157
Subject: Re: Category : virtex e I/O bank contention
From: "Alun" <alun101@DELETEtesco.net>
Date: Thu, 5 Oct 2000 22:49:16 +0100
Links: << >>  << T >>  << A >>
> After configuration I see that the 3.3V rail is supplying  a portion of
the power to the 2.5V rail throuht some unknown path.Currently I'm powering
the 3.3V rail and 2.5V rail off a current limited bench supply. Eventually
the current drawn from the 2.5v bench supply reaches 0mA and  can be removed
from the equation- 2.5V being maintained by the 3.3V supply through some
unknown path.


Have you connected the pins to another device (eg an unconfigured FPGA) with
weak pull-ups to 3V3?

Alun




Article: 26158
Subject: Simultaneous Switching question
From: "Tom Hicks" <thicks@spinnakernet.com>
Date: Thu, 5 Oct 2000 15:04:39 -0700
Links: << >>  << T >>  << A >>
I'm wondering if the guidelines for simultaneous switching (max number of drivers of a certain type that can switch per power/gnd pair) is the limit for a specific power/ground pair (ex the drivers between VCC pad X and GND pad Y cannot simultaneously switch more than Z amount of curent) or do you simply sum up all simultaneous switching driver current and divide by the total number of power/ground pairs in the package.

-Tom

Article: 26159
Subject: Altera Internal Error
From: Gary Cook <gary_cook@ntlworld.com>
Date: Thu, 05 Oct 2000 23:18:20 +0100
Links: << >>  << T >>  << A >>
Running Maxplus 9.64 and am having problems getting
internal errors during fitting ... sometimes during
partitioner and even 1% through netlist compiler. It's
not consistant at all ... I can run fine for a while and
then bang! all of a sudden I can't compile a thing.
Altera support aren't much help and the web-site mentions
a similar error but doesn't give much help either ...
just wondering if anyone here's got any info that could
help...

not sure if it's an os thing ... running it on nt and get no
problems, running on win98 and get problems ... ???

Cheers,

Gary Cook.


Article: 26160
Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response
From: Zoltan Kocsi <root@127.0.0.1>
Date: 06 Oct 2000 10:34:56 +1100
Links: << >>  << T >>  << A >>
Jamie Lokier <spamfilter.oct2000@tantalophile.demon.co.uk> writes:

> Specifically, if there was a really good GPL synthesis tool (no license
> fee + you have the source), and the tool suited your style of work,
> would you use it for customer project?  Or would there still be a
> significant non-technical barrier for use of a new tool?

Of course ! GPL gives you a lot of benefit: you don't rely on the 
existence of the vendor, nor on its willing to help you with that
particular tool version. You are not tied to a particular platform
(Linux people would jump up and down for a GPL'd tool) and you can
twist and turn the tools any way you like to suite your needs.
The bug-elimination rate is way higher with free software than
with commercial one.

There's a drwaback as well: free tools usually come with no
glossy docs and idiot proof GUI frontends with buttons to mail 
to customer support. Setting up a crosscompiling and debugging
environment using gcc/gdb et al is not the same thing as running 
the Install Wizard and click on BuildProject then on FixBugs.
On the other hand, gcc/gdb et al are usually much more flexible
than the wizardish tools - this can come handy if you have to
do something unorthodox.

Never the less, the software development world seems to be quite happy 
about free tools. I, for one, would be quite happy to use GPL'd FPGA tools.
The problem I see is that logic synthesis is a rather hard nut. Not
many people know the intricate details of optimally mapping logic
onto arbitrary cell structures. I don't know books on synthesis like 
the Dragon Book on compiling. This severely limits the developer base.
In addition, the target audience is a much smaller lot than for 
software tools or general purpose programs.

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+

Article: 26161
Subject: Re: Xilinx Licensing.
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 06 Oct 2000 02:23:42 +0100
Links: << >>  << T >>  << A >>


rickman wrote:

> Was this the super computer talking? Or Marvin the paranoid android?

The computer called, I think, Deep Thought describing what was needed to calculate the question to which the
answer was 42.



Article: 26162
Subject: Re: pci host
From: sulimma@my-deja.com
Date: Fri, 06 Oct 2000 07:25:46 GMT
Links: << >>  << T >>  << A >>

> > Hi. I wonder what it would take to make a sharc dsp to pci
controller (I
> > only need very basic pci functionality, enough to control a pci
ethernet
> > card, with dma).

If it is just ethernet that you want, you can connect a CS8900a directly
to some general purpose I/O, or to the processors local bus with little
or no glue logic.

CU,
    Kolja


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 26163
Subject: Floorplanning
From: "Dines Justesen" <dcj_k@rescom.dk>
Date: Fri, 6 Oct 2000 09:33:27 +0200
Links: << >>  << T >>  << A >>
I a current design I am using Xilinx Virtex FPGAs to implement various DSP
functions. Most of the time the maximum frequency canbe increased quite a
bit by using the floorplanner.

The design is done using the express edition of Xilinx Foundation, and
consist of several smaller entityes which are then used to create the whole
system. What I would like to do is to florplan each of the smaller designs,
and then use these as RPMs in the top level design. I have look in the
manuals, on the xilinx website, and various other places on the net but have
been unable to find out whether this is possible using the express edition,
and how it is done. (I found a document descriing how to do use RLOCs in
VHDL code, but that did not work with express.

Does any one out there now whether this is possible in the express edition?
If it is possible where can I find information on how this is done?

Thanks,

dines

--
--------------------------------------------
Dines Justesen // dcj@rescom.dk
--------------------------------------------




Article: 26164
Subject: Re: Altera Internal Error
From: "JPC" <cachemi@cppm.in2p3.fr>
Date: Fri, 6 Oct 2000 10:40:12 +0200
Links: << >>  << T >>  << A >>
I'm running on NT and have a similar problem.
As I haven't any reply from Altera's support on this issue, I solved it in
reinstalling the 9.5 version.
Works fine now.

Jean-Pierre


"Gary Cook" <gary_cook@ntlworld.com> a écrit dans le message news:
39DCFE2C.82E5AF94@ntlworld.com...
> Running Maxplus 9.64 and am having problems getting
> internal errors during fitting ... sometimes during
> partitioner and even 1% through netlist compiler. It's
> not consistant at all ... I can run fine for a while and
> then bang! all of a sudden I can't compile a thing.
> Altera support aren't much help and the web-site mentions
> a similar error but doesn't give much help either ...
> just wondering if anyone here's got any info that could
> help...
>
> not sure if it's an os thing ... running it on nt and get no
> problems, running on win98 and get problems ... ???
>
> Cheers,
>
> Gary Cook.
>



Article: 26165
Subject: Re: Multiplication
From: Vipan Kakkar <vipank@cobalt.et.tudelft.nl>
Date: Fri, 06 Oct 2000 11:04:50 +0200
Links: << >>  << T >>  << A >>

--------------B31760737222B2DE001B88AE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear Friends:

It is OK, but I think then for the radix point repositioning ( for multiplication
with fractions) I need to do some division. If not then how can I do it? This
thing is new for me. I need help in this.

Regards,


Ray Andraka wrote:

> No hardware changes needed in the multiplier itself.  All you have to do is
> change the interpretation of the position of the radix point.  It is equivalent
> to scaling your input and output by 32 in your case.
>
> Vipan Kakkar wrote:
> >
> > Dear Friends:
> >
> > I would like to know that how to multiply e.g. 1100 with 0.0011. I
> > already have an array multplier to multiply e.g. 1100 with 0110. But,
> > now I want to multiply fractions (i.e. .0011) using the same multiplier,
> > so what modifications should I do in the existing multiplier.
> >
> > Regards
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com  or http://www.fpga-guru.com

--
____________________________________________________________________________
Vipan Kakkar (Research Assistant), Circuits & Systems Group,
Dept. of Electrical Engineering, Delft University of Technology,
Mekelweg 4, 2628 CD DELFT. The Netherlands.            Tel: +31 62 8171782



--------------B31760737222B2DE001B88AE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Dear Friends:
<p>It is OK, but I think then for the radix point repositioning ( for multiplication
with fractions) I need to do some division. If not then how can I do it?
This thing is new for me. I need help in this.
<p>Regards,
<br>&nbsp;
<p>Ray Andraka wrote:
<blockquote TYPE=CITE>No hardware changes needed in the multiplier itself.&nbsp;
All you have to do is
<br>change the interpretation of the position of the radix point.&nbsp;
It is equivalent
<br>to scaling your input and output by 32 in your case.
<p>Vipan Kakkar wrote:
<br>>
<br>> Dear Friends:
<br>>
<br>> I would like to know that how to multiply e.g. 1100 with 0.0011.
I
<br>> already have an array multplier to multiply e.g. 1100 with 0110.
But,
<br>> now I want to multiply fractions (i.e. .0011) using the same multiplier,
<br>> so what modifications should I do in the existing multiplier.
<br>>
<br>> Regards
<p>--
<br>-Ray Andraka, P.E.
<br>President, the Andraka Consulting Group, Inc.
<br>401/884-7930&nbsp;&nbsp;&nbsp;&nbsp; Fax 401/884-7950
<br>email ray@andraka.com
<br><a href="http://www.andraka.com">http://www.andraka.com</a>&nbsp; or
<a href="http://www.fpga-guru.com">http://www.fpga-guru.com</a></blockquote>

<pre>--&nbsp;
____________________________________________________________________________
Vipan Kakkar (Research Assistant), Circuits &amp; Systems Group,
Dept. of Electrical Engineering, Delft University of Technology,
Mekelweg 4, 2628 CD DELFT. The Netherlands.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel: +31 62 8171782</pre>
&nbsp;</html>

--------------B31760737222B2DE001B88AE--


Article: 26166
Subject: Problem Foundation 3.1 sp 3
From: Maciek Kudla <kudla@fuw.edu.pl>
Date: Fri, 06 Oct 2000 11:11:54 +0200
Links: << >>  << T >>  << A >>
After installation sp3 for Foundation 3.1 (Win98) I can not implement
any vhdl code.
Project menager stops with following message:
***
Reading component libraries for design expansion...
Annotating constraints to design from file "race.ucf" ...
Checking timing specifications ...
Checking expanded design ...
  The XML Parser environment is incorrectly set up, preventing it from
  finding its text transcoding files. Normally these will be located
  via the ICU_DATA environment variable, or located relative to the
  XML4C2 DLL (or SharedLib.) Please check your installation
***
Sombody knows what it is?

Maciek


Article: 26167
Subject: Re: Boundary Scan and LVDS in Virtex E
From: gabriel_t@my-deja.com
Date: Fri, 06 Oct 2000 09:35:35 GMT
Links: << >>  << T >>  << A >>


Hi Kent,
Thanks for your answer,


> As I understand it, it *is* possible . . . you simply set your pair of
> output pins such that one of the is logic '1', and the other one is
> logic '0'.  And then you invert them both.  This gives you two
> differential logic levels.
>

Yes I agree, this sounds possible. You drive the pins just like you
do it in VHLD when you instantiate a LVDS driver. But ...



> If I'm not mistaken, LVDS is 2.5v logic; I beleive that during the
> JTAG test the LVDS outputs will be the same as the Vccio pins for that
> I/O bank, so you should be safe there, too.

... the heart of the problem is here. LVDS is supplied in 2.5 V but it's
not a 2.5 V logic. LVDS common mode voltage is 1.25 V , but differential
voltage is 350 mV (or high voltage = 1.425 V, low voltage = 1.075 V).
So,  if during JTAG test the LVDS outputs will be the same as the Vcco
pins for that I/O bank (as I beleive too), it won't work ! Moreover I
wonder if doing the test after the configuration of the FPGA will change
someting or not... will the pin be driven with LVDS voltage levels then
? Does JTAG uses the drivers as configured by VHDL ?


>
> Warning: You are going to run into a problem if your LVDS signals are
> AC-coupled.  JTAG is inherently slow; I find that our JTAG clock is
> between 1 MHz and 5MHz maximum.  Consider that you have to shift in
> data for each pin of the FPGA every time you change the JTAG output
> pins, then you can only toggle the output pins at a frequency less
> than (1~5MHz / Pin Count).  I'm guessing 15 KHz maximum.
>

Yes, that's true, but it's not a problem for us. We're doing some kind
of interconnect test involving 3 boards. So signals are cathed by other
BS cells but not directly.



Gabriel



Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 26168
Subject: Re: Non-standard vhdl expressions
From: eml@riverside-machines.com.NOSPAM
Date: Fri, 06 Oct 2000 10:06:13 GMT
Links: << >>  << T >>  << A >>
On Thu, 5 Oct 2000 23:43:16 +0200, "Domagoj" <domagoj@engineer.com>
wrote:

>Hi there,
>    My university working group is just about to start designing vhdl 93/87
>simulator. We are not sure yet about the status ( freeware probably ).
>Our problem is that there are many cases found in praxis, that are not
>described in LRMs. Here are a few cases :
>1) different number ranges that some tools support
>2) library ieee;
>    use std_logic_1164.all;
>    Most of simulators support this behaviour.
>
>Could anyone share his/her experiences with these problems ?
>Please include a short explanation about the non-standard
>behaviour, and the tool name that supports it, if possible.
>
>Any comments would be highly appreciated.

Wrong newsgroup - try comp.lang.vhdl. What's Praxis? The LRM specifies
a minimum range for integers and reals, and you're free to increase
the range if you want. You'll probably want to increase the integer
range by at least 1, but this will probably lead to non-portable
behaviour. Std_logic isn't defined in the LRM because it's simply an
extra enumerated type, which users have agreed on. However, you will
need to put in acceleration for standard packages such as
std_logic_1164, numeric_std, VITAL, and so on.

You'll find that some simulators interpret bits of the LRM
differently, and you'll have to find out for yourself which bits they
are. A good place to start would be the documentation for the
'compatibility' flag on Cadence's Leapfrog, or possibly NC.

Good luck! You'll need it.

Evan 

Article: 26169
Subject: Re: Synopsys FPGA Compiler II on Solaris
From: Lars Rzymianowicz <larsrzy@ti.uni-mannheim.de>
Date: Fri, 06 Oct 2000 13:00:44 +0200
Links: << >>  << T >>  << A >>
Jörg Ritter wrote:
> I'm using the fc2 under solaris2.6 and 2.7 (SunOS 5.6 and 5.7).
> Do you get window decorations when using KDE as the window manager ?

No, the window frames don't appear on the screen. I have to start
FC2 under CDE to resize the windows. Seems a common problem for some
tools, the previous Primetime showed the same behavior, with the newest
version it's gone.
Do you have any bugfix for that?

Lars
-- 
Address:  University of Mannheim; B6, 26; 68159 Mannheim, Germany
Tel:      +(49) 621 181-2716, Fax: -2713
email:    larsrzy@{ti.uni-mannheim.de, atoll-net.de, computer.org}
Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/

Article: 26170
Subject: Re: Multiplication
From: Ray Andraka <ray@andraka.com>
Date: Fri, 06 Oct 2000 11:48:18 GMT
Links: << >>  << T >>  << A >>
No need for actual division, just implied division by a conceptual bit shift.
FOr example:

7*5 is
 	    0 1 1 1.
 	  x 0 1 0 1.
---------------------
	1 0 0 0 1 1.	

while 7/8 * 5/7 is
	    0.1 1 1
	  x 0.1 0 1
----------------------
	.1 0 0 0 1 1
and 7/8 * 5 is
	    0.1 1 1
	  x 0 1 0 1
--------------------
	1 0 0.0 1 1

So you see the bits are always the same.  What changes is our interpretation of
the bit weights.  In the logice then, if your weighting is always the same then
you handle it by aligning your inputs and outputs to the implied radix point.  





Vipan Kakkar wrote:
> 
> Dear Friends:
> 
> It is OK, but I think then for the radix point repositioning ( for
> multiplication with fractions) I need to do some division. If not then how can
> I do it? This thing is new for me. I need help in this.
> 
> Regards,
> 
> 
> Ray Andraka wrote:
> 
> > No hardware changes needed in the multiplier itself.  All you have to do is
> > change the interpretation of the position of the radix point.  It is
> > equivalent
> > to scaling your input and output by 32 in your case.
> >
> > Vipan Kakkar wrote:
> > >
> > > Dear Friends:
> > >
> > > I would like to know that how to multiply e.g. 1100 with 0.0011. I
> > > already have an array multplier to multiply e.g. 1100 with 0110. But,
> > > now I want to multiply fractions (i.e. .0011) using the same multiplier,
> > > so what modifications should I do in the existing multiplier.
> > >
> > > Regards
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com  or http://www.fpga-guru.com
> 
> --
> ____________________________________________________________________________
> Vipan Kakkar (Research Assistant), Circuits & Systems Group,
> Dept. of Electrical Engineering, Delft University of Technology,
> Mekelweg 4, 2628 CD DELFT. The Netherlands.            Tel: +31 62 8171782
> 
> 

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

Article: 26171
Subject: programm Xilinx FPGAs via JTAG
From: Marc Reinert <reinert@tu-harburg.de>
Date: Fri, 06 Oct 2000 15:36:42 +0200
Links: << >>  << T >>  << A >>
Hi

when I try to download my program on a FPGA (XC4003) via JTAG-port there
is no reaction of my hardware.

To test this function I'm using a demoboard (XC4000). My testprogram
asserts some LED on this board. It works fine when I download the
program with the Hardware Programmer (using D/P, DIN, CCLK, /PROG) - but
it doesn't work when I try to use the JTAG-Port (TDI, TDO, TCK, TMS).

What I did first is to start the JTAG-Programmer. Then I can see my
devices a the right *.bit is shown in that window. After that I select
"program". It seems to work but no LEDs are asserted.

My Log-File says:

"JTAG Programmer Started 2000/10/06 14:14:40
Loading Boundary-Scan Description Language (BSDL) file
'C:/Programme/Fndtn/xc4000e/data/xc4003e_pc84.bsd'.....completed
successfully.
Checking boundary-scan chain integrity...done.
Verifying device positions in boundary-scan chain...
Verification completed.
Boundary-scan chain validated successfully.
'light(Device1)': Checking boundary-scan chain integrity...done.
'light(Device1)': Reading bit-stream file...done.
'light(Device1)': Programming device...done.
'light(Device1)': Programming completed successfully."

I've selected all possibilities of the mode-settings but it didn't work.
What's wrong?

Marc


Article: 26172
Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response
From: Jamie Lokier <spamfilter.oct2000@tantalophile.demon.co.uk>
Date: 06 Oct 2000 15:50:56 +0200
Links: << >>  << T >>  << A >>
rickman  writes:
> One is the fact that there is a much smaller market for the end use of
> the tool. So development costs a lot more when spread over the smaller
> user base. Certainly customers are sensitive to tools costs. 

The market gets larger when one considers that an open source tool is
likely to target chip families from several vendors, eventually.

There are already open source tools for ASIC design and synthesis.  I'm
not sure how good they are, but they are commercial supported.

> Another is the fact that the target of the tools seem to change a lot
> more extensively and quickly than the CPUs that are the targets of SW
> development tools. This makes it hard and expensive for both the
> commercial and any potential freeware/open source tools to be kept up to
> date.

On the other hand, GCC has shown that when a tool is _designed_ for easy
retargetting, the users are quite likely to do it themselves or pay
someone they now to fine tune for a new target.

Of course the ideal is that FPGA vendors are involved in the
retargetting process because it helps them -- a good backend makes the
new FPGA look good.

> So even if the dollars were dropped as an issue, it is no small task to
> keep a toolset up to date with the new architectures in FPGAs. I for one
> would embrace open source tools if they work and can be used
> efficiently.

Would you pay for open source tools, if that payment led to the toolset
being kept up to date with the FPGAs you use, and working with your
preferred design approach?

>  Even though the vendors charge for their tools, that is not
> the real cost of using them. The big bucks are spent dealing with all
> the design "issues" that they create.

No kidding.  Not just the FPGA PAR tools either -- synthesis tools, oh
boy the Perl scripts I've had to write to modify netlists just to get
one tool compatible with another are, shall we say, an indication of how
disappointing "customer support" from the tool vendors can be.

> A constantly changing open source toolset would not have any less
> "issues" than commercial tools and may be worse.

An open source toolset would have to respond to customer requirements to
survive just like the commercial ones do (eventually).  As you say, it's
not $$$ at the end of the day, at least for the professional users.

In the end what seems to count is having a good, dedicated support team
who are able to respond to those "issues" and have the skill to fix
them.

That's the same as commercial offerings.  However, open source does
change the nature of the competition, so that if the support team aren't
up to the job, anyone else interested can join in.  Don't have the
skills?  Read the source and _learn_ the skills directly.

> One last note; the chip vendors are not really interested in open source
> tools since they feel that they will have to "support" any and all tools
> that are used to program their parts. I know that Peter Alfke from
> Xilinx has stated on more than one occasion that Xilinx would want to
> support customers regardless of how they were generating the bitstream.
> In theory they are a hardware company and will have to provide this
> support to sell chips. Open source tools would be a can of worms for
> them if they really adopt this approach. 

How is this worse with open source?  Now, if the users are randomly
hacking the "Xilinx backend" of "GNU fpgatool", they'll be getting
unusual designs out which will stretch FPGA vendors.

This is a good thing, because the FPGAs are seeing applications and
design techniques they weren't seeing before.

The issue of dangerously erroneous bitstreams isn't an issue, because a
properly written tool has a fairly small, indepdendent component to
check the bitstream to make sure it doesn't cause contention.  Customers
have no need to change _that_ part.  As for customers who are depending
on potentially buggy timing information... well again, put the toolset
together properly so there's a Xilinx-supplied "give you the timing from
low level files" tool, which can always be run no matter what cunning
changes customers are applying to their local toolchain.

Not really a can of worms if you put together the tools with keeping
down the cost of customer support in mind.

More than likely, the homebrew level of tools _will_ be a problem for
Xilinx et al. if they insist on supporting those users, because those
tools will be buggy, poorly documented, based on incorrect documentation
from FPGA vendors and guesses from reverse engineering etc.

On the other hand, professionally assembled open source with support
from the beginning from the FPGA vendors naturally has "keep down the
cost of customer support" right in there as a design goal.  That means
making the tool a good one, robust in the face of internal bugs, and
with top quality diagnostics.

> Personally I think that open source tools could be a major boon to the
> FPGA community. Especially if it fosters innovation in how the tools
> work and the user interfaces.

Exactly.

> I think that tool and FPGA vendors have a large interest in reducing
> "support" which often means catering to the lowest common
> denominator. The results are tools that "get in the way" in many
> respects in order to offer a minimal learning curve to beginners. Not
> that this is bad. But I would like to see what happens if tools are
> developed by the tool users rather than the tool sellers.

I think there is ample room for tool sellers to coexist in open source
with the FPGA vendors and users.  Most users don't want to write tools
(though they might like to make local changes).  FPGA vendors want to
know the tool is well supported and professionally put together, but
they want the economic burden of pleasing users due to tool issues to be
someone else's problem.

So there's a role for the tool supplier.  What's missing at the moment
is simply the lack of responsiveness by tool suppliers to users
individual demands and the users' own creative input -- and that means
lack of innovation in new designs.  Not to mention fewer FPGAs sold.

> Too bad that FPGA designers are not the same community as the software
> developers. Carpenters make tools out of wood. Machinists make tools out
> of metal. Software developers make tools out of software. What tools do
> hardware designers make?

First, people who program FPGAs are increasingly not hardware designers
at all.  They're parallel digital logic designers.

How many people have you seen in this newsgroup discussing things like
FIR filters etc., yet who (possibly) wouldn't know where to put
termination resistors on the board?

Second, there are hardware designers who can write compilers (software
and hardware) and even GUIs.  I'm one of them and I know I'm far from
the only one.  Anyone wants to fund open source FPGA tools, you know
where to find me and we can put together a team..

Third, Zoltan Kocsi wrote:
> The problem I see is that logic synthesis is a rather hard nut. Not
> many people know the intricate details of optimally mapping logic
> onto arbitrary cell structures. I don't know books on synthesis like 
> the Dragon Book on compiling. This severely limits the developer base.

The Dragon Book is a bit dated for software compilers now too.
Nevertheless, many techniques that apply to software also apply to
hardware compilation, though particularly synthesis.  The obvious stuff
like eliminating unused logic, combining shared expressions,
propositional logic and table-driven logic to reduce logic expressions
etc.  Dataflow analysis is surprisingly similar, though the control
flow/data flow relationships are obviously a little different.

More modern software compilation techniques are in some ways more
applicable, because there is more and more emphasic on flow graphs and
data relation graphs than before.  (E.g. GVN on an SSA form (software
compiler jargon) is a form of assembling a data relation graph).  These
techniques also apply, with a little sleight of hand, to hardware
synthesis.

That leaves the well known hard nuts of synthesising for an
architecture's logic blocks, and fitting the whole thing.  You're right,
there's not a wealth of applicable literature.  However, if you look at
ASIC world, then you will even find a fair amount of free software
oriented in that direction.

What I'm saying is that the leap from one to another is not as great as
you'd imagine, particular with more modern techniques, and particularly
for the larger FPGA applications.  (Those "system on a chip" things).

Besides, good fitting, and fitting fast for dynamic designs, really
_are_ hard nuts and to some extent, isn't it in the FPGA vendors
interests to have pooled public research & development into these
difficult problem?

> In addition, the target audience is a much smaller lot than for 
> software tools or general purpose programs.

There's a vicious circle here.  Not many program FPGAs in comparison to
say assembly language or C on microprocessors.  But then, not many PC
video cards use an FPGA to implement the 3d rendering algorithms...  Not
many high-speed network cards really use that FPGA to help the
computer's applications.  Not many supercomputer clusters are built from
FPGAs.

If the tools were available, then those sort of applications might
become economic on FPGAs.  There's no doubt in my mind that a cluster of
high-speed FPGAs can out-compute a cluster of Pentium 4s for some
problems.  For one thing FPGAs are excellent communicators.  Especially
when FPGA compiler technology catches up with CPU compiler technology.

Now that they're getting affordable, large, and not too power hungry,
FPGAs are approaching the stage where they can seriously be applied to
real computer problems like number crunching and dynamic web serving.
(Compress video to match subscribers bandwidth and serve up, anyone?).

But it's too hard to program them for anyone but hardware designers.
Not least because to _learn_ to be a hardware designer requires time
with tools that normal CS students will never see, and would never want
to.

Ok, this is a different topic from the open source one.  But I do
believe that until there are good open source FPGA programming solutions
around, FPGAs aren't going to be used to their full potential as
powerful processing devices.

My 2p..
-- Jamie

Article: 26173
Subject: Project Leader, Architecture Modeling
From: brian13074@my-deja.com
Date: Fri, 06 Oct 2000 15:06:02 GMT
Links: << >>  << T >>  << A >>
(Project Leader, Architecture Modeling)

I'm a headhunter who specializes in Engineering,
ASIC, ATM and related fields.

I currently have opportunities available for ASIC Design Engineer
professionals with a dynamic company.

Details for these positions are pasted below.  In addition to these
specific positions, I have several others which require related skills
and experience.

Do you know of anyone who would be a good candidate for these
positions?  Please ask them to contact me immediately.

Thanks very much.

Brian Mason
GateSource Partners
brian@gatesource.com
703-502-8461
www.gatesource.com


Title include:

*Project Leader, Architecture Modeling

*ASIC Architect, Network Processor

*ASIC Design Manager

*Senior Circuit Design and Analysis Engineer

*Senior Applications Engineer

Title: Project Leader, Architecture Modeling
Location:  Northern Virginia
Compensation:  Competitive

Responsibilities:

*To provide hands-on project leadership in development and maintenance
of simulation models for high performance embedded network processors
for communications applications.

Qualifications
Requires 4 years of experience in micro-architecture modeling using
C/C++ or a high level hardware design language
Experience with cycle accurate simulation modeling
Experience with software engineering tools for managing large-scale
software projects

Additional Qualifications
Knowledge of  communication protocols
Experience with mixed-level  C/RTL simulation on a RTL simulator
Knowledge of Verilog/VHDL.

Title: ASIC Architect, Network Processor

Responsibilities:
* To develop ASIC architectures for high performance network processors.
To provide ASIC architecture specifications to an ASIC implementation
team.

Qualifications:
Requires 4 years of experience in ASIC and semi-custom
micro-architecture development for submicron CMOS implementation
Experience with pipelined and superscalar processor architectures
Experience with hierarchical memory design using on-chip and off-chip
memory technologies
Experience with architectures in submicron CMOS operating above 100 mhz

Additional Qualifications
Hands-on experience with architecture modeling in C/C++
Hands-on experience with high performance logic design using
Verilog/VHDL
Knowledge of communication protocols


Title: ASIC Design Manager

Responsibilities:
To provide hands-on leadership to communication ASIC implementation
projects.

Qualifications
Requires 5 years of experience with ASIC design and implementation using
logic synthesis, static timing analysis, equivalence checking, DFT tools
and project management tools
Experience with ASIC design and implementation using CMOS at .25micron
and below, with operating speed at 100 mhz and above
Experience with ASIC design and implementation using on-chip and
off-chip memory technologies
Experience with interfacing to physical design tools for placement and
routing   and achieving post-layout timing closure,
Experience with interfacing with manufacturing teams for test
development and package design
Demonstrated managerial and leadership skills

Additional Qualifications
Direct experience in communications ASICs projects highly desirable
Knowledge of communications protocols highly desirable
Familiarity with top-down design and verification methodology using
cycle-accurate high level simulation models and mixed-level simulation
on RTL simulators


Title: Senior Circuit Design and Analysis Engineer

Responsibilities:
To validate electrical and timing characteristics of an ASIC according
to its specifications

Qualifications
Experience with circuit analysis and simulation in .25 micron and
beyond, using 2D/3D physical extraction tools and Hspice
Experience with design and analysis of I/O pad rings in .25micron CMOS
and beyond, slew rate analysis, noise analysis, power consumption
analysis
Experience with critical path analysis and crosstalk analysis in .25
micron CMOS and beyond

Additional Qualifications
Experience providing guidelines and constraints to the physical design
process
Experience with phase-locked loop designs and analysis
Experience with  high speed SRAM designs and analysis
Experience with signaling techniques such as LVDS

Title: Senior Applications Engineer

Responsibilities:
To design communication boards for router/switch applications based on
the company's communication ASICs and embedded software packages

Qualifications
Hands-on experience with designing and debugging communication boards
for router/switch applications and communications protocols
Experience with embedded real-time software packages in communications
applications
Experience with system interfaces to framers and switch fabrics
Proven professional and interpersonal communication skills

Additional Qualifications
FPGA design using Verilog/VHDL and logic synthesis
Experience with high speed board design for high performance memory
subsystems


My client US headquarters is in Northern Virginia.
Company profile is pasted below.

Thanks.

Brian

Brian Mason
GateSource Partners
brian@gatesource.com
703-502-8461
www.gatesource.com

My client is a privately held company, specializes in the design and
manufacturing of
high-performance CMOS Application Specific Integrated Circuits (ASIC)
for data communication
 network equipments.  The company chip sets target ATM, Frame Relay and
IP applications in
 the area of access devices, multiservice platforms, network interface
cards, and edge/core
switches and routers with gigabit bandwidth requirements.

 Their innovative chip set solutions are based on proprietary and
patented technologies developed over the last decade by the key founding
members, including real-time multithread processing, hierarchical
traffic scheduling and shaping, and high-performance low-power circuit
design techniques, serving as a basis for  Acorn Networks' baseline
communications processor architecture for OC-48c wirespeed operation,
and readily scalable to OC-192c and beyond.


The company has been funded by the DoD since August 1995 to develop
advanced chip sets for ATM Segmentation and Reassembly at 2.5 Gbps and
10 Gbps.  My client has also developed
proof-of-concept prototypes using its own proprietary chip sets for
high-end video transport over the WAN.  In the first quarter of 2000,
they raised its first round from MCI Worldcom Venture Fund, TechFarm,
Chase Capital Partners and Capitol Ventures.


Please email your resume immediately to:

Brian Mason
GateSource Partners
brian@gatesource.com
703-502-8461


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 26174
Subject: Re: programm Xilinx FPGAs via JTAG
From: Nicolas Matringe <nicolas.matringe@IPricot.com>
Date: Fri, 06 Oct 2000 17:20:49 +0200
Links: << >>  << T >>  << A >>
Marc Reinert a écrit :
> 
> Hi
> 
> when I try to download my program on a FPGA (XC4003) via JTAG-port
> there is no reaction of my hardware.
> 
> To test this function I'm using a demoboard (XC4000). My testprogram
> asserts some LED on this board. It works fine when I download the
> program with the Hardware Programmer (using D/P, DIN, CCLK, /PROG) -
> but it doesn't work when I try to use the JTAG-Port (TDI, TDO, TCK,
> TMS).

Hi
Are you using the same .bit file in both cases?
I had a similar problem with a Virtex some time ago: I had to use the
JTAG clock as the Startup Clock (run bitgen with the -g
startupclock=jtagclock option) or it wouldn't work.
I don't know if it's the same with XC4000 parts

-- 
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    16 rue du Moulin des Bruyeres
Tel +33 1 46 67 51 11      F-92400 COURBEVOIE - FRANCE
Fax +33 1 46 67 51 01      http://www.IPricot.com/



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
2017JanFebMarApr2017

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