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
On 12/10/2014 1:05 PM, Tim Wescott wrote: > On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote: > >> On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote: >>> >>> Also, metastability decreases exponentially with decreasing clock rate. >> >> Can you explain this claim? I can't think of any reason why >> metastability would be anything but linear with clock rate if the same >> slack time is available. > > If you clock a FF at time t, and you don't use the result until time t + > Ts (Ts being your clock period), then the FF has that whole Ts-long period > to resolve the metastability one way or another. That part will be > exponential with Ts. You are forgetting about the time required for the signal to propagate to the output, through the logic, and the setup time for the next FF. These times all need to be subtracted from the clock cycle time yielding the slack time. This is the only number important to resolving metastability. > But yes, you would expect a linear part, too. The linear aspect comes from the probability of having a metastable event that needs to be resolved. Think of them as edge collisions between the clock and the data input. The more of them you have in a second the more likely a metastable event. -- RickArticle: 157451
rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >>>> Also, metastability decreases exponentially with decreasing clock rate. >>> Can you explain this claim? I can't think of any reason why >>> metastability would be anything but linear with clock rate if the same >>> slack time is available. I will claim that it is ambiguous enough not to be wrong, but ... >> If you clock a FF at time t, and you don't use the result until time t + >> Ts (Ts being your clock period), then the FF has that whole Ts-long period >> to resolve the metastability one way or another. That part will be >> exponential with Ts. > You are forgetting about the time required for the signal to propagate > to the output, through the logic, and the setup time for the next FF. > These times all need to be subtracted from the clock cycle time yielding > the slack time. This is the only number important to resolving > metastability. In the long time (slow clock) limit, that is pretty insignificant. People well say "My clock is only 10kHz, metastability can't be a problem" which is pretty much right. But clocking multiple signals with different delays, they can end up on different sides of a clock pulse, even for very slow clocks. >> But yes, you would expect a linear part, too. > The linear aspect comes from the probability of having a metastable > event that needs to be resolved. Think of them as edge collisions > between the clock and the data input. The more of them you have in a > second the more likely a metastable event. -- glenArticle: 157452
I think by popular opinion, my issue is not metastability but rather clock domain crossing as many have pointed out. This explains why adding a single synchronizing FF fixed my issue as Kevin pointed out. Also, an interesting point on the conclusion of Xilinx's XAPP094 stating that "Modern CMOS circuits are so fast that this metastable delay can safely be ignored for clock rates below 200 MHz." This also support why I Also don't think its a metastable problem since my CLK rate is 20MHz. I guess what I am taking out of all this is that not all signals need to be synchronized with a FF. Only those who fan out to multiple processes that are time aligned. This ensures two identical process to have the same output given the same input. Now the synchronized FF output can be metastable, in which case a second FF will reduce it probability significantly. Am I on the right path? or completely out on left field? PS: is there a way to attach a picture in this forum? Thanks HV. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157453
On 12/10/2014 7:26 PM, glen herrmannsfeldt wrote: > rickman <gnuarm@gmail.com> wrote: > > (snip, I wrote) >>>>> Also, metastability decreases exponentially with decreasing clock rate. > >>>> Can you explain this claim? I can't think of any reason why >>>> metastability would be anything but linear with clock rate if the same >>>> slack time is available. > > I will claim that it is ambiguous enough not to be wrong, but ... ??? Not being wrong doesn't sound the same as being right.... >>> If you clock a FF at time t, and you don't use the result until time t + >>> Ts (Ts being your clock period), then the FF has that whole Ts-long period >>> to resolve the metastability one way or another. That part will be >>> exponential with Ts. > >> You are forgetting about the time required for the signal to propagate >> to the output, through the logic, and the setup time for the next FF. >> These times all need to be subtracted from the clock cycle time yielding >> the slack time. This is the only number important to resolving >> metastability. > > In the long time (slow clock) limit, that is pretty insignificant. Not sure what that means in the real world. > People well say "My clock is only 10kHz, metastability can't be > a problem" which is pretty much right. It may be right, but is not relevant to the original issue. > But clocking multiple signals with different delays, they can > end up on different sides of a clock pulse, even for very slow > clocks. > >>> But yes, you would expect a linear part, too. > >> The linear aspect comes from the probability of having a metastable >> event that needs to be resolved. Think of them as edge collisions >> between the clock and the data input. The more of them you have in a >> second the more likely a metastable event. > > -- glen > -- RickArticle: 157454
On 12/10/2014 8:50 PM, hvo wrote: > I think by popular opinion, my issue is not metastability but rather clock > domain crossing as many have pointed out. This explains why adding a > single synchronizing FF fixed my issue as Kevin pointed out. Also, an > interesting point on the conclusion of Xilinx's XAPP094 stating that > "Modern CMOS circuits are so fast that this metastable delay can safely be > ignored for clock rates below 200 MHz." This also support why I Also don't > think its a metastable problem since my CLK rate is 20MHz. That is an interesting load of BS.... er, I mean "opinion". The question is how do you establish "Modern CMOS circuits"? They are talking about their own specific FPGA circuits which may have been true at that time. Someone pointed out to me in another thread that since that app note was written in 1997, Xilinx processes have changed considerably and the gain/bandwidth product has actually dropped. So please take the 200 MHz figure with a grain of salt and verify your metastable MTBF before deciding to ignore it. Besides, the extra FF almost never makes a difference to the design. > I guess what I am taking out of all this is that not all signals need to be > synchronized with a FF. Only those who fan out to multiple processes that > are time aligned. This ensures two identical process to have the same > output given the same input. > Now the synchronized FF output can be metastable, in which case a second FF > will reduce it probability significantly. Metastability is the same thing as the multiple destination problem, but can happen one FF later. If the FF being fed the async signal only feeds one other FF you don't have a problem so much. But if it feeds multiple FFs then it is a bigger problem more likely to bite you. Still, it is easier to fix something that may not be broken than to analyze the issue to death. BTW, the issue is *not* fanning out to multiple processes. It is driving multiple FFs. If the input is driving a FF that controls the enable on a bunch of logic in the same process, this can be a problem. > Am I on the right path? or completely out on left field? > > PS: is there a way to attach a picture in this forum? No, but you can post a picture somewhere and give a link. The way I look at metastability is to imagine the output of each FF that may go metastable as oscillating for a few ns after the clock. So either add another FF in front of this to resolve the metastability or verify there is sufficient settling time in the existing path by adding a timing constraint. This slack time is the parameter that is in the exponential term for MTBF. So a little bit goes a long way. There are tons of other references to explain this stuff. Do a web search and you'll find more than you can read. -- RickArticle: 157455
rickman <gnuarm@gmail.com> wrote: > On 12/10/2014 8:50 PM, hvo wrote: >> I think by popular opinion, my issue is not metastability but rather clock >> domain crossing as many have pointed out. This explains why adding a >> single synchronizing FF fixed my issue as Kevin pointed out. Also, an >> interesting point on the conclusion of Xilinx's XAPP094 stating that >> "Modern CMOS circuits are so fast that this metastable delay can safely be >> ignored for clock rates below 200 MHz." This also support why I Also >> don't think its a metastable problem since my CLK rate is 20MHz. > That is an interesting load of BS.... er, I mean "opinion". The > question is how do you establish "Modern CMOS circuits"? They are > talking about their own specific FPGA circuits which may have been true > at that time. Someone pointed out to me in another thread that since > that app note was written in 1997, Xilinx processes have changed > considerably and the gain/bandwidth product has actually dropped. So > please take the 200 MHz figure with a grain of salt and verify your > metastable MTBF before deciding to ignore it. > Besides, the extra FF almost never makes a difference to the design. (snip) > Metastability is the same thing as the multiple destination problem, but > can happen one FF later. If the FF being fed the async signal only > feeds one other FF you don't have a problem so much. But if it feeds > multiple FFs then it is a bigger problem more likely to bite you. > Still, it is easier to fix something that may not be broken than to > analyze the issue to death. > BTW, the issue is *not* fanning out to multiple processes. It is > driving multiple FFs. If the input is driving a FF that controls the > enable on a bunch of logic in the same process, this can be a problem. (snip) > The way I look at metastability is to imagine the output of each FF that > may go metastable as oscillating for a few ns after the clock. So > either add another FF in front of this to resolve the metastability or > verify there is sufficient settling time in the existing path by adding > a timing constraint. This slack time is the parameter that is in the > exponential term for MTBF. So a little bit goes a long way. Yes it is exponential, off of a pretty small time. If you are careful, you might get your slack time within about 5% of the clock period. Most likely, there is at least 5% already in the times given. Much of the delay changes with process, voltage, and temperature, so they have to build in some margin for all those. If you are within 5%, then the time for an additional FF to resolve is about 20 times longer. Now, consider increasing the clock period by a factor of 10. If you still have a slack time within 5%, the slack time is now also 10 times longer. About the only way it could fail is using the favorite trick of overclockers: turn up the clock frequency until it fails, then back down just a little bit. But then it is more likely that it fails by not meeting the timing that you didn't check for, and not so likely metastability. The other way is with a metastability locked-loop. I might not have invented it in discussion here some years ago, but I believe I first named it. That is a circuit that adjusts the phase of one clock such that it comes as close as possible to the actual metastability point, similar to the way PLLs lock onto a frequency. > There are tons of other references to explain this stuff. Do a web > search and you'll find more than you can read. -- glenArticle: 157456
hvo wrote: > I think by popular opinion, my issue is not metastability but rather clock > domain crossing as many have pointed out. This explains why adding a > single synchronizing FF fixed my issue as Kevin pointed out. Also, an > interesting point on the conclusion of Xilinx's XAPP094 stating that > "Modern CMOS circuits are so fast that this metastable delay can safely be > ignored for clock rates below 200 MHz." This also support why I Also don't > think its a metastable problem since my CLK rate is 20MHz. > > I guess what I am taking out of all this is that not all signals need to be > synchronized with a FF. Only those who fan out to multiple processes that > are time aligned. This ensures two identical process to have the same > output given the same input. > Now the synchronized FF output can be metastable, in which case a second FF > will reduce it probability significantly. > > Am I on the right path? or completely out on left field? > > PS: is there a way to attach a picture in this forum? > > Thanks > HV. > > --------------------------------------- > Posted through http://www.FPGARelated.com Your original problem was most definitely *not* metastability. However mitigating the probability of metastability is still worth while. It's important to understand the mechanisms involved. From a simple perspective, you can consider that any flip-flop has a "window" near the sampling clock edge where metastability can happen. For modern CMOS, that window is very small, probably less than 1 ps. In any case it's *much* smaller than the window you normally try to stay out of between setup and hold when using synchronous logic. The chances of getting a metastable event at the first flip-flop when introducing an asynchronous signal is simply the probability that an edge of the incoming signal falls within this metastability window. Note that the expected failure rate is related to both the clock rate, which determines how often in time a window is "open" and the edge rate of the incoming signal. Now we come to why you want a second flip-flop. A metastable event has the effect of increasing the clock to output timing of the first flip-flop. There is theoretically no upper bound on the amount of time that the event can last, but the chances of the event lasting any particular length of time go down *very* quickly as the length of time goes up. In real world applications, there are secondary processes (mostly system noise) that "help" an event to end in a way similar to a coin standing on edge on a bar where there are a lot of patrons picking up and setting down mugs. In any case you can see that you want "slack" time in the path from this first flip-flop to all other synchronous elements. The second flop is an easy way to ensure the ease of adding a lot of slack in the path. However it has a secondary impact on the chance of failure. When the first flop has an event that increases its time such that all subsequent flops no longer meet setup requirements, your circuit will fail. With the second flip-flop in place, instead of having an upper bound after which the circuit will fail, what you need for failure is an event that causes the second flip-flop to go metastable. This means that instead of the probability of an event being greater than "x" you now are looking at the probability of an event being exactly "x" +/- something very small. So even if the first path doesn't have the slack to prevent a metastable event from violating the setup/hold of the second flop, the system won't actually fail unless the event is within a very small range. This dramatically reduces the MTBF. Now deciding whether you really need a second flop depends on requirements for MTBF and the amount of slack you can give between the first flop and all of its loads. At a low clock frequency it's likely that you can ensure enough slack that you don't need the second flop to meet the MTBF requirements. A slower clock also means that you add more delay by inserting another flop. If latency is an issue, you probably don't want to do that. It's a bit counterintuitive, but in this case you could actually improve MTBF without adding delay by using a second flop on the opposite clock edge, assuming you can meet timing to subsequent flops in 1/2 clock period. -- GaborArticle: 157457
On Friday, June 16, 2000 2:00:00 AM UTC-5, rob_di...@my-deja.com wrote: > This is a serious question, because I often wonder why people ask such > questions:- > > was it really quicker to post this question to a news group and wait a > day or so for someone to give you a one liner answer than to read page > 1 of any EPLD datasheet and page 1 of any FPGA datasheet? > > Rob > > PS the answer you were given was correct as far as it went but a full > answer would take at least 200 words and did you really expect someone > to bother? > Dude do you really have to be an @$$ about it? Either help him or don't but don't chastise someone for asking what to YOU seems like a dumb question.Article: 157458
Would it be possible to connect an FPGA up to an 80386 (or other) CPU, to respond to memory and port requests, and leverage it as a resource? I'm thinking software runs on the 80386, given it by the FPGA, instructing it as a type of co- processor, which does things on command. I see voltage differences as an issue. Best regards, Rick C. HodginArticle: 157459
On Thursday, 11 December 2014 20:55:20 UTC+1, Rick C. Hodgin wrote: > Would it be possible to connect an FPGA up to > an 80386 (or other) CPU, to respond to memory > and port requests, and leverage it as a resource? > > I'm thinking software runs on the 80386, given > it by the FPGA, instructing it as a type of co- > processor, which does things on command. > > I see voltage differences as an issue. > > Best regards, > Rick C. Hodgin http://igg.me/at/zynq :) get one I did build many of my work stations myself, 8088 based, 80386 was advanced stuff. All is doable, question is what makes sense and what is fun. Hacking bare metal Zynq is FUN!Article: 157460
Le 11/12/2014 18:40, gentrysm1@gmail.com a écrit : > On Friday, June 16, 2000 2:00:00 AM UTC-5, rob_di...@my-deja.com wrote: [...] > Dude do you really have to be an @$$ about it? Either help him or don't but don't chastise someone for asking what to YOU seems like a dumb question. Do you realize the post you're answering to is 14 years old ? NicolasArticle: 157461
How would I handle the disparate voltages? Are there rail devices which support N pins in at V1, which then support V2 out the other side? So I would wire 80386 to rail-1, and rail-2 to FPGA? Best regards, Rick C. HodginArticle: 157462
Antti wrote: > I did build many of my work stations myself, > 8088 based... Nice. Best regards, Rick C. HodginArticle: 157463
On 11/12/2014 19:55, Rick C. Hodgin wrote: Hi Rick, > Would it be possible to connect an FPGA up to > an 80386 (or other) CPU, to respond to memory > and port requests, and leverage it as a resource? Sure, look at the 387 interface. The 386 does all the hard work of decoding the effective address and when the data is ready the 387 grabs it. > > I'm thinking software runs on the 80386, given > it by the FPGA, instructing it as a type of co- > processor, which does things on command. > > I see voltage differences as an issue. Have a look at Enterpoint's Craignell module schematics: http://www.enterpoint.co.uk/component_replacements/craignell.html Regards, Hans. www.ht-lab.com > > Best regards, > Rick C. Hodgin >Article: 157464
On 2014-12-11 Antti wrote in comp.arch.fpga: > > http://igg.me/at/zynq >:) get one > > I did build many of my work stations myself, 8088 based, 80386 was advanced stuff. > > All is doable, question is what makes sense and what is fun. > > Hacking bare metal Zynq is FUN! It indeed is! I started not too long ago on the zynq, using the Avnet MicroZed. Now have a daul core bare metal app running. I found this blog very helpful: http://forums.xilinx.com/t5/Xcell-Daily-Blog/Adam-Taylor-s-MicroZed-Chronicles-Part-61-PicoBlaze-Part-Six/ba-p/551888 (scroll to the bottom of the page for an index of all articles, starting at the very first steps. Even if you are not using the MicroZed I think most of it is very useful for getting familiar with the zynq. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) mathematician, n.: Some one who believes imaginary things appear right before your _i's.Article: 157465
On 12/11/2014 1:24 PM, Rick C. Hodgin wrote: > How would I handle the disparate voltages? What does this mean ??Article: 157466
hamilton wrote: > On 12/11/2014 1:24 PM, Rick C. Hodgin wrote: > >How would I handle the disparate voltages? > > What does this mean ?? The 80386 uses 5V. I was thinking the Altera Cyclone V GX Starter Kit only supported up to 3.3V. But I see now it supports 5V on GPIO pins. Best regards, Rick C. HodginArticle: 157467
On Thu, 11 Dec 2014 12:24:15 -0800, Rick C. Hodgin wrote: > How would I handle the disparate voltages? Are there rail devices which > support N pins in at V1, > which then support V2 out the other side? So I would wire 80386 to > rail-1, and rail-2 to FPGA? > > Best regards, > Rick C. Hodgin You want a level shifter or translator: <http://www.digikey.com/product-search/en/integrated-circuits-ics/logic- translators/2556437> -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157468
On Thu, 11 Dec 2014 14:03:14 -0800, Rick C. Hodgin wrote: > hamilton wrote: >> On 12/11/2014 1:24 PM, Rick C. Hodgin wrote: >> >How would I handle the disparate voltages? >> >> What does this mean ?? > > The 80386 uses 5V. I was thinking the Altera Cyclone V GX Starter Kit > only supported up to 3.3V. But I see now it supports 5V on GPIO pins. "Support" as in it will let you power a GPIO block from 5V? Or does it just mean that a 3.3V GPIO pin is 5V tolerant? If the latter, then you need to make sure that the '386 has TTL-level inputs (V_HI < 3V or so). -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157469
On Thu, 11 Dec 2014 11:55:14 -0800, Rick C. Hodgin wrote: > Would it be possible to connect an FPGA up to an 80386 (or other) CPU, > to respond to memory and port requests, and leverage it as a resource? > > I'm thinking software runs on the 80386, given it by the FPGA, > instructing it as a type of co- processor, which does things on command. > > I see voltage differences as an issue. > > Best regards, > Rick C. Hodgin Are you doing this to have fun playing with obsolete processors, or do you have a job to do? If it's the former -- have fun. If it's the latter -- you are aware that there are all sorts of far more modern solutions to this general problem than the one you're proposing, yes? -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157470
On Thu, 11 Dec 2014 21:01:12 +0100, Nicolas Matringe wrote: > Le 11/12/2014 18:40, gentrysm1@gmail.com a écrit : >> On Friday, June 16, 2000 2:00:00 AM UTC-5, rob_di...@my-deja.com wrote: > [...] >> Dude do you really have to be an @$$ about it? Either help him or don't >> but don't chastise someone for asking what to YOU seems like a dumb >> question. > > Do you realize the post you're answering to is 14 years old ? Speaking of useless chastisement... -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157471
Is there a way to monitor signals in existing wires? For example, with an oscilloscope and probe I can watch voltage changes. Is there a standard way to connect to an existing, working device, and monitor and record its switching over time? Such would seem to be desirable for peeking at proprietary "wake up" chirps, and to monitor device communications to establish its protocol interface. On old phone systems, a coil device could be used to "copy" the phone signal without tapping the voltage. I guess I'm looking for something similar for general purpose wire use. Best regards, Rick C. HodginArticle: 157472
On Wed, 10 Dec 2014 14:21:01 -0500, rickman wrote: > On 12/10/2014 1:05 PM, Tim Wescott wrote: >> On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote: >> >>> On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote: >>>> >>>> Also, metastability decreases exponentially with decreasing clock >>>> rate. >>> >>> Can you explain this claim? I can't think of any reason why >>> metastability would be anything but linear with clock rate if the same >>> slack time is available. >> >> If you clock a FF at time t, and you don't use the result until time t >> + Ts (Ts being your clock period), then the FF has that whole Ts-long >> period to resolve the metastability one way or another. That part will >> be exponential with Ts. > > You are forgetting about the time required for the signal to propagate > to the output, through the logic, and the setup time for the next FF. > These times all need to be subtracted from the clock cycle time yielding > the slack time. This is the only number important to resolving > metastability. I suspect that the paper (which doesn't sound very thorough) is presupposing that you take a design with a given propagation delay, and just start turning the frequency down on the clock. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157473
On 11/12/14 19:55, Rick C. Hodgin wrote: > Would it be possible to connect an FPGA up to > an 80386 (or other) CPU, to respond to memory > and port requests, and leverage it as a resource? > > I'm thinking software runs on the 80386, given > it by the FPGA, instructing it as a type of co- > processor, which does things on command. IIRC Intel has wittered about such a thing in the last year. Informed opinion seemed skeptical that it would amount to much. I suspect Intel's objective was to try to take the steam out if ARM's sails, since ARM is more than happy for you to embed their processors in your own logic; see any smartphone for details. A much more interesting half-way house is Xilinx's Zynq chips, i.e a dual-core ARM and FPGA fabric, tightly intertwined with decent Verilog/VHDL tools and software development environments. Have a look at the MicroZed and similar boards. > I see voltage differences as an issue. Not if the FPGA and processor are in the same package, which is the best arrangement.Article: 157474
Tim Wescott wrote: > "Support" as in it will let you power a GPIO > block from 5V? Or does it just mean that a > 3.3V GPIO pin is 5V tolerant? It says you can assign 5V to each pin, which I assume means true I/O. I would use externally regulated 5V power supply, as from an old case, for all CPU Vcc inputs. The GPIO would only power data and a handful of switches. > If the latter, then you need to make sure that > the '386 has TTL-level inputs (V_HI < 3V or so). Definitely a 5V part circa 1986. Ceramic 16 MHz package. Best regards, Rick C. Hodgin
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