Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 33525

Article: 33525
Subject: Re: Digital Mixer
From: Ray Andraka <ray@andraka.com>
Date: Sun, 29 Jul 2001 18:06:17 GMT
Links: << >>  << T >>  << A >>
I think you are saying you want to add a constant phase shift of 90 degrees to
your signal, in which case mixing it like you specified isn't going to do
that.  The mixer you've specified shifts the center frequency of the input
signal by Fs/4 (multiplies the signal by e^(-j*2pi*t).  To do a constant phase
shift, you need to do a rotation of 90 degrees on the signal.  Fortunately, 90
degrees is really easy:  I<= -Qin and Q<=Iin.

Noddy wrote:

> Hi all,
>
> I was wondering if anyone can confirm this: if I want to, lets say,
> digitally mix my bandwidth by pi/2, in other words shift the unit circle in
> the z plane by 90 degrees, all I need to do is multiply my incoming samples
> by the sequence 1,+j,-1,-j. Is this correct? I have implemented this in a
> schematic design, but it doesn't appear to be working as I had hoped.
>
> Any other ideas?
>
> adrian

--
-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: 33526
Subject: Re: SRL16
From: Ray Andraka <ray@andraka.com>
Date: Sun, 29 Jul 2001 18:12:22 GMT
Links: << >>  << T >>  << A >>
One note on the serial cascade:  There is some recovery time required after switching delays...ie you'll need to be a bit more sophisticated if
you need to support clock by clock tap changes.

Ray Andraka wrote:

> You can't use the F5/F6 mux in the same slice as 2 srl16's because the BX and BY lines which control the mux are shared with the write enables
> for the SRL16's.  Depending on your application, you might change the programming of the SRL16 address lines on two serially cascaded SRL16s,
> which (without intervening FD's) gives you a delay between 2 and 32 clocks and no mux.  You will need to translate the delay code into the 8
> select bits for the SRL16s.  If you are concerned for speed, you'll want to register the output of each SRL16 with the FF in the same
> half-slice.  The clock to out time of the SRL16 is pretty lousy compared to that of the FF's.
>
> Huang wrote:
>
> > Hi,
> >
> > When using CoreGenerator for a SRL16 based shif register, say, a 32x1 shfit register, I found the result was 3 LUT, 2 for SRL16, 1 for mux.
> >
> > Does anyone know why CoreGen doesn't use MUXF5/6/7/8 for a more resource efficient result?
> >
> > Thanks
>
> --
> -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: 33527
(removed)


Article: 33528
Subject: Re: Xilinx/Altera "behavioral" verilog
From: Andy Botterill <csm@plymouth2.demon.co.uk>
Date: Sun, 29 Jul 2001 20:04:08 +0100
Links: << >>  << T >>  << A >>
In article <20010729.133501.492067917.26595@polybus.com>, B. Joshua
Rosen <bjrosen@polybus.com> writes
>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.

Many thanks for such a detailed answer. I come from an ASIC
manufacturing background so the absence of scan would worry me. So there
is a 1 in 5000 chance of detecting a faulty FPGA? This is equivalent to
200 dppm which is a good quality level.
>
>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. The FPGA vendors do some of this but they are limited
>by the amount of time that they can tie up a chip tester for. Generally
>the vendor tests runs in under a second, in my experience it takes about

A 1 second test time would be considered normal. A test time of 20
minutes would be very expensive.

>20 minutes to really test an FPGA. If you are selling low volume high
>value equiptment that contains a large number of FPGAs and loads many
>different patterns into them, like and ASIC emulator, then this degree
>of testing is necessary. If you are shipping high volume low priced
>boards then it's cheaper to live with the one in 5000 fall out. Adding
>scan logic to a particular circuit is useless because any change to the
>pattern, including another place and route on the same design, will
>change which resources are used inside of the FPGA.
>
>
>In article <996308678.26850.0.nnrp-07.9e9832fa@news.demon.co.uk>, "Tim"
><tim@rockylogic.com.nospam.com> wrote:
>
>> "Andy Botterill" <csm@plymouth2.demon.co.uk> wrote in message
>> news:YNNvDUAmacY7EwX0@plymouth2.demon.co.uk...
>> 
>>> >Programmable parts have different test requirements to ASICs, so I
>>> >guess the answer to your question is Yes.
>>>
>>> If you cannot insert scan into an FPGA how do you get a high fault
>>> coverage? If you have a poor fault coverage you will be shipping
>>> defective parts which is not good for your business.
>> 
>> The FPGA manufacturers do this for you.  They use a combination of the
>> reprogrammability of the part and, presumably, a few undisclosed test
>> structures.
>> 
>> The result is closer to 100% tested than just about any ASIC.  All you
>> have to worry about is logical and timing errors :)
>> 
>> 
>> 
>> 
>>

-- 
Andy Botterill

Article: 33529
(removed)


Article: 33530
Subject: Re: Xilinx/Altera "behavioral" verilog
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Sun, 29 Jul 2001 21:38:30 +0100
Links: << >>  << T >>  << A >>
Truly interesting.  Any comments from A or X?

"B. Joshua Rosen" <bjrosen@polybus.com> wrote in message
news:20010729.133501.492067917.26595@polybus.com...
> 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. The FPGA vendors do some of this but they are limited
> by the amount of time that they can tie up a chip tester for. Generally
> the vendor tests runs in under a second, in my experience it takes about
> 20 minutes to really test an FPGA. If you are selling low volume high
> value equiptment that contains a large number of FPGAs and loads many
> different patterns into them, like and ASIC emulator, then this degree
> of testing is necessary. If you are shipping high volume low priced
> boards then it's cheaper to live with the one in 5000 fall out. Adding
> scan logic to a particular circuit is useless because any change to the
> pattern, including another place and route on the same design, will
> change which resources are used inside of the FPGA.
>
>
> In article <996308678.26850.0.nnrp-07.9e9832fa@news.demon.co.uk>, "Tim"
> <tim@rockylogic.com.nospam.com> wrote:
>
> > "Andy Botterill" <csm@plymouth2.demon.co.uk> wrote in message
> > news:YNNvDUAmacY7EwX0@plymouth2.demon.co.uk...
> >
> >> >Programmable parts have different test requirements to ASICs, so I
> >> >guess the answer to your question is Yes.
> >>
> >> If you cannot insert scan into an FPGA how do you get a high fault
> >> coverage? If you have a poor fault coverage you will be shipping
> >> defective parts which is not good for your business.
> >
> > The FPGA manufacturers do this for you.  They use a combination of the
> > reprogrammability of the part and, presumably, a few undisclosed test
> > structures.
> >
> > The result is closer to 100% tested than just about any ASIC.  All you
> > have to worry about is logical and timing errors :)




Article: 33531
Subject: Re: finite defect statistics
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Mon, 30 Jul 2001 08:53:05 +1200
Links: << >>  << T >>  << A >>
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

Article: 33532
Subject: Re: Jitter Added by FPGA counter
From: John_H <johnhandwork@mail.com>
Date: Sun, 29 Jul 2001 21:57:47 GMT
Links: << >>  << T >>  << A >>
In the earlier days of FPGAs and ASICs we had some tough times with unintended
jitter added to signals targeted at telecom systems.  Not a good thing.
Something I've noticed in my years of being around these signals is that FPGAs
are sensitive (more particularly in some I/O formats) to what else is going on
inside - or at the interface to - the chip.  You won't have a nanosecond worth
of jitter added to things but if you want to keep to under 100ps, you may not
have great luck within the FPGA.  Keeping the signaling to LVCMOS style outputs
(low impedance to each rail) may help because some of the "trash" seen on older
programmable devices was riding on top of the logic high voltage and would
affect the downward swing.

Consider using a single-chip external register to resynch your counter divider
to the original clock.  The amount of signal feedtrough getting into your clock
should be significantly limited at that point.  If you need excellent jitter
control this might be your quickest way to an end.  With nothing else going in
to the device and with well filtered rails to the register you should end up
with very consistent results.  Noise on your supply and noise on your input can
both contribute to misplaced edges.

- John


Andrew Bridger wrote:

> Hi,
> In my application the FPGA is generating sampling clocks for various ADC's
> and DAC's.  I was planning to use a divide by N counter then divide by 2 to
> generate the 50% duty cycle clock.  I am wondering if there is any analysis
> I can do to predict how much jitter the counter will add to my ADC clock?
> It may be trivial for our application but I'm just not sure.
>
> The ADC max sampling rate is 8MHz, the ADC device itself has 50 ps aperture
> jitter.  (I notice a DLL adds 60ps max jitter, not that a DLL is part of the
> clock chain in my design)
>
> Chip is XC2S100/200, Foundation ISE.
>
> Thanks
> Andrew


Article: 33533
Subject: Re: Reset during accumulation
From: John_H <johnhandwork@mail.com>
Date: Sun, 29 Jul 2001 22:01:54 GMT
Links: << >>  << T >>  << A >>
If your accumulation is gated don't just clear the register but decide whether
to load the accumulator with a zero (not accumulating a sample this period) or a
one (accumulating).  This will allow a clean reset that doesn't lose a sample.

If your accumulator isn't incrementing by one, just change to load value to be
either zero or the accumulation value depending on the gate.

It works so much nicer when cycles aren't excluded.

- John


Noddy wrote:

> Hi all,
>
> I am using an accumulator  to accumulate N samples. I have a seperate
> counter to N which, when reached, will reset the accumulator back to zero to
> begin accumulation again. My only problem is that the accumulator misses one
> sample in this reset as it goes back to zero. I initially used a synchronous
> clear pin, but after spotting the problem, tried to use an asynchronous pin.
> My N counter goes high for one clockperiod to reset, so I tried AND gating
> it with the clock period (both inverted and non inverted) to only reset for
> half a clock period - this still doesn't work and the accumulator still
> insists on going back to zero for one clock period.
>
> Any ideas?
>
> Adrian


Article: 33534
Subject: Re: finite defect statistics
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Sun, 29 Jul 2001 18:27:29 -0400
Links: << >>  << T >>  << A >>
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

Article: 33535
Subject: Re: Jitter Added by FPGA counter
From: Ray Andraka <ray@andraka.com>
Date: Sun, 29 Jul 2001 23:22:14 GMT
Links: << >>  << T >>  << A >>
In Virtex, you'll get much better results if you use a differential clock
standard.  If you can't, then not using the any of I/Os in the same I/O bank as
your clock input will drastically reduce the jitter introduced.

John_H wrote:

> In the earlier days of FPGAs and ASICs we had some tough times with unintended
> jitter added to signals targeted at telecom systems.  Not a good thing.
> Something I've noticed in my years of being around these signals is that FPGAs
> are sensitive (more particularly in some I/O formats) to what else is going on
> inside - or at the interface to - the chip.  You won't have a nanosecond worth
> of jitter added to things but if you want to keep to under 100ps, you may not
> have great luck within the FPGA.  Keeping the signaling to LVCMOS style outputs
> (low impedance to each rail) may help because some of the "trash" seen on older
> programmable devices was riding on top of the logic high voltage and would
> affect the downward swing.
>
> Consider using a single-chip external register to resynch your counter divider
> to the original clock.  The amount of signal feedtrough getting into your clock
> should be significantly limited at that point.  If you need excellent jitter
> control this might be your quickest way to an end.  With nothing else going in
> to the device and with well filtered rails to the register you should end up
> with very consistent results.  Noise on your supply and noise on your input can
> both contribute to misplaced edges.
>
> - John
>
> Andrew Bridger wrote:
>
> > Hi,
> > In my application the FPGA is generating sampling clocks for various ADC's
> > and DAC's.  I was planning to use a divide by N counter then divide by 2 to
> > generate the 50% duty cycle clock.  I am wondering if there is any analysis
> > I can do to predict how much jitter the counter will add to my ADC clock?
> > It may be trivial for our application but I'm just not sure.
> >
> > The ADC max sampling rate is 8MHz, the ADC device itself has 50 ps aperture
> > jitter.  (I notice a DLL adds 60ps max jitter, not that a DLL is part of the
> > clock chain in my design)
> >
> > Chip is XC2S100/200, Foundation ISE.
> >
> > Thanks
> > Andrew

--
-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: 33536
Subject: Re: finite defect statistics
From: Ray Andraka <ray@andraka.com>
Date: Sun, 29 Jul 2001 23:28:09 GMT
Links: << >>  << T >>  << A >>
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: 33537
(removed)


Article: 33538
Subject: Re: SRL16
From: Huang <>
Date: Sun, 29 Jul 2001 19:15:43 -0700
Links: << >>  << T >>  << A >>
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?

Article: 33539
Subject: Re: finite defect statistics
From: Peter Alfke <palfke@earthlink.net>
Date: Mon, 30 Jul 2001 03:27:33 GMT
Links: << >>  << T >>  << A >>
The defect numbers quoted are definitely wrong.
Xilinx ships about a million FPGAs per week. Just imagine the uproar in this
newsgroup and elsewhere, if one in a thousand, or one in 10,000, or even one in
100,000 were found to malfunction.
"Nobody is perfect", but the test coverage is pretty close to 100%.

Peter Alfke, Xilinx Applications
====================================
Ray Andraka 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: 33540
Subject: Re: Can't Install Modelsim - Alternatives for Verilog Simulation???
From: "Srinivasan Venkataramanan" <svenka3@siliconsystems.co.in>
Date: Mon, 30 Jul 2001 11:46:34 +0530
Links: << >>  << T >>  << A >>
Hi,
  Try ICARUS Verilog from:

http://icarus.com/eda/verilog/index.html

(FAQ says it runs on Windows + Cygwin32)

I personally have used SilosIII (from http://www.simucad.com) under Windows
98.

Good Luck,
Srini
--
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:9jugr9$5vr$1@slb4.atl.mindspring.net...
> Modelsim licensing refuses to work on my computer.
>
> What alternatives to Modelsim are there for Verilog simulation
> on Windows 2000?
>
> Thanks.
>
>



Article: 33541
Subject: Re: PCI-Interface
From: "Zimba" <zimba@zamba.com>
Date: Mon, 30 Jul 2001 09:10:26 +0200
Links: << >>  << T >>  << A >>
http://www.plxtech.com/

Clemens



Article: 33542
Subject: Re: 3.3i service pack 8
From: "Zimba" <zimba@zamba.com>
Date: Mon, 30 Jul 2001 09:13:53 +0200
Links: << >>  << T >>  << A >>
You can, just try several times. I had the same problem and finally got the
file when I tried a bit later.

Clemens



Article: 33543
Subject: Re: XC4010 ! help please
From: skintigh@alum.wpi.edu (Seth Kintigh)
Date: 30 Jul 2001 03:39:17 -0700
Links: << >>  << T >>  << A >>
I have that exact same issue.  Xilinx apparently decided it was a
mistake to make that chip and so thought it was best to screw everyone
who bought it by refusing to support it in future software and
crippling support in current software.

To design on it, I use Synplify 5.0.8/a (the very last version to work
correctly) which only runs on a Sun, and the non-y2k compliant XACT
software which only runs on an HP.

Fun Fun FUN.

Joe <ja.gallegos@boeing.com> wrote in message news:<3B61E7E2.453B694@boeing.com>...
> We have it on Sun OS4.1 -- XACT will not work on Solaris
> 
> Werner Dreher wrote:
> 
> > Joe,
> >
> > on which platform do you use the XACT software?
> > We have a legal license for XACT (and the software itself) for
> > Sun/SunOS, but the software doesn't run because of an y2k bug
> > in the license deamon :-(
> >
> >  Werner Dreher
> >
> > Joe wrote:
> > >
> > > Unfortunately, you will have to get a copy of Xilinx's legacy tool called XACT. We use both the Alliance and XACT toolset to support Xilinx legacy and new devices...
> > >
> > > Tran Cong So wrote:
> > >
> > > > Hi,
> > > > I have now to design on a very old FPGA XC4010 (not E or XL).
> > > > The problem is the current development softwware that I am using is Fondation ISE 3.1 and this version does not support for xc4000 family and the old software XACT Step 5.2/Sun is out of license. I tried to contact distributor to get new license but just have got the NOT SUPPORT because the software (XACTStep) is too old.
> > > > Does any one have an idea how to be able to work with XC4000 family at this time ? The device is not replacable because replacement means to destroy the PCB.
> > > > Thank you very much.
> > > > Tran Cong So.

Article: 33544
Subject: Re: Modulator Sizing Questions
From: dottavio@ised.it (Antonio)
Date: 30 Jul 2001 05:23:13 -0700
Links: << >>  << T >>  << A >>
Hy Ray,
can you better explain where I've to put the delay of the adder??






Ray Andraka <ray@andraka.com> wrote in message news:<3B590A8D.AE5DCA72@andraka.com>...
> Oops, pushed the send too fast....
> 
> Antonio wrote:
> 
> > 3) If for example one input of the multiplier is 10 bits, also the
> > other must be ten bits ?? and how much for the output ???
> 
> No, you can have both inputs have arbitrary sizes.  I believe the latest
> Xilinx core generator allows you to set the widths of the inputs
> independently.  In your case, you do not need multipliers: each
> coefficient is a constant that you are either adding to or subtracting
> from the sum of products (you are multiplying by either 1 or -1), so
> instead, use adder/subtractors with the signal input controlling the a/s
> control.  Since this is a filter, the signal is delayed in a tapped delay
> queue.  You can transpose the delay to the output side of the filter,
> which allows you to perform the adds in a chain, then the structure is a
> chain of adder/subtractors that have one input connected to a constant
> coefficient, and the other to the output of the previous adder in the
> chain.
> 
> >
> >
> > 4) By the way , it is important that the inputs of the multiplier have
> > the same rate ??
> 
> No, but they should both change as a result of transitions on the same
> clock signal.  For example, one input can change on every clock cycle
> while the other only changes every 4th cycle.  The multiplier in an FPGA
> is generally deeply pipelined (takes several clocks before the product of
> the inputs appears on the output).
> 
> >
> >
> > 5) if for example the input of the following adder are both 10 bits,
> > how much bits I've to provide for the output.
> 
> In your case, you know the values at the input of the adders, since they
> are constants.  From these, you can compute the maximum value at the
> output of each adder, which in turn tells you how many bits of
> significance you need at that node.  For example, the coefficient
> mentioned above (previous post) could be represented with only 11 bits
> instead of the 16 without loosing any more precision than the original
> quantization.  If you add that with another coefficient of similar
> magnitude, you will likely need 12 bits to represent the largest possible
> sum without overflow.
> 
> >
> >
> > I know many of these question could be stupid , but, how I can say,
> > I've not the answer so if you have some answer also only at some of
> > them I'll be really happy if you tell it to me or also if you redirect
> > me to some resource speaking strictly about these thinghs ...
> >
> > Antonio D'Ottavio

Article: 33545
(removed)


Article: 33546
Subject: Re: finite defect statistics
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Mon, 30 Jul 2001 09:39:16 -0400
Links: << >>  << T >>  << A >>
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: 33547
Subject: Re: Athlon 1.4 vs Pentium 4 1.7 for Foundation ISE/ModelSim?
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Mon, 30 Jul 2001 09:47:57 -0400
Links: << >>  << T >>  << A >>
The Athlon will probably be much faster. The P4 has a very long pipeline
and really suffers on any code that takes a lot of branches. The relevant
benchmark is probably the Linux kernel compile time where the Althon is
about twice as fast as the P4. The place where the P4 shines is in highly
vectorizable code like MPEG encoding. Place and Route and simulation
programs aren't vectorized at all. Both of those tasks are compiler like
so the Athlon is likely to be the best choice.

In article <9j49st$9m4@dispatch.concentric.net>, "Pete Fraser"
<pete@rgb.com> wrote:

> We're upgrading a few of our old 800 MHz PIII machines to speed Xilinx
> design.
> 
> Has anybody published benchmarks to indicate if we'd be better of with
> fast Athlons or Fast P 4s?
> 
> Thanks.
> 
>

Article: 33548
Subject: How to add carry optimizations
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Mon, 30 Jul 2001 23:59:00 +1000
Links: << >>  << T >>  << A >>
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: 33549
Subject: Help: Simple counter example in WebPack schamatic capture
From: thedimreaper@hotmail.com (Jack Nimble)
Date: 30 Jul 2001 07:08:28 -0700
Links: << >>  << T >>  << A >>
I am quite new to this and am having all manner of problems designing
a counter with the schematic capture side of Xilinx's WebPack.

I am trying to implement a 16-bit binary counter using the library
model CB16CE the output of which is read through 2 8-bit tri-state
buffers hooked to a data bus.

But no matter how I split/wire up the busses between the devices the
WebPack compilation process fails with errors. Some say I have nothing
connected to the 16 outputs of the counter, when from the schematic I
have. If I try another way it complains about net names.

Could some kind sole email me a schematic of such a counter that I
could investigate?

I've been through the help system specifically the part about busses
but I can't get a grip on what I'm doing wrong.

Many thanks 

JN



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search