Accurate pulse with ultra low rise time

Hello, I have a GPS module, an FPGA spartan 3 development kit and a voltage switch 3.3v -10v and vice versa.
I need to take the 1 pulse per second (PPS) which is coming from the GPS and change its width 80µs to 20µs, rise time to 20ns max and amplitude from 3.3v to 10v.

Everyone is connected to each other with wire wrap.

The width convertion isn't a big deal but the others are really hard to solve. See, the rise time of the PPS with a resonance circuit is less than 20ns, of course the wire wrap isn't ideal for this speed (=coil+capacitor) and I get 50ns rise time thus voltage switching cannot be simultaneousley as the voltage switch has its own rise time, 12ns , which is being added and I get 62ns rise time.

The FPGA is'nt helping either, its signal rise time reachs to 40ns and its best shot is 50ns after the original PPS which is also not good, the delay should be short as possible (0ns-5ns).

The solution for all of this is to use a low jitter clock such as Rubidium clock ,make a frequency divider/multiplier and some Hocus Pocus.-But the problem is that I don't have such clock and I can only use the FPGA clock while is being fixed by its DCM core. In short I need your help.

P.S

All of my measurements were taken by digital scope.

If you are that concerned about your risetime, then step one is getting rid of the wirewrap. Dead bug has a lot less drawbacks in that regard.

Anyways, you could do several things if you want better risetime. LVDS transmitters are cheap and can give you pretty good risetime. You could do a couple of amplifier stages to 1) increase the slewrate 2) get to your desired 10 Volt output level. Dunno, it depends on your end goal I'd say.

Since you mention the magic combo of fpga + gps + pps + Rb ... what are you trying to do that you think you need such rise times?

Telling clearly about the intended signal processing would surely help. Level translation of a PPS signal is one thing, pulse width manipulation a second one, but how is it related to a FPGA?

Your post doesn't seem to tell about the actual design problem or an involved specification. 20 ns risetime is a huge number for high speed CMOS (e.g. FPGA) I/O standards and a moderate value for high level logic. I don't see a problem in this regard.

elad1434 said:

The FPGA is'nt helping either, its signal rise time reachs to 40ns and its best shot is 50ns after the original PPS which is also not good, the delay should be short as possible (0ns-5ns).

Click to expand...

Something doesn't seem right about this. (You are using a Spartan 3 development kit, correct?)

You could try changing the slew rate of the I/O signal in the Xilinx constraints file - from slow to fast, if it isn't done so already, but either way that seems questionably high. It leads me to believe something else in the circuit is causing the slow rise-time of that signal. Is there a partial schematic that you can attach or any scope screenshots?

The initial plan was to take the PPS and connect it to the FPGA. The FPGA samples the line and then generates a similar pulse 20us width (simple clock counter) instead of 80us (which is provided by the gps) and then connect the output to the level translator and get what I desired. But what happenned is this: the pulse comes in 50ns after the PPS, the FPGA output rise time is slow -50ns and at the end another 12ns is added to the rise time as a result (I suppose) from simultaneously convertion. Link to level translator datasheet is added below.

I've been searching alot about the constraints subject and nothing mentioned as a high speed I\O or low slew rate... I need a specific name.

LVDS transmitters are cheap and can give you pretty good risetime. You could do a couple of amplifier stages to 1) increase the slewrate 2) get to your desired 10 Volt output

Click to expand...

Could you be more specific? maybe drawing would do.. and it is not that cheap..



https://www.analog.com/static/imported-files/data_sheets/ADG3123.pdf

elad1434 said:

Could you be more specific? maybe drawing would do.. and it is not that cheap..

Click to expand...

I could. But how about some more details on your design?

What I don't quite follow is why you feel the static delay is a problem. I mean, you put your pulse through some circuits and there's bound to be a delay. Generally with timing applications (guessing from the PPS) you don't care as much about absolute delays as you do about the cycle to cycle variations (jitter, phase noise, take your pick). Hence me asking if you could describe the application in more detail.

The initial plan was to take the PPS and connect it to the FPGA. The FPGA samples the line and then generates a similar pulse 20us width (simple clock counter) instead of 80us (which is provided by the gps) and then connect the output to the level translator and get what I desired. But what happenned is this: the pulse comes in 50ns after the PPS, the FPGA output rise time is slow -50ns and at the end another 12ns is added to the rise time as a result (I suppose) from simultaneously convertion. Link to level translator datasheet is added below.

Click to expand...

The mysterious reports about slow FPGA risetimes have been already commented by others. Related to known FPGA specifications, this sounds as a case of inappropriate circuit design. I think, you have to slow down FPGA output signals artificially to get rise times above 1 ns.

But this is a minor detail, also the level conversion. A more serious problem is delay jitter. By design, synchronous FPGA logic will process an incoming PPS pulse in terms of it's internal clock. Even a very fast FPGA clock results in a digital delay jitter of several ns. I don't expect, that this is a wanted effect.

"All of my measurements were taken by digital scope."

what is the sampling rate and bandwidth that was used? if you only have a 20MHz bandwith and don't have effective equivalent-time-sampling, you probably won't have the resolution required.