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
Symon wrote: > The whole point is that you can never be sure how long the first FF will > stay metastable. The maximum time it can take to resolve is infinite. Yes, but the probability that it will take an infinite time to resolve is zero. Or at least, the probability of a black hole from outer space smashing into the circuit is higher. One has to pick some realistic reliability level (9 9's over 10 years?) in order to design finite cost hardware. Then one solution to any synchronizer is merely to find a flip-flop circuit that resolves in N clock periods (hopefully only 1) with much higher probability than needed for you target reliability, and use that time as your designed-in flop-to-flop synchronization delay. As for the Schmitt trigger suggestion, yes it might (or might not) resolve faster; but it's still an analog circuit with finite gain. Therefore there's still a threshold voltage somewhere. IMHO. YMMV. -- rhn A.T nicholson d.O.t C-o-MArticle: 90276
Michael Chan wrote: > In the problem I was trying to solve, I couldn't treat > the two clock domains as synchronised, since one clock sometimes led, and > sometimes lagged the other clock. This resulted in data changing just as it > was being sampled. I was told to add some flipflops to fix up the problems, > but it didn't seem like a very good solution. As it was, I sampled data on > the falling edge of the clock, but I wonder what I could have done if there > wasn't sufficient timing margin for that to work (taking into account the > jitter between the two domains). Actually, thinking about it now I think it > would have been sufficient to simply sample the output of the negative edge > triggered flip-flop with a positive edge triggered flip-flop. I think this is know as isochronous design (not quite asynchronous, but the same frequency with an unknown phase between clock domains). The common solution to minimize cycle jitter (random alternation in synchronizing both before and after the receive clock) is to pick a receive clock phase farthest from the point most likely to cause metastable behavior. Then, at least, you lower the probability of failing to meet setup and hold, and thus have a more predictable circuit. DLL's a commonly used for this in DDR and SerDes type applications. IMHO. YMMV. -- rhn A.T nicholson d.O.t C-o-MArticle: 90277
<rhnlogic@yahoo.com> wrote in message news:1128709591.126283.195900@g14g2000cwa.googlegroups.com... > Symon wrote: >> The whole point is that you can never be sure how long the first FF will >> stay metastable. The maximum time it can take to resolve is infinite. > > Yes, but the probability that it will take an infinite time to resolve > is zero. Or at least, the probability of a black hole from outer > space smashing into the circuit is higher. > Well, of course. But you're quoting me a little out of context. I was replying to Raymond's post in which he said:- "So if you are sure that the first FF can't stay longer in metastable state than Tperiod-Tsu, you are fine." My point is that you can never be 'sure'. You have to design the system using probabilities, as you say. Cheers, Syms.Article: 90278
Hiya all, I just put out my new Dev. board that's open source, but I do sell assembled units. Thought I would just the link and some specs here for fun. Any comments are appreciated... the schematics/user-guide/pcb/bom are all available for download. http://via.dynalias.org A feature list (taken from the web page): FPGA * Altera Cyclone EP1C12Q240Cx * -8 Speed grade preloaded, -7 and -6 upon request * 12,060 LE's - enough for 4 NIOS processors! * 240 Kbits of on-chip RAM * 2 PLL's - one pre-loaded with 50MHz oscillator, second upon request * 1 PLL output header * 240 QFP package Programming * Supports both Byteblaster II and @ltium LiveDesign 3rd party programmer * Soft JTAG chain support for Altium programmer * EPCS4 Active-serial configuration device RAM * 256Kx32 / 512K x 16 SRAM with 12 nS access time (10,12,15 and 20 nS available) * Easily integrates with both NIOS and @ltium soft-processor Flash * Altera EPCS4 configuration device for Active Serial (AS) configuration on startupt * 4 Mbits of space allows for a complete image and ~64 Kbyte of user-code * 32-Mbit SPI Flash for extended storage of user-code; bootable with custom bootloader Ethernet * National Semiconductor DP83846A 10/100-Base TX PHY with industry standard MII * Full-duplex communication and auto-negotiation * MDIO interface * 5 LED output signals that are connected to FPGA * RJ45 jack and integrated magnetics with 2 LEDs connected to FPGA * Works with Opencores Ethernet MAC and Altium's EMAC controllers Peripherals * Dallas I2C Real-time-clock with Battery * Microchip on-board I2C temperature sensor * Microchip 512 Kbit I2C EEPROM * Power-on reset controller * RS232 port * 8x LED outputs and 4 pushbuttons + Reset button * 16x GPIO signals * 8x 5-Volt inputs and 8x 5-Volt bi-directional signals (can be toggled by jumper) Software * Comes with sample code that communicates with nearly all peripherals * Altium P*otel and Altera quartus projects with Constraint and Pin files included * Support is free! Daughtercards * Common daughtercards include ADC, DAC, serial port expander * Custom design available to suit customer requirements Feel free to contact me for any other questions. Jai.Article: 90279
jjohnson@cs.ucf.edu wrote:
>Summary: Should high-speed shift registers (purely DFFs) flow
>left->right, top->bottom, or does it matter?
>
>Doing a Virtex4 (LX100). I wound up with high-speed inputs (clocks and
>serial data) on the IOBs that run vertically down the center of the
>die. OK for clocks, since the DCMs and BUFGs are also in that center
>column.
>
>Regarding data: I deserialize the inputs, and pass parallel data to
>some large datapath blocks that start on the left edge of the die. I
>constrain all my deserializer logic to use sites near the center column
>to minimize clock skew. (Sorry, I can't use the on-chip deserializers;
>they max out at 10 bits, and I need 12.)
>
>Kind of annoying to take my inputs from the center over to the left,
>and then start flowing left-to-right, but that's just how the layout
>wound up...
>
>Anyway, older Xilinx docs say you should flow left->right, and
>numerical operations should have their MSB flowing downward (?) to make
>best use of carry chains. Is that still the case?
>
>Back to my deserializers: I'm using 20 of them, so that's 40 6-bit
>shift registers (6 bits on rising edge, 6 bits on falling edge), which
>I plan to do manual placement on. I don't want to use the SRL16's (yet;
>long story...), but just DFFs.
>
>I thought left->right flow was perfect for shift registers, but ISE
>seems to place all the DFFs for a downward flow. Actually, since my
>inputs are all down the center column (20 serial data streams) and need
>to go left, horizontal alignment flowing right-to-left makes for best
>placement. Not sure about routing though...
>
>Any suggestions? The data is coming in close to 1Gbps, so the shift
>regs run close to 500 MHz...
>
>Thanks again for all the help; I'll appreciate your input as I work
>another weekend...
>
>
>
You can still use the deserializers. Use them as 6 bits and unload them
at 2x the rate. Since your data is ~1Gbps, that gets you to an unload
frequency at about 170 MHz, which is quite easy to deal with. The
SRL16's wouldn't help you much for a deserializer.
As far as the layout, unless you are using the carry chains, there is no
reason to arrange the registers for horizontal flow. In fact, with the
V4SX family, you'll find that you'll have more of a vertical flow to use
the DSP48s anyway. Direct register to register connections, even
without an optimal place and route are pretty fast in V4, and I think
you'll find that 500 MHz is fairly easy to achieve if there is no logic
between the flip-flops, even in a -10 part. For high clock rates, you'
want to avoid the carry chains. The router doesn't do a very good job
at getting on and off the chains, even when the driving flip-flop is in
an adjacent slice, so even if you get lucky and make timing with one PAR
run, there is a good chance you won't make timing after making design
changes. As long as you stay off the carry chains and keep your logic
to one level between flip-flops, the fabric will run faster than the
maximum clock spec of the BRAM and DSP48 slices. That max clock is 400
MHz for a -10 part, 500 MHz in a -12. If you avoid logic in front of
the FF's you can get well past 500 MHz in a -10 part. Be careful that
the synthesis doesn't use the sync reset input though, that input is
dreadfully slow: IIRC more than 2ns tsu. Synplicity has a nasty habit
of using the sync reset for logic (which would be a good thing if it
could be overridden with a switch), which kills the performance of a
high clock rate design.
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 90280
:
Peter, as I have said before, fast and slow metastability recovery is
relative. You very much can still be bitten by metastability in modern
FPGAs. Yes the resolution time is decreasing, but so are the clock
cycle times.
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 90281All, The problem being described is a very practical one. Many lifetimes ago, in a different job, I designed telecom synchronization systems. These systems looked at references from two separate redundant feeds (east-west, or north-south, as they are usually called in the literature), and (tried) to keep a local oscillator locked in phase to one (or the other, but usually not both) references. The local oscillator might be pretty good (Stratum 4, just a plain old crystal), or might be really quite good (a rubidium steered quartz oscillator). It was inevitable that somewhere, sometime, the phase detectors, frequency counters, etc. would get to just the right point, and metastable outputs would happen (which led to bad counts, or bad phase measurements). When the phase was "just right" the naturally occurring jitter would rock you back and forth across the metastable threshold .... The result would be that the clock system would suddenly think it was terribly out of sync, and slew like crazy to go find phase lock (with what it thought was the right phase now). This was, of course, unacceptable, as all systems sync'd to this one would dump their buffers (overflow or underflow). As well, alarms were turned in, references switched, and so on. Not pretty. A two stage solution was initially used, and found to be not good enough. We then used a series of what we thought were clever arrangements of flip flops and clock edges, all no help (as noted above in the other thread, it is easy to make it worse, not better). Finally, a simple software patch solved the whole problem: if you suddenly think you are WAY OFF, stop, throw the result out, and check again. If you still think you are WAY OFF, then just call the new spot your reference (if it really is WAY OFF, then all the damage is done, and why should you continue to make all sync'd equipment suffer), and turn in a "notification" of poor sync quality (so if someone at the network control center feels we are doing the wrong thing, they can override and take over control). As long as this little patch executed about once every 6 months, no one cared. So, the solution to this little problem: build the best synchronizer you can, and also have another means to deal with the inevitable "failure" to get a valid result. Another solution that we never tried was to build three separate detection packages for phase and frequency, each offset by a portion of the period (like 0, 1/3, and 2/3) and then vote. If two out of three of the detectors said the phase was 0x1234h (yes, it was a 16 bit phase detector, 8 bits for the raw number of clocks, and 8 bits for the fraction of a clock), then we might go ahead and use that number. If there was no majority, the value would be ignored, and the reading taken again. AustinArticle: 90282
Sandro wrote: > d...@xess.com wrote: > > We have a more recent document that shows how to use makefiles with > > WebPACK or ISE. It does not need fe_shell. You can see it here: > > > > http://www.xess.com/appnotes/makefile.html > > Maybe that works with ISE 6.x with "projectfile.prj" as ascii file... > > any suggest to make it to run with ISE 7.x with "projectfile.ise" as > binary unknown (for me) format file ? > > Sandro Sandro: The makefiles only use the .prj and .xst files to get information about the project and the synthesis options. These are both ASCII in 6.x. So the makefiles will work if these are still ASCII in 7.x. The makefiles don't use anything in the .npl file so they shouldn't be affected by the switch to .ise binary files in 7.x.Article: 90283
Did you turn the caches on?
- Peter
Eli Hughes wrote:
> Hello
>
> Has anyone here had experience with interrupt latency in a PowerPC block
> in a VirtexII Pro? I did a simple experiment where I setup a PowerPC
> core where the critical interrupt input is always raised (just tied it
> to net_vcc in the .mhs file). I then registered a very simple interrupt
> handler:
>
> void MyIrqA(void * arg)
> {
>
> i = MYIP; // read a generic register on the PLB Bus
>
> }
>
>
> with built Xilinx Functions:
>
> XExc_RegisterHandler(XEXC_ID_CRITICAL_INT, (XExceptionHandler)MyIrqA,
> (void *)0);
>
> and then enabled the interrupt with:
>
> XExc_mEnableExceptions(XEXC_CRITICAL);
>
>
>
> I then monitor a bus read signal for my generic register to see how
> often it occurrs. The PLB bus and PowerPC is being clocked at 100MHz on
> a Digilent VirtexII Pro development board.
>
> To my surprise, there is almost 10uS between reads! I know this isn't a
> PLB bus issue, I can do multiple reads in the interrupt route and the
> read pulses are within a few bus cycles of each other.
>
>
>
> Is there anythign I can do to help this? What in the world is Xilinx
> doing in their BSP to save context that takes 10uS with a 100MHz clock
> period?
>
> -Eli Hughes
>
>
Article: 90284Austin described the difficult case where the two frequencies are supposed to be identical, but are really generated by different oscillators and thus have an unknown and changing phase relationship. I think the original question dealt with the simpler case where both frequencies come from a common source, but have developed a certain delay difference that -worst case- could be drifting around zero. Which of course invites metastabilty. The simple (simplistic?) solution is to offset the edges deliberately, e.g. by using oppsite polarities. That avoids metastability, as long as the delay uncertainty never approaches half a period. PeterArticle: 90285
I agree 100%, but remember, the original posting mentioned 1.6 and 24 MHz. It is hard to imagine that metastabilty would cause any trouble in such a system, especially when the routing delay from the single synchronizing flip-flop to it single second synchronizer is kept under control, guaranteeing 5 or more ns of slack.(Which is very easy, just change the time spec). If the original posting had mentioned hundreds of MHz, this thread would have run very differently. Peter AlfkeArticle: 90286
"Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag news:43468fc4$0$49012$14726298@news.sunsite.dk... > "Raymund Hofmann" <filter002@desinformation.de> wrote in message > news:di5qj7$pvg$1@online.de... >> >> CMOS is reported not to stay long in such a metastable state. >> So if you are sure that the first FF can't stay longer in metastable >> state than Tperiod-Tsu, you are fine. >> > The whole point is that you can never be sure how long the first FF > will stay metastable. The maximum time it can take to resolve is > infinite. Yes, our whole life has to deal with probabilities. Lukily they are different and selectable. And the lifetime of our Earth may not be long enough to get a good, fast CMOS FF (.18um technology) in metastability for longer than 20ns. >> >> In a CMOS FF you could avoid the hypothetical persisting metastable >> state by constructing the feedback (of the output stage) with a >> schmitt-trigger. >> > This doesn't help fix the problem. Do you hint at the schmitt trigger going metastable >20nS ? OK, i think on a 7414 this may be demonstrated, but in modern CMOS ? So the Question would be: What is the probability distribution of the metastable duration comparing the normal FF with a schmitt trigger output state feedback FF? I guess the schmitt output stage will be significantly better and even practically metastable free after 20nS in the lifetime of our Planet. >> >> Such a FF should never - by construction - stay in the metastable >> state, only the CK->Q time may be affected. >> > This is why the problem isn't fixed by the Schmitt idea. The CK->Q > time can be anything up to infinite. So, Q can be changing just as the > next stage of the circuit tries to sample it. A FF in a metastable > state doesn't necessarily have to have a funny output voltage. It's in > a state where it hasn't made up its mind what its output should be. This brings another Idea to my mind: What about injecting noise in the FF feedback loops which is small enough not to alter their (static)performance, but large enough to drive the feedback loops (and maybe schmitt triggers) into clipping and thus their stable state ? Practically this is what you get in a FPGA/ASIC due to crosstalk in and out of the chip, although it's not uncorrelated white noise. And the inherent noise of CMOS technology also helps, with the high gain of the feedback loops. Raymund HofmannArticle: 90287
On Sat, 8 Oct 2005 14:02:36 +0200, "Raymund Hofmann" <filter002@desinformation.de> wrote: <most stuff snipped> >What is the probability distribution of the metastable duration >comparing the normal FF with a schmitt trigger output state feedback FF? >I guess the schmitt output stage will be significantly better and even >practically metastable free after 20nS in the lifetime of our Planet. Back in 1977, some unfortunate soul wrote to IEEE Transactions on Computers with a proposal to eliminate metastability through the use of Schmitt triggers. A while later, Thomas Chaney, one of the pioneers in the investigation of metastable operation, wrote a reply. Chaney went to the trouble of building up a Schmitt-trigger-based circuit that he deliberately made as clean as possible--good bypassing and the like--and measured performance with and without the Schmitt trigger in place. He concluded that not only did the Schmitt trigger circuit not eliminate metastability, but it made the metastable performance of the circuit significantly *worse*. Even the original proposer of the idea admitted that, yes, Chaney was right. >This brings another Idea to my mind: > >What about injecting noise in the FF feedback loops which is small >enough not to alter their (static)performance, but large enough to drive >the feedback loops (and maybe schmitt triggers) into clipping and thus >their stable state ? This is an idea that has been proposed before. Unfortunately, it's just as likely that noise will drive you into a metastable state as out of it. If you sense some frustration on the part of the old hands in this group, it's because metastable-fix mania sweeps through here on a regular basis, and every time the same "fixes" and "improvements" are trotted out, virtually all of which were disproved ages ago. Please, please, please, everybody, go to: http://fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm and read the whole thing. Then look at the bibliography at the end and read some more. The subject has been well-researched. The point is, you don't *have* to guess, at least not if the vendor gives you a little information on their metastable performance. And if there isn't enough information from the vendor, there are simple ways to trade latency for lower metastable failure rate. Let's move on, folks. Let the healing begin. Bob Perlman Cambrian Design WorksArticle: 90288
Hello all I am sure this is a trivial question for you all,but i am getting tired of breaking pins off my gal lol. How do i leave just one of the output pins permanently tristated without affecting the other outputs? I use opaljr for writing my equation. Thanks Deon HansenArticle: 90289
Hi Remis, I doubt that running the Xilinx software from command line is going to speed up the compilation of your design (Perhaps, buying a faster computer is going to solve that problem.), but it can still be done for FPGAs in ISE WebPACK contrary to what Xilinx is saying. Assuming that you are using ISE WebPACK 7.1i, download the following files. http://www.xilinx.com/support/sw_manuals/xilinx7/download/xst.zip http://www.xilinx.com/support/sw_manuals/xilinx7/download/dev.zip The above two documents explain the arguments for the command line version of the Xilinx software. For an example of a sample batch file script, check out page 13 (or 14) of the following PDF file. http://legacy.memec.com/solutions/reference/xilinx/downloads/S-II_PCI_Tutorial.pdf The above document itself is several years old, but Xilinx software doesn't change that much from version of version, so the sample batch file script should even work with 7.1i. From there, make changes to meet to needs. Next, make sure that your XILINX environmental variable is pointing to your ISE WebPACK install path. (i.e., XILINX=d:\Xilinx) I hope it works. Kevin Brace Remis Norvilis wrote: > I wonder if there is a posibility to do Xilinx fpga synthesis and > implementation from command line on WindowsXP platform to speed up the > process. > Xilinx web site mentioned something, that it's only availabe for CPLDs. > XESS have an app note on how to use Make file to script and automate build > process. It needs fe_shell utility, but I don't think it comes with WebPack > edition. -- Brace Design Solutions Xilinx (TM) LogiCORE (TM) PCI compatible BDS XPCI PCI IP core available for as little as $100 for non-commercial, non-profit, personal use. http://www.bracedesignsolutions.com Xilinx and LogiCORE are registered trademarks of Xilinx, Inc.Article: 90290
Bob Perlman <bobsrefusebin@hotmail.com> wrote: >>What about injecting noise in the FF feedback loops which is small >>enough not to alter their (static)performance, but large enough to drive >>the feedback loops (and maybe schmitt triggers) into clipping and thus >>their stable state ? >This is an idea that has been proposed before. Unfortunately, it's >just as likely that noise will drive you into a metastable state as >out of it. It is an idea I proposed before, without any claim that it would reduce the occurence metastable states only that it would reduce their duration.Article: 90291
I think I know that answer all ready, but I just wanted to but out the question... Is there any 3rd party JTAG cable/controller that can be used to configure Xilinx's Virtex-4? Thanks!Article: 90292
why.. the xilinx one is cheap enough I have seen alternatives... but they weren't much cheaper Simon "Waage" <chris@ednainc.com> wrote in message news:1128804979.089139.49140@g47g2000cwa.googlegroups.com... > I think I know that answer all ready, but I just wanted to but out the > question... > > Is there any 3rd party JTAG cable/controller that can be used to > configure Xilinx's > Virtex-4? > > Thanks! >Article: 90293
hello! When I use ths XST to synthesis(Simulate Post-translate VHDL Modele) a project,it tells me errors: ERROR:HDLParsers:3317...Library SIMPRIM cannot be found. ERROR:HDLParsers:3013...Library SIMPRIM is not declared. library SIMPRIM; use SIMPRIM.VCOMPONENTS.ALL; use SIMPRIM.VPACKAGE.ALL; why?How to do it? Thanks!Article: 90294
There are a number of Parallel Cable III look-alikes available including one or two from ourselves. The only thing to watch out for is the minimum voltage than they will run at. If a 2.5V programming voltage only is available some of the 3rd party cables will not operate. Our PROG1 cable will work down to about 2.2V and with mods down to about 1.7V. Our PROG2 cable which is being released with our Raggedstone1 release in a few weeks time with be slightly more restricted and but will operate happily at 2.5V and 3.3V. John Adair Enterpoint Ltd. - Home of Raggedstone1. The Very Cheap Spartan3 Development Board. http://www.enterpoint.co.uk "Waage" <chris@ednainc.com> wrote in message news:1128804979.089139.49140@g47g2000cwa.googlegroups.com... >I think I know that answer all ready, but I just wanted to but out the > question... > > Is there any 3rd party JTAG cable/controller that can be used to > configure Xilinx's > Virtex-4? > > Thanks! >Article: 90295
"Bob Perlman" <bobsrefusebin@hotmail.com> schrieb im Newsbeitrag news:8mufk156urltejl11o21p7oup8arqq8bi2@4ax.com... > On Sat, 8 Oct 2005 14:02:36 +0200, "Raymund Hofmann" > <filter002@desinformation.de> wrote: > > <most stuff snipped> > >>What is the probability distribution of the metastable duration >>comparing the normal FF with a schmitt trigger output state feedback >>FF? >>I guess the schmitt output stage will be significantly better and even >>practically metastable free after 20nS in the lifetime of our Planet. > > <some innuendos about unfortunate souls snipped> > I was talking about a FF containing a schmitt trigger _in_ it's feedback loops. And I was talking about a 7414 schmitt trigger eventually not suitable for this (and how to get it inside a FF feedback loop), although maybe not detailed enough. > >>This brings another Idea to my mind: >> >>What about injecting noise in the FF feedback loops which is small >>enough not to alter their (static)performance, but large enough to >>drive >>the feedback loops (and maybe schmitt triggers) into clipping and thus >>their stable state ? > > This is an idea that has been proposed before. Unfortunately, it's > just as likely that noise will drive you into a metastable state as > out of it. Metastability is not the question, it's "duration probability" is. Every FF has some CK->Q uncertainty(jitter) you could also call "Metastable", even with proper setup/hold. So I can't second this. > > If you sense some frustration on the part of the old hands in this > group, it's because metastable-fix mania sweeps through here on a > regular basis, and every time the same "fixes" and "improvements" are > trotted out, virtually all of which were disproved ages ago. I guess you sense some illusion of superiority. > > Please, please, please, everybody, go to: > > http://fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm > > and read the whole thing. Then look at the bibliography at the end > and read some more. I get partial dyslexia reading the whole thing. This is where I also want to expose my Ignorance and explain everything (in my way). > > The subject has been well-researched. The point is, you don't *have* The ether has also been "well researched" until Albert Einstein. You are free to defame me of thinking I am a Genius. Can you also think on your own or do you only quote "well researched" subjects ? Is there a reason individual life is finite by conception ? > to guess, at least not if the vendor gives you a little information on > their metastable performance. And if there isn't enough information > from the vendor, there are simple ways to trade latency for lower > metastable failure rate. > > Let's move on, folks. Let the healing begin. > Who's healing do you mean ? Raymund HofmannArticle: 90296
Thank you, i will do it like you wrote :-) "Symon" <symon_brewer@hotmail.com> skrev i meddelandet news:434649c7$0$49021$14726298@news.sunsite.dk... > Hi Bill, > Sorry, but your circuit is not good. In fact it wastes some FFs and logic to > make the metastability performance worse by many orders of magnitude. The > time from b to q in your circuit is half a 24MHz clock period. The OR gate > eats up some of this time. This is much better:- > > process(clk_24M) > begin > if rising_edge(clk_24M) then > a <= d; > q <= a; > end if; > end process; > The signal 'a' has a whole 24 MHz period to settle. In your UCF file, do > this:- > > NET "a" MAXDELAY = 1ns; > > This is just to make sure the router doesn't screw up. > > Have you taken Philip's advice and read > http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm ? > > Also, re-read Bob's post. He's explained very well why your circuit isn't > good, and your latest modification doesn't address the concerns he > expresses. > > HTH, Syms. > >Article: 90297
Raymund - Best of luck to you. For others who want to learn about metastability and avoid the mistakes and misconceptions of the past, my advice holds; please read: http://fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm Bob Perlman Cambrian Design Works ---------- "But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." - Carl Sagan On Sun, 9 Oct 2005 14:27:18 +0200, "Raymund Hofmann" <filter002@desinformation.de> wrote: > >"Bob Perlman" <bobsrefusebin@hotmail.com> schrieb im Newsbeitrag >news:8mufk156urltejl11o21p7oup8arqq8bi2@4ax.com... >> On Sat, 8 Oct 2005 14:02:36 +0200, "Raymund Hofmann" >> <filter002@desinformation.de> wrote: >> >> <most stuff snipped> >> >>>What is the probability distribution of the metastable duration >>>comparing the normal FF with a schmitt trigger output state feedback >>>FF? >>>I guess the schmitt output stage will be significantly better and even >>>practically metastable free after 20nS in the lifetime of our Planet. >> >> <some innuendos about unfortunate souls snipped> >> > >I was talking about a FF containing a schmitt trigger _in_ it's feedback >loops. And I was talking about a 7414 schmitt trigger eventually not >suitable for this (and how to get it inside a FF feedback loop), >although maybe not detailed enough. > >> >>>This brings another Idea to my mind: >>> >>>What about injecting noise in the FF feedback loops which is small >>>enough not to alter their (static)performance, but large enough to >>>drive >>>the feedback loops (and maybe schmitt triggers) into clipping and thus >>>their stable state ? >> >> This is an idea that has been proposed before. Unfortunately, it's >> just as likely that noise will drive you into a metastable state as >> out of it. > >Metastability is not the question, it's "duration probability" is. Every >FF has some CK->Q uncertainty(jitter) you could also call "Metastable", >even with proper setup/hold. > >So I can't second this. > >> >> If you sense some frustration on the part of the old hands in this >> group, it's because metastable-fix mania sweeps through here on a >> regular basis, and every time the same "fixes" and "improvements" are >> trotted out, virtually all of which were disproved ages ago. > >I guess you sense some illusion of superiority. > >> >> Please, please, please, everybody, go to: >> >> http://fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm >> >> and read the whole thing. Then look at the bibliography at the end >> and read some more. > >I get partial dyslexia reading the whole thing. This is where I also >want to expose my Ignorance and explain everything (in my way). > >> >> The subject has been well-researched. The point is, you don't *have* > > >The ether has also been "well researched" until Albert Einstein. >You are free to defame me of thinking I am a Genius. >Can you also think on your own or do you only quote "well researched" >subjects ? >Is there a reason individual life is finite by conception ? > >> to guess, at least not if the vendor gives you a little information on >> their metastable performance. And if there isn't enough information >> from the vendor, there are simple ways to trade latency for lower >> metastable failure rate. >> >> Let's move on, folks. Let the healing begin. >> > >Who's healing do you mean ? > >Raymund HofmannArticle: 90298
Hello, Hopefully these groups are appropriate for this quesiton, apologies if not. I've designed a PCI card that does data capture, along with a driver module for Linux 2.4. It all seems to work fine, BUT I have one nagging doubt regarding the DMA performance. I've implemented a data-aware bus master DMA on the PCI interface FPGA, i.e. the PCI card is initialised to transfer a v.large amount of data (upto 512Mbytes). When data is available the card initiates the transfer into the allocated memory location. The memory is then mmap'd into user space, where the user app/driver can interogate the PCI card to find out how much data has been transferred, and process it accordingly. So far so good, all seems to work. The doubt I have is regarding cache paging. Scenario - 2300 bytes of data are received by the PCI card and transferred into the bottom of the memory area. The application/driver detects this transfer and starts processing the data. This will cause the memory page to be copied into the processor cache. While the app is processing this data more (e.g.3400bytes) data arrives in the PCI card and is transferred into memory. When the application has processed the first block of data, it interrogates the PCI card and detects the new data. When it goes to process it, it looks for the data at the end of the first block, BUT and here's the doubt, is there any reason to believe that the page in cache will have been invalidated and reloaded when the 2nd block of data was transferred by the PCI cards DMA action ? Or will the application be looking at the "old" data that was in the unused part of the page when it was first copied into cache ? At the moment I've designed round this concern, by modifying the data handover protocol and ensuring the driver module only hands data over in 4096 byte blocks (Linux 2.4 default page size). The target platforms are PCs using standard Intel chipsets. Any hints appreciated. Many Thanks GordonArticle: 90299
Hi Antii How can i identify the unrelated logic ? what is the meaning of unrelated logic. ? could you please explain about it ? regards bijoy
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