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 8375

Article: 8375
Subject: Re: what is metastability time of a flip_flop
From: John Woodgate <jmw@jmwa.demon.co.uk>
Date: Thu, 11 Dec 1997 07:35:12 +0000
Links: << >>  << T >>  << A >>
In article <348F327A.BFA74FB0@CatenaryScientific.com>, Chuck Parsons
<chuck@CatenaryScientific.com> writes

>John Woodgate wrote:
>
>> In article <66m579$159i$1@mdnews.btv.ibm.com>, Dale Pontius
>> <pontius@btv.MBI.com> writes
>> >
>> >2: The biggest injectors of noise into the system - one other
>> >   way cited in this thread of getting out of metastability,
>> >   tend to be your own power supplies. In this case, the noise
>> >   they tend to inject is just the kind that pushes you toward
>> >   metastability, not away from it.
>>
>> Please enlarge on how there can be two different kinds of noise. This is
>> a serious question, not sarcasm.
>
>  [ Please excuse any accidental similarity between this post and an answer to
>    John's question. Which I would like to see as well.
>   His words "different kinds of noise" prompt me to  expound on that a bit.]
>
>
>Sure John, I know you are not directing this question at me, and I'm
>not sure how to create noise that pushes you towards metastabilty, if
>you don't know the state of the system. But it is possible, to create
>noise that on average pushes you away from metastability. Without
>knowing the state of the system! But merely its dynamic behavior. I think
>a few words on this, are not wasted.

Agreed.
>
>    There are many ways noise can be different in this particular problem.
>First off I am using the term loosely to include pickup or interference as
>well as the intrinsic noise of the circuit components.  This is a very
>important distinction because it does not have to be random.

However, there is nothing in your further explanation that requires it
to be non-random, I think?
>
>   Second, the amplitude and frequency of the noise can be significantly
>different. Obviously, as we all know putting a capacitor across a
>resistor significantly changes the frequency distribution of the Johnson noise
>without changing the RMS average value of it.

True, although 'we' don't all know that, I guess.
>
>   Why would the frequency of the noise make it different for this problem?
>Because of the natural response time of the flip-flop system. Just to pick a
>definite number let us say that the flip flop rise times inside a chip are 
>100ps.
>The exact number isn't important. If the noise has a cutoff frequency due to
>filtering of 1MHz, then the response of the circuit is very fast compared to the
>frequency of the noise. If the noise moves the circuit significantly off the
>metastable point, the circuit will have plenty of time to "latch" before the
>noise can change sign. 

Yes, that's clear.

>On the other hand if we have very high frequency
>noise of say 100GHz, the response of the circuit will be slow compared to
>the noise and it will effectively become an integrator. The circuit when
>disturbed off the metastable point by the noise will not have time to begin
>moving before the noise randomly changes sign and pretty much cancels
>itself out. For this last kind of noise I can agree that the chances of pushing 
>you
>towards metastability are (almost) the same as pushing you away. However,
>while the net effect may be small, it will always average out to be a net push
>"away from metastability".

H'mm. I am not so sure about that. It looks more as though the 100 GHz
noise has no effect at all.
>
>
>   Why would the amplitude of the noise make a difference? For two reasons,
>one by definition the first order response of any system to perturbations around
>a metastable point will be zero. The net positive feedback will therefore be
>determined by the second derivative of the response function, and therefore
>basically be related to the amplitude squared of the noise, not the amplitude.
>Large perturbations well sweep the system quickly out of the metastable region
>much more quickly than small ones.

Godd point indeed.
>
>   Very important point, for points in the system outside the metastable region
>the first derivative of the response function is not zero. This makes the
>probability that
>the noise puts the system back into the metastable state much less that the
>probability
>of moving it out of the metastable state. In simple terms, it is because the 
>system
>won't "wait" for the noise but is racing for the supply rails.

True. The mathematical definition of 'metastable' involves the first
derivative being zero at a single point, and negative everywhere else,
at least locally. On that basis, it is *infinitely* more probable that
the system is moved away from metastability.
>
>   Another way that the noise amplitude is important is that, we have all been
>assuming
>that the noise is not enough to transition the system from a latched state into 
>the
>metastable state. I don't think there is much point in discussing that 
>situation,
>though
>it is obviously possible. The math in that situation changes drastically, 
>because
>now the non-metastable events will "wait" in the latched condition to be kicked
>into the metastable state.

Yes, now the noise is bigger than around half the noise margin of the
device, one hopes: the noise margin would be a thoroughly misleading
value if the input casuing metastability was only slightly larger than
the 'logical zero' input. 
>
>  We all remember the random walk problem, and perhaps you have also seen the
>problem rendered as a drunk who falls down, and gets up going a random 
>direction.

No, I stuided electronics, not physics. My studies in that field have
been purely experimental!

>In this problem, near a metastable point the drunk starts out at the top of a 
>hill,
>and
>every time he goes down the hill he speed up and starts running but every time 
>he
>goes up
>the hill he slows down and starts crawling.
>
>
I can confirm that!
>
>Chuck
>
>
Thanks very much for the explanations.

-- 
Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. 
OOO - Own Opinions Only. It is useless to threaten a strong man - he will
ignore you. It is dangerous to threaten a weak man - he will kill you if he can.
Article: 8376
Subject: Re: gates
From: Lars <larsherm@sn.no>
Date: Thu, 11 Dec 1997 09:18:31 +0100
Links: << >>  << T >>  << A >>
David Decker wrote:
> 
> fliptron@netcom.com (Philip Freidin) wrote:
> 
> >About 42
> >
> >In article <348CDAB1.4ECC@bignet.net> Roger Blincow <"Roger Blincow"@bignet.net> writes:
> >>what is the average amount of gates needed per device?
> >>im looking for a ballpark estimate.
> >>*respond to z5c@hotmail.com
> >>
> >>--z
> >
> >
> 
> Yes, Yes, I know. That's the answer to life, the universe, and
> everything! Too easy.
> 
> But which color gates?
> That ought to keep you busy a little longer.

Golden of course (Golden Gate).
I just had to....
Article: 8377
Subject: Re: what is metastability time of a flip_flop
From: pontius@btv.MBI.com (Dale Pontius)
Date: 11 Dec 1997 12:58:29 GMT
Links: << >>  << T >>  << A >>
In article <GXtt7aAkX5j0EwAm@jmwa.demon.co.uk>,
        John Woodgate <jmw@jmwa.demon.co.uk> writes:
>
> H'mm. I agree at the practical level, but it's not an explanation.

The noises you make, yourself, tend to be correlated to your own
activity. The noises coming in from outside may or may not be
correlated. For instance, that noise coming in on the supply
line may have been related to moving the head on the disk drive,
which is pretty well completely disconnected from what I'm doing
on-chip. (at least in the microscopic sense, even if the bits in
my memory did tell the disk to do a seek.)
>
> Perhpas we should give up digital altogether, and go back to analogue.

We always were analog. Digital is an approximation. Kind of like
classical vs quantum. Of course by that argument, there's another
kind of digital underlying the analog, but I doubt we can fab
parts in that domain for a few years.

Dale Pontius
(NOT speaking for IBM)
Article: 8378
Subject: XC4003 developpement board
From: "Denis Lachapelle" <sysacom@cam.org>
Date: 11 Dec 1997 14:35:42 GMT
Links: << >>  << T >>  << A >>
	In the realisation of a project we have developped a board having 2 XC4003
PC84 chip, all the pins are accessible, each chip has the connector to
download the configuration. The board objective was to test a design, it
can be used for almost any application.  

If you are interested in these board let us know.

-- 
Denis Lachapelle, sysacom@cam.org
Sysacom R&D plus inc.
www.cam.org/~sysacom
tel 514 585-6396, fax 514 582-3231

Article: 8379
Subject: Re: I looked up Altera in an Italian dictionary.....
From: Tom Bowns <bowns@data-io.com>
Date: Thu, 11 Dec 1997 17:21:07 GMT
Links: << >>  << T >>  << A >>
> By the way, Altera stands for "alterable"...

Gotta throw in my two cents. 

Way back in '85, I was told by those guys that Altera is the latin word
for "logic".

To me, though, Altera sounded too much like "Errata" so I figured they
wouldn't get too big in the market.  Who knew?

-TBB
Article: 8380
Subject: Re: what is metastability time of a flip_flop
From: Brad Taylor <Brad.Taylor@xilinx.com>
Date: Thu, 11 Dec 1997 10:46:43 -0800
Links: << >>  << T >>  << A >>
Peter wrote:
> 
> I think you are right.
> 
> The only factor which guarantees the *eventual* exit from a metastable
> state is thermal noise, so injecting some is going to help a lot.
> 
> As to predicting how much it will help, I don't know. Probably many
> orders of magnitude.
> 
> Peter.
> 

 I don't have any data to back me up, but I'll bet that thermal noise
(in the FF I assume)is just as likely to push the state into equlibrium
as away from it. Any such noise should appear be the same as a noisy
input which I believe does not affect metastable recovery. 
-
Brad


-- 
====================================================================
 Email:   brad.taylor@xilinx.com 
 Phone:   1-408-879-6976
 Fax:     1-408-879-4676
 Address: 2100 Logic Drive, San Jose, Ca. 95124
====================================================================
Article: 8381
Subject: Re: what is metastability time of a flip_flop
From: fliptron@netcom.com (Philip Freidin)
Date: Thu, 11 Dec 1997 23:04:06 GMT
Links: << >>  << T >>  << A >>
Unfortunately, the response below propagates the myth that a clean 
transition from 1 to 0 or 0 to 1, but with additional delay, is somehow 
metastable free.

THIS IS NOT THE CASE, never has been, never will.

At the heart of a flip flop or arbiter or schmidt trigger, there is a 
bi-stable circuit that has the two expected states, and a linear region 
in which the input when placed at a given level, causes the output to 
have an output at other than the expected limit values of '0' and '1'.

The bi-stable circuit typically has both positive feedback and gain, 
which together are responsible for the bi-stables behaviour. In 
particular, the positive feedback is the mechanism that is the basis for 
the bi-stable state of the circuit, and the gain affects the performance 
of the device, as well as having a significant effect on the metastable 
recovery time. The bi-stable circuit can go into a metastable state when 
the feedback signal is at such a level that when applied to the input, it 
causes the output (feedback voltage), to match the input (feedback 
voltage also). The circuit is in equilibrium, and can remain there 
indefinitely. Any small perterbation (or not being at the EXACT 
equilibrium point) will cause regenerative positive feedback, which 
eventually will cause the bi-stable to reach one of its expected two 
stable states.

In the Phillips device referenced below, all that has been added to the 
basic bi-stable is a follower circuit, that has as its threshold, a level 
that is far from the equilibrium point of the bi-stable. As such, 
although the output can change monotonically, the delay is unbounded, and 
so the problem still exists, and is pushed to the device that follows it, 
which will have to tollerate a basically asynchronous input. If the next 
stage is a synchronizer, and sufficient additional settling time is 
given, then the normal MTBF type calculations can be applied.


Philip Freidin

In article <348DDC80.5E16@solopoint.com> jim.wall@solopoint.com writes:
>Hal Murray wrote:
>> 
>> In article <SAM.97Dec5161742@colossus.stdavids.picker.com>, sam@stdavids.picker.com (Sam Goldwasser) writes:
>> 
>> > There are always asynchronous (unclocked) systems!
>> 
>> That doesn't solve the problem, just changes it.  You get the dual
>> of the synchronizer problem - the arbiter.  Consider trying to
>> decide which of two request signals comes first.
>> 
>> You can build a circuit that will get a correct answer
>> but there is no promise on when the answer will be available.
>> It might take forever.
>Actually Phillips makes a metastable-free arbiter. 4bit, fully
>asynchronous and guaranteed to aribrate between the 4 requests with no
>conflicts. If there is a internal metastable condition, it lengthens the
>arbitration time slightly, but the outputs are always clean. I forget
>the part number, but I used it for several designs and it worked great.>
>						-Jim
Article: 8382
Subject: Pre-Reg Required For Free On-Line "Deep Submicron" Seminar
From: jcooley@world.std.com (John Cooley)
Date: Thu, 11 Dec 1997 23:30:50 GMT
Links: << >>  << T >>  << A >>
I just got e-mail from the guys at EDTN saying that they're sponsoring 
some sort of free on-line Deep Sub-micron seminar involving a whole suite of
Synopsys/Viewlogic tools (and non-EDA specific design issues) for next
Thursday (Dec 18th) at 10AM PST (1PM EST) -- but you *must* be pre-registered
to partake in it.  Check out "www.edtn.com" if this sounds interesting to you.

                           - John Cooley
                             Part Time EDA Consumer Advocate
                             Full Time ASIC, FPGA & EDA Design Consultant

===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how 5459 other
 users dealt with it ?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
      !!!     "It's not a BUG,               jcooley@world.std.com
     /o o\  /  it's a FEATURE!"                 (508) 429-4357
    (  >  )
     \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
     _] [_         Verilog, VHDL and numerous Design Methodologies.

     Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
   Legal Disclaimer: "As always, anything said here is only opinion."
Article: 8383
Subject: Re: what is metastability time of a flip_flop
From: Chuck Parsons <chuck@CatenaryScientific.com>
Date: Thu, 11 Dec 1997 18:56:12 -0500
Links: << >>  << T >>  << A >>


John Woodgate wrote:

> In article <348F327A.BFA74FB0@CatenaryScientific.com>, Chuck Parsons
> <chuck@CatenaryScientific.com> writes
>
> >On the other hand if we have very high frequency
> >noise of say 100GHz, the response of the circuit will be slow compared to
> >the noise and it will effectively become an integrator. The circuit when
> >disturbed off the metastable point by the noise will not have time to begin
> >moving before the noise randomly changes sign and pretty much cancels
> >itself out. For this last kind of noise I can agree that the chances of pushing
> >you
> >towards metastability are (almost) the same as pushing you away. However,
> >while the net effect may be small, it will always average out to be a net push
> >"away from metastability".
>
> H'mm. I am not so sure about that. It looks more as though the 100 GHz
> noise has no effect at all.
> >

  Well, we have do have a way of evaluating the integral of dV(V+Vnoise)/dt dt in
a probabilistic sense so we need a distribution function for the noise and dV(V)/dt.
I know dV(V) sounds weird, but in this situation dV/dt is basically a function of V.

   But the normal situation that arises is not zero but something proportional to
sqrt(T)
where T is the time we are integrating over. It is however, generally speaking much
much less than the integral of absolute_value(dV/dt). This is in complete analogy
to flippling a coin N times. The expected value of Nheads is N/2, and yes the the
most
probable value of Nheads-N/2 is zero. But the expected value of (Nheads-N/2)**2 is
proportional to N or the expected magnitude absolute_value(Nheads-N/2) is
proportional
to sqrt(N).

  Please note that absoulte_value(integral(x)) is very different than
integral(absolute_value(x)).
In the above paragraph I have referred to both.



Article: 8384
Subject: Royalties Agreement
From: Jim Ternus <JTio@skypoint.com>
Date: Thu, 11 Dec 1997 16:41:03 -0800
Links: << >>  << T >>  << A >>
Hello,

A plesent change of pace from the standard Xilina and Altera who's
better battles.  

I am developing an product with another company.  I was wondering if
someone out there had a basic ROYALTY AGREEMENT contract they would be
willing to share.  I will use this as a reference only.  

I have to come up with a contract.  I would like to do this without the
expense of a lawyer writing up fantasy agreements that no one will sign
(been there/done that). Then I'll end up going back an forth untill the
lawyer fee is out of hand.

Please Email me your response.


Thanks in advance for any help.




Jim Ternus
iO Engineering, Inc
Article: 8385
Subject: Re: Z80 in FPGA: clockspeed?
From: Jeff Wetch <wetch@sprintmail.com>
Date: Thu, 11 Dec 1997 19:08:43 -0700
Links: << >>  << T >>  << A >>
Pieter Hulshoff wrote:
Back in 1993, Michael Markowitz of EDN Magazine wrote a series of
articles about VHDL and he used the Z80 as the design example.  The
source code may be available.  At the time it was on their BBS, now it
may be on their web site.  The articles ran from Jan '93 until Mar '93.

Regards,

Jeff 




> 
> I've been wondering: If you were to build a Z80 microprocessor in FPGA, what
> would be the maximum clockspeed the processor could run at? Anyone have some
> information on this subject?
> 
> Kind regards,
> 
> Pieter
Article: 8386
Subject: Re: what is metastability time of a flip_flop
From: "rk" <stellare@erols.com>
Date: 12 Dec 1997 03:49:31 GMT
Links: << >>  << T >>  << A >>
John Woodgate <jmw@jmwa.demon.co.uk> wrote in article
<01bd0699$7e62a980$2f80accf@default>...
> In article <66n2v2$16ve$2@mdnews.btv.ibm.com>, Dale Pontius
> <pontius@btv.MBI.com> writes
> >In article <SCm4O0AIIsj0Ewzg@jmwa.demon.co.uk>,
> >        John Woodgate <jmw@jmwa.demon.co.uk> writes:
> >> In article <66m579$159i$1@mdnews.btv.ibm.com>, Dale Pontius
> >> <pontius@btv.MBI.com> writes
> >>>

<snip>

> >Someone else asked me to "quantify fail rates" for a DRAM. You
> >just can't do that, because there is no acceptable fail rate
> >expressable in ppm. A million operations at 33 MHz only gets
> >you up to 30 mS, when sometimes you'd like to run 24X7 for an
> >entire quarter on a server. OK, the math is simple:
> >
> >13weeks*7days*24hours*60minutes*60seconds*33e6ops/second=2.6e14
> 
> That is a useful and important point.
> >
> >Planning for anything other than zero is unacceptable. Time teaches.
> >
> >Dale Pontius
> >(NOT speaking for IBM)
> 
> But you have just pointed out that we are in a situation analoguos to
> thermodynamics:
> 
> 1. You cannot win, you can only break even.
> 2. You can only break even at absoulte zero.
> 3. You cannot reach absolute zero.
> 
> For metastability:
> 
> 1. You cannot avoid metastability, you can only escape from it quickly.
> 2. You can only escape quickly by using noise perturbation.
> 3. Noise perturbation can create metastability.
> 
> Perhpas we should give up digital altogether, and go back to analogue.
> -- 
> Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. 
> OOO - Own Opinions Only. It is useless to threaten a strong man - he will
> ignore you. It is dangerous to threaten a weak man - he will kill you if
he
> can.

don't think we could give up digital altogether, need it for some stuff
(usenet?), but we can make it realiable.  it is odd that the interesting
parts of digital are getting pulled in different directions - on the board
with the really fast signals it's more analog than digital, and inside the
chips (say, fpga's to sort of stay on topic), there's the increasing use of
VHDL and other HDLs, macro generators, and other synthesis tools, leading
to more use of software skills to design the hardware.

of course, the way to solve the metastable problem is to not solve it at
the circuit level but at the system - although more people are aware of
asynchronous interfaces, it seems that a lot of systems are still designing
them in, even when they are easily avoidable.  for a hi-rel circuit, you
need a system design that supports that; minimize the # of asynchronous
interfaces, minimize their event rate, and maximize the time alloted to
resolve it.  from what i see, most of the time this isn't all that hard to
do and systems with properly designed asynchronous interfaces have been
built that run for many, many years without problems (have one that we
started in '89 and still going strong).  but redesigning the system after
the glitches arrive to fix these things is, or course, rather painful.

now,

as dale said, planning for zero is the way to go.  then you have a system
that you can design/analyze and then verify with test. 

but,

sometimes you can't help but have asynchronous inputs.  for example, the
pulse output of a detector driving a counter that operates within a window.
 screwed.  but this can be made very reliable, and we all talked about
logic design techniques such as using gray codes.  also, as peter a./xilinx
pointed out, the newer devices are fast and resolve themselves pretty well.
 

here are some calcuations i did using chip express cx2001 technology, based
on their flip-flop parameters and example in the CX Technology Design
Manual, so i could see how this technology performs.  The CX2001 series
uses a channelled module architecture (gate array) with each module
consisting of three 2:1 muxes and an AND gate (a bit differently set up
than Act 1 but not all that dissimilar); there are no hardwired flip-flops,
as there is in the xilinx devices which peter a. previously talked about. 
I assumed a 50 MHz clock, a 10 MHz average incoming data rate, and made the
extra settling time a paramter.  here's what i got:

	extra delay		  mtbf               mtbf
        (nsec)		 (years)		 (years)

	1.0000e+0		448.25e-6		14.214e-12
	2.0000e+0		180.84e-3		5.7344e-9
	3.0000e+0		72.956e+0		2.3134e-6
	4.0000e+0		29.432e+3		933.29e-6
	5.0000e+0		11.874e+6		376.52e-3
	6.0000e+0		4.7903e+9		151.90e+0
	7.0000e+0		1.9325e+12		61.280e+3
	8.0000e+0		779.64e+12		24.722e+6
	9.0000e+0		314.53e+15		9.9736e+9
	10.000e+0		126.89e+18		4.0236e+12
	11.000e+0		51.191e+21		1.6233e+15
	12.000e+0		20.652e+24		654.87e+15
	13.000e+0		8.3316e+27		264.19e+18
	14.000e+0		3.3612e+30		106.58e+21

so,

with the 20 nSec period, let's say we allocate 10 nSec of additional delay
for the first synchronizing flip-flop to recover; this leaves 10 nSec for
clk->q, routing delays, tsu, and any unfavorable tskew.  since the
flip-flops in a synchronizer will be physically close, this is probably
very conservative.  as can be seen from the chart, 10 nSec will give a
pretty good reliability prediction.  also, each additional nSec of settling
time give an improvement of about a factor of 400 in MTBF.

of course, if this could be made synchronous, it should be since
synchronous systems are more verifiable and is planning for zero faults -
the synchronizers can be tested for a while and then you can say, "well, we
tested it for a while and didn't see it fail and the calculations look
good."  but, please see the .sig below

--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 8387
Subject: Re: what is metastability time of a flip_flop
From: jhallen@world.std.com (Joseph H Allen)
Date: Fri, 12 Dec 1997 04:56:57 GMT
Links: << >>  << T >>  << A >>
In article <01bd06b0$9dc53600$8e84accf@default>, rk <stellare@erols.com> wrote:

>of course, the way to solve the metastable problem is to not solve it at
>the circuit level but at the system - although more people are aware of
>asynchronous interfaces, it seems that a lot of systems are still designing
>them in, even when they are easily avoidable.  for a hi-rel circuit, you
>need a system design that supports that; minimize the # of asynchronous
>interfaces, minimize their event rate, and maximize the time alloted to
>resolve it.  from what i see, most of the time this isn't all that hard to
>do and systems with properly designed asynchronous interfaces have been
>built that run for many, many years without problems (have one that we
>started in '89 and still going strong).  but redesigning the system after
>the glitches arrive to fix these things is, or course, rather painful.

I can just see it now... the system will give its tentative answer, and the
longer you wait the more likely it is that you have the actual final answer,
but of course the system could change its mind at the last second... hmm...
sounds like a certain biological system we're all familiar with...


-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 8388
Subject: Re: what is metastability time of a flip_flop
From: murray@pa.dec.com (Hal Murray)
Date: 12 Dec 1997 07:04:22 GMT
Links: << >>  << T >>  << A >>
In article <348AF661.3B243D2F@CatenaryScientific.com>, Chuck Parsons <chuck@Cate
naryScientific.com> writes:

>   Surely, the noise on the power supply affects the recovery time. I would
> think a noisy environment would help quit a bit. Do people spec these times
> with noisy or clean power?

I can't convince myself that the noise is going to help anything.  I
admit that I'm not very good at device physics.  It looks to me like
symmetry arguments can be used to prove that noize will hurt as much
as it helps.

I think your bat+ball example is misleading.  First, it's two dimensional
rather than one dimensional.  Next, you assume the bats were carefully
ballanced.  In the metastability case, you also have to consider how the
bats got to be ballanced.  Somebody had to kick them up there.  The ball
could help the kicks that weren't quite going fast enough and hurt the bats
that were going just fast enough to get over the hump.


>  To be clear, the rejection of the power supply noise by the amps is probably
> quite poor at high frequencies. Noisy power will push the metastable state one
> way or the other. As, a mater of fact I would think that the right amount of
> 1GHz noise could guarantee recovery within 1.5ns

I get (very) suspicious whenever anybody says "guarantee" in a sentance
containing "metastability".  Clearly that statement is wrong if the amp
can't switch within 10 ns.

If noise is such a great solution, why didn't the world notice it before?
What do we know now that people didn't know a few years ago?
Article: 8389
Subject: Re: what is metastability time of a flip_flop
From: John Woodgate <jmw@jmwa.demon.co.uk>
Date: Fri, 12 Dec 1997 07:22:00 +0000
Links: << >>  << T >>  << A >>
In article <34907D9C.462A5D33@CatenaryScientific.com>, Chuck
Parsons <chuck@CatenaryScientific.com> writes
>
>
>John Woodgate wrote:
>
>> In article <348F327A.BFA74FB0@CatenaryScientific.com>, Chuck Parsons
>> <chuck@CatenaryScientific.com> writes
>>
>> >On the other hand if we have very high frequency
>> >noise of say 100GHz, the response of the circuit will be slow compared to
>> >the noise and it will effectively become an integrator. The circuit when
>> >disturbed off the metastable point by the noise will not have time to begin
>> >moving before the noise randomly changes sign and pretty much cancels
>> >itself out. For this last kind of noise I can agree that the chances of 
>pushing
>> >you
>> >towards metastability are (almost) the same as pushing you away. However,
>> >while the net effect may be small, it will always average out to be a net 
>push
>> >"away from metastability".
>>
>> H'mm. I am not so sure about that. It looks more as though the 100 GHz
>> noise has no effect at all.
>> >
>
>  Well, we have do have a way of evaluating the integral of dV(V+Vnoise)/dt dt 
>in
>a probabilistic sense so we need a distribution function for the noise and 
>dV(V)/dt.
>I know dV(V) sounds weird, but in this situation dV/dt is basically a function 
>of V.

It always is, isn't it, unless it's zero?
>
>   But the normal situation that arises is not zero but something proportional 
>to
>sqrt(T)
>where T is the time we are integrating over. It is however, generally speaking 
>much
>much less than the integral of absolute_value(dV/dt). This is in complete 
>analogy
>to flippling a coin N times. The expected value of Nheads is N/2, and yes the 
>the
>most
>probable value of Nheads-N/2 is zero. But the expected value of (Nheads-N/2)**2 
>is
>proportional to N or the expected magnitude absolute_value(Nheads-N/2) is
>proportional
>to sqrt(N).
>
>  Please note that absoulte_value(integral(x)) is very different than
>integral(absolute_value(x)).
>In the above paragraph I have referred to both.
>
>
>
Yes, of course. But you have assumed, AFAICS, in there somewhere a
non-linearity, either that the pdf of the noise is asymmetrical and the right
way round to produce a net movement away from metastability (which I
think is petitio principii) or that the integration somehow involves a
rectification. I would regard your case as still unproven by argument,
although I can accept that the effect is real.
-- 
Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. 
OOO - Own Opinions Only. It is useless to threaten a strong man - he will
ignore you. It is dangerous to threaten a weak man - he will kill you if he can.
Article: 8390
Subject: Re: what is metastability time of a flip_flop
From: Koenraad Schelfhout VH14 8993 <ksch@sh.bel.alcatel.be>
Date: Fri, 12 Dec 1997 08:37:51 +0100
Links: << >>  << T >>  << A >>
Please stop the discussion on metastability here.  This is a news
group on fpga's not on general electronic design items.
Since the last weeks it seems that at least 30 messages on this topic
appeared.

Thanks in advance
-- 

 Koenraad SCHELFHOUT

 Switching Systems Division          http://www.alcatel.com/
 Microelectronics Department - VH14     _______________
________________________________________\             /-___
                                         \           / /
 Phone : (32/3) 240 89 93                 \ ALCATEL / /
 Fax   : (32/3) 240 99 47                  \       / /
 mailto:ksch@sh.bel.alcatel.be              \     / /
_____________________________________________\   / /______
                                              \ / /
 Francis Wellesplein, 1                        v\/
 B-2018  Antwerpen
 Belgium
Article: 8391
Subject: Re: what is metastability time of a flip_flop
From: "rk" <stellare@erols.com>
Date: 12 Dec 1997 09:27:58 GMT
Links: << >>  << T >>  << A >>
Joseph H Allen <jhallen@world.std.com> wrote in article
<EL28Ey.H0w@world.std.com>...
> In article <01bd06b0$9dc53600$8e84accf@default>, rk <stellare@erols.com>
wrote:
> 
> >of course, the way to solve the metastable problem is to not solve it at
> >the circuit level but at the system - although more people are aware of
> >asynchronous interfaces, it seems that a lot of systems are still
designing
> >them in, even when they are easily avoidable.  for a hi-rel circuit, you
> >need a system design that supports that; minimize the # of asynchronous
> >interfaces, minimize their event rate, and maximize the time alloted to
> >resolve it.  from what i see, most of the time this isn't all that hard
to
> >do and systems with properly designed asynchronous interfaces have been
> >built that run for many, many years without problems (have one that we
> >started in '89 and still going strong).  but redesigning the system
after
> >the glitches arrive to fix these things is, or course, rather painful.
> 
> I can just see it now... the system will give its tentative answer, and
the
> longer you wait the more likely it is that you have the actual final
answer,
> but of course the system could change its mind at the last second...
hmm...
> sounds like a certain biological system we're all familiar with...

oops, perhaps i didn't write clearly, sorry about that.  here's a rephrase
of the last sentence:

	1. system built.
	2. system 'glitches' a lot in the lab
	3. managers less than thrilled
	4. boss says, "er, take a look at that for us, k?"
	5. take a look at design (see asynchronous stuff all over the place)
		without good synchronizers, poor system design
	6. me less than thrilled
	7. boss says, "er, you got a new job assignment"
	8. me less than thrilled

hope this helps,

--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------

Article: 8392
Subject: Re: REPOST: "Verilog Won & VHDL Lost -- You Be The Judge"
From: Jonathan Bromley <jseb@oxim.demon.co.uk>
Date: Fri, 12 Dec 1997 10:25:28 +0000
Links: << >>  << T >>  << A >>
In article <EKw6Iz.Mv@world.std.com>, John Cooley
<jcooley@world.std.com> writes (re my comment that we need to
ask whether VHDL delivers on its intended purpose,
improving quality and maintainability on big projects).....

> I'm not sure how to objectively answer that question

I wasn't asking you to, John, not yet anyway - I think it's a
genuine research problem.

> because on large projects you have so many variables.

yes, of course, but NB all the variables you suggested would apply
just as much to VHDL teams as to Verilog teams, or come to that, 
teams designing big projects using schematics (are there any?)
or teams writing software in C++ or *anything*. Big projects are
big projects.  Bridges, banking software, telecomms chips - all 
need project teams and design tools.  Small projects can be made to
succeed despite poor tools or poor management, because individuals can
operate at all levels of the design hierarchy simultaneously.  Big
projects are too big for one person to appreciate all at once, and 
have to be subdivided.  Only with good tools can you do the 
subdivision and the subsequent integration effectively.

<snip>
> And these are just a few concerns that would be very hard to factor
>out in testing large projects, Jonathan!  I wouldn't even attempt to
> try to deal with the political aspects that influence large projects
> and the choice of using Verilog or VHDL in them!

No argument with that.

>> I promise I won't whinge on about this any more!
> No, please do.  A good discussion usually brings out a few barbs!
OK, you provoked me again.... just this once....
-- 
Jonathan Bromley

Article: 8393
Subject: Re: what is metastability time of a flip_flop
From: pontius@btv.MBI.com (Dale Pontius)
Date: 12 Dec 1997 14:26:22 GMT
Links: << >>  << T >>  << A >>
In article <01bd06b0$9dc53600$8e84accf@default>,
        "rk" <stellare@erols.com> writes:
>
> I assumed a 50 MHz clock, a 10 MHz average incoming data rate, and made the
> extra settling time a paramter.  here's what i got:
>
>       extra delay               mtbf               mtbf
>         (nsec)                 (years)                 (years)
>
>       1.0000e+0               448.25e-6               14.214e-12
>       2.0000e+0               180.84e-3               5.7344e-9
>       3.0000e+0               72.956e+0               2.3134e-6
>       4.0000e+0               29.432e+3               933.29e-6
>...    5.0000e+0               11.874e+6               376.52e-3
>
> with the 20 nSec period, let's say we allocate 10 nSec of additional delay
> for the first synchronizing flip-flop to recover; this leaves 10 nSec for

I like your chart. I just wish I had 10 nS to spare. On the next-to-
last design, I gave up 1 nS for such stuff and had to work like crazy
to make it up in other places. I also wish the clock were "only" 50 MHz
and the data rate "only" 10 MHz.

Dale Pontius
(NOT speaking for IBM)
Article: 8394
Subject: Re: what is metastability time of a flip_flop
From: pontius@btv.MBI.com (Dale Pontius)
Date: 12 Dec 1997 14:29:41 GMT
Links: << >>  << T >>  << A >>
In article <66qnlm$3f1@src-news.pa.dec.com>,
        murray@pa.dec.com (Hal Murray) writes:
>
> I think your bat+ball example is misleading.  First, it's two dimensional
> rather than one dimensional.  Next, you assume the bats were carefully
> ballanced.  In the metastability case, you also have to consider how the
> bats got to be ballanced.  Somebody had to kick them up there.  The ball
> could help the kicks that weren't quite going fast enough and hurt the bats
> that were going just fast enough to get over the hump.
>
We're also approaching the point where "digital" becomes less
meaningful, and our circuits are becoming nearly analog again.

To put it another way, as signals get faster and voltages get
lower, the bat gets shorter and fatter. In the limit, the bat
ends up looking just like a ball, though that's the absurd
point.

Still, where we are today the bat is not as likely to tip as
it once was, and it is easier to knock back into standing
position.

Dale Pontius
(NOT speaking for IBM)
Article: 8395
Subject: Re: PCs vs. workstations
From: Emmanuel Monnerie <monnerie@oconee.em.slb.com>
Date: Fri, 12 Dec 1997 09:45:32 -0500
Links: << >>  << T >>  << A >>
I've been working with ALTERA systems for 2 years, and I've noticed much
better performances of their latest MaxplusII compiler, on my PC with a
120MHz pentium. I'm using one of their bigger chip (Flex10K100) and a
compilation that could last 2H 2 years ago, lasts now 1/4H, with 90% of
success in terms of timing. I have tried also a 266MHz pentiumII, and
times are divided by 2 or 3.

Hardware requirements are strong : 128MB of Ram, pentium, 500MB of
Altera files, but with this configuration, the software uses fully the
processor and reaches great performances.

In my opinion, workstations will always be slower because of their real
multitask environment. The main quality of PC is their ability to give
maximum horsepower to one software. 

Emmanuel

Bill Lenihan wrote:
> 
> Does anyone know of any cases, benchmarks, studies, etc., demonstrating
> where the envelope is for FPGA designs done on state-of-the-art PCs vs.
> state-of-the-art workstations? Has anyone had a case where a design
> couldn't compile on a PC, but could when ported to a workstation? (or
> vice-versa?)
Article: 8396
Subject: Re: Z80 in FPGA: clockspeed?
From: timolmst@cyberramp.net
Date: Fri, 12 Dec 1997 15:22:05 GMT
Links: << >>  << T >>  << A >>
Jeff Wetch <wetch@sprintmail.com> wrote:

>Pieter Hulshoff wrote:
>Back in 1993, Michael Markowitz of EDN Magazine wrote a series of
>articles about VHDL and he used the Z80 as the design example.  The
>source code may be available.  At the time it was on their BBS, now it
>may be on their web site.  The articles ran from Jan '93 until Mar '93.

>Regards,

>Jeff 


I have heard that the code in the article was deliberately incomplete,
per an agreement with Zilog. They (Zilog) didn't want people to be
able to reproduce the Z80 core. Can't say that I'd blame them.



Tim Olmstead
webmaster of the CP/M Unofficial web page
email : timolmst@cyberramp.net
http://cdl.uta.edu/cpm


Article: 8397
Subject: Re: Z80 in FPGA: clockspeed?
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Fri, 12 Dec 1997 09:43:20 -0800
Links: << >>  << T >>  << A >>
While I don't know the answer, I can point you to some people that probably
do know.  VAutomation has a series of processor cores
(http://www.vautomation.com/vz80/vz80.htm).  I know that they've implemented
it in Altera FLEX and probably also in Xilinx XC4000-series.  I'd recommend
contacting them.  They also sell a Z80 core.

They do have another example on their web site for a 6502-compatible core
(http://www.vautomation.com/v6502/v6502.htm).  It requires 88% of a Xilinx
XC4010-4 FPGA and operates at 8 MHz.  Xilinx now offers significantly faster
silicon than the -4 speed grade so I wouldn't be surprised if the fastest
current speed grade provides 16-20 MHz performance.  On another page
(http://www.vautomation.com/html/products.htm), VAutomation mentions that
the 6502 core operates at 7 MHz in an Altera FLEX 10K50 device, though
VAutomation doesn't specify the speed grade.

VAutomation gives their contact address as sales@VAutomation.com.

-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------



Pieter Hulshoff wrote in message <66mqan$n55$1@news2.xs4all.nl>...
>I've been wondering: If you were to build a Z80 microprocessor in FPGA,
what
>would be the maximum clockspeed the processor could run at? Anyone have
some
>information on this subject?
>
>Kind regards,
>
>Pieter


Article: 8398
Subject: CROSSPOST: WANTED: Electronics Company with Experience in Space Projects
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Fri, 12 Dec 1997 09:53:15 -0800
Links: << >>  << T >>  << A >>
I'c crossposting this from sci.electronics.design as it also seems
appropriate for comp.arch.fpga.

-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------


Sven Muencheberg wrote in message <01bd064a$01669ad0$3c3216ac@l0140>...
>Hello,
>
>my company is looking for a sub-contractor in an upcoming project. What we
>are looking for is a electronics company with experience in space projects,
>which can design several boards for a signal processing device on a
>satellite.
>
>The company should be experienced in the following subjects:
>- Design of memory boards and extensions
>- FPGA design
>- Actel parts
>- Dealing with requirements for space missions (reliability, environment of
>launch and orbit, etc.)
>
>The company should preferably be located in Europe.
>
>Please mail me, if you know a company that fits our requirements.
>
>Regards,
>Sven Muencheberg
> __  __   --------------------------------------------------------
>|  |/  /  Kayser-Threde GmbH     ms@kayser-threde.de
>| ====<   Wolfratshauser Str. 48           Tel.: +49 89/724 95-121
>|__|\__\  81379 Munich, Germany            Fax:  +49 89/724 95-104
>


Article: 8399
Subject: RC5-64 on FPGA
From: Eyal Soha <barrel@po.EECS.Berkeley.EDU>
Date: Fri, 12 Dec 1997 13:30:08 -0800
Links: << >>  << T >>  << A >>
Hi, I'm new to this newsgroup but it was recommended to me by someone as
something I might want to check out.  I'm working on an implementation of
the RC5 algorithm in hardware.  The design is complete, and works in
simulation, but it doesn't fit on the XC4010XL, which is all I have
available to me.  I know I can split it across two, but I'd rather use my
resources better than that.

If it wouldn't be too much trouble, I'd appreciate any comments on the
design I currently have.  It's been painstakingly converted to gif format
and put online.  The url for the schematics is:

http://www-inst.EECS.Berkeley.EDU/~barrel/sch/

The main schematic is rc5-64.gif.  It does most of the work, with other
schematics included for completeness.  More information on the RC5 FPGA
project can be found at:

http://www-inst.EECS.Berkeley.EDU/~barrel/rc5.html and
http://www.distributed.net/

So far as I know, I've made more progress than most anyone else working
with Distributed.  So, if you have a few minutes to spare, please go over
my schematics and let me know of any improvements I could make to squeeze
510 CLBs into the area of 400.

Furthermore, I've received at least two emails from people looking at my
design that claim switching to bit-serial processing would allow me to
full pipeline my design such that 12 boards would double the entire
throughput of the project (which currently stands at around the power of
14,000 Pentium Pro/200s).

I've also been considering map/place/routing the design by hand, to reduce
the overall area needed.  Would this be worthwhile?

I check my email often and try to reply quickly, fastest to
barrel@po.eecs.berkeley.edu.  I'd appreciate any help or suggestions, as
I'm sure do the other thousands of people with Distributed.  BTW, if
you've got a computer just idling, why not join in the fun?  The client is
available form the Distributed homepage mentioned above.  Thanks for
everything!

Eyal



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