rickman <gnuarm@gmail.com> wrote: (snip)> I'm not sure what you would want to simulate. Metastability is > probabilistic. There is For a given length of settling time there is > some probability of it happening. Increasing the settling time > reduces the probability but it will never be zero meaning there is no > max length of time it takes for the output of a metastable ff to > settle.A favorite statistical physics problem is calculating the probability that all the air molecules will move to one half of a room. There are many other problems with a very small, but non-zero, probability. -- glen
accumulator (again)
Started by ●July 2, 2012
Reply by ●July 9, 20122012-07-09
Reply by ●July 9, 20122012-07-09
Dear All, I would like to thank you all for your contributions. I finally solved the = problem, that was not in the code as I immediately decided since i'm not ve= ry experienced in VHDL, but rather in my miss interpretation of the AD9058'= s datashet. I feel very stupid!=20 It was tanks to all your comments that I decided to finally rethink the pro= ject as a all and spotted the problem. "God saves the internet and the good people that lives there" jmariano
Reply by ●July 9, 20122012-07-09
On Sun, 08 Jul 2012 15:38:45 -0700, rickman wrote:> On Jul 6, 10:00 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal > Murray) wrote: >> In article <nZ-dnch1rrNvHG_SnZ2dnUVZ_qSdn...@web-ster.com>, >> Tim Wescott <t...@seemywebsite.please> writes: >> >> >Paranoid logic designers will have a string of two or three registers >> >to avoid metastability, but I've been told that's not necessary. (I'm >> >not much of a logic designer). >> >> Ahh, but are they paranoid enough? >> >> The key is settling time. >> >> In the old days of TTL chips, a pair of FFs (with no logic in between) >> got you settling time of as much logic as the worst case delay for the >> rest of the system. In practice, that was enough. >> >> With FPGAs, routhing is important. A pair of FFs close together is >> probably good enough. If you put them on opposite sides of a big chip, >> the routing delays may match the long path of the logic delays and eat >> up all of your slack time. >> >> Have any FPGA vendors published recent metastability info? (Many thanks >> to Peter Alfke for all his good work in this area.) >> >> I'm not a silicon wizard. Is it reasonable to simulate this stuff? I'd >> like to know worst case rather than typicals. It should be possible to >> do something like verify simulations with lab typicals and then use >> simulations to find the numbers for the nasty corners. > > I'm not sure what you would want to simulate. Metastability is > probabilistic. There is For a given length of settling time there is > some probability of it happening. Increasing the settling time reduces > the probability but it will never be zero meaning there is no max length > of time it takes for the output of a metastable ff to settle.The drivers of metastability are probabilistic, yes. But given enough information you could certainly simulate the positive feedback loop that is a flip-flop. I suspect that unless the ball that is the flip-flop state is poised right on the top of the mountain between the Valley of Zero and the Valley of One, that the problem is mostly deterministic. It's only when the after-strobe balance is perfect and the gain is so low that the FF voltage is affected more by noise than by actual circuit forces that the problem would remain probabilistic _after_ the strobe happened. "Enough information", in this case, would involve a whole lot of deep knowledge of the inner workings of the FPGA, and the simulation would be an analog circuits problem. So I suspect that you couldn't do it for any specific part unless you worked at the company in question. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●July 9, 20122012-07-09
On Jul 9, 1:38=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:> rickman <gnu...@gmail.com> wrote: > > (snip) > > >> > Paranoid logic designers will have a string of two or three register=s to> >> > avoid metastability, but I've been told that's not necessary. =A0(I'=m not> >> > much of a logic designer). > > (snip) > > > Hi Ed. =A0They way it was explained to me, I believe from Peter Alfke, > > is that what really resolves metastability is the slack time in a > > register to register path. =A0Over the years FPGA process has resulted > > in FFs which only need a couple of ns to resolve metastability to 1 in > > a million operation years or something like that (I don't remember the > > metric, but it was good enough for anything I do). =A0It doesn't matter > > that you have logic in that path, you just need those few ns in every > > part of the path. =A0In theory, even if you use multiple registers with > > no logic, what really matters is the slack time in the path and that > > is not guaranteed even with no logic. =A0So the design protocol should > > be to assure the slack time from the input register to all subsequent > > registers have sufficient slack time. > > I suppose that is true, but really it shouldn't be a problem. > It is usual for many systems to clock as fast as you can, > consistent with the critical path delay. As metastability > is exponential, even a slightly shorter delay is usually enough > to make enough difference in the exponent. > > That assumes that there is a FF to FF path that is faster than > the FF logic FF path. I believe that is usual for FPGAs, but > if you manage to get a critical path with only one LUT, then > I am not so sure. But that is pretty hard in most real systems. > > > Do you remember how much time that needs to be? =A0I want to say 2 ns, > > but it might be more like 5 ns, I just can't recall. =A0Of course it > > depends on your clock rates, but I believe Peter picked some more > > aggressive speeds like 100 MHz for his example. > > I would expect most systems to have at least a 10% margin. > That is, the clock period is at least 10% longer than the > critical path delay. Probably closer to 20%, but maybe 10%. > So, with a 10ns clock there might be only 1ns slack. > Assuming some delay, say 1ns minimum from FF to FF, that > has nine times the slack, and that is in an exponent. > > -- glenYou keep talking about the critical path delay as if the metastable input is driving the critical path. There is only one critical path in a design normally. All other paths are faster. Are you assuming that all paths have the same amount of delay? Regardless, all I am saying is that you don't need to use a path that has no logic to obtain *enough* slack to give enough settling time to the metastable input. But in all cases you need to verify this. As mentioned in another post, Peter Alfke's numbers show that you only need about 2 ns to get 100 million years MTBF. Of course whether this is good enough depends on just how reliable your systems have to be and how many there are. It is 100 million years for one unit, but for 10 million units it will only be 10 years MTBF for the group. Rick
Reply by ●July 9, 20122012-07-09
On Jul 9, 11:36=A0am, jmariano <jmarian...@gmail.com> wrote:> Dear All, > > I would like to thank you all for your contributions. I finally solved th=e problem, that was not in the code as I immediately decided since i'm not = very experienced in VHDL, but rather in my miss interpretation of the AD905= 8's datashet. I feel very stupid!> > It was tanks to all your comments that I decided to finally rethink the p=roject as a all and spotted the problem.> > "God saves the internet and the good people that lives there" > > jmarianoDon't think of it as a stupid mistake, think of it as a "good catch"! Rick
Reply by ●July 9, 20122012-07-09
On Jul 9, 2:35=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:> On Sun, 08 Jul 2012 15:38:45 -0700, rickman wrote: > > On Jul 6, 10:00 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal > > Murray) wrote: > >> In article <nZ-dnch1rrNvHG_SnZ2dnUVZ_qSdn...@web-ster.com>, > >> =A0Tim Wescott <t...@seemywebsite.please> writes: > > >> >Paranoid logic designers will have a string of two or three registers > >> >to avoid metastability, but I've been told that's not necessary. =A0(=I'm> >> >not much of a logic designer). > > >> Ahh, but are they paranoid enough? > > >> The key is settling time. > > >> In the old days of TTL chips, a pair of FFs (with no logic in between) > >> got you settling time of as much logic as the worst case delay for the > >> rest of the system. =A0In practice, that was enough. > > >> With FPGAs, routhing is important. =A0A pair of FFs close together is > >> probably good enough. =A0If you put them on opposite sides of a big ch=ip,> >> the routing delays may match the long path of the logic delays and eat > >> up all of your slack time. > > >> Have any FPGA vendors published recent metastability info? (Many thank=s> >> to Peter Alfke for all his good work in this area.) > > >> I'm not a silicon wizard. =A0Is it reasonable to simulate this stuff? =I'd> >> like to know worst case rather than typicals. =A0It should be possible=to> >> do something like verify simulations with lab typicals and then use > >> simulations to find the numbers for the nasty corners. > > > I'm not sure what you would want to simulate. =A0Metastability is > > probabilistic. =A0There is For a given length of settling time there is > > some probability of it happening. =A0Increasing the settling time reduc=es> > the probability but it will never be zero meaning there is no max lengt=h> > of time it takes for the output of a metastable ff to settle. > > The drivers of metastability are probabilistic, yes. =A0But given enough > information you could certainly simulate the positive feedback loop that > is a flip-flop. > > I suspect that unless the ball that is the flip-flop state is poised > right on the top of the mountain between the Valley of Zero and the > Valley of One, that the problem is mostly deterministic. =A0It's only whe=n> the after-strobe balance is perfect and the gain is so low that the FF > voltage is affected more by noise than by actual circuit forces that the > problem would remain probabilistic _after_ the strobe happened. > > "Enough information", in this case, would involve a whole lot of deep > knowledge of the inner workings of the FPGA, and the simulation would be > an analog circuits problem. =A0So I suspect that you couldn't do it for a=ny> specific part unless you worked at the company in question. > > -- > My liberal friends think I'm a conservative kook. > My conservative friends think I'm a liberal kook. > Why am I not happy that they have found common ground? > > Tim Wescott, Communications, Control, Circuits & Softwarehttp://www.wesco=ttdesign.com That's what probability is all about, dealing with the lack of knowledge. You don't know the exact voltage of the input when the clock edge changed and you don't know how fast either signal was changing... etc. But you do know how often you expect all of these events to line up to produce metastability and you know the distribution of delay is a logarithmic taper. I won't try to argue about how many angels can dance on the head of a pin, but I have no information to show me that the formula that Peter used is not accurate, even for extreme cases. Rick
Reply by ●July 9, 20122012-07-09
rickman <gnuarm@gmail.com> wrote: (snip, I wrote)>> I suppose that is true, but really it shouldn't be a problem. >> It is usual for many systems to clock as fast as you can, >> consistent with the critical path delay. As metastability >> is exponential, even a slightly shorter delay is usually enough >> to make enough difference in the exponent.>> That assumes that there is a FF to FF path that is faster than >> the FF logic FF path. I believe that is usual for FPGAs, but >> if you manage to get a critical path with only one LUT, then >> I am not so sure. But that is pretty hard in most real systems.(snip)> You keep talking about the critical path delay as if the metastable > input is driving the critical path. There is only one critical path > in a design normally. All other paths are faster. Are you assuming > that all paths have the same amount of delay?No, but it might be that many have about the same delay. Well, my favorite things to design are systolic arrays, where there is the same logic (though with different routing, different delay) between a large number of FFs. For any pipelined processor, the most efficient logic has about the same delay between successive registers.> Regardless, all I am saying is that you don't need to use a path that > has no logic to obtain *enough* slack to give enough settling time to > the metastable input. But in all cases you need to verify this.Yes. One would hope that no logic would have the shortest delay, though in the case of FPGAs, you might not be able to count on that.> As mentioned in another post, Peter Alfke's numbers show that you only > need about 2 ns to get 100 million years MTBF. Of course whether this > is good enough depends on just how reliable your systems have to be > and how many there are. It is 100 million years for one unit, but for > 10 million units it will only be 10 years MTBF for the group.I have done designs with at most two LUTs between registers, and might even be able to do one. -- glen
Reply by ●July 9, 20122012-07-09
On Mon, 09 Jul 2012 17:20:26 -0700, rickman wrote:> On Jul 9, 2:35 pm, Tim Wescott <t...@seemywebsite.com> wrote: >> On Sun, 08 Jul 2012 15:38:45 -0700, rickman wrote: >> > On Jul 6, 10:00 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal >> > Murray) wrote: >> >> In article <nZ-dnch1rrNvHG_SnZ2dnUVZ_qSdn...@web-ster.com>, >> >> Tim Wescott <t...@seemywebsite.please> writes: >> >> >> >Paranoid logic designers will have a string of two or three >> >> >registers to avoid metastability, but I've been told that's not >> >> >necessary. (I'm not much of a logic designer). >> >> >> Ahh, but are they paranoid enough? >> >> >> The key is settling time. >> >> >> In the old days of TTL chips, a pair of FFs (with no logic in >> >> between) got you settling time of as much logic as the worst case >> >> delay for the rest of the system. In practice, that was enough. >> >> >> With FPGAs, routhing is important. A pair of FFs close together is >> >> probably good enough. If you put them on opposite sides of a big >> >> chip, the routing delays may match the long path of the logic delays >> >> and eat up all of your slack time. >> >> >> Have any FPGA vendors published recent metastability info? (Many >> >> thanks to Peter Alfke for all his good work in this area.) >> >> >> I'm not a silicon wizard. Is it reasonable to simulate this stuff? >> >> I'd like to know worst case rather than typicals. It should be >> >> possible to do something like verify simulations with lab typicals >> >> and then use simulations to find the numbers for the nasty corners. >> >> > I'm not sure what you would want to simulate. Metastability is >> > probabilistic. There is For a given length of settling time there is >> > some probability of it happening. Increasing the settling time >> > reduces the probability but it will never be zero meaning there is no >> > max length of time it takes for the output of a metastable ff to >> > settle. >> >> The drivers of metastability are probabilistic, yes. But given enough >> information you could certainly simulate the positive feedback loop >> that is a flip-flop. >> >> I suspect that unless the ball that is the flip-flop state is poised >> right on the top of the mountain between the Valley of Zero and the >> Valley of One, that the problem is mostly deterministic. It's only >> when the after-strobe balance is perfect and the gain is so low that >> the FF voltage is affected more by noise than by actual circuit forces >> that the problem would remain probabilistic _after_ the strobe >> happened. >> >> "Enough information", in this case, would involve a whole lot of deep >> knowledge of the inner workings of the FPGA, and the simulation would >> be an analog circuits problem. So I suspect that you couldn't do it >> for any specific part unless you worked at the company in question. >> >> -- >> My liberal friends think I'm a conservative kook. My conservative >> friends think I'm a liberal kook. Why am I not happy that they have >> found common ground? >> >> Tim Wescott, Communications, Control, Circuits & >> Softwarehttp://www.wescottdesign.com > > That's what probability is all about, dealing with the lack of > knowledge. You don't know the exact voltage of the input when the clock > edge changed and you don't know how fast either signal was changing... > etc. But you do know how often you expect all of these events to line > up to produce metastability and you know the distribution of delay is a > logarithmic taper. > > I won't try to argue about how many angels can dance on the head of a > pin, but I have no information to show me that the formula that Peter > used is not accurate, even for extreme cases.Well, first, I wasn't trying to contradict you -- I just picked the wrong place in the thread to answer Hal's question. And second, before you can know the necessary inputs to your statistical calculations, you need to do some simulating to see how long it takes for the state to come down from various places on the mountaintop. The difference between a circuit that has a narrow & sharp potential peak vs. one that has a wide, flat, broad one is significant. (One that had a true stable spot at 1/2 voltage would be mucho worse, but that's not too likely in this day and age). -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●July 10, 20122012-07-10
Tim Wescott <tim@seemywebsite.com> wrote: (snip, someone wrote)>> That's what probability is all about, dealing with the lack of >> knowledge. You don't know the exact voltage of the input when the clock >> edge changed and you don't know how fast either signal was changing... >> etc. But you do know how often you expect all of these events to line >> up to produce metastability and you know the distribution of delay is a >> logarithmic taper.(snip)> Well, first, I wasn't trying to contradict you -- I just picked the wrong > place in the thread to answer Hal's question.> And second, before you can know the necessary inputs to your statistical > calculations, you need to do some simulating to see how long it takes for > the state to come down from various places on the mountaintop.> The difference between a circuit that has a narrow & sharp potential peak > vs. one that has a wide, flat, broad one is significant.Story I heard some years ago, the sharper and narrower the peak, the harder it is to get into the metastable state, but the longer it stays when it actually gets there. -- glen
Reply by ●July 10, 20122012-07-10
On Tue, 10 Jul 2012 04:12:21 +0000, glen herrmannsfeldt wrote:> Tim Wescott <tim@seemywebsite.com> wrote: > > (snip, someone wrote) >>> That's what probability is all about, dealing with the lack of >>> knowledge. You don't know the exact voltage of the input when the >>> clock edge changed and you don't know how fast either signal was >>> changing... etc. But you do know how often you expect all of these >>> events to line up to produce metastability and you know the >>> distribution of delay is a logarithmic taper. > > > (snip) >> Well, first, I wasn't trying to contradict you -- I just picked the >> wrong place in the thread to answer Hal's question. > >> And second, before you can know the necessary inputs to your >> statistical calculations, you need to do some simulating to see how >> long it takes for the state to come down from various places on the >> mountaintop. > >> The difference between a circuit that has a narrow & sharp potential >> peak vs. one that has a wide, flat, broad one is significant. > > Story I heard some years ago, the sharper and narrower the peak, > the harder it is to get into the metastable state, but the longer it > stays when it actually gets there.Wow. That's counter-intuitive. I would think that the sharper the peak the less likely that the device would be stuck without knowing which way to fall. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
