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 14000

Article: 14000
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: John Woodgate <jmw@jmwa.demon.co.uk>
Date: Wed, 6 Jan 1999 21:50:46 +0000
Links: << >>  << T >>  << A >>
<76v9qq$dqp@src-news.pa.dec.com>, Hal Murray <murray@pa.dec.com> wrote,
preferably NOT having sent me a copy by e-mail:
>In article <S4WnzrBY0ok2EwBJ@jmwa.demon.co.uk>, John Woodgate 
><jmw@jmwa.demon.co.uk> writes:
>> <76sf7q$1ip@src-news.pa.dec.com>, Hal Murray <murray@pa.dec.com> wrote:
>> >If the problem is "irrelevant" for "most applications", how do I tell
>> >if I'm working on one where it is relevant?
>> 
>> Assume that it is, until you prove that it isn't. In other words, if it
>> works, OK; if it doesn't, don't rule out metastability as the cause.
>
>
>That's the sort of attitude that gets people burned.  Testing
>a design doesn't tell you it doesn't have any metastability problems.
>It only tells you that they don't happen often enough for your
>tests to catch them.

I was trying to answer a rather paradoxical question briefly. I mean
that even though metastability is rare, ***if you find a problem***,
don't discount metastability as the cause. I didn't mean to imply that
any finite number of working units is a *guarantee* that the next one
will work.

Of course, testing a design, even for an infinite time, does not tell
you that another sample won't fail, but that is not much help. It does
not mean that testing is pointless. 

I don't know whether you have been following this thread, but much of
it, AIUI, is about how difficult it can be to determine *if* a design is
vulnerable to metastability. In such a case, your philosophy of 'design
it right and be sure' cannot be applied. Of course, if it can, it should
be, without question.
-- 
Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. 
OOO - Own Opinions Only. You can fool all of the people some of the time, but 
you can't please some of the people any of the time.

Article: 14001
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: John Woodgate <jmw@jmwa.demon.co.uk>
Date: Wed, 6 Jan 1999 21:56:33 +0000
Links: << >>  << T >>  << A >>
<36934FF2.234F64BD@NOSPAMerols.com>, rk <stellare@NOSPAMerols.com>
wrote, preferably NOT having sent me a copy by e-mail:
>ah, the russian roullette [spell] theory of electronics design.

See my reply in this thread to a much politer critique of what I wrote.

You don't have to be insulting to make your point. In fact, the more you
bluster, the less strong your case seems.

I've survived in electronics for 43 years, and so have my designs: AFAIK
none has failed seriously. It's a bit late for a career change now.
-- 
Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. 
OOO - Own Opinions Only. You can fool all of the people some of the time, but 
you can't please some of the people any of the time.

Article: 14002
Subject: VHDL Bit String Literals
From: "Adam J. Elbirt" <aelbirt@nac.net>
Date: Wed, 06 Jan 1999 14:12:19 -0800
Links: << >>  << T >>  << A >>
Does anyone know the IEEE or Synopsys library that must be added to use
bit string literals with std_logic_vectors?

Thanks.

Adam

Article: 14003
Subject: How to use Special Pins as IO on Xilinx FPGA???
From: asax@my-dejanews.com
Date: Wed, 06 Jan 1999 23:56:06 GMT
Links: << >>  << T >>  << A >>
Hi,

Is there anyone who can tell me how to assign a signal to the special pin on
Xilinx FPGA. I am using XC4028 device and want to use TDO (special pin) as an
output signal in my design. I can not lock this pin using UCF file. Design is
in verilog HDL and I am using leonardo for synthesis.

Any help would be greatly appreciated.

--
Amit Saxena
MTS
GDA Tech. Inc
San Jose, CA

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Article: 14004
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 7 Jan 1999 00:13:32 GMT
Links: << >>  << T >>  << A >>
rk <stellare@NOSPAMerols.com> writes:

Regarding metastability-proof logic...

>i believe the delivery data has slipped ... until just after delivery of the
>perpetual motion machine.

>while modern flip-flops have quite good metastable state characteristics, it
>is impossible to design a guaranteed by law metastable state proof flip-flop.
>the best you can do is describe it statistcally; and you can get good
>performance, making the failure rate insignificant w.r.t. normal cmos device
>failure rates.

As I understood, for a given technology there is an invariant quantity,
something like 
(probability of going metastable)*(length of stay in the metastable state)

You can improve one at the expense of the other.  For example, adding
noise can reduce the time in the metastable state, but will increase
the chance of it happening.  Actually, it is probably a continuous curve
with constant area, where you can reduce the probability of long
metastability while increasing shorter metastability.  If short is short
enough, then you have solved the problem.

Hope this helps,

-- glen



Article: 14005
Subject: Re: which FPGA to choose ?
From: Ray Andraka <randraka@ids.net>
Date: Wed, 06 Jan 1999 19:33:13 -0500
Links: << >>  << T >>  << A >>
A lot depends on your data rates.   For bit parallel arithmetic (DSP) Xilinx 4K is
still a hands down winner.   I've posted several times here regarding the
shortcomings of Altera 10K in this type of application.  Actel has the
advantage/disadvantage of being a one-time programmable part.  From a
reconfiguration for test or functionality standpoint the one time programmables
are a non-starter.  Actel introduced its SPGA last year which is RAM based.  I
have not used that part.  Atmel has some nice offerings if you are working bit
serially or intend to use partial reconfiguration.  For parallel arithmetic, the
lack of a carry chain is a considerable handicap.  For a microprocessor run ACG,
it is quite likely that you can get away with a bit serial circuit and a very
small device.  If that is the case, you might look either at the Atmel 40K (The 6K
is not a good device for the neophyte) or Xilinx Spartan (basically a economy
version of the 4K).

ekuria01@kepler.poly.edu wrote:

> Hello,  I must convert a microcontroller based digital AGC to an FPGA. The
> AGC in question uses relatively simple math (adds, shifts, and Look up
> Tables). I also need to implement digital peak detectors that peak detect
> using and A/D converter.
>
>        I am a novice with FPGAs and my expertiese only extends to micro coding
> for controllers. Any help on how to choose FPGAs, and what company FPGAs sound
> apt for my application will be greatly appreciated.
>
>        Thank you all in advance.
>
> Eldho Kuriakose
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 14006
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Wed, 06 Jan 1999 19:47:17 -0500
Links: << >>  << T >>  << A >>
glen herrmannsfeldt, from caltech, writes:

> rk <stellare@NOSPAMerols.com> writes:
>
> Regarding metastability-proof logic...
>
> >i believe the delivery data has slipped ... until just after delivery of the
> >perpetual motion machine.
>
> >while modern flip-flops have quite good metastable state characteristics, it
> >is impossible to design a guaranteed by law metastable state proof flip-flop.
> >the best you can do is describe it statistcally; and you can get good
> >performance, making the failure rate insignificant w.r.t. normal cmos device
> >failure rates.
>
> As I understood, for a given technology there is an invariant quantity,
> something like
> (probability of going metastable)*(length of stay in the metastable state)

the formula generally used is: mtbf = e^(k2*t)   /   ( k1 * fclk * fdata)

the key here is that it's an exponential function, with w.r.t. t.  no diminishing
returns, here.

an example from chipx, cx2001 (just happen to have the book open)

    clk = 50 MHz

    data = 10 MHz

    time available for nutso behaviour = 10 nsec (1/2 clock period in this case)

    ====> mtbf = 4 x 10^12 years.

as they say, good enough for government work.  and i believe you can find better
flip-flops, too.

===============================================================

> You can improve one at the expense of the other.  For example, adding
> noise can reduce the time in the metastable state, but will increase
> the chance of it happening.  Actually, it is probably a continuous curve
> with constant area, where you can reduce the probability of long
> metastability while increasing shorter metastability.  If short is short
> enough, then you have solved the problem.

yes, run the numbers, and you can make estimates.  but, there is no "solution"
that guarantees that the problem is solved.  everyonce in a while somebody
publishes a "solution" and they quickly get hammerred and confess their sins.

good evening,

rk

=======================================



> Hope this helps,
>
> -- glen



Article: 14007
Subject: fpga socket
From: schaltung@hotmail.com
Date: Thu, 07 Jan 1999 00:52:58 GMT
Links: << >>  << T >>  << A >>
Hi!

Has anyone had any good or bad experience using a socket for a XILINX 160-PIN
PQFP?

I think I found one in ALLIED Catalog that could work. any suggestion?

Antonio Moreno
schaltung@hotmail.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Article: 14008
Subject: Re: fpga socket
From: Ray Andraka <randraka@ids.net>
Date: Thu, 07 Jan 1999 01:11:13 -0500
Links: << >>  << T >>  << A >>
And why is it that you want to socket a Xilinx ?

Using a socket is asking for trouble.  First, you increase the pin inductance so
that the bypassing is not as effective.  More importantly, you greatly reduce the
reliability of the connections.  I recently dealt with a customer that socketed a
bunch of Xilinx.  Almost all of the debug problems were eventually traced to bad
connections either at the socket-chip interface or at the socket board interface
(the socket covers the pads so it is very difficult to properly mount or inspect
the joints).

The xilinx is infinitely programmable, and from my experience not very prone to
failure.  If you screw up board layout, you can re-assign pins.

schaltung@hotmail.com wrote:

> Hi!
>
> Has anyone had any good or bad experience using a socket for a XILINX 160-PIN
> PQFP?
>
> I think I found one in ALLIED Catalog that could work. any suggestion?

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 14009
Subject: Re: fpga socket
From: Chris Eilbeck <chris@yordas.demon.co.uk>
Date: 07 Jan 1999 07:20:10 +0000
Links: << >>  << T >>  << A >>
Ray Andraka <randraka@ids.net> writes:

> The xilinx is infinitely programmable

I think you must have more patience than me, Ray :)

Chris
-- 
Chris Eilbeck
mailto:chris@yordas.demon.co.uk
Linux - Don't fear the Penguin

Article: 14010
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Thu, 07 Jan 1999 09:05:24 GMT
Links: << >>  << T >>  << A >>

Why would adding noise increase the chance of it happening? I am
talking about noise whose spectrum is *below* that of the frequency
response of the feedback loop of the latch in question.

I think adding noise will **not change** the MS behaviour, and
depending on how the noise is made up it might even put an upper limit
on it, e.g. a square wave at 100MHz, injected into the feedback loop,
ought to set an upper limit on the metastable condition of 5ns.

>You can improve one at the expense of the other.  For example, adding
>noise can reduce the time in the metastable state, but will increase
>the chance of it happening.  Actually, it is probably a continuous curve
>with constant area, where you can reduce the probability of long
>metastability while increasing shorter metastability.  If short is short
>enough, then you have solved the problem.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.

Article: 14011
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Thu, 07 Jan 1999 08:06:34 -0500
Links: << >>  << T >>  << A >>
John Woodgate wrote:

> <36934FF2.234F64BD@NOSPAMerols.com>, rk <stellare@NOSPAMerols.com>
> wrote, preferably NOT having sent me a copy by e-mail:
> >ah, the russian roullette [spell] theory of electronics design.
>
> See my reply in this thread to a much politer critique of what I wrote.

why?  what you proposed is EXACTLY the equivalent of russian roullette [still
can't spell] and so, by analogy, makes a point.  of course, in real russian
roullette, a head gets blown off and someone dies; in critical systems for life
support, say, much the same things happen. and us here in the states saw that
sort of attitude back in '86 in the space program where people did get blown up.

unfortunately, the red reset button has become more or less a universal component
of equipment design and leads to a what i would call "bad" design attitude such
as this:

        >>                                                                    In
other words, if it
        >> works, OK; if it doesn't, don't rule out metastability as the cause.

hey, it works, OK, cool.  of course, we saw another engineer who perhaps said it
a tad more elegantly:

        >That's the sort of attitude that gets people burned.  Testing
        >a design doesn't tell you it doesn't have any metastability problems.
        >It only tells you that they don't happen often enough for your
        >tests to catch them.

with respect to polite, Professor, i remember asking a question in another group
(sci.electronics.design) for information to help me in an area out of my field.
you PUBLICLY RIDICULED ME FOR ASKING what you thought was A STUPID QUESTION,
ALTHOUGH IT BECAME APPARRENT [spell?] THAT YOU HAD NO IDEA WHAT YOU ARE TALKING
ABOUT.  additionally, you publicly talk down and ridicule people quite
frequently, and i really don't participate in that group any more, partly because
of dealing with worthless but embarrassing comments from people like you.  so, if
YOU don't like it now, well, too bad.  sorry to burst your ego bubble.  well, no,
not sorry at all.

==================================================

> I was trying to answer a rather paradoxical question briefly.

sorry, no paradox here at all:

>> >If the problem is "irrelevant" for "most applications", how do I tell
>> >if I'm working on one where it is relevant?

i don't see this as a terribly difficult problem or a paradox.  one designs the
system with knowledge about metastable states and architects it accordingly, run
some calculations on the devices in question (or better, choose them
appropriately - say, an appropriate logic family, the best flip-flop macro in the
asic vendor's guide w.r.t. metastability, etc., etc.), and you obtain a failure
rate that you consider acceptable for your application.  then you test it as hard
as you can, giving some evidence that your design is correct, just like any other
parameter.  better yet, when possible, get rid of the asynchronous interfaces, be
done with it.  not really a paradox at all.  as from your previous posts in other
threads, it is apparent that you're not that up on digital logic as your claims
about output drive capability for a simple HCxx buffer were way off, perhaps you
should start with the basics, first, before you continue your blabbering.

=======================================================

>
I mean
>that even though metastability is rare, ***if you find a problem***,
>don't discount metastability as the cause. I didn't mean to imply that
>any finite number of working units is a *guarantee* that the next one
>will work.

        >>                                                                    In
other words, if it
        >> works, OK; if it doesn't, don't rule out metastability as the cause.

well, that's exactly the opposite of what you said.  of course, it doesn't
exactly take a seymour cray to figure out "if it fails, then don't discount x as
a cause automagically."  puh-lease.

========================================

> You don't have to be insulting to make your point.

me insulting?  go look at what you blabber around the internet.  i was just
getting warmed up.

=========================================

>                                                     In fact, the more you
> bluster, the less strong your case seems.

sorry, Professor.  i don't need to bluster and i don't need to make a case.  your
attitude of "if it works, OK" is just bad engineering and that is a fact; no case
to be made.  unless one decides to apply clintonian logic, distinctly different
from the boolean variety.

===========================================

> I've survived in electronics for 43 years, and so have my designs: AFAIK
> none has failed seriously.

hmmm ... i guess that depends on what you consider serious.  of course, one can
read the above as you've been designing stuff with annoying and quirky bugs in it
for a long time but nothing fatal.  i've seen a lot of those sorts of engineers.

============================================

> It's a bit late for a career change now.

it's never too late to change; i do it all the time.  the problems and the
technologies keep on changing.  and the skills needed to succeed keep growing.
on the other hand, perhaps it's time for you to retire.

==============================================

> Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124.
> OOO - Own Opinions Only. You can fool all of the people some of the time, but
> you can't please some of the people any of the time.

yeah, and when YOU learn some manners and stop YOUR rudeness, perhaps you will do
better with of the people that you have trouble with.

rk



Article: 14012
Subject: Re: fpga socket
From: Ray Andraka <randraka@ids.net>
Date: Thu, 07 Jan 1999 08:21:22 -0500
Links: << >>  << T >>  << A >>


Chris Eilbeck wrote:

> > The xilinx is infinitely programmable
>
> I think you must have more patience than me, Ray :)
>

No, possibly more experience though.  While I've seen people use the
programmability as a crutch to bolster bad design practice, it is not
something I do.  A functional simulation followed by a thorough static
timing analysis leads to a near 100% record of first time successes with
xilinx designs.  I have taken advantage of reconfiguration on many
occasions to do very thorough board testing...100% interconnect and at
speed worst case memory pattern testing that would be difficult any
other way.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 14013
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Dan Prysby <dprysby1@email.mot.com>
Date: Thu, 07 Jan 1999 08:35:05 -0600
Links: << >>  << T >>  << A >>
I am aware of the statistical calc for a basic transmission gate FF.

What I am asking is if anyone has heard of facts relating to
a recent effort on a true 100% metastable-proof FF.

Also, until someone does it, it is OK to say it is impossible.
However, I will not put effort into a perpetual motion machine.

Dan Prysby

rk wrote:
> 
> Dan Prysby wrote:
> 
> > I have read that there is effort to design a metastable-proof
> > flip-flop. Anyone have any facts to share?
> 
> i believe the delivery data has slipped ... until just after delivery of the
> perpetual motion machine.
> 
> while modern flip-flops have quite good metastable state characteristics, it
> is impossible to design a guaranteed by law metastable state proof flip-flop.
> the best you can do is describe it statistcally; and you can get good
> performance, making the failure rate insignificant w.r.t. normal cmos device
> failure rates.
> 
> also, about 10 years ago, amd (and perhaps signetics) produced
> metastable-state hardened flip-flops.
> 
> rk

Article: 14014
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: rbmccammon@mmm.com (Roy McCammon)
Date: Thu, 07 Jan 1999 08:59:08 -0600
Links: << >>  << T >>  << A >>
rk wrote:
> EVERY CIRCUIT IS CONSIDERED GUILTY UNTIL PROVEN INNOCENT!

Nice in pricipal, but very difficult to apply
in practice.



Opinions expressed herein are my own and may not represent those of my employer.

Article: 14015
Subject: Re: fpga socket
From: Bob Sefton <rsefton@home.com>
Date: Thu, 07 Jan 1999 15:47:23 GMT
Links: << >>  << T >>  << A >>
I used them on a project 5-6 years ago before ISP was built into
Altera CPLDs. The sockets were an absolute nightmare. I ended up
ripping off the sockets and soldering the 160-pin and 208-pin QFP
parts directly to the board. If a part needed to be reprogrammed
we had to unsolder it and replace it with a new programmed part.
This was expensive, and after a couple of times on the same part
you start to lift pads off the board, but it was inifinitely
better than dealing with the sockets.

Bob S.

schaltung@hotmail.com wrote:
> 
> Hi!
> 
> Has anyone had any good or bad experience using a socket for a XILINX 160-PIN
> PQFP?
> 
> I think I found one in ALLIED Catalog that could work. any suggestion?
> 
> Antonio Moreno
> schaltung@hotmail.com
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

Article: 14016
Subject: Re: fpga socket
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 07 Jan 1999 11:16:45 -0500
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> Chris Eilbeck wrote:
> 
> > > The xilinx is infinitely programmable
> >
> > I think you must have more patience than me, Ray :)
> >
> 
> No, possibly more experience though.  While I've seen people use the
> programmability as a crutch to bolster bad design practice, it is not
> something I do.  A functional simulation followed by a thorough static
> timing analysis leads to a near 100% record of first time successes with
> xilinx designs.  I have taken advantage of reconfiguration on many
> occasions to do very thorough board testing...100% interconnect and at
> speed worst case memory pattern testing that would be difficult any
> other way.

Ray, I think this was just a joke about the idea of spending the rest of
your life programming a Xilinx part "infinitely".   =8^)

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 14017
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Brad Taylor <blt@emf.net>
Date: Thu, 07 Jan 1999 09:24:51 -0800
Links: << >>  << T >>  << A >>
I know,  I'm sure you are right about this, but I can't help trying!  I
guess I shouldn't speculate in so public a forum. At least there is
someone around to catch it. There is another flaw, since the
"integrating" window detector has to detect a transition near threshold
and then remember that for say a few ns, it is in effect a sampling
system which can go metastable.  If the Clock enable's value is
undefined, the FF cannot work of course.

So we have speed of light, law of gravity, time travel, perpetual motion
and metastable free sampling.  I might also add Rob's law of hardware
which states that you cannot install and configure a PC add-in card
without losing a day.

Best Wishes,
Brad



Hal Murray wrote:
> 
> > Someone claims to be developing a 100% metastable-proof FF. Hmmm..,
> > since a FF has to make a decision as to whether a signal is above a
> > threshhold or below it and the signal can be exactly on the threshold,
> > this would seem unlikely.
> 
> It's like the second law of thermo.  There is no way to make a
> metastable-proof FF.  Your alarm bells should ring whenever anybody
> even hints in that direction.
> 
> > Now that I think about it though, perhaps you could use an integrating
> > window detector to determine is a signal was anywhwere near threshold
> > around the sampling window. If so, the FF's clock enable could be
> > disabled. (The delay through the threshold detector could be balanced by
> > a fixed delay of the signal to be sampled using speed of light delay).
> 
> That's a typical example of the sort of kludges that people come up
> with.  In this case, I think I can find the flaw.
> 
> You have just moved the problem.  Remember, you also have to meet
> the setup and hold times for the clock enable.  What if the input
> signal changes a bit earlier so the clock enable is changing at
> the wrong time?
> 
> --
> These are my opinions, not necessarily my employers.

Article: 14018
Subject: Re: FPGA development system
From: Richard Schwarz <aps@associatedpro.com>
Date: Thu, 07 Jan 1999 14:03:17 -0500
Links: << >>  << T >>  << A >>
Renzo,

Check out our site at http://www.associatedpro.com . Also you might want
to check with the specific vendors to see if they will give you
materials if your affiliated with a University.

renzo.arce@st.com wrote:

> Hi,
>
> I am implementing a hardware lab. for our research's group and
> I must to make a decision on whish FPGA development system to buy
> (Altera, Xilinx, etc).
>
> We develop research's projects and we need a system hw/sw to
> simulate, debbuging and hardware implementation of advanced
> algorithm applications.
>
> Somebody can give me some suggest?
>
> Best regards
>
> Renzo Arce
> STMicroelectronics
> Italy
> renzo.arce@st.com



--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

    Richard Schwarz, President
    Associated Professional Systems Inc. (APS)
    email: richard@associatedpro.com
    web site: http://www.associatedpro.com
    Phone: 410-569-5897
    Fax:   410-661-2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 14019
Subject: Re: fpga socket
From: Mike Treseler <tres@tc.fluke.com>
Date: Thu, 07 Jan 1999 11:15:56 -0800
Links: << >>  << T >>  << A >>
schaltung@hotmail.com wrote:

> Has anyone had any good or bad experience using a socket 

IC sockets are evil. Solder it in.

         -Mike Treseler

Article: 14020
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Jamie Lokier <spamfilter.dec1998@tantalophile.demon.co.uk>
Date: 07 Jan 1999 19:37:08 +0000
Links: << >>  << T >>  << A >>
Peter  writes:

> I think adding noise will **not change** the MS behaviour, and
> depending on how the noise is made up it might even put an upper limit
> on it, e.g. a square wave at 100MHz, injected into the feedback loop,
> ought to set an upper limit on the metastable condition of 5ns.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think you're being optimistic here.

A simple 100MHz signal will reduce the likelihood of the metastable
condition exceeding 5ns, but won't, as far as I know, guarantee to limit
it.

I don't know if it's possible to construct a device that guarantees a
metastability time limit.  I am not convinced by the hand-waving
arguments around here that say it's impossible -- but the maths is not
simple.  A real device does not have one or two continuous state
parameters, but infinitely many (think of the internal energy flows).

-- Jamie

Article: 14021
Subject: Re: fpga socket
From: Ray Andraka <randraka@ids.net>
Date: Thu, 07 Jan 1999 16:30:08 -0500
Links: << >>  << T >>  << A >>
Yeah, I got the joke now.  When I first read it, I was a bit bleary-eyed and
it went right over my head.

Nice to see others think sockets are the devil's work.  I'm working with a
customer right now that is insisting on socketing memories and a xilinx.  No
amount of convincing is changing his mind.  Guess I'll be spending time in the
lab!

Rickman wrote:

> Ray Andraka wrote:
> >
> > Chris Eilbeck wrote:
> >
> > > > The xilinx is infinitely programmable
> > >
> > > I think you must have more patience than me, Ray :)
> > >
> >
> > No, possibly more experience though.  While I've seen people use the
> > programmability as a crutch to bolster bad design practice, it is not
> > something I do.  A functional simulation followed by a thorough static
> > timing analysis leads to a near 100% record of first time successes with
> > xilinx designs.  I have taken advantage of reconfiguration on many
> > occasions to do very thorough board testing...100% interconnect and at
> > speed worst case memory pattern testing that would be difficult any
> > other way.
>
> Ray, I think this was just a joke about the idea of spending the rest of
> your life programming a Xilinx part "infinitely".   =8^)
>
> --
>
> Rick Collins
>
> redsp@XYusa.net
>
> remove the XY to email me.



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 14022
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: John Woodgate <jmw@jmwa.demon.co.uk>
Date: Thu, 7 Jan 1999 21:31:04 +0000
Links: << >>  << T >>  << A >>
<3694B15A.83DA0E4D@NOSPAMerols.com>, rk <stellare@NOSPAMerols.com>
wrote, having noted that I prefer NOT to receive an e-mail copy:
>John Woodgate wrote:
>
>> <36934FF2.234F64BD@NOSPAMerols.com>, rk <stellare@NOSPAMerols.com>
>> wrote, preferably NOT having sent me a copy by e-mail:
>> >ah, the russian roullette [spell] theory of electronics design.
>>
>> See my reply in this thread to a much politer critique of what I wrote.
>
>why?  what you proposed is EXACTLY the equivalent of russian roullette [still
>can't spell] 

rest of diatribe snipped.

For every one of these rabid ravings, I get a number of thank-you
messages. Maybe we should have a referendum on whether I or 'rk' should
be banned from this NG?
-- 
Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. 
OOO - Own Opinions Only. ERROR! OUT OF CORNFLAKES. Please check cereal port 
configuration.

Article: 14023
Subject: Re: fpga socket
From: Brad Taylor <blt@cmln.com>
Date: 07 Jan 1999 15:25:34 PST
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------DF023B657AD628E5B009B72B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Bob Sefton wrote:
> 
> I used them on a project 5-6 years ago before ISP was built into
> Altera CPLDs. The sockets were an absolute nightmare. I ended up
> ripping off the sockets and soldering the 160-pin and 208-pin QFP
> parts directly to the board. If a part needed to be reprogrammed
> we had to unsolder it and replace it with a new programmed part.
> This was expensive, and after a couple of times on the same part
> you start to lift pads off the board, but it was inifinitely
> better than dealing with the sockets.
> 

There is really nothing wrong with occasional desoldering if the pads
don't lift. As I recall using the better grades of epoxy-fiberglass or
polyamide will eliminate the lifted pads. You do need to find a good
experienced re-work shop though.

-
Brad




> Bob S.
> 
> schaltung@hotmail.com wrote:
> >
> > Hi!
> >
> > Has anyone had any good or bad experience using a socket for a XILINX 160-PIN
> > PQFP?
> >
> > I think I found one in ALLIED Catalog that could work. any suggestion?
> >
> > Antonio Moreno
> > schaltung@hotmail.com
> >
> > -----------== Posted via Deja News, The Discussion Network ==----------
> > http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

--
--------------DF023B657AD628E5B009B72B
Content-Type: text/x-vcard; charset=us-ascii;
 name="blt.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brad Taylor
Content-Disposition: attachment;
 filename="blt.vcf"

begin:vcard 
n:Taylor;Brad
tel;work:1-408-730-3300 ext108
x-mozilla-html:FALSE
url:www.cmln.com
org:Chameleon Systems;Applications
version:2.1
email;internet:blt@cmln.com
title:Director of Applications
adr;quoted-printable:;;1195 W. Fremont Ave=0D=0A;Sunnyvale;CA;94087-3825;USA
note;quoted-printable:Chameleon Systems is a fabless semiconductor company. Chameleon=0D=0Ais developing a new class of devices known as ASPPs for=0D=0A"Application Specific Programmable Device". Please contact me=0D=0Adirectly for more information about our product line at=0D=0Ablt@cmln.com=0D=0A=0D=0A
fn:Brad Taylor
end:vcard

--------------DF023B657AD628E5B009B72B--

Article: 14024
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10
From: Brad Taylor <blt@cmln.com>
Date: 07 Jan 1999 17:04:30 PST
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------3CFBDA44DDDCFB9D24338EF5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Someone claims to be developing a 100% metastable-proof FF. Hmmm..,
since a FF has to make a decision as to whether a signal is above a
threshhold or below it and the signal can be exactly on the threshold,
this would seem unlikely. 

Now that I think about it though, perhaps you could use an integrating
window detector to determine is a signal was anywhwere near threshold
around the sampling window. If so, the FF's clock enable could be
disabled. (The delay through the threshold detector could be balanced by
a fixed delay of the signal to be sampled using speed of light delay).  

I'm used to thinking of sampling being a metastable functions as a law
of the universe, so I must be missing something. 

Best Wishes,
Brad



Dan Prysby wrote:
> 
> I am aware of the statistical calc for a basic transmission gate FF.
> 
> What I am asking is if anyone has heard of facts relating to
> a recent effort on a true 100% metastable-proof FF.
> 
> Also, until someone does it, it is OK to say it is impossible.
> However, I will not put effort into a perpetual motion machine.
> 
> Dan Prysby
> 
> rk wrote:
> >
> > Dan Prysby wrote:
> >
> > > I have read that there is effort to design a metastable-proof
> > > flip-flop. Anyone have any facts to share?
> >
> > i believe the delivery data has slipped ... until just after delivery of the
> > perpetual motion machine.
> >
> > while modern flip-flops have quite good metastable state characteristics, it
> > is impossible to design a guaranteed by law metastable state proof flip-flop.
> > the best you can do is describe it statistcally; and you can get good
> > performance, making the failure rate insignificant w.r.t. normal cmos device
> > failure rates.
> >
> > also, about 10 years ago, amd (and perhaps signetics) produced
> > metastable-state hardened flip-flops.
> >
> > rk

-- 
-------------------------------------------
Brad Taylor     Chameleon Systems
Phone:          1-408-730-3300 ext 108
Fax:            1-408-730-3303
Email:          <Brad Taylor>blt@cmln.com
WWW:            www.cmln.com
Location:       1195 W. Fremont Ave
                Sunnyvale, CA 94087-3825
-------------------------------------------
--------------3CFBDA44DDDCFB9D24338EF5
Content-Type: text/x-vcard; charset=us-ascii;
 name="blt.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brad Taylor
Content-Disposition: attachment;
 filename="blt.vcf"

begin:vcard 
n:Taylor;Brad
tel;work:1-408-730-3300 ext108
x-mozilla-html:FALSE
url:www.cmln.com
org:Chameleon Systems;Applications
version:2.1
email;internet:blt@cmln.com
title:Director of Applications
adr;quoted-printable:;;1195 W. Fremont Ave=0D=0A;Sunnyvale;CA;94087-3825;USA
note;quoted-printable:Chameleon Systems is a fabless semiconductor company. Chameleon=0D=0Ais developing a new class of devices known as ASPPs for=0D=0A"Application Specific Programmable Device". Please contact me=0D=0Adirectly for more information about our product line at=0D=0Ablt@cmln.com=0D=0A=0D=0A
fn:Brad Taylor
end:vcard

--------------3CFBDA44DDDCFB9D24338EF5--



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