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 2700

Article: 2700
Subject: Re: How Big Chips Will Be Designed In The Not Too Distant Future
From: verschue@eb.ele.tue.nl (Ad Verschueren)
Date: 25 Jan 1996 11:28:43 GMT
Links: << >>  << T >>  << A >>
In article <4e0f88$b25@agate.berkeley.edu>,
Steve Pope <spp@bob.EECS.Berkeley.EDU> wrote:
>Brian Childs <brian@vizef.demon.co.uk> writes:
>
>> I also agree with this trend. In fact it is already here... You only
>> have to look at the companies who used to (and probably still do)
>> provide custom design services, who now publish/market an extensive
>> range of 'off the shelf cores'. 
>
>This is because whenever a design shop designs a chip for one
>customer, its elements then become potential "off the shelf cores" for
>the next customer.    Problem is, the actual level of circuit
>re-use is always lower than one hopes.   Rule of thumb -- if you
>can get by with less than half of a design being newly-designed
>circuitry, you're doing really well.

In my experience, the amount of curcuit re-use increases tremendously when
you are allowed to make (small) modifications to a previous design - and
I don't mean setting a few parameters differently here... We do have large
groups of students working and learning here using our own tools, and they
are copying and pasting all over the place. Everything they made over the
last couple of years is placed in a central depository, we do not allow
anything in there which is not thoroughly documented (both on paper and
within the designs themselves). Not only complete designs are open for
re-use, but also any sub-part of a design can be copied in separation.
>
>If the design shop is accumulating large numbers of "off the shelf
>cores" it's a good bet they are desinging these things anew for each
>customer and that is why they have so many of them.

I think design shops should worry more about building cores which are
robust enough to be modified by their customers than to create 'new'
cores on request (which stop working as soon as a slight modification
has been made).
>
>> What appears to be missing is any good
>> design tools to assist designers (or do you know different). 
>
>We've been saying this for the last 15 years. :)

Going to whisper mode: take a look at our tools... Check out
http://www.eb.ele.tue.nl/proj/idassfly.html
...fully interactive designing and simulating within a graphical
environment - capable of handling very complex designs, VHDL output
and automatically generated test environments available (as of today :-).
If you want to play around with it, drop me an e-mail...
Ending whisper mode, sorry for the advertisement, just couldn't resist :-(
>
>Steve

Ad Verschueren

--(dr.ir.) Ad (A.C.) Verschueren-----------------------VERSCHUE@EB.ELE.TUE.NL--
  Eindhoven University of Technology   Digital Information Processing Systems
  Smail: Room EH 10.26 ---- P.O. Box 513 ---- 5600 MB  Eindhoven, Netherlands
  Voice: +31-40-2473404  FAX: +31-40-2448375  [corner for rent, apply within]

-- 
--(dr.ir.) Ad (A.C.) Verschueren-----------------------VERSCHUE@EB.ELE.TUE.NL--
  Eindhoven University of Technology   Digital Information Processing Systems
  Smail: Room EH 10.26 ---- P.O. Box 513 ---- 5600 MB  Eindhoven, Netherlands
  Voice: +31-40-2473404  FAX: +31-40-2448375  [corner for rent, apply within]


Article: 2701
Subject: Re: How Big Chips Will Be Designed In The Not Too Distant Future
From: spp@bob.EECS.Berkeley.EDU (Steve Pope)
Date: 25 Jan 1996 17:24:51 GMT
Links: << >>  << T >>  << A >>
verschue@eb.ele.tue.nl (Ad Verschueren) replise to my post,

>>This is because whenever a design shop designs a chip for one
>>customer, its elements then become potential "off the shelf cores" for
>>the next customer.    Problem is, the actual level of circuit
>>re-use is always lower than one hopes.   Rule of thumb -- if you
>>can get by with less than half of a design being newly-designed
>>circuitry, you're doing really well.

| In my experience, the amount of curcuit re-use increases
| tremendously when you are allowed to make (small) modifications
| to a previous design - and I don't mean setting a few parameters
| differently here... We do have large groups of students working
| and learning here using our own tools, and they are copying and
| pasting all over the place. Everything they made over the last
| couple of years is placed in a central depository, we do not
| allow anything in there which is not thoroughly documented (both
| on paper and within the designs themselves). Not only complete
| designs are open for re-use, but also any sub-part of a design
| can be copied in separation.

I agree that you are describing techniques that serve to increase
re-use.   But I'll stand by my estimate that anything better than
50% re-use -- for REQUIREMENTS DRIVEN projects -- is really
pretty good, even with the techniques you mention.

Of course, for RESOURCE DRIVEN projects, you will get more re-use
more readily.  (e.g., "What cores do I already have, and what
can I design with them" -- i.e. a typical university situation.)

Steve


Article: 2702
Subject: Re: HowTo access a SRAM with a XC4000
From: peter@xilinx.com (Peter Alfke)
Date: 25 Jan 1996 19:32:11 GMT
Links: << >>  << T >>  << A >>
In article <4e7lbm$idl@news.alcatel.ch>, Peter Siegrist <sigi> wrote:

> Ja es ist moeglich
> Ich steuere mit meine 4010 exteren SRAM 25ns, DUAL_Port_RAM 25ns
> und die Interen RAM's ca.20ns
>
Ja, es ist jetzt sogar noch viel besser geworden:

The new XC4000E family has synchronous and dual-port RAM. You can treat
the RAM block as if it were a register. Address, Data, and Write
Strobe=Write Enable only have to meet the set-up time before the global
clock edge. No more need for careful timing to make sure that WS starts
and ends during valid address times.
Try it, you'll like it.

Peter Alfke, Xilinx Applications, San Jose, CA


Article: 2703
Subject: Re: XILINX XACT 6.0.0 Tools flaky
From: ecla@world.std.com (alain arnaud)
Date: Thu, 25 Jan 1996 20:09:18 GMT
Links: << >>  << T >>  << A >>
Gavin Melville (gavin@cypher.co.nz) wrote:
: Hi All,

: I am using the windows based XACT (step) tools, and have found them to
: be a little "flaky", with occasional lockups and crashes -- in
: particular the Design Editor (V5.2.0).   This version has run fine
: from DOS, but the need for simulation has forced me to use the Windows
: tools.   One particular problem -- XDE doesn't always seem to generate
: the same bitstream each time DebugLoad is run.

	[etc deleted]

I have beenusing XACT 6.0 since June 95. I have installed them on more than
ten machine from a  486-33  with 20Mb RAM to Pntium-133 with 64 MB. 
I have seen a net productivity gain of at least 2x from start to finish.
Yes, sometimes  the tool will crash but in over 7 months of usage not 
any more than  any other windows applications. I have found that more 
crashes is an indication (most times) of an unreliable windows installation 
or flaky hardware, both of which have nothing to do with XACT. 

You definitely get a bit more performance by using WFW.

Email me if you need help on XACT 6.0

Alan Arnaud (arnaud@ecla.com)

ECLA Inc. -Networking ASICS and FPGAs designs- 
1-800-928-1236
Newton, MA


Article: 2704
Subject: Put an 8051 in your ASIC
From: icdcbob@netcom.com (Robert F. Calderwood)
Date: Thu, 25 Jan 1996 20:37:58 GMT
Links: << >>  << T >>  << A >>
We are offering a gate-level description of the popular 8051-type
microcontroller suitable for use with most ASIC manufacturers (FPGA,
gate array, or standard-cell). Licenses are available starting at
US$2995 for a single ASIC type at a single foundry. More detalis can
be obtained by anonymous ftp to ftp.netcom.com in the directory
/ftp/pub/ic/icdc in the file nld.txt or via the Web at 
ftp://ftp.netcom.com/pub/ic/icdc/nld.txt
or reply to this post.

__________________________________________________________________________
 _   ____      __  ____    ____
| | |  __|    / / |  _ \  |  __|    Integrated Circuit Design Concepts
| | | |      / /  | | | | | |      12502 Carmel Way, Santa Ana CA 92705
| | | |__   / /   | |_| | | |__   Voice (714) 633-0455 Fax (714) 838-7705
|_| |____| /_/    |____/  |____|
_________________________________________________________________________
-- 
__________________________________________________________________________
 _   ____      __  ____    ____
| | |  __|    / / |  _ \  |  __|    Integrated Circuit Design Concepts
| | | |      / /  | | | | | |      12502 Carmel Way, Santa Ana CA 92705
| | | |__   / /   | |_| | | |__   Voice (714) 633-0455 Fax (714) 838-7705
|_| |____| /_/    |____/  |____|
_________________________________________________________________________


Article: 2705
Subject: ** ASIC Designers Wanted For Next Week's Great ESDA Shootout **
From: jcooley@world.std.com (John Cooley)
Date: Fri, 26 Jan 1996 07:23:18 GMT
Links: << >>  << T >>  << A >>
   Next week at the HP Design SuperCon '96 I'll be running an ESDA Shootout
on Tuesday afternoon.   (Our goal is to determine whether the ESDA tools
like those sold by i-Logix, Summit, and Speed can do better or worst than
everyday engineers designing ASIC's using plain old "vi" or EMACS.)  Given
90 minutes, ASIC designers will be asked to hand code a small state machine
and then to synthesize it to gates.  The ESDA Vendors will be sweating it out
creating the *same* design using *their own* ESDA tools!

   The top hand-coding ASIC designers who produce the fastest running
gate-level designs will win instant fame (in the write-up of the contest)
with the best winning an HP color laser printer!  Since we don't have an
infinite number of workstations available, if you're interested in being a
part of this contest *please* e-mail me *TODAY* at "jcooley@world.std.com"
so we can get an estimated head count.

   NAME:_________________________   Phone Number:____________________
   e-mail address:___________________________________________________
   Prefered HDL (Verilog or VHDL):___________________________________

  Oh, don't forget to come to the panel discussion the next day (Wednesday,
Jan. 31st) to see the ESDA vendors either gloat on their victories or squirm
trying to explain why their tools couldn't cut it.  Or, if things go awry,
you could find the contest judge (me) sweating it out trying to explain why
things got screwed up!  :^)
                              - John Cooley
                                Part Time EDA Consumer Advocate
                                Full Time ASIC, FPGA & EDA Design Consultant

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 3881 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."


Article: 2706
Subject: Re: HowTo access a SRAM with a XC4000
From: pwu@maz-hh.de (Peter Wurbs)
Date: Fri, 26 Jan 1996 07:46:43 GMT
Links: << >>  << T >>  << A >>
Philipp,

I have realized a design in XC4013-4, running at 20MHz, that reads
and writes a SRAM at full speed.
It is my experience, that there are no problems.
Use the registered Pads (INFF, OUTFF) to get well defined timings.
Even registerd I/O-Ports can be built.
If you need access at full speed, you need a WE-Signal, that is the
gated system clock. Be carefully generating this signal.
Additionally I realized an arbiter for the RAM access, so that several
blocks within the FPGA can access the SRAM.

Bye,

Peter.

---------------------------------------------------------
Peter Wurbs (MAZ Hamburg GmbH, Dep. Broadband Communication)
Phone:  ++40-76629 1771
Fax:    ++40-76629 199
e-Mail: pwu@maz-hh.de
---------------------------------------------------------



Article: 2707
Subject: Re: HowTo access a SRAM with a XC4000
From: jsgray@ix.netcom.com(Jan Gray)
Date: 26 Jan 1996 08:31:41 GMT
Links: << >>  << T >>  << A >>
In <4e68e6$9c1@mailman.xilinx> "Steve Knapp (Xilinx, Inc.)" <stevek>
writes: 
>
>The concept seems feasible.  A few questions though:
>
>1.  How much RAM is required?  General the XC4000E RAM is good for
designs
>    requiring less than 64 words of memory.  Increasing the word width
does not
>    significantly increase the amount memory required.
>
>    Some example sizes:  A 32-deep memory of 16-bit words consumes 32
XC4000E
>    logic blocks.  A 64-deep memory of 16-bit words consumes 80 logic
blocks
>    (64 for the RAM, and 16 for bank select and output multiplexing).

Quite true, but sometimes you can take advantage of the 4000(E)'s
abundant 3state drivers to have deep (multi-bank) memories w/o having
to waste CLB gates multiplexing bank data outputs.  Assuming you are
already using horizontal long lines for an on-chip data bus of some
kind, multiplexing bank outputs is as simple as decoding more
significant address lines into bank enable signals which enable tbufs
to drive bank data outputs onto the shared data bus.  Fortunately, the
tbuf inputs are immediately adjacent to the SRAM/ROM CLBs so trivial
routing resources are consumed.  Floorplan-wise, the data bus runs
horizontally, each SRAM/ROM bank is a column of CLBs and TBUFs, with
addresses, WE, and bank select longlines running vertically.

For instance, my 4010-based 32-bit RISC has several banks of 16 words x
32-bits of on-chip boot ROM.  Address bits A[7:6] control bank output
enables, A[5:2] specify the word address across all banks, and A[1:0]
is decoded with the processor's data-width specifier (byte, halfword,
word) to derive byte enables.  The bank output enables and byte enables
are and'd together and each result drives 8 "data out" tbufs for some
byte in some bank.

Jan Gray
Redmond, WA


Article: 2708
Subject: Xilinx MC68681 Emulation
From: msaundrs@dtwc.com (Mike Saunders)
Date: Fri, 26 Jan 1996 15:53:29 GMT
Links: << >>  << T >>  << A >>
I am looking for a design library for a software UART for the Xilinx
xc4000 series.  I would really like to have something that would be
very similar to the Motorola 68681 Duart.  Does anyone know of a
company that may be producing this kind of library.  We would not
prefer to recreate the wheel if at all possible.  Thanks in advance.

-- Mike Saunders
Datron World Communications



Article: 2709
Subject: VHDL/Verilog training
From: tdb@icf.hrb.com (T. D. Bouvia)
Date: 26 Jan 96 13:27:27 EST
Links: << >>  << T >>  << A >>

I am requesting any and all feedback regarding in-house training of 
VHDL/Verilog.  This could be tutorials, seminars, video tapes, etc...

I am looking for prices, quality assessments, contacts, etc...

Also, any comments from individuals who have received this type of training
from a professional training service would be appreciated.

-- 

 \\\\\\\\\ \\\\\\\    \\\\\\    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    \\      \\   \\    \\  \\   ^  Timothy D. Bouvia             ^
   \\      \\    \\   \\\\\\    ^  HRB Systems, Inc., Dept. 112  ^  
  \\      \\    \\   \\   \\    ^  State College, Pa. 16804-0060 ^
 \\     \\\\\\\\   \\\\\\\\     ^  Internet: tdb@icf.hrb.com     ^
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Article: 2710
Subject: Re: How Big Chips Will Be Designed In The Not Too Distant Future
From: Steven Bird <steve@vizef.demon.co.uk>
Date: Sat, 27 Jan 1996 17:06:53 +0000
Links: << >>  << T >>  << A >>
In article <4e8ed3$boc@agate.berkeley.edu>, Steve Pope
<spp@bob.EECS.Berkeley.EDU> writes
>verschue@eb.ele.tue.nl (Ad Verschueren) replise to my post,
>
>>>This is because whenever a design shop designs a chip for one
>>>customer, its elements then become potential "off the shelf cores" for
>>>the next customer.    Problem is, the actual level of circuit
>>>re-use is always lower than one hopes.   Rule of thumb -- if you
>>>can get by with less than half of a design being newly-designed
>>>circuitry, you're doing really well.
>
>| In my experience, the amount of curcuit re-use increases
>| tremendously when you are allowed to make (small) modifications
>| to a previous design - and I don't mean setting a few parameters
>| differently here... We do have large groups of students working
>| and learning here using our own tools, and they are copying and
>| pasting all over the place. Everything they made over the last
>| couple of years is placed in a central depository, we do not
>| allow anything in there which is not thoroughly documented (both
>| on paper and within the designs themselves). Not only complete
>| designs are open for re-use, but also any sub-part of a design
>| can be copied in separation.
>
>I agree that you are describing techniques that serve to increase
>re-use.   But I'll stand by my estimate that anything better than
>50% re-use -- for REQUIREMENTS DRIVEN projects -- is really
>pretty good, even with the techniques you mention.
>
>Of course, for RESOURCE DRIVEN projects, you will get more re-use
>more readily.  (e.g., "What cores do I already have, and what
>can I design with them" -- i.e. a typical university situation.)
>
>Steve

I seen this 50% trend too. The only time I've seen significant re-use is
on designs which are evolutionary rather than revolutionary. In fact
most ASIC's tend to be evolutionary i.e. taking an existing design on to
new heights. Where re-use tends to fall off is when the next design
iteration is carried out by a new team and then a touch of NIH sets in.
Not 'Not Invented Here' *but* 'No Information Here'. If the design is
not documented adiquately and the designer cannot quickly understand how
a module is implemented there is the tendency to start again. This is
not new, software engineering has had this problem for decades. The
'mistake' I feel is in the original promotion of HDL's, by the EDA
companies, as enabling technology for design re-use. This is like saying
C++ enables design re-use because it is different to C. It is good
design practises that are needed which will create an environment that
fosters design re-use. Re-use of poorly document design modules leaves a
real risk of misunderstanding and subsiquent delays to schedules. This
is something seasoned engineers are all to aware of and tend to avoid
the re-use option where the risk is tangable. 


-- 
Steven Bird


Article: 2711
Subject: Re: VHDL/Verilog training
From: guerino1@ix.netcom.com(Frank Guerino )
Date: 27 Jan 1996 20:38:14 GMT
Links: << >>  << T >>  << A >>


In <1996Jan26.132727.24274@hrbicf> tdb@icf.hrb.com (T. D. Bouvia)
writes: 
>
>
>I am requesting any and all feedback regarding in-house training of 
>VHDL/Verilog.  This could be tutorials, seminars, video tapes, etc...
>
>I am looking for prices, quality assessments, contacts, etc...
>
>Also, any comments from individuals who have received this type of
training
>from a professional training service would be appreciated.
>

You can get excellent training for VHDL through IKOS systems.
They have relationships with consulting companies that spec-
ialize in VHDL training.  IKOS themselves gives excellent
simulation/co-simulation trainging also.  One of the consul-
ting services companies they deal with is "Top Down Design".

A contact at IKOS is their sales person in your area.  His
name is Mike Kochanik. (201) 445-7001 ext 202.  His email is
"mikek@ikos.com"

I've been through this VHDL training program and it's very
good.

FG


Article: 2712
Subject: Re: Chosing VHDL or Verilog Does Have An Impact For U.S. Engineers
From: guerino1@ix.netcom.com(Frank Guerino )
Date: 27 Jan 1996 20:58:28 GMT
Links: << >>  << T >>  << A >>
In <DLKnL8.LJ9@world.std.com> jcooley@world.std.com (John Cooley)
writes: 
>
>Tony Goodloe <tgoodloe@adtran.com> wrote:
>>Verilog vs. VHDL - IT DOESN'T MATTER! People have shipped products 
>>and made money using each. Learn one. Don't fret about the decision.
>>The hard part is understanding what HDLs are all about in general. 
>>Once you learn one, the other will come.
>
>Sorry, Tony, but I have to disagree with you on this one here.  Unlike
Europe
>or in Japan, U.S. engineers are basically hired by the buzzwords they
have
>on their resume *and* how well the engineers know them.  Most U.S.
companies
>don't like to train if they can get a person with the right buzzwords
in the
>first place.  In light of the last 10 years, most U.S. workers know
they're
>disposable at any moment -- so it pays to keep your career such that
the 
>right buzzwords are on your resume at all times.
>

Hogwash!  People are hired on ability in this industry.  And
what matters is not which HDL you know but if you understand
how to implement the entire methodology/process to get a chip
from specification - through synthesis - through verification
- and through signoff.  If you can do this you will be valu-
able to any and all companies that design chips.  It is im-
portant to understand differences between VHDL and Verilog,
but that's not what will keep you employed in this industry...

FG


Article: 2713
Subject: Re: Chosing VHDL or Verilog Does Have An Impact For U.S. Engineers
From: jcooley@world.std.com (John Cooley)
Date: Sun, 28 Jan 1996 16:36:19 GMT
Links: << >>  << T >>  << A >>
jcooley@world.std.com (John Cooley) writes: 
>Sorry, Tony, but I have to disagree with you on this one here.  Unlike
>Europe or in Japan, U.S. engineers are basically hired by the 
>buzzwords they have on their resume *and* how well the engineers 
>know them.  Most U.S. companies don't like to train if they can 
>get a person with the right buzzwords in the first place.  In light 
>of the last 10 years, most U.S. workers know they're disposable at 
>any moment -- so it pays to keep your career such that the right 
>buzzwords are on your resume at all times.

Frank Guerino  <guerino1@ix.netcom.com> wrote:
>Hogwash!  People are hired on ability in this industry.  And
>what matters is not which HDL you know but if you understand
>how to implement the entire methodology/process to get a chip
>from specification - through synthesis - through verification
>- and through signoff.  If you can do this you will be valu-
>able to any and all companies that design chips.  It is im-
>portant to understand differences between VHDL and Verilog,
>but that's not what will keep you employed in this industry...
>
>FG

Frank, I think you're missing my point that this "ability" usually is
measured by how well one knows buzzwords like "Synopsys", "MOTIVE",
"DFT", "DSP", "Verilog" -- you've never had a headhunter call you up
asking if you know buzzword "XYZ"?  You've never known engineers who
were hot career-wise because they knew these buzzwords or others who
weren't doing so well because they didn't have the right buzzwords?
(I've known plenty of DoD engineers who knew chip design but who have
had bad times getting a new job because it wasn't with the commercial
EDA tools the rest of industry uses.)  If you're one of the three 
Americans working in a company that will guarentee your job as long
as the company lives, great.  Unfortunetly, most the rest of us
remaining 250 million Americans *have* to constantly keep our 
*marketable* skills contuniously up to date *because* we don't know 
what the future brings.  That is, if the company needs you to develope
firmware using their own funky proprietary software versus using
industry wide tools to design a new ASIC, it would be damn wise to
take the industry wide tools job!  When I was at Data General I used
to know experts in their propietary OS called "AOS" -- when they
downsized the UNIX jocks got jobs & career advances in a heartbeat.
The "AOS" wizards (who had exact same skills in the wrong brand name
("AOS" versus "UNIX")) had one hell of a time finding work!

Also, Frank, don't confuse the fact that right now engineers are 
hired pretty much because they're what's available right now due 
to the current 6 month shortage of them.  Once the glut comes back,
it'll be disposable employee as usual.

                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 3713 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."


Article: 2714
Subject: GAL programming for hobby use...Is there no hope?
From: mark.stephens@gsfc.nasa.gov (Mark Stephens)
Date: Mon, 29 Jan 1996 10:09:19 -0500
Links: << >>  << T >>  << A >>
I'd really, really like to get rid of the NOR gate glue logic and replace
it with some species of GAL.  I have PLDasm and it's manual and can now
create the JDEC files.  Unfortunately, my PROM programmer is just that...
PROMs only.  

Do I need to get another programmer or can one home brew for a specific chip?

thanks!

mark

-- 
mark stephens                                    "In constraint,
NASA GSFC Code 521                                is freedom"
Greenbelt, MD
(301) 286-4269         mark.stephens@gsfc.nasa.gov


Article: 2715
Subject: Re: AT&T Orca vs Xilinx
From: husby@fnal.gov (Don Husby)
Date: 29 Jan 1996 15:22:01 GMT
Links: << >>  << T >>  << A >>
kurt@emphasys.de wrote:
>
>Hi,
>has anyone expirience with AT&T ORCA FPGAs ?
>For some designs we think about switching from Xilinx to ORCA.
>Thanks in advance for any information and comparison of the tools.
>Kurt.

I've been using ORCA for about a year now, and have rarely been tempted to
go back to Xilinx.  The parts seem to be better optimized for the types of 
circuits that I'm doing.  They especially excel at things that require:

1) Wide internal tri-state busses.
   The ORCA has 8 TBUFs per PFU which can drive horizontally or vertically.
   The 4000 has 2 per CLB on horizontal lines only.  (This is equivalent of 4
   per PFU assuming that 1 PFU is roughly equivalent to 2 CLB.) 

2) Large arithmetic functions.  Each PFU can be a 4-bit adder/subtractor.

3) Multi-way multiplexers.  Each PFU has a multiplexed data input to its
   flip-flops.  This allows, for example, a 4-bit loadable up/down counter to 
   be implemented in only a single PFU.  Also, it allows a 4-bit wide 3-to-1
   multiplexer to be implemented in a single PFU.  I use this function a lot.
   Unfortunately, the sofware doesn't supprt this very well.  The only way to
   use it is to make hard macros.

4) Lots of I/O pins.


Software:
  The ORCA software leaves a bit to be desired.  The user interface is not 
very well designed (compared to Xilinx).  There is essentially no control over 
mapping and very little control over placement and routing.  Specifying timing 
constraints requires a lot of patience.  On the PC, only one of the tools can 
be used at any time - you can't run a place'n'route in the background while
using the other tools.
  My guess is that a good man-year of effort could clean up most of the 
problems and make this a really useful tool.

Cost:
  When I checked about 9 months ago, ORCA parts were about 1/2 the price
of equivalent Xilinx parts.  This has probably changed significantly.

Recommendation:
  It seems like a toss up to me.  ORCA is cheap (but dirty), and can do some 
things that Xilinx simply can't do with any sized chip.  Xilinx has better 
software and support and provides a broader line of chips.  If you're buying
a first system, I would get Xilinx unless you need a special capability that
ORCA has. 



Article: 2716
Subject: Re: Chosing VHDL or Verilog Does Have An Impact For U.S. Engineers
From: markg@ichips.intel.com (Mark Gonzales)
Date: 29 Jan 1996 18:20:45 GMT
Links: << >>  << T >>  << A >>
In article <4ee3lk$et@cloner2.ix.netcom.com>,
Frank Guerino  <guerino1@ix.netcom.com> wrote:
>Hogwash!  People are hired on ability in this industry.  [...]

Yes, *but* you need to have the right buzzwords on your resume to get it
passed the (automated?) pre-screening process that happens before anyone
from the hiring department gets to see it.

Mark
--
definately not speaking for Intel.


Article: 2717
Subject: Re: GAL programming for hobby use...Is there no hope?
From: mzenier@netcom.com (Mark Zenier)
Date: Mon, 29 Jan 1996 18:53:24 GMT
Links: << >>  << T >>  << A >>
in <mark.stephens-2901961009190001@mstephens.gsfc.nasa.gov>, Mark Stephens wrote:
: I'd really, really like to get rid of the NOR gate glue logic and replace
: it with some species of GAL.  I have PLDasm and it's manual and can now
: create the JDEC files.  Unfortunately, my PROM programmer is just that...
: PROMs only.

: Do I need to get another programmer or can one home brew for a specific chip?

So you want to build a PLD programmer: a FAQ File

[Last Revised: January 29, 1996]

(The following is aimed at the level of the basement hacker, 
restricted to lower complexity parts.  Which is what I've found
in the surplus market.)

So you want to build a logic device programmer.

Here's a list of articles and databooks that I've scraped together.  
Grouped by devices supported and in order of usefulness (IMHO).

Just remember that if you build your own programmer, factor in
some money for test data (that is, destroyed parts).  Unless you're
using cheap parts, the $500 to $700 you tried to avoid spending for 
an inexpensive programmer could add up sooner than you expected.

First, be aware that the manufacturers don't feel it's in their
interest to give you enough information to build one. There's a 
couple of reasons.  Some them make money by selling programmers 
and software.  Some of them don't want to spend a lot of money 
trying to figure out why you (and thousands others like you) can't 
get parts to  program (or worse, stay programmed) using your homemade 
programmer.  

So, starting around 1985, most manufacturers have removed this 
information from their databooks.  Expect most CMOS parts to
have proprietary algorithms.  Also expect as parts are redesigned
to be faster, the old programming algorithms may be obselete, or
have certain parameters in them shift.

But if you are convincing, some of the manufacturers will give 
you the information on a nondisclosure basis.  (I've heard
National and TI are pretty nice.  And Cypress doesn't even require a 
nondisclosure agreement.  But Lattice and AMD are downright rude.
Unfortunatly, National is reported to be getting out of this business.)

And there is a new trend in industry that will help the hobbyist.
Manufacturers would like to control their inventory, but the
way older parts are programmed adds extra (possibly) expensive
steps to the process of making a circuit board:  procuring and 
inventorying the unprogrammed parts, programming them, reinventorying
the programmed parts (and insuring they are programmed and marked 
correctly), making sure they are available to be inserted in the 
circuit board, and placed the right location ...

And after all of that, the board is tested in Automatic Test Equipment.
This automatic test equipment has the same sort of electronics that
a device programmer has (and have been used for this at many companies).
So why not design parts that can easily (without destroying connected
circuitry) programmed during the final test stage and skip many of
the steps mentioned in the previous paragraph.  

In order to do this, the semiconductor companies have to make the
parts easy to program, and release the programming algorithms.
Intel and Lattice with their Flex and ispLSI families are doing this.
Altera has taken over Intel's PLD operation as of October '94.


1. GALs (EEPROM based), from Lattice, National and SGS-Thomson

"Build This PLD Programmer" by Robert G. Brown
Electronics Now (magazine), May 1994
     This is a simple programmer limited to the 16v8 and 20v8
     parts.  It consists of two circuit cards, one a general
     purpose parallel port for the IBM PC and a programmer
     card with the drivers, ZIF socket, and voltage regulators.
     (Very similar to the Elektor project.)

     Various kits and software available from
     R.G. Brown
     30 Wicks Road
     E. Northport, NY  17731

"Project: GAL programmer" by Manfred Nosswitz.
Elektor Electronics (magazine), May 1992
     This is a simple (5 IC's, 7 transistors, 2 voltage reg.) board
     driven by a program (in this case for an IBM PC or clone) using
     the computer's printer port.  It supports the 16v8, 20v8 original
     and A versions.  

"Project: GAL Programmer Upgrade" by M. Nosswitz
Elektor Electronics, June 1993
     An add-on board with a D/A converter to allow a variable programming
     voltage, and a new software driver.  Now programs B version GALS,
     22V10's, 20RA10's, and the GAL6001 PLA.


     The software and PC boards are available through the Elektor
     publishers/franchises in various countries.
     In the US this is Old Colony Sound Lab (the publishers of
     Audio Amateur, and the former publisher of the US edition of
     Elektor Electronics).   

     Old Colony Sound Lab
     P.O. Box 243
     Peterborough, NH  03458
     (603) 924-6371 or -6526   Fax (603) 924-9467

     In the UK
     Elektor Electronics (Publishing)
     P. O. Box 1414
     Dorchester  DT2 8YH
     England

     The item number for the software is 1701, the US price as of
     June 1993 is $22.30, the UK price 11.15 pounds.  The software
     upgrade is item 1881, $21.50 or 10.75 pounds.  The PC board
     is item 920030, US $22.30, UK 11.15 pounds.  The PC board for
     the upgrade is 930060, $9.50 or 4.75 pounds.

     Back issues may still be available from Old Colony, otherwise
     the address is 

     Worldwide Subcription Service, Ltd.
     Unit 4, Gibbs Reed Farm
     Pashley Road, Ticehurst  TN5 7HE
     England

"Generic Array Logic (GAL)"  D. Gembris
Elektor Electronics, April 1992
     A description of the architechture of a GAL, along with the
     programming algorithms.  Unfortunatly this describes the
     nonvolatile memory layout for the original version parts, and
     the A version parts would not work if this information were used.
     Some other information is left out, including describing the 
     nonvolatile memory register that contains the part ID code and 
     manufacturer.  (This article is useful if you want to disassemble 
     the software from the previous reference, but incomplete otherwise.  
     Not really needed if you want to build and use the project as is.)

2. Cypress and Samsung (UVEPROM based)

     Contrary to the trend.  Cypress Semiconductor published the
     algorithms for the simpler PLD chips they produced.  They
     have since discontinued this, and you have to request them,
     but no special agreement is required.  As of the 1990 databook,
     they included the algorithms for their 16L8, 16R8, 16R6, 
     16R4, 20G10 (like a smaller 22v10), and their 22v10 devices.

     Judging from the algorithms in their 1988 databook, Samsung 
     is a second source for Cypress.  Their CPL 20 family is the 
     same as the Cypress devices.  In addition, they have 24 pin 
     devices with the same technology that implement the 20L10, 
     20L8, 20R8, 20R6, and 20R4 devices.
     
"EPLD programmer design"  John Cromie
Electronics & Wireless World,  February 1989
     An article describing a single chip microprocessor driven
     programmer (using a Hitachi 63701) that programs the devices.
     "Contact the author for software.", a common trend in
     this publication's "projects".

3. PEEL18CV8 (EEPROM), from International CMOS Technology, Gould AMI 

"Create Your Own IC's", Bill Green
Popular Electronics, January 1990
     A single board Z80 based programmer for the PEEL18CV8 using
     keyboard entry.  No algorithm description.  PLD and EPROM 
     for z80 program needed to duplicate.  (Listed price was
     cheap, about $80 in 1990.)  Later versions were produced that
     had an interface to download from a computer, rather than
     keypad only entry.

4.   CPLDs from Intel/Altera and Lattice

     Databooks from Lattice, "pLSI and ispLSI Data Book and Handbook"
     and Intel, "Programmable Logic" have the interface and download
     specifications.  (The catch here is that the data to be downloaded
     needs to be generated from a manufacturer provided software as
     the internal layout and mapping of the device are still proprietary.) 
     This software is cheap or free, but you need to contact the
     company, or find their ftp site on the internet.

     As part of the Lattice's GAL line of parts, there is an ispGAL22v10 
     part in 28 pin PLCC package.  In the 1994 Lattice databook, there are 
     sufficient information to download the part using the onboard serial 
     interface.  And, since it is a standard architecture supported by
     most logic compiler/assemblers, there isn't a problem with a proprietary
     interal layout.

     A free demo logic compiler/programmer package is available for some of 
     the Altera EPX7xx parts from Xess Corp.  (info at http://www.xess.com/) 
     or files in the ftp://ftp.vnet.net/pub/users/xess/PLDshell/ directory.
     See the December 1995 Circuit Cellar Ink magazine for more details.

5. Classic Bipolar Fuse Programmed PALS from MMI, National, TI

"A PAL Programmer" and "Getting Started with PALS" , Robert A. Freedman
Byte, January 1987
     A programmer for the original PAL family (too many to list).  Implemented
     in the form of a IBM PC expansion card. (And sold for a while by
     Microway).  Design is implemented with PALs.  

PAL Programmable Array Logic Handbook
Monolithic Memories, 1981
  or
"Designing with Programmable Array Logic", Tech. Staff of Monolithic Memories
McGraw-Hill, 1981
     A hardback copy of the MMI databook, including the programming
     algorithms. 

Interface, Bipolar LSI, Bipolar Memory, Programmable Logic Databook
National Semiconductor, 1983
     Databook back when they still published the algorithms.

The TTL Data Book, Volume 4, Bipolar Programmable Logic and Memory
Texas Instruments, 1985
     Databook back when they still published the algorithms.

The IC Master, 1986
     TI actually published some of the algorithms in the advertising 
     pages in the Custom/Semicustom section.

6. AMD version of the classic PALS (Fuse Programmed)

Programmable Array Logic Handbook
Advanced Micro Devices, 1986-1987
     This has the algorithms for the bipolar amPAL devices that
     existed at the time, including the amPAL22V10.  These 
     differ from the 1983 algorithms, which were preliminary.  

7. PLS153, PLS159 from Signetics (Fuse Programmed)

AN12, "Low Cost Programmer for PLD 20-Pin Series"
Programmable Logic Data Manual
Signetics, 1986 and 1987
     A programmer for the low end 20 pin PLA family.  Implemented 
     in those devices.  Device mapping for only two of the members.

8. PLS100, from Signetics (Fuse Programmed)

"Programming p.l.d.s", V. Lakshminarayanan
Electronics & Wireless World, January and February 1988
     A circuit description for a programmer for the oldest
     Signetics PLA device.  No Algorithm. Contact author for
     software.

Bipolar and Mos Memory Databook
Signetics, 1980
     Algorithm desciption.  (IMHO, why bother ;-) )


Finally, here's an edited note from Paul Hoepping about some German
language articles on PLD programmers.  (Thanks.)

>Date: Thu, 31 Aug 1995 00:00:00 +0200
>From: Paul_Hoepping@citybox.fido.de (Paul Hoepping)
>Subject: List of GAL-Programmer-Projects
>
>c't is a german computer and electronics magazine. It features mainly  
>articles on computer hardware, architecture and digital electronics. I do  
>not know if there is a english equivalent.  
>
>elrad is a very professional german electronics magazine. It features all  
>kinds of digital and analog electronics and their theoretical basics.  
>There is no english equivalent.
>
>c't 9/90 and 10/90
>GAL Programmer for the 16v8 and 20v8. A plug-in PC card with many 74HC374  
>drivers allows programming and testing. The software to this project has a  
>simple GAL assembler. Source text in Turbo Pascal.
>
>c't 12/92
>Update for the above programmer. Several different programming voltages  
>and modes. The programmers decides automatically on the voltage and mode  
>by reading and interpreting ID bytes. Some Information on GALs 16V8A,  
>16V8B, 20V8A, and 20V8B. No source text of the parts that actually do the  
>programming.
>
>c't 4/94
>Extension to a EPROM programmer project. This extension allows programming  
>of 16V8, 20V8, 22V10, GAL6001 in both normal, A, B-Version. Some  
>information on GALs.
>
>elrad 11/92
>very low cost programmer that uses the PC printer port. A 16V8 and a 20V8  
>compensate for the differences in the pin out of the 16v8 and the 20v8.  
>This programmer can only do the old 16v8 and 20v8.
>
>elrad 5/94
>overview of all CPLDs and FPGAs and their development systems.
>
>elrad 7/94
>How to chose the right PLD for a design.
>
>elrad 10/94
>Starterkit for Lattice ispLSI1016, ispGAL22v10, and ispGDS14
>These new devices from Lattice are In System Programmable. You can get the  
>Lattice Development Software free of charge from the elrad BBS. Without  
>any instruction book hard to use. This version of the software can only  
>programm the smallest devices of the ispLSI family. If you want more you  
>need the full version that sells at DM 1500,-. Interesting.
>By the way: the BBS has also a Version of PALASM, free of charge!
>
>elrad 5/95
>Presentation of the Lattice ispLSI CPLD family.
>
>elrad 1/94
>PLD development using easy-ABEL.

Mark Zenier  mzenier@eskimo.com  mzenier@netcom.com


Article: 2718
Subject: Re: Emulation for a wireless chip
From: <jasonf>
Date: 29 Jan 1996 19:04:46 GMT
Links: << >>  << T >>  << A >>
I received a few requests to get a fax of the study "The Effect of Fixed I/O
Pin Positioning on The Routability and Speed of FPGAs" by Mohammed A.S. Khalid
and Jonathon Rose, Dept. of Electrical and Computer Engineering, University of
Toronto.  I was unable to fulfill all of the fax requests due to problems with
the fax machines.  However the paper is available on ftp, and I would encourage
anyone who is interested to look there instead. (See below.)

I also feel obliged to make 2 comments...

1) I apologize to anyone who may have been offended by my posting from January
16 1995.  I can appreciate the value of the comp.arch.fpga newsgroup as an
objective forum for discussion on topics of interest to the programmable logic,
and in it's original intent, the reconfigurable logic community.  So I hope I
have not set a poor example of putting "marketing blah" on the public
discussion newsgroup.  I think it would have helped to have stated that the
article was a published paper and to have not made any factual implications
beyond exactly what was stated in the paper.  As a member of a commercially
competing firm, I recognize that it is especially important to be objective in
such situations.  Routing of FPGAs is a complex issue with many technical
issues.  It is not my intent to get into such a lengthy discussion, and I don't
have the time to accept an invitation for further discussion on the issue.  But
I do apologize if I offended anyone.

2) The paper is actually interesting and stands on it's own merit.  If you are
interested to take a look, please get it off of ftp.  The paper was presented
at the 3rd Canadian Workshop on Field Programmable Devices (FPD '95), May 29 -
June 1, 1995.  The ftp address is: ftp.csri.toronto.edu. 
Please look for "techrep.ps" in the sub-directory "csri-technical-reports/325".

Sincerely,
Jason Feinsmith
Xilinx



Article: 2719
Subject: Re: GAL programming for hobby use...Is there no hope?
From: jimdrew@aol.com (Jim Drew)
Date: 29 Jan 1996 17:38:12 -0500
Links: << >>  << T >>  << A >>
Dump the GALs, they are absolutely worthless and expensive.

Go with PEELs.  Contact ICT for literature.  There was a PEEL programmer
in Radio Electronics several years ago.  It could burn 18CV8s.  I use a BP
MicroSystems PD1128 for burning PEEL/GALS/etc.  It is a bit spendy, but it
is industrial grade (I have burned several hundred thousand PEELs with no
problems).

PEELs provide a wide range of different Macro Cells, making them much more
versatile than GALs.  They are about .75 cents for an 18CV8 and about
$1.75 for a 22CV10 (although I pay less than this for 1000+ quantities).


Article: 2720
Subject: Sunshine EXPRO-80 adapter socket for MACH210
From: vaughan@wave.co.nz
Date: 30 Jan 1996 02:14:42 GMT
Links: << >>  << T >>  << A >>


I need to program some MACH210's, I have a Sunshine EXPRO-80 universal 
programmer which is capable of programming them with the addition of a 
PLCC adapter socket. However, the cost of said adapter is unreasonable
(to say the least, NZ$300) so I figure I can make my own. Can anyone 
supply me with info on which pins are used to program the Mach210 ?
This, and any other information would be greatly appreciated.


Article: 2721
Subject: Re: Chosing VHDL or Verilog Does Have An Impact For U.S. Engineers
From: guerino1@ix.netcom.com(Frank Guerino )
Date: 30 Jan 1996 05:01:22 GMT
Links: << >>  << T >>  << A >>
In <DLwGsJ.Foo@world.std.com> jcooley@world.std.com (John Cooley)
writes: 
>

>
>Frank, I think you're missing my point that this "ability" usually is
>measured by how well one knows buzzwords like "Synopsys", "MOTIVE",
>"DFT", "DSP", "Verilog" -- you've never had a headhunter call you up
>asking if you know buzzword "XYZ"?  You've never known engineers who
>were hot career-wise because they knew these buzzwords or others who
>weren't doing so well because they didn't have the right buzzwords?


I've met too many people that have made the mistake of hiring on
"buzzwords".  They're not what makes the engineer.  They may make
it easier to make a decision, but they mean nothing to a good manager.
Synthesis concepts are the same whether you're using Synopsys or
Bulldozer or Silcsyn.  HDL concepts are the same whether you use
VHDL or Verilog.  A good engineer can adapt to tools quickly.  Just
because you have had exposure to a synthesis tool doesn't mean I
want you on my design team.  As a matter of fact, there won't be any
synthesis tools on the exam sheet I give an interviewing engineer.


>Also, Frank, don't confuse the fact that right now engineers are 
>hired pretty much because they're what's available right now due 
>to the current 6 month shortage of them.  Once the glut comes back,
>it'll be disposable employee as usual.


The "glut" in my experience has always been engineers that range
from poor to mediocre who load their resumes with keywords to get
interviews but then can't answer simple basic design questions when
sitting in front of you at their interview.  Every company that
I've ever dealt with has always made it a practice to hire good
engineers even through so called "gluts" or hiring freezes.  If
you're good you'll always be part of the exception, not part of
the rule.  "Tools" help build foundations but their nothing without
the knowledge of how or why you're building the house...

I go through hundreds of resume's that all have the great keywords
on them.  It's the one that has barely any but has much "content"
that I'm always looking for.

FG


Article: 2722
Subject: ABEL
From: Steve Lee <sjlee@iastate.edu>
Date: Mon, 29 Jan 1996 21:21:18 -0800
Links: << >>  << T >>  << A >>
Hi,

I am using MacABEL in classes and was wondering if anyone knew of a FAQ for ABEL or some more 
information about the language.

Thanks in advance.

-- 
Steve Lee
Computer Engineering/Computer Science
Iowa State University
email -> sjlee@iastate.edu
WWW   -> http://www.cs.iastate.edu/~sjlee/homepage.html


Article: 2723
Subject: HELP WANTED - PC-UPROG device programmer
From: fink@post.tau.ac.il (Udi Finkelstein)
Date: Tue, 30 Jan 1996 15:52:32 GMT
Links: << >>  << T >>  << A >>
I have received a universal device programmer called PC-UPROG, which
is made by Advantech. He bought it a few years ago, and now he has
little use for it.

Unfortunately, he can't find the disks with the software for it!

Does anyone knows an FTP site or a Web site which has this software?
If not, can anyone mail a copy of the software (I believe it's legal,
since I *have* the unit, and the software is useless without the
programmer!).

thanks,
Udi



Article: 2724
Subject: Re: VHDL/Verilog training
From: sgm@hplb.hpl.hp.com (Steve Methley)
Date: Tue, 30 Jan 1996 17:12:07 GMT
Links: << >>  << T >>  << A >>
T. D. Bouvia (tdb@icf.hrb.com) wrote:

: I am requesting any and all feedback regarding in-house training of 
: VHDL/Verilog.  This could be tutorials, seminars, video tapes,
etc...

A slight basenote drift but does anyone know of a good Verilog course
in the UK?

Best Regards,
Steve.




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