PS: Do not confuse 1 PPS (1 pulse per second) with 2 ps (2 picoseconds), which would make the PIC a 500 GHz capable device.
500 GHz capable? What are you talking about? That 2ps number is for jitter, not toggle-rate. I have no idea if 2ps number is accurate, but I do know that "van Baak" is certainly familiar with the difference.
To 5065AGuru and his 2ps PIC jitter comment:
Just to wrap your head around a 2ps jitter. Here is a 'SINGLE 28GHz D-FLIP-FLOP' whose deterministic jitter is 2ps:
HMC853LC3 ->
https://www.digikey.com/product-detail/en/analog-devices-inc/HMC853LC3/1127-1239-ND/3881936It is a 207$ part for 1 single D-flip-flop.
Whoever spouts 2ps jitter would require a testing scope fixture from Lecroy worth over 1M$ to verify this so called fact.
Unless the manufacturer of the 2ps jitter IC is at least the size of Analog Devices or Texas Instruments, and they specify the exact PCB fixture and leads required to achieve that figure & the IC is over 200$ each, it is completely bogus.
Expect a ~1ns jitter when using the PIC to divide your clock when using the cheaper PICs without the internal PLL. I suspect, but have no evidence, this figure may increase to ~1.5ns with the internal 4x PLL versions. This is assuming you drive the CLK input with a clean oscillator, not a crystal.
(Their IOs on the PIC16/18/12 series are really clean when using a dumb IO pin with nothing more than BSF, BCF or MOVWF command and you drive the CLK input pin from an oscilator. (bit set port F, bit clear port F, move Wreg to port F.))
There was a "Simple or Lowpower , cant remember which" div by 5/10 discussion on timenuts not so long ago.
The below was somehow, the condensed outcome.
I seem to remember it was for freq's up to 100MHz
/Bingo
The 74XX160/74XX162 is the decade divider that runs at maximum
clock rate for the chip. Meaning no external feedback is
necessary to make it work at divide by 5/10.
The 74XX161/74XX163 can only divide by powers of 2 at maximum
clock rate. You have to add feedback to divide by 5 and THAT
is what slows it down so much. Dividing by 10 is even slower
in most logic families.
There is also 74XX190 series.
(2). Ignoring the above (suspicious) result. Can we factually get a ball park figure on the jitter for a similar microcontroller. Apparently, yes.
Microchip do a jitter (related) application note ( http://ww1.microchip.com/downloads/en/AppNotes/00002450A.pdf ), which is for a similar (but not identical) mcu.
It gives a ballpark figure (by examining various figures in the app note), of around 10 to 20 nanoseconds.
The app note is more about the clock oscillator and stuff, so might not apply to using a timer, but I hope it will do as a rough ball park figure.
Look, I'm not defending that 2ps number (although I do believe that Mr. van Baak has some expertise in this area), but that uChip app note is, as you noted, about the jitter in the free-running R-C controlled oscillator of their part. This has virtually no relevance to the clock-to-Q timing jitter of a synchronous part like the PIC in question. These aren't even close to being the same thing -- they're not in the same universe, let alone ball park.
Look, I'm not defending that 2ps number (although I do believe that Mr. van Baak has some expertise in this area), but that uChip app note is, as you noted, about the jitter in the free-running R-C controlled oscillator of their part. This has virtually no relevance to the clock-to-Q timing jitter of a synchronous part like the PIC in question. These aren't even close to being the same thing -- they're not in the same universe, let alone ball park.
You're right, I agree. My quick skim read through that app note, missed those important facts. It was at least partly, about the internal oscillator.
When the internal PLL is used, with a crystal, I've got another ballpack figure. Via another app note,
http://ww1.microchip.com/downloads/en/DeviceDoc/93008b.pdf . This (For the faster DSpic series), seems to suggest, that when using the PLL, the clock jitter is +/- 3% of the clock frequency = 6% total.
Which would suggest (at 10 MHz), a jitter of about 6 ns. (10MHz=100 ns period, 6% of that).
So, without using the PLL, presumably it would be more like 100 ps, or 1 ns. (Presumably).
Not linked information, is that getting below 100 ps jitter, becomes extremely difficult, because the slightest voltage variation, radio signal interference, thermal noise and other random effects. Cause these (difficult to overcome), variations (Jitter).
I guess we need a
time nut metrology time expert, who works (worked) at Microchip (or similar), who can verify (or not), my/our? claims. That 2 ps, is NOT the right figure, and give clues/information as to what the jitter might be, when not using the PLL.
I was just following this thread for some reason, had a mega4809 hooked up so just tried to make a freq divider. The main clock has a divider from 1 to 64 (1 2 4 6 8 10 12 16 24 32 48 64) of which the /10 is useful for lower freqs or if you just wanted 1MHz on clkout (and just a few lines of code).
The tca timer is 16bit, and has a freq mode, so made a simple little class to set tca to output all available integer frequencies from 1Hz to 5MHz (55 total choices out of 64k). Below 80Hz the timer prescale starts to get used and the cpu div will use /10 for some of them. Not much code, and half of it is a lookup table for the values I generated (cpudiv, tcadiv, tcacmp, freq).
FreqGenerate10Mhz fg;
while( true ){
Print( oled, "\tHz: %7lu", fg.freq ); //\t is my 'home' command
while( board.sw.isOff() ){}
fg.next(); //5Mhz ... 1Hz
}
The list of available choices-
5M,2.5M,1.25M,1M,625k,500k,312.5k,250k,200k,156.25k,125k,100k,
78.125k,62.5k,50k,40k,31.25k,25k,20k,15.625k,12.5k,10k,
8k,6.25k,5k,4k,3.125k,2.5k,2k,1.6k,1.25k,1k,
800,625,500,400,320,250,200,160,125,100,
80,50,40,32,25,20,16,10,8,5,4,2,1
My meter says it works, but I have no idea how this compares to using logic ic's, and have no idea when the difference starts to matter. It is the simpler option for those that are better at mcu's than dealing with logic ic's, or at least would be the first option to try. An 8 pin avr0/1 would probably do even if a display was wanted (and leaving updi pin for only programming)- pwr/gnd/updi, scl/sda, wo0, switch, extclk. These avr 0/1 need a logic signal to use an external clock, so may still end up using a logic ic to drive a crystal if that is your source.
Even if its not good enough (however defined), it took 15 minutes to get it working and test. If it turns out it does well, then you have a 50cent mcu solution and a square inch of board space needed. If not, you lost 15 minutes of time, plus whatever time it took to test.
Maybe even just ask Tom Van Baak how he came to that figure, he's a very knowledgeable, approachable guy and he's the one making the claim.
FWIW, I'd be inclined to believe that he's damn close to being correct because the timenuts community would have called him out on it a *long* time ago otherwise.
That is an interesting comment. I will consider possibly contacting him in the future, about it.
Is he on this forum. Googling for him (here, on EEVblog forums), seems to come up (ironically) with your name and a discussion about him.
I don't seem to be able to find the post, in non-mobile format, and google insists on finding it in the 'other' area (mobile ?).
https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/155/?wap2I suspect, a decently/properly/efficiently programmed MCU (i.e. care taken to make it cycle exact and get the best out of timers and things, not using the PLL, if necessary), should give results at least as good as of the shelf, TTL (modern day equivalents), would. Hopefully even better. Because the internal logic switching speeds should be significantly faster in a MCU, compared to most general logic stuff.
Maybe even just ask Tom Van Baak how he came to that figure, he's a very knowledgeable, approachable guy and he's the one making the claim.
FWIW, I'd be inclined to believe that he's damn close to being correct because the timenuts community would have called him out on it a *long* time ago otherwise.
Also FWIW, please remember that in this case jitter has little to do with device speed or propagation time. For the picDiv, jitter will be caused by variations in internal clock-tree and CLK-to-Q prop-delay caused by internal temperature changes, and by the noise figure of the internal mosfets. The noise-figure contribution will be in part reduced by applying a fast rise-time clock input to the PIC (rather than a sinewave).
The more I consider this, the more plausible that 2ps number sounds.
Was there a reason why the 74HC4017 wouldn't work for divide-by-10 as vk6gzo suggested in #13? It has a Q5-9 output that provides a 50% duty cycle. So 10MHz in, 1MHz out. Pretty straightforward.
Was there a reason why the 74HC4017 wouldn't work for divide-by-10 as vk6gzo suggested in #13? It has a Q5-9 output that provides a 50% duty cycle. So 10MHz in, 1MHz out. Pretty straightforward.
No reason, it's a good solution for the 1/10 problem.
I emailed Tom Van Baak about the 2ps, and got this very nice reply:
Thanks for the mail. Given the recent interesting eevblog thread I will try to write something up and post the gory details. But here's a summary for you.
I chose the PIC12F675 in the late 90's because it was a ubiquitous, dirt-simple, fully-synchronous, perfect-cycle-counting MCU. Most MCU and CPU these days employ all sorts of tricks to improve net CPU performance but as a result old fashion cycle counting timing suffers. Of course real engineers would use FPGA for frequency division these days. And if anyone knows of one in a 8-pin DIP for $1, I'll switch tomorrow.
The story continues with the various TAPR pulse distribution amplifiers and then the TAPR frequency divider, which used some of my PIC dividers. In particular I designed most of the dividers to be pin-compatible with John Ackermann's (N8UR) TAPR T2-mini board, a delightful, compact, BNC-to-BNC digital frequency divider.
Since John and I are serious time nuts we were curious about the "noise" (jitter, wander, drift, etc.) that an inline divider would introduce -- not just the PIC chip itself but also the fancy input sinewave signal conditioning and the output buffer. So in 2012 I tested a pair of T2-mini using a TimePod 5330A; not a cheap instrument, and easily capable of sub-ps resolution.
Like I said, I'll see if I can write up the entire test process, but one of the plots is here:
http://leapsecond.com/pic/T2mini-jitter.png
The ADEV is about 3e-13 @ 1s and the RMS jitter is 8e-13. So that's where the "under a few ps of jitter" comment came from. Feel free to copy/paste this reply. I can follow up with more details shortly.
/tvb
www.LeapSecond.com
I think someone here owes Tom an apology...
I emailed Tom Van Baak about the 2ps, and got this very nice reply:
Thanks for the mail. Given the recent interesting eevblog thread I will try to write something up and post the gory details. But here's a summary for you.
.....
.....
Like I said, I'll see if I can write up the entire test process, but one of the plots is here:
http://leapsecond.com/pic/T2mini-jitter.png
The ADEV is about 3e-13 @ 1s and the RMS jitter is 8e-13. So that's where the "under a few ps of jitter" comment came from. Feel free to copy/paste this reply. I can follow up with more details shortly.
/tvb
www.LeapSecond.com
I think someone here owes Tom an apology...
Allan Deviation ->
https://en.wikipedia.org/wiki/Allan_variance is not the same as 'Deterministic Jitter' or absolute Jitter which are what's relevant when going from 10MHz to 1MHz. When going from 10MHz to 1KHz or less, the Allan Deviation figure becomes more relevant. Just look at the Allan graph, as you go from .01s up to 100s, notice how the jitter on the plot drops? How can that be possible unless you are not actually measuring the jitter noise output of the pin referenced to the 10MHz input, but, measuring the jitter VS frequency? At any frequency output, the pin jitters and it's 'Deterministic Jitter' will remain the same no matter what spectrum of time you analyze it's output at.
For god sakes, the 'Timepod5330A' test instrument used to measure the PIC's output is a 30MHz spectrum analyzer. Of course it cannot measure the PIC CLK input pin to - IOpin Jitter in any way, it only measures the average output frequency gathered over 10 minutes using only 126K sample points and can deliver an RMS Jitter reading based on the quality of the source clock feeding the PIC since the PICs output pin and clk timing is beyond the instrument's bandwidth capabilities, the output will look as good as the source feeding the PIC.
The PIC outputs are clock D-Flip-Flop latched to the CLK input on the cheap old PICs without any other circuitry in the way. Since the 1Hz code uses no peripherals in those old PICs and it only feeds that 'D-flipflop' input a high and low once in a blue moon, after all the time, that Allan Deviation with reference to the main clock input will look damn near perfect as it is virtually perfect. It's similar to a 74AC74 D-Flipflop clocked at 10MHz, except the PIC's CLK input is also amplified since it was designed to accept a crystal oscillator input.
You need a good 5-20Gsps scope triggered on the PIC's clk input & IO pin, reading an IO pin cycling as fast as possible, and over trillions of samples, not 126Kpoints, measuring the Tmax-Tmin delay on the 50% rise and fall of the IO pin & you will get the Absolute Jitter of the PIC's IO pin VS CLK input, and, it is not as tiny as 2ps, this I can guarantee.
The Allan deviation test and setup chart only says that the PIC can divide the CLK input by 10 million perfectly and that the
RMS jitter over
10 minutes as per spec on the provided graphic is 2ps. The response of the PIC's clk input and IO rise and fall time relationship is outside the domain of what a '5330A Programmable Cross Spectrum Analyzer' was designed to measure, IE, except for the output being a square wave, you will be measuring the quality of your source clock you are feeding the PIC.
Suggesting a "solution" needing software development (not a lot), a programming and debugging environment, programming/burning hardware etc. instead of just buying a 25 cent part with far superior timing characteristics (74HC390) and just using it 'as is' is "better"?
Wow. I see parallel universes that seem to consist of pull-down menus, PIC and ATMega brainwash.
If those contributors worked with me, they'd be fired on the spot. Just throwing any 8-pin MCU at any problem is not engineering to me.
Sorry, had to get that off my chest.
I'm guessing you don't ever use FPGAs, preferring football field size PCB layouts and shipping container size nuclear reactor PSUs.
Good for you, I like people who can live in the past.
Can you read? I only said that the knee-jerk reaction of selecting an MCU for a problem that a single standard logic IC can solve just as well is overkill. I work with FPGAs and MCUs myself, but apply them where they belong. Don't troll.
Why do you think I'm a 'guy'? And you apparently still can't read.
Says the guy who suggested anyone who wanted to use a micro 'isn't engineering' and should be sacked.
Seriously, that is some new level of gatekeeping that should be called out. I've seen managers bully people in a similar manner, end result: the best engineers quit, the "cogs in the machine" stayed, which I guess is what they wanted anyway.
Why would you introduce a counter, when a simple single transistor 1 MHz oscillator can be injection locked to the 10 MHz source? An injection locked oscillator is the easiest job in the solar system.
I would like to see that "fleshed out" - I've never heard of an injection locked divider, and a quick look around suggests that they need at least two transistors, inductors, and a sinusoidal input. (does the OXCO mentioned by the OP provide a sine wave?)
Not that a tuned transistor circuit will necessarily come out cheaper or smaller than a chip (or a microcontroller, for that matter.)
My understanding of his code is that it doesn't use PLL or timers (can't remember if they're even available on the PIC chips he used, 12C508 I think) so they can't add to the jitter, instead I think it relies on cycle exact code.
I'm mired in some STM32 code while attending a virtual radio convention and it's been a while since I looked at PIC .asm so I'm not going to dig into it but the code is nice and simple, it's available for download on his website (1) and its performance has been widely discussed on the Timenuts mailing list, there has been quite a bit of discussion as to why the dirt cheap, simple architecture of the 8 bit PIC chips can make accurate, low jitter divider so well.
The take away is that it's good and well regarded by people who chase parts per billion accuracy and notice jitter at levels most of us just don't care about.
TimeNuts list archives are searchable on the web, febo.com (2) to dig through for the aforementioned discussions.
(1) http://www.leapsecond.com/pic/picdiv.htm
(2) http://lists.febo.com/pipermail/time-nuts_lists.febo.com/
Thanks for the nice reply. It has taken me a while to go through the links, and look at some of the stuff.
There is a lot of information/posts in those threads.
To everyone:
This Jitter thing, has turned out to be way more complicated, than I was expecting. But I'm learning new stuff, and it is fun and interesting.
The following app note, seems to explain about the terminology surrounding jitter, and goes into details about some of it:
https://www.nxp.com/docs/en/application-note/AN4056.pdfIt seems that for every new thing about jitter, I'm learning/understanding in this thread. I'm also realising that there are another two things that I DON'T understand about jitter.
tl;dr
If I appear to have gone relatively quiet in this thread, it is because I come to the realisation that there is much for me to learn about jitter. Before potentially making a fool of myself, and attempting to tell others, how/why jitter works the way I thought it did.
Here is TI's own measurements of a simple modern 3.3v CMOS 74LVTH125 buffer capable of over 100MHz:
It has a 102ps jitter. I would expect an older half-speed 5v 74AC125 to have a 204ps jitter. An old PIC probably cannot do better than 204ps, however, with an entire CPU inside on a die, let's give them the benefit of the doubt and say a 200ps output jitter and my scope measurements in the past with that 1ns jitter noise was inside the error of my 500MHz, 5Gsps setup and PCB noise circuitry.
200ps is 2 orders of magnitude worse than 2ps.
To everyone:
This Jitter thing, has turned out to be way more complicated, than I was expecting. But I'm learning new stuff, and it is fun and interesting.
When looking at jitter in these circumstances, remember, there are 2 different issues which have been tackled in this thread and mixed up erroneously.
When you look at CLK jitter on these MCU's data sheets, they are talking about their circuitry's capability of generating a pure clock from a crystal with all their inherent flaws/noise/jitter introduced by many local signals and loads switching throughout the MCU and adjacent pins and power supply noise. Things get even worse when you look at these MCU's built in oscillators which are usually RC based.
What the OP asked for is a 10MHz divider where we are assuming that his 10MHz source is perfect.
Force feeding any of these MCU's CLK input with a perfect 10MHz external clock source, defining how sub-nanosecond timing response of the MCU's core and switching speed of the output pins in relation is actually not defined in the data sheets you are looking at. The closest to thing to this is my old measured 1ns jitter noise on the scope with an old PIC16C/18F series MCU.
This brings us to Allan Deviation measurements. Think about this one carefully, if I have a 1Hz square wave coming out of a PIC & measure it for 10 minutes as in the provided chart,
IE 600 cycles. How is it possible to determine 2ps deviation on that IO pin with only 600 transitions compared to the 10MHz source?
The 2ps Deterministic Jitter of that Analog Devices HMC853LC3 D-flifflop was measured running at 25GHz with an Agilent 86100C 33GHz DCA, a scope shot in the data sheet which had to run billions of clock cycles to achieve that 2ps measurement. To analyze a PIC output running at 1Hz with the same fidelity, you would not achieve this mark in 10 minutes, but, you would need to run the analysis for around 792.7 years. 600 cycles of the IO pin, twice a second is not enough to tell you the true extent of the PIC's CLK input to an IO output. And what's worse is that the Allan Deviation is a RMS figure not showing you any spurious peaks. Allan Deviation is a measurement of the quality of a clock for it's total frequency and measuring 1Hz, it's tough to find noise unless your 1Hz source is a true sine wave free of distortion.
>I have a few Tektronix TM500 modules that require a stable 1MHz frequency source for testing and calibration.
If your source is a 1 million pico second clock, how would pico seconds in double/triple digits even enter the picture? How can any instrument that takes 1MHz as a timing source be affected by these small jitter values? If they can, then does that mean you can use them to measure ps (I suspect not)?
Maybe worrying about ps jitter is not necessary when you are a mile away from it, and using pretty much anything to divide 10 to 1 will work equally well. I don't know.
Build one of each version, and report back.
If you want to maintain a 1:1 mark/space on the output, then you need to connect it so that the divide by 5 stage is followed by the divide by 2 stage.
That sounds logical, but then the two stages are different.
I think it's better to have both stages divide by the sqrt(10).
I have gotten pretty good results by estimating jitter from the transition time and supply or ground noise which changes the threshold voltage. The problem is that the transition time of internal nodes may not be known, but it can be roughly calculated for a given process by measuring jitter in a simpler device.
Usually though, I just do not care because I know single ended logic produces jitter from 10s to 100s of picoseconds just from the above source. If I want low jitter, then I use differential signaling to remove the effects of supply and ground noise (ECL) or I carefully decouple and regulate the supply voltage of simple single ended logic. Complex logic is never a place to look for low jitter.
>I have a few Tektronix TM500 modules that require a stable 1MHz frequency source for testing and calibration.
If your source is a 1 million pico second clock, how would pico seconds in double/triple digits even enter the picture? How can any instrument that takes 1MHz as a timing source be affected by these small jitter values? If they can, then does that mean you can use them to measure ps (I suspect not)?
Maybe worrying about ps jitter is not necessary when you are a mile away from it, and using pretty much anything to divide 10 to 1 will work equally well. I don't know.
Build one of each version, and report back.
I'm not the one talking about jitter here.
I just want to divide 10MHz down to 1MHz in a way to be 'good enough' for my TM500 modules, 6 to 8 display digits depending on specific module etc.
>I have a few Tektronix TM500 modules that require a stable 1MHz frequency source for testing and calibration.
If your source is a 1 million pico second clock, how would pico seconds in double/triple digits even enter the picture? How can any instrument that takes 1MHz as a timing source be affected by these small jitter values? If they can, then does that mean you can use them to measure ps (I suspect not)?
Maybe worrying about ps jitter is not necessary when you are a mile away from it, and using pretty much anything to divide 10 to 1 will work equally well. I don't know.
Build one of each version, and report back.
I'm not the one talking about jitter here.
I just want to divide 10MHz down to 1MHz in a way to be 'good enough' for my TM500 modules, 6 to 8 display digits depending on specific module etc.
LOL, the 74HC4017 decade counter will be all you need. Ignore the rest of this thread...
Tie the CLK to the CLK input, turn on the enable (CE), GND the reset & use the 'TC' (ten count) output as your 1 MHz output.
The simplest method to me for a 10MHz to 1MHz divider is a single 74HC390, but if I am going to get a PCB made anyway, and I have a tube of 25 Hitachi chips sitting right beside me that I bought for 370yen, I may as well add a few extras to get some more frequency options. It's not like I'm spending much cash to do so when they cost me 15 cents a pop...
I remember when 370 Yen was US$ 1.03.
A 74HC390 or other 10:1 logic IC is an easy solution (and unlike a locked multivibrator, won't drift out of lock with aging), but a MCU or FPGA could be the best solution if the parts are already there and have spare pins/storage space, or added functionality is desired.
