Hi!

Try TVB's picDiv at http://www.leapsecond.com/pic/picdiv.htm

Edésio

On Wed, Jan 13, 2016 at 09:22:09AM +0000, Jerome Blaha wrote:

Tom Van Baak has developed dividers based on simple PIC chips that will
produce 1 PPS from several input frequencies.  These dividers have
remarkably low jitter, down in the couple-of-picosecond range, and are
very simple.

I've implemented life support circuitry around two versions of Tom's
code, both available as kits from TAPR:

The TADD-2 is a 4x6 inch board with 6 BNC outputs, each of which can be
set to provide 1, 10, 100, 1K, or 10K PPS from either a 5 or 10 MHz input:
http://tapr.org/kits_tadd-2.html

The T2-Mini is a tiny board with a single input and output.  The default
firmware allows PPS output for 1, 2.5, 5, or 10MHz input:
http://tapr.org/kits_t2-mini.html

Both of these devices have a low-jitter sine-to-square converter on the
input, and work over a wide input amplitude range, so just about any
sine wave will drive them.

John

On 1/13/2016 4:22 AM, Jerome Blaha wrote:

Sounds like a PICDIV is just about right:
http://www.leapsecond.com/pic/picdiv.htm

Ole

On Wed, Jan 13, 2016 at 10:22 AM, Jerome Blaha jblaha@polariswireless.com
wrote:

If anyone is interested in the equivalent functionality using an ATTiny25 (for instance, if you’re already heavily invested in AVR instead of PIC, like I am), ping me. I’ve privately written code to solve almost the same problem and it could easily be adapted into doing the same job.

Just shy of a half dozen folks have asked, so I'll post here as soon as I finish cleaning it up. I'll put it on Github when it's ready. I just need a day or two.

Sent from my iPhone

The code is at

https://github.com/nsayer/GPS-disciplined-OXCO/blob/master/tiny_divider.c

It’s a first cut. The code at the moment will just divide the input clock by 10 million, so you get a 1 PPS 50% duty square wave out. It should run on any ATTinyx5 model - it certainly will fit on at ATTiny25 if you wish.

I’ve not exhaustively tested it yet. I need to feed it into my TIA to make sure it’s exactly 1 Hz - it’s conceivable I’ve committed a fencepost error that would make it off enough that my scope can’t tell (my TIA is busy at the moment).

I believe the code won’t do the math properly below 10 MHz. You’d need to select the next lower prescale setting and change a couple of the formulae, but I don’t foresee an issue with doing so.

I’ll come back with an exhaustive test report (and any bug fixes) when I get my TIA back from GPSDO ADEV duty. :)

Nick, can the Attiny25 divide down a 20Mhz input. I understand the 12fxxx pics max out at 20Mhz on a input so not sure if they would be suitable for my purpose. Can't seem to find anything in the datasheet for the tiny that explains the maximum frequency on a input pin.

-=Bryan=-

Hi

The way pretty much all of these work is to take the “10 MHz” in on the clock input port.
The critical spec is the upper frequency for an external clock input. With some chips this
is in the vicinity of 50 MHz. On others it tops out at 4 MHz.

The next step after wiring it up is to check the jitter on the resulting output. It would be
nice if all input circuits were designed equally well. There is evidence out there that this
is not the case…..In some cases the performance can be improved by feeding the MCU
input with a high slew rate signal rather than a sine wave. About all that takes is a single
gate.

Bob

I'm curious if that code will perform the intended function (down to the clock cycle) when compiled. A check in the simulator would be a good idea while the TIA is busy.

If it doesn't give you the performance you are looking for, try programming it in assembly, as was done for the PicDiv.

Dan

I did a test last night (I accidentally bonked the device I was testing and it sort of went nuts, so I had to start it over) and found and fixed a fencepost bug. After that, it was accurate down to the limits of my TIA (something like the 10s of ps range). My test methodology was to feed 10 MHz from one of my GPSDOs into the TIA reference and the same 10 MHz into the device input. I then had the TIA perform period measurements with a 10 second gate. The result was 1 second, ± maybe a dozen or two ps on average, but again, that’s where the limits of my TIA (Keysight 53220A) lie.

The whole point of using the timer subsystem the way I am is so that you don’t have to care about the instruction timings. As long as the code is quick enough not to overrun any interrupts, it’s all good. And by using the timer prescaler, you have pretty good assurance that that’s the case.

I was thinking to make a frequency divider by using FPGA. Here is my
attempt to implement it using VHDL.
This is frequency divder plus D flip-flop which I was planed to use as
source of 60Hz for my Telechron clock.
However I never implement it in HW. Instead I was using STM32F4 with its
timers.
The purpose was to divide 9.8304 Mhz OCXO output by 81920 to get 60Hz
and use the D flip-flop to keep output in sync.
Some day I'll return to this with my soldering iron in hands. ;-)

-- Company:
-- Engineer: V.P.

-- Create Date:    17:58:43 11/09/2015
-- Design Name:
-- Module Name:    freq_div - Behavioral
-- Project Name:
-- Target Devices:
-- Tool versions:
-- Description:

-- Dependencies:

-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity freq_div is
Port ( clk_in : in  STD_LOGIC;
rst : in  STD_LOGIC;
clk_out : out  STD_LOGIC);
end freq_div;

architecture Behavioral1 of freq_div is

signal prescaler : integer range 0 to 81919 :=0;
signal clk_out_i : std_logic;

begin

gen_clk : process (clk_in, rst)
begin  -- process gen_clk
	if rst = '1' then
		clk_out_i   <= '0';
		prescaler   <= 0;
	elsif rising_edge(clk_in) then   -- rising clock edge
		if (prescaler = 81919) then
			prescaler   <= 0;
			clk_out_i   <= not clk_out_i;
		else
			prescaler <= prescaler + 1;
		end if;
	end if;
end process gen_clk;

clk_out <= clk_out_i;

end Behavioral1;

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity d_ff is
Port ( d_clk_in : in  STD_LOGIC;
d_rst : in STD_LOGIC;
D : in  STD_LOGIC;
Q : out  STD_LOGIC
);
end d_ff;

architecture Behavioral2 of d_ff is

begin

d_ff_clk : process (d_clk_in, d_rst, D)
begin  -- process d_ff_clk

	if ( rising_edge(d_clk_in) ) then  --This makes the process 

synchronous(with clock)
if(d_rst = '1') then
Q <= '0';
else
Q <= D;
end if;
end if;
end process;  --end of process statement.

end Behavioral2;

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use work.all;

entity Z1 is
Port ( z1in : in  STD_LOGIC; -- clk_in
z2in : in  STD_LOGIC; -- reset
z1out : out  STD_LOGIC -- Signal Out

 );

end Z1;

architecture SOut of Z1 is

component freq_div is
	Port ( clk_in : in  STD_LOGIC;
        rst : in  STD_LOGIC;
        clk_out : out  STD_LOGIC
	);
end component;

component d_ff is
	Port ( d_clk_in : in  STD_LOGIC;
		  d_rst : in STD_LOGIC;
        D : in  STD_LOGIC;
		  Q : out  STD_LOGIC
	);
end component;

signal wire: std_logic;	-- put signal to "wire" or use it as a "wire"

begin

u0:
freq_div
port map (
clk_in => z1in,
rst => z2in,
clk_out => wire
);
u1:
d_ff
port map (
d_clk_in => z1in,
d_rst => z2in,
D => wire,
Q => z1out
);

end SOut;

On 2016-01-13 21:35, Nick Sayer via time-nuts wrote:

--
WBW,

V.P.

For the AVRs I generally use (including the ATTinyx5s the subject here), it’s 10 MHz if you’re running at 3.3 volts and 20 MHz at 5 volts.

My testing last night (I described the methodology elsewhere) went to the limits of my TIA. The output from my GPSDO is a square wave, so I didn’t condition the input. In the past what I’ve used for that is a DC blocking cap, followed by a Thevenin termination (100Ω to ground and Vcc) feeding a 74LVC1G17 Schmitt trigger buffer. I don’t know if that’s up to Time Nuts standard or not. The one downside I’ve seen with it is that it kind of requires a larger input amplitude than is sometimes convenient.

On Wed, 13 Jan 2016 14:31:25 +0100, Ole Petter Ronningen wrote:

Ulrich B made an AVRDIV, for those who use AVR's (bottom of page)

http://www.ulrich-bangert.de/html/downloads.html

/CFO

Am 14.01.2016 um 15:50 schrieb Vlad:

A year or 2  ago, I have posted a VHDL solution here that fits into half
a Xilinx
Coolrunner 2C64A-5. When the input clock is pretty (50% duty cycle) it
runs at
200 MHz in. (tested)
The 2C64 does not take a lot of space:

<
https://picasaweb.google.com/lh/photo/4Bpcfouj8WH0shNGIyuVUtMTjNZETYmyPJy0liipFm0?feat=directlink

The bottom row of test circuits are a 100->200 MHz doubler and a
200->400MHz doubler
with a wide SAW filter to kill the harmonics.

Since the 10811 oven is so big, the Coolrunner will find a niche on the
universal VCXO carrier board I talked about 6 Weeks ago. Also, Charles
Steinmetz' version of the Wenzel and the LT limiter, so we can compare
them easily.

I have chosen to use W.J. Riley's ring mixer PLL and not the AD9901, no
point to
re-invent the wheel. But that will cost the ability to lock on external
1pps; only
lock to external 10 MHz is provided.

BTW. I have coded an AD9901 work-alike in VHDL that could also fit into
this
Coolrunner, but it was never tested because we have solved our problem
otherwise.

regards, Gerhard

I and others have written divider routines in assembler for the ATtiny25
etc.  The version I have is crude but divides by 10, 100, and 1000.  I
also have a version that divides by 1E4, 1E5, and 1E6.  I also have a
version that generates 3 pps outputs, one with a 50% duty cycle plus
positive and negative short duration pulses.

All three sync up to the 10 MHz clock using a pps input.  The sync takes
about 2 to 3 s, is within several clock cycles (adjustable) but always
has one clock cycle  uncertainty.  Basically we look for an interrupt on
the pps input and if one occurs we poll the pin to find the next one.
This leads to the one cycle uncertainty.  I tried interrupts but had
more variance than polling - ymmv. If there is no pps interrupt the wdt
times out and we jump into the main loop.

I'm working from memory but I seem to recall there's several ns
variation between the three outputs and they change about 14 to 16 ns
after the clock.

I'm happy to email the assembler code to anyone who wants to start from
it.  Its crude and will need testing/tweeking.  I have several chips in
use that work well but I just changed a few things and have not burned
and tested the changes in a circuit.

Drop me a line if you want the sources.

bob

On 1/14/2016 7:20 AM, Daniel Watson wrote:

Nick wrote:

You will get less jitter (as well as more sensitivity) if you use a
buffer without a Schmitt input (it should also be "native" CMOS --
with an input threshold of 1/2 Vcc -- not CMOS with TTL input
thresholds).  For best performance, the input signal should be scaled
to drive the buffer input quite close to both logic power supply
rails.  You can use Shottky diodes (1N5711, 1N6263) to clamp the
buffer input to 0 and Vcc if necessary (I would include such diodes
as a best practice, even if I did not expect input excursions beyond
the rails).

Best regards,

Charles

For lowest jitter the gate power supply noise needs to be very low.Biasing the input at 50% supply helps somewhat but the gate threshold is never exactly 50% and the low pass filtering effect of the coupling capacitor increases the contribution of power supply noise to jitter.
A power supply noise below 10nV/rtHz is probably required to achieve the lowest jitter. Few regulators achieve this particularly at low frequencies.

Bruce

On Friday, 15 January 2016 8:10 PM, Charles Steinmetz <csteinmetz@yandex.com> wrote:

Nick wrote:

You will get less jitter (as well as more sensitivity) if you use a
buffer without a Schmitt input (it should also be "native" CMOS --
with an input threshold of 1/2 Vcc -- not CMOS with TTL input
thresholds).  For best performance, the input signal should be scaled
to drive the buffer input quite close to both logic power supply
rails.  You can use Shottky diodes (1N5711, 1N6263) to clamp the
buffer input to 0 and Vcc if necessary (I would include such diodes
as a best practice, even if I did not expect input excursions beyond
the rails).

Best regards,

Charles

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

On Thu, 14 Jan 2016 09:50:15 -0500
Vlad time@patoka.org wrote:

Nice!

As side note: when using an FPGA anyways, it might be good to use
something like a lambda divider [1,2].

I'm not so sure whether their explanation why this improves the noise
floor is the right one, but it definitly helps and is quite easy to
implement.

		Attila Kinali

[1] " The sampling theorem in Pi and Lambda dividers", by Calosso, Rubiola, 2013
http://rubiola.org/pdf-articles/conference/2013-ifcs-Frequency-dividers.pdf

[2] Slides to the above
http://rubiola.org/pdf-slides/2013C-IFCS--Dividers.pdf

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson

On Friday, January 15, 2016 12:13:47 PM Attila Kinali wrote:

A lambda divider is only useful when one wants a sinewave or a triangular wave
output. In the case of a CMOS divider It reduces output noise by averaging the
upconverted supply noise produced by sampling the supply noise at different
phases of the output signal period. When upconverted power supply noise
dominates merely paralleling outputs that sample the power supply noise at the
same time will have little discernable effect on the output noise.

Bruce

Am 15.01.2016 um 10:14 schrieb Bruce Griffiths:

I have recently measured the noise of some regulators, LEDs and Zeners
with partly unexpected results.
I'll do a write-up and put it on my web site, but here are 3 pictures
that already tell a lot:

Zeners:

<
https://www.flickr.com/photos/137684711@N07/24411798996/in/album-72157662535945536/

Note the low 1/f corner of the BZX84 C2V7 and 3V3.
And 0 dB is the noise of a 60 Ohm resistor, or the INPUT referred noise
of an AD797 or LT1028.

LEDs abused as References:

<
https://www.flickr.com/photos/137684711@N07/24354944411/in/album-72157662535945536/

The Avago HLMP-6000 is the clear winner in terms of noise. Optically,
it's quite dim.

Regulators:

<
https://www.flickr.com/photos/137684711@N07/24070698809/in/album-72157662535945536/

The clear winner here is the LT3042. Now if they made it in an
acceptable package!
I mounted the MSOP-10 dead bug style on unetched FR4, soldered a thick
1mm Cu wire across
the exposed pad and put the rest of the circuit on raster board. That
was no fun, even under the
microscope.

BTW the extra quiet reference of the LT3042 is a current source, so
there is no
real justification for the repeated claims here that ECL must be noisy
because of
its integrated current source.

Batteries:

I have done the writeup already:
<
http://www.hoffmann-hochfrequenz.de/downloads/NoiseMeasurementsOnChemicalBatteries.pdf

and since we are at it:  Lab supplies

<
http://www.hoffmann-hochfrequenz.de/downloads/Noise_Measurements_On_Some_Laboratory_Power_Supplies.pdf

(still incomplete, but no longer high priority for me)

regards, Gerhard

In message 569BC23A.3030400@arcor.de, Gerhard Hoffmann writes:

This is one of the most stupid ideas ever, because LEDs works both ways.

(Back when LED wrist-watches first came out, people soon discovered
that they would reset themselves when photographed with flash.)

If you insist on using LEDs as voltage references, the first thing
you need to do is to dip the LED in something which shields it 100%
from incoming light including infrared

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

On Sun, 17 Jan 2016 17:32:58 +0100
Gerhard Hoffmann dk4xp@arcor.de wrote:

Thanks a lot! This is some very valuable data.

If you could note also the exact circuits you used, that would help
to compare the circuits.

		Attila Kinali

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson

On Wed, 13 Jan 2016 09:22:09 +0000, Jerome Blaha wrote:

Ulrich B. has made an AVR 1PPS, for those that uses AVR's instead of PIC's
AVR PPSDIV 2008-09-06 - in bottom of page.
http://www.ulrich-bangert.de/html/downloads.html

The Mega8 version should be easy to port to an Arduino clone

CFO

Hi

Back in the 70’s I was involved in making LCD watches. The whole “photo”
issue had not been fully through through. One day our chief marketing guy for
the project was driving around in Phoenix AZ. He looks down and notices that
his watch is dead. Pops out a spare, puts it on, confirms it it working. Hangs his arm out
the window and …. that one is dead as well.

We changed the die coat on the ASIC to an opaque version soon after that …

Light does indeed interact with semiconductors. It happens even on circuits that
you would not think are photo sensitive. Physics is nasty that way ….

Bob

You might have come across the Raspberry Pi story : one of the revised
versions had a SMPS control chip that was intended to be buried inside a
phone, not exposed on an open pcb.

https://www.raspberrypi.org/forums/viewtopic.php?t=99042

On Mon, Jan 18, 2016 at 3:11 PM, Bob Camp kb8tq@n1k.org wrote:

Looking to the complex solutions for the frequency divider (CPLD/MCU), I
start to think about skews and propagation delays. Its not obvious from
the first glance. But I think such things exists.
It could be interesting to compare the numbers.  Is it worth to consider
some correction to avoid phase difference between of input and output ?

On 2016-01-18 08:59, cfo wrote:

--
WBW,

V.P.

Indeed Bob in the 70s I built a failure diagnostic equipment to record the
Idd of a chip as a function of a position of a spot of light scanning the
surface. The intensity was very low and not optimum wavelength.......it was
a scope raster demagnified by using a microscope camera accessory backwards.
The intensity was modulated and the signal detected on a PSD and displayed
on a modified Robot SSTV receiver.....but it showed just how senstive chips
are to light.

Alan
G3NYK

----- Original Message -----
From: "Bob Camp" kb8tq@n1k.org
To: "Discussion of precise time and frequency measurement"
time-nuts@febo.com
Sent: Monday, January 18, 2016 3:11 PM
Subject: Re: [time-nuts] Generating a solid PPS from 10Mhz source

Hi

The same issue come into random logic. The most common chip logic way to do this is with rippling
divide by 10’s.  Been there / done that.. The output pulse in that case is delayed  by quite a bit. Put
a “sync” flip flop on the output and the (obvious) question is — do you know the delay is << 100 ns?
When it’s not, you start doing full up programmable dividers …. you then have a Fmax question.

The nice thing about a FPGA (or CPLD) is that they come with a cute timing analyzer. You can indeed
answer questions like this with a quite high level of confidence. That assumes that you bother to set
up the timing analyzer :)

With an MCU, you have pretty good information on the output delay. The ambiguity comes on the clock
input. It’s rare to see that fully documented. You are then back to a “measure it and see” situation. You
probably could guess that the input delay and output delays relate to the clock delay.

Regardless of the divider it’s self, you will have the sine to square conversion. You also
may have a sensitivity on a square back to sine conversion. All of it (and the divider) will have both temperature
and voltage sensitivity. Most of that will be in the “measure it and see” category.

Based on measurements, all of it comes out in the “no big deal” range for normal applications.

Bob

On Monday, January 18, 2016 11:45:00 AM Poul-Henning Kamp wrote:

Actually when forward biased they are not that sensitive.
I used a string of forward biased LEDS to set the voltage of a node in an
amplifier. To detect 100Hz modulation due to photocurrents in the LEDs the 150W
incandescent bulb had to be placed within a few cm of the LEDs.
Using a little bit of opaque pain or epoxy is a small price to pay.
Photosensitivity is also an issue with glass encapsulated low leakage diodes
if you scratch  the paint.
Even glass encapsulated reference (and other) zeners are photosensitive.
For sensitive measurements a light tight enclosure is often used.

Bruce

In message 29659871.S9XTlaFu4r@linux, Bruce Griffiths writes:

Incandescent bulbs don't have much "hum" in their light output,
they're basically heating elements and they don't cool down nearly
fast enough.

Try with fluorescent light instead, there's a reason people accuse
them of flickering.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Hi,

No, the black plastic around ICs isn't black by chance.
Einstein got his Nobel price on the photoelectric effect, which is
relevant in this case.

A few years ago I assisted in modifying a camera for an amateur
astronomer. Among the modifications, one was to turn of power for a
pre-amplifier, as the biased amplifier was also emitting a faint
infrared light that the sensor picked up and accumulated causing a
redish gradient over the whole screen - mathcing the radiation pattern
from the on-chip amplifier. By only powering on the amplifier before
read-out significantly reduced the effect to essentially zero.

Cheers,
Magnus

On 01/18/2016 04:11 PM, Bob Camp wrote:

Hi

Some time - check out what a “60 Hz” incandescent bulb looks like when
hooked to 20 Hz …. flicker flicker flicker …

I suspect they optimize the thermal mass of the filament to reduce the flicker at
50/60 Hz.

Bob

On Mon, 18 Jan 2016 20:45:20 +0000, you wrote:

Hook photocell to an audio amp and shine a 60Hz powered lamp on it; you'll
be surprised.  I don't know what the modulation percentage is, but I know a
flashlight lamp can be modulated with decent sounding speech audio.

--
Gary Woods AKA K2AHC- PGP key on request, or at home.earthlink.net/~garygarlic
Zone 5/4 in upstate New York, 1420' elevation. NY WO G

On Monday, January 18, 2016 08:45:20 PM you wrote:

150W

Its actually quite difficult to find low frequency operated fluorescent lamps
here. I only have a small 6" one (sans phosphor so strictly not fluorescent)
I assembled some years ago as a source of the mercury green line for an
interferometer. I'll unearth it and setup an experiment using forward
biased LEDs.

In any case obtaining an LED photocurrent of more than few microamp is
very difficult. With a forward current of a few mA the resultant change in
LED voltage will only be a few uV.

Shielding the LED to  ensure that such photocurrent induced modulation
of the forward voltage drop is at the subnanovolt level is relatively simple.

I used to test the suitability of photomultiplier housings by checking for
light leaks with a 1 KW incandescent lamp using the photomultiplier as the
light detector. Labyrinth seals with nested enclosures with everything
painted matte black usually sufficed.

Biggest problem was light leakage via the BNC/MHV connectors.

Bruce

On 1/18/16 4:19 PM, Bob Camp wrote:

They optimize that to a tiny fraction of a gnat's eylash.  Mass
production, every microcent counts.

That true. Its nice looking "Timeng report". I saw the numbers there.

Performance Summary for Xilinx XC32C32A:

Min. Clock Period 3.300 ns.
Max. Clock Frequency (fSYSTEM) 303.030 MHz.

Clock to Setup (tCYC) 3.300 ns.
Clock Pad to Output Pad Delay (tCO) 3.700 ns.

Its always few nanoseconds delays. Which quite sad, since I was expect
better from CPLD. With this "background", PICDIV looks much more
attractive with its 2ps Jitter.
Long live for Tom and Microchip engineers !

D flip-flop looks like a good solution. However, now I am thinking it
could do its own "timing correction" (skew/delay) to the signal. Looks
like "classic" 74LS74 has similar delays as CPLD has.
Nothing is perfect. ;-)

I was using Wenzel "two 3906" solution. BTW, when I compare it to
"74AC", I saw more spikes with it:

http://www.patoka.ca/OCXO/Vectron-74AC04b-2-OSQ.png
http://www.patoka.ca/OCXO/Vectron-74AC04-2-OSQ.png

Which make me thinking that 74AC/74HC logic make the conversion more
"smooth". However, in my observations, I saw that "two 3906" is close to
reflect the actual signal coming from OCXO. I mean if OCXO has some
spike (noise), than it immediately will be noticed by "two 3906" schema.
74AC/74HC solution somehow remove/ignore it. I don't know how to explain
this. Its just from my setup and my observation and probably not correct
at all.

--
WBW,

V.P.

The clock to output delay of the PIC will be similar or perhaps a little
worse.
You seem to be confusing delay and jitter.
There are zero delay buffers (in the sense that the output transitions are
aligned with the clock transitions) but these have excessive jitter due to the
internal DLL used to achieve 'zero delay'.

Bruce

On Tuesday, January 19, 2016 03:37:13 PM Vlad wrote:

Hi

If you fire up the FPGA and measure it, you will find a sub picosecond jitter on a signal passing through it.
If you use the internal PLL or DLL in an FPGA, you might indeed see close to 1x10^-12 ADEV in some cases.
In general you should be able to get into the parts in the 10^-13 range even with an internal FPGA PLL.

Delay wise, you have the advantage on the FPGA that the “internal” gates are running 100’s of ps delay wise
rather than a couple of ns delay. You still have i/o delay and routing delay to deal with. As mentioned in another
post, delay is very much not the same thing as jitter.

Bob

On Mon, 18 Jan 2016 14:34:56 -0500
Bob Camp kb8tq@n1k.org wrote:

I wouldn't trust that timing analyzer too much. We just build a TDC using
an Cyclone 4 FPGA here (actually, porting the OHWR delay line TDC from
Spartan to Cyclone) and the timing analysis was... weird, at best.

Although the average delay was about right (40ps and 120ps) it only
showed a two element structure, ie the delays of the chain were
"40ps, 120ps, 40ps, 120ps,..." without any higher level structure
(which should have shown). The test results showed a quite more
detailed structure with few delays over 100ps and most being between
20ps and 80ps. Interestingly, some were close to 0ps, for which
we have no explanation good explanation.

			Attila Kinali

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson

In message 20160120122824.39fb655285dd0e68c3884835@kinali.ch, Attila Kinali w
rites:

Any on-chip PLL's with "spread-spectrum" to fudge EMI tests ?

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

On Wed, 20 Jan 2016 14:13:11 +0000
"Poul-Henning Kamp" phk@phk.freebsd.dk wrote:

Nope, the cyclone4 PLLs do not support spread spectrum.
Also, the 0ps positions were stable (suggesting some FPGA
internal feature to be the cause), but they weren't evenly
spread over the delay chain.

		Attila Kinali

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson

Attila,

On 01/20/2016 03:21 PM, Attila Kinali wrote:

The timing report and estimator is just to make sure that a synchron
design will work. The type of jitter/noise that you see is kind of
typical. It's not that I don't like FPGA, I love it, but I just don't
trust it for precision timing like that.

Cheers,
Magnus

Hi

Been there / done that on both parts. The timing analyzer is doing what it is supposed to do =
analyze the worst case delays against the constraints you provided. It then makes sure that
the data gets where it needs to go “in time” for it to be correct. The approach is typical semiconductor
industry “six sigma over a billion cycles on a billion devices each with a billion gates” sort of thing.
The result is a part that does indeed work. It’s not much use for predicting things like jitter.

Some of which are fabric (routing) delays). Some of which are simply the analog nature of digital
circuits (noise matters, gain matters). Some of them may be a result of auto routing the design rather
than manually placing everything. (Yes manual routing can help. It’s a major pain for fairly little gain).

The explanation is fairly simple, you have a clock and a “data pulse” flying down the delay / carry chain. With
an ASIC you could make sure they take a very linear route through the silicon. With a FPGA you can’t do that.
Both are routed through this and that. When you get down to the ps level, there is no guarantee which one
gets there first. Even if there was, the aperture time on the flip flops is sensitive to things like voltage and temperature.
What you see this time may not be what you see that time. There are a whole bunch of papers on  all of this.
Bottom line, not all indicated data patterns can be placed in a nice orderly plot ( = you don’t know which one
came first). About the only way to order them is to count the zeros. Not perfect, but about the best you can do.

Bob

On Wed, 20 Jan 2016 17:56:31 -0500
Bob Camp kb8tq@n1k.org wrote:

We placed the delay line manualy and run the calibration loop of the
OHWR TDC. Which does a histogram over all bins excited with a (hopefully)
uncorrelated ring oscillator. We tried both the OHWR temperature to binary
encoder and a "count all zeros/ones" version. Both showed the same behaviour,
ie that some bins hardly see any hits. Yes, i would expect this kind of
thing in general, due to the layout/routing of the wires in the FPGA. But
I would expect it to have some kind of regularity, a kind of pattern in the
distance between these un-excitable bins. But there is none. That's why I'm
saying we have no good explanation for it.

We have not had the time to analyze the routing in detail to see whether
there is anything fishy there. I will try to squeeze that in, if possible.

		Attila Kinali

--
It is upon moral qualities that a society is ultimately founded. All
the prosperity and technological sophistication in the world is of no
use without that foundation.
-- Miss Matheson, The Diamond Age, Neil Stephenson

Hi

That was my conclusion about manual routing. You still have the same “gaps”
as autoroute. There obviously are variations in the cells that are not visible from
a macro level view. Given the fine detail involved, that’s not a major surprise. They
are packing stuff in there mighty tight. A 10% variation in this or that probably scores
as “that’s fine” process wise. It’s certainly fine in terms of off the shelf digital logic.
For a TDC that’s probably not a “that’s fine” on some parameters.

Consider the voltage threshold that the logic decides is a one vs a zero. On off the
shelf logic that’s a 20% to 80% sort of spec. It may be more consistent than that, but
they spec it that way. All of your clock and data signals are slew rate limited. A variation
in logic threshold will ultimately come up as a timing issue. There are many things like that
in there ...

Bob

Hi Guys,

Le mercredi 13 janvier 2016 à 09:22 +0000, Jerome Blaha a écrit :

What would it take to make that PPS adjustable with a step <= 1ns ?
I see that the PIC solution has a mean of "arming" the 1PPS to let it
start at the desired time, but the granularity would be of course
10MHz. For example are there easy-to-use programmable delays to reach
the missing precision ?

Xav

Hi

The question is (as always) why?

If you are trying to get to low temperature coef and low jitter and good long term stability ….

No, they really aren’t good enough.

Bob

Moin,

On Sun, 17 Jan 2016 17:32:58 +0100
Gerhard Hoffmann dk4xp@arcor.de wrote:

I had a closer look at the datasheet of the LT3042 and disagree with you
on this conclusion. Yes, the LT3042 uses a current source into a resistor
as reference. But the resistor is bypassed by a HUGE ceramic capacitor.
The resulting low-pass filter has a cut-off frequency in the low hertz
region, if not sub-hertz. Or to cite the datasheet:

One problem that conventional linear regulators face is
that the resistor divider setting the output voltage gains up
the reference noise. In contrast, the LT3042's unity-gain
follower architecture presents no gain from the SET pin
to the output. Therefore, if a capacitor bypasses the SET
pin resistor, then the output noise is independent of the
programmed output voltage. The resultant output noise
is then set just by the error amplifier's noise -- typically
2nV/sqrt(Hz) from 10kHz to 1MHz and 0.8µVRMS in a 10Hz
to 100kHz bandwidth using a 4.7µF SET pin capacitor.

In contrast to that, the current sources in ECL circuits do not have a
bypass capacitor. Or rather, you cannot bypass the current source itself
as it is used as an infinitely large resistor for the differential "pairs"
in the ECL circuit.

If you decrease the value of the by-pass capacitor such that you get
a low pass cut-off frequency in the, let's say, 100Hz range, then you
should see the effect clearly in your measurements.

		Attila Kinali

--
Reading can seriously damage your ignorance.
-- unknown