Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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
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: 8378In 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-3231Article: 8379
> 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? -TBBArticle: 8380
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
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.> > -JimArticle: 8382
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: 8383John 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
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, IncArticle: 8385
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, > > PieterArticle: 8386
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
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: 8388In 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
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
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: 8391Joseph 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
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 BromleyArticle: 8393
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
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: 8395I'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
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/cpmArticle: 8397
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, > >PieterArticle: 8398
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
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:
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