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
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
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?
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.
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
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'.
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.
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.
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.
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.
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.
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.
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.
A 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.
Just to clarify my details, I was not thinking of a dual Cal / SW osc, but of an Alternate scheme ( like in PAL TV's ), where you try and build two identical Oscs, and then use each one 50% of the time.
- this does imply a repetitive trigger situation (as in the OP ), and most precison delay measuring schemes are triggered in one way or another.
That means heating / thermal die slopes / etc do not matter, because you alternately cal and use each one, and at whatever the trigger rate is ( 80ns here )
Thanks for the answer everybody. It's a lot to take in for a newbie so i'll probably have to do a little research on the different stuff in John's reply but it's definitely a start. Thanks a lot, Amish
Amish, you never told us the criticality of your timing detector. If you can tolerate an 8 ns detection error, then the interesting solution suggested by John is not required. But if timing is critical, it is a really superb solution. Peter Alfke
I agree that the approach I suggested may be significant overkill. I wouldn't suggest the approach for a newbie unless desperate for precision or very confident in the ability to tackle a problem full of nuance. Many seasoned engineers still don't design with the silicon target in mind, producing quite functional but less than optimal code; often the ability to retarget the code to a different family is justification enough to not think at the silicon level. The tast I suggested - to show what precision could be obtained - keeps the silicon at the forefront of most of the coding decisions.
With 2X the 125 MHz clock Peter suggested (without a DCM!) you get good results without 2+ man-weeks of effort. If you could pull off the task I suggested in 2 days, I'd graduate you far beyond newbie. If you're interested in this type of technique for speed or precision, I'd suggest reading XAPP 671 that has a delay structure similar to the ring oscillator for high speed asynchronous data capture.
I originally thought that timing would be critical but it would seem that the error would actually cause the signal to be stuck for a longer time which makes my life easier. 125 MHz is more than enough. I did really like John's solution and I will definitely keep it in mind if a problem requiring more precision comes up in the future. Thanks again, Amish
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.