Hi, first of all, I know that asynchronous signals are bad, etc but that's what i have to work with. I am using Spartan 3E FPGA. I have an internal clock running at 125 MHz. I cannot use any DCM for conversion so i'm stuck with that. I get an external signal that alternates between high and low state at a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an error in external hardware that the signal is held low or high for more than 1/2 a cycle. I need to be able to detect this. I originally thought of detecting the first rising edge,(Major issues with setup time can occur here) then use a counter and approximate that 3 125 MHz cycle should fall into the low region of the 13.56 MHz period. If my counter reaches 3 or 4 and the signal is still hi, then there is an error. I would also need to check if the signal stays low for longer than necessary. It's not very precise thought so i am wondering if there is a better solution. Any idea???? Thanks a lot, Amish
Determine error in asynchronous signal
Started by ●February 21, 2007
Reply by ●February 21, 20072007-02-21
axr0284 wrote:> Hi, > first of all, I know that asynchronous signals are bad, etc but > that's what i have to work with. I am using Spartan 3E FPGA. I have an > internal clock running at 125 MHz. I cannot use any DCM for conversion > so i'm stuck with that. > > I get an external signal that alternates between high and low state at > a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an > error in external hardware that the signal is held low or high for > more than 1/2 a cycle. I need to be able to detect this. > > I originally thought of detecting the first rising edge,(Major issues > with setup time can occur here) then use a counter and approximate > that 3 125 MHz cycle should fall into the low region of the 13.56 MHz > period. If my counter reaches 3 or 4 and the signal is still hi, then > there is an error. I would also need to check if the signal stays low > for longer than necessary. > > It's not very precise thought so i am wondering if there is a better > solution. Any idea???? Thanks a lot, > AmishKey question is how much more than 1/2 a cycle is an error ? How soon do you need to flag that as an error ? Is jitter OK on that error signal ? You need to set a trip threshold, and the longer that it, % wise, the easier it gets :) It's basically an XOR edge detector triggering a monostable. -jg
Reply by ●February 21, 20072007-02-21
The straightforward implementation (counting 125 MHz during every half- period of 13.5 MHz) has a phasing error of one 125 MHz period = 8 ns. If that is too big an error, you can frequency-double the 125 MHz (asuming it has a 50% duty cycle) quite easily, see my "Six easy pieces" in Xilinx TechXclusives. That reduces the phasing error to 4 ns. Then you must declare an error when the count reaches 11. Peter Alfke On Feb 21, 2:39 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote:> axr0284 wrote: > > Hi, > > first of all, I know that asynchronous signals are bad, etc but > > that's what i have to work with. I am using Spartan 3E FPGA. I have an > > internal clock running at 125 MHz. I cannot use any DCM for conversion > > so i'm stuck with that. > > > I get an external signal that alternates between high and low state at > > a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an > > error in external hardware that the signal is held low or high for > > more than 1/2 a cycle. I need to be able to detect this. > > > I originally thought of detecting the first rising edge,(Major issues > > with setup time can occur here) then use a counter and approximate > > that 3 125 MHz cycle should fall into the low region of the 13.56 MHz > > period. If my counter reaches 3 or 4 and the signal is still hi, then > > there is an error. I would also need to check if the signal stays low > > for longer than necessary. > > > It's not very precise thought so i am wondering if there is a better > > solution. Any idea???? Thanks a lot, > > Amish > > Key question is how much more than 1/2 a cycle is an error ? > How soon do you need to flag that as an error ? > Is jitter OK on that error signal ? > > You need to set a trip threshold, and the longer that it, % wise, > the easier it gets :) > > It's basically an XOR edge detector triggering a monostable. > > -jg
Reply by ●February 21, 20072007-02-21
axr0284 wrote:> Hi, > first of all, I know that asynchronous signals are bad, etc but > that's what i have to work with. I am using Spartan 3E FPGA. I have an > internal clock running at 125 MHz. I cannot use any DCM for conversion > so i'm stuck with that. > > I get an external signal that alternates between high and low state at > a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an > error in external hardware that the signal is held low or high for > more than 1/2 a cycle. I need to be able to detect this. > > I originally thought of detecting the first rising edge,(Major issues > with setup time can occur here) then use a counter and approximate > that 3 125 MHz cycle should fall into the low region of the 13.56 MHz > period. If my counter reaches 3 or 4 and the signal is still hi, then > there is an error. I would also need to check if the signal stays low > for longer than necessary. > > It's not very precise thought so i am wondering if there is a better > solution. Any idea???? Thanks a lot, > Amish1) How precise do you want to be and 2) is this a unique test or do you want the measurement in production? I've been playing down at this level in the Spartan 3E for a while. It can be done to extreme precision but how much pain and resource do you want to throw that direction?
Reply by ●February 21, 20072007-02-21
John_H wrote: <snip>>> It's not very precise thought so i am wondering if there is a better >> solution. Any idea???? Thanks a lot, >> Amish > > > 1) How precise do you want to be and 2) is this a unique test or do you > want the measurement in production? > > I've been playing down at this level in the Spartan 3E for a while. It > can be done to extreme precision but how much pain and resource do you > want to throw that direction?What does 'extreme precision' and 'pain and resource' equate to, on the 3E ? -jg
Reply by ●February 21, 20072007-02-21
John_H wrote:> axr0284 wrote: >> Hi, >> first of all, I know that asynchronous signals are bad, etc but >> that's what i have to work with. I am using Spartan 3E FPGA. I have an >> internal clock running at 125 MHz. I cannot use any DCM for conversion >> so i'm stuck with that. >> >> I get an external signal that alternates between high and low state at >> a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an >> error in external hardware that the signal is held low or high for >> more than 1/2 a cycle. I need to be able to detect this. >> >> I originally thought of detecting the first rising edge,(Major issues >> with setup time can occur here) then use a counter and approximate >> that 3 125 MHz cycle should fall into the low region of the 13.56 MHz >> period. If my counter reaches 3 or 4 and the signal is still hi, then >> there is an error. I would also need to check if the signal stays low >> for longer than necessary. >> >> It's not very precise thought so i am wondering if there is a better >> solution. Any idea???? Thanks a lot, >> Amish > > 1) How precise do you want to be and 2) is this a unique test or do you > want the measurement in production? > > I've been playing down at this level in the Spartan 3E for a while. It > can be done to extreme precision but how much pain and resource do you > want to throw that direction?First stab: Most people can just skip the post when their eyes start to glaze over; I'm going into detail to show what *can* be done, not necessarily to suggest this is a great way to go. The fastest routed LUT delay in the S3E is on the order of 270 ps (from -MIN timing). If an 8-LUT ring oscillator were used, the oscillator period would be a maximum of about 230 MHz or just over 16 ring oscillator periods in your 13.56 MHz period. For each half cycle, use a ring oscillator and a 5-bit combinatorial Gray code counter to count the ring oscillator half periods. If the ring oscillator is only enabled when the half cycle you're measuring begins, the ring oscillator starts oscillating and the Gray counter starts counting when you enter the appropriate half cycle. When the end of the half cycle hits, latch the count values into their embedded registers and latch a 1 in a self-reset register. Use the self-reset register to reset the ring oscillator and clear the Gray counter. When all is zero, asynchronously clear the self-reset register. The ring oscillator is disabled and held in reset until the next half period begins. End result - you can decode a binary count value from the bits you've latched independently for the two half cycles. The two values should be approximately the same and the sum of the two counts is the total ring oscillator LUT delays in a 13.56 MHz period. If the 13.56 MHz period *is* constant, the 100% point total should be roughly consistent between adjacent cycles though it may vary by many percent across temperature, voltage, and other internal influences. You can compare the two half counts to a percentage of the total to see if you're in the acceptance window or not. The 8-LUT ring oscillator can be constructed in one CLB with around 20 ps routing between LUTs (as reported by the Timing Analyzer or FPGA Editor) with judicious selection of which LUT goes where (using LOC or RLOC/RLOC_ORIGIN constraints) to access the shortest, most consistent timing. SLICE_L and SLICE_M delays vary slightly but don't impact a measurement on the order of what you're trying to achieve. The ring oscillator and the combinatorial Gray counter should be developed with great care. The conversion from the 8-bit Johnson counter (the ring oscillator) and the 5-bit half-period Gray counter is more than 2 minutes of work especially with the extra bit in the Gray counter used to reduce confusion between conflicting Johnson counts and Gray counts when they both transition about the same time when sampled. The self-reset is used to guarantee hold times between the sampling 13.56 MHz clock and the clear. What a mess, right? But, ... Your resolution could be just over 1% in the slowest device (a count of 93 for the total period). You use no DCMs. You don't even need the 125 MHz clock. You have lots of fun straining your Gray matter. - John_H
Reply by ●February 21, 20072007-02-21
Jim Granville wrote:> John_H wrote: > <snip> >>> It's not very precise thought so i am wondering if there is a better >>> solution. Any idea???? Thanks a lot, >>> Amish >> >> >> 1) How precise do you want to be and 2) is this a unique test or do >> you want the measurement in production? >> >> I've been playing down at this level in the Spartan 3E for a while. >> It can be done to extreme precision but how much pain and resource do >> you want to throw that direction? > > What does 'extreme precision' and 'pain and resource' equate to, on the > 3E ? > > -jgPrecision: better than 800 ps. Another technique could be used to approximately halve that value if needed. Pain and resource: check the other post.
Reply by ●February 21, 20072007-02-21
axr0284 wrote:> Hi, > first of all, I know that asynchronous signals are bad, etc but > that's what i have to work with. I am using Spartan 3E FPGA. I have an > internal clock running at 125 MHz. I cannot use any DCM for conversion > so i'm stuck with that. > > I get an external signal that alternates between high and low state at > a rate of 13.56 MHz with 50% duty cycle. It can happen that due to an > error in external hardware that the signal is held low or high for > more than 1/2 a cycle. I need to be able to detect this. > > I originally thought of detecting the first rising edge,(Major issues > with setup time can occur here) then use a counter and approximate > that 3 125 MHz cycle should fall into the low region of the 13.56 MHz > period. If my counter reaches 3 or 4 and the signal is still hi, then > there is an error. I would also need to check if the signal stays low > for longer than necessary. > > It's not very precise thought so i am wondering if there is a better > solution. Any idea???? Thanks a lot, > Amish >It may take less logic to shift it in, and look for three or four consecutive ones or zeros. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●February 21, 20072007-02-21
John_H wrote: <snip>> > First stab: > > Most people can just skip the post when their eyes start to glaze over; > I'm going into detail to show what *can* be done, not necessarily to > suggest this is a great way to go. > > > The fastest routed LUT delay in the S3E is on the order of 270 ps (from > -MIN timing). > > If an 8-LUT ring oscillator were used, the oscillator period would be a > maximum of about 230 MHz or just over 16 ring oscillator periods in your > 13.56 MHz period. > > For each half cycle, use a ring oscillator and a 5-bit combinatorial > Gray code counter to count the ring oscillator half periods. If the > ring oscillator is only enabled when the half cycle you're measuring > begins, the ring oscillator starts oscillating and the Gray counter > starts counting when you enter the appropriate half cycle. When the end > of the half cycle hits, latch the count values into their embedded > registers and latch a 1 in a self-reset register. Use the self-reset > register to reset the ring oscillator and clear the Gray counter. When > all is zero, asynchronously clear the self-reset register. The ring > oscillator is disabled and held in reset until the next half period begins.Interesting. and perhaps allow a 6th bit, or more, just to cover faster than expected ring osc cases. You could also make the Gray Counter saturating, so there is no confusion of '>' - otherwise a multiple of Gray cycles might get a 'pass mark'.> > End result - you can decode a binary count value from the bits you've > latched independently for the two half cycles. The two values should be > approximately the same and the sum of the two counts is the total ring > oscillator LUT delays in a 13.56 MHz period. If the 13.56 MHz period > *is* constant, the 100% point total should be roughly consistent between > adjacent cycles though it may vary by many percent across temperature, > voltage, and other internal influences. You can compare the two half > counts to a percentage of the total to see if you're in the acceptance > window or not. > > The 8-LUT ring oscillator can be constructed in one CLB with around 20 > ps routing between LUTs (as reported by the Timing Analyzer or FPGA > Editor) with judicious selection of which LUT goes where (using LOC or > RLOC/RLOC_ORIGIN constraints) to access the shortest, most consistent > timing. SLICE_L and SLICE_M delays vary slightly but don't impact a > measurement on the order of what you're trying to achieve. > > The ring oscillator and the combinatorial Gray counter should be > developed with great care. The conversion from the 8-bit Johnson > counter (the ring oscillator) and the 5-bit half-period Gray counter is > more than 2 minutes of work especially with the extra bit in the Gray > counter used to reduce confusion between conflicting Johnson counts and > Gray counts when they both transition about the same time when sampled.I think here you have jumped to sampling BOTH, in order to hike the precision from the ~4ns to the ~270ps, right ? I've often thought of doing exactly this, but wondered just how you'd 'align' the Johnson edges, with the Gray, to keep things a) monotonic and b) hopefully nominally equal in LSB step size.> The self-reset is used to guarantee hold times between the sampling > 13.56 MHz clock and the clear. > > What a mess, right? But, ... > Your resolution could be just over 1% in the slowest device (a count of > 93 for the total period). > You use no DCMs. > You don't even need the 125 MHz clock.No, but as some stage an absolute time reference might be a good idea ? I've also thought of building two of these types of circuit, and having one in a CAL phase whilst the other samples the IP, and then swap on the next cycle, (and so on). Thus you store the 93 (or 87, or 104) or whatever your CAL says is the present time-value. Have you ever tried that ? Logic has > doubled (bit it is 2-of-the-same), but you now track-out the process and temp variations. Another idea was to 'Coarse Cal', with a tapped Osc, so the CAL scheme simply tries to lock N x OscPeriod, to some reference time. -jg
Reply by ●February 22, 20072007-02-22
Jim Granville wrote:> John_H wrote: > > <snip> >> >> First stab: >> >> Most people can just skip the post when their eyes start to glaze >> over; I'm going into detail to show what *can* be done, not >> necessarily to suggest this is a great way to go. >> >> >> The fastest routed LUT delay in the S3E is on the order of 270 ps >> (from -MIN timing). >> >> If an 8-LUT ring oscillator were used, the oscillator period would be >> a maximum of about 230 MHz or just over 16 ring oscillator periods in >> your 13.56 MHz period. >> >> For each half cycle, use a ring oscillator and a 5-bit combinatorial >> Gray code counter to count the ring oscillator half periods. If the >> ring oscillator is only enabled when the half cycle you're measuring >> begins, the ring oscillator starts oscillating and the Gray counter >> starts counting when you enter the appropriate half cycle. When the >> end of the half cycle hits, latch the count values into their embedded >> registers and latch a 1 in a self-reset register. Use the self-reset >> register to reset the ring oscillator and clear the Gray counter. >> When all is zero, asynchronously clear the self-reset register. The >> ring oscillator is disabled and held in reset until the next half >> period begins. > > Interesting. > > and perhaps allow a 6th bit, or more, just to cover faster than expected > ring osc cases. You could also make the Gray Counter saturating, so > there is no confusion of '>' - otherwise a multiple of Gray cycles might > get a 'pass mark'.The ring oscillator is subject to the -MIN timing for the device; the numbers work out to 40% of the fastest (-5) speed grade. Adding an extra bit or two would increase the range to measure longer times but I'd expect the maximum counts to be about 160 for the sum of the two halves rather than the 93 or 271 for the max -4 numbers or the -MIN numbers, respectively, given what I saw as "typical" on my S3E Starter board (-4 device). There should be no part that exceeds a LUT-delay count of 271 for an 8-LUT ring oscillator in a Spartan 3E device.>> End result - you can decode a binary count value from the bits you've >> latched independently for the two half cycles. The two values should >> be approximately the same and the sum of the two counts is the total >> ring oscillator LUT delays in a 13.56 MHz period. If the 13.56 MHz >> period *is* constant, the 100% point total should be roughly >> consistent between adjacent cycles though it may vary by many percent >> across temperature, voltage, and other internal influences. You can >> compare the two half counts to a percentage of the total to see if >> you're in the acceptance window or not. >> >> The 8-LUT ring oscillator can be constructed in one CLB with around 20 >> ps routing between LUTs (as reported by the Timing Analyzer or FPGA >> Editor) with judicious selection of which LUT goes where (using LOC or >> RLOC/RLOC_ORIGIN constraints) to access the shortest, most consistent >> timing. SLICE_L and SLICE_M delays vary slightly but don't impact a >> measurement on the order of what you're trying to achieve. >> >> The ring oscillator and the combinatorial Gray counter should be >> developed with great care. The conversion from the 8-bit Johnson >> counter (the ring oscillator) and the 5-bit half-period Gray counter >> is more than 2 minutes of work especially with the extra bit in the >> Gray counter used to reduce confusion between conflicting Johnson >> counts and Gray counts when they both transition about the same time >> when sampled. > > I think here you have jumped to sampling BOTH, in order to hike the > precision from the ~4ns to the ~270ps, right ? > > I've often thought of doing exactly this, but wondered just how you'd > 'align' the Johnson edges, with the Gray, to keep things > a) monotonic > and > b) hopefully nominally equal in LSB step size.Both are sampled, indeed, making the precision a *minimum* or 270 ps but a maximum just under 800 ps with a typical -4 value being, perhaps, about 450 ps (based on my one sample of one -4 ES device). The Johnson counter is the "ruling" time stamp. Using the full Johnson count range as one period, each step in the Johnson count is 1/16 and the half-period counter give gray values in 1/2 steps. If the Johnson counter says 1/16 but the Gray counter says 5.5, the Gray gets nudged to 6.0 rather than brought down to 5.0. Care must be taken to align the uncertainties such that a disagreement between values is "obvious" as to which way to correct the Gray value. The LSB sizes are pretty darned close when the LUTs are in the same CLB and the routes are all the same, shortest length. I mentioned there's a slight difference between SLICE_M and SLICE_L LUTs bet the system ends up pretty darned consistent.>> The self-reset is used to guarantee hold times between the sampling >> 13.56 MHz clock and the clear. >> >> What a mess, right? But, ... >> Your resolution could be just over 1% in the slowest device (a count >> of 93 for the total period). >> You use no DCMs. >> You don't even need the 125 MHz clock. > > No, but as some stage an absolute time reference might be a good idea ?If you want an absolute measurement, the 125 MHz can be used as a reference to measure the ring oscillator frequency. Absolutely. The task at hand was determining when the duty cycle of the 13.56 MHz signal is out of whack; nothing absolute needed.> I've also thought of building two of these types of circuit, and having > one in a CAL phase whilst the other samples the IP, and then swap on the > next cycle, (and so on). Thus you store the 93 (or 87, or 104) or > whatever your CAL says is the present time-value. > > Have you ever tried that ?The beauty is that the same ring oscillator can feed the frequency counter. No need for an independent CAL cycle if you're interested in the average frequency. Something I'm looking at now for a different application is using a reference oscillator to drive the scale in a sing-oscillator based NCO where jitter isn't a huge concern (a couple nanoseconds are fine) but the phase needs to be agile - far beyond the capabilities of a DCM.> Logic has > doubled (but it is 2-of-the-same), but you now track-out the > process and temp variations.For applications where one ring oscillator is used for cal and another is used for strict delay rather than another ring oscillator, my concern has been that the full scale values would be off a bit because of the energy (and heating) for the CW oscillator versus the one-shot delay. It's all touchy-feely at this point without a bit of testing or specific device knowledge but the differences should be minor if everything is very close together. I just haven't tried.> Another idea was to 'Coarse Cal', with a tapped Osc, so the CAL scheme > simply tries to lock N x OscPeriod, to some reference time. > > -jgA tapped oscillator as in finely adjusting the ring oscillator? Absolutely. A combination of LUTs with different route time selections (choose the longer or the shorter route) in a ring oscillator can arrive at a closest-approximation to some M/N of the reference clock, dithering between two very close ring period values to keep the phase where it needs to be. Carry chains can also provide some tight resolution though the overall frequency can tend to increase because the carry chain starts to leave the ring oscillator's neighborhood and needs to be routed back. This is the stuff of good fun for me. It's been nice bouncing it by you, Jim. If anyone else has looked far enough into the ramblings to spark some interest, kudos! Silicon is wonderful to stretch in funny ways to think outside the sandbox. - John_H
