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 May 17, 9:17 am, Paul <pauljbenn...@gmail.com> wrote: > Peter, > > I know you folks at Xilinx like to claim that you've permanently > solved all the world's metastability problems, our xilinx fae tells us > the same things.... And maybe you're right for telecom applications > and whatnot. But I hope you don't support many Hi-rel applications > because I promise you, no defense or aerospace company is going to > happy being told they don't need to double register asynchronous > signals. Our design guidelines here at unstated defense company > (sorry, i dont disclose that on the net) are VERY strict about double > registering ALL asynchronous signals, no questions asked. 2 D-Q > crossings and nothing else. Right or wrong, I haven't been in the > business long enough to know for sure, we view metastability as a > statistical thing...and like most naturally occurring statistics, zero > probability tends to never exist, very very very small near zero > probabilities exist. > > At anyrate... yes, I'm well aware of Xilinx's current stand on the > metastability problem. But you yourself just said that the problem > exists for "a few ns" statistically exceeding 3ns once in a universe. > So lets say 2 ns is something we should design for then.... 2ns = > 500MHz.... What's Xilinx's Fmax these days??? Even if its not a > problem now, it's soon to become a problem again unless you're going > to tell me you're done increasing your operating frequencies. > > anywho... our view and i believe the view of most of the defense/ > aerospace world is that something as simple as 2 registers is not > worth ANY impact on system reliability. > > On May 16, 5:42 pm, Peter Alfke <p...@xilinx.com> wrote: > > > > > Maybe this is homework, or it is an interview question, but I took it > > as a challenge. > > Being a minimalist, and understanding metastability fairly well, I > > came up with the following solution: > > > Only one 4-input LUT plus a flip-flop clocked by the slow clock. > > LUT inputs are: INput pulse, slow CLK signal, its own output O, the > > flip-flop output Q > > ( set O if Qbar AND INpulse, reset O if Q AND CLKbar, otherwise keep > > O. O drives flip-flop D) > > > Ah, but how about metastability? > > If IN and CLK both go High within a certain bulls-eye that is <1 > > femtosecond wide, then Q might be undefined for a few ns after the > > rising clock edge. Statistically, the "few ns" will not exceed 3 ns > > during the lifetime of the universe. The, hopefully synchronous, slow > > clock domain should be able to cope with that. Otherwise concatanate > > another flip-flop. > > > Well, I do not know why anybody wants such a circuit, but it did > > exercise the grey cells... > > Peter Alfke > > > On May 16, 7:09 am, Paul <pauljbenn...@gmail.com> wrote: > > > > General rule of thumb is that you want 2 registers to cross between > > > clock domains, follow that rule to deal with any metastability > > > issues. Now you just have the problem that your first clock domain is > > > faster and you might not catch it with the slower domain. > > > > Personally, my approach here would be to "hold" the signal in your > > > CLK_FAST with an enabled register until you receive some sort of feed > > > back that you've grabbed it in CLK_SLOW, bearing in mind that those > > > feedback / feedforward signals should all be double registered to > > > prevent metastability. Also keep in mind that an enabled register > > > does NOT count as one of your two "synchronization" registers, because > > > an enabled register is actually implemented as a register with a mux > > > in front of it - only direct D-to-Q connections with NO combinational > > > logic count for clock domain crossing issues. Now, depending upon the > > > timing of it all, this could end you up with more than 1 clock pulse > > > width. Assuming that you know your input pulses are spaced far enough > > > apart that you KNOW it's not ACTUALLY multiple pulses, then a simple > > > edge detect will fix this problem for ya. > > > > The ideal behind the metastability stuff is that if you clock a signal > > > exactly at the transisition the output of the flop has some > > > probability of floating somewhere between 0 and 1 for some amount of > > > time. Adding any combinatorial logic extends that amount of time. > > > The idea of having 2 registers is that you reduce your probability of > > > a metastable event because even if you hit that .01% chance of it > > > remaining metastable for long enough to create a problem at the first > > > register, you got another .01% on your side at the second register. > > > (Note: .01% is much higher than it really is.. but remember, if you're > > > clocking signals in the MHz range, those tiny probabilities add up > > > REAL quick!) > > > > On May 16, 1:35 am, himassk <hima...@gmail.com> wrote: > > > > > Hi, > > > > > Please suggest me how to transfer a single clockwide pulse from high > > > > frequency clock domain and create a single clockwide pulse in a slow > > > > clock domain? > > > > What are different methods available? > > > > > Thanks in advance. > > > > > Regards, > > > > Himassk.- Hide quoted text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - Paul, I would rate Peter as one of the most knowledgable people in the area of metastability, He has published papers and performed experiments characterizing metastability as Xilinx products have evolved. I think you have to take the comment within the context of what he was explaining, that the circuit could be done with one LUT and one FF. As to whether it is worth the trouble of arguing and guaranteeing that there is enough slack time to all the other FF's is another story, and adding another stage may be the most expedient method. He did mention it, and it is probably the way to go for those of us less knowledgable in this area. - NewmanArticle: 119376
"Paul" <pauljbennett@gmail.com> wrote in message news:1179407855.921375.242960@k79g2000hse.googlegroups.com... > Peter, > > signals. Our design guidelines here at unstated defense company > (sorry, i dont disclose that on the net) are VERY strict about double > registering ALL asynchronous signals, no questions asked. 2 D-Q > crossings and nothing else. Right or wrong, I haven't been in the > business long enough to know for sure, we view metastability as a > statistical thing...and like most naturally occurring statistics, zero > probability tends to never exist, very very very small near zero > probabilities exist. > Aha, the common spotted "that's the way we've always done it"! Guess what, you should do the maths to work out if you can use 1,2 or maybe more FFs as the technology changes rather than relying on what's gone before! Cheers, Syms. p.s. Here's a tip for the top, if want your unstated defense company employer to stay undisclosed on this, ahem, 'NG', you might consider not posting from work. Bless!Article: 119377
Excellent points, Symon -- things like that sure have happened in the past! There is also some focus on "dissimilar spares" in attempts to mitigate what you describe. Thank you for the insight! Anne On May 16, 4:57 pm, "Symon" <symon_bre...@hotmail.com> wrote: > "Anne" <anneatkin...@yahoo.com> wrote in message > > news:1179331157.808046.24310@y80g2000hsf.googlegroups.com... > > > An ultimate goal of this sub-project is to reduce the total number of > > spare parts that must be flown on a mission by having spares that are > > reconfigurable such that, for example, they could function as a DSP or > > microprocessor or microcontroller at any given time (just one specific > > application at any given time). > > Hi Anne, > Here's a thought. Imagine you make a bunch of identical thingies which can > be either a dsp, a uP, whatever. Cool, you've reduced the parts inventory. > You set off on your mission to Mars, and one of these things go wrong. > However, it turns out this is not a random failure, but a systemic failure > due to a design fault. (Perhaps the sub-contract designer mixed up imperial > and metric units?!) This means, because all your replacements are identical, > they'll all have the same fault. Kinda like the reason that some people > think GM crops are bad, because a single disease can wipe out an entire > harvest of a monoculture plant. > Maybe there's an argument to have a couple (or maybe more) different designs > of replacement. It's a long trip to Fry's from the red planet! > Cheers, Syms.Article: 119378
cs_posting@hotmail.com wrote: > On May 17, 12:16 am, GomoX <gomox...@gmail.com> wrote: >> Hey everyone, >> >> As an assignment for a course in my CS degree, I have to build a D >> latch, a D flip flop and a 1 bit register with VHDL. I have been given >> the "process" versions of those and I have to rewrite them using >> elementary gates and feedback connections. >> >> My teachers are not really profficient in the topic (sadly) but we are >> going through hoops to get stuff working. I have read on several pages >> that because of limitations in VHDL simulations, basic sequential >> circuits such as the latch/ff should not be implemented with gates but >> using processes instead. > > Yes, you really don't want to do that. Looping back a combinatorial > output makes a sort of infinite loop of dependencies for the simulator > to try to make sense of. In the real world it works because of delay > and capacitance and stuff like that, but an HDL simulator it's not > designed to do physical modeling of actual devices! Instead it's > designed to simulate the application-level behaviour of devices that > can be reasonably represented with just a few paramaters (like > propogation delay), and having just a few states, (like 1, 0, > undriven, and unkown) > > If you want to do something like what you are talking about, try > playing with software that's designed to simulate the analog behaviour > of real devices, which is to say spice. Get yourself some simple > logic gate circuits to put in a spice deck and play with graphing how > that responds over time to "digital" inputs. > > If you *must* build gate models in VHDL, be sure to include a delay in your gate, eg OUT <= not(IN1 and IN2) after 2 ns;Article: 119379
On May 17, 12:19 am, sudhakar...@gmail.com wrote: > Hi to all ............ > > Now i am in to developing DDR2memory contoller with STRATIX II EP2S > 180 . > Is there mega core which can support burst length 8 ?I found only > burst lenth 4 controllers. So i have written and no problem with code. > I am using DDIO bidirectional mega function for data path to send and > receive data on both edges . But problem is so many set up and Hold > time violations with this mega function . > Has any body developed own memory controller for BURST LENTH 8 . > please help me regarding this .......... > > thanks and regrads > sudhakar Hi Sudhakar, Check out http://www.nwlogic.com. They have cores that are allow burst of len of 8. But to get back to you problem, are you seeing setup and hold time violations in simulation? -sanjayArticle: 119380
Since the OP specifically asked about a window where setup violations occur, we are looking at metastablity from a different view point than what is the probability of a metastable event from a random asynchornous input. First metastability can be induced reliably in the lab for demostration to students ... we did this in the 1980's, and here is a current online reference http://www.sigcon.com/Pubs/news/4_4.htm on how to demonstrate it. Note the key variable in not time or probability, but a precise window of input voltage. Metastability can occur any where we have a feedback path in logic, but it's best understood in terms of FF's. It's generally defined as an event when a FF continues to oscillate longer than a clock period. What's particularly wicked about this, is any amount of oscillation will result in additional dynamic switching power, including periods less than a full clock period which would create a metastable event by definition. Now, if we consider just the switching interval of a CMOS logic gate output, we have a predictable voltage/time ramp generator between the two rails. The particular voltage of this ramp is predictable in time relative to it's clock (or driving input), and by varying the time, we can predictably produce inputs near/at the metastable input voltage for the FF. This is the state we are in with a synchronous system with setup violations, as the OP specifically questions about. As any number of inputs to FF's hover around the metastable input voltage, the amount of oscillation will increase, and increase dynamic power as a result ... the amount of power increase depends directly on the system design. If the oscillations occur on high fanout signals with excessive routing, the switched capacitance will be very high, and possibly relatively high power will be consumed as compared to normal operation. Even very small voltage changes in the ramp, as caused by very small increases in timing delay by die thermal heating, may well have the possiblity of pushing the ramp voltage closer to the metastable voltage, so some thermal feedback is quite possible here, depending on the design. On May 17, 5:57 am, Paul Leventis <paul.leven...@gmail.com> wrote: > There is an extremely narrow window of time where metastability occurs > in a flip-flop, and the window in which prolonged metastability occurs > (something close to the clock period, for example) is infintessimally > small. The chances of having a large number of FFs in a metastable > state for any appreciable time is essentially nil. Given the above, please explain why?Article: 119381
sudhakarmvs@gmail.com wrote: The Microtronix DDR core apparently is ble to handle BLEN=8. It's also very robust when it comes to setup&hold. Have a look at the FPGA Products page of wwww.microtronix.com Best regards, BenArticle: 119382
Hi Folks, I need to put in DDR or DD2 interfaces. I need about 1.2GB/s bandwidth. As I am targetting a low end fpga, I am limited by the max bitrate on the i/o. (DDR333 or DDR2-400). What will be a better alternative go with DDR333 or DDR2-400? My main considerations are - power and ability to hide the latencies during accesses. From what I see on the usual memory vendors - 1. Mobile DDR available in x32 organization in one package 2. DDR2 available in x16 but significantly lower power at IDD7. I would love to hear your thoughts. Thank you. Best regards, SanjayArticle: 119383
Hello, Is there any expert who can guide me about the following problem: I need video system with following main specifications. 1) Input : standard video formats 2) compression: MPEG4/MPEG2 etc. 3) Output: RS232 4) Decoder: Soft decoder in PC Is there any company who offers customized solutions in this area. ThanksArticle: 119384
Dear all, Thank you for your patience... I have looked up on the web and read quite a few articles but I am still very confused re SystemC and TLM. My understanding is that TLM allows you to model at an appropriate level for what you want to do (communication and functional are separated, timed and untimed detail for either possible). However, I don't understand where TLMs go. Say I have an architectural model in software - call it arch. I have a hardware RTL model for an FPGA. I want arch to call up hardware. Is the TLM used between arch and hardware? When the person's developing arch, is hardware replaced by its equivalent TLM? And, more fundamentally - is TLM just an abstract idea? I mean, if we have to create another model (now called a TLM), why give it another special name? Isn't it just another block of SystemC? I hope that you can help in some way, even if only to refer to some online explanations or suggest another newsgroup. regards, confusedArticle: 119385
I am not trying to teach anyone anything, I have read many of your documents and I realize you are a very informed source. I apologize if you took my comments any differently. I simply wanted to point out that if our initialer poster is eventually going to be working in a hi- rel industry they very likely may be required to treat this as a potential problem - whether or not it is necessarily proven by current studies. If you read my comments, I openly noted that I do not have a wealth of experience but that in practice this is often the case in such industries. I claim to have no knowledge beyond that, nor did I previously make that claim. And I certainly did not question your expertise in the area, I apologize if it came across that way. On May 17, 1:24 pm, Peter Alfke <p...@xilinx.com> wrote: > Paul, you don't have to teach me about the dangers of metastability. I > am the one who has performed lots of quantitative measurements. But I > am also fighting any un-qualified paranoia. > > In this particular design I pointed out that the effect of > metastability is an uncontrollable statistical delay on the output of > the flip-flop that, per description, is clocked by the "slow clock". > I wrote that the "slow clock" domain probably has enough slack to > accomodate a few ns of uncontrollable delay at the flip-flop output. > "Slow clock" does not mean 500 MHz, in my book. > > I know what I am talking about, and I was forthcoming and explicit. > This was a specific circuit, no need to bombard me with > generalities. > > And for the record: > Xilinx and I personally have NEVER EVER claimed to have solved the > metastability problem. Because we all known that to be impossible. I > have just, quite often, quantified the probabilities. > > BTW: I consider your posting ill-informed, offensive and slanderous. > Peter Alfke > > ============== > On May 17, 6:17 am, Paul <pauljbenn...@gmail.com> wrote: > > > > > Peter, > > > I know you folks at Xilinx like to claim that you've permanently > > solved all the world's metastability problems, our xilinx fae tells us > > the same things.... And maybe you're right for telecom applications > > and whatnot. But I hope you don't support many Hi-rel applications > > because I promise you, no defense or aerospace company is going to > > happy being told they don't need to double register asynchronous > > signals. Our design guidelines here at unstated defense company > > (sorry, i dont disclose that on the net) are VERY strict about double > > registering ALL asynchronous signals, no questions asked. 2 D-Q > > crossings and nothing else. Right or wrong, I haven't been in the > > business long enough to know for sure, we view metastability as a > > statistical thing...and like most naturally occurring statistics, zero > > probability tends to never exist, very very very small near zero > > probabilities exist. > > > At anyrate... yes, I'm well aware of Xilinx's current stand on the > > metastability problem. But you yourself just said that the problem > > exists for "a few ns" statistically exceeding 3ns once in a universe. > > So lets say 2 ns is something we should design for then.... 2ns = > > 500MHz.... What's Xilinx's Fmax these days??? Even if its not a > > problem now, it's soon to become a problem again unless you're going > > to tell me you're done increasing your operating frequencies. > > > anywho... our view and i believe the view of most of the defense/ > > aerospace world is that something as simple as 2 registers is not > > worth ANY impact on system reliability. > > > On May 16, 5:42 pm, Peter Alfke <p...@xilinx.com> wrote: > > > > Maybe this is homework, or it is an interview question, but I took it > > > as a challenge. > > > Being a minimalist, and understanding metastability fairly well, I > > > came up with the following solution: > > > > Only one 4-input LUT plus a flip-flop clocked by the slow clock. > > > LUT inputs are: INput pulse, slow CLK signal, its own output O, the > > > flip-flop output Q > > > ( set O if Qbar AND INpulse, reset O if Q AND CLKbar, otherwise keep > > > O. O drives flip-flop D) > > > > Ah, but how about metastability? > > > If IN and CLK both go High within a certain bulls-eye that is <1 > > > femtosecond wide, then Q might be undefined for a few ns after the > > > rising clock edge. Statistically, the "few ns" will not exceed 3 ns > > > during the lifetime of the universe. The, hopefully synchronous, slow > > > clock domain should be able to cope with that. Otherwise concatanate > > > another flip-flop. > > > > Well, I do not know why anybody wants such a circuit, but it did > > > exercise the grey cells... > > > Peter Alfke > > > > On May 16, 7:09 am, Paul <pauljbenn...@gmail.com> wrote: > > > > > General rule of thumb is that you want 2 registers to cross between > > > > clock domains, follow that rule to deal with any metastability > > > > issues. Now you just have the problem that your first clock domain is > > > > faster and you might not catch it with the slower domain. > > > > > Personally, my approach here would be to "hold" the signal in your > > > > CLK_FAST with an enabled register until you receive some sort of feed > > > > back that you've grabbed it in CLK_SLOW, bearing in mind that those > > > > feedback / feedforward signals should all be double registered to > > > > prevent metastability. Also keep in mind that an enabled register > > > > does NOT count as one of your two "synchronization" registers, because > > > > an enabled register is actually implemented as a register with a mux > > > > in front of it - only direct D-to-Q connections with NO combinational > > > > logic count for clock domain crossing issues. Now, depending upon the > > > > timing of it all, this could end you up with more than 1 clock pulse > > > > width. Assuming that you know your input pulses are spaced far enough > > > > apart that you KNOW it's not ACTUALLY multiple pulses, then a simple > > > > edge detect will fix this problem for ya. > > > > > The ideal behind the metastability stuff is that if you clock a signal > > > > exactly at the transisition the output of the flop has some > > > > probability of floating somewhere between 0 and 1 for some amount of > > > > time. Adding any combinatorial logic extends that amount of time. > > > > The idea of having 2 registers is that you reduce your probability of > > > > a metastable event because even if you hit that .01% chance of it > > > > remaining metastable for long enough to create a problem at the first > > > > register, you got another .01% on your side at the second register. > > > > (Note: .01% is much higher than it really is.. but remember, if you're > > > > clocking signals in the MHz range, those tiny probabilities add up > > > > REAL quick!) > > > > > On May 16, 1:35 am, himassk <hima...@gmail.com> wrote: > > > > > > Hi, > > > > > > Please suggest me how to transfer a single clockwide pulse from high > > > > > frequency clock domain and create a single clockwide pulse in a slow > > > > > clock domain? > > > > > What are different methods available? > > > > > > Thanks in advance. > > > > > > Regards, > > > > > Himassk.- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text -Article: 119386
Paul, apologies are accepted. In the future, when you admittedly are a novice, then do not start a posting with an obnoxious statement, like: "Peter, I know you folks at Xilinx like to claim that you've permanently solved all the world's metastability problems, our xilinx fae tells us the same things...." You seem to say that blindly obeying rules is more important than thinking. I am glad I do not work in such an environment. PeterArticle: 119387
Paul, To paraphrase your original post. "While you try to appear like you're not charlatans and yet 'solved the world's woes' and while some non-essential technologies might allow shoddy design practices you better not try to pass your lies on to those of us involved with 'real' technology who know better from experience." If you honestly intended no insult, you did an absurdly poor job of communicating your intent. Perhaps in the future it would be better to reread what you write, trying to look at the post from the perspective of someone else. The best thing would be to set the post aside for a few days before rereading it or have someone else read it to make sure your thoughts are communicated effectively; but since neither of those luxuries may be available or appropriate, please try to catch yourself before you disturb others - many more than the person you're attacking. Sorry... "responding to." Since it's already sent, set the post aside for a few days. If, next week, you can reread your response and believe that you were level-headed in your response with no assertion of "greater knowledge" and no appearance of belittling the author you were responding to... then there's no hope. If you can see why others reacted poorly to your diatribe, you have a chance to avoid the extreme - and unintended - positions you portray. Good luck and thanks for clarifying your viewpoint. - John_H "Paul" <pauljbennett@gmail.com> wrote in message news:1179432781.443392.211590@w5g2000hsg.googlegroups.com... >I am not trying to teach anyone anything, I have read many of your > documents and I realize you are a very informed source. I apologize > if you took my comments any differently. I simply wanted to point out > that if our initialer poster is eventually going to be working in a hi- > rel industry they very likely may be required to treat this as a > potential problem - whether or not it is necessarily proven by current > studies. If you read my comments, I openly noted that I do not have a > wealth of experience but that in practice this is often the case in > such industries. I claim to have no knowledge beyond that, nor did I > previously make that claim. And I certainly did not question your > expertise in the area, I apologize if it came across that way. <snip> >> On May 17, 6:17 am, Paul <pauljbenn...@gmail.com> wrote: >> >> >> >> > Peter, >> >> > I know you folks at Xilinx like to claim that you've permanently >> > solved all the world's metastability problems, our xilinx fae tells us >> > the same things.... And maybe you're right for telecom applications >> > and whatnot. But I hope you don't support many Hi-rel applications >> > because I promise you, no defense or aerospace company is going to >> > happy being told they don't need to double register asynchronous >> > signals. Our design guidelines here at unstated defense company >> > (sorry, i dont disclose that on the net) are VERY strict about double >> > registering ALL asynchronous signals, no questions asked. 2 D-Q >> > crossings and nothing else. Right or wrong, I haven't been in the >> > business long enough to know for sure, we view metastability as a >> > statistical thing...and like most naturally occurring statistics, zero >> > probability tends to never exist, very very very small near zero >> > probabilities exist. >> >> > At anyrate... yes, I'm well aware of Xilinx's current stand on the >> > metastability problem. But you yourself just said that the problem >> > exists for "a few ns" statistically exceeding 3ns once in a universe. >> > So lets say 2 ns is something we should design for then.... 2ns = >> > 500MHz.... What's Xilinx's Fmax these days??? Even if its not a >> > problem now, it's soon to become a problem again unless you're going >> > to tell me you're done increasing your operating frequencies. >> >> > anywho... our view and i believe the view of most of the defense/ >> > aerospace world is that something as simple as 2 registers is not >> > worth ANY impact on system reliability.Article: 119388
I've inherited a design at my new company where there are two source- synchronous interfaces at 80MHz SDR. On one interface a clock (tx_clk) is forwarded to the FPGA and on the other the clock (rx_clk) is forwarded from the FPGA. rx_clk is generated from taking tx_clk through an IBUF, BUFG, and finally an OBUF to the pad. These are single-ended LVCMOS25 clocks and the device is a Xilinx Virtex-4 LX80- FF1148-10. The entire system is synchronous to tx_clk. At my previous company, it was generally a rule of thumb to use a DDR IOB register to regenerate the clock when sending it out from the FPGA. Is this typically a good rule to follow, and, if so, is this written in some documentation? Thanks for any help!Article: 119389
Does anyone know of a location from which to download simple logic symbol shapes for Visio (and gate, or gate, etc)?Article: 119390
bwilson79@gmail.com wrote: > I've inherited a design at my new company where there are two source- > synchronous interfaces at 80MHz SDR. On one interface a clock > (tx_clk) is forwarded to the FPGA and on the other the clock (rx_clk) > is forwarded from the FPGA. rx_clk is generated from taking tx_clk > through an IBUF, BUFG, and finally an OBUF to the pad. These are > single-ended LVCMOS25 clocks and the device is a Xilinx Virtex-4 LX80- > FF1148-10. The entire system is synchronous to tx_clk. > > At my previous company, it was generally a rule of thumb to use a DDR > IOB register to regenerate the clock when sending it out from the > FPGA. Is this typically a good rule to follow, and, if so, is this > written in some documentation? > > Thanks for any help! > Using the DDR registers is the recommended way to regenerate the clock. It will be source-synchronous with the output data, provided that the output data is registered in the output IOBs. This scheme removes the variables of BUFG delay times and fabric routing delays. Note that your output rx_clk will not be phase-aligned with tx_clock. -KevinArticle: 119391
> Given the above, please explain why? The edges during transition inside FPGA are fairly sharp, therefore there is a very short window in which the arrival of the clock could cause a FF to go metastable. And since this window of opportunity is small and the arrival time of transistions to the various flops in a design has some spread to it, it is very unlikely that many FF would be metastable at the same time. - PaulArticle: 119392
<bwilson79@gmail.com> wrote in message news:1179435132.737655.222610@e65g2000hsc.googlegroups.com... > I've inherited a design at my new company where there are two source- > synchronous interfaces at 80MHz SDR. On one interface a clock > (tx_clk) is forwarded to the FPGA and on the other the clock (rx_clk) > is forwarded from the FPGA. rx_clk is generated from taking tx_clk > through an IBUF, BUFG, and finally an OBUF to the pad. These are > single-ended LVCMOS25 clocks and the device is a Xilinx Virtex-4 LX80- > FF1148-10. The entire system is synchronous to tx_clk. > > At my previous company, it was generally a rule of thumb to use a DDR > IOB register to regenerate the clock when sending it out from the > FPGA. Is this typically a good rule to follow, and, if so, is this > written in some documentation? > > Thanks for any help! I haven't come across specific documentation saying "do this!" The desire to use the same structures as those that generate the data comes down to error budgets. If you can guarantee that the clock and data are always in a valid relationship with the delivered source-synchronous communication channel, it doesn't matter which method you use. Since it's significantly easier to deliver *matched* delays for the DDR-generated clock, the error budget has significantly lower uncertainty than the combinatorial path. The skew can be a large factor in the overall error budget depending on the receiver. While a clock edge centered precisely between the data edges might seem like the best solution from an oscilloscope's perspective, having the clock preceed the data output and encounter a route onto the receiver chip that's longer than the data path to the chip's innards might be a better match overall. I'd suggest there's no "correct" way to cover all bases, just a "better" way for the specific transmit/receive pair characteristics. Personally, I DDR all my generated clocks. - John_HArticle: 119393
http://idioms.thefreedictionary.com/teach+grandmother+to+suck+eggs ;) Eric Paul wrote: > Peter, > > I know you folks at Xilinx like to claim that you've permanently > solved all the world's metastability problems, our xilinx fae tells us > the same things.... And maybe you're right for telecom applications > and whatnot. But I hope you don't support many Hi-rel applications > because I promise you, no defense or aerospace company is going to > happy being told they don't need to double register asynchronous > signals. Our design guidelines here at unstated defense company > (sorry, i dont disclose that on the net) are VERY strict about double > registering ALL asynchronous signals, no questions asked. 2 D-Q > crossings and nothing else. Right or wrong, I haven't been in the > business long enough to know for sure, we view metastability as a > statistical thing...and like most naturally occurring statistics, zero > probability tends to never exist, very very very small near zero > probabilities exist. > > At anyrate... yes, I'm well aware of Xilinx's current stand on the > metastability problem. But you yourself just said that the problem > exists for "a few ns" statistically exceeding 3ns once in a universe. > So lets say 2 ns is something we should design for then.... 2ns = > 500MHz.... What's Xilinx's Fmax these days??? Even if its not a > problem now, it's soon to become a problem again unless you're going > to tell me you're done increasing your operating frequencies. > > anywho... our view and i believe the view of most of the defense/ > aerospace world is that something as simple as 2 registers is not > worth ANY impact on system reliability. > > > > On May 16, 5:42 pm, Peter Alfke <p...@xilinx.com> wrote: >> Maybe this is homework, or it is an interview question, but I took it >> as a challenge. >> Being a minimalist, and understanding metastability fairly well, I >> came up with the following solution: >> >> Only one 4-input LUT plus a flip-flop clocked by the slow clock. >> LUT inputs are: INput pulse, slow CLK signal, its own output O, the >> flip-flop output Q >> ( set O if Qbar AND INpulse, reset O if Q AND CLKbar, otherwise keep >> O. O drives flip-flop D) >> >> Ah, but how about metastability? >> If IN and CLK both go High within a certain bulls-eye that is <1 >> femtosecond wide, then Q might be undefined for a few ns after the >> rising clock edge. Statistically, the "few ns" will not exceed 3 ns >> during the lifetime of the universe. The, hopefully synchronous, slow >> clock domain should be able to cope with that. Otherwise concatanate >> another flip-flop. >> >> Well, I do not know why anybody wants such a circuit, but it did >> exercise the grey cells... >> Peter Alfke >> >> On May 16, 7:09 am, Paul <pauljbenn...@gmail.com> wrote: >> >> >> >>> General rule of thumb is that you want 2 registers to cross between >>> clock domains, follow that rule to deal with any metastability >>> issues. Now you just have the problem that your first clock domain is >>> faster and you might not catch it with the slower domain. >>> Personally, my approach here would be to "hold" the signal in your >>> CLK_FAST with an enabled register until you receive some sort of feed >>> back that you've grabbed it in CLK_SLOW, bearing in mind that those >>> feedback / feedforward signals should all be double registered to >>> prevent metastability. Also keep in mind that an enabled register >>> does NOT count as one of your two "synchronization" registers, because >>> an enabled register is actually implemented as a register with a mux >>> in front of it - only direct D-to-Q connections with NO combinational >>> logic count for clock domain crossing issues. Now, depending upon the >>> timing of it all, this could end you up with more than 1 clock pulse >>> width. Assuming that you know your input pulses are spaced far enough >>> apart that you KNOW it's not ACTUALLY multiple pulses, then a simple >>> edge detect will fix this problem for ya. >>> The ideal behind the metastability stuff is that if you clock a signal >>> exactly at the transisition the output of the flop has some >>> probability of floating somewhere between 0 and 1 for some amount of >>> time. Adding any combinatorial logic extends that amount of time. >>> The idea of having 2 registers is that you reduce your probability of >>> a metastable event because even if you hit that .01% chance of it >>> remaining metastable for long enough to create a problem at the first >>> register, you got another .01% on your side at the second register. >>> (Note: .01% is much higher than it really is.. but remember, if you're >>> clocking signals in the MHz range, those tiny probabilities add up >>> REAL quick!) >>> On May 16, 1:35 am, himassk <hima...@gmail.com> wrote: >>>> Hi, >>>> Please suggest me how to transfer a single clockwide pulse from high >>>> frequency clock domain and create a single clockwide pulse in a slow >>>> clock domain? >>>> What are different methods available? >>>> Thanks in advance. >>>> Regards, >>>> Himassk.- Hide quoted text - >> - Show quoted text - > >Article: 119394
I have Visio 2003, a search for gates bought it all up. "Richard Henry" <pomerado@hotmail.com> wrote in message news:1179436266.635156.169680@n59g2000hsh.googlegroups.com... > Does anyone know of a location from which to download simple logic > symbol shapes for Visio (and gate, or gate, etc)? >Article: 119395
On May 17, 3:18 pm, Paul Leventis <paul.leven...@gmail.com> wrote: > > Given the above, please explain why? > > The edges during transition inside FPGA are fairly sharp, therefore > there is a very short window in which the arrival of the clock could > cause a FF to go metastable. And since this window of opportunity is > small and the arrival time of transistions to the various flops in a > design has some spread to it, it is very unlikely that many FF would > be metastable at the same time. > > - Paul And they are all very sharp independent of fanout?Article: 119396
<confusedpp@gmail.com> wrote in message news:1179432667.625797.158110@l77g2000hsb.googlegroups.com... > Dear all, > Thank you for your patience... > I have looked up on the web and read quite a few articles but I am > still very confused re SystemC and TLM. > My understanding is that TLM allows you to model at an appropriate > level for what you want to do (communication and functional are > separated, timed and untimed detail for either possible). Correct, just think of TLM as a function call, so for example instead of changing address, assert read strobe and then read the data you would just issue a function called say read_data(address). The advantage is that your simulator has to schedule far less events and thus should run a lot quicker. > However, I don't understand where TLMs go. > Say I have an architectural model in software - call it arch. I have > a hardware RTL model for an FPGA. > I want arch to call up hardware. Is the TLM used between arch and > hardware? When the person's developing arch, is hardware replaced by > its equivalent TLM? yes, TLM sits between arch and your hardware, to be more precise, your hardware is connected to an adaptor which translates pins wiggles to TLM function calls. > > And, more fundamentally - is TLM just an abstract idea? I mean, if > we > have to create another model (now called a TLM), why give it another > special name? Isn't it just another block of SystemC? Yes, you could see it like that. TLM is just another model/block of concurrent processes communicating using functions calls. Download the SCV library and have a look at some of the examples, they might explain things better. > > I hope that you can help in some way, even if only to refer to some > online explanations or suggest another newsgroup. > Try the SystemC forum https://www.systemc.org/forum/forum.php?forum_id=5 were a lot of the Doulos experts hang around :-) > > regards, > confused I am also still confused on a lot of SystemC (and C++) stuff.... Hans www.ht-lab.comArticle: 119397
On May 17, 3:18 pm, Paul Leventis <paul.leven...@gmail.com> wrote: > > Given the above, please explain why? > > The edges during transition inside FPGA are fairly sharp, therefore > there is a very short window in which the arrival of the clock could > cause a FF to go metastable. And since this window of opportunity is > small and the arrival time of transistions to the various flops in a > design has some spread to it, it is very unlikely that many FF would > be metastable at the same time. Thanks Paul. It's simple enough to verify with a worst case design that exploits worst case switching power (from the oscillations) from a small number of driving FF's located in areas with relatively low clock skew, and constructed with worst case fanout to slow down the switching speed. Next time I'm near a large Altera FPGA and software in the lab with some time to spend, I'll give it a try.Article: 119398
One other question Paul ... do the Altera/Xilinx parts have any problems with cut thru power (top and bottom transistors on at same time) in any worst case situations related to setup violations, clock rate, or fanout?Article: 119399
On May 17, 2:33 pm, "scada" <s...@optonline.net> wrote: > I have Visio 2003, a search for gates bought it all up. > > "Richard Henry" <pomer...@hotmail.com> wrote in message > > news:1179436266.635156.169680@n59g2000hsh.googlegroups.com... > > > > > Does anyone know of a location from which to download simple logic > > symbol shapes for Visio (and gate, or gate, etc)?- Hide quoted text - > > - Show quoted text - I have 2003, Standard Version. I don't see any place to search for shpes.
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