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
Elftmann wrote: > Peter, > > The A40MX02 and A40MX04 devices still require the master/slave latch > implementation, we call these CC-Flops. While the A40MX family is not a > qualified space environment device, it is interesting to note that the > CC-Flops have traditionally had better "Single Event Upset" SEU > characteristics versus the "hard-coded" flops in the RH1280 (same > architecture as A42MX). I believe that. SEU-tolerance gets better when there is a lot of "inertia" in the latch, while fast metastable recovery needs a "nervous", very fast feedback loop. Peter AlfkeArticle: 24851
As you may have read, Xilinx will put PowerPCs in the Virtex-II chips. That might make part of this discussion moot. I don't like to sell futures or sound like a marketeer, but this might be important information for the user community. This is public information, let's talk details in a few months... Peter Alfke Ben Franchuk wrote: > Chris Hills wrote: > > > > Ben Franchuk <bfranchuk@jetnet.ab.ca> writes > > > > > > Why do all the design tutorials settle on 8 bit cpu's or > > >16 bit RISC's or PDP-8's. Would not a medium sized project > > >(24/32/36) be better examples to show both the power and the > > >limitations of FPGA's. Or is it that the low cost/student development > > >systems can only handle the low end (ie small) FPGA's. > > > > Because according to most industry figures I see the 8-bit embedded > > industry is between 55 and 65% of the whole. A small but significant > > market is still the 4 -bit systems. The 16-bit market is also large and > > growing. There is a small 64 bit market 2%? > > > > This leaves less than 15% of the market for 24/32/32 bit systems > > > > The architecture with by far the largest market share is the 8051 with > > 20-30% of the WHOLE embedded market. No other single > > architecture comes close. > > > > This not a technical argument but a simple commercial one. 8051 may > > be a pig technically but it has the market. > > However the embedded industry is still simple control that a 59 cent > real 8051 the can be used in aunt sandys washing machine. It does not > make sense to use a $50 fpga in $49 modem.I am not sure what the main > generic FPGA market is but it not low priced computer products. > Ben. > -- > "We do not inherit our time on this planet from our parents... > We borrow it from our children." > "Octal Computers:Where a step backward is two steps forward!" > http://www.jetnet.ab.ca/users/bfranchuk/index.htmlArticle: 24852
Peter Alfke wrote: > > I tried exactly that, 18 years ago, while at AMD. I used a neat feedback > system, to force metastable event to occur all the time. > I failed miserably. > Well, that was then... I still like the idea. I'd like to see two numbers :- Metastability, and aperture time, which are often confused. Metastability, as I define as a propogation of a Tsu,Th violation. CLK ________________/======\________/=======\________/=== D >________________/===============\_____________________ Qout _______________?????????????HHHH???????????LLLLL If the ??? time extends to the NEXT clock edge, you have a metastability event. You can force the ??? by Phase Skew of CLK and D. Suggested method for this is Linear variable delay elements, simplest scheme I can think of is differential Vdd skew on two Buffer Chains. This will allow phase resolutions to the low pS, with a VHC14 device. To test the ??? duration is harder - anyone tried the Digital Phosphor Scopes on this problem ? The Multiple FLOPS suggested sounded a good idea. Aperture time is that SKEW between two Tsu.Th times, that causes a finite window where multiple Q's do not all follow the CLK.D CLK ________________/======\_______/=======\_______ Da ________________/===============\_______________ Db ________________/===============\_______________ Qb.Qa 000000000000033333333333333333XXXXXXXXXXXXXXX If Da,Db are derived from the SAME pin externally, there will be a finite Ck-D phase window, where the Qa.Qb outputs do not follow exactly. ( ie one follows, and one misses ) This divergence will last a whole clock cycle. On a FPGA, routing delays can also worsen Aperture times. In fully syncronous systems, both effects disappear. - jgArticle: 24853
Many long postings, but I hope we all agree ( and should enforce ) Jon's finishing sentence: Jon Kirwan wrote: > I just don't see a proper place for NDAs hidden in > visitor logs and explicitly required for the first-time interview. > > Peace, > Jon Peter Alfke ( who hasn't interviewed for a job in the past 12 years, but instead interviewed hundreds of applicants...)Article: 24854
"inertia" and "nervous", not exactly terms taught by the universities :<) Rather than try to oversimplify the topic of SEU or go way off topic, those interested can head to Rich Katz's web page which has a good collection of papers and data on SEU: http://rk.gsfc.nasa.gov/fpgas.htm#SEU-Hardening%20of%20Flip-Flops "Peter Alfke" <palfke@earthlink.net> wrote in message news:39A02C19.20190222@earthlink.net... > > > Elftmann wrote: > > > Peter, > > > > The A40MX02 and A40MX04 devices still require the master/slave latch > > implementation, we call these CC-Flops. While the A40MX family is not a > > qualified space environment device, it is interesting to note that the > > CC-Flops have traditionally had better "Single Event Upset" SEU > > characteristics versus the "hard-coded" flops in the RH1280 (same > > architecture as A42MX). > > I believe that. SEU-tolerance gets better when there is a lot of "inertia" in > the latch, while fast metastable recovery needs a "nervous", very fast > feedback loop. > > Peter Alfke > >Article: 24855
Right on, Eric! -Simon "Eric Braeden" <braeden@erinet.com> wrote in message news:399fff62$0$62230$53a6afc1@news.erinet.com... > > Elftmann, It's not just hardware design managers that are blowing > off design specs. I am always shocked and then sickened when > a US Govt project leaders for software development worth $100K's and > above refuse to write specs and refuse to pay for a spec to be > written. Then when the project fails to meet schedule or fails to > function as "imagined" they request more money to fix things. > In the mean time all the project management team gets > awards for view-graph presentations. > > These people should all be working at MacDonald's. That would > be safe for me. I never go there!! > > Eric > > > > >Article: 24856
hey i read once, on this news grp, that there is no need for timing simulation if the design is well synchronised. the functional does the job my design contains plenty of FSM, and also the BRAM. if i use the timing simulation, it works fine, whereas it fails for functional simulation. any help please Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24857
Jim, the problem is that your ??? time is not a fixed value, but can only be measured in a statistical way. For us to guarantee that ??? will hardly ever ( say, once per 1000 years) exceed, say 2 ns , we must measure ??? values that occur reasonably often ( once per second, or minute ). ??? is then much less than 1 ns, perhaps in the 100 ps range. That's where the problem lies... Peter Alfke Jim Granville wrote: > Peter Alfke wrote: > > > > I tried exactly that, 18 years ago, while at AMD. I used a neat feedback > > system, to force metastable event to occur all the time. > > I failed miserably. > > Well, that was then... I still like the idea. > > I'd like to see two numbers :- > > Metastability, and aperture time, which are often confused. > > Metastability, as I define as a propogation of a Tsu,Th violation. > > CLK ________________/======\________/=======\________/=== > D >________________/===============\_____________________ > Qout _______________?????????????HHHH???????????LLLLL > > If the ??? time extends to the NEXT clock edge, you have > a metastability event. > > You can force the ??? by Phase Skew of CLK and D. Suggested method > for this is Linear variable delay elements, simplest scheme I can think > of is differential Vdd skew on two Buffer Chains. This will allow phase > resolutions to the low pS, with a VHC14 device. > > To test the ??? duration is harder - anyone tried the Digital Phosphor > Scopes > on this problem ? > The Multiple FLOPS suggested sounded a good idea. > > Aperture time is that SKEW between two Tsu.Th times, that causes > a finite window where multiple Q's do not all follow the CLK.D > > CLK ________________/======\_______/=======\_______ > Da ________________/===============\_______________ > Db ________________/===============\_______________ > Qb.Qa 000000000000033333333333333333XXXXXXXXXXXXXXX > > If Da,Db are derived from the SAME pin externally, there will be a > finite > Ck-D phase window, where the Qa.Qb outputs do not follow exactly. > ( ie one follows, and one misses ) > This divergence will last a whole clock cycle. > On a FPGA, routing delays can also worsen Aperture times. > > In fully syncronous systems, both effects disappear. > > - jgArticle: 24858
Elftmann wrote: > "inertia" and "nervous", not exactly terms taught by the universities :<) > I believe in explanations that are intuitively understandable. Conceptual understanding comes first, math follows. Not everybody will agree. :-) PeterArticle: 24859
Can you give us a hint as to what failed? We can't help you if you don't give us the information. What kind of error messages did you get? What tools are you using? What FPGA vendor are you using? -Simon Ramirez <erika_uk@my-deja.com> wrote in message news:8npkro$fin$1@nnrp1.deja.com... > hey > > i read once, on this news grp, that there is no need for timing > simulation if the design is well synchronised. the functional does the > job > > my design contains plenty of FSM, and also the BRAM. if i use the > timing simulation, it works fine, whereas it fails for functional > simulation. > > any help please > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 24860
Elftmann wrote: > > Peter, > > The A40MX02 and A40MX04 devices still require the master/slave latch > implementation, we call these CC-Flops. While the A40MX family is not a > qualified space environment device, it is interesting to note that the > CC-Flops have traditionally had better "Single Event Upset" SEU > characteristics versus the "hard-coded" flops in the RH1280 (same > architecture as A42MX). Please note that the previous statement is > no-longer true with the SX, RTSX, and SXA devices. > No surprise there. The feedback time, which translates into your FF's GBW product determinines to a large degree your resistance to SEU as well as your susceptability to metastable events. Unfortunately, faster flip-flops, good for metastability and for high clock rate systems don't fare as well as slower flip flops for SEU. Antoher way of looking at that is that you need a certain amount of energy to get the flip-flop to toggle. The higher the GBW< the less energy needed, and nece the smaller the window where metastable events will happen, but that also means it doesn't take as much energy to upset the applecart either. > The A42MX, SX, RTSX, and SXA devices all have "hard-coded" flip-flops. > > Actel set out on the same mission to characterize metastability > characteristics in our newer devices, but ran into the same problem as the > Xilinx team did. I'll check back with Product Engineers next week and see > where it sits on the priority list these days. As a result of past > discussions in this group I continue to push on Product Engineering to make > metastability characterization standard operating procedure. > > "Peter Alfke" <palfke@earthlink.net> wrote in message > news:399FFF7A.CF624270@earthlink.net... > > Metastability is caused by the (limited) gain bandwidth product of the > > master latch in the flip-flop. As such it has nothing to do with the > > programming technology. Xilinx ( and Altera :-) ) flip-flops are > > hard-implemented, optimized structures that contain no programming > > elements in the critical path. > > I suppose the same is true of most ASICs. The original Actel devices > > composed their latches out of multiplexers, and we always pointed out > > their (theoretically) poor metastable performance. I assume that Actel > > now also has "hard-coded" flip-flops. (?) > > So the physics is the same. It's just that SRAM-based FPGAs are easier > > to "play with". > > > > Peter Alfke > > ======================================= > > Hal Murray wrote: > > > > Hal Murray wrote: > > > > > What sort of metastability data is available for antifuze parts? > > > > > > How do they measure it? Any reason that technique can't be > > > applied to SRAM based parts? > > > > > > How do ASIC vendors get metastability data? > > > -- > > > These are my opinions, not necessarily my employers. I hate spam. > > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 24861
That's fine for a design run through usign the big green pushbotton mentality. However when you start carefully architecting the design for the utmost performance I'll bet you are bumping into the metastability thing again. I think the real cause might just be the lack of ability to effectively measure it anymore. First, by using programmable logic, we are dealing with internal signals and clocks. The IO on current chips is slower than the internals, so direct measurement from outside is likely to be skewed significantly from what is actually happening inside. That in turn tells us that we need to put at least part of the meausurement circuit inside the chip, which means working with the same type of resources we are trying to measure. Now, at least in evaluating radar, and I suspect the same is true here, you really would like your test equipment to have an order of magnitude or more resolution than the unit under test so that you can resolve the results suffienctly. I suspect this is the case with metastability measurements in the FPGA. Peter, maybe you can expound on this (or you could tell me I'm off picking flowers in left field). Hal Murray wrote: > > In article <399F587E.7C0F4A56@andraka.com>, > Ray Andraka <ray@andraka.com> writes: > > I don't buy the metastability is becoming a non-issue thing at all. Not one > > little bit. As the filpflops get faster, so do the clock rates. Sure, if you > > are keeping the same clock rate the metastability problem diminishes. If > > however you are pushing the performance of these parts to the edges of the > > envelope, metastability is waiting behind every turn waiting to bite you in the > > behind. It all comes down to the clock speed, therate of change of the async > > data and the gain BW of the flip flops. push up the clock and/or the rate of > > change high enough and you can gt yourself into problems period. > > It sure isn't a non-issue, not with all the recent traffic on the subject. :) > > But Peter reports that he couldn't measure it, so something interesting has > changed. > > I suspect there is a parameter that we aren't considering yet - some > way to look at the problem that will give us some insight. > > What's the ratio of raw FF speed to typical cycle time, even if > we consider the cycle time when pushing the envelope? > > Do modern chips spend more time in routing relative to > the routing for the FF-FF pattern needed for a synchronizer? > > Has the basic design of the master latch improved? > > -- > These are my opinions, not necessarily my employers. I hate spam. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 24862
YIKES! That's scary. It probably means you have parts of the design that are depending on the delays through logic. If that is the case then you'd best head back to the drawing board because it is likely to bite you hard when you get it into production. On the other hand it could be a simple cockpit problem with your simulation. For example, is your simulation switching inputs right at the clock edge? In a timing simulation you'll probably get away with that because the delays are modeled. In a functional simulation, it might be getting the data into the input flip-flops on the same clock edge the clock is changing on. I've seen that happen, and it can cause some headscratching until you figure out what you did wrong in the setup. If you have a design that mixes instantiated clocked primitives with inferred registers you might also want to turn off the TimingChecksOn Generic on the unisim library elements (I'm arrogantly assuming xilinx for the moment). I've had occasional trouble in the past if I left them on in a functional simulation. erika_uk@my-deja.com wrote: > > hey > > i read once, on this news grp, that there is no need for timing > simulation if the design is well synchronised. the functional does the > job > > my design contains plenty of FSM, and also the BRAM. if i use the > timing simulation, it works fine, whereas it fails for functional > simulation. > > any help please > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 24863
Peter Alfke wrote: > > Jim, the problem is that your ??? time is not a fixed value, but can only be > measured in a statistical way. > For us to guarantee that ??? will hardly ever ( say, once per 1000 years) > exceed, say 2 ns , we must measure ??? values that occur reasonably often ( > once per second, or minute ). > ??? is then much less than 1 ns, perhaps in the 100 ps range. > That's where the problem lies... > > Peter Alfke True, that's why I said : To test the ??? duration is harder. One measurement, I thought of that is indirect, would be to clock off the Failing Q, then use the FPGA to analyse results, looking for multiple edges on Q following a Clock. This method assumes that multiple edges will occur as a by product of some metastable settlings, and would allow limits on the Delay Skew to be found, thus giving some values for the metastable window. The FPGA could be coded for a ratio test, so that you can state 'We had >100,000 metastable settlings, and in XX of these did the event NOT settle in a sample times of YY ns' - jgArticle: 24864
Ray Andraka wrote: > you really would like > your test equipment to have an order of magnitude or more resolution than the > unit under test so that you can resolve the results suffienctly. I suspect this > is the case with metastability measurements in the FPGA. Peter, maybe you can > expound on this (or you could tell me I'm off picking flowers in left field). > Well, it may not be as bad as you think. But the test circuit sure has to be weird and not something anybody would do normally. I am thinking of giving up on the frequency method ( because a half period of any manageable frequency is too long ) and go to an external phase shifter or delay element. Maybe it is possible, with a little help from the DLL and some realistically-sized R and variable C to achieve the delay changes that allow measurement. It's a bit murky still, and I will be gone until mid-September, but there is at least a ray ( no pun intended! )of hope... Peter AlfkeArticle: 24865
Jan Gray wrote: > The XSOC/xr16 articles/kit [1] builds a 16-bit RISC because > > 1) 16-bits is often a better fit for a small embedded system. Smaller > pointers, smaller code addresses => smaller memory footprint. Baring the fact that we all are entrenched in 8 bit wide memory chips - the same could be said of 18 bits. > 2) 16-bits adequately demonstrates all of the design issues of FPGA CPU+SoC > development. A 32-bit processor would not have been more educational. No problem with that, why cloud the issue with trivial details, providing your cpu does not require pre/post op bytes in the design link some nameless cpu's. > 3) the prototype board (the XESS XS40 [2]) provided only 8-bit-wide RAM. > (The XSOC design reads a byte on each clock edge). A 32-bit instruction or > data word machine would have required 2-4 clock cycles per > instruction/load/store and constrained the performance of the machine. Ah bus limitations. > > 4) XSOC fits in a very small FPGA (an XC4005XL). It is quite possible to > build a 32-bit RISC in about half of an XC4010XL, there was the j32 [3], and > the presently unreleased xr32, which will run fine (but for the 8-bit RAM > problem just mentioned) in an XC4010XL in the XESS XS40-010XL. With enough > care it is possible to build a 32-bit RISC in an XC4005XL! (Hint: > architecture width need not equal datapath implementation width.) True but full alu width will save on control states. > The current Xilinx Foundation Student Edition 1.5i supports chips up to > XC4010XL and XCS40 (comparable to a XC4020XL). So there's plenty of > headroom. For example, it is quite possible to build a 2-processor 32-bit > pipelined RISC using the current student tools. I understand there is a new > version of Student Ed. on the way that may provide support for small Virtex > devices. $#%@! Software limitations!. > A 24-bit machine (12-13 CLBs tall) would fit naturally in an XC4005XL or > Spartan 10 (14x14 CLBs). My alu design needs B,A+B,A-B,-A+B,A^B,A|B,A&B,shift right(A),shift left(B). About 6 CLB's no matter how you slice it per bit. Since the memory for the register set is single port, there is no advantage to me to pipeline my alu thus my cycle times are longer but they do it all. My alu is strongly influenced by the 2901 bit slice. With the Altera software for the 10k10 I can use the TTL macro library to create easy schematic cause I think better in those terms rather than a textual description in a high level language. Once I get the first revision working I then can fine tune the design. I am using the Altera 10k10 because that is what hardware/software I can get here in the middle of the bald prairie at the price I can afford. > Jan Gray > Gray Research LLC > > [1] http://www.fpgacpu.org/xsoc/cc.html > [2] http://www.xess.com/prod004.html > [3] http://www3.sympatico.ca/jsgray/homebrew.htm Arg!!! More great web sites to surf.:) Ben. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Octal Computers:Where a step backward is two steps forward!" http://www.jetnet.ab.ca/users/bfranchuk/index.htmlArticle: 24866
I was thinking while I was writing my post "what if you put signals you could adjust the phasing between into two adjacent pins...." well looks like that is what you are taling about here. I suppose if you could guarantee the paths were virtually identical, then you might have something that would work there. Still it is not clear how you'd generate the small phase delay differences required without it getting swamped by parasitics and stray signals. I think as soon as you are outside of the chip, you open a whole new can of worms when you are dealing with the very small metastable trigger window which sounds like is a very small number of ps wide. I'd think breathing near it would be enough to shift your test signal pahse difference away from the window. Well, I thinks you got your work cut out for you, and it does sound like it would make fodder for a good FPGA2001 paper. (You got till Sept 29 to get your paper in, think you can do it on your vacation?) Peter Alfke wrote: > > Ray Andraka wrote: > > > you really would like > > your test equipment to have an order of magnitude or more resolution than the > > unit under test so that you can resolve the results suffienctly. I suspect this > > is the case with metastability measurements in the FPGA. Peter, maybe you can > > expound on this (or you could tell me I'm off picking flowers in left field). > > > > Well, it may not be as bad as you think. But the test circuit sure has to be weird and > not something anybody would do normally. I am thinking of giving up on the frequency > method ( because a half period of any manageable frequency is too long ) and go to an > external phase shifter or delay element. Maybe it is possible, with a little help from > the DLL and some realistically-sized R and variable C to achieve the delay changes > that allow measurement. It's a bit murky still, and I will be gone until > mid-September, but there is at least a ray ( no pun intended! )of hope... > > Peter Alfke -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 24867
That assumes the metastability generates multiple edges. I've seen it do that - had a case a number of years ago that made a nice high frequency (well over 100 MHz) burst with very short turn on and off times on a TTL LS374 -- the radar guys upstairs would have killed for a circuit that could do that reliably. I still got the scope picture of that floating around here somewhere. I've also seen cases where the flip-flop just got incredibly slow, the change was pretty much monotonic, but the transition time would driven anything short of a schmitt trigger bonkers. Not sure what the behavior of the flip-flops in the FPGA are, and if it is an oscillation there's an even shot you wouldn't see it anywhere observable since it would have to pass thorugh some logic that normally won't handle the type of frequencies it is likely to generate. Jim Granville wrote: > > Peter Alfke wrote: > > > > Jim, the problem is that your ??? time is not a fixed value, but can only be > > measured in a statistical way. > > For us to guarantee that ??? will hardly ever ( say, once per 1000 years) > > exceed, say 2 ns , we must measure ??? values that occur reasonably often ( > > once per second, or minute ). > > ??? is then much less than 1 ns, perhaps in the 100 ps range. > > That's where the problem lies... > > > > Peter Alfke > > True, that's why I said : To test the ??? duration is harder. > > One measurement, I thought of that is indirect, would be to clock off > the Failing Q, then use the FPGA to analyse results, looking for > multiple > edges on Q following a Clock. > This method assumes that multiple edges will occur as a by product > of some metastable settlings, and would allow limits on the Delay > Skew to be found, thus giving some values for the metastable window. > > The FPGA could be coded for a ratio test, so that you can state > 'We had >100,000 metastable settlings, and in XX of these did the event > NOT settle in a sample times of YY ns' > > - jg -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 24868
> I would like to know the nature of the relationship that others have > experienced with the licensed FPGA distees. > > Sincerely > Daniel DeConinck > High Res Technologies, Inc. Recently, I was told by Insight (Singapore) that they will not support small quantity order. Neither are they willing to give samples. We tried other electronic suppliers and still could not get our hands on just a few simple fpgas (Xilinx XC4000E series), and we finally ordered them through the Internet. Despite several attempts to report this matter to Insight/Memec/Xilinx, it didn't help. Regards, Kang Liat Chuan Agilis Communication TechnologiesArticle: 24869
> NDAs have a purpose, of course. I hope nothing I've said suggests I > think otherwise. I just don't see a proper place for NDAs hidden in > visitor logs and explicitly required for the first-time interview. I'm pretty sure I've seen reasonable boiler-plate stuff on sign in logs, but it was anti-NDA rather than NDA. The visitor promised not to tell any of his secrets unless a real NDA was signed. The idea was to keep a visitor/vendor who was a small time inventor from claiming the big company stole his ideas when they both invented something at roughly the same time. -- These are my opinions, not necessarily my employers. I hate spam.Article: 24870
try to loook at my FIFO design at http://www.geocities.com/Siliconvalley/Pines/6639/ip/memory_cores.html it has a single clock but you can easiely modify it. it is customizable core and does not depend on the target FPGA, you can replace a dual port core for specific technology or remove the reset from the dual port memory to use the on FPGA memory blocks (altera and Xilinx). Please let me know if you use it or modify it. feel free to ask Regards Jamil Khatib In article <399A3044.1901EF20@quest-innovations.com>, Richard Meester <rme@quest-innovations.com> wrote: > Hello all, > > I need to implement small fifo's, with 2 diiferent clock domains. They > need to be 4 bit wide, and 16 deep. Can anyone suggest how to implement > these fifo's without waisting lots of ram using the blockram devices, > since they com in 4096bit, and i only have 12 of them, and i need more > than 12 fifo's. I have looked at the xilinx site, but they only have > notes subscribing the use of blockram, and the other notes using single > ram, have the same clock domains. > > Regards, > > Richard. > > Ps. the device i am targeting is a spartan2. > > -- > Quest Innovations > tel: +31 (0) 227 604046 > http://www.quest-innovations.com > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24871
In article <39988E05.562512B2@yahoo.com>, rickman <spamgoeshere4@yahoo.com> wrote: >I am interviewing for jobs and I am finding more than one company that >wants me to sign a non-disclosure (ND). For more discussion on this, see slashdot: http://slashdot.org/article.pl?sid=00/08/18/1833229 Gyles. -- gyles@nortelnetworks.com All opinions expressed are my own, not those of Nortel Networks.Article: 24872
This is an informational (I hope) posting, hopefully giving some additional
insight to the behavior of metastables.
The following is an edited version of some of my postings to
sci.electronics.design, during May of 2000.
Since this is quite long, here is a quick guide to the contents of this message:
1) The original poster asked people to look at his WWW page, where he had
a schematic for a claimed metastable free design. Several people pointed out
his error, including me. My response includes some historical notes, as well as
a list of observed metastable behavior. The original poster never responded.
2) Another poster also responded, and assumed that metastables only occur
as an oscillation (a pulse running around a loop). My response details the
internal mechanism for metastables, and also discusses some old TTL
technology.
3) The poster in (2) followed up my post, and I replied again. In this post,
we discussed oscillation versus delayed output. I made my case that I
believe at the system level, both are just as bad, and so tricks that
convert an oscillation metastable into a delayed output metastable are
of no use.
In particular, I comment that the signals that we are worried about going
metastable are signals that connect to the D pin of flip-flops. As such,
oscillation or delayed transition are both a disaster.
Signetics (a division of Philips (no relation)) used to claim they had a
metastable immune flip-flop. The 74F50109 description includes the following:
" The 74F50109 is designed so that the outputs can never display a
metastable state due to setup and hold time violations. If setup and hold
times are violated the propagation delays may be extended beyond the
specifications but the outputs will not glitch or display a metastable state.
Typical metastability parameters for the 74F50109 are: t < .2 ns,
T0 = 10us, and h=3.8 ns."
Absolutely incredible!
The names have been changed to protect the lack of an NDA.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Hi XXXX,
I've seen two posting that both describe the path that
shows that when fdiv_2 is low, the async signal goes all the
way through to the final flipflop.
The topic of designing circuits for dealing with metastability is a very
well researched area. The now widely held belief is that it is impossible
to design such a circuit. Indeed, ALL claimed metastable free circuits
have been proven not to be. Usually the only thing achieved by complex
circuits that try and deal with all sorts of special cases, is that they
obscure the metastable mode during analysis. The best way to deal with
the metastable problem (the synchronization of an asynchronous signal
feeding into and affecting a synchronous system) is to synchronize the
signal with a multi stage synchronizer, comprizing of no more than 2 or
more flipflops, connected as a shift register, and clocked by the clock
of the destination domain.
Even such circuits as a three stage synchronizer, with the first and third
flipflop clocked on the rising edge of the clock and the middle flipflop
clocked on the falling edge, are less effective than a simpler two stage
synchronizer, with both clocked on the rising edge.
While much of the really good literature on the topic has been written by
Fred Rosenberger and Thomas Chaney, as early as 1966 , many others
have also written on the topic.
B. I. Strom of Bell Labs wrote in 1979 "Proof of the equivalent
realizability of a time-bounded arbiter and a runt-free inertial delay"
Which basically shows that both are un-realizable. The guts of an arbiter
is the desired metastable-free flipflop.
In 1977, E. G. Wormald published a note in the IEEE transactions on
computing, march 1977, page 317, claiming to have designed a metastable
free flipflop. At the core of the design, it used a Schmitt trigger to
try and avoid metastability. In IEEE trans. on comp. Oct 1979, page 802,
Thomas Chaney commented on the Wormald design.
He explained that Schmitt triggers can them selves go metastable.
He built a circuit as per Wormald'd note, and demonstrated that it went
metastable. He closed with the following:
"In closing, there is a great deal of theoretical and experimental
evidence that a region of anomalous behavior exists for every device
that has two stable states. The maturity of this topic is now such that
papers making contrary claims without theoretical or experimental support
should not be accepted for publication".
Wormald's response to Chaney (same issue) includes the following:
"Hopefully, the discussion will discourage further attempts to eliminate
this unavoidable characteristic"
While your design does not use Schmitt triggers, it has been shown that
there is a path that allows the asynch signal to feed the final flip
flop, and therefore it can go metastable.
Unfortunately, simulation is NOT sufficient proof of metastable free
behavior. For a good example of someone who has fooled themself (and the
patent office) see 4,999,528 . Spice does not have infinite precision,
and the problems of rounding and convergence are well known.
Also let me state that there are a few lost souls who think that the only
way a metastable presents itself is as an oscillation on the output. This
is not the case. Metastable outputs can be
1) Oscillations from Voh to Vol, that eventually stop.
2) Oscillations that occur (and may not even cross) Voh and Vol
3) A stable signal between Voh and Vol, that eventually resolves.
4) A signal that transitions to the opposite state of the pre clock
state, and then some time later (without a clock edge) transitions
back to the original state.
5) A signal that transitions to the oposite state later than the
specified clock-to-output delay.
6) Probably some more that I haven't remembered.
I would suggest a change in the title of your web page :-)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
YYYY posted the following (indented by ">"), and I responded
>I have thought about this problem for a while. The point that becomes
>clear is that any digital solution simply moves the hazard to the next
>level.
I agree.
>I think there may well be a solution, but it lies with the analog
>behavior of the gates in use, and related to stability criteria used in
>feedback theory.
I totally disagree (sorry), see my article above.
>Think of a D flip-flop as two cascaded latches, open alternately on the
>clock high and low state.
>
>First of all, the latches must have mux hazard protection:
>
> Q = (D & LE) # (Q & !LE) # (D & Q);
>
>Logic compilers typically throw away the last term as "redundant", but
>in reality !(LE) != !LE , so it's not redundant. !LE is inverted AND
>DELAYED from LE, or the other way around.
>
>Next, the latch loop gain must meet stability criteria. If the latch
>loop delay is more than about half the slew time, there is a hazard of
>metastability. Metastability is when the a latch feedback loop thrashes
>on and off, chasing itself.
That's only one of it's failure modes. Another is when the loop assumes
an (almost stable) analog level between the two normal '1' and '0' states.
Here's how it fails. The latch, when closed effectively comprises two
inverters in a loop. If the input to the first is '0', its output is '1',
and there fore the output of the second inverter is '0', which was
driving the input of the first inverter. It is therfore latching the
value. The opposite state is also possible.
To load the latch, the loop is opened, and a '0' or a '1' is connected to
the input of the first inverter. The output of the second inverter will
with time become the same level, and when the loop is closed, the output
of the second inverter is reconnected to the input of the first.
The inverters are basically high gain inverting amplifiers. If you apply
an analog signal to the input, there is a region of the input range for
which the output is a value other than the desired '0' or '1' levels.
For example, lets have an inverter running at 5V, with rail to rail
outputs, and the middle of its switching theshold is 2.0V, and it has a
gain of 20. (for simplicity I will assume a linear monotonic transfer
characteristic for the analog region)
INPUT OUTPUT
0 5
1 5
1.8 5
1.9 4.5
1.95 3.5
2.0 2.5
2.01 2.3
2.02 2.1
2.025 2.0
2.03 1.9
2.04 1.7
2.05 1.5
2.1 0.5
2.2 0
3 0
4 0
5 0
Somewhere between 2.02 and 2.025 volts input, the output will be the same
value. I leave it as an exercise for the reader to determine the value.
If I have two such inverters in series, and the output of the second is
connected to the input of the first, then the loop will be stable (for
some time) at this intermediate value.
Even if the two inverters are not identical, there is still some analog
value that when placed on the input of the first inverter, will cause an
output which when fed to the second inverter will cause its output to
assume a value that matches the input to the first inverter.
This is true of ALL bistable circuits.
The loop does not need to be made of inverters.
This is independent of the loop gain (other than it must be greater than 1).
This is independent of loop delay.
How does this analog level get into our "digital" systems? Take a step
back and think about the way the latch is made to "track" the input
signal, while the latch is open. The loop is opened, and the input signal
charges and discharges the input node of the first inverter. The charging
and discharging depends on the size of the capacitance of the node, and
the impedance of the input signal source and the interconnect to the first
inverter. The input can not instantaneously change from the '0' to '1'
levels. It must transition through the analog region where the output is
transitioning through its analog region. See the table above. The charging
stops and the loop is closed when the clock signal transitions. If this
happens at just the wrong time, the value on the input of our first
inverter meets the criterion for the loop to be in the metastable state,
of being neither a '0' or a '1'.
The quality of a device to minimize how often it goes metastable, and how
long it may stay that way depends on the loop gain, and the signal
transition rates. Improving both these characteristics will minimize the
region for which the inputs and outputs are in the analog region.
>If the loop delay is 10nS, a 5nS pulse can race around the loop until
>slew asymmetry wipes out one side of the wave. This is why TTL, which is
>highly asymmetric, is "less prone" to metastability. In fact, such
>storms in TTL logic simply move quickly to a "0" because the pull down
>is always a lot stronger than the pull up.
Unfortunately, this is not true either. Since there are two gates in the
loop, even if you did have a pulse racing around the loop, what one gate
would make shorter, the other gate would make longer. One of the worst
devices for metastability is the 74S74. Almost all other 74xxx74 devices
behave better. Your assertion that TTL quickly resolve to '0' is also
incorrect. A device in a metastable condition has equal likelihood of
resolving to a '0' or a '1'.
>
>In analog terms, a "single dominant pole" in the latch feedback should
>mean that the latch will produce, at worst, a single pulse, if any.
See below for a list of the ways that a metastable can be seen.
>If the second latch of the DFF is not open for some delay after the
>closure of the first, then this pulse is not seen at the DFF output.
Unfortunately, the duration of the metastable state in the first latch is
unbounded, and so there is no guarantee that it will be resolved by the
time the second latch is opened. Delaying the opening of the second latch
cannot guarantee hiding the metastability, and would also adversely
affect the clock to output time of the circuit.
>The
>second latch must also close before the first opens (on the falling
>clock), ie:
>
>LE1= !clock & !LE2;
>LE2= clock & !LE1;
>
>A latch uses positive feedback, not negative, but you can see that if
>the loop gain is high at the frequency = 1/loop_delay, wrt DC gain, the
>latch can oscillate for a time before stabilizing.
>Cheers,
>YYYY
Sorry for the bad news YYYY,
Cheers anyway :-)
Philip
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
YYYY responded (indented by ">") and I replied:
>I was thinking that it might be possible for a circuit to meta-stabilize
>faster than the general response, and so hiding the problem, but as you
>point out the meta-unstable time can be unbounded.
>
>A couple ideas:
>
>1. If the failing loop is followed by a third gate who's threshold is
>off from the point of equilibrium, then this static condition becomes a
>1 or 0. For this reason, I think, in many cases, a static failure mode
>does not translate to the kinds of system failure that oscillating does.
>This leaves us with the dynamic case I was interested in. A strategy
>aimed at damping oscillation would be useful, even if it does nothing
>for the static case.
>
>Cheers,
>Steve
Although oscillation and delayed transition are two of the several ways a
metastable can manifest itself (see my previous article for some other
failure modes), what you are suggesting above will basically turn the
oscillation mode into the delayed output mode.
(
In fact, I suspect this is what actually happens in the delayed output
case, or something similar. Here are two scenarios:
a) Internal latch oscillates with a small swing. The output of the latch
is buffered, and the buffer has a threshold that is outside of the peak
to peak swing of the oscillation. When the oscillation stops, and the
latch takes on a stable '1' or '0' state, the following buffer then
'reports' the result, but with late clk-to-q problem.
b) Internal latch oscillates with large swing. The output of the latch is
buffered, and the buffer is slow (or is slowed by its load), and the high
frequency oscillations dont get seen on the buffer's output. When the
oscillation stops, and the latch takes on a stable '1' or '0' state, the
following buffer then 'reports' the result, but with late clk-to-q problem.
)
While you characterize the oscillating and delayed outputs as two
different failure modes (you call them dynamic and static), to me they
are the same thing: The flipflop does not behave as per the data sheet,
and valid Q is late.
Here's some info about my digital design style which may help to
understand my position:
I do digital design that is fully synchronous. ALL flipflops are clocked
by one master clock signal. Clocks are never gated. Async reset or set are
only used for system initialization. Clock enables (mux in D path,
recirculating Q ) for flipflops that need to have their clock disabled
for some cycles. Async inputs are handled in carefully designed circuits
that minimize the occurence of metastables getting into the main design.
From a timing point of view, all async paths within the design start at a
flipflop, go through some cloud of logic, and end at a flipflop. Since
all flops are clocked by the same clock signal, all logic paths have the
same worstcase delay requirements, which is clock period minus flipflop
output time minus flipflop setup time. This can be exhaustively analyzed
by a static timing analyzer. The design only needs functional (unit
delay) simulation, and timing simulation is un-needed.
If the system must have more than 1 master clock, i.e. data arrives from
a source with a 50MHz clock, and is processed and leaves with a 27.5MHz
clock, then I break the design into two sub-designs, that are each
totally synchronous, and great care is applied at the point where the
data moves between the two domains. FIFOs, dual port memories,
semaphores/flags, and carefully designed synchronizers all help to cross
the chasm.
So in my systems, the signals that can go metastable, are signals that in
the limit always have D pins as their destinations. Never clock pins. So
whether it oscillate and then goes stable, or just goes to a stable state
at a later time, it is still violating the clock-to-Q spec of the data
sheet, and this value was used to guarantee system timing during static
timing analysis.
I am unable to imagine a scenario where a signal that could go metastable
is used as a clock to a flipflop, and where the difference between
oscillating or delayed signal would make a difference.
Philip Freidin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Philip Freidin
Mindspring that acquired Earthlink that acquired Netcom has
decided to kill off all Shell accounts, including mine.
My new primary email address is philip@fliptronics.com
I'm sure the inconvenience to you will be less than it is for me.
Article: 24873OpenTech cdrom new release is available now. The new release has some new open hardware designs and many new open source eda tools. The OpenTech cdrom will provide solution to many hardware designers who want reference designs and can not afford the expensive eda tools For more information visit http://www.opencores.org/OIPC/projects/OpenTech Best regards Jamil Khatib Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24874
OpenTech cdrom new release is available now. The new release has some new open hardware designs and many new open source eda tools. The OpenTech cdrom will provide solution to many hardware designers who want reference designs and can not afford the expensive eda tools For more information visit http://www.opencores.org/OIPC/projects/OpenTech Best regards Jamil Khatib Sent via Deja.com http://www.deja.com/ Before you buy.
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