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 33575

Article: 33575
Subject: Re: finite defect statistics
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Mon, 30 Jul 2001 20:56:47 GMT
Links: << >>  << T >>  << A >>
Josh,

In addition to what Ray says, are you sure your printed-circuit boards
are good?  Have you done any sort of signal-integrity simulation on
them?  Since you indicate that you're changing your clock speeds, what
sort of clock generator are you using?  Do you have a proper
clock-distribution tree on your boards? Please tell me your boards are
not wire-wrapped.

Just because you run at reduced clock speeds doesn't mean you don't have
to worry about edge rates.

How about your power-supply distribution? Decoupling?

Are your parts socketed?  

Say, for instance, you worked for a commercial company, and you put an
FPGA on a board, and you shipped 100,000 boards.  This means that your
customer service group would be dealing with 2,000 returned products. 
Methinks your manager would not only fire you, he'd shoot you in the
face with a bazooka*.

-andy

* Thanks to Bill Cosby for the bazooka line.

"B. Joshua Rosen" wrote:
> 
> I've got these figures based on the tests that I have written for an
> ASIC emulator company. Each box has hundreds of FPGAs so we would typically
> find several bad FPGAs per system. I don't have exact figures for the
> Virtex family, although they seem to be better than the 4000
> family, but the 1 in 50 number held for various incarnations of the
> 5200 and 4000 series. My tests do not violate any timing restrictions, in fact we
> run them at various clock rates and failures happen at the lowest speeds
> as well as for the higher speeds. Before adding these tests we would
> frequently run into problems with customer patterns, now that's much
> much rarer although it can still happen occasionally. Even with about 150
> test patterns we are only getting coverage of 93% of the PIPs, although
> the coverage of the PIPs that we actually use is probably closer to 99%.
> Xilinx has added tests to their test suites which use the same methodology as
> my tests and it does seem that the Virtex parts have a lower fallout than
> the older families. I've also used a Xilinx internal tool to determine
> what my coverage is. I could be wrong about the chances of a particular
> pattern hitting a defect but I'm not wrong about defect rate. With my
> test patterns I will generally see 2 or 3 patterns fail on a bad part
> out of a suite of approximately 150. However my patterns are designed for
> maximum coverage, it's possible that a typical pattern has only a 1 on
> 500 chance of seeing the defect as opposed to the 1 in 50 that I see. So
> if 1 in 50 parts has a defect and 1 in 500 patterns hits it then you
> would see a 1 in 25000 fallout in real systems. If my test patterns are
> closer to the real world then the system fallout rate would be 1 in 2500.
> Either way the system fallout rate is low enough that you wouldn't notice
> it. Also without a test suite like I wrote for the emulator company you
> would have no way of knowing that it was the FPGA that caused the
> problem, the board will simply be declared a dog and tossed aside on the
> dog board pile.
> 
> In article <3B649C58.D09F96FC@andraka.com>, "Ray Andraka"
> <ray@andraka.com> wrote:
> 
> > Where are you getting these numbers from?  My experience with FPGAs over
> > the past 13 years and several hundred designs certainly doesn't support
> > such numbers.   Is it possible you might have been violating timing???
> > What devices were you testing?
> >
> > "B. Joshua Rosen" wrote:
> >
> >> Date codes don't matter it's really a random process that causes
> >> problems. Having several boards is certainly useful in development but
> >> you would probably do that anyway. As I say the chances of actually
> >> hitting a problem are low, but if you go through 10 ro 20 spins you
> >> will likely have a one in a few hundred chance of hitting a defective
> >> switch.
> >>
> >> Josh
> >>
> >> In article <3B6477B1.575B@designtools.co.nz>, "Jim Granville"
> >> <jim.granville@designtools.co.nz> wrote:
> >>
> >> > B. Joshua Rosen wrote:
> >> >>
> >> >> The coverage that the FPGA vendors provide is less than perfect but
> >> >> it's good enough for most applications. In my experience, writing
> >> >> FPGA test programs for an ASIC emulator manufacturer, about 1 in 50
> >> >> FPGAs have some defect although the chance of any one pattern
> >> >> running into that defect is in the neighborhood of 1 in 100. As a
> >> >> result the chance that any one pattern will have a problem on any
> >> >> particular FPGA is about 1 in 5000. As you raise the number of
> >> >> patterns that you run on a particular FPGA the chances that you will
> >> >> run into a problem approached the 1 in 50 number.
> >> >>
> >> >> The way that you test FPGAs is different then the way that you test
> >> >> an ASIC. FPGAs are mostly interconnect which makes them harder to
> >> >> test. On the other hand because they are soft you can run an
> >> >> unlimited number of different test patterns on them, which
> >> >> simplifies the problem as compared to an ASIC. If you are concerned
> >> >> about shipping an FPGA with a hidden defect then the way that you
> >> >> solve it is to run a large number of test patterns on your FPGAs and
> >> >> throw out the bad ones.
> >> > <snip>
> >> >
> >> >  Very interesting stats.
> >> > Besides shipping product, this also has issues for development
> >> > itself.
> >> >  With a 1:50 chance of a defect, it would make sense to have two,
> >> > or maybe three, (and probably with different date codes), test boards
> >> > that are called on for second opinions when a curly fault arises.
> >> >  As these boards rack up more 'passes', they increase in value :-)
> >> >
> >> >  Sounds like the tools could benefit from a 'randomise' switch
> >> > - or maybe a start-from-other-corner placement alogrithm ?
> >> >
> >> > -jg
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc. 401/884-7930     Fax
> > 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com
> >
> >

Article: 33576
Subject: Re: Xilinx/Altera "behavioral" verilog
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 30 Jul 2001 23:57:22 +0100
Links: << >>  << T >>  << A >>


Paul Smart wrote:

> Hi Rick,
> I have the TestBench product guys at IBM telling me that the output
> from the ngd2ver is "behavioral", not "structural".
> Paul
>
> On Fri, 27 Jul 2001 19:17:38 +0100, Rick Filipkiewicz
> <rick@algor.co.uk> wrote:
>

I'm not sure, then, what your guys mean by structural. I always thought it
means a huge list of instantiations of models for the ASIC/FPGAs primitive
elements. If that's so then that's what NGD2VER produces. I just did a quick
grep for ``assign'' & ``always''  and found none.



Article: 33577
Subject: Re: i2c master
From: "kryten_droid" <kryten_droid@ntlworld.com>
Date: Tue, 31 Jul 2001 02:00:34 +0100
Links: << >>  << T >>  << A >>
Dick Ginther <dick.ginther@wavecom.ca> wrote in message
news:r3j97.20$7i.589926@tomcat.sk.sympatico.ca...
> Hi,
>     I'm looking for some open source for a i2c bus master...does anyone
> know of some?

Why? Master behaviour is easy to bit-bash.

Slave behaviour is something well worth doing in hardware though...



Article: 33578
Subject: Re: SRL16
From: Ray Andraka <ray@andraka.com>
Date: Tue, 31 Jul 2001 01:21:31 GMT
Links: << >>  << T >>  << A >>
Yes, there is a difference.  I missed the fact that you were using a Virtex2.  Virtex only allows 1 output from an SRL16, while virtex2 gives you the selected output plus the last tap so it is easier to cascade them.  I am not sure offhand whether the
V2 SRL16 blocks the F5 mux or not.  The place to look is the FPGA editor if you have any doubts.

Huang wrote:

> Ray, thanks a lot for your answer.
>
> What I am trying to do is implementing a circular queque.
> The output of cascaded SRL16 will be modified and loaded as input.
>
> In the Virtex2 handbook chapter2, page 214, a 32bit shift register is implemented as two SELC16E and a MUXF5. Additionally, the verilog template for component instatiation by Xilinx does have a corresponding SRLC32E_MACRO.v, which is synthesisable.
>
> Is there any difference between Virtex and Virtex2 regarding SRL16?

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



Article: 33579
Subject: Re: Xilinx/Altera "behavioral" verilog
From: Ray Andraka <ray@andraka.com>
Date: Tue, 31 Jul 2001 01:47:49 GMT
Links: << >>  << T >>  << A >>


Paul Smart wrote:

> Thanks to all who responded. The following "threads" of thought have
> been discussed (so far):
>
> ----------
> The output of ngd2ver is considered "behavioral" by at least one ATPG
> tool vendor (IBM TestBench product). Some tools can work with
> behavioral verilog, some tools cannot work with non-scan architecture.

It is behavioral in the sense that you can't go back and run that vhdl
through the tools to regenerate the design (wrong library).  It doesn't
map directly back into the unisim primitives.


>
>
> ----------
> "Timing errors in placed and routed design"
> This illustrates why the manufacturer cannot 100% test, as he is not
> testing the customers exact placed and routed design. My customer may
> see failures in the system.

If you have timing errors in the placed and routed design, the static
timing analyzer will find them, provided you have sufficiently constrained
the design.  Places to look out for: multiple or gated clocks, crossing
clock domains, clock skew introduced by not using clock nets, set-up and
hold (offsets) to I/o pins.  If the analyzer shows timing errors, it may
work in the lab, but I'll guarantee that if you make enough of them you'll
see some of them back from the customer (unless it is a path that you've
determined is not a problem, of course)

>
>
> ----------
> "Manufacturers do the testing for you"
> Shortcuts *may* be taken by the FPGA manufacturer to reduce the cost
> of test, and the customers design can never be 100% tested for (unless
> it is one of the test designs, and is a 100% testable design). My
> customer may see failures in the system.

The reconfigurability of the devices does allow close to 100% testing of
the pips, switch boxes and LUTs.   Adding scan to the internal logic of
the FPGA is expensive and yields very little benefit, as you can (and the
manufacturers do) easily use reconfigurability to get at any pip,
switchbox, LUT, flip-flop, carry chain element etc in the design.

>
>
> ----------
> "Parts are not 100% testable (absence of scan or other DFT tools)"
> " DPM levels"
>
> My customer is in the following categories:
> -Comparatively high volume of FPGA's per board/system
> -Comparatively low volume of systems
> -Extremely high system reliability requirements

Sounds pretty typical...

>
>
> My customer DOES see significant failures in boards/system (100's of
> devices per month)

Sounds like you have a design problem you haven't properly diagnosed.  I'd
check very carefully that a) your static timing analysis has full coverage
of the design, b) you don't have any timing failures, c) you aren't having
a problem with crossing clock domain boundaries improperly, d) your input
clocks are clean, e) you've distributed clocks on the clock networks, not
on general routing (your aren't gateing clocks, right?), f) your power
supplies are solid and properly bypassed, etc.   Also, make sure you are
using the latest timing files for your timing analysis.  Refinements in
the characterization have required adjustments to the timing parameters(in
both directions).

Again, across literally hundreds of designs, I have yet to see a failure
caused by a device defect that was not a result of abusing the part
(overstressing temp or voltage)  or a silicon bug (in which case the error
is the same on every device).

Could you tell us which devices you have experienced these problems with?
Have you isolated the problems to particular structures in the FPGA?  I
suspect not, rather I am guessing you fail a board, then run a homespun
test that also fails so you assume the chip is bad.  Is there any way you
can post the details of your testing so that others can substantiate or
refute your claims?  Have the manufacturers of the chips involved had a
chance to review your test setup and results?  If so what are their
comments?

>
>
> They experience DPM from
> 300-500 (reasonable)
> 1000-5000 (painful)
> 5000-10,000 (extreme production impact)
>
> These failures are uncovered during the thorough board level and
> system level testing perfomed during manufacturing.
>
> DPM in the 1000 to 2000 range are common.
>
> They have seen as high as 50,000 DPM in an extreme case (design
> routing problem (caused by software?) was identified).
>
> Die steps and new generation devices see higher failure rates
> initially, and then scale back over time (product maturity?).
>
> Many  of the failed components cannot be verified as rejects by the
> manufacturer (the manufacturers test methods missed the problem). This
> applies to both X and A, my customer is a large user of both.

>
>
> ----------
> My ideal first goal would be to have the verilog output from the tools
> be  directly usable with existing ASIC ATPG tools, specifically those
> that can work with non scan designs. It is not a final solution, but
> it is a step in the right direction.
>
> DFT tools for FPGA might be the next step. Given that this problem
> does not significantly affect all users of FPGAs, I don't know how
> reasonable it is to expect such tools to become a reality in the near
> future.
>
> My end goal is to test and remove as many defects as possible at the
> component level, before my customer places them on a board. It remains
> to be seen how we will get there.

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



Article: 33580
Subject: Re: finite defect statistics
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Mon, 30 Jul 2001 22:00:58 -0400
Links: << >>  << T >>  << A >>
These failures occur both on board and on chiptesters. My client has
Xilinx prescreen FPGAs on a chiptester using a subset of my test patterns
(approximately 40 out of the 150). The fall out rate on the chiptester is
consistant to what we were seeing on boards before we were doing
prescreening. The screened parts have much lower on board failure rates
because the prescreening find about 90% of the bad parts. The full test
suite finds the remaining bad parts. The reason for not running the full
suite on the tester has to do with test time limitations. 

I can't post my methodology on the net, it's proprietary to my client.
However I have spent time with Xilinx's test group discussing my
techniques and they agree that they are sound.  More to the point
Xilinx is using a similar strategy to test the Virtex parts. 

To answer your question about variable clock speeds, the clocks are PLL
based and designed to be variable. The clock tree's are extremely well
controlled and are not the source of any of these internal problems. The
systems that these FPGAs are in are million dollar ASIC emulators, they
are not garage shop kluges. Also I've been implementing variations of
these test patterns for multiple incarnations of the system going back to
1994. The FPGAs that have been used are the 5212, 4013, 4036e, 4062xl and
the XCV800. The failure rates have been fairly consistant over the years
across the various generations of FPGAs, although I think that the rates
are somewhat lower for the Virtex parts.

Josh

In article <jSj97.8011$bl1.1229433@newsread1.prod.itd.earthlink.net>,
"Andy Peters <andy [@] exponentmedia" <".> wrote:

> Josh,
> 
> In addition to what Ray says, are you sure your printed-circuit boards
> are good?  Have you done any sort of signal-integrity simulation on
> them?  Since you indicate that you're changing your clock speeds, what
> sort of clock generator are you using?  Do you have a proper
> clock-distribution tree on your boards? Please tell me your boards are
> not wire-wrapped.
> 
> Just because you run at reduced clock speeds doesn't mean you don't have
> to worry about edge rates.
> 
> How about your power-supply distribution? Decoupling?
> 
> Are your parts socketed?
> 
> Say, for instance, you worked for a commercial company, and you put an
> FPGA on a board, and you shipped 100,000 boards.  This means that your
> customer service group would be dealing with 2,000 returned products.
> Methinks your manager would not only fire you, he'd shoot you in the
> face with a bazooka*.
> 
> -andy
> 
> * Thanks to Bill Cosby for the bazooka line.
> 
> "B. Joshua Rosen" wrote:
>> 
>> I've got these figures based on the tests that I have written for an
>> ASIC emulator company. Each box has hundreds of FPGAs so we would
>> typically find several bad FPGAs per system. I don't have exact figures
>> for the Virtex family, although they seem to be better than the 4000
>> family, but the 1 in 50 number held for various incarnations of the
>> 5200 and 4000 series. My tests do not violate any timing restrictions,
>> in fact we run them at various clock rates and failures happen at the
>> lowest speeds as well as for the higher speeds. Before adding these
>> tests we would frequently run into problems with customer patterns, now
>> that's much much rarer although it can still happen occasionally. Even
>> with about 150 test patterns we are only getting coverage of 93% of the
>> PIPs, although the coverage of the PIPs that we actually use is
>> probably closer to 99%. Xilinx has added tests to their test suites
>> which use the same methodology as my tests and it does seem that the
>> Virtex parts have a lower fallout than the older families. I've also
>> used a Xilinx internal tool to determine what my coverage is. I could
>> be wrong about the chances of a particular pattern hitting a defect but
>> I'm not wrong about defect rate. With my test patterns I will generally
>> see 2 or 3 patterns fail on a bad part out of a suite of approximately
>> 150. However my patterns are designed for maximum coverage, it's
>> possible that a typical pattern has only a 1 on 500 chance of seeing
>> the defect as opposed to the 1 in 50 that I see. So if 1 in 50 parts
>> has a defect and 1 in 500 patterns hits it then you would see a 1 in
>> 25000 fallout in real systems. If my test patterns are closer to the
>> real world then the system fallout rate would be 1 in 2500. Either way
>> the system fallout rate is low enough that you wouldn't notice it. Also
>> without a test suite like I wrote for the emulator company you would
>> have no way of knowing that it was the FPGA that caused the problem,
>> the board will simply be declared a dog and tossed aside on the dog
>> board pile.
>> 
>> In article <3B649C58.D09F96FC@andraka.com>, "Ray Andraka"
>> <ray@andraka.com> wrote:
>> 
>> > Where are you getting these numbers from?  My experience with FPGAs
>> > over the past 13 years and several hundred designs certainly doesn't
>> > support such numbers.   Is it possible you might have been violating
>> > timing??? What devices were you testing?
>> >
>> > "B. Joshua Rosen" wrote:
>> >
>> >> Date codes don't matter it's really a random process that causes
>> >> problems. Having several boards is certainly useful in development
>> >> but you would probably do that anyway. As I say the chances of
>> >> actually hitting a problem are low, but if you go through 10 ro 20
>> >> spins you will likely have a one in a few hundred chance of hitting
>> >> a defective switch.
>> >>
>> >> Josh
>> >>
>> >> In article <3B6477B1.575B@designtools.co.nz>, "Jim Granville"
>> >> <jim.granville@designtools.co.nz> wrote:
>> >>
>> >> > B. Joshua Rosen wrote:
>> >> >>
>> >> >> The coverage that the FPGA vendors provide is less than perfect
>> >> >> but it's good enough for most applications. In my experience,
>> >> >> writing FPGA test programs for an ASIC emulator manufacturer,
>> >> >> about 1 in 50 FPGAs have some defect although the chance of any
>> >> >> one pattern running into that defect is in the neighborhood of 1
>> >> >> in 100. As a result the chance that any one pattern will have a
>> >> >> problem on any particular FPGA is about 1 in 5000. As you raise
>> >> >> the number of patterns that you run on a particular FPGA the
>> >> >> chances that you will run into a problem approached the 1 in 50
>> >> >> number.
>> >> >>
>> >> >> The way that you test FPGAs is different then the way that you
>> >> >> test an ASIC. FPGAs are mostly interconnect which makes them
>> >> >> harder to test. On the other hand because they are soft you can
>> >> >> run an unlimited number of different test patterns on them, which
>> >> >> simplifies the problem as compared to an ASIC. If you are
>> >> >> concerned about shipping an FPGA with a hidden defect then the
>> >> >> way that you solve it is to run a large number of test patterns
>> >> >> on your FPGAs and throw out the bad ones.
>> >> > <snip>
>> >> >
>> >> >  Very interesting stats.
>> >> > Besides shipping product, this also has issues for development
>> >> > itself.
>> >> >  With a 1:50 chance of a defect, it would make sense to have two,
>> >> > or maybe three, (and probably with different date codes), test
>> >> > boards that are called on for second opinions when a curly fault
>> >> > arises.
>> >> >  As these boards rack up more 'passes', they increase in value :-)
>> >> >
>> >> >  Sounds like the tools could benefit from a 'randomise' switch
>> >> > - or maybe a start-from-other-corner placement alogrithm ?
>> >> >
>> >> > -jg
>> >
>> > --
>> > -Ray Andraka, P.E.
>> > President, the Andraka Consulting Group, Inc. 401/884-7930     Fax
>> > 401/884-7950
>> > email ray@andraka.com
>> > http://www.andraka.com
>> >
>> >

Article: 33581
Subject: Re: How to add carry optimizations
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Tue, 31 Jul 2001 13:32:49 +1000
Links: << >>  << T >>  << A >>
But how do you do a normal add while getting access to the right
carry bits?

John_H wrote:
> 
> You're trying to do all the work for the synthesizer by telling it how to
> perform addition.
> Let the synthesizer to the addition - you just concentrate on the saturable
> aspect.
> Leonardo spectrum should get all the carry chains together fine because it
> know how to utilize them to add.
> 
> Russell Shaw wrote:
> 
> > Hi all,
> >
> > I made this saturable adder from converting AHDL code in a previous
> > message.
> >
> > It adds signed HEX numbers together, but doesn't roll-over if there's
> > an overflow.
> >
> > I'm using leonardo-spectrum to generate an edif netlist, which is
> > compiled by altera maxplus2.
> >
> > Where and how, if any, can i add technology-dependent optimizations
> > such as carry chains etc?
> >
> > Also, are there such things as VHDL debuggers where you can single-
> > step thru the code and see what all the signals and variables are
> > doing?
> >
> > LIBRARY ieee;
> > USE ieee.std_logic_1164.all;
> >
> > PACKAGE types IS
> >   subtype word is std_ulogic_vector(3 downto 0);
> > END types;
> >
> > LIBRARY ieee;
> > USE ieee.std_logic_1164.all;
> > use work.types.all;
> >
> > ENTITY saturable_adder IS
> > port(
> >   a,b: in word;
> >   s:   out word
> >      );
> > END adder;
> >
> > LIBRARY ieee;
> > USE ieee.std_logic_1164.all;
> > use work.types.all;
> >
> > ARCHITECTURE total OF saturable_adder IS
> > BEGIN
> >   behav: PROCESS (a,b) is
> >   variable sum: word;
> >   variable carry_in,carry_out: std_ulogic;
> >   constant msb:integer:=word'left;
> >
> >   BEGIN
> >     carry_in:='0';
> >     for ndx in 0 to (word'left-1) loop
> >       sum(ndx):=a(ndx) xor b(ndx) xor carry_in;
> >       carry_out:=(a(ndx) and b(ndx)) or (a(ndx) and carry_in) or (b(ndx)
> > and carry_in);
> >       carry_in:=carry_out;
> >     end loop;
> >     sum(msb):=a(msb) xor b(msb) xor carry_in;
> >     if( (a(msb) and b(msb) and not carry_in)='1' )
> >     then
> >       sum:=(others=>'0');
> >       sum(msb):='1';
> >     elsif( (not a(msb) and not b(msb) and carry_in)='1' )
> >     then
> >       sum:=(others=>'1');
> >       sum(msb):='0';
> >     end if;
> >     s<=sum;
> >   END PROCESS behav;
> > END total;
> >

--
   ___                                           ___
  /  /\                                         /  /\
 /  /__\ Russell Shaw, B.Eng, M.Eng(Research)  /  /\/\
/__/   / Victoria, Australia, Down-Under      /__/\/\/
\  \  /  http://home.iprimus.com.au/rjshaw    \  \/\/
 \__\/                                         \__\/

Article: 33582
Subject: Re: Webpack Tutorials
From: "Srinivasan Venkataramanan" <svenka3@siliconsystems.co.in>
Date: Tue, 31 Jul 2001 12:22:44 +0530
Links: << >>  << T >>  << A >>
Hi,
  Try the one from XESS, kind-of-beginner's guide.

HTH,
Srini

http://www.xess.com/appnotes/webpack-1_5.pdf

--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India


"Dave Feustel" <dfeustel@mindspring.com> wrote in message
news:9k4hdk$a4g$1@slb5.atl.mindspring.net...
> I've got Webpack download and installed.
> Where can I find tutorials that will show
> me how to use the software?
>
> Thanks,
>
> Dave Feustel
>
>



Article: 33583
Subject: Re: i2c master
From: Ingmar Hohmann <i.hohmann@seh.de>
Date: Tue, 31 Jul 2001 09:29:06 +0200
Links: << >>  << T >>  << A >>
Have a look to:

http://www.opencores.org/projects.shtml

By Ingmar

Dick Ginther schrieb:

> Hi,
>     I'm looking for some open source for a i2c bus master...does anyone
> know of some?
>     Thanks.

--
___________________________________________________________________

Ingmar Hohmann                    mailto:ih@seh.de
SEH Computertechnik GmbH          http://www.seh.de
Suedring 11        Fax:  +49 521 94226 99
D-33647 Bielefeld                 Phone:+49 521 94226 63
GERMANY
__________________________________________________________________



Article: 33584
Subject: Re: i2c master
From: "kryten_droid" <kryten_droid@ntlworld.com>
Date: Tue, 31 Jul 2001 09:03:17 +0100
Links: << >>  << T >>  << A >>
Dick Ginther <dick.ginther@wavecom.ca> wrote in message
news:r3j97.20$7i.589926@tomcat.sk.sympatico.ca...
> Hi,
>     I'm looking for some open source for a i2c bus master...does anyone
> know of some?

Why? Master behaviour is easy to bit-bash.

Slave behaviour is something well worth doing in hardware though...





Article: 33585
Subject: Re: ERROR
From: Nicolas Matringe <nicolas.matringe@IPricot.com>
Date: Tue, 31 Jul 2001 10:38:00 +0200
Links: << >>  << T >>  << A >>
Tomek a écrit :
> 
> Hi
> I have a problem. I have XILINX Foundation Software v1.3 . I
> have FLEXlm license. I work under Windows NT.
> When I want to create ".bit" file I have error:
> 
> map -p xc4005xl-3-pc84 -o map.ncd ../xc4000xl.ngd vgatst.pcf
> map:  version M1.3.7
> Copyright (c) 1995-1997 Xilinx, Inc.  All rights reserved.
> 
> par -w -l 4 -d 0 map.ncd vgatst.ncd vgatst.pcf
> PAR: Xilinx Place And Route M1.3.7.
> Copyright (c) 1995-1997 Xilinx, Inc.  All rights reserved.
> 
> ERROR:baspw:110 - Cannot find Input file "map.ncd".  Please
> verify that your paths and permissions are properly set for
> this file.

Hi
Are you sure the map.ncd file exists? If the mapper fails it won't
generate anything and the placer will give you such an error. Have a
look at the mapper report (*.mrp)

-- 
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 11      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/

Article: 33586
Subject: RAM - VHDL - Altera,...
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Tue, 31 Jul 2001 08:55:06 GMT
Links: << >>  << T >>  << A >>
A never ending problem! Trying to get RAMs in my design so that there is
not to much vendor specific code.
For Altera I'm using Leonardo and Max+plus, for Xilinx WebPack.

I need a RAM with rgistered rd and wr address and unregistered data (in/out)
ports.
One version works:
Generate a .tdf file with Altera wizard and declare the component in the
VHDL
code. But now I have .tdf files. I want only VHDL.

Second try: Write it in VHDL: (code attached)
The generated code does not use the registers in the Altera EAB. It
generates
DFFs. Not good for the timing and a waste of resource.

Third try: Instantiate Altera lpm-ram in VHDL (attached as aram.vhd):
Leonardo takes it as black box, but generates a long name with all generics
in the modul name for the edf file and Max+plus does not find this modul!

Lot of time wasted till now. Perhaps someone solved this problem allready.
Thanks

Martin
--
Whant to see the evolution of a Java processor?

         http://www.jopdesign.com



begin 666 ram.vhd
M+2T-"BTM"7)A;2YV:&0-"BTM#0HM+0EI;G1E<FYA;"!M96UO<GD@9F]R($I/
M4#,-"BTM#0HM+2!N;W<@9F]R(%AI;&EN>"!))W9E('1O('5S92!62$1,(#HM
M*0T*+2T-"@T*3&EB<F%R>2!)145%(#L-"G5S92!)145%+G-T9%]L;V=I8U\Q
M,38T+F%L;" [#0IU<V4@245%12YS=&1?;&]G:6-?87)I=&@N86QL(#L-"G5S
M92!)145%+G-T9%]L;V=I8U]U;G-I9VYE9"YA;&P@.PT*#0IE;G1I='D@<F%M
M(&ES#0IG96YE<FEC("AW:61T:" Z(&EN=&5G97(@.CT@,S([(')E9U]W:61T
M:" Z(&EN=&5G97(@.CT@."D[#0IP;W)T("@-"@ED871A"0DZ(&EN('-T9%]L
M;V=I8U]V96-T;W(H=VED=&@M,2!D;W=N=&\@,"D[#0H)=W)A9&1R97-S"3H@
M:6X@<W1D7VQO9VEC7W9E8W1O<BAR96=?=VED=&@M,2!D;W=N=&\@,"D[#0H)
M<F1A9&1R97-S"3H@:6X@<W1D7VQO9VEC7W9E8W1O<BAR96=?=VED=&@M,2!D
M;W=N=&\@,"D[#0H)=W)E;@D).B!I;B!S=&1?;&]G:6,[#0H)8VQO8VL)"3H@
M:6X@<W1D7VQO9VEC.PT*#0H)<0D)"3H@;W5T('-T9%]L;V=I8U]V96-T;W(H
M=VED=&@M,2!D;W=N=&\@,"D-"BD[#0IE;F0@<F%M(#L-"@T*+2T-"BTM"7)E
M9VES=&5R960@=W)A9&1R97-S+"!W<F5N#0HM+0EU;G)E9VES=&5R960@9&EN
M#0HM+0ER96=I<W1E<F5D(')D861D<F5S<PT*+2T)=6YR96=I<W1E<F5D(&1O
M=70-"BTM#0IA<F-H:71E8W1U<F4@<G1L(&]F(')A;2!I<PT*#0H)='EP92!M
M96U?='EP92!I<R!A<G)A>2 H,"!T;R R-34I(&]F('-T9%]L;V=I8U]V96-T
M;W(H=VED=&@M,2!D;W=N=&\@,"D[#0H-"@ES:6=N86P@;65M( D).B!M96U?
M='EP93L-"@T*"7-I9VYA;"!W<F%D9'().B!S=&1?;&]G:6-?=F5C=&]R*')E
M9U]W:61T:"TQ(&1O=VYT;R P*3L-"@ES:6=N86P@<F1A9&1R"3H@<W1D7VQO
M9VEC7W9E8W1O<BAR96=?=VED=&@M,2!D;W=N=&\@,"D[#0H)<VEG;F%L('=R
M7V5N80DZ('-T9%]L;V=I8SL-"@T*"7-I9VYA;"!D;PD).B!S=&1?;&]G:6-?
M=F5C=&]R*'=I9'1H+3$@9&]W;G1O(# I.PT*#0H-"F)E9VEN#0H-"G!R;V-E
M<W,H8VQO8VLI#0IB96=I;@T*"6EF(')I<VEN9U]E9&=E*&-L;V-K*2!T:&5N
M#0H)"7=R861D<B \/2!W<F%D9')E<W,[#0H)"7=R7V5N82 \/2!W<F5N.PT*
M"0ER9&%D9'(@/#T@<F1A9&1R97-S.PT*"65N9"!I9CL-"F5N9"!P<F]C97-S
M.PT*#0IP<F]C97-S*&1A=&$L('=R7V5N82D-"F)E9VEN#0H):68@*'=R7V5N
M82 ]("<Q)RD@=&AE;@T*"0EM96TH8V]N=E]I;G1E9V5R*'5N<VEG;F5D*'=R
M861D<BDI*2 \/2!D871A.PT*"65N9"!I9B [#0IE;F0@<')O8V5S<SL-"@T*
M"61O(#P](&UE;2AC;VYV7VEN=&5G97(H=6YS:6=N960H<F1A9&1R*2DI.PT*
7"7$@/#T@9&\[#0H-"F5N9"!R=&P[#0H`
`
end

begin 666 aram.vhd
M+2T-"BTM"6%R86TN=FAD#0HM+0T*+2T):6YT97)N86P@;65M;W)Y(&9O<B!*
M3U S#0HM+0E697)S:6]N(&9O<B!!;'1E<F$-"BTM#0HM+0T*#0I,:6)R87)Y
M($E%144@.PT*=7-E($E%144N<W1D7VQO9VEC7S$Q-C0N86QL(#L-"G5S92!)
M145%+G-T9%]L;V=I8U]A<FET:"YA;&P@.PT*=7-E($E%144N<W1D7VQO9VEC
M7W5N<VEG;F5D+F%L;" [#0H-"F5N=&ET>2!R86T@:7,-"F=E;F5R:6,@*'=I
M9'1H(#H@:6YT96=E<B Z/2 S,CL@<F5G7W=I9'1H(#H@:6YT96=E<B Z/2 X
M*3L-"G!O<G0@* T*"61A=&$)"3H@:6X@<W1D7VQO9VEC7W9E8W1O<BAW:61T
M:"TQ(&1O=VYT;R P*3L-"@EW<F%D9')E<W,).B!I;B!S=&1?;&]G:6-?=F5C
M=&]R*')E9U]W:61T:"TQ(&1O=VYT;R P*3L-"@ER9&%D9')E<W,).B!I;B!S
M=&1?;&]G:6-?=F5C=&]R*')E9U]W:61T:"TQ(&1O=VYT;R P*3L-"@EW<F5N
M"0DZ(&EN('-T9%]L;V=I8SL-"@EC;&]C:PD).B!I;B!S=&1?;&]G:6,[#0H-
M"@EQ"0D).B!O=70@<W1D7VQO9VEC7W9E8W1O<BAW:61T:"TQ(&1O=VYT;R P
M*0T**3L-"F5N9"!R86T@.PT*#0HM+0T*+2T)<F5G:7-T97)E9"!W<F%D9')E
M<W,L('=R96X-"BTM"75N<F5G:7-T97)E9"!D:6X-"BTM"7)E9VES=&5R960@
M<F1A9&1R97-S#0HM+0EU;G)E9VES=&5R960@9&]U= T*+2T-"F%R8VAI=&5C
M='5R92!R=&P@;V8@<F%M(&ES#0H-"@E#3TU03TY%3E0@86QT9'!R86T-"@E'
M14Y%4DE#("@-"@D)=VED=&@)"3H@3D%455)!3#L-"@D)=VED=&AA9 D).B!.
M05154D%,.PT*"0EI;F1A=&%?<F5G"0DZ(%-44DE.1SL-"@D)=W)A9&1R97-S
M7W)E9PD).B!35%))3D<[#0H)"7=R8V]N=')O;%]R96<)"3H@4U1224Y'.PT*
M"0ER9&%D9')E<W-?<F5G"0DZ(%-44DE.1SL-"@D)<F1C;VYT<F]L7W)E9PD)
M.B!35%))3D<[#0H)"6]U=&1A=&%?<F5G"0DZ(%-44DE.1SL-"@D):6YD871A
M7V%C;'()"3H@4U1224Y'.PT*"0EW<F%D9')E<W-?86-L<@D).B!35%))3D<[
M#0H)"7=R8V]N=')O;%]A8VQR"0DZ(%-44DE.1SL-"@D)<F1A9&1R97-S7V%C
M;'()"3H@4U1224Y'.PT*"0ER9&-O;G1R;VQ?86-L<@D).B!35%))3D<[#0H)
M"6]U=&1A=&%?86-L<@D).B!35%))3D<[#0H)"6QP;5]F:6QE"0DZ(%-44DE.
M1SL-"@D);'!M7VAI;G0)"3H@4U1224Y'#0H)*3L-"@E03U)4("@-"@D)"7=R
M96X).B!)3B!35$1?3$]'24,@.PT*"0D):6YC;&]C:PDZ($E.(%-41%],3T=)
M0R [#0H)"0EQ"3H@3U54(%-41%],3T=)0U]614-43U(@*#,Q($1/5TY43R P
M*3L-"@D)"61A=&$).B!)3B!35$1?3$]'24-?5D5#5$]2("@S,2!$3U=.5$\@
M,"D[#0H)"0ER9&%D9')E<W,).B!)3B!35$1?3$]'24-?5D5#5$]2("@W($1/
M5TY43R P*3L-"@D)"7=R861D<F5S<PDZ($E.(%-41%],3T=)0U]614-43U(@
M*#<@1$]73E1/(# I#0H)*3L-"@E%3D0@0T]-4$].14Y4.PT*#0HM+0EA='1R
M:6)U=&4@;F]O<'0Z(&)O;VQE86X[#0HM+0EA='1R:6)U=&4@;F]O<'0@;V8@
M86QT9&)R86TZ(&-O;7!O;F5N="!I<R!T<G5E.PT*#0IB96=I;@T*+2T)<2 @
M(" \/2!S=6)?=VER93 H,S$@1$]73E1/(# I.PT*#0H-"@EA;'1D<')A;5]C
M;VUP;VYE;G0@.B!A;'1D<')A;0T*"4=%3D5224,@34%0("@-"@D)5TE$5$@@
M/3X@,S(L#0H)"5=)1%1(040@/3X@."P-"@D)24Y$051!7U)%1R ]/B B54Y2
M14=)4U1%4D5$(BP-"@D)5U)!1$1215-37U)%1R ]/B B24Y#3$]#2R(L#0H)
M"5=20T].5%)/3%]214<@/3X@(DE.0TQ/0TLB+ T*"0E21$%$1%)%4U-?4D5'
M(#T^("))3D-,3T-+(BP-"@D)4D1#3TY44D],7U)%1R ]/B B24Y#3$]#2R(L
M#0H)"4]55$1!5$%?4D5'(#T^(")53E)%1TE35$52140B+ T*"0E)3D1!5$%?
M04-,4B ]/B B3T9&(BP-"@D)5U)!1$1215-37T%#3%(@/3X@(D]&1B(L#0H)
M"5=20T].5%)/3%]!0TQ2(#T^(")/1D8B+ T*"0E21$%$1%)%4U-?04-,4B ]
M/B B3T9&(BP-"@D)4D1#3TY44D],7T%#3%(@/3X@(D]&1B(L#0H)"4]55$1!
M5$%?04-,4B ]/B B3T9&(BP-"@D)3%!-7T9)3$4@/3X@(D,Z+W5S<B]C<'4O
M:F]P,R]R86TN;6EF(BP-"@D)3%!-7TA)3E0@/3X@(E5315]%04(]3TXB#0H)
M*0T*"5!/4E0@34%0("@-"@D)=W)E;B ]/B!W<F5N+ T*"0EI;F-L;V-K(#T^
M(&-L;V-K+ T*"0ED871A(#T^(&1A=&$L#0H)"7)D861D<F5S<R ]/B!R9&%D
M9')E<W,L#0H)"7=R861D<F5S<R ]/B!W<F%D9')E<W,L#0HM+0D)<2 ]/B!S
E=6)?=VER93 -"@D)<2 ]/B!Q#0H)*3L-"@T*96YD(')T;#L-"@``
`
end


Article: 33587
Subject: Re: multi-context FPGA
From: "Cemal Coemert (TIP)" <coemert@fokus.gmd.de>
Date: Tue, 31 Jul 2001 12:04:21 +0200
Links: << >>  << T >>  << A >>
Take a look at:

http://www.chameleonsystems.com/what/RCP_Product_Brief.pdf



Reiner Hartenstein wrote:

> Hi, colleague,
>
> are there multi context FPGAs on the market
> having 2 or 4 banks of configuration memory ?
>
> Reiner





Article: 33588
Subject: Re: finite defect statistics
From: Ray Andraka <ray@andraka.com>
Date: Tue, 31 Jul 2001 12:58:38 GMT
Links: << >>  << T >>  << A >>
Can you give us any more detail as to the exact nature of the failures, and
any back up you might have to substantiate it?  Have you pinpointed the
failures to specific nodes in a part, and then verified that that node still
fails with a different test circuit designed specifically to exercise the
'bad' node?   No trying to be a pain, but I've seen some pretty bad design in
very expensive equipment over the years.  Seems that the poorer the design,
the more likely the designer is to blame the chip.  There are an awful lot of
mediocre designers out there, and they don't just inhabit garages (in fact, on
average I'd venture to say that the small shops tend to crank out better
designs...they tend to hire the cream of the crop).  The fact that it fails on
a chip tester as well as on the board just tells me that there is a problem
with design you are putting in the FPGA to test it.  Again, if the failure
rates were even a 10th of what you are claiming, I would have expected to see
a couple over my career, and would have expected a huge outcry here and in the
press.

"B. Joshua Rosen" wrote:

> These failures occur both on board and on chiptesters. My client has
> Xilinx prescreen FPGAs on a chiptester using a subset of my test patterns
> (approximately 40 out of the 150). The fall out rate on the chiptester is
> consistant to what we were seeing on boards before we were doing
> prescreening. The screened parts have much lower on board failure rates
> because the prescreening find about 90% of the bad parts. The full test
> suite finds the remaining bad parts. The reason for not running the full
> suite on the tester has to do with test time limitations.
>
> I can't post my methodology on the net, it's proprietary to my client.
> However I have spent time with Xilinx's test group discussing my
> techniques and they agree that they are sound.  More to the point
> Xilinx is using a similar strategy to test the Virtex parts.
>
> To answer your question about variable clock speeds, the clocks are PLL
> based and designed to be variable. The clock tree's are extremely well
> controlled and are not the source of any of these internal problems. The
> systems that these FPGAs are in are million dollar ASIC emulators, they
> are not garage shop kluges. Also I've been implementing variations of
> these test patterns for multiple incarnations of the system going back to
> 1994. The FPGAs that have been used are the 5212, 4013, 4036e, 4062xl and
> the XCV800. The failure rates have been fairly consistant over the years
> across the various generations of FPGAs, although I think that the rates
> are somewhat lower for the Virtex parts.
>
> Josh
>
> In article <jSj97.8011$bl1.1229433@newsread1.prod.itd.earthlink.net>,
> "Andy Peters <andy [@] exponentmedia" <".> wrote:
>
> > Josh,
> >
> > In addition to what Ray says, are you sure your printed-circuit boards
> > are good?  Have you done any sort of signal-integrity simulation on
> > them?  Since you indicate that you're changing your clock speeds, what
> > sort of clock generator are you using?  Do you have a proper
> > clock-distribution tree on your boards? Please tell me your boards are
> > not wire-wrapped.
> >
> > Just because you run at reduced clock speeds doesn't mean you don't have
> > to worry about edge rates.
> >
> > How about your power-supply distribution? Decoupling?
> >
> > Are your parts socketed?
> >
> > Say, for instance, you worked for a commercial company, and you put an
> > FPGA on a board, and you shipped 100,000 boards.  This means that your
> > customer service group would be dealing with 2,000 returned products.
> > Methinks your manager would not only fire you, he'd shoot you in the
> > face with a bazooka*.
> >
> > -andy
> >
> > * Thanks to Bill Cosby for the bazooka line.
> >
> > "B. Joshua Rosen" wrote:
> >>
> >> I've got these figures based on the tests that I have written for an
> >> ASIC emulator company. Each box has hundreds of FPGAs so we would
> >> typically find several bad FPGAs per system. I don't have exact figures
> >> for the Virtex family, although they seem to be better than the 4000
> >> family, but the 1 in 50 number held for various incarnations of the
> >> 5200 and 4000 series. My tests do not violate any timing restrictions,
> >> in fact we run them at various clock rates and failures happen at the
> >> lowest speeds as well as for the higher speeds. Before adding these
> >> tests we would frequently run into problems with customer patterns, now
> >> that's much much rarer although it can still happen occasionally. Even
> >> with about 150 test patterns we are only getting coverage of 93% of the
> >> PIPs, although the coverage of the PIPs that we actually use is
> >> probably closer to 99%. Xilinx has added tests to their test suites
> >> which use the same methodology as my tests and it does seem that the
> >> Virtex parts have a lower fallout than the older families. I've also
> >> used a Xilinx internal tool to determine what my coverage is. I could
> >> be wrong about the chances of a particular pattern hitting a defect but
> >> I'm not wrong about defect rate. With my test patterns I will generally
> >> see 2 or 3 patterns fail on a bad part out of a suite of approximately
> >> 150. However my patterns are designed for maximum coverage, it's
> >> possible that a typical pattern has only a 1 on 500 chance of seeing
> >> the defect as opposed to the 1 in 50 that I see. So if 1 in 50 parts
> >> has a defect and 1 in 500 patterns hits it then you would see a 1 in
> >> 25000 fallout in real systems. If my test patterns are closer to the
> >> real world then the system fallout rate would be 1 in 2500. Either way
> >> the system fallout rate is low enough that you wouldn't notice it. Also
> >> without a test suite like I wrote for the emulator company you would
> >> have no way of knowing that it was the FPGA that caused the problem,
> >> the board will simply be declared a dog and tossed aside on the dog
> >> board pile.
> >>
> >> In article <3B649C58.D09F96FC@andraka.com>, "Ray Andraka"
> >> <ray@andraka.com> wrote:
> >>
> >> > Where are you getting these numbers from?  My experience with FPGAs
> >> > over the past 13 years and several hundred designs certainly doesn't
> >> > support such numbers.   Is it possible you might have been violating
> >> > timing??? What devices were you testing?
> >> >
> >> > "B. Joshua Rosen" wrote:
> >> >
> >> >> Date codes don't matter it's really a random process that causes
> >> >> problems. Having several boards is certainly useful in development
> >> >> but you would probably do that anyway. As I say the chances of
> >> >> actually hitting a problem are low, but if you go through 10 ro 20
> >> >> spins you will likely have a one in a few hundred chance of hitting
> >> >> a defective switch.
> >> >>
> >> >> Josh
> >> >>
> >> >> In article <3B6477B1.575B@designtools.co.nz>, "Jim Granville"
> >> >> <jim.granville@designtools.co.nz> wrote:
> >> >>
> >> >> > B. Joshua Rosen wrote:
> >> >> >>
> >> >> >> The coverage that the FPGA vendors provide is less than perfect
> >> >> >> but it's good enough for most applications. In my experience,
> >> >> >> writing FPGA test programs for an ASIC emulator manufacturer,
> >> >> >> about 1 in 50 FPGAs have some defect although the chance of any
> >> >> >> one pattern running into that defect is in the neighborhood of 1
> >> >> >> in 100. As a result the chance that any one pattern will have a
> >> >> >> problem on any particular FPGA is about 1 in 5000. As you raise
> >> >> >> the number of patterns that you run on a particular FPGA the
> >> >> >> chances that you will run into a problem approached the 1 in 50
> >> >> >> number.
> >> >> >>
> >> >> >> The way that you test FPGAs is different then the way that you
> >> >> >> test an ASIC. FPGAs are mostly interconnect which makes them
> >> >> >> harder to test. On the other hand because they are soft you can
> >> >> >> run an unlimited number of different test patterns on them, which
> >> >> >> simplifies the problem as compared to an ASIC. If you are
> >> >> >> concerned about shipping an FPGA with a hidden defect then the
> >> >> >> way that you solve it is to run a large number of test patterns
> >> >> >> on your FPGAs and throw out the bad ones.
> >> >> > <snip>
> >> >> >
> >> >> >  Very interesting stats.
> >> >> > Besides shipping product, this also has issues for development
> >> >> > itself.
> >> >> >  With a 1:50 chance of a defect, it would make sense to have two,
> >> >> > or maybe three, (and probably with different date codes), test
> >> >> > boards that are called on for second opinions when a curly fault
> >> >> > arises.
> >> >> >  As these boards rack up more 'passes', they increase in value :-)
> >> >> >
> >> >> >  Sounds like the tools could benefit from a 'randomise' switch
> >> >> > - or maybe a start-from-other-corner placement alogrithm ?
> >> >> >
> >> >> > -jg
> >> >
> >> > --
> >> > -Ray Andraka, P.E.
> >> > President, the Andraka Consulting Group, Inc. 401/884-7930     Fax
> >> > 401/884-7950
> >> > email ray@andraka.com
> >> > http://www.andraka.com
> >> >
> >> >

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



Article: 33589
Subject: Schematic user info
From: "Noddy" <g9731642@campus.ru.ac.za>
Date: Tue, 31 Jul 2001 15:13:25 +0200
Links: << >>  << T >>  << A >>
Sorry, just an administrative question. Could someone please tell me how to
manually adjust the user info that appears at the bottom right-hand corner
of a schematic diagram in the Xilinx Foundation software?

Adrian




Article: 33590
Subject: Re: How to add carry optimizations
From: Ray Andraka <ray@andraka.com>
Date: Tue, 31 Jul 2001 13:33:12 GMT
Links: << >>  << T >>  << A >>
For a saturating adder, sign extend the inputs by one bit more than you need for
your output, then if the top two output bits don't match you substitute the
overflow value.  The Xilinx 4K was neat because with the carry chain in front of
the logic, you could include the mux in the adder logic to get the whole thing in
1 lut per bit.  Here is an RTL version that avoids having to construct the whole
thing.  I just typed this out, and it has not been tested so use at your own
risk.  Incidently, there are times when a structural construction is
advantageous:  it allows you to put placement in your code, and can also be used
to enforce a specific structure.  The synthesis tools do fine with basic adders,
subtractors and counters.  They can be more troublesome when you try to add
functions (for example an adder/subtractor with one input gated), in that the
synthesis may not turn out the optimal solution.

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

entity sat_add is
 port(
    a: in std_logic_vector;
    b: in std_logic_vector;
    s: out std_logic_vector);

    constant width:natural:=s'length;
end sat_add;

architecture rtl of sat_add is
    signal aext:signed(width downto 0);
    signal bext:signed(width downto 0);
    signal lcl_sum:std_logic_vector(width downto 0);
    signal limit:std_logic_vector(width-1 downto 0);
begin
    aext<= resize(signed(a),width+1);
    bext<=resize(signed(b),width+1);
    lcl_sum<= std_logic_vector(aext+bext);
    limit<= (others=> lcl_sum(width);
    s<= lcl_sum(width-1 downto 0) when lcl_sum(width)=lcl_sum_width-1 else limit;

end rtl;



Russell Shaw wrote:

> But how do you do a normal add while getting access to the right
> carry bits?
>
> John_H wrote:
> >
> > You're trying to do all the work for the synthesizer by telling it how to
> > perform addition.
> > Let the synthesizer to the addition - you just concentrate on the saturable
> > aspect.
> > Leonardo spectrum should get all the carry chains together fine because it
> > know how to utilize them to add.
> >
> > Russell Shaw wrote:
> >
> > > Hi all,
> > >
> > > I made this saturable adder from converting AHDL code in a previous
> > > message.
> > >
> > > It adds signed HEX numbers together, but doesn't roll-over if there's
> > > an overflow.
> > >
> > > I'm using leonardo-spectrum to generate an edif netlist, which is
> > > compiled by altera maxplus2.
> > >
> > > Where and how, if any, can i add technology-dependent optimizations
> > > such as carry chains etc?
> > >
> > > Also, are there such things as VHDL debuggers where you can single-
> > > step thru the code and see what all the signals and variables are
> > > doing?
> > >
> > > LIBRARY ieee;
> > > USE ieee.std_logic_1164.all;
> > >
> > > PACKAGE types IS
> > >   subtype word is std_ulogic_vector(3 downto 0);
> > > END types;
> > >
> > > LIBRARY ieee;
> > > USE ieee.std_logic_1164.all;
> > > use work.types.all;
> > >
> > > ENTITY saturable_adder IS
> > > port(
> > >   a,b: in word;
> > >   s:   out word
> > >      );
> > > END adder;
> > >
> > > LIBRARY ieee;
> > > USE ieee.std_logic_1164.all;
> > > use work.types.all;
> > >
> > > ARCHITECTURE total OF saturable_adder IS
> > > BEGIN
> > >   behav: PROCESS (a,b) is
> > >   variable sum: word;
> > >   variable carry_in,carry_out: std_ulogic;
> > >   constant msb:integer:=word'left;
> > >
> > >   BEGIN
> > >     carry_in:='0';
> > >     for ndx in 0 to (word'left-1) loop
> > >       sum(ndx):=a(ndx) xor b(ndx) xor carry_in;
> > >       carry_out:=(a(ndx) and b(ndx)) or (a(ndx) and carry_in) or (b(ndx)
> > > and carry_in);
> > >       carry_in:=carry_out;
> > >     end loop;
> > >     sum(msb):=a(msb) xor b(msb) xor carry_in;
> > >     if( (a(msb) and b(msb) and not carry_in)='1' )
> > >     then
> > >       sum:=(others=>'0');
> > >       sum(msb):='1';
> > >     elsif( (not a(msb) and not b(msb) and carry_in)='1' )
> > >     then
> > >       sum:=(others=>'1');
> > >       sum(msb):='0';
> > >     end if;
> > >     s<=sum;
> > >   END PROCESS behav;
> > > END total;
> > >
>
> --
>    ___                                           ___
>   /  /\                                         /  /\
>  /  /__\ Russell Shaw, B.Eng, M.Eng(Research)  /  /\/\
> /__/   / Victoria, Australia, Down-Under      /__/\/\/
> \  \  /  http://home.iprimus.com.au/rjshaw    \  \/\/
>  \__\/                                         \__\/

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



Article: 33591
Subject: Re: RAM... got it
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Tue, 31 Jul 2001 13:49:58 GMT
Links: << >>  << T >>  << A >>
After some more try I got it. It was wrong to use altdpram.
Using lpm_ram_dp instead solves the problem.
Now I got rid of those .tdf files and ready to move to Xilinx...
But, oach: I read in the data sheet that it's not possible to use
the block RAM with unregistered din or unregistered rdaddress!
So I've to change my whole design :-(

Martin
--
Whant to see the evolution of a Java processor?

         http://www.jopdesign.com

The solution to Altera rams in Leonardo:

--
--    aram.vhd
--
--    internal memory for JOP3
--    Version for Altera
--
--

Library IEEE ;
use IEEE.std_logic_1164.all ;
use IEEE.std_logic_arith.all ;
use IEEE.std_logic_unsigned.all ;

entity ram is
generic (width : integer := 32; addr_width : integer := 8);
port (
    data        : in std_logic_vector(width-1 downto 0);
    wraddress    : in std_logic_vector(addr_width-1 downto 0);
    rdaddress    : in std_logic_vector(addr_width-1 downto 0);
    wren        : in std_logic;
    clock        : in std_logic;

    q            : out std_logic_vector(width-1 downto 0)
);
end ram ;

--
--    registered wraddress, wren
--    unregistered din
--    registered rdaddress
--    unregistered dout
--
architecture rtl of ram is

    COMPONENT lpm_ram_dp
    GENERIC (LPM_WIDTH: POSITIVE;
            LPM_WIDTHAD: POSITIVE;
            LPM_NUMWORDS: NATURAL := 0;
            LPM_TYPE: STRING := "LPM_RAM_DP";
            LPM_INDATA: STRING := "REGISTERED";
            LPM_OUTDATA: STRING := "REGISTERED";
            LPM_RDADDRESS_CONTROL: STRING := "REGISTERED";
            LPM_WRADDRESS_CONTROL: STRING := "REGISTERED";
            LPM_FILE: STRING := "UNUSED";
            LPM_HINT: STRING := "UNUSED"
            );
    PORT (rdaddress, wraddress: IN STD_LOGIC_VECTOR(LPM_WIDTHAD-1 DOWNTO 0);
            rdclock, wrclock: IN STD_LOGIC := '1';
            rden, rdclken, wrclken: IN STD_LOGIC := '1';
            wren: IN STD_LOGIC;
            data: IN STD_LOGIC_VECTOR(LPM_WIDTH-1 DOWNTO 0);
            q: OUT STD_LOGIC_VECTOR(LPM_WIDTH-1 DOWNTO 0));
    END COMPONENT;

begin

    cmp_ram: component lpm_ram_dp
            generic map (
                LPM_WIDTH => width,
                LPM_WIDTHAD =>    addr_width,
                LPM_NUMWORDS =>    2**addr_width,
                LPM_TYPE => "LPM_RAM_DP",
                LPM_INDATA => "UNREGISTERED",
                LPM_OUTDATA => "UNREGISTERED",
                LPM_RDADDRESS_CONTROL => "REGISTERED",
                LPM_WRADDRESS_CONTROL => "REGISTERED",
                LPM_FILE => "C:/usr/cpu/jop3/ram.mif",
                LPM_HINT => "USE_EAB=ON")
            port map (
                rdaddress => rdaddress,
                wraddress => wraddress,
                data => data,
                rdclock => clock,
                wrclock => clock,
                wren => wren,
                q => q
            );

end rtl;



Article: 33592
Subject: Re: multi-context FPGA
From: Jon <jschneider@cix.ceeowe.ewekay>
Date: 31 Jul 2001 15:14:04 +0100
Links: << >>  << T >>  << A >>
"Dave Feustel" <dfeustel@mindspring.com> writes:
> PACT offers 80 Pentium4s on a 100Mhz chip

No they don't. The thing would need a power station to run it for starters.

They have something capable of a number of calculations per second
which might be equivalent to what 80 P4s could be kept busy doing.

Same sort of thing as Xilinx's 800 GigaFlop (or something like that)
Virtex configuration.

        Jon

Article: 33593
Subject: Re: finite defect statistics
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Tue, 31 Jul 2001 10:33:09 -0400
Links: << >>  << T >>  << A >>
Ray I shouldn't dignify this with a response since you are clearly
talking about a subject that you know nothing about. However for everyone
elses benefit I'll give more detail about the nature of the failures that
we see. We run these tests on approximately 30,000 FPGAs a year. Prior to
prescreening we were seeing a fall out rate of about 1 in 50. The reports
that we get back form Xilinx on the screened parts are consistant with
that number. The nature of the failure is that a bad part will fail 2 or 3
patterns out of a total of about 150. We can't identify a particular node
because the tests are designed to give a go/no go answer. However we can
generally determine which half of the FPGA failed because all of the
tests are part of a pair, each member testing approximately 50% of the
CLBs. It's clear that the defects are very small, maybe as small as a
single gate. Bad parts mostly work, i.e. out of 150 patterns they will
pass 147 or 148. The clock speed range is 12Mhz to 30Mhz. The designs are
completely syncronous and there are no gated clocks. Parts that fail
will generally fail at all clock speeds so you can see it's not a timing
problem. It should be obvious that a design that can't run at 12Mhz on
one part is unlikely to run at 30Mhz on the remaining 400 parts in the
system, but of course they do run on the remaining parts because there
are no timing problems in the designs. The reason that you haven't seen
these problems is because you aren't looking. We only knew that there was
a problem because we were getting reports from the field about failures.
The nature of ASIC emulators makes it's possible to identify the source
of a problem by shuffling the patterns between different FPGAs. The field
guys were then able to identify the bad FPGAs. After we realized that
there was a problem we developed these test patterns. Now field failures
are much much less frequent, although they aren't zero because our
coverage isn't 100%. 

n article <3B66ABD1.D878B8B7@andraka.com>, "Ray Andraka"
<ray@andraka.com> wrote:

> Can you give us any more detail as to the exact nature of the failures,
> and any back up you might have to substantiate it?  Have you pinpointed
> the failures to specific nodes in a part, and then verified that that
> node still fails with a different test circuit designed specifically to
> exercise the 'bad' node?   No trying to be a pain, but I've seen some
> pretty bad design in very expensive equipment over the years.  Seems
> that the poorer the design, the more likely the designer is to blame the
> chip.  There are an awful lot of mediocre designers out there, and they
> don't just inhabit garages (in fact, on average I'd venture to say that
> the small shops tend to crank out better designs...they tend to hire the
> cream of the crop).  The fact that it fails on a chip tester as well as
> on the board just tells me that there is a problem with design you are
> putting in the FPGA to test it.  Again, if the failure rates were even a
> 10th of what you are claiming, I would have expected to see a couple
> over my career, and would have expected a huge outcry here and in the
> press.
> 
> "B. Joshua Rosen" wrote:
> 
>

Article: 33594
Subject: Re: Schematic user info
From: Klaus Falser <notvalid@notvalid.it>
Date: Tue, 31 Jul 2001 18:08:37 +0200
Links: << >>  << T >>  << A >>
In article <996585039.510644@turtle.ru.ac.za>, g9731642@campus.ru.ac.za 
says...
> Sorry, just an administrative question. Could someone please tell me how to
> manually adjust the user info that appears at the bottom right-hand corner
> of a schematic diagram in the Xilinx Foundation software?
> 
> Adrian
> 
> 

Under File -> Edit Table Entry ..

-- 
Falser Klaus
R&D Electronics Department
Company	: Durst Phototechnik AG
	  Vittorio Veneto Str. 59
	  I-39042 Brixen
Voice	: +0472/810235
	: +0472/810111
FAX	: +0472/830980
Email	: kfalser@IHATESPAMdurst.it 

Article: 33595
Subject: Re: Athlon 1.4 vs Pentium 4 1.7 for Foundation ISE/ModelSim?
From: cyber_spook <pjc@cyberspook.freeserve.co.uk>
Date: Tue, 31 Jul 2001 18:28:08 +0100
Links: << >>  << T >>  << A >>


Rick Collins wrote:

> cyber_spook wrote:
> >
> > Hi,
> >
> > Rick Filipkiewicz wrote:
> >
> > > My conclusion from this small sample is that the P&R tool speed is
> > > dominated by memory performance.
> >
> > With this type of application (memory hugary!) the speed of the CPU is only
> > any good when it has the data to process. In other words a 450, 600 or 1.4
> > will just spend most of its time sitting on its "bum" waiting for memory.
> >
> > This was proven when Cambridge Uni fitted 4Gb of SRAM (not DRAM) to a 40Mhz
> > 386DX - Was the fastest thing you have ever seen!!
> >
> > Cyber_Spook_Man
>
> I find this hard to believe. I don't doubt that the general rule for
> memory is faster is better. But I don't think a 40 MHz 386 will outrun a
> 1 GHz anything just because the 386 is running in zero wait state
> memory. I also find it hard to believe you can fit 4 Gb of SRAM to a
> processor without slowing down the SRAM. That is a lot of memory, about
> 512 chips (assuming the Gb means gigabits, not gigabytes)!!!
>

Sorry - was not compairing a 386 to a 1Ghz PC of today, Its just that Cambridge
produced a machine that ran faster than anything else around - was for simulation
software or somthing?


Article: 33596
Subject: Re: i2c master
From: rotemg@mysticom.com (Rotem Gazit)
Date: 31 Jul 2001 10:29:03 -0700
Links: << >>  << T >>  << A >>
"Dick Ginther" <dick.ginther@wavecom.ca> wrote in message news:<r3j97.20$7i.589926@tomcat.sk.sympatico.ca>...
> Hi,
>     I'm looking for some open source for a i2c bus master...does anyone
> know of some?
>     Thanks.

Xilinx XAPP333: CoolRunner XPLA3 I2C Bus Controller Implementation 
http://www.xilinx.com/xapp/xapp333.pdf ???

Article: 33597
Subject: Re: i2c master
From: Jennifer Jenkins <jennifer.jenkins@xilinx.com>
Date: Tue, 31 Jul 2001 11:44:17 -0600
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------701C5CCA47202106778BECF1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Check out the I2C Xilinx reference design:

 http://www.xilinx.com/xapp/xapp333.pdf


Ingmar Hohmann wrote:

> Have a look to:
>
> http://www.opencores.org/projects.shtml
>
> By Ingmar
>
> Dick Ginther schrieb:
>
> > Hi,
> >     I'm looking for some open source for a i2c bus master...does anyone
> > know of some?
> >     Thanks.
>
> --
> ___________________________________________________________________
>
> Ingmar Hohmann                    mailto:ih@seh.de
> SEH Computertechnik GmbH          http://www.seh.de
> Suedring 11        Fax:  +49 521 94226 99
> D-33647 Bielefeld                 Phone:+49 521 94226 63
> GERMANY
> __________________________________________________________________

--------------701C5CCA47202106778BECF1
Content-Type: text/x-vcard; charset=us-ascii;
 name="jennifer.jenkins.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jennifer Jenkins
Content-Disposition: attachment;
 filename="jennifer.jenkins.vcf"

begin:vcard 
n:Jenkins;Jennifer
tel;fax:(505) 858-3106
tel;work:(505) 798-4813
x-mozilla-html:FALSE
url:http://www.xilinx.com
org:Xilinx CoolRunner CPLDs;<br><img src="http://www.xilinx.com/images/xlogoc.gif" alt="Xilinx">
adr:;;7801 Jefferson St. NE;Albuquerque;New Mexico;87109;
version:2.1
email;internet:Jennifer.Jenkins@xilinx.com
title:Applications Engineer
fn:Jennifer Jenkins
end:vcard

--------------701C5CCA47202106778BECF1--


Article: 33598
Subject: Re: RAM... got it
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 31 Jul 2001 11:28:12 -0700
Links: << >>  << T >>  << A >>
The Virtex BlockRAM operates synchronously, even in read mode. It thus differs
from a traditional old RAM where the read operation used to be combinatorial.

So you need a read clock for Virtex BlockRAMs, but you also get all the
advantages of fully synchronous operation. For example, you can use the output
data as the next address, without incurring a race condition.

Note that the read-while-you write operation has only one flavor in Virtex and
Virtex-E ( you always see at the read port the data you just wrote), but in
Virtex-II you have three choices ( by configuration):
1. Read before write, i.e. read the old content that is now being overwritten
2. Write before read, i.e. read the new data ( like in Virtex and Virtex-E)
3. Don't change the data output, i.e. keep it constant until you do a real read
operation.

Herzlich willkommen bei Xilinx !

Peter Alfke, Xilinx Applications
==============================
Martin Schoeberl wrote:

> After some more try I got it. It was wrong to use altdpram.
> Using lpm_ram_dp instead solves the problem.
> Now I got rid of those .tdf files and ready to move to Xilinx...
> But, oach: I read in the data sheet that it's not possible to use
> the block RAM with unregistered din or unregistered rdaddress!
> So I've to change my whole design :-(
>
> Martin
> --
> Whant to see the evolution of a Java processor?
>
>          http://www.jopdesign.com
>
> The solution to Altera rams in Leonardo:
>
> --
> --    aram.vhd
> --
> --    internal memory for JOP3
> --    Version for Altera
> --
> --
>
> Library IEEE ;
> use IEEE.std_logic_1164.all ;
> use IEEE.std_logic_arith.all ;
> use IEEE.std_logic_unsigned.all ;
>
> entity ram is
> generic (width : integer := 32; addr_width : integer := 8);
> port (
>     data        : in std_logic_vector(width-1 downto 0);
>     wraddress    : in std_logic_vector(addr_width-1 downto 0);
>     rdaddress    : in std_logic_vector(addr_width-1 downto 0);
>     wren        : in std_logic;
>     clock        : in std_logic;
>
>     q            : out std_logic_vector(width-1 downto 0)
> );
> end ram ;
>
> --
> --    registered wraddress, wren
> --    unregistered din
> --    registered rdaddress
> --    unregistered dout
> --
> architecture rtl of ram is
>
>     COMPONENT lpm_ram_dp
>     GENERIC (LPM_WIDTH: POSITIVE;
>             LPM_WIDTHAD: POSITIVE;
>             LPM_NUMWORDS: NATURAL := 0;
>             LPM_TYPE: STRING := "LPM_RAM_DP";
>             LPM_INDATA: STRING := "REGISTERED";
>             LPM_OUTDATA: STRING := "REGISTERED";
>             LPM_RDADDRESS_CONTROL: STRING := "REGISTERED";
>             LPM_WRADDRESS_CONTROL: STRING := "REGISTERED";
>             LPM_FILE: STRING := "UNUSED";
>             LPM_HINT: STRING := "UNUSED"
>             );
>     PORT (rdaddress, wraddress: IN STD_LOGIC_VECTOR(LPM_WIDTHAD-1 DOWNTO 0);
>             rdclock, wrclock: IN STD_LOGIC := '1';
>             rden, rdclken, wrclken: IN STD_LOGIC := '1';
>             wren: IN STD_LOGIC;
>             data: IN STD_LOGIC_VECTOR(LPM_WIDTH-1 DOWNTO 0);
>             q: OUT STD_LOGIC_VECTOR(LPM_WIDTH-1 DOWNTO 0));
>     END COMPONENT;
>
> begin
>
>     cmp_ram: component lpm_ram_dp
>             generic map (
>                 LPM_WIDTH => width,
>                 LPM_WIDTHAD =>    addr_width,
>                 LPM_NUMWORDS =>    2**addr_width,
>                 LPM_TYPE => "LPM_RAM_DP",
>                 LPM_INDATA => "UNREGISTERED",
>                 LPM_OUTDATA => "UNREGISTERED",
>                 LPM_RDADDRESS_CONTROL => "REGISTERED",
>                 LPM_WRADDRESS_CONTROL => "REGISTERED",
>                 LPM_FILE => "C:/usr/cpu/jop3/ram.mif",
>                 LPM_HINT => "USE_EAB=ON")
>             port map (
>                 rdaddress => rdaddress,
>                 wraddress => wraddress,
>                 data => data,
>                 rdclock => clock,
>                 wrclock => clock,
>                 wren => wren,
>                 q => q
>             );
>
> end rtl;


Article: 33599
Subject: computer science Vs Computer Enginnering
From: pound_euro@altavista.com (edgar)
Date: 31 Jul 2001 11:30:30 -0700
Links: << >>  << T >>  << A >>
heya,


This year, I got my Bachelor in computer science. i wanted to
undertake a PhD in the fielld of FPGA, but i have been refused even
that i have my degree with a mark of 65%.

when i asked the boss there, he told me this is a computer engineering
department and not computer science, i can't accepet you even if you
got 90%!!!!

i have decided to join a software company, but still wondering on what
he means,
what is the differences between computer science and computer
engineering ?


Edgar S



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