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