Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On May 15, 3:24=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> wrote: > rickman wrote: ...snip... > Ok, I am beginning to have my light bulb turn on slowly here. =A0The cloc= k > enable concept is new to me, but I think I get it. =A0By sampling my > external clock and creating pulses in the clk50 domain, I can use those > to enable the counter. > > The only thing I'm still unsure about is, that if these rising_edge > pulses are generated by logic, then they are delayed somewhat from > clk50. =A0Do they enable count on the NEXT clk50 edge? =A0(And then > disappear a few ns after that clock edge?) > > Would it make more sense in this type of situation to sample with a 180 > deg phase shifted ~clk50, so that the clock enable pulses would be > centered on the clk50 counting edges? It is hard to give specific advice to such a general question, but I don't think I have ever had to do anything other than detect the edge of the clock, no "phase shifting" required. However, if your sampled clock is close in speed to half the sampling clock rate (i.e. close to the Nyquist rate) then you might find that you need to also sample the data to keep the two in sync. But the details here depend on the details of your interface. A timing diagram is the only way to see what is going on. Recently I had a design that needed to sample the incoming clock and data, but I first registered the serial data with the incoming clock, then sampled both. This allowed me to minimize the skew introduced to the incoming clock relative to the data and have a fresh alignment to work with internally. This was only required because the clock edge and other aspects of the design were programmable so I need to optimize the setup and hold times for a general case rather than working with specific details of a single interface case. > > "Always" is a big statement. =A0I nearly always pick one fast clock > > domain as the "internal" clock and sync slow clocks to this fast one. > > Each "external" clock becomes a clock enable internally. =A0There are > > times when I use the external clock directly, for example the serial > > clock on an SPI port directly clocks the shift register in a recent > > SPI design. =A0Then I have lots of time to sync the parallel word to th= e > > internal clock. =A0But this could be done either way. =A0Sometimes it > > depends on the relative rate of the two clocks. =A0The closer in speed > > they are the harder it can be to fully analyze the timing. > > Yes, I see. =A0And I also see how this becomes quite messy if the externa= l > clock is near the speed of the internal one. =A0But only if data needs to > cross between the two domains, right? Even that doesn't have to be a problem. There is a circuit that will guarantee that you get every clock edge in a crossing and by using a combination of clocking with the incoming clock and sampling you can assure that the data stays with the clock. The limitation is the jitter in your clocks. That has to be smaller than the difference is period. If one clock edge jitters too much so that a period has no clock edge in it (or two if you are looking from the other perspective), you can miss events and data. > Ok, so while I have learned something so far about how to sync external > (slow) clocks to an internal fast clock, it is the case here that this > qep_sim() is a unique clock domain, so should be able to be clocked by > its external source directly. But you can use the internal clock as a means of "filtering" the spurious edges of the incoming clock. > > I suspect that has to do with your clock signal. =A0Does it have a slow > > rise/fall time? =A0I suspect a bit of noise is making it double clock. > > When you route it differently (since it is not on a clock IO pin) the > > glitch can get filtered out depending on how it is routed. =A0It only > > takes a very tiny glitch to cause this sort of double clocking and > > such a tiny glitch can be filtered by the random routing. =A0Putting it > > on a global clock tree should make it fail more often. > > I have to probe it again Monday. =A0I recall Friday that I was a bit > surprised that it had a rounder rising edge near the upper level than I > would have expected. =A0However, I think it is still in the <200ns range. > =A0 It originates from a TI ISO7220C, which specify 1ns output rise/fall. > =A0Good grief, that can't be right. =A0I'ts slowed down a little with a > resistor in there for various reasons related to power sequencing of the > IO buffer panel, vs. the DSP that it usually feeds, or optionally the FPG= A. 200 ns is an eternity on the input of an FPGA. The internal FFs can be clocked by glitches on the order of 10's of ps, IIRC. You will never see this on a scope. The FPGA circuit itself is the best way to detect double clocking problems. > I tried to find the min rise time spec in the Spartan 3E datasheet last > night, and I could swear I found a place where it said 500ns, and now > for the life of me I can't find it again in that hideously long document. Even if they give you a number it will have no meaning since it all depends on the construction of your board. Ground bounce is inevitable. The only question is "how much"? A slow input is susceptible to a smaller amount of ground noise than a fast one. Another advantage (or maybe this was pointed out before) of the rising edge detection on the resync approach is that it removes all such glitches. They are so fast that at the slower sample rate they can't be seen. > I will look into this again with the scope. =A0I'm almost sure it's not > noise though, since a time magnification of the clock when a counting > glitch occurs is perfectly smooth. Yeah, it will look great. But if it is crossing the threshold when a bit of noise hits, it will either double clock on one rising edge or can see a rising edge when the clock is falling. > An important fact is that the counting error always happens on a falling > edge of this ext_sim_clk, not at random times. =A0So it's not picking up > junk from other traces which may carry asynchronous signals, of which > there are a few. I don't really suspect cross talk although that could be happening. FPGAs have a lot of really fast stuff going on inside and it all happens within the same fraction of a nanosecond. That puts a current spike on the ground and power pins which causes a voltage spike from the dI/dt. I have seen this a number of times while I haven't seen an issue with crosstalk causing this in maybe 20 years. I think the PCB designers tend to watch for crosstalk pairs like a hawk while folks sometimes forget about the ground noise of fast parts. > >> I have gathered that when clocks are to be brought in to the FPGA, it = is > >> highly recommended to use a GCLK IO pin, so the signal may be buffered > >> onto a global clock routing line. =A0I have to see if I can rearrange = my > >> IOs to get these external inputs onto GCLK IOs, but there are two of > >> them and the NEXYS2 isn't very liberal about providing GCLKs on the pi= n > >> headers. =A0Some other GCLKs are available on another connector, but I > >> don't yet have the mating for that. > > > Don't try to fix a problem if you don't understand the cause. =A0Why > > would a GLK IO pin eliminate your problem? > > Oh, I don't have any intention of fixing it until I have understood it > (I stated this in the OP)! > > >> Of course, when muxing external clock sources, if there are a lot of > >> them, one could eat into the supply of GCLKs quickly, so this is > >> undesirable. > > > Bingo! =A0That is a big reason for treating slow clocks as clock enable= s > > on an internal clock. > > Well in this case, it also gets muxed. =A0So it would be a waste of GCLK > inputs if it gets fed through logic and becomes a "derived clock" anyway. The big issue with muxing clocks is the added routing time which disrupts the timing relationship between the clock and the incoming data. The tools can help to analyze this, but it is better to not have to deal with it at all if you can. Muxing a clock enable is pretty much transparent since at that point it is just logic. > >> A more interesting question is then, is it possible to take a GP IO > >> input pin, and internally buffer it onto an internal clock routing lin= e? > > > Isn't that what is already happening in your case? > > I have no idea at this point until I learn more about constraints and > how to interpret the hundreds of pages of jibberish that the tools > report when I make my bit file. > > As I mentioned in another post, there seems to be considerable > discussion on the Altera forum about using constraints to control how a > clock is distributed. That sort of stuff is hard to deal with in my opinion. Better off just not having the clock in the first place. > There is also a discussion of how muxing clocks can be dangerous. =A0I am > very suspicous that this might be the real cause of my problem, rather > than a signal integrity issue (I'm pretty good with signal integrity): > > "Gated clocks: On/off gating and muxing of clocks in clock control > blocks or logic"http://www.alteraforum.com/forum/showpost.php?p=3D8506&po= stcount=3D7 > > I have to learn more about how these things are managed on the Xilinx > device as well. In the Lattice parts I use they have clock mux blocks. But these don't deal with the main problems of muxing clocks, the delay. They just provide a way to "cleanly" switch between clocks without generating splinter pulses. If the clock has no data interface then you have a lot more freedom to run clocks through logic. > >> Thanks for input and clarification. > > > Let us know what you find. =A0It is hard to analyze problems like this > > without doing tests. =A0I may be completely off base in this case. > > > Rick > > What do you make of the test that I did where I took a copy of the muxed > clock, and routed it back outside, then the glitches disappeared? Remember that the glitch can be as small as a few 10's of picoseconds which doesn't take much to filter out. I wouldn't worry with that test myself. The problem is not something mysterious. You said the problem *always* happens on a clock edge and never in the middle of a clock cycle, so that is clear enough to me that it is a combination of the slow clock edges and a bit of ground noise. Fix one or the other or sample the clock and data to in essence, provide a digital low pass filter. > Since this was not perturbing the ext_sim_clk input path, and yet the > problem disappeared, it argues strongly that the glitches are > originating internally, possibly in the mux, where perhaps a change in > loading by adding the new output path makes the glitches go away. > > Thanks very much for your feedback! I don't think this test shows that at all. You can filter the glitches anywhere downstream of their source. Try adding a fast buffer to the clock signal. If that makes the problem go away then it is pretty clear that the slow clock edges are the problem. But that doesn't mean you have to fix it with a buffer. I build a board with a general purpose serial input/output. My customer at a major networking company figured out what I was doing in the FPGA and liked it so much they are doing the same thing in their larger products which have dozens of external clocks. He got the details from me and changed his design so it uses one internal clock instead. He especially liked the "filtering" the sampling approach provides since they don't know the nature of the signals their customers will use this with. Need any consulting help? Things are pretty slow for me at the moment. Although this is working well for my kayaking schedule. :^) RickArticle: 151776
On May 14, 11:17=A0pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net> wrote: > Andrew Holme wrote: > > > If it's an external clock, slow rise and fall times plus additive noise= can > > cause multiple counts if it slews too slowly through the logic threshol= d. > > If the external clock rate is low, the best solution is to sample it at= a > > rate comparable to the rise/fall time. > > Thanks for the reply. > > Ugh. =A0I could have sworn a few minutes ago I found a spec of 500ns for > the min slew rate of an input in the hideous ds312.pdf "Spartan-3E FPGA > Family: =A0Data Sheet" but now I can't find it again. > > Anyway, getting a clean enough clock to a logic device really isn't that > hard. =A0I'll scope it again Monday and see if I can't put it up somewher= e. One more comment and then I have to run. You will never see the glitch on a scope, if for no other reason because it doesn't have to be on the external signal. A small ground shift from internal switching currents can add a very narrow spike to an input right at the IO buffer in the FPGA. No noise on the input, spike on the output. Ground bounce, the invisible noise source. RickArticle: 151777
The ususal suspect here is ground bounce. If outputs are switching at the same time that the clock edge occurs the wiggle you see on the scope is also partly present on the GND pin(s), and so also seen superimposed on the CLK signal by the CLK input buffer. A simple test is dividing the CLK by 2 and sending that to an output pin. You will immediately see the non-periodic pattern and most scopes can trigger on a pulse that is longer than a CLK period. Fast CLK edges will prevent this problem, but your CLK is far from perfect (for a fast chip, that is...). Regards, Arie de Muynck "Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote in message news:iqss1601vk@news6.newsguy.com... > Hi: > > Today I took scope shots of a clock input to my Xilinx Spartan 3e, > Digilent NEXYS2 board. The clock goes to a counter, simulating a > quadrature encoder, as explained in post "Counter clocks on both edges > sometimes, but not when different IO pin is used" on 5-13-2011. > > I have discovered that I'm dealing with a different animal here than > even the fastest logic chips I've grown comfortable with, the AC family. > > First is the input to the NEXYS2 IO connector pin, driven by a TI > ISO7240c chip, with about a 150 series resistor. This shows an > incidence where the counter incorrectly counted on the falling edge: > > http://web.newsguy.com/crobcng/spartan3e/scope_11.png > > The falling edge which caused the glitch: > > http://web.newsguy.com/crobcng/spartan3e/scope_12.png > > At this point I was thinking, "there is no reason for this to be a > problem." As any discrete logic chip would never glitch with this. > > Nonetheless, the evidence is that internally the counter is seeing a > rising edge here, so there must be a brief upward wiggle internally. > How to see this? I can't really. The best I can do is take a copy of > the internal signal, and spit it back out another IO port. > > Here is where things get weird. Depending on which pins are chosen, it > is possible that the glitches will go away when a copy is sent out an IO > port. An important additional clue was the fact that an adjacent pin to > the clock input, when changed from unconfigured (input) to output, even > if just a static logic level was output, caused the glitching to go > away. More on that later. > > Here is the scope looking at the output from the FPGA, of a copy of the > internal clock, again captured on an offending falling edge causing an > incorrect count (note this just looks the same as scope_12.png above: > > http://web.newsguy.com/crobcng/spartan3e/scope_13.png > > But when zoomed in, there is the slightest wiggle present: > > http://web.newsguy.com/crobcng/spartan3e/scope_14.png > > Now this is a 500MHz scope with a 500MHz probe, and very short (1.5cm) > ground lead, so this is a good probing setup. That little wiggle is > nearly a Ghz! Due to at least -6dB of attenuation from the scope + > probe, the actual wiggle is probably twice or more than the amplitude > shown, which is barely anything. > > Now this is of course NOT what the internal signal looks like, of > course, because it had to go through an output buffer. Also, the choice > of LVCMOS 3.3V makes this perhaps the slowest output possible. > > But it seems like the output buffer is trying to tell us something, > about what the internal signal looks like. It has a friggin' glitch! > > I also zoomed in on several adjacent falling edges, ones which did not > cause a counter glitch. These have at most a "shelf" at the same level, > but no slope reversal. Most have just an inflection. There is a > pattern here. > > > Finally, I replaced the driver of the input pin from the relatively high > impedance source to a terminated 50 ohm cable with 10ns edges coming > directly from a generator, and the glitches stopped. This is consistent > with the fact that the behavior changes in relation to the change in > impedance of a pin adjacent to the input pin. > > > This is fascinating. I have to wrap my head around the fact that things > can be happening inside the chip at the near GHz rate, so the magnitude > of the signal integrity requirement stringency is about an order of > magnitude more demanding than I'm used to. > > > I would like to scope this again with my 1GHz scope (the one I thought > I'd only ever need for my optical parametric oscillator work), and see > if also I can get a faster, lower voltage signaling standard selected. > I'm not sure if the NEXYS2 board will let that happen. We'll see. > > I'm also curious to see what will happen if the edge time is slowed > down, but the drive impedance is still low. Fortunately my generator > has adjustable slew rates, so I can check this out too. > > > Well at least now I know what is really going on. > > > -- > _____________________ > Mr.CRC > crobcBOGUS@REMOVETHISsbcglobal.net > SuSE 10.3 Linux 2.6.22.17Article: 151778
Arie de Muynck wrote: > The ususal suspect here is ground bounce. If outputs are switching at the > same time that the clock edge occurs the wiggle you see on the scope is > also > partly present on the GND pin(s), and so also seen superimposed on the CLK > signal by the CLK input buffer. > A simple test is dividing the CLK by 2 and sending that to an output pin. > You will immediately see the non-periodic pattern and most scopes can > trigger on a pulse that is longer than a CLK period. > Fast CLK edges will prevent this problem, but your CLK is far from > perfect (for a fast chip, that is...). > > Regards, > Arie de Muynck Indeed. Why on earth don't they put some hysteresis on the inputs to these silly chips? Thanks for the reply! -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151779
rickman wrote: >> Would it make more sense in this type of situation to sample with a 180 >> deg phase shifted ~clk50, so that the clock enable pulses would be >> centered on the clk50 counting edges? > > It is hard to give specific advice to such a general question, but I > don't think I have ever had to do anything other than detect the edge > of the clock, no "phase shifting" required. However, if your sampled > clock is close in speed to half the sampling clock rate (i.e. close to > the Nyquist rate) then you might find that you need to also sample the > data to keep the two in sync. But the details here depend on the > details of your interface. A timing diagram is the only way to see > what is going on. Ok I made a edge detect, clock enable modification to my circuit, and it worked fine the first try (after an hour of battling with the Xilinx tools from hell over some silly coding issue). >> Ok, so while I have learned something so far about how to sync external >> (slow) clocks to an internal fast clock, it is the case here that this >> qep_sim() is a unique clock domain, so should be able to be clocked by >> its external source directly. > > But you can use the internal clock as a means of "filtering" the > spurious edges of the incoming clock. Yes. I still think the situation can arise where frequency division, pulse generation, etc. must be done based on a clock or timebase from another system. And where the resynchronization jitter can't be tolerated by registering the input "clock" to another clock close to the chip. I work in scientific research, and critical timing systems with lasers, engines, etc. are all over the place. Having to do ms delays with ns accuracy and ps jitter are commonplace. Hence a significant part of our equipment budget goes to the likes of Stanford Research Systems, Berkeley Nucleonics, etc. So the situation will eventually arise where I will have to deliver a clean external clock to an FPGA. I underestimated the snappiness needed here to feed a clock from my rather robust (from an idiot proofing from the user, surge, and ESD proofing perspective) but sluggish (with excessive protective impedance in the line) input buffering scheme. The signal is certainly smooth, so it's not external noise, but at a 30ns rise/fall, that's certainly enough to allow a little wiggle of ground bounce to screw things. Another reason why I love input hysteresis. I always put Schmitt triggers on all my external world digital inputs. > 200 ns is an eternity on the input of an FPGA. The internal FFs can > be clocked by glitches on the order of 10's of ps, IIRC. You will > never see this on a scope. The FPGA circuit itself is the best way to > detect double clocking problems. This fact is now clear. >> I tried to find the min rise time spec in the Spartan 3E datasheet last >> night, and I could swear I found a place where it said 500ns, and now >> for the life of me I can't find it again in that hideously long document. > > Even if they give you a number it will have no meaning since it all > depends on the construction of your board. Ground bounce is > inevitable. The only question is "how much"? A slow input is > susceptible to a smaller amount of ground noise than a fast one. Yes. > Another advantage (or maybe this was pointed out before) of the rising > edge detection on the resync approach is that it removes all such > glitches. They are so fast that at the slower sample rate they can't > be seen. That is an advantage, and I think I'll use this approach whenever possible now. > I don't really suspect cross talk although that could be happening. > FPGAs have a lot of really fast stuff going on inside and it all > happens within the same fraction of a nanosecond. That puts a current > spike on the ground and power pins which causes a voltage spike from > the dI/dt. I have seen this a number of times while I haven't seen an > issue with crosstalk causing this in maybe 20 years. I think the PCB > designers tend to watch for crosstalk pairs like a hawk while folks > sometimes forget about the ground noise of fast parts. Yeah, I am convinced that it is the ground bounce at this point. > The big issue with muxing clocks is the added routing time which > disrupts the timing relationship between the clock and the incoming > data. The tools can help to analyze this, but it is better to not > have to deal with it at all if you can. Muxing a clock enable is > pretty much transparent since at that point it is just logic. That's what I'm doing now. I made two edge detectors right on the input timebases (I really don't want to call them clocks now) and then fed the CEs to a mux, then on to the CE input of the enhanced qep_sim(). > In the Lattice parts I use they have clock mux blocks. But these > don't deal with the main problems of muxing clocks, the delay. They > just provide a way to "cleanly" switch between clocks without > generating splinter pulses. If the clock has no data interface then > you have a lot more freedom to run clocks through logic. In my case, splinter pulses (I call them "seams" or phase discontinuities) aren't an issue, since there are a few recalibration revolutions of the QEP every time the mux might be switched before anything important happens. But this needs to be carefully considered. >> Since this was not perturbing the ext_sim_clk input path, and yet the >> problem disappeared, it argues strongly that the glitches are >> originating internally, possibly in the mux, where perhaps a change in >> loading by adding the new output path makes the glitches go away. > > I don't think this test shows that at all. Correct. I had gotten a bit sidetracked by the fact that muxes of the Y=s&a|~s&b equation can glitch when s switches while a and b are both true. This can be easily fixed, but isn't related to my problem, which has s constant. > You can filter the > glitches anywhere downstream of their source. Try adding a fast > buffer to the clock signal. If that makes the problem go away then it > is pretty clear that the slow clock edges are the problem. And that is what happened. Goes away with faster input. > Need any consulting help? Things are pretty slow for me at the > moment. Although this is working well for my kayaking schedule. :^) > > Rick Please send your CV to my work email: crcarleREMOVETHISCRAP@ANDTHISTOOsandia.gov I have used a consultant before (someone who hangs here), but wound up doing things my way anyway, after learning a few important bits from him. In general I have the time to figure things out, and I love the learning process, so it's unlikely we'll need you. There are also some expert FPGA designers on site, but somewhat partitioned from my division. But I do like to keep a list of prospective consultants on file, because the situation occasionally arises where a consultant is the right solution. Good day! -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151780
On Tue, 17 May 2011 06:40:07 -0700, rickman wrote: > Need any consulting help? Things are pretty slow for me at the moment. > Although this is working well for my kayaking schedule. :^) > > Rick Heh, you too, huh? If only the wind dropped (here on the Isle of Skye), anyway. At least the three sheets of ply lurking in the garage since 2004 are now kayak-shaped... - BrianArticle: 151781
> At this point I can't say I understand what you are asking. =A0Do you > have something specific you are asking about or have you figured it > out at this point? > The idea was to have a small but efficient CPU inside of FPGA which could be used to collect some debugging data (e.g. connected to my http://www.ise.pw.edu.pl/~wzab/fpgadbg tool) and also to control behavior of user IP core. Forth seems to be the best solution due to it's extendibility and possibility to work using simple link (serial or other). I've exchanged some e-mails with the developer who ported J1 to MyHDL and after this discussion I think, that the approach used in Riscy Pygness may be really the best solution. -- Thanks, WojtekArticle: 151782
> First is the input to the NEXYS2 IO connector pin, driven by a TI > ISO7240c chip, with about a 150 series resistor. This shows an > incidence where the counter incorrectly counted on the falling edge: What's the signal path to the FPGA? > The falling edge which caused the glitch: > http://web.newsguy.com/crobcng/spartan3e/scope_12.png What exactly are you scoping here? Ch3&4 are at 5V, is there some current/voltage limiting device between the pins and the FPGA? Are ch3 and ch4 your quadrature encoder inputs? What's ch1 looking at? If that falling edge is an input than at ~30ns it's shouldn't be what's causing the problem unless you've got _terrible_ ground problems. > Here is where things get weird. Depending on which pins are chosen, it > is possible that the glitches will go away when a copy is sent out an IO > port. An important additional clue was the fact that an adjacent pin to > the clock input, when changed from unconfigured (input) to output, even > if just a static logic level was output, caused the glitching to go > away. More on that later. This shows your design is still susceptible to asynchronous inputs toggling. Synchronise both(all) the inputs at the IO to the system clock then use those to look for falling or rising edges for your counter NialArticle: 151783
Nial Stewart wrote: >> First is the input to the NEXYS2 IO connector pin, driven by a TI >> ISO7240c chip, with about a 150 series resistor. This shows an >> incidence where the counter incorrectly counted on the falling edge: > > What's the signal path to the FPGA? The ISO is on a 6-layer PCB IO buffering panel with BNC connectors to connect to a research lab. The output of the ISO (input to FPGA) at 3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA header pin on the Digilent NEXYS2 board. >> The falling edge which caused the glitch: >> http://web.newsguy.com/crobcng/spartan3e/scope_12.png > > What exactly are you scoping here? That is a horizontally magnified view of the input to the FPGA (ch1 "A0") measured at the Digilent board pin, with 1.5cm probe ground to the Digilent pin. The other channels are outputs from the FPGA, after they pass through output buffering devices and level translation to 5V on the buffering panel. > Ch3&4 are at 5V, is there some current/voltage limiting device between > the pins and the FPGA? > > Are ch3 and ch4 your quadrature encoder inputs? Buffered, translated outputs from the FPGA, they go out the panel and also at 3.3V go to a TI TMS320F2812. > What's ch1 looking at? Explained above. > If that falling edge is an input than at ~30ns it's shouldn't be what's causing > the problem unless you've got _terrible_ ground problems. Well if there are ground problems, they are out of my control, as this is the signal at the pin on the Digilent board. I would expect them to have done a competent job. I'm not sure, is there a history of people complaining about Digilent board signal integrity problems? >> Here is where things get weird. Depending on which pins are chosen, it >> is possible that the glitches will go away when a copy is sent out an IO >> port. An important additional clue was the fact that an adjacent pin to >> the clock input, when changed from unconfigured (input) to output, even >> if just a static logic level was output, caused the glitching to go >> away. More on that later. > > > This shows your design is still susceptible to asynchronous inputs toggling. The important other fact is that if the drive impedance is made stiffer (180->50ohms) and speed to the FPGA input increased (30->10ns) then the glitches are no longer observed, even after an all night wait. > Synchronise both(all) the inputs at the IO to the system clock then use those > to look for falling or rising edges for your counter Yeah, tried that. Works. I think I have things under control, with two possible choices of path forward. Thanks for the feedback. -- _____________________ Mr.CRC crobcBOGUS@REMOVETHISsbcglobal.net SuSE 10.3 Linux 2.6.22.17Article: 151784
Brian Drummond wrote: > On Tue, 17 May 2011 06:40:07 -0700, rickman wrote: > >> this is working well for my kayaking schedule. :^) >> > Heh, you too, huh? Is there some requirement that FPGA coders are also kayakers? Pete Fraser Looksha IV HVArticle: 151785
jc wrote: > Problem 1 questions: > How did you discover this behavior? Simulation? Chipscope? If > chipscope, does it work in functional simulation? If so, can you > describe difference between simulation stimulus and chipscope > stimulus? > Are you using separate clocks to write/read data to/from dpram? > Does your design pass static timing analysis for all clock domains? > What is the exact relationship between the write cycles and read > cycles? > Did you use coregen to create the dpram? If so, what latency does it > say your dpram will have? It will alter this depending on if you > select primitive/core output regs. > > Problem 2 questions: > Maybe you have unintentionally configured and are using a programmable > almost empty flag? > > - John > Additional questions on Problem 2: What are the write clock and read clock frequencies? You *do* understand that the empty flag gets synchronized to the read clock? If you write one word and then wait a long time does the empty flag eventually go low? Is this behavior noted in simulation or in the real world? If in simulation did you wait at least 100 ns for global set/reset to end before writing the FIFO? -- GaborArticle: 151786
Does anyone know if its possible to change the waveform signals so that they are in hex instead of binary. I dont want to do it manually but just have it come up in hex when the design is loaded. Thanks Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151787
>> What's the signal path to the FPGA? > > The ISO is on a 6-layer PCB IO buffering panel with BNC connectors to > connect to a research lab. The output of the ISO (input to FPGA) at > 3.3V passes via a 2" ground return wire and 2" signal wire to an FPGA > header pin on the Digilent NEXYS2 board. Then it's probably not a ground problem, especially if this is the only input to the FPGA. > That is a horizontally magnified view of the input to the FPGA (ch1 > "A0") measured at the Digilent board pin, with 1.5cm probe ground to the > Digilent pin. Does that go straight to the FPGA? Is this what it's seeing? >> If that falling edge is an input than at ~30ns it's shouldn't be what's causing >> the problem unless you've got _terrible_ ground problems. > > Well if there are ground problems, they are out of my control, as this > is the signal at the pin on the Digilent board. I would expect them to > have done a competent job. > I'm not sure, is there a history of people complaining about Digilent > board signal integrity problems? No, as above this almost definitely isn't a problem. >> This shows your design is still susceptible to asynchronous inputs toggling. > > The important other fact is that if the drive impedance is made stiffer > (180->50ohms) and speed to the FPGA input increased (30->10ns) then the > glitches are no longer observed, even after an all night wait. There could be a race condition internally which stops being a factor when you speed up the inputs. Depending on your build, choice of pins etc this could be re-introduced at any point. :-) >> Synchronise both(all) the inputs at the IO to the system clock then use those >> to look for falling or rising edges for your counter > > Yeah, tried that. Works. I think I have things under control, with two > possible choices of path forward. No, there's _only_ one path forward, synchronise your inputs. The input you're looking at is _reasonably_ fast, how fast is the internal clock you're using to synchronise it? Ideally it'll be a good multiple (> 5) of this clock. > Thanks for the feedback. No problem, other people's problems are always interesting! NialArticle: 151788
On Wed, 18 May 2011 09:46:26 -0500, maxascent wrote: > Does anyone know if its possible to change the waveform signals so that > they are in hex instead of binary. I dont want to do it manually but > just have it come up in hex when the design is loaded. My modelsim.ini contains the following lines in the [vsim] section: ; Default radix for all windows and commands. ; Set to symbolic, ascii, binary, octal, decimal, hex, unsigned DefaultRadix = symbolic Regards, AllanArticle: 151789
Thanks Allan I forgot to look in the .ini file Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151790
On 05/18/11 17:31, Allan Herriman wrote: > On Wed, 18 May 2011 09:46:26 -0500, maxascent wrote: > >> Does anyone know if its possible to change the waveform signals so that >> they are in hex instead of binary. I dont want to do it manually but >> just have it come up in hex when the design is loaded. > > > My modelsim.ini contains the following lines in the [vsim] section: > > ; Default radix for all windows and commands. > ; Set to symbolic, ascii, binary, octal, decimal, hex, unsigned > DefaultRadix = symbolic you can also type radix hex in the command console or add it to your .do fileArticle: 151791
On May 18, 5:32=A0am, wzab <wza...@gmail.com> wrote: > The idea was to have a small but efficient CPU inside of FPGA which > could be used to collect some debugging data (e.g. connected > to myhttp://www.ise.pw.edu.pl/~wzab/fpgadbgtool) > and also to control behavior of user IP core. > Forth seems to be the best solution due to it's extendibility > and possibility to work using simple link (serial or other). I once saw a 3-word Forth, which consisted of only three words running on the target board: fetch, store and execute. Everything else was done on the host system and the three words were invoked over a serial link. You have two options: 1. Words compiled on the host run on the host, performing any I/O over the serial link. 2. Words compiled on the host run on the target after being uploaded. Do you need a CPU to implement the "three words" or can you use hardware? If you have a fast enough serial link (JTAG can be pretty fast), all you need is fetch and store in the FPGA and execute on the PC. An interesting interface option, while not as fast as SPI/JTAG, is I2C. Silabs CP2112 is a USB HID to I2C interface chip. A Forth (or Python or whatever) Windows app can talk to your I2C stuff with no drivers other than the built-in USB HID support. -BradArticle: 151792
> > >On 05/18/11 17:31, Allan Herriman wrote: >> On Wed, 18 May 2011 09:46:26 -0500, maxascent wrote: >> >>> Does anyone know if its possible to change the waveform signals so that >>> they are in hex instead of binary. I dont want to do it manually but >>> just have it come up in hex when the design is loaded. >> >> >> My modelsim.ini contains the following lines in the [vsim] section: >> >> ; Default radix for all windows and commands. >> ; Set to symbolic, ascii, binary, octal, decimal, hex, unsigned >> DefaultRadix = symbolic > >you can also type >radix hex >in the command console or add it to your .do file > Ok thanks, Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151793
On 5/18/2011 7:50 AM, Nial Stewart wrote:
> No problem, other people's problems are always interesting!
"It's funny 'cause it's true." as Homer Simpson said.
Time for me to get back to making some more-interesting problems.
-- Mike Treseler
Article: 151794Hi, I need to take out two square wave signals from the Virtex II Pro FPGA board(XC2VP30, package ff896) with good signal shape and less jitter value. The frequency of the two square wave signals are around 40MHz and one is the delayed version of the other. I am trying to evaluate the performance of a delay generator block inside the FPGA. Hence, the shape and precision of the delays is of greater importance to me. I have tried to take the signals through various pins on the board including the high speed expansion connector. But I found that only when the signals are routed out through the EXT_CLK_P(G15) and EXT_CLK_N(F15) pins, the jitter performance is the best. But there is a funny thing happening when I observe the two waveforms on a scope. Below are the two cases. Looks like, when the signal levels of the two signals are different, the signal with ZERO logic goes up to around 0.2*Vsupply and at the same time the signal with logic '1' goes down by around 0.2Vsupply. Can anybody suggest how can I avoid such a situation? I feel there is some sort of resistor coupling between these two signals. But, can I disable this coupling by changing some setting in the ucf file? This is the entry in the ucf file corresponding to the two pins mentioned above. NET "clk_in_copy" LOC = "G15" | IOSTANDARD = LVTTL | SLEW = FAST | DRIVE = 12 ; #EXTERNAL_CLOCK_P=G15 NET "op_from_delay_chip_copy" LOC = "F15" | IOSTANDARD = LVTTL | SLEW = FAST | DRIVE = 12 ; #EXTERNAL_CLOCK_N=F15 Please suggest a way to set these signals such that the coupling between these two signals is nullified and I can use them as two true single ended outputs. Here is an illustration of the case. https://picasaweb.google.com/lh/webUpload?uname=pratap.iisc&aid=5608112619950590593 Waiting for some helpful answers. Thanks and regards, PratapArticle: 151795
"Brad" <hwfwguy@gmail.com> wrote in message news:75de307b-6c91-46ed-9ee6-e2a57c5716a0@s41g2000prb.googlegroups.com... On May 18, 5:32 am, wzab <wza...@gmail.com> wrote: > > Forth seems to be the best solution due to it's extendibility > > and possibility to work using simple link (serial or other). > > I once saw a 3-word Forth, > Frank Sergeant's 3-instruction Forth: http://pygmy.utoh.org/forth.html Rod PembertonArticle: 151796
On May 18, 11:06=A0pm, Pratap <pratap.i...@gmail.com> wrote: > Hi, > I need to take out two square wave signals from the Virtex II Pro FPGA > board(XC2VP30, package ff896) with good signal shape and less jitter > value. The frequency of the two square wave signals are around 40MHz > and one is the delayed version of the other. I am trying to evaluate > the performance of a delay generator block inside the FPGA. Hence, the > shape and precision of the delays is of greater importance to me. I > have tried to take the signals through various pins on the board > including the high speed expansion connector. But I found that only > when the signals are routed out through the EXT_CLK_P(G15) and > EXT_CLK_N(F15) pins, the jitter performance is the best. But there is > a funny thing happening when I observe the two waveforms on a scope. > Below are the two cases. Looks like, when the signal levels of the two > signals are different, the signal with ZERO logic goes up to around > 0.2*Vsupply and at the same time the signal with logic '1' goes down > by around 0.2Vsupply. Can anybody suggest how can I avoid such a > situation? I feel there is some sort of resistor coupling between > these two signals. But, can I =A0disable this coupling by changing some > setting in the ucf file? This is the entry in the ucf file > corresponding to the two pins mentioned above. > > NET "clk_in_copy" =A0LOC =3D "G15" | IOSTANDARD =3D LVTTL =A0| SLEW =3D F= AST | > DRIVE =3D 12 ; > #EXTERNAL_CLOCK_P=3DG15 > > NET "op_from_delay_chip_copy" =A0LOC =3D "F15" | IOSTANDARD =3D LVTTL | S= LEW > =3D FAST | DRIVE =3D 12 ; > #EXTERNAL_CLOCK_N=3DF15 > > Please suggest a way to set these signals such that the coupling > between these two signals is nullified and I can use them as two true > single ended outputs. > > Here is an illustration of the case.https://picasaweb.google.com/lh/webUp= load?uname=3Dpratap.iisc&aid=3D56081... > > Waiting for some helpful answers. > Thanks and regards, > Pratap Sorry...The link for the picture was wrogly pasted...Here is the correct link. https://picasaweb.google.com/pratap.iisc/May182011?authkey=3DGv1sRgCMjQ85X3= q5O50gE#5608112742914669794Article: 151797
On 5/18/11 6:16 AM, Brad wrote: > On May 18, 5:32 am, wzab<wza...@gmail.com> wrote: >> The idea was to have a small but efficient CPU inside of FPGA which >> could be used to collect some debugging data (e.g. connected >> to myhttp://www.ise.pw.edu.pl/~wzab/fpgadbgtool) >> and also to control behavior of user IP core. >> Forth seems to be the best solution due to it's extendibility >> and possibility to work using simple link (serial or other). > > I once saw a 3-word Forth, which consisted of only three words running > on the target board: fetch, store and execute. Everything else was > done on the host system and the three words were invoked over a serial > link. You have two options: > > 1. Words compiled on the host run on the host, performing any I/O over > the serial link. > 2. Words compiled on the host run on the target after being uploaded. > > Do you need a CPU to implement the "three words" or can you use > hardware? If you have a fast enough serial link (JTAG can be pretty > fast), all you need is fetch and store in the FPGA and execute on the > PC. Those three useful commands are necessary to support any kind of remote download or bootstrap regardless of language, but they certainly don't constitute anything resembling Forth. Most microprocessor boards come with this facility on board, usually in some form of ROM. JTAG is one way of doing it, although it also has other functions. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================Article: 151798
On May 18, 2:15=A0pm, Elizabeth D Rather <erat...@forth.com> wrote: > On 5/18/11 6:16 AM, Brad wrote: > > I once saw a 3-word Forth, which consisted of only three words > > *running on the target board* > Those three useful commands are necessary to support any kind of remote > download or bootstrap regardless of language, but they certainly don't > constitute anything resembling Forth. Yes, the "Three Word Forth" is an attention grabbing title, not *really* a three word forth, especially since the execute implies something to be executed, so for the "processor inside an FPGA" system, you still need the processor for the execute to have something *to* execute. Heck, "load, store, execute" would be a "three word forth" in any setting in terms of the absolute minimum bootstrap required, given knowledge of how to build a raw executable on the target.Article: 151799
On May 18, 11:15=A0am, Elizabeth D Rather <erat...@forth.com> wrote: > Most microprocessor boards come > with this facility on board, usually in some form of ROM. =A0JTAG is one > way of doing it, although it also has other functions. I implemented SwiftX's XTL protocol (except for Execute) in VHDL to access stuff in my FPGA without the need for a CPU, for testing. -Brad
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