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 3800

Article: 3800
Subject: Re: US-NH FPGA Design Engineer, Avionics
From: suzanne@world.std.com (suzanne M southworth)
Date: Sun, 4 Aug 1996 04:12:42 GMT
Links: << >>  << T >>  << A >>


Go John GO!!!!! Drive them all out!

(giggle).


John Cooley (jcooley@world.std.com) wrote:
: >Reference Number: 	1000417
: >Title:			FPGA Design Engineer, Avionics
: >Location:		NH
: >Type:			Permanent
: >Salary:			Open, relative to experience
: >
: >Description:
: >
: >Design and develop electronic circuits that will be primarily digital
: >with some custom components including FPGAs and/or ASICs. Designs may
: >involve processors, data bus interfaces, combinatorial functions, and
: >aircraft or spacecraft interfaces. The design process will include
: >simulations using state of the art tools. 


: This one's easy; it's Lockheed-Sanders up in New Hampshire.  I even
: know the engineers up there!  If anyone's is looking for a job
: there, blow off this headhunter and send your resumes to me.  I'll
: forward them to the engineers there and they can get the referal
: bonus!  (Or if you want to send your resume up to their HR dept.,
: call (603) 555-1212 and ask for "Lockheed-Sanders".)

: Why can't these headhunters post in the job newsgroups?

:                            - 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 4599 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: 3801
Subject: ANNOUNCE : HDL Editor
From: garyc1@msn.com (gary crothers)
Date: 4 Aug 96 10:43:09 -0700
Links: << >>  << T >>  << A >>
VHDL System Solutions P\L are now accepting orders for their HDL 
(VHDL and Verilog) editor called Setanta ED.

A 45-day evaluation copy of Setanta ED may be downloaded from :

http://www.vhdl.com.au

Trivia : "Setanta" is the name of a famous Irish mythical warrior who 
was capable of defeating armies, single-handedly.


Setanta ED has been designed and developed by FPGA/ASIC designers.
Article: 3802
Subject: (no subject)
From: bblase@sdsu.edu
Date: 4 Aug 1996 21:44:17 GMT
Links: << >>  << T >>  << A >>
> 
> --------------------------------------------------------------------
> 
> Newsgroup: comp.arch.fpga
> 
>    * Multi-FPGA Partitioners? - "J. A. Herrera Camacho" (21)
>    * assigning LOC in XACT - Rafiki Kim Hofmans (30)
>         o Andy Gulliver (6)
>         o Raghavendra G Jorapur (17)
>    * Re: Job posting - John Cooley (30)
>    * Re: Question: FPGA versus ASIC design. - Peter (28)
>    * Reconfigurable Hardware - Pasquale Corsonello (13)
>    * ANNOUNCE: FREE Model of the Month - IPCRA - Rob Hurley (53)
>    * ANNOUNCE: New FREE Tip of the Month - Encapsulation - Rob
>      Hurley (52)
>    * US-NH FPGA Design Engineer, Avionics - Kevin Hawes (35)
>         o John Cooley (40)
>              + Mark Christensen (53)
>              + suzanne M southworth (48)
>    * US-NH FPGA Computer Architecture Design Engineer - Kevin Hawes
>      (39)
>    * Re: Clearing security fuse on Lattice ispLSI2032? - Matt Cross
>      (15)
>    * Re: Question: FPGA versus ASIC design. - Hajimowlana Hossain
>      (20)
>    * Xilinx/FPGA Timing Problems - Jeff Hunsinger (36)
>         o Peter (33)
>    * Re: Question about books for FPGA - Peter Alfke (26)
>    * ANNOUNCE : HDL Editor - gary crothers (12)
> 
> --------------------------------------------------------------------
> 


Article: 3803
Subject: Re: Job posting
From: jerry@certus.com (Jerry McGoveran)
Date: Mon, 05 Aug 1996 00:53:53 GMT
Links: << >>  << T >>  << A >>

HighTech <hightech@mv.mv.com> wrote:
>>
>>Are we going to start posting job listings to these newsgroups?
>>

jcooley@world.std.com (John Cooley) wrote:
>Please don't.  Job postings are for the job newsgroups.  Once the
>headhunters start massively job posting in the technical newsgroups,
>it effectively kills the technical discussions in the newsgroups
>because it turns off too many engineers.

>It's all a matter of signal-to-noise; what does the fact that 8
>different headhunters posting and reposting "HOT JOBS AT SGI!!!"
>have to do with my getting a solution to the EDA bug I'm currently
>fighting?  Nothing.
>                           - John Cooley
>                             Part Time EDA Consumer Advocate
>                             Full Time ASIC, FPGA & EDA Design Consultant


John,

I haven't done a count, but it seems that your crusade against 
these job postings have generated much more "noise" than the postings
themselves.  I have to wonder about the effectiveness of your tactics
if your goal is to keep the group focused on technical issues.  As 
another poster stated, the job postings can be easily skipped in most
decent news readers.

Now, before anyone takes me wrong, I do not defend the posting of off
topic articles to *any* group.  Those who violate netiquette should
be sent a copy of the FAQ and the charter and asked politely to 
refrain from such violations in the future.  By email, not by post.
Repeat offenders should be dealt with more sternly.

However, as a pragmatic sort, I realize that these posts will occur
in spite of anyone's best efforts to prevent them.  So why waste
valuable time (John - read 'billable hours') tilting at windmills?
So far, the number of jobs postings are a small percentage of the
total traffic in this group.  They are nowhere near a threat to
overwhelm the technical content.  If and when that starts to
happen, I'll be right there beside you helping to preserve our
forum.  Until then, let's be careful not to overreact.

-Jerry


Certus Consulting Group               | Consulting in Integrated Circuit
3733 Chesapeake Court                 | Design and Verification,
Antioch, CA 94509                     | Fault Grading, Test Development,
(510)757-0685                         | and Logic Synthesis
http://www.certus.com/certus/

Article: 3804
Subject: Re: Question about books for FPGA
From: Rainer Scharnow <amigo@bintec.de>
Date: Mon, 5 Aug 1996 09:46:48 +0200
Links: << >>  << T >>  << A >>
On Sat, 3 Aug 1996, Peter Alfke wrote:

> In article <Pine.SUN.3.91.960729074337.16136A-100000@Bundy>, Rainer
> Scharnow <amigo@bintec.de> wrote:
> 
> > Of course, no 
> > one describes the limitations of the products 8-).
> > 
> Did it ever occur to you that the only thing the parameter values in the
> data sheet describearet device limitation?
> ...
> Our industry gives you hundreds ( thousands ? ) of pages of product limitations.
> I suppose you have never looked at it this way. :-)

Hi,

I must appologize, my statement about limitations was very weak :-). 
Wanted to say the limitations of a specific device have to do with the 
kind of logic I have to synthesize (bus oriented logic vs. state machine 
oriented applications for example). Or think of geometry aspects at the 
FPGA (left-right orientation in XC3xxx, nearly symmetric orientation in 
XC4xxx) that will influence the design preparations strongly - nothing 
for softies :-)

E-regards

---------------------------
Rainer Scharnow
(amigo@bintec.de)
BinTec Commmunications GmbH
---------------------------
Article: 3805
Subject: Re: assigning LOC in XACT
From: manningc@southern.co.nz (Charles Manning)
Date: 5 Aug 1996 07:52:49 GMT
Links: << >>  << T >>  << A >>
In article <4to4cb$bt@rc1.vub.ac.be>, tw38966@vub.ac.be says...
>
>Hi,
>
>can someone tell me how I can assign LOCs to a 16 bit IOPAD in the Xilinx
>schematic entry ?
>I suppose I have to make a file with the LOCs.
>
>Or is the only solution using 16 times 1 IOPAD ? :(


When you edit I assume you're using Active cad. From what I can tell...

For a single IOPAD you assign the  property LOC=Pnn.
For an bulti-bit IOPAD, assign a whole heap of properties, called LOC[0] to LOC[n-1]
to match the bits.
eg.
 LOC[0]=P5
 LOC[1]=P6
 LOC[2]=P7
 ...
 LOC[15]=P20


#disclaimer<I'm a newbie>


-- 
------------ When all else fails, find a scapegoat ----------------
Charles Manning                          manningc@southern.co.nz              
Christchurch, New Zealand         
-------------------------------------------------------------------

Article: 3806
Subject: A Survey on Design Errors, Now by E-mail
From: movahed@tumlis.lis.e-technik.tu-muenchen.de (M. Movahedin)
Date: 5 Aug 1996 11:41:50 GMT
Links: << >>  << T >>  << A >>


Dear ASIC/FPGA Designer

This is the E-mail version of the survey on design errors.

You can visit us at http://www.lis.e-technik.tu-muenchen.de/DEP/ and
run the survey online, or fill out this E-mail and return it to us.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

This server is installed to collect the opinions of ASIC and FPGA designers
regarding the concept of design errors and problems they can cause. Our
final goal is to develop special technology extensions and synthesis
algorithms that allow the designers to correct their mistakes even after
chip fabrication. (This capability is named Correctability) These mistakes
are principally those design errors that are made during the design
development steps and have not been found in verification phases. In order
to get more familiar with this subject, you can refer to:

     "Modeling of VHDL Design Errors and Methods for their Correctability",
     M.R. Movahedin, P. Kindsmόller, W. Stechele,
     VHDL International Users' Forum, Spring 1996 (VIUF'96).

or get its postscript version.

This survey will help us to find out what kind of design errors have to be
concentrated more on, and which imaginable ones are less important.

We appreciate your efforts in filling out this questionnaire, and will send
you a copy of the processed results, if you provide us with an E-mail
address here:



IMPORTANT: Answers to some questions seem to be your confidential
information, or violate copyright of your organization. Hereby we state that
all of the collected data will be processed absolutely confidentially. It
means:

  1. The log-file of this WWW-Server, which holds your host-name, will be
     used only for administration purposes (if any were necessary), and will
     be erased after a short time.
  2. Above E-mail address (if you have provided) will not be used for any
     intention, but sending the results to you.
  3. None of the answers will be published individually, but among others
     after statistical processes.

(If you need, we can also send a signed version of this statement to you).

However, most of the questions are non-critical as far as the
confidentiality is concerned, and you may leave any question un-answered if
you wish.

Thank you again.

Institute for Integrated Circuits
Technical University of Munich
Munich, Germany

For any question or further information, feel free to send us a message:
     M_Movahedin@lis.e-technik.tu-muenchen.de

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

please fill the multiple choices with a `X';

e.g. <X> (selected) or 
     < > (unselected)

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

                         PART 1: GENERAL QUESTIONS

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

  1. You are mainly involved in the design of digital systems using:

					< > Full Custom ASICs
					< > Gate Arrays, Standard Cells
					< > Programmable Logic (FPGA, CPLD)

     Note: if you are involved both in ASIC and FPGA designs, please fill
     this questionnaire two times, one as an ASIC designer, and second as an
     FPGA one.

     -----------------------------------------------------------------------
  2. The average size of your designs (excluding RAMs and ROMs) is:

					< > less than 3K
					< > 3K - 10K
					< > 10K - 20K
					< > 20K - 50K
					< > 50K - 100K
					< > 100K - 200K
					< > more than 200K

     -----------------------------------------------------------------------
  3. Which of the following design methods describes your strategy best:

    < >  Describe the design in a high level using an HDL, and have the
     synthesizers make necessary resource scheduling, allocation and
     technology mapping automatically, and provide desired design
     constraints. (e.g. you are a Synopsys Behavioral Compiler user)

    < >  Make resource scheduling and allocation manually, and let the
     synthesizer automatically define the data elements (registers,
     operators, etc.) and their bussing structure, do eventually resource
     sharing, map them to the technology in use, and provide desired design
     constraints. (e.g. you use Synopsys VHDL/HDL/Design Compiler at RTL
     level without being very deeply involved in hardware design concepts)

    < >  Make resource scheduling and allocation, data element selection and
     their bussing structure and resource sharing manually, define all of
     them in an HDL, use a synthesizer to translate and map it to the
     technology in use, and provide desired design constraints. (e.g. you
     are a conventional hardware designer, are always strongly aware of the
     structure of final design, using Synopsys VHDL/HDL/Design Compiler at
     RTL level)

    < >  Do all jobs manually using schematic capture tools.

    < >  others (please specify) : [                                  ]
    
     -----------------------------------------------------------------------
  4. As an HDL, you use:
        o VHDL
					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)

        o Verilog
					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)

        o  others (please specify) : [                                  ]
					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)

     -----------------------------------------------------------------------
  5. How many percent of your designs (chips) work quite properly in the
     first system they are integrated in?

					< > 90%-100%
					< > 65%-90%
					< > 35%-65%
					< > 10%-35%
					< > 0%-10%

     -----------------------------------------------------------------------
  6. If your chip did not work properly in the first system integration, how
     many times averagely would you have to modify your design, till it
     works fairly after its integration in the whole system?

					< > 1
					< > 2-3
					< > 4-7
					< > more than 7

     -----------------------------------------------------------------------
  7. Having a flawed chip in the hand, you can do some of the following
     tasks.
     How often can they be applied (i.e. practically possible)?

        o You do not need to be aware of design errors, because you develop
          your designs first in FPGAs and then translate them to ASICs.
          Nothing to lose, even in case of some design errors.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)

        o Though the chip is flawed, it is still usable, however with a
          reduction in performance or desired features.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o The chip is still usable, however a change in the software is
          necessary in order to compensate for the hardware flaw.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o The chip is still usable, however some extras or changes in the
          hardware around it (at the board level) are necessary in order to
          compensate for the hardware flaw.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o The hardware error can be corrected using Laser or Focused Ion
          Beam on the chip, so it would be quite usable later on.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o Unfortunately nothing, the chip is functionally not usable at all,
          i.e. the chip has some fatal errors.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)

        o  others (please specify) : [                                  ]

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     -----------------------------------------------------------------------
  8. A flawed chip can not work properly in the whole system because of
     errors or malfunctions in its different parts, some of which are listed
     below.
     How often can each of them happen?

        o Malfunction or design error in the chip logic functionality.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


               In this particular case, the design error lies in:

                  o Data Section, i.e. data elements like registers,
                    operators & multiplexers, and their bussing structure.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


                  o Control Section, i.e. the state machine that controls
                    the operations.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o Malfunction or error in the internal timings.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o Malfunction or error of environmental interfaces, namely I/O
          specifications.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o Error or failing in chip fabrication that could not been detected
          in the test phase.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o  others (please specify) : [                                  ]

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     -----------------------------------------------------------------------
  9. How often does each of the following points influence on the
     malfunction of a chip in a system in which the chip is integrated:

        o Mistakes and errors in the original specification that specifies
          the functionality of the design and is sent to designers to
          develop the necessary hardware and software based on it.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o Incompleteness of the original specification, i.e. some seldom
          happening situations are not considered carefully, and hence the
          designers would not take care of.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o Errors and/or bugs in the HDL description of the design, which is
          developed by you or your design team and is further synthesized by
          a synthesizer tool.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o Errors and/or bugs in the CAD tools. (synthesis, place&route,
          timing analysis, functionality verification, etc.)

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


        o Errors in the specification and/or prediction of the environment
          status, with which the chip has to interface. (e.g. thermal
          conditions, etc. )

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)

        o  others (please specify) : [                                  ]

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     -----------------------------------------------------------------------
 10. If some methods are developed that would allow you to correct your
     design errors even after the fabrication of your ASIC (namely
     correctability), then you would be ready to pay for its advantages
     with:
        o an increase in the area of the design by at most

					< > 10%
					< > 30%
					< > 75%
					< > 100%
					< > 200%
					< > no matter

        o a decrease in the speed of the design by at most

					< > 60%
					< > 40%
					< > 20%
					< > 10%
					< > 5%
					< > not at all


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

                     PART 2: (V)HDL DESIGN ERROR MODEL

The second part of this questionnaire concentrates on a (V)HDL design error
model. This model is mainly based on the usually used synthesizable subset
of VHDL, but you can answer the questions, even if you are a Verilog user.

This model deals mainly with the mistakes made during the development of the
design HDL description, and are propagated to gate level by a synthesizer,
resulting in a flawed chip. In view of the fact that a quite complete
simulation and/or verification of a large design takes a long time and is
practically impossible, those flaws could not be detected before chip
fabrication and only after the chip takes effect in the whole system, they
would be detected by observing the system malfunctions. Thus, a redesign ,
i.e. rewriting the HDL description and correcting its mistakes, will be
necessary to achieve to a flawless chip.

The answer to the question why these errors have happened and not detected
in verification phases is beyond this questionnaire, and depends strongly on
the designers' design methodology. But it can not be forgotten that no one
can claim that his/her design is quite error free. The VLSI history shows
that even large powerful companies have designed and fabricated flawed
microprocessors and their mistakes are first detected after a very long
while.

Below, different possible and imaginable (V)HDL design errors (mostly with
an example showing it more clearly) are presented. These different classes
of mistakes have a very important point in common: they do not cause any
syntax error and don't make the design unsynthesizable based on the
synthesizable VHDL subset in use, because the HDL description after these
changes should be compiled again and be synthesized as before. In each item,
you are asked to define: how often can they appear, i.e. how probable are
they;

     -----------------------------------------------------------------------
  1. Mistakes in ENTITY declaration of any making up modules, including:
     extra or inadequate ports, false port direction, false port width.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     Example:

          Flawed VHDL Code:

          ENTITY e IS
          PORT (
          a, b, _c_ : IN INTEGER;
          d: IN BIT_VECTOR(7 DOWNTO 0))
          END e;

          Corrected VHDL Code:

          ENTITY e IS
          PORT (
          a,b: IN INTEGER;
          d: OUT BIT_VECTOR(_15_ DOWNTO 0);
          _f_: IN BOOLEAN)
          END e;

     -----------------------------------------------------------------------
  2. Mistakes in declaration parts, including: false signal and/or variable
     bit wide, false signal and/or variable type.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     -----------------------------------------------------------------------
  3. Mistakes in constants, e.g. logic value, integer value, state machine
     state enumeration names, etc.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     Example:

          Flawed VHDL Code:

          a <= 12;
          b <= TRUE;
          next_state <= state_5

          Corrected VHDL Code:

          a <= _15_;
          b <= _FALSE_;
          next_state <= _state_8_;

     -----------------------------------------------------------------------
  4. Mistakes in net (identifier) names.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     Example:

          Flawed VHDL Code:

          a <= b + c ;
          z <= x AND y ;

          Corrected VHDL Code:

          a <= b + _e_ ;
          z <= x AND _t_ ;

     -----------------------------------------------------------------------
  5. Misplacement of parenthesis.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)



     Example:

          Flawed VHDL Code:

          x <= a AND ( b OR c );

          Corrected VHDL Code:

          x <= _(_ a AND b _)_ OR c;

     -----------------------------------------------------------------------
  6. Mistake in operators, e.g. logic operators and arithmetic ones.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     Example:

          Flawed VHDL Code:

          x <= a AND b ;
          y <= c - d ;

          Corrected VHDL Code:

          x <= a _OR_ b ;
          y <= c _+_ d ;

     -----------------------------------------------------------------------
  7. Assignment errors, including: deficiency in a necessary assignment,
     extra existence of an assignment, incomplete assignment.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     Example:

          Flawed VHDL Code:

          ----
          y <= a AND b;
          z <= a XOR b;

          Corrected VHDL Code:

  >>>        x <= a OR b;
  >>>        ----
  >>>        z <= a XOR b XOR c;

     -----------------------------------------------------------------------
  8. Absence of a conditional (IF-THEN-ELSE and WHEN-CASE) expression.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     Example:

          Flawed VHDL Code:

          next_state <= state_8;

          Corrected VHDL Code:

          IF a='1' THEN
          next_state <= state_8;
          END IF;

     -----------------------------------------------------------------------
  9. Extra conditional control of some expressions that do not need any,
     though the conditional expression itself must exist to control other
     expressions.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     Example:

          Flawed VHDL Code:

          output_1 <= FALSE;
          IF a='1' THEN
          next_state <= state_8;
          output_1 <= TRUE;
          END IF;

          Corrected VHDL Code:

          output_1 <= FALSE;
          IF a='1' THEN
          next_state <= state_8;
          END IF;

     -----------------------------------------------------------------------
 10. Deficiency in controlling of some expressions with a conditional
     expression, though the conditional expression itself exists.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     Example:

          Flawed VHDL Code:

          IF a='1' THEN
          next_state <= state_8;
          END IF;
          output_1 <= TRUE;

          Corrected VHDL Code:

          IF a='1' THEN
          next_state <= state_8;
          output_1 <= TRUE;
          END IF;

     -----------------------------------------------------------------------
 11. Misplacement of an expression in a WHEN-CASE structure.

					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)



     Example:

          Flawed VHDL Code:

          CASE a(1 DOWNTO 0) IS
          WHEN "00" => b <= c+1;
          WHEN "01" => b <= c-1;
          WHEN OTHERS => b <= c;
          END CASE;

          Corrected VHDL Code:

          CASE a(1 DOWNTO 0) IS
          WHEN "00" => b <= c+1;
          WHEN "01" => b <= c-1;
          WHEN "10" => b <= c+1;
          WHEN OTHERS => b <= c;
          END CASE;

     -----------------------------------------------------------------------
 12. Mistakes in component instantiation, including: false component name,
     false port binding or false passed generic parameters.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     -----------------------------------------------------------------------
 13. Mistakes in GENERATE expressions, i.e. extra/inadequate generation of
     concurrent codes.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     -----------------------------------------------------------------------
 14. Mistakes in function and procedure calls, i.e. false function name,
     false ports and parameters.


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     -----------------------------------------------------------------------
 15.  others (please specify) : [                                  ]


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


     -----------------------------------------------------------------------
 16.  others (please specify) : [                                  ]


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)

     -----------------------------------------------------------------------
 17.  others (please specify) : [                                  ]


					< > almost always (90%-100%)
					< > often (65%-90%)
					< > sometimes (35%-65%)
					< > seldom (10%-35%)
					< > almost never (0%-10%)


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

                 You are welcome to comment on this survey:

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


Article: 3807
Subject: Re: Xilinx/FPGA Timing Problems
From: jeffh@oakhill-csic.sps.mot.com (Jeff Hunsinger)
Date: 5 Aug 1996 14:48:28 GMT
Links: << >>  << T >>  << A >>

> The "proper" way to do this is to use one of the global clock nets to
> clock all the D-types, and use clock enables to decide which actually
> get clocked. 

I already do this, but I still get flakey operation. Re-routing with tightened
(or even loosened!) frequency constraints can result in a working design, but
I'm hesitant to trust these "fixes". Sometimes one part of a circuit will start
working after re-routing, but another area will develop a problem.

If I ever need to define frustration, this will serve me well.

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

Jeff Hunsinger
jeffh@oakhill-csic.sps.mot.com

Article: 3808
Subject: !! Semiconductor SuperSite.Net
From: "Aaron A. Cohn" <aaCohn@SuperSite.Net>
Date: Mon, 05 Aug 1996 15:27:02 +0000
Links: << >>  << T >>  << A >>
!! Semiconductor SuperSite.Net
-- 
The Semiconductor SuperSite features a directory of 1,000 semiconductor 
vendors and thousands of products from semiconductor processing vendors.
********************
 SuperSite.Net, Inc.
Sales@SuperSite.Net
http://SuperSite.Net
***********************************
http://SuperSite.Net/Semiconductor/
http://SuperSite.Net/TechJobs/
***********************************
Article: 3809
Subject: Re: Designing Dual Port RAM with 4000 series.
From: e9125884@stud1.tuwien.ac.at (Gerhard Wiesinger)
Date: 5 Aug 1996 18:19:53 GMT
Links: << >>  << T >>  << A >>
In article <peter-2307961035010001@appsmac-1.xilinx.com>,
   peter@xilinx.com (Peter Alfke) wrote:
>In article <DuyvHJ.50J@news.uwindsor.ca>, hajimow@engn.uwindsor.ca wrote:
>
>>         I am using Xilinx 4000 series and I want to design a dual port RAM.
>


>Pelase don't even try to do that. 
>The XC4000E has additional hardware ( transistors ) that facilitate
>dual-port RAM operation. The XC4000 does not. If you need true dual port
>RAM operation, use the XC4000E. As a bonus, it is also cheaper than the
>equivalent XC4000.

Is there a VHDL model available which is also synthesizeable?

BTW:
As far I read the databook (1993) I saw that the dual ported ram cannot be 
written on both ports?

Are there any Xilinx FPGAs available which support symmetrically dual ported 
ram operations?

Ciao,
Gerhard
Article: 3810
Subject: Re: Job posting
From: George Patrick <gpatrick@aracnet.com>
Date: Mon, 05 Aug 1996 12:50:31 -0700
Links: << >>  << T >>  << A >>
> I haven't done a count, but it seems that your crusade against
> these job postings have generated much more "noise" than the postings
> themselves.  I have to wonder about the effectiveness of your tactics
> if your goal is to keep the group focused on technical issues.  As
> another poster stated, the job postings can be easily skipped in most
> decent news readers.
> 
Agreed.  The amount of ANY postings to this group is so small that
the few extra posts by headhunters (as long as they are looking for
Cadence people) is not going to damage it.  As it is there are more 
posts from those misguided AutoCAD people than messages about IC or 
PCB design texhnical issues.  Another issue: It's easy to say "post 
into the jobs groups," but when is the last time you tried to go 
thru the 2000 or more posts a day posted to those various groups 
for the one or two posts a month for designers?  IMHO, it's time 
to worry more about MAKING technical posts than worrying about the 
few posts that will show up here for jobs.  If it bothers anyone 
THAT much, they ought to step forward to form a moderated Cadence 
group.
-- 
+----------------------------------------------------------------+
| George H. Patrick III    Take what you like and leave the rest |
| gpatrick@aracnet.com                           My opinion ONLY |
| George.Patrick@pii.com        http://www.aracnet.com/~gpatrick |
+----------------------------------------------------------------+
Article: 3811
Subject: Job Opportunity-Hughes Research Laboratories
From: Lynn Ross <lross@msmail4.hac.com>
Date: Mon, 05 Aug 1996 13:54:58 -0800
Links: << >>  << T >>  << A >>
Hughes Research Laboratories has an immediate opening for a researcher 
to join our Embedded Real-Time Processing Project team developing 
special purpose, high performance, processors for embedded real-time 
signal and image processing.

While specific duties will be matched to the skills of the team as a 
whole, anticipated job functions include developing special purpose 
processors at one or more levels of:  architecture, performance 
modeling, HDL design, ASIC/FPGA design, digital circuit design, and 
board level design; developing software tools to support the design 
process, including runtime support software and application code for the 
special purpose. Additional responsibilities will include working with 
customers to analyze, identify and develop new research areas.

Preference will be given to candidates with greater technical breadth. 
It is desired that candidates posses technical knowledge in several (not 
all) areas from the following list: 
€	digital system design (including custom ASIC, gate array, and  FPGA 
  design)
€	computer architecture	
€	digital signal and image processing
€	processor performance modeling	
€	software tool development
€	hardware design in VHDL or Verilog	
€	software engineering
€	programming in C or C++ for UNIX/WindowsNT	
€	parallel processing

Candidates should possess a M.S. or Ph.D. in Electrical Engineering, 
Computer Engineering, or Computer Science; a Ph.D. is preferred.  In 
addition, candidates should possess:  strong verbal and written 
communications skills, the ability to function effectively in a team 
environment; and an openness to technical challenges and learning new 
skills.   Based on government restrictions regarding the export of 
technical data, a U.S. citizenship or permanent resident status is 
required.

HRL staff members are encouraged to invent, patent and publish on a 
regular basis.  This commitment helps keep Hughes poised at the 
frontiers of electronics and information technology.  Our ideal 
location, competitive salary and benefits package contribute to a work 
environment designed to optimize creative research.

Please send your resume to:  € Lynn W. Ross  € Department 3DSWWW  € 
Hughes Research Laboratories  € 3011 Malibu Canyon Road,  € Malibu  € CA  
€ 90265  FAX:  310-317-5651  € E-mail:  lross@hrl.com.  To learn more 
about HRL, visit our WebPage at http://www.hrl.com/  Proof of legal 
right to work in the United States is required.  An Equal Opportunity 
Employer.
Article: 3812
Subject: Re: Xilinx/FPGA Timing Problems
From: ft63@dial.pipex.com (Peter)
Date: Tue, 06 Aug 1996 06:58:36 GMT
Links: << >>  << T >>  << A >>

>I already do this, but I still get flakey operation. Re-routing with tightened
>(or even loosened!) frequency constraints can result in a working design, but
>I'm hesitant to trust these "fixes". Sometimes one part of a circuit will start
>working after re-routing, but another area will develop a problem.

Does it simulate OK, with a simulator? Which one?

Another area, speaking from memory, is one of the command line
switches on xnfmap (I think) which allows the use of the "direct"
input. This has a nonzero hold time, whereas normal D-types have a
zero hold time. Or something like that. But I never had problems with
that.

Peter.
Article: 3813
Subject: ACTEL Prices
From: bxa8@po.CWRU.Edu (Bassam Al-Kharashi)
Date: 6 Aug 1996 10:57:21 GMT
Links: << >>  << T >>  << A >>

Hello ...

I would like to know the cost of the following devices
Actel ... A1425A    84 pins       2,500 gates
Actel ... A1240A    84 pins       4,000 gates 
Actel ... A14100A   257 pins     10,000 gates.

Thanks for your help

Bassam 
bxa8@po.cwru.edu
-- 
Bassam A. Al-Kharashi
email bxa8@po.cwru.edu
Article: 3814
Subject: Pricing information - ACTEL
From: bxa8@po.CWRU.Edu (Bassam Al-Kharashi)
Date: 6 Aug 1996 11:01:48 GMT
Links: << >>  << T >>  << A >>

Hello ...

I would like to know the cost of the following devices
Actel ... A1425A    84 pins       2,500 gates
Actel ... A1240A    84 pins       4,000 gates 
Actel ... A14100A   257 pins     10,000 gates.

Thanks for your help

Bassam 
bxa8@po.cwru.edu
-- 
Bassam A. Al-Kharashi
email bxa8@po.cwru.edu
Article: 3815
Subject: ACTEL Security Fuse
From: bxa8@po.CWRU.Edu (Bassam Al-Kharashi)
Date: 6 Aug 1996 11:16:54 GMT
Links: << >>  << T >>  << A >>

Does the security fuse protect the fpga from beeing able to read
it? 
-- 
Bassam A. Al-Kharashi
email bxa8@po.cwru.edu
Article: 3816
Subject: Re: Question about books for FPGA
From: peter@xilinx.com (Peter Alfke)
Date: Tue, 06 Aug 1996 10:34:09 -0700
Links: << >>  << T >>  << A >>
In article <Pine.SUN.3.91.960805093518.21200A-100000@Bundy>, Rainer
Scharnow <amigo@bintec.de> wrote:


> Wanted to say the limitations of a specific device have to do with the 
> kind of logic I have to synthesize (bus oriented logic vs. state machine 
> oriented applications for example).

Don't look for marketing literature to tell you that information. You
would have to read between the lines, and you might still get the wrong
information.
Nobody, especially no marketing group, wants to say anything remotely
negative about the products they are selling.
I would be looking for information from users, especially universities.

Regarding Xilinx devices, you may want to look up the app note "Chosing a
Xilinx Product Family" on page 14-3 in the new 1996 Data Book that is
being distributed right now. Your best bet may be on the web (
www.xilinx.com ).
I wrote those 6 pages, and it is as close to being candid as you may ever
get information from any supplier.

Peter Alfke, Xilinx Applications
Article: 3817
Subject: "Xilinx nixes its antifuse arrays"
From: markc@gibelet.nexen.com (Mark Christensen)
Date: 6 Aug 1996 15:53:16 -0400
Links: << >>  << T >>  << A >>

Xilinx 8100 series users may want to check out the August 5th
EE Times cover page. Not surprising given all the problems with
the part.
-- 
Mark Christensen				       ascom-Nexion
email: markc@nexen.com				       289 Great Road
ph: (508) 266-2315				       Acton, MA 01720

Article: 3818
Subject: Image Processing and Voice Recognition
From: Andreas Spanias <spanias@asu.edu>
Date: 6 Aug 1996 20:03:14 GMT
Links: << >>  << T >>  << A >>
Two Short Courses in Image Processing and Voice Recognition

For more information and a complete brochure contact

Andreas Spanias
spanias@asu.edu

Article: 3819
Subject: Re: Xilinx/FPGA Timing Problems
From: Ray Andraka <randraka@ids.net>
Date: 7 Aug 1996 01:53:30 GMT
Links: << >>  << T >>  << A >>
ft63@dial.pipex.com (Peter) wrote:
>
[stuff deleted] 

> But I have more often come across a nastier problem, common to all
> FPGAs: say you have a 16-bit shift register. Obviously, for a SR to
> work, the clock skew stage-to-stage has to be less than the clock-to-Q
> propagation delay. IOW, you ideally want to clock all the stages
> together.

True.  Use the global clock to minimize skew.
> 

[stuff deleted]

> The "proper" way to do this is to use one of the global clock nets to
> clock all the D-types, and use clock enables to decide which actually
> get clocked. Of course, in my above SR example, they all get clocked
> together anyway, but you may still need to gate the clocks, otherwise
> the SR will be shifting all the time!
> 
> Unless I am oversimplifying your problem, it is possible that this is
> what you are seeing. Even if you do everything "synchronous", this is
> where you get caught.
> 
If you are gating clocks you are not synchronous!  The right way to 
do this is to create an enable in the logic using feedback. This uses 
up two variables to the LUT but it is fast and avoids any clock skew 
problems. If you must gate the clock(avoidable in most cases) you 
should use the clock enable inputs to the CLBs, but beware their use 
can congest routing. 

-Ray Andraka
Chairman, the Andraka Consulting Group
401/884-7930   FAX 401/884-7950
mailto:randraka@ids.net
http://www.ids.net/~randraka/
 
The Andraka Consulting Group is a digital hardware design firm 
specializing in high performance FPGA designs.  Services include 
complete design, development, simulation, and integration of these 
devices and the surrounding circuits.  We also evaluate,troubleshoot, 
and improve existing designs. Please call or write for a free 
brochure.

Article: 3820
Subject: Quick question for Model Tech. experts:
From: Kayvon Irani <kirani@cinenet.net>
Date: Tue, 06 Aug 1996 21:06:14 -0700
Links: << >>  << T >>  << A >>
Quick question for Model Tech. experts:

	How do you get around the problem of grouping individual signals to create and
	view a bus on Model Tech? If I start with a signal like counter(7 downto 0)
	and go through synthesis and place and route my final netlist now has eight
	individual signals representing counter(7 downto 0). Since Model Tech does 	
	not have the capablity to group signals; what'd be an easy way to
	group them back together at the netlist level?

	Regards,
	Kayvon Irani
	Lear Astronics
Article: 3821
Subject: Problem With Xilinx/Viewlogic PROwave
From: Mark Garaway <mgaraway@deltanet.com>
Date: Tue, 06 Aug 1996 21:17:29 -0700
Links: << >>  << T >>  << A >>
I'm using Xilinx's Xact 6.0 development set with the Viewlogic tools.  It
was my customer's choice.  My problem is with the PROwave waveform display and editor
tool. It seems to change the sequence of signals I specify in the PROsim wave command and
displays them in a different apparently random fashion.  For example, I say wave xyz.wfm a
b c d in PROsim and PROwave displays the signals as d a c b or something different each
time I run a simulation.  Any help is greatly appreciated.  It would sure be nice to see
the simulation waveforms the way I want them.  I you think the rest of the news group
would benefit from an answer please post the reply here otherwise e-mail is fine.

Regards,
Mark Garaway
mgaraway@deltanet.com
Article: 3822
Subject: Re: Xilinx/FPGA Timing Problems
From: Scott Kroeger <Scott.Kroeger@mei.com>
Date: Tue, 06 Aug 1996 22:21:56 -0600
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> ft63@dial.pipex.com (Peter) wrote:
> >
> [stuff deleted]
> 
> > But I have more often come across a nastier problem, common to all
> > FPGAs: say you have a 16-bit shift register. Obviously, for a SR to
> > work, the clock skew stage-to-stage has to be less than the clock-to-Q
> > propagation delay. IOW, you ideally want to clock all the stages
> > together.
> 
> True.  Use the global clock to minimize skew.
> >
> 
> [stuff deleted]
> 
> > The "proper" way to do this is to use one of the global clock nets to
> > clock all the D-types, and use clock enables to decide which actually
> > get clocked. Of course, in my above SR example, they all get clocked
> > together anyway, but you may still need to gate the clocks, otherwise
> > the SR will be shifting all the time!
> >
> > Unless I am oversimplifying your problem, it is possible that this is
> > what you are seeing. Even if you do everything "synchronous", this is
> > where you get caught.
> >
> If you are gating clocks you are not synchronous!  The right way to
> do this is to create an enable in the logic using feedback. This uses
> up two variables to the LUT but it is fast and avoids any clock skew
> problems. If you must gate the clock(avoidable in most cases) you
> should use the clock enable inputs to the CLBs, but beware their use
> can congest routing.

There is no difference between creating an enable in the logic and using 
the clock enable input (which just wraps the ff output back to the ff 
input.)  Using the enable is not the same as gating the clock.  The 
former doesn't change the clock timing as it only controls the feedback 
path.  AFAIK using the CE inputs does not congest routing anymore than 
using a logic contrived CE, unless the signal that drives the CE is 
sourced within the same CLB and therefore doesn't need local 
interconnect.

Regards,
Scott
Article: 3823
Subject: Pin assignments synopsys->Maxplus2?
From: Andreas Doering <doering@iti.mu-luebeck.de>
Date: Wed, 07 Aug 1996 09:46:05 +0200
Links: << >>  << T >>  << A >>
Hello,
I am designung for ALTERA devices (namely EPM9560, EPF10K50) 
using SYNOPSYS-FPGA-compiler and Maxplus2. I want to put 
my pin assignments into the VHDL-source. 
I know that I can edit the .acf file, but Maxplus2-online help tells 
that it can be done using EDIF-properties, too.
Now I do not know how to produce these property entries with 
FPGA compiler. Attributes on the speciphic ports seem to be ignored.
Is there another way to get around (some kind of awk script, 
that extracts the pin assignments and inserts them into the edif file.
I guess this is tedious to write this.
Thanks in advance.
Andreas
-- 
---------------------------------------------------------------
                        Andreas Doering
                        Medizinische Universitaet zu Luebeck
                        Institut fuer Technische Informatik

		        Email: doering@iti.mu-luebeck.de
----------------------------------------------------------------
Article: 3824
Subject: Re: Xilinx/FPGA Timing Problems
From: Alexandr Solovkin <sol@elvis.msk.su>
Date: 7 Aug 1996 10:45:48 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <randraka@ids.net> wrote:
>ft63@dial.pipex.com (Peter) wrote:
>>
>[stuff deleted] 
>
>> But I have more often come across a nastier problem, common to all
>> FPGAs: say you have a 16-bit shift register. Obviously, for a SR to
>> work, the clock skew stage-to-stage has to be less than the clock-to-Q
>> propagation delay. IOW, you ideally want to clock all the stages
>> together.
>
>True.  Use the global clock to minimize skew.

You may manually route clock back to the data flow.
So, if data goes from 1 to 16 register, clock goes to clock16 !before!
then to clock15 and so on. This kills your problem.

Best regards.
Alex



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