phase jitter profiles for FPGA?

[sarepairman2]

If I wanted to use a FPGA as a high resolution phase shifter, how does phase jitter look like?

how about phase jitter vs ambient temperature?


I am interested in a high resolution phase shift capability.

Would it be better to use a micro processor and a dedicated phase shift IC to fine tune, rather then doing it entirely in a FPGA?

I imagine it comes down to threshold levels, Vb levels and driver noise on the output driver of the FPGA?

For signals <1MHz

[AndyC_772]

This sounds like a question best answered by looking at the data sheet for the specific FPGA you have in mind; nobody can know (quantitatively) what a technical specification is without at least knowing which device it applies to.

I do know Altera FPGAs have reconfigurable PLLs, in which the phase of the clock can be dynamically reconfigured in steps of 1/8th of the VCO frequency. That's potentially very fine grained phase adjustment, though again, it's impossible to know if it's fine enough for your application without knowing how fine you need.

[Someone]

You wont get much help from the Xilinx datasheets, they usually refer you back to the IP generation tools. There are so many variables involved its hard to provide an accurate estimate of the resultant noise and easier to just buy a dev board and try it.

[Alexei.Polkhanov]

There should be MAX/MIN value available in datasheet(s), but actual estimated value for your specific design probably will be shown in your timing closure report. Quartus II from Altera has "TimeQuest Timing Analyzer"

--- snip ---
derive_clock_uncertainty
The derive_clock_uncertainty command automatically generate clock uncertainty values for FPGA clock signals. Basically clock uncertainty is the jitter of a clock. This command should always be used in your timing constrain file.
--- snap ---

http://www.alterawiki.com/wiki/Timing_Constraints

It is all in software.

[sarepairman2]

the idea is to very very precisely control a H bridge.

I just thought of the FPGA being one way to do it.

more of a thought experiment then anything else.

Would a MCU or FPGA typically be better?

I am guessing the more gates you use the worse it gets... so fpga is nicer?

[Dago]

the idea is to very very precisely control a H bridge.

I just thought of the FPGA being one way to do it.

more of a thought experiment then anything else.

Would a MCU or FPGA typically be better?

I am guessing the more gates you use the worse it gets... so fpga is nicer?

The jitter due to an FPGA would be absolutely negligible when controlling a H-bridge.

[Alexei.Polkhanov]

Yup Dago is right.

To put it into numbers jitter of MCU or FPGA will be probably 2 or 3 orders of magnitude smaller than you would care for H-bridge. We are talking about hundreds of picoseconds to tens of nanoseconds of jitter vs microsecond accuracy that is important for H-bridge. If not then I wonder where would such jitter requirement is coming from?

[sarepairman2]

why would you stop caring about a H bridge?

[Dago]

For a H-bridge the reason why you would generally care about about the edge timing is to prevent overshoot and minimize phase-error (for non-feedback applications not a concern). Overshoot is usually prevented by delaying either side by hundreds of nanoseconds to microseconds. And for phase-error if we assume your H-bridge would be switching at 100 kHz and the FPGA would cause lets say 50ns (a very very large number for jitter from an FPGA) the phase-error caused would be 1% which would make very little difference.

[sarepairman2]

For a H-bridge the reason why you would generally care about about the edge timing is to prevent overshoot and minimize phase-error (for non-feedback applications not a concern). Overshoot is usually prevented by delaying either side by hundreds of nanoseconds to microseconds. And for phase-error if we assume your H-bridge would be switching at 100 kHz and the FPGA would cause lets say 50ns (a very very large number for jitter from an FPGA) the phase-error caused would be 1% which would make very little difference.

depending on where you are putting your energy 1% can be absolutely horrid!

what is the solution to the absolute lowest phase jitter? low noise analog system that uses a high speed comparator?
i.e. something controlled with a low noise high resolution DAC

other then electro mechanical delay line control  O0

[c4757p]

what the hell kind of magical unicorn fart H-bridge are you even trying to build.

[uncle_bob]

For a H-bridge the reason why you would generally care about about the edge timing is to prevent overshoot and minimize phase-error (for non-feedback applications not a concern). Overshoot is usually prevented by delaying either side by hundreds of nanoseconds to microseconds. And for phase-error if we assume your H-bridge would be switching at 100 kHz and the FPGA would cause lets say 50ns (a very very large number for jitter from an FPGA) the phase-error caused would be 1% which would make very little difference.

depending on where you are putting your energy 1% can be absolutely horrid!

what is the solution to the absolute lowest phase jitter? low noise analog system that uses a high speed comparator?
i.e. something controlled with a low noise high resolution DAC

other then electro mechanical delay line control  O0

Hi

Comparators are very noisy devices. You will be lucky to get into low nanoseconds with most of them. If you need "absolute low" that will be in the femto second (1x10^-15) range. Is it worth > $10K a copy to do that in your application? If so, it can be done.

Bob

[sarepairman2]

For a H-bridge the reason why you would generally care about about the edge timing is to prevent overshoot and minimize phase-error (for non-feedback applications not a concern). Overshoot is usually prevented by delaying either side by hundreds of nanoseconds to microseconds. And for phase-error if we assume your H-bridge would be switching at 100 kHz and the FPGA would cause lets say 50ns (a very very large number for jitter from an FPGA) the phase-error caused would be 1% which would make very little difference.

depending on where you are putting your energy 1% can be absolutely horrid!

what is the solution to the absolute lowest phase jitter? low noise analog system that uses a high speed comparator?
i.e. something controlled with a low noise high resolution DAC

other then electro mechanical delay line control  O0

Hi

Comparators are very noisy devices. You will be lucky to get into low nanoseconds with most of them. If you need "absolute low" that will be in the femto second (1x10^-15) range. Is it worth > $10K a copy to do that in your application? If so, it can be done.

Bob

how can it be done?

[joeqsmith]

I had collected some data several years ago looking at the noise of an output pin from a Xilinx device.   Good layout, supply, etc, looks like I was in the 1.88ps RMS.   Comparing two pins, looks like I measured around 860fs RMS.   

[sarepairman2]

oh wow. how does phase drift look like over temperature and aging?

[AndyC_772]

Quantitatively, what jitter and phase noise performance do you actually need?

What are you going to physically connect to the device pins?

I did some work a few years ago that required absolutely the lowest jitter physically achievable. Suffice to say that as soon as your signal ceases to be a differential pair, routed as a parallel, impedance controlled trace on your PCB, the phase noise and jitter performance will skyrocket. It's inevitable.

[filssavi]

There's something I don't understand here, an H bridge is usually composed of power devices, Vertically diffused MOS or IGBT usually, either way having sub-picosecond accurate signals with them is like trying to aim a nuclear missile at a 1 mm target, shure you can do it, but the explosion will blow up the entire city anyway so what's the point in doing that, you just need to get close by

getting back to our devices a MOS turn on time you read on the datasheet is not an exact figure, it varies with the PCB layout (gate trace inductance limit the current rise and thus the speed at which your device switched on/off),  mosfet capacitances (in turn influenced by the operating voltages, process and mos geometry variation at the foundry) and so on, the worst thing is that for all these values you get most of the times only typical figures on the datasheet no min/max or graph.

and while some of this variations are static and can be calibrated out some others aren't (like the various capacitances vs VDS), and even if the dependency isn't that strong  even a 0.0001 change in turn on time will have on your load by far much greater effects than what your FPGA/MCU will have

and I dont get the energy bit either, jitter is random in nature (assuming independent, gaussian distribution jitter on turn on and turn off of the H-bridge, for lack of better data) you have 0.5 probability that the jitter will be in the same direction at the two ends, having no net effect on the time the load is energized, and 0.25 prob that the jitter will actually decrease the energy you use on the load (by turning on later and turning off before) and only 0.25 prob that the energy will go up, so i think designing around that is a waste of time

[tggzzz]

If I wanted to use a FPGA as a high resolution phase shifter, how does phase jitter look like?
how about phase jitter vs ambient temperature?
I am interested in a high resolution phase shift capability.
Would it be better to use a micro processor and a dedicated phase shift IC to fine tune, rather then doing it entirely in a FPGA?
I imagine it comes down to threshold levels, Vb levels and driver noise on the output driver of the FPGA?
For signals <1MHz

Start by removing the unhelpful adjectives like "high", and replace them with numbers or ranges of numbers. Your idea of "high" might be someone else's "trivially low".

Next, design the circuit so that its operation is defined by fundamental properties not by the vague variable properties of an individual device. Thus clock frequency is good whereas propagation delay or software loop speed are poor.

Finally, based on the properties of your design, work out what it properties will be for an ideal device. If that is insufficient for your requirements, ask about the properties of individual devices.

[uncle_bob]

how can it be done?

Hi

Are fetmoseconds close enough or do you need attoseconds? Is $100K a unit in thousand piece volumes to much?

You will need a good optical setup and the ability to fabricate custom semiconductors at state of the art geometries for a start.

Of course you will also have to use the same devices in your H bridge. You will also have to be happy with a few mili amps of current and a one volt swing on the bridge. Any device that actually carries switched power will have crapped out back at the nanoseconds level.

No this is not "absolute best" quite yet. We are only up to about a billion dollars in tooling. If you have significantly more than that to invest up front, there are still other things that can be done. Without some sort of numbers on what you are after, even starting on a solution is pointless. Analyzing your need is always the first step in any design.

Bob

[sarepairman2]

well if i give you people specifications then you stop being creative

i got alot of interesting ideas from this thread. i usually post to learn broad things not to solve specific design problems

[tggzzz]

well if i give you people specifications then you stop being creative
i got alot of interesting ideas from this thread. i usually post to learn broad things not to solve specific design problems

If you want a discussion rather than answers, it would be polite to indicate that in the original post.

[uncle_bob]

well if i give you people specifications then you stop being creative

i got alot of interesting ideas from this thread. i usually post to learn broad things not to solve specific design problems

Hi

We might also be able to give you exact data on jitter in a specific FPGA configuration  if we knew what you actually were after.

Bob