Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21602 Discussions

interface stratixIV with an external ultrafast comparator

Altera_Forum
Honored Contributor II
5,493 Views

Hi everybody :)  

 

we need to interface ultrafast comparator- ADCMP572 - of analog device to a stratix4 device to perform one bit conversion. 

we expect that the comparator will ouput very short pulses(200 ps). The goal is to sample those pulses with FPGA. 

The comparator datasheet is attached 

 

1) from a physical point of view, at which FPGA INPUT should we connect the output of the comparator -CML- in order that the short pulses can travel the FPGA with a minimum distortion ? must we connect to stratixIV transceiver only or can we to another inputs ? 

 

2) we need to drive the LATCH differential input with a minimum jitter (<100ps) ? From which output of FPGA should we drive it ? must we connect to stratixIV transceiver only or can we to another inputs ? 

 

Waiting for your response.. 

Shalom
0 Kudos
30 Replies
Altera_Forum
Honored Contributor II
1,990 Views

1. To achieve 200 ps or better timing resolution, you absolutely need the Gigabit receivers deserializer operation. You have to operate the receiver DC coupled, in basic mode, without any automatic alignment or other special functions. 

 

2. I don't see a purpose for latched comparator operation, as far as you described the application.
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

I think that making use of the latch function of the comparator is the only way to make it work. By connecting the latch input to a GT output generating a 5GHz clock the output timing of the comparator is now synchronous to the reference clock of the GT receiver. The GT receiver will have to be kept into the LTR mode as the data signal has no clock information embedded. I suppose phase shifting the reference input clock of the GT receiver will be useful in aligning the data input.

0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

 

--- Quote Start ---  

I think that making use of the latch function of the comparator is the only way to make it work. 

--- Quote End ---  

 

Why, the input bitstream will be latched by the receiver as well. A single bit can be either '0' or '1', you don't get more information by latching it externally before. Furthermore, not latching the signal will increase the available time resolution up to the maximum bit rate of the Statix IV device. But implementation details depend of course on the exact design purpose, that hasn't been said yet.
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

Using the latch feature of the comparator would guarantee proper sampling by the GT receiver. In the other case we rely on the sampling mechanism built into the the GT receiver, which is for receiving centered aligned data. But it is certainly worth considering. Note that the comparator's data sheet specifies a 80 ps minimum pulse width or 6.25 GHz.

0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

 

--- Quote Start ---  

In the other case we rely on the sampling mechanism built into the the GT receiver, which is for receiving centered aligned data. 

--- Quote End ---  

 

Of course. But what problems do you expect when sampling asynchronous data? I can't see any.
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

The internal sampling is 'optimized' for centered aligned data in a communications channel. If the data is not properly aligned we get an error and do the error recovery.  

In the case of using this mechanism for asynchronous sampling the output of the deserialiser may possibly not truthfully represent that input as we don't have any real idea how it behaves when e.g. the data changes state at the sampling moment. Of course (quite probably) it may just go fine, some deeper insight how the GT receiver operates would help here. On the other hand the latch feature in the comparator is well specified.  

Now shalom could connect a GT output as the latch clock in his design anyway. This way he can try both modes. Interesting exercise!?
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

I also prefer to evaluate the actual device behaviour empirically and determine e.g. sampling time uncertainty. The required 100ps jitter should be achieved by Stratix IV according to the data rate specification, I think.

0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

Hi FvM and JosyB 

 

Thank's for your interess at the problem and for the Help ;)  

 

1) purpose of latch input: in applications where the sampled signal is periodic, we can at each period, sample the input at different phase of the period with the help of the Latched input(where the Hold and Setup time is relatively low - 5/15 ps) we can have a relatively high sampling rate of the periodic signal. 

 

from a voltage point of view, is the output of the Comparator correspond to the input of Gigabit Transceiver of stratixIV ?  

What about the Lacth input ? From a voltage point of view - From a physical point of view - where should we connect it to the FPGA? 

 

Shalom
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

CML sounds O.K. It's important to choose an I/O standard that can work DC coupled. 

 

Regarding driving the latch from the FPGA. I fear, only Gigabyte transceivers can provide the intended bit timing through serializer. I fear however, that the overall jitter performance won't be better than achieved by the receiver alone. But if you provide the option in your hardware design, you can operate the comparator latched or pass-through as well and test what's better. To fully utilize the jitter performance of the comparator, you would need an external timing generator, I think.
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

OK! 

 

What about if we use only physical i/o of transceiver(transmitter for Latch input, and Receiver for Comparator output) without using Transceiver MegaFunction, but using a custom code based on PLL's (that can achieve a 78ps resolution) ? will we able to utilize the entire performance of the i/o?
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

Looking at the DC and Switching Characteristics page 1-38 and 1-39 Altera specifies/mentions a 0.32 UI total jitter for the XLAUI/CAUI case and also .032 UI for the SFI-S transmitter at 11.3 Gbps. This comes down to 27.6 ps. 

Both specs have high RefClk frequencies (644.53 and 706.25) driven at the dedicated reference clock inputs. 

 

Shalom, that's about what I had in mind. However just using the physical IO is not enough, you'll have to pass via the GT blocks, but you can use the MegaWizard to generate the TX-part to generate the Latch signal and the RX-part to sample the incoming signal. 

To achieve the phased sampling you will probably have to use an external oscillator with a variable phase. I don't see any references in the Stratix IV doc about this. Remember the GX/GT blocks are made for communication and as such only need to generate a 90 degree (or centered) internal clock to sample the incoming data stream. Using an internal PLL to feed the GT block is a possibility but the jitter may be higher?
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

Probably Higher... 

But there is a dynamic(real time) reconfiguration into the PLL-with a 78ps resolution. we can eventually use this option to "achieve the phased sampling". 

Mean feed the latch input from a pll output only by using the I/O GT ? the jitter will be always inferior to 100ps ??
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

Shalom, 

 

Referring back to the SIV manual it could be down to 27.6 ps 

The latch enable for the comparator is effectively the output of a GT transmitter block running at 10 (or 11.3) GHz and generating a 5 GHz clock with about 32 ps jitter, but it then relies on using the nearby RefClk inputs. You could use an external clock synthesizer (e.g. ADF4350) to generate a very low jitter input clock with programmable phase.
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

What is important for us now is not the high frequency we can achieve for the Latch input, but the jitter of its driver, is the important parametter for a better accuracy of the sampling,so.. 

 

..I mean, feed the Latch input from a PLL output only, by using the GT I/O PIN on the StratixIV but without using GT magafunction. what about this? what will be the jitter of this output ?
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

I don't think you can use the GT IO pin as the output of any PLL, that's why I suggested using the TX-part of a GT block and generate a 5 GHz clock with tying a fixed pattern of 0101010... to the transmitter data input. 

Using a normal PLL's output has way too much jitter. 

What is the actual speed your are aiming at? I just went for the idea that you'd use a StratixIV for it's speed. Can you tell us more about the application ? (just male curiousness ...)
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

what we can tell for the application: we have a periodic random signal that we want to sample. 

this random periodic signal can be a high accuracy radar echo that we want to sample. 

We expect comparator output pulses of 100-200ps width, and larger. 

Given that the signal is periodic, we can sample at each period at a different phase, by driving the Latch input at different phase! A StratixIV PLL can generate a clock with a 78ps phase delay (dynamically reconfigurable), so we can sample at each period, with this clock , at phase delays of 78ps, so having a sampling rate of 78ps. 

 

So what is most important for us now, is to achieve a relatively low jitter, and not necessarily a high speed... 

Later, we will also want to sample this periodic signal also with the aid of GT receiver megafunction.. but NOW we want to check what are the limit whithout using GT magafunction. 

This is why we are asking, is there any possibilitys of using GT I/O PIN without using GT megafunction , just to use the high frequency capability of those PIN, if there ? in order that the signal can enter the FPGA with a minimum distortion-from comparator output; or output the FPGA with a minimum jitter, to drive the Latch input.
0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

The GX/GT pins are connected to the GX/GT blocks and I didn't see a possibility to drive them directly from the a PLL or any other logic for that matter. You could ask your FAE to verify that. However generating the clock via the GX/GT block like I described is not difficult nor that time consuming. I normally make a small project to test such things using the Quartus internal simulator in timing mode (in fact that's what I'm doing now for a StratixII GX project ...)

0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

I complete agree with josyb's understanding of the GXB hardware capabilities. That's, what the transceiver block is designed for. I don't expect that there are other connection options for the specific blocks than shown in the hardware manual.

0 Kudos
Altera_Forum
Honored Contributor II
1,990 Views

OK JosyB and FvM ! its already a good information. 

Thanks for Help, i think we have no choice..We can't use a custom design only go with transceiver megafunction, using your advices to implement it !
0 Kudos
Altera_Forum
Honored Contributor II
1,889 Views

Hi everybody! 

 

we have talked with the FAE in our country, and he tell us that for this application we cannot use the GT receiver because we need to transmit with 8/10 in order that in the receiver we can use the clock recovery... is this true ?? 

The question is : in application that we dont use the transmitter gt, can we sample an asynchronous signal with the GT receiver only ( with a specified data rate) ? 

 

Shalom
0 Kudos
Reply