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 46800

Article: 46800
Subject: Re: XCR3384XL availability
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 09 Sep 2002 11:40:11 -0400
Links: << >>  << T >>  << A >>
I am not clear on what you are saying.  Based on the number of cells in
these chips, the area should be 50% larger.  So you will get about 1/3
less die and you will have 50% more area to see defects in.  The price
of the 384XL is 3:1 over the 256XL price.  Because of the lower number
of 384XL die on the wafer, multiply the price of the 256XL by 3/2, now
the ratio is 2:1.  

I think if you do the math, you will see that a 50% increase in chip
area does not make a 50% reduction in yield unless your yield is already
pretty low.  

Just how tiny are these two parts?  


Austin Lesea wrote:
> 
> Falk,
> 
> That is a bit unfair.
> 
> Larger die parts cost more to make, because the yield is less.  That is
> semiconductor physics 101.
> 
> To imply a yield "problem" is misleading, and untrue.
> 
> And, quite frankly, a bit absurd.  After all, it is a CPLD, is absolutely tiny
> compared to the FPGAs that we make.
> 
> Austin
> 
> Falk Brunner wrote:
> 
> > "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
> > news:3D78D726.A3FA9369@yahoo.com...
> > > I have received an email reply from Xilinx which says that the XCR3384XL
> > > device is significantly more expensive to make than the XCR3256XL and so
> > > there are no plans to significantly reduce the price.
> >
> > Hmm, looks like a yield problem. So you will end up by using two 256er
> > devices, wont you?
> > --
> > MfG
> > Falk

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 46801
Subject: SystemC query
From: Vikram Chandrasekhar <cvikram@ruf.rice.edu>
Date: Mon, 9 Sep 2002 10:42:01 -0500
Links: << >>  << T >>  << A >>

 Hi,

 I have a specific query regarding the fixed point conversion routines
 in SystemC. I have observed that while using the SC_TRN (trruncation mode)
 of quantization, there is an anamoly that I am unable to figure out.

 Say we have a variable "x" quantized with "wl" bits and "iwl" integer
 bits. In the SC_TRN mode, all values of x in the range [-1/2^(wl-iwl),0]
 get quantized to 0. However, I expect the quantization to be towards
 -1/2^(wl-iwl)  as SC_TRN represents the round towards minus infinity mode.
 why is this discrepency occuring?

 Can anyone please advice.
 Thanks
 Vikram


Article: 46802
Subject: Re: symplicity conv_integer problem
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Mon, 09 Sep 2002 09:12:12 -0700
Links: << >>  << T >>  << A >>
Nikhil Bhatia wrote:

In the following code, synplicity removes the "sk_wroffset_ctr_en " i.e optimises away.


Perhaps sk_wroffset_ctr_en is never assigned to a port pin.

Perhaps wroffset_ctr_en(i) evaluates to a constant.

Consider running a sim and tracing the code.

     -- Mike Treseler


Article: 46803
Subject: Re: XCR3384XL availability
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 09 Sep 2002 09:24:49 -0700
Links: << >>  << T >>  << A >>
Rick,

I am saying it has nothing to do with yield.  Yield is not a factor.

I defer to Peter's answer.

Austin


rickman wrote:

> I am not clear on what you are saying.  Based on the number of cells in
> these chips, the area should be 50% larger.  So you will get about 1/3
> less die and you will have 50% more area to see defects in.  The price
> of the 384XL is 3:1 over the 256XL price.  Because of the lower number
> of 384XL die on the wafer, multiply the price of the 256XL by 3/2, now
> the ratio is 2:1.
>
> I think if you do the math, you will see that a 50% increase in chip
> area does not make a 50% reduction in yield unless your yield is already
> pretty low.
>
> Just how tiny are these two parts?
>
> Austin Lesea wrote:
> >
> > Falk,
> >
> > That is a bit unfair.
> >
> > Larger die parts cost more to make, because the yield is less.  That is
> > semiconductor physics 101.
> >
> > To imply a yield "problem" is misleading, and untrue.
> >
> > And, quite frankly, a bit absurd.  After all, it is a CPLD, is absolutely tiny
> > compared to the FPGAs that we make.
> >
> > Austin
> >
> > Falk Brunner wrote:
> >
> > > "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
> > > news:3D78D726.A3FA9369@yahoo.com...
> > > > I have received an email reply from Xilinx which says that the XCR3384XL
> > > > device is significantly more expensive to make than the XCR3256XL and so
> > > > there are no plans to significantly reduce the price.
> > >
> > > Hmm, looks like a yield problem. So you will end up by using two 256er
> > > devices, wont you?
> > > --
> > > MfG
> > > Falk
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 46804
Subject: Re: Metastability numbers
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 9 Sep 2002 18:30:02 +0200
Links: << >>  << T >>  << A >>
"Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag
news:3D7C176F.D6CA850F@earthlink.net...

> If I can decypher your drawing, thta's exactly what we use for measuring.
> Look at XAPP094...

Hmmm.
If I got it right, you have a free running clock with 50 MHz and another
free running 350 Mhz clock for sampling.
Both clock are NOT related to each other by deriving them from the same
clock source or by use of a PLL.
In this case, the phase drift between the two clocks is undefined, random.
What does it mean?
If the two clock would be derived from the same source (350 MHz divided by 7
yields 50 Mhz) or phase coupled by a PLL, you would see a steady phase
relation on your scope (if you trigger on the 50 MHz, not the 350 MHz ;-)
If the two sources are real independent but exactly tuned, you would see
this steady picture too, but not for a long time, since tempeature drift and
other things will detune the oscillators.
If you detune the two clocks by a given amount (some ppm), then there will
be a given "crash" frequency, which is the number of transition crossing
(data and sampling clock edges are happen simultaneously) that will cause
metastable events.

So how is this handeled in the setup? The application note just speaks about
unrelated clocks. But with such a setup, is it possible to reproduce the
measurement results? May it be possible that you just catch a (un)lucky
canned oscillator and measure house numbers, since the "crash" frequency is
totaly random.
In the "bible" of Graham & Johnson, there is a circuit for metastability
experiments. Why not using this one (or something similar). In my eyes, this
cicuit gives much more possibilities to do repeatable mesurements. Yes, the
original circuit produces metastable events with every sampling edge, which
is not the case in real applications. But wouldnt it be better to do a
maximum stress test and after this scale down to real application numbers,
just as it is done with power consumtion (average toggle rate)?

Just some ideas.

--
MfG
Falk






Article: 46805
Subject: Re: C/C++ to Verilog/VHDL ?!
From: johnjakson@earthlink.net (John Jakson)
Date: 9 Sep 2002 09:32:47 -0700
Links: << >>  << T >>  << A >>
Frank

Instead of beating on C/C++/Java/.. to create HDL logic, you really
could do a better job the other way around.

Learn/use a simple subset of structural Verilog/VHDL that synthesizes
easily to FPGA and the tools are not too expensive or even free. Then
you can also reverse compile the same Verilog to C for really fast
simulations.

In most of my work I do a structural C model 1st then rewrite as
Verilog almost 1 to 1 mapping. The Verilog code can then be put back
through V2C to produce a C model that is equiv to Verilog but only
runs about 2-5x slower than the best case hand written C model. I hope
to release (gpl) this compiler when it is more user friendly but there
are others out there too some for free. With the C model in hand you
can also ship that as a perfectly good but much slower model of youy
app. Now the C model can simulate many times faster than Verilog and
you can also tweak the code to reduce the V2C penalties while getting
the benfit of the maintenance being mostly on Verilog source. Win win
alround & no $70K C to V to buy.

IMHO using just C to do asic/fpga design is like driving a car from
the back seat!

Article: 46806
Subject: Re: XCR3384XL availability
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 09 Sep 2002 12:36:06 -0400
Links: << >>  << T >>  << A >>
Mikeandmax wrote:
> 
> OR - just perhaps evaluate Lattice ispMACH4384 - it is available in 1.8, 2.5
> and 3.3v versions - is also an extremely low current technology - Lattice went
> to an all CMOS gate structure in this family - no sense amplifiers to gobble up
> current.
> 
> oops, affiliation and all that stuff -
> 
> Michael Thomas
> LSC SFAE
> for the latest info on Lattice products - http://www.latticesemi.com


Hmmm... you are going to make me work for this one aren't you?  I
checked the Lattice web site and the search says that ispMACH4384 is not
a valid part number.  Ah, there it is the ispMACH4384V.  This part does
not seem to be 5 volt tolerant, no?  

Can you help me out a little?  I don't see a clear selection guide and I
am working over a very low speed data link today.  Can you find the
parts that meet my criteria?  I had pretty well settled on the
XCR3256XL, but if you have something cheaper, I would love to hear about
it.  

Requirements:

small package such as 256 fine pitch BGA (17 mm sq)
>=256 macrocells
>160 IOs
very low idle current
low operating current
3.3 volt Vcc 
JTAG boundary scan
JTAG programming
onchip memory for FIFOs would be useful, but not required
memory will allow fewer macrocells >140


Thanks,


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 46807
Subject: Re: XCR3384XL availability
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 09 Sep 2002 09:42:04 -0700
Links: << >>  << T >>  << A >>

--------------EA8EA0260D7110C20687AC52
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

I thought that I had explained it pretty well ( see below).

rickman wrote:

> I am not clear on what you are saying.  Based on the number of cells in
> these chips, the area should be 50% larger.

More than that, the routing grows overproportionally.

> So you will get about 1/3
> less die and you will have 50% more area to see defects in.

Wrong, see above

> The price
> of the 384XL is 3:1 over the 256XL price.  Because of the lower number
> of 384XL die on the wafer, multiply the price of the 256XL by 3/2, now
> the ratio is 2:1.
>
> I think if you do the math, you will see that a 50% increase in chip
> area does not make a 50% reduction in yield unless your yield is already
> pretty low.

Let's avoid "yield" and use the more common "net die per wafer".
Net die per wafer will be substantially less ( or should I say fewer) due to
overproportional chip size plus the effect of defect density limitations ( which
kicks in at large chip sizes)..

Just read my previous posting, repeated here:

The original question was:
Why four times the price for 50% more macrocells?

Here is an attempt at a rational explanation.
There are five factors that contribute to disproportionate pricing:

1. More chip area. CPLDs don't grow linearly, their interconnect grows
faster. (Different from FPGAs)
2. Lower yield due to defect density on the wafer. That increases the cost for
any die faster than the growth of the die area. (Semiconductor Physics 101)
3. Lower production volume. High volume drives cost down. The reverse is also
true.
4. Fancier package.
5. And finally: Less competitive pressure. Everybody will understand this.

These are the five factors that make the '384 overproportionally more expensive
than the '256.
You might argue about each individual factor, but you cannot overcome their
composite effect.
But CoolRunner-II uses smaller geometries and will be less expensive...

Peter Alfke, Xilinx Applications








Article: 46808
Subject: Re: Polyphase filtering...
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 09 Sep 2002 12:56:30 -0400
Links: << >>  << T >>  << A >>
Noddy wrote:
> 
> Hi,
> 
> Sorry, been at conference and so haven't been able to respond.
> 
> > This is all true.  I expect that number 3 is what the OP would be
> > looking for, but he was not clear in his problem statement.
> 
> Ok, this is my problem. I am building a filterbank receiver (to be precise,
> its a pulsar timer, but that is irrelevant) for a radio astronomy
> observatory. Hence, at the moment the design wil just quite a few boards
> with FPGAs on, each with a complex low pass filter (I am using quadrature
> signals). All have the same characteristics, and I do some digital complex
> mixing prior to the filters to shift the signals about DC.
> 
> What I was thinking of doing was, since the filters have a cutoff of  0.125,
> I could move all the filtering onto a single FPGA by implementing a
> polyphase filter with N=8, followed by FFT etc. etc.
> 
> What do you think?
> 
> Adrian

That is exactly what polyphase filtering is good for.  You can get by
with less hardware.  But make sure you are not going to suffer from the
rolloff at your filter edge.  The cutoff is not absolute and should be
slightly below the decimated Nyquist rate to allow the transistion band
to remove all artifacts before you reach the decimated Nyquist rate. 
The decimated Nyquist rate should be in the stop band rather than at the
cutoff, or at least 1/2 way though the transistion band (which results
in the same amount of "junk" but will make it slightly harder to further
filter).  
    
_______ 
       \ ____ cutoff (-6dB)
        \
         \
          \   Transistion band
           + ---  Put Nyquist rate no lower than here
            \
             \
              \  Stop band
               \________________

Result after midtransistion band frequency folding
The transition band above the Nyquist rate is folded into the 
same freqs as the transition band below the Nyquist rate
_______ 
       \
        \
         \
          \   
           >
          /
         /
        /
_______/

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 46809
Subject: atmel CPLD documentation
From: eccles@a-znet.com (George Eccles)
Date: Mon, 09 Sep 2002 17:14:04 GMT
Links: << >>  << T >>  << A >>
I am considering using an Atmel ATF15xx series CPLD.  This would be my
first PLD of any sort, and I'm a little bit floundering.  For
instance, the part data sheet says that outputs can be configured for
"open-collector" (open drain?) operation; but, I don't find any
mention of that in the  "Programmer's Reference Guide".

Is there other documentation on these parts?  Or, is there a better
way to learn this stuff?

Thanks,
George


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Article: 46810
Subject: Re: why the need for HIGH speed design?
From: lng <>
Date: Mon, 9 Sep 2002 10:25:24 -0700
Links: << >>  << T >>  << A >>
I would like to know  if anyone do FFT filter for NTSC or PAL in real time?

Article: 46811
(removed)


Article: 46812
Subject: Re: XCR3384XL availability
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 9 Sep 2002 18:46:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote:
...
: Can you help me out a little?  I don't see a clear selection guide and I
: am working over a very low speed data link today.  Can you find the
: parts that meet my criteria?  I had pretty well settled on the
: XCR3256XL, but if you have something cheaper, I would love to hear about
: it.  

: Requirements:

: small package such as 256 fine pitch BGA (17 mm sq)
:>=256 macrocells
:>160 IOs
: very low idle current
: low operating current
: 3.3 volt Vcc 
: JTAG boundary scan
: JTAG programming
: onchip memory for FIFOs would be useful, but not required
: memory will allow fewer macrocells >140

Coolrunner II may be an alternative, also it seems no general available
yet...

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 46813
(removed)


Article: 46814
Subject: Re: atmel CPLD documentation
From: eccles@a-znet.com (George Eccles)
Date: Mon, 09 Sep 2002 18:57:16 GMT
Links: << >>  << T >>  << A >>
On Wed, 04 Sep 2002 23:30:43 -0500, Mike Rosing
<rosing@neurophys.wisc.edu> wrote:

>George Eccles wrote:
>> I am considering using an Atmel ATF15xx series CPLD.  This would be my
>> first PLD of any sort, and I'm a little bit floundering.  For
>> instance, the part data sheet says that outputs can be configured for
>> "open-collector" (open drain?) operation; but, I don't find any
>> mention of that in the  "Programmer's Reference Guide".
>> 
>> Is there other documentation on these parts?  Or, is there a better
>> way to learn this stuff?
>
>I just looked at an ATF1500 and I don't see it as having open-collector
>drivers.  I've never used these parts tho, so maybe I'm missing
>something.

It's on the first page of the data sheet I'm looking at:

   " Programmable Output Open Collector Option per Macrocell"

> What tools are you going to use to program the parts with?
>Can you run them now?  Can you get a demo version and try it out?

Don't know, no, no.  I'm just getting starting, trying to decide if it
will do what I need.

>You may be able to hit the "help" button and do a search for
>"open-collector" and find the right place to set your outputs up.

Done that (in CUPL); it doesn't appear to be listed.

George



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Article: 46815
Subject: Re: XCR3384XL availability
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 10 Sep 2002 07:27:49 +1200
Links: << >>  << T >>  << A >>
rickman wrote:
> 
> I am not clear on what you are saying.  Based on the number of cells in
> these chips, the area should be 50% larger.  So you will get about 1/3
> less die and you will have 50% more area to see defects in.  The price
> of the 384XL is 3:1 over the 256XL price.  Because of the lower number
> of 384XL die on the wafer, multiply the price of the 256XL by 3/2, now
> the ratio is 2:1.
> 
> I think if you do the math, you will see that a 50% increase in chip
> area does not make a 50% reduction in yield unless your yield is already
> pretty low.

 For reference points, here is info from Lattice Web :

# Pricing for the ispXPLD5512MC in volumes of >1000 pieces 
# starts at $17.75

# For high-volume applications, the ispMACH 4512C will be 
# priced below $15.00.

# Projected pricing for the ispMACH5768VG is as low as 
# $33.00 in high-volume for the second half of 2002

 Seems they also have a steepening of the price curve, but at 512->768,
not 256->384.

-jg

Article: 46816
Subject: Re: Metastability numbers
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 09 Sep 2002 12:39:13 -0700
Links: << >>  << T >>  << A >>


Falk Brunner wrote:

> Hmmm.
> If I got it right, you have a free running clock with 50 MHz and another
> free running 350 Mhz clock for sampling.
> Both clock are NOT related to each other

True, one is a canned crystal oscillator of 50 MHz, the other one is an hp
pulse generator.
Since the measurements give repeatable results that fit the exponential
relationship between extra settling time and MTBF, I like this method. But I
will look up the Howard Johnson "bible", it's right here on my bookshelf.

Peter

> So how is this handeled in the setup? The application note just speaks about
> unrelated clocks. But with such a setup, is it possible to reproduce the
> measurement results? May it be possible that you just catch a (un)lucky
> canned oscillator and measure house numbers, since the "crash" frequency is
> totaly random.

No, I vary the hp output frequency around 350 MHz. We have changed the
chip-internal design, giving us different interconnect delays, and the results
have moved accordingly. All very repeatable, albeit statistical.

>
> In the "bible" of Graham & Johnson, there is a circuit for metastability
> experiments. Why not using this one (or something similar). In my eyes, this
> cicuit gives much more possibilities to do repeatable mesurements.

Mine are repeatable already.

> Yes, the
> original circuit produces metastable events with every sampling edge,

No, I sample 50 MHz with a >300 MHz clock. Most samples are naturally far away
from the metastability-inducing window.

> which
> is not the case in real applications.

What happens in a "real" application? I think I am close to a real
synchronizing case.

> But wouldnt it be better to do a
> maximum stress test and after this scale down to real application numbers,

I think that's what I am doing, when the circuit goes matastable many times a
minute...

Mit freundlichen Gruessen, that's what MfG stands for in German  :-)
Peter

>
> just as it is done with power consumtion (average toggle rate)?
>
> Just some ideas.
>
> --
> MfG
> Falk


Article: 46817
Subject: Re: Metastability numbers
From: nospam <nospam@please.com>
Date: Mon, 09 Sep 2002 20:45:52 +0100
Links: << >>  << T >>  << A >>
"Falk Brunner" <Falk.Brunner@gmx.de> wrote:

>"Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag
>news:3D7C176F.D6CA850F@earthlink.net...
>
>> If I can decypher your drawing, thta's exactly what we use for measuring.
>> Look at XAPP094...
>
>Hmmm.
>If I got it right, you have a free running clock with 50 MHz and another
>free running 350 Mhz clock for sampling.
>Both clock are NOT related to each other by deriving them from the same
>clock source or by use of a PLL.
>In this case, the phase drift between the two clocks is undefined, random.

I don't see it matters. As long as the clocks beat and the beat period is
small compared to the measurement time.  

During a measurement period the number of times both clock edges occur
within a given metastability window only depends on the ratio of the
clocks, a few ppm off frequency gives a few ppm measurement error. 

I would be concerned about the clocks interacting with each other, a minute
amount of jitter induced in one clock by the other could really distort the
measurement. 

I think I would keep the clock generators physically separate with the
device under test in the middle that way the device gets to see both clocks
before the generators get to see each other.



Article: 46818
Subject: Re: Metastability numbers
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 09 Sep 2002 13:19:05 -0700
Links: << >>  << T >>  << A >>


nospam wrote:

>
> I think I would keep the clock generators physically separate with the
> device under test in the middle that way the device gets to see both clocks
> before the generators get to see each other.

Sure, done that.
Remember, I have been at this, on and off, for 14 years...
Ciao
Peter Alfke



Article: 46819
Subject: Re: C/C++ to Verilog/VHDL ?!
From: "Frank Andreas de Groot" <nospam@nospam.com>
Date: Mon, 09 Sep 2002 20:57:08 GMT
Links: << >>  << T >>  << A >>
You are right but my problem is twofold, first I don't know VHDL, I bought a
book about digital design and VHDL and it's pretty straightforward, but the
main thing is, my "algorithm" is huge in hardware, I couldn't easily make
that within a year... If I would specify it in C, it would be several nested
loops with lots of pattern recognition and very complex decisions. No way I
will ever get that to work in VHDL. And I need to tweak it all the time,
radically change it maybe, and I can start all over again in VHDL...
We are talking about a newbie here, trying to put some major artificial
intelligence into a FPGA...

My idea was to code in C/Java, get a slow but working FPGA fast to play
with, slowly learn VHDL at the same time, and replace more and more of my
C/Java by handcoded VHDL. Comparable to coding a quick prototype, a proof of
concept in Visual Basic, and then refining routine by routine, after which
you hand-optimize it in assembly...

In 1 week I'll get the board and I'm very anxious to get started...
I'll sure try to code some Verilog or VHDL myself. I *need* the end result
to be as fast as possible. It might even be that there is no gain at all
when using a high-level procedural language converter...

Frank


"John Jakson" <johnjakson@earthlink.net> wrote in message
news:38111bbc.0209090832.50335d7a@posting.google.com...
>
> Instead of beating on C/C++/Java/.. to create HDL logic, you really
> could do a better job the other way around.




Article: 46820
Subject: Re: Metastability numbers
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 10 Sep 2002 08:57:08 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Falk Brunner wrote:
<snips> 
> True, one is a canned crystal oscillator of 50 MHz, the other one is an hp
> pulse generator.
> > So how is this handeled in the setup? The application note just speaks about
> > unrelated clocks. But with such a setup, is it possible to reproduce the
> > measurement results? May it be possible that you just catch a (un)lucky
> > canned oscillator and measure house numbers, since the "crash" frequency is
> > totaly random.
> 
> No, I vary the hp output frequency around 350 MHz. We have changed the
> chip-internal design, giving us different interconnect delays, and the results
> have moved accordingly. All very repeatable, albeit statistical.

 Maybe you should document this as 50Mhz[Xtal], and 350MHz+dF[Generator]
- one problem with saying 50MHz and 350MHz is the (possible) 
inference of a x7 integer ratio. 

 or quoting as : 50.000Mhz and 350.010MHz ?

-jg

Article: 46821
Subject: differences between CoolRunner XPLA3 and CoolRunner-II?
From: jjjkkl@hotmail.com (John)
Date: 9 Sep 2002 14:06:40 -0700
Links: << >>  << T >>  << A >>
What are the fundamental differences between Xilinx's CoolRunner XPLA3
and CoolRunner-II? And which family tends to use the least power?

Article: 46822
Subject: Re: Metastability numbers
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 09 Sep 2002 14:09:47 -0700
Links: << >>  << T >>  << A >>

Falk Brunner wrote:

> In the "bible" of Graham & Johnson, there is a circuit for metastability
> experiments. Why not using this one (or something similar). In my eyes, this
> cicuit gives much more possibilities to do repeatable mesurements.

With all due respect to Howard Johnson ( we know each other and have met twice
), his book is nine years old, and his examples are even older. Maybe he could
successfully conduct such experiments when natural delays were 10 ns, and even
longer in the case of TTL.
Now we are talking about hundred picoseconds, and I see no way of balancing a
circuit under these circumstances.
And why even try to do it, when the statistical approach gives repeatable and
justifyable results ?
It worked in 1988 and 1995. Later I had a problem and got discouraged. Now,
with much better clocking structures, we do it again. It's tough to argue
against a successful set-up, isn't it?
But, "this is a free country" and the chips are programmable. Anybody with
minimal resources is capable to verify the results, or come up with a different
set-up. I am amazed that some university hasn't done it already. I haven't
heard from Washington U. (Dick Chaney) lately, they sure know a lot about
metastability...

Peter Alfke, Xilinx Applications


Article: 46823
Subject: Re: Altera Stratix DSP Performance
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 10 Sep 2002 09:16:13 +1200
Links: << >>  << T >>  << A >>
Xanatos wrote:
> 
> Although I usually take press releases with a grain of salt, I have heard
> lots of great things about Stratix and DSP...However, it seems like Altera
> has a winner.
> 
> http://biz.yahoo.com/prnews/020909/sfm036_3.html
> 
> Looks great to me.

Hmmm....

"Altera Stratix DSP Performance Increases Over 500 Percent 
Using Soft Multipliers"

Wow, 500% PERFORMANCE!, now where's that grain of salt...

Oh, here it is :

"Using "soft" multipliers from Stratix(TM)
TriMatrix(TM) memory structures, the number of high-performance 
multipliers in a Stratix FPGA can be increased up to 500 percent."

and suddenly 'Performance' has morphed into 'number',
and 'over' has morphed into 'up to' - and I see no mention of 
the fact that to even get to the quantity level, you consume all the
on chip RAM. ( Real world deployment probability == zero )

Q: Does no one, with even a passing technical literacy, 
ever _read_ these press releases, before they are trotted out ?

Now we know where the 'soap powder' copy writers go to die...

-jg

Article: 46824
Subject: Re: Metastability numbers
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 09 Sep 2002 15:34:04 -0700
Links: << >>  << T >>  << A >>
I used "roughly" and "about" for exactly that reason.
And I assumed people would give me the benefit of the doubt
that I have not (yet) gone completely senile.  :-)
The grey cells are still working under their grey cover.
Have fun, life is too short to be taken seriously!
More data soon (on metastability, that is...)
Ciao
Peter

Jim Granville wrote:

>  Maybe you should document this as 50Mhz[Xtal], and 350MHz+dF[Generator]
> - one problem with saying 50MHz and 350MHz is the (possible)
> inference of a x7 integer ratio.
>
>  or quoting as : 50.000Mhz and 350.010MHz ?
>
> -jg




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