using lvds

hey..

it´s analogs ad9252

thanks

The serialisation factor in your system is actually 14. The ALTLVDS does not support this, but you could set it to handle a deserialisation of 7 bits and concatenate two 7-bit packets into one 14 bit. ALTLVDS however uses a PLL to sample the inputs, so if you have multiple devices, ADCs in this case) you may run out of PLLs.

However as the outputs of the ADC are nicely source synchronous and are accompanied by a dataclock and a frame-indicator , you can easily deserialise the ADC data channels with simple shiftregisters. Feed the inputs into a DDR-In block and then serialise the 2 bits in a 7-bit shiftregister each. assemble the 2 7-bit buses into a 14-bit bus and define the right moment to register it.

You need to do some work to constrain all this though.

I have done this for ADS527x and AD9222 octal ADCs, unfortunately my code is in AHDL (I do use VHDL nowadays).

Hi there !!!

Are u sure about the value of the serialisation factor? I thought that a serialisationfactor unequal one is only possible if i would mix, say 2 channels, together and transfer the data alternating. so for mixing 2 channels gives an serialisationfactor or deserialisationfactor of 2, so every second bit (beginning with bit 0) belongs to channel 1 and all other to channel 2. So it doesn´t matter how many bits belong to one datastream or sampled value. I´m not sure about but i thought that i found this out while reading through altlvds documentation.

The problem with running out of PLL came also to my mind as i will use more devices so i think i´ll have to find ways to work without the megafunction and use the dataclock and frame-indicator in combination with shiftregisters...

So the solution u provided in your previous post is this possible solution using altlvds or not ? what´s this ddr-in block ? Is it possible to go in shiftregisters with differential signals ??

thanks for helping

greets

AD9252 is basically similar to AD9222, expect for a resolution of 14 versus 12 bit.

I completely agree with josyb about the suggested solution (DDIO + shift register). Also the deserialization factor of 14 is correct. Strictly spoken, you won't necessarily need a PLL for the receiver, because the ADC provide both fast and slow (respectively bit and frame) clock. but, 700 Mbps is pretty on the edge, a means to adjust the clock phases manually may turn out to be badly required. A receiver PLL would use the frame clock (FCO) as input clock and generate the fast clock. You can also connect both ADC clocks to the FPGA and keep all options.

See below a VHDL example of 4-channel 14-Bit ADC receiver, that can be easily changed to 8 Channels.

chan:
FOR I IN 0 TO 3 GENERATE
	lvds_rcv : altddio_in
	GENERIC MAP (
		intended_device_family => "Cyclone III",
		invert_input_clocks => "ON",
		lpm_type => "altddio_in",
		power_up_high => "OFF",
		width => 1
	)
	PORT MAP (
		datain => AD9259_D(I DOWNTO I),
		inclock => fastclock,
		dataout_h => dataout_h(I DOWNTO I),
		dataout_l => dataout_l(I DOWNTO I)
	);
	PROCESS (fastclock)
	BEGIN
      IF rising_edge(fastclock) THEN
         lvds_sr(I) <= lvds_sr(I)(11 downto 0) & dataout_l(I) & dataout_h(I);
		END IF;
	END PROCESS;
	PROCESS (slowclock)
	BEGIN
	   IF reset = '1' THEN
	      lvds_rx(I) <= (others => '0');
      ELSIF rising_edge(slowclock) THEN
         lvds_rx(I) <= lvds_sr(I);
		END IF;
	END PROCESS;
END GENERATE;

There maybe a couple of pitfalls in using both the fastclock and the slowclock:

1. the last falling edge (clocking in the LSB ) is only 1/4 Tc before the slowclock rising which comes down to 714 ps only.

2. at slowclock rising the last two bits are not yet in the shiftregister

It is IMHO advisable to use the slowclock as a data input (if you look at the timing diagram you can see that it has the same timing as the data outputs) and derive a transfer signal from it to clock the shifregister info into the output register.

I managed 4 octals (ADS527x) at 300 MHz in a EP2C8F256C6. The datasheet report shows some headroom for the setup and hold ties, so I think the 350MHz should be quite feasible too. Using a single clock to do all the work will help too.

thanks guys for helping !

but now i´m a little bit confused about all that :-)

1.) serialization/deserialization, ok i misunderstood all that stuff

2.) i can type in the deserialization factor of 14 manually, and in handbook

it´s mentioned "if the number is not available to choose, type the desired

number in this box"! do u think that this won´t function?

3.) if it is possible to tpye in 14 isn´t it better to use lvds megafunction instead of ddio and shiftregister

4.) i if i use DDIO (it´s double data rate megafunction i reckon) and shiftregister (i suppose that this solution works without altlvds megafunction) i´m wondering if this also works with lvds input signals ???

greets

--- Quote Start ---

There maybe a couple of pitfalls in using both the fastclock and the slowclock.

--- Quote End ---

I didn't explicitely mention, that fast- and slowclock in my VHDL code are both PLL output clocks, adjusted for maximum skew margin and correct data receiption. If the receiver is intended for operation without PLL, an addional synchronous FCO delay would be required.

My favourite solution for bitrates near the Cyclone III limits is a receiver PLL with automatic bit phase adjustment, utilizing the ADC test mode and Cyclone III PLL dynamic phase shift.

--- Quote Start ---

2.) i can type in the deserialization factor of 14 manually, and in handbook

it´s mentioned "if the number is not available to choose, type the desired

number in this box"! do u think that this won´t function?

3.) if it is possible to tpye in 14 isn´t it better to use lvds megafunction instead of ddio and shiftregister

--- Quote End ---

As far as I remember, the MegaFunction allows it, but the RTL and gate level synthesis result looks rather strange. If the processing hasn't changed since Quartus 8, DDIO + shift register will be better, I think. At least it's working correctly.

--- Quote Start ---

4.) i if i use DDIO (it´s double data rate megafunction i reckon) and shiftregister (i suppose that this solution works without altlvds megafunction) i´m wondering if this also works with lvds input signals ???

--- Quote End ---

You should have noticed, that both josyb's and my references are dealing with LVDS interfaces. Actually, LVDS is just an I/O standard, that can be assigned to an input port (if it's connected to the non-inverted pin of a differential pin pair).

I didn't have 4 PLLs in the EP2C8 so I had to do without.

I recompiled my block for 350 MHz and adjusted the .sdc for the changed timings and relations. The Multicorner Datasheet reports 150 ps Setup time and 344 ps Hold time for the Data inputs, which is well within the 414 ps as calculated from the ADC's datasheet. The 'auto' device selected by the compiler is an EP2C5T144C6.

On my 'real' design with 4 octals, and 300 MHz operation, the worst case setup is 277 ps and the worst case hold is 422 ps. Two of the blocks have standard Clk inputs, the two other have DPClk inputs.

I'm not a fan of the 'training' approach (sometimes it can't be avoided though), it just bloats the resource usage, complicates start-up, and it this case is not necessary.

thank u for helping..

@FvM, i´ve tried to implement your type of solution. but how do i´ve to declare lvds_sr and lvds_rx so that there is no error in synthesis....

phh it´s long time ago i´ve done vhdl coding, so sorry for that "stupid" question...