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
"Allan Herriman" <allanherriman@hotmail.com> wrote in message news:gdf9o3dsdk8l2p9954gnfga9bcsp5to7ki@4ax.com... <snip> > What you may find surprising is that 0% of the clock domain crossing > bugs had anything to do with metastability. Glitches and races were > the cause. > > My interpretation: > I think that most designers have heard of metastability, so they put > retiming flip flops everywhere. Consequently, metastability related > problems don't occur often. > Your last paragraph directly contradicts the previous one. If designers actually were properly putting in retiming flip flops then they wouldn't be having clock domain crossing issues. Even if the signal under consideration is an input pin of the device, it still either exists in some clock domain (to which the device may have access to) or it is completely asynchronous to any clock. In either case, sampling of some signal with a clock implies a clock domain crossing into the new clock domain. A metastable output is always caused by violating setup or hold timing requirements. This is a necessary condition. However violating setup or hold time requirements does not necessarily cause an output to be metastable. This implies that violating setup and hold is not a sufficient condition to cause metastability. Since the only knob you have to turn to try to create a metastable output is the timing of one signal relative to another this means that there is no way you can create an experiment that will always cause a flip flop to go metastable. So the only thing you can do is repeat an experiment over and over in the hope that eventually it will go metastable. Having done this though you will still only be able to conclude that violating timing can cause metastability (note: 'can cause' not 'will cause'). KJArticle: 127851
On Wed, 09 Jan 2008 12:49:48 GMT, "KJ" <kkjennings@sbcglobal.net> wrote: > >"Allan Herriman" <allanherriman@hotmail.com> wrote in message >news:gdf9o3dsdk8l2p9954gnfga9bcsp5to7ki@4ax.com... ><snip> >> What you may find surprising is that 0% of the clock domain crossing >> bugs had anything to do with metastability. Glitches and races were >> the cause. >> >> My interpretation: >> I think that most designers have heard of metastability, so they put >> retiming flip flops everywhere. Consequently, metastability related >> problems don't occur often. >> > >Your last paragraph directly contradicts the previous one. Quite the contrary. Please make the distinction between actual metastability and other clock domain crossing issues, such as sampling the same async signal with two different flip flops. In the rest of your post (snipped) you didn't even seem to acknowledge that there are other types of clock domain crossing issues that aren't related to metastability. The first point of my post was that metastability is easy to deal with - just add another flip flop and leave enough timing slack to get whatever MTBF you want. (I know from some of my designs that unless you have clock rates of more than a few hundred MHz, it isn't hard to get failure rates of < 1 metastability-related failure in the lifetime of the product.) The other point of my post was that because everyone has heard of metastability and that it's usually easy to deal with - just add flip flops and some timing slack - it gets taken into account in designs and doesn't actually cause a lot of bugs. Instead, actual bugs related to clock domain crossings are mostly caused by things not related to metastability. (I'm sure you could list a few. I'll see if I can dig up a copy of the training material I wrote which describes the most common errors.) Also, please bear in mind that I was quoting the results of actual research on fielded product designs. Regards, AllanArticle: 127852
> "Allan Herriman" <allanherriman@hotmail.com> wrote in message > news:gdf9o3dsdk8l2p9954gnfga9bcsp5to7ki@4ax.com... > <snip> >> What you may find surprising is that 0% of the clock domain crossing >> bugs had anything to do with metastability. Glitches and races were >> the cause. >> >> My interpretation: >> I think that most designers have heard of metastability, so they put >> retiming flip flops everywhere. Consequently, metastability related >> problems don't occur often. KJ wrote: > Your last paragraph directly contradicts the previous one. Maybe Allan's point is that lack of proper synchronization is a much more common problem than metastable events are in properly synchronized designs. -- Mike TreselerArticle: 127853
michel.talon@gmail.com wrote: > Hi, > > I've a basic question about spartan3. I'm used to work with altera's > FPGA with size unit in logic cells. > I've to use a spartan 3 FPGA, and its size is in gates. > My question : how can I compare the two FPGA ( just for having an > estimation in logic cells ) ? > > Thanks by advance, > > Best regards, Michel. You're used to working with Altera's Logic Elements (LEs) and you don't know how to compare this with the Spartan3 because these chips are specified by gate count? Look at the darned data sheet! I've a feeling you'l find the data you need in the first pages. The "system gates" column is followed "Equivalent Logic Cells." As a seasoned Xilinx data sheet reader myself, I've learned to ignore this column and look at "Slices" and multiply by 2 instead since the "equivalent" means multiplying by a rude, evasive, misleading marketing factor.Article: 127854
"Allan Herriman" <allanherriman@hotmail.com> wrote in message news:veh9o3t1s270peip0bqvatsa9g2mc99ql3@4ax.com... > On Wed, 09 Jan 2008 12:49:48 GMT, "KJ" <kkjennings@sbcglobal.net> > wrote: > >> >>"Allan Herriman" <allanherriman@hotmail.com> wrote in message >>news:gdf9o3dsdk8l2p9954gnfga9bcsp5to7ki@4ax.com... >><snip> >>> What you may find surprising is that 0% of the clock domain crossing >>> bugs had anything to do with metastability. Glitches and races were >>> the cause. >>> >>> My interpretation: >>> I think that most designers have heard of metastability, so they put >>> retiming flip flops everywhere. Consequently, metastability related >>> problems don't occur often. >>> >> >>Your last paragraph directly contradicts the previous one. > > Quite the contrary. Please make the distinction between actual > metastability and other clock domain crossing issues, such as sampling > the same async signal with two different flip flops. > Yes, but sampling an async signal with two different flip flops would not be an example of properly adding retiming flip flops. > In the rest of your post (snipped) you didn't even seem to acknowledge > that there are other types of clock domain crossing issues that aren't > related to metastability. > Actually I do agree with most of what you said (although re-reading my post I can see it probably didn't come across that way...sorry). I certainly agree that darn near every timing problem that I've investigated as well has to do with moving a signal either from a completely asynchronous domain or some other clock domain. Whether or not there was actual metastability or not was irrelevant since the solution to the design error was to properly move the signal into the sampling clock domain. Fundamentally the design error was violation of setup/hold requirements and/or sampling that signal in more than one place. Whether or not that caused actual metastability or not I didn't investigate. My only disagreement was when you said "...so they put retiming flip flops everywhere. Consequently, metastability related problems don't occur often.". But if they properly put in the retiming flops, then they wouldn't have any timing issues, let alone a low probability (but not non-existent) one such as metastability. But my point probably hinges on the work 'properly' as well. > > The first point of my post was that metastability is easy to deal with > - just add another flip flop and leave enough timing slack to get > whatever MTBF you want. (I know from some of my designs that unless > you have clock rates of more than a few hundred MHz, it isn't hard to > get failure rates of < 1 metastability-related failure in the lifetime > of the product.) I agree as long as that signal from async or other domain goes only into exactly one flip flop than it has been properly taken care of. I'll also add that even when apparently coded properly, I've found that synthesis tools can sometimes defeat this by replicating a flop to improve its result which means you have to add vendor specific attributes to try to guard against this. > > The other point of my post was that because everyone has heard of > metastability and that it's usually easy to deal with - just add flip > flops and some timing slack - it gets taken into account in designs > and doesn't actually cause a lot of bugs. I think you're overestimating new designers ability to properly add these flops based on postings in this and other newsgroups even when the poster seems to have knowledge of metastability. > Instead, actual bugs > related to clock domain crossings are mostly caused by things not > related to metastability. (I'm sure you could list a few. I'll see > if I can dig up a copy of the training material I wrote which > describes the most common errors.) > Violating setup and/or hold time requirements covers darn near everything. Sampling with only one flip flop into the new domain covers most other cases. Never combinatorially generate a signal that will be used to sample another signal covers the only other things that I can recall at the moment. > Also, please bear in mind that I was quoting the results of actual > research on fielded product designs. > And posting those results is appreciated...like I said, I think we're solidly in agreement about the solution although I might not have come across as such in my earlier posting. Kevin JenningsArticle: 127855
Eli Bendersky wrote: >>> 2) If such an input is sampled by two different FFs for different >>> purposes, they may end up with different results. >> This is the case of the *missing* synchronizer. >> This is often confused with metastability, >> but it is really a design error. >> I don't have to wait nearly as long to >> observe an error in this case. >> > > Yes, and my question was about the "missing synchronizer", which is a > design error as you said. > > I just wanted an example of real code from real life doing something > useful that is susceptible to this design error. > > Eli A real life situation for a missing synchronizer would be the "duh" moment I had in one of my first processor interfaced designs. I wrote a value to the FPGA but the register write wasn't related to the system clock. Occasionally some of my logic got one part of the word on one cycle before all the logic got the full register value on the second cycle. This schism where values were *supposed* to change simultaneously but didn't caused me problems. Just adding a synchronizing flop DOES NOT get rid of metastability troubles. Just adding two consecutive synchronizing flops DOES NOT get rid of metastability. Luckily most of the time the path between the two flops ends up being short but too often the designer DOES NOT properly constrain the path between those two flops. The effect of hitting the metastability window is that the logic takes a moment longer to decide if it's high or low. While the static timing analyzer will guarantee your results if you meet setup and hold, the synchronizing flop specifically violates the setup and hold in order to rarely hit that metastability window. In this case, the constraints MUST be changed to guarantee the metastability related errors will be in the 1k or 1M year kind of range. The timing constraint from a synchronizing flop to the next flop in the sequence MUST be constrained to a time that's shorter than the prevailing system clock period. If the signal takes up to 2 ns longer to decide what signal level it is, the following logic (or second synchronizing flop) must have that additional headroom built-in through timing constraints. - John_HArticle: 127856
On Wed, 09 Jan 2008 05:47:51 -0800, Mike Treseler <mike_treseler@comcast.net> wrote: > >> "Allan Herriman" <allanherriman@hotmail.com> wrote in message >> news:gdf9o3dsdk8l2p9954gnfga9bcsp5to7ki@4ax.com... >> <snip> >>> What you may find surprising is that 0% of the clock domain crossing >>> bugs had anything to do with metastability. Glitches and races were >>> the cause. >>> >>> My interpretation: >>> I think that most designers have heard of metastability, so they put >>> retiming flip flops everywhere. Consequently, metastability related >>> problems don't occur often. > >KJ wrote: >> Your last paragraph directly contradicts the previous one. > >Maybe Allan's point is that >lack of proper synchronization is a much more >common problem than metastable events are >in properly synchronized designs. Yes! Thanks Mike. I couldn't find the actual figures I wanted, but from memory it went something like this (most commonly encountered clock domain crossing or async logic bug listed first): - (race) Passing vectors (i.e. multiple signals) from clock domain A to clock domain B and expecting all the bits to arrive on the same B clock. - (race) As above, but adding multiple banks of retiming flip flops in the B clock domain, which fixed the (non-existent) metastability issue but did nothing about the race. - (race) Passing a signal in clock domain A to multiple flip flops in clock domain B, and expecting the B flip flops to get the same value on the same clock. - (race) As above, but created when the tools replicate the B logic to manage fanout. - (glitch) Multiple signals in clock domain A hit some combinatorial logic producing a single signal which is sampled by a flip flop in clock domain B. Sometimes there may be a glitch which gets sampled by the B flip flop. It can be difficult to design combinatorial logic with good glitch coverage (and if you do, the tools will often remove it). (See XAPP 024, btw.) - (glitch) Clock multiplexers made out of combinatorial logic with inadequate glitch coverage (or adequate glitch coverage removed by the tools). I think the significant thing about that list is that even if flip flops were infinitely fast and had 0 chance of ever entering a metastable state, all of those bugs would still exist. Regards, AllanArticle: 127857
On Jan 9, 3:03 am, posedg...@yahoo.com wrote: > On Jan 9, 7:57 am, quark.flav...@gmail.com wrote: > > > On Jan 9, 7:43 am, posedg...@yahoo.com wrote: > > > > Is it possible to use DDR SDRAM as single data rate SDRAM and thus > > > eliminate the need for DCM's and tight clock frequency > > > specifications ..? > > > You still have to feed the DDR with appropriate clock signals, because it'll > > always work with differential clock. If you're working with the Spartan 3E > > starter kit this means that the clock frequency should be in the range of > > 75-133 MHz, the DCM is handy because it easily synthesizes these > > frequencies starting from the 50 MHz soldered clock. > > But does the clock frequency have to be within 75-133 MHz range when > the data provided by the DLL on the second flank is ignored?, plain > SDRAM can be clocked down to a few kHz according to Micron (a dram > manufacturer). > It would at least save some DCMs and pcb layout headache. All DDR memories spec a minimum clock frequency. Whether this is due to the internal DLL or other dynamic structures may be vendor dependent. Usually they have the ability to turn off the DLL using a mode register bit, but you'll be doing a lot of experimenting to see if that works. Also note that while you can send the same data twice to emulate single data rate, you still need to meet more stringent timing if you want the chip to see the same write data on both clock edges. If you only meet timing for the second edge, then you'll have to live with tighter timing when you read, because the RAM will send data that changes mid-cycle. You also can't just use some existing SDR IP, since at least the start-up and mode register settings are different, and you'll need to drive the DQS pins on writes, even if you don't use them for reads. I'm assuming you have a board that already has DDR memory on it and you just want to use it more easily? If you're designing a new board you should really look into using the SDR chips instead.Article: 127858
On Jan 8, 1:58 am, jeroen.cl...@gemidis.be wrote: > root cause: > Power down of the FPGA is not correct accoarding to the spec. The fall > time of the power supply is to long. this results in a bad behaviour > of the micro Blaze(uB). During power down the pointer of the uB is > jumping to a random place in the uB code. From this point the uB > executes several actions depending on the fall time of the power > supply. It happens that the pointer jumps to the "write_spi_flash" > function in the code. are you absolutely certain this is what is happening? that is, have you tried wiring in a power monitor to reset microblaze and the problem goes away? it seems unlikely to me. you are saying it randomly jumps and then runs correctly for a bit. all the other registers are randomly changing and the code still works? but if you are sure this is what is happening... how about writing some hardware that holds microblaze reset if it tries to access an invalid address. in a 32bit address space, a jump to a random location is likely to be invalid. alan nishioka alan@nishioka.comArticle: 127859
On Thu, 10 Jan 2008 01:38:32 +1100, Allan Herriman <allanherriman@hotmail.com> wrote: >On Wed, 09 Jan 2008 05:47:51 -0800, Mike Treseler ><mike_treseler@comcast.net> wrote: > >> >>> "Allan Herriman" <allanherriman@hotmail.com> wrote in message >>> news:gdf9o3dsdk8l2p9954gnfga9bcsp5to7ki@4ax.com... >>> <snip> >>>> What you may find surprising is that 0% of the clock domain crossing >>>> bugs had anything to do with metastability. Glitches and races were >>>> the cause. >>>> >>>> My interpretation: >>>> I think that most designers have heard of metastability, so they put >>>> retiming flip flops everywhere. Consequently, metastability related >>>> problems don't occur often. >> >>KJ wrote: >>> Your last paragraph directly contradicts the previous one. >> >>Maybe Allan's point is that >>lack of proper synchronization is a much more >>common problem than metastable events are >>in properly synchronized designs. > >Yes! Thanks Mike. > >I couldn't find the actual figures I wanted, but from memory it went >something like this (most commonly encountered clock domain crossing >or async logic bug listed first): > >- (race) Passing vectors (i.e. multiple signals) from clock domain A >to clock domain B and expecting all the bits to arrive on the same B >clock. > >- (race) As above, but adding multiple banks of retiming flip flops in >the B clock domain, which fixed the (non-existent) metastability issue >but did nothing about the race. > >- (race) Passing a signal in clock domain A to multiple flip flops in >clock domain B, and expecting the B flip flops to get the same value >on the same clock. > >- (race) As above, but created when the tools replicate the B logic to >manage fanout. > >- (glitch) Multiple signals in clock domain A hit some combinatorial >logic producing a single signal which is sampled by a flip flop in >clock domain B. Sometimes there may be a glitch which gets sampled by >the B flip flop. >It can be difficult to design combinatorial logic with good glitch >coverage (and if you do, the tools will often remove it). (See XAPP >024, btw.) > >- (glitch) Clock multiplexers made out of combinatorial logic with >inadequate glitch coverage (or adequate glitch coverage removed by the >tools). > > > >I think the significant thing about that list is that even if flip >flops were infinitely fast and had 0 chance of ever entering a >metastable state, all of those bugs would still exist. A few more. These are still async logic, but not related to clock domain crossings. - Using async reset or set inputs on flip flops to implement a logic function (rather than just using them for initialisation). I can remember a case where a design would fail even when we could prove mathematically that it couldn't fail. Rewriting it to avoid the use of async resets fixed the problem. - Gating clocks to create a logic function. I know this sort of thing is done in ASICs to save power, but it just doesn't seem to work too well in FPGAs sometimes.Article: 127860
On Jan 8, 8:03 am, "MJ Pearson" <mjp...@york.ac.uk> wrote: > >Hi, > > >Gabor is right, As an addendum to his comment, I think that some > >cameras from "Basler" use DVAL as pixel framing signal. It is used > >when the user want to output some selected region from CCD of camera. > >If you are getting two pulses of DVAL, check your camera whether it is > >operating in single or dual tap mode and what is the region of > >interest in camera setting. > > >Hope this helps, > > >/MH > > Thanks, > > My camera operates in 2-taps interleaved mode. It operates as a line scan > camera, a single row value for each column of the sensor array is > calculated and read out. Therefore I don't think the ROI will come into > it, but I'm not sure what the taps refer to or their definition, and > haven't had any luck in finding out...? The term "taps" come from the CCD world, where video comes out as a serial analog stream from the sensor. In larger sensors, the array was read out with more than one analog shift register or CCD where a CCD might read out a quadrant or half of the sensor array. Each of these output streams is called a "tap" and would be digitized independently to provide the necessary readout bandwidth. In some older cameras, the framegrabber would need to re-assemble the multiple taps into an image, possibly getting data in a different order for each tap. One example of this is a four quadrant CCD read out at the four corners of the array. When shifting out the data, you would get the four corner pixels first and scan through in raster fashion toward the final central pixels. In this case you have all combinations of left-to-right, right-to-left, top-to-bottom, and bottom-to-top scanning. Modern cameras might use similar CCD devices, but generally re-order the data within the camera electronics so the output looks like a simple raster. Interleaved tap order usually refers to odd / even pixels coming out of two taps of the camera. In this case each tap services every other pixel of the entire image, so the resultant image is formed by merging (interleaving) the two taps to form a single raster. For Camera Link, the number of "taps" usually refers to the number of digitized pixels sent on each Camera Link pixel clock, regardless of the organization of the sensor. The same camera may operate in 1, 2, or 4 tap modes for example using Medium camera link and 8, 16, or 32 bits per clock. You may find more information in the technical manual of your camera. These are usually available from the vendor's website and have more detailed information that the user manual that ships with the camera. HTH, GaborArticle: 127861
"Allan Herriman" <allanherriman@hotmail.com> wrote in message news:t7o9o3tvvs7jn0gpa56uf2cjng1239729u@4ax.com... > > - Using async reset or set inputs on flip flops to implement a logic > function (rather than just using them for initialisation). I can > remember a case where a design would fail even when we could prove > mathematically that it couldn't fail. Rewriting it to avoid the use > of async resets fixed the problem. > Hi Allan, Can you remember what that was? I'm fairly sure synthesis tools use this type of trick, and I've never seen a problem with it, providing timing is met. > > - Gating clocks to create a logic function. I know this sort of thing > is done in ASICs to save power, but it just doesn't seem to work too > well in FPGAs sometimes. > Right, you get runts or glitches on the clock which might clock some FFs but not others. Very bad! Cheers, Syms.Article: 127862
On 9 jan, 15:12, John_H <newsgr...@johnhandwork.com> wrote: > michel.ta...@gmail.com wrote: > > Hi, > > > I've a basic question about spartan3. I'm used to work with altera's > > FPGA with size unit in logic cells. > > I've to use a spartan 3 FPGA, and its size is in gates. > > My question : how can I compare the two FPGA ( just for having an > > estimation in logic cells ) ? > > > Thanks by advance, > > > Best regards, Michel. > > You're used to working with Altera's Logic Elements (LEs) and you don't > know how to compare this with the Spartan3 because these chips are > specified by gate count? > > Look at the darned data sheet! I've a feeling you'l find the data you > need in the first pages. The "system gates" column is followed > "Equivalent Logic Cells." As a seasoned Xilinx data sheet reader > myself, I've learned to ignore this column and look at "Slices" and > multiply by 2 instead since the "equivalent" means multiplying by a > rude, evasive, misleading marketing factor. Thanks for your answers, I wasn't sure that Xilinx logic cells and altera logic elements were equivalent, but it seems to be.. So thank you. Best regards, Michel.Article: 127863
I do not see how metastability could ever be a "useful" feature. My app note is an analysis tool that measures the statistical probability of the metastable delay by random testing. As such it is useful, and I think it shows the only practical way to really get quantitative data. Peter Alfke, Xilinx Applications On Jan 8, 10:22=A0pm, Eli Bendersky <eli...@gmail.com> wrote: > On Jan 8, 9:41=A0pm, Peter Alfke <pe...@xilinx.com> wrote: > > > On Jan 8, 6:20=A0am, Eli Bendersky <eli...@gmail.com> wrote:> Hello, > > > > Suppose that I'm sampling an asynchronous signal with a FF, without > > > using any synchronizers before it. This FF will become metastable from= > > > time to time with a MTBF depending on the device's parameters, the > > > clock rate and the input signal change rate. > > > Eli, Look at XAPP094 (you can easily google it) It shows the circuit I > > have used to quantify metastable delay. > > The delay is short, so you have to be quick to catch it... > > Peter Alfke > > Hi Peter, > I downloaded this application note a couple of weeks ago and went > through it. Would you say that your metastability-catching circuit > could be useful for some real application ?Article: 127864
On 9 jan, 16:04, Alan Nishioka <a...@nishioka.com> wrote: > On Jan 8, 1:58 am, jeroen.cl...@gemidis.be wrote: > > > root cause: > > Power down of the FPGA is not correct accoarding to the spec. The fall > > time of the power supply is to long. this results in a bad behaviour > > of the micro Blaze(uB). During power down the pointer of the uB is > > jumping to a random place in the uB code. From this point the uB > > executes several actions depending on the fall time of the power > > supply. It happens that the pointer jumps to the "write_spi_flash" > > function in the code. > > are you absolutely certain this is what is happening? > that is, have you tried wiring in a power monitor to reset microblaze > and the problem goes away? > I am not absolutly certain because I can not look inside the uB during Shut down. But it explains what I tried this far: 1) I have made the spi pins of the fpga tri-state. Only if the uB puts 0xBABE in a 16bit register the spi pins leave the high impedant state and normal spi communication between flash and fpga is possible. -> spi commands are logged during power down. 2) I removed the opb_spi core from the design. -> only spi bootloader has access to the flash -> no spi commands are logged during power down. 3) opb_spi core enabled and disabled spi subroutines in the uB code. - > no spi commands are logged during power down. 4) Driving the uB reset to ground before shutting down the power of the bord (initial design -> opb_core and spi_subroutines enabled) -> no spi commands are logged during power down. >it seems unlikely to me. you are saying it randomly jumps and then >runs correctly for a bit. all the other registers are randomly >changing and the code still works? I think I need some explenation with the following sentence "all the other registers are randomly changing" which registers do you mean? >how about writing some hardware that holds microblaze reset if it >tries to access an invalid address. in a 32bit address space, a jump >to a random location is likely to be invalid. Seems a nice solution to me but can you explain it more in detail please? How can I trigger my hardware on a jump to an invalid location of the microblaze pointer? thanks!Article: 127865
On Jan 9, 9:33 am, "Symon" <symon_bre...@hotmail.com> wrote: > "Allan Herriman" <allanherri...@hotmail.com> wrote in message > > news:t7o9o3tvvs7jn0gpa56uf2cjng1239729u@4ax.com... > > > - Using async reset or set inputs on flip flops to implement a logic > > function (rather than just using them for initialisation). I can > > remember a case where a design would fail even when we could prove > > mathematically that it couldn't fail. Rewriting it to avoid the use > > of async resets fixed the problem. > > Hi Allan, > Can you remember what that was? I'm fairly sure synthesis tools use this > type of trick, and I've never seen a problem with it, providing timing is > met. <snip> I know that at least XST will use these inputs to implement logic functions. They have comparatively long setup times, and I see them frequently when looking at static timing analysis reports. Regards, John McCaskill www.FasterTechnology.comArticle: 127866
On Jan 9, 8:25=A0am, John McCaskill <jhmccask...@gmail.com> wrote: > On Jan 9, 9:33 am, "Symon" <symon_bre...@hotmail.com> wrote: > > > "Allan Herriman" <allanherri...@hotmail.com> wrote in message > > >news:t7o9o3tvvs7jn0gpa56uf2cjng1239729u@4ax.com... > > > > - Using async reset or set inputs on flip flops to implement a logic > > > function (rather than just using them for initialisation). =A0I can > > > remember a case where a design would fail even when we could prove > > > mathematically that it couldn't fail. =A0Rewriting it to avoid the use= > > > of async resets fixed the problem. > > > Hi Allan, > > Can you remember what that was? I'm fairly sure synthesis tools use this= > > type of trick, and I've never seen a problem with it, providing timing i= s > > met. > > <snip> > > I know that at least XST will use these inputs to implement logic > functions. =A0They have comparatively long setup times, and I see them > frequently when looking at static timing analysis reports. > > Regards, > > John McCaskillwww.FasterTechnology.com While XST may use the inputs in implementing the logic, it uses the synchronous set/reset rather than the asynchronous clear/preset equivalent. Any synchronous implementation should be covered by the timing analysis.Article: 127867
"John_H" <newsgroup@johnhandwork.com> wrote in message news:209b6b6e-a2eb-4ece-b4ac-3e5488271f4f@v67g2000hse.googlegroups.com... > While XST may use the inputs in implementing the logic, it uses the > synchronous set/reset rather than the asynchronous clear/preset > equivalent. Any synchronous implementation should be covered by the > timing analysis. OK, of course. Thanks, John_H!Article: 127868
Hi together, recently, I acquired an old FPGA development board out of the remainder of stock of a company. The board has quite powerful FPGAs on it, however, I can't find any information about it. It might be a custom development board, but I'm not sure about this. I uploaded some photos at http://www.fim.uni-passau.de/~koltes/fpgaboard/. If anyone of you has any information about this board or even documentation, I would be very glad, if you could contact me. Best regards, Andreas KoltesArticle: 127869
> remainder of stock of a company. The board has quite powerful FPGAs on > it, however, I can't find any information about it. It might be a > custom development board, but I'm not sure about this. > > I uploaded some photos athttp://www.fim.uni-passau.de/~koltes/fpgaboard/. > > If anyone of you has any information about this board or even > documentation, I would be very glad, if you could contact me. Do you want information about the board, or the chips? Xilinx Virtex-II can be programmed by Xilinx Webpack I assume. Maybe you could use the chips to decode the board connections.Article: 127870
michel.talon@gmail.com wrote: >On 9 jan, 15:12, John_H <newsgr...@johnhandwork.com> wrote: >> michel.ta...@gmail.com wrote: >> > Hi, >> >> > I've a basic question about spartan3. I'm used to work with altera's >> > FPGA with size unit in logic cells. >> > I've to use a spartan 3 FPGA, and its size is in gates. >> > My question : how can I compare the two FPGA ( just for having an >> > estimation in logic cells ) ? >> >> > Thanks by advance, >> >> > Best regards, Michel. >> >> You're used to working with Altera's Logic Elements (LEs) and you don't >> know how to compare this with the Spartan3 because these chips are >> specified by gate count? >> >> Look at the darned data sheet! I've a feeling you'l find the data you >> need in the first pages. The "system gates" column is followed >> "Equivalent Logic Cells." As a seasoned Xilinx data sheet reader >> myself, I've learned to ignore this column and look at "Slices" and >> multiply by 2 instead since the "equivalent" means multiplying by a >> rude, evasive, misleading marketing factor. > >Thanks for your answers, I wasn't sure that Xilinx logic cells and >altera logic elements were equivalent, but it seems to be.. So thank >you. They are equivalent. Mostly... The LUTs in a Xilinx device can be used as a 16x1 bit memory or a variable length (up to 16 bit) shift register. This gives you a total of 18 flipflops per slice in a Xilinx device versus 2 in an Altera device. Using the LUTs as memory is a very efficient way to create small memories. Because such a memory is built from multiple elements which can be place freely, it is likely the routing is less constrained than in an Altera device. Using the LUTs as a shift register allows to create very efficient clock dividers and FIFO's. An efficient way of using LUT rams can be in designs in which multiple channels are processed in sequence. By using LUT memory as registers instead of flipflops to keep intermediate results the savings can be enourmous. Almost the same amount of logic for 1 channel can deal with up 16 channels. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 127871
> Do you want information about the board, or the chips? > Xilinx Virtex-II can be programmed by Xilinx Webpack I assume. > Maybe you could use the chips to decode the board connections. I'm primarly looking for information about the board. I guess, the FPGAs are part of a JTAG chain, but I'm not even sure how to access the JTAG subsystem, since there are lots of connectors and jumper banks on the board. There is also a single small push button device on the board, maybe some sort of reset? Despite this I have no idea what the two large chips are supposed to do which can be seen at the bottom of the page. I was told, that this board might have been used in the development of some sort of tape drives, but this information is unconfirmed. AndreasArticle: 127872
Hello, I have downloaded my program to FPGA and it works as it supposed to do. However, I need to download it every time after I switch power off. Hence I wonder - how to save program on FPGA permanently so that it would work even after power was switched off and on again?Article: 127873
> I have downloaded my program to FPGA and it works as it supposed to > do. However, I need to download it every time after I switch power > off. Hence I wonder - how to save program on FPGA permanently so that > it would work even after power was switched off and on again? Some vendors sell FPGAs which are SRAM-based; these devices lose their configuration when the power goes out. They need to have a separate EEPROM connected to the FPGA. This is usually well-documented in application notes for your particular vendor. Some vendors sell FPGAs which are SRAM-based but have nonvolatile storage built into the FPGA, so that when the power goes out, they reload the configuration from the onboard NVRAM. These devices are also offered by most vendors. Actel ships FPGAs which are entirely flash-based; all configuration bits are non-volatile, so they retain their configuration when the power goes out. Actel also ships antifuse-based FPGAs, which are one- time programmable, but won't lose their configuration. K.Article: 127874
John_H wrote: (snip) > A real life situation for a missing synchronizer would be the "duh" > moment I had in one of my first processor interfaced designs. I wrote a > value to the FPGA but the register write wasn't related to the system > clock. Occasionally some of my logic got one part of the word on one > cycle before all the logic got the full register value on the second > cycle. This schism where values were *supposed* to change > simultaneously but didn't caused me problems. Again, I wouldn't call this metastability. It can be made worse by metastability, but the problem is that the propagation delay to the different parts of the register is (always) slightly different, and if you get close enough to the clock edge some will get one value, and some the other. That will still be true even for perfect FFs. > Just adding a synchronizing flop DOES NOT get rid of metastability > troubles. Just adding two consecutive synchronizing flops DOES NOT get > rid of metastability. Luckily most of the time the path between the two > flops ends up being short but too often the designer DOES NOT properly > constrain the path between those two flops. Synchronizing FFs don't get rid of it, but if the probability is low enough that is good enough. Two synchronizing FFs will square the probability of metastability on each clock cycle (assuming statistical independence). > The effect of hitting the metastability window is that the logic takes a > moment longer to decide if it's high or low. While the static timing > analyzer will guarantee your results if you meet setup and hold, the > synchronizing flop specifically violates the setup and hold in order to > rarely hit that metastability window. In this case, the constraints > MUST be changed to guarantee the metastability related errors will be in > the 1k or 1M year kind of range. First the logic must be designed to avoid the multiple register clocking problem. In the case of FIFOs this is done by using gray code such that only one bit changes on any cycle. You get one or the other, where both are valid. The metastability problem comes not while crossing clock domains, but after crossing clock domains. It is normal for the output of a register to go through other logic before the next register. The delay of that logic, in addition to the possible metastability delay, causes the metastability problem. Efficient logic design maximizes the logic between register stages, and so gets closer to failure due to metastability caused delay. A synchronizing register allows the maximum time for metastability to be resolved before entering the next FF. > The timing constraint from a synchronizing flop to the next flop in the > sequence MUST be constrained to a time that's shorter than the > prevailing system clock period. If the signal takes up to 2 ns longer > to decide what signal level it is, the following logic (or second > synchronizing flop) must have that additional headroom built-in through > timing constraints. Yes. -- glen
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